draft-weiler-dnssec-dlv-pre00.txt		draft-weiler-dnssec-dlv-pre01.txt
	S. Weiler		S. Weiler
	22 May 2005		SPARTA, Inc.
			February 8, 2006
	DNSSEC Lookaside Validation (DLV)		DNSSEC Lookaside Validation (DLV)
	draft-weiler-dnssec-dlv-pre00.txt		draft-weiler-dnssec-dlv-pre01.txt
	Copyright Notice		Copyright Notice
	Copyright (C) Samuel Weiler (2005).		Copyright (C) Samuel Weiler (2006).
	Abstract		Abstract
	DNSSEC Lookaside Validation (DLV) is a mechanism for publishing		DNSSEC Lookaside Validation (DLV) is a mechanism for publishing
	DNSSEC trust anchors outside of the DNS delegation chain. It		DNSSEC trust anchors outside of the DNS delegation chain. It allows
	allows resolvers to validate DNSSEC-signed data from zones whose		resolvers to validate DNSSEC-signed data from zones whose ancestors
	ancestors either aren't signed or refuse to publish DS records for		either aren't signed or refuse to publish DS records for their
	their children.		children.
			Changes from pre00 to 00
			An earlier version of this draft was circulated privately beginning
			in May 2005. The primary difference between that document and this
			one is the resolver policy for choosing DLV entries from one DLV
			domain, which could have a tremendous impact on load at the DLV
			domain's authoritative servers. This document describes a policy of
			"Closest Encloser Trumps", as described in Section 3.2.2 of [8]. The
			previous version described a policy of "Accept Any Success".
	1. Introduction		1. Introduction
	DNSSEC [RFC4033] authenticates DNS data by building public-key		DNSSEC [1] [2] [3] authenticates DNS data by building public-key
	signature chains along the DNS delegation chain from a root of		signature chains along the DNS delegation chain from a trust anchor,
	trust, ideally the DNS root. Due to a myriad of technical and		ideally a trust anchor for the DNS root.
	political concerns, it appears unlikely that many delegation-heavy
	zones, including the root and most generic top level domains
	(gTLDs), will sign their zones in the near future, which leaves DNS
	resolvers with no means to validate data from the children of those
	zones without maintaining a large number of preconfigured keys.
	This document describes a way to publish trust anchors in the DNS		This document describes a way to publish trust anchors in the DNS but
	but outside of the normal delegation chain.		outside of the normal delegation chain.
	Some design trade-offs leading to the mechanism presented here are		Some design trade-offs leading to the mechanism presented here are
	described in [INI19].		described in [8].
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [4].
	2. Architecture		2. Architecture
	DNSSEC Lookaside Validation allows a set of well-known domains,		DNSSEC Lookaside Validation allows a set of well-known domains,
	called "DLV domains", to publish secure entry points for zones that		called "DLV domains", to publish secure entry points for zones that
	are not their own children.		are not their own children.
	With DNSSEC, validators may expect a zone to be secure when they		With DNSSEC, validators may expect a zone to be secure when they have
	have one of two things: a preconfigured trust anchor for the zone		one of two things: a preconfigured trust anchor for the zone or a
	or a validated DS for the zone in its parent. DLV adds a third		validated DS for the zone in its parent (which presumes a
	mechanism: an entry in a DLV domain. Whenever a DLV domain		preconfigured trust anchor for the parent or another ancestor). DLV
	publishes a DLV RRset for a zone, a resolver may expect the named		adds a third mechanism: a validated entry in a DLV domain (which
	zone to be signed. Absence of a DLV RRset for a zone does not		presumes a preconfigured trust anchor for the DLV domain). Whenever
	necessarily mean that the zone should be expected to be insecure;		a DLV domain publishes a DLV RRset for a zone, a resolver may expect
			the named zone to be signed. Absence of a DLV RRset for a zone does
			not necessarily mean that the zone should be expected to be insecure;
	if the resolver has another reason to believe the zone should be		if the resolver has another reason to believe the zone should be
	secured, validation of that zone's data should still be attempted.		secured, validation of that zone's data should still be attempted.
	3. DLV Domains		3. DLV Domains
	A DLV domain includes trust statements about descendants of a single		A DLV domain includes trust statements about descendants of a single
	zone, called the 'target' zone. For example, the DLV domain		zone, called the 'target' zone. For example, the DLV domain
	trustbroker.example.com could target the .org zone and the DLV		trustbroker.example.com could target the .org zone and the DLV domain
	domain bar.example.com could target the root.		bar.example.com could target the root.
	A DLV domain contains one or more DLV records for each of the		A DLV domain contains one or more DLV records [5] for each of the
	target's descendant zones that have registered security information		target's descendant zones that have registered security information
	with it. For a given zone, the corresponding name in the DLV		with it. For a given zone, the corresponding name in the DLV domain
	domain is formed by replacing the target zone name with the DLV		is formed by replacing the target zone name with the DLV domain name.
	domain name. For example, assuming the DLV domain
	trustbroker.example.com targets the .org zone, any DLV records for
	the zone example.org can be found at
	example.trustbroker.example.com. DLV records for the org zone can
	be found at the apex of trustbroker.example.com.
	A DLV domain SHOULD NOT contain data other than DLV records,		For example, assuming the DLV domain trustbroker.example.com targets
	appropriate DNSSEC records validating that data, the apex NS and		the .org zone, any DLV records corresponding to the zone example.org
	SOA records, and, optionally, delegations.		can be found at example.trustbroker.example.com. DLV records
			corresponding to the org zone can be found at the apex of
			trustbroker.example.com.
	To gain full benefit from aggressive negative caching, described in		As another example, assuming the DLV domain bar.example.com targets
	Section 6, a DLV domain SHOULD NOT use minimally-covering NSEC		the root zone, DLV records corresponding to the zone example.org can
	records, as described in [EPSILON].		be found at example.org.bar.example.com. DLV records corresponding
			to the org zone can be found at org.bar.example.com. And DLV records
			corresponding to the zone zone itself can be found at the apex of
			bar.example.com.
	4. DLV Resource Record		A DLV domain SHOULD NOT contain data other than DLV records,
			appropriate DNSSEC records validating that data, the apex NS and SOA
			records, and, optionally, delegations.
	The DLV resource record has exactly the same wire and presentation		To gain full benefit from aggressive negative caching, described in
	formats as the DS resource record, defined in [RFC4034] and		section X, a DLV domain SHOULD NOT use minimally-covering NSEC
	RFC3658. It uses the same IANA-assigned values in the algorithm		records, as described in [6], and it SHOULD NOT use NSEC3 records, as
	and digest type fields as the DS record. (Those IANA registries		described in [7]
	are known as the "DNS Security Algorithm Numbers" and "DS RR Type
	Algorithm Numbers" registries.)
	Unlike the DS record, the DLV record MUST NOT appear on the		4. Overview of Resolver Behavior
	parent's side of a zone cut. Consequently, DLV records to not
	require the special processing described in section 2.2.1 of
	RFC3658. DLV records MAY appear at the apex of a zone.
	5. Resolver Behavior, Overview		To minimize load on the DLV domain's authoritative servers as well as
			query response time, a resolver SHOULD first attempt validation using
			any applicable (non-DLV) trust anchors. If the validation succeeds
			(with a result of Secure), DLV processing need not occur.
	When configured with a trust anchor for a DLV domain, a resolver		When configured with a trust anchor for a DLV domain, a resolver
	SHOULD attempt to validate all queries at and below the target of		SHOULD attempt to validate all queries at and below the target of
	that DLV domain.		that DLV domain.
	To do validation using DLV, a resolver looks for a (validated) DLV		To do validation using DLV, a resolver looks for a (validated) DLV
	RRset applicable to the query and uses it as though it were a DS		RRset applicable to the query, as described in the following section,
	RRset to validate the answer using the normal procedures in RFC4035		and uses it as though it were a DS RRset to validate the answer using
	Section 5.		the normal procedures in RFC4035 Section 5.
	The resolver continues to search for applicable DLV RRsets and
	attempt validation using them until either the answer is validated
	as Secure or all possible applicable DLV records have been checked.
	If any of the applicable DLV records led to a Secure result, the
	answer is treated as Secure. If all of the DLV records led to
	Insecure validation results, the answer is treated as Insecure.
	And if no DLV records led to Secure results and at least one led to
	a Bogus result, the answer is treated as Bogus.
	The choice of which DLV record(s) to use, and in what order, has a
	significant impact on the query load seen at DLV domain
	authoritative servers. Consequently, resolvers are advised to
	closely follow the algorithm in the following section. More
	detailed discussion of this algorithm and other possible choice can
	be found in [INI19].
	5.1 Resolver Behavior, Detail		For each query, the resolver attempts validation using the "closest
			enclosing" DLV RRset, which is the DLV RRset with the longest name
			that matches the query or could be an ancestor of the QNAME. For
			example, assuming the DLV domain trustbroker.example.com targets the
			.org zone, and there exist DLV RRsets named trustbroker.example.com
			(applicable to .org), example.trustbroker.example.com (applicable to
			example.org, and sub.example.trustbroker.example.com (applicable to
			sub.example.org), a resolver would use the
			sub.example.trustbroker.example.com DLV RRset for validating queries
			for sub.example.org.
	To minimize load on the DLV domain's authoritative servers as well		This policy is slightly different than the one discussed in previous
	as query response time, a resolver SHOULD accept any Secure		versions of this document. More detailed discussion of this policy
	validation result (as described in RFC4035 Section 4.3) as decisive		and other possible choices can be found in [8].
	and SHOULD NOT attempt to exhaustively search for all possible DLV
	RRsets applicable to the QNAME after a Secure result has been
	found. Furthermore, the resolver SHOULD use cached DLV RRsets and
	careful choice of queries to attempt to find a Secure validation
	result with the minimum number of queries to the DLV domain.
	Accordingly, a resolver SHOULD first attempt validation using any		5. Resolver Behavior
	applicable (non-DLV) trust anchors. If the validation succeeds
	(with a result of Secure), DLV processing need not occur.
	If other (non-DLV) trust anchors failed to yield a Secure		As above, to minimize load on the DLV domain's authoritative servers
	validation result, a resolver SHOULD then attempt to use any		as well as query response time, a resolver SHOULD first attempt
	applicable cached DLV RRsets. For clarity, it may be possible for		validation using any applicable (non-DLV) trust anchors. If the
	several DLV RRsets within a single DLV domain to be applicable to		validation succeeds (with a result of Secure), DLV processing need
	a given QNAME. Using the previous example of the bar.example.com		not occur.
	DLV domain targeting the root and a QNAME of www.example.org,
	there could be four DLV RRsets of relevance:
	-- a DLV RRset at bar.example.com corresponding to the root's
	DNSKEY(s),
	-- a DLV RRset at org.bar.example.com,
	-- a DLV RRset at example.org.bar.example.com, and
	-- a DLV RRset at www.example.org.bar.example.com.
	If none of the cached DLV RRsets leads to a Secure result (or there		To find the closest enclosing DLV RRset for a given query, the
	are no applicable cached DLV RRsets), the resolver queries the DLV		resolver starts by looking for a DLV RRset corresponding to the
	domain to attempt to find another of the applicable DLV RRsets. To		QNAME. If it doesn't find a DLV RRset for that name (as confirmed by
	minimize the number of queries to the DLV zone, it is suggested		the presence of a validated NSEC record) and that name is not the
	that the resolver start with a query for the least specific		apex of the DLV domain, the resolver removes the leading label from
	applicable DLV RRset (the one with the fewest labels), then		the name and tries again. This process is repeated until a DLV RRset
	progress to longer names. Section 8 discusses a slightly different		is found or it is proved that there is no enclosing DLV RRset
	strategy.		applicable to the QNAME. In all cases, a resolver SHOULD check its
			cache for the desired DLV RRset before issuing a query. Section 8
			discusses a slight optimization to this strategy.
	Having found an applicable DLV RRset or received a proof that the		Having found the closest enclosing DLV RRset or received a proof that
	requested record doesn't exist, the resolver MUST validate that		no applicable DLV RRset exists, the resolver MUST validate that RRset
	RRset or non-existence proof using the normal procedures in Section		or non-existence proof using the normal procedures in Section 5 of
	5 of RFC4035. In particular, any delegations within the DLV domain		RFC4035. In particular, any delegations within the DLV domain need
	need to be followed, with normal DNSSEC validation applied. If		to be followed, with normal DNSSEC validation applied. If validation
	validation of the DLV RRset leads to a result of Insecure (the DLV		of the DLV RRset leads to a result of Bogus, then it SHOULD NOT be
	record is in an unsecured portion of the DLV tree), then it SHOULD		used and the validation result for the original query SHOULD be
	NOT be used. If the validation of the DLV RRset leads to a result		Bogus, also. If validation of the DLV RRset leads to a result of
	of Secure, then resolver then treats that DLV RRset as though it		Insecure (the DLV record is in an unsecured portion of the DLV tree),
	were a DS RRset for the applicable zone and attempts validation		then it SHOULD NOT be used and the validation result for the original
	using the procedures described in RFC4035 Section 5. If any such		query SHOULD be Insecure, also. If the validation of the DLV RRset
	validation returns a Secure result, the answer is treated as Secure		leads to a result of Secure, then resolver then treats that DLV RRset
	and DLV processing ends. Otherwise, the resolver continues to		as though it were a DS RRset for the applicable zone and attempts
	query for other applicable DLV RRsets until a Secure validation		validation using the procedures described in RFC4035 Section 5.
	results or all applicable DLV RRsets have been exhausted.
	To avoid confusing authors of resolvers and protocol		To avoid confusing authors of resolvers and protocol specifications,
	specifications, a resolver SHOULD NOT attempt to validate data from		a resolver SHOULD NOT attempt to validate data from a DLV domain
	a DLV domain using DLV.		using DLV.
	6. Aggressive Negative Caching		6. Aggressive Negative Caching
	To minimize load on authoritative servers for DLV domains,		To minimize load on authoritative servers for DLV domains,
	particularly those with few entries, DLV resolvers SHOULD implement		particularly those with few entries, DLV resolvers SHOULD implement
	aggressive negative caching, as defined in this section.		aggressive negative caching, as defined in this section.
	Previously, cached negative responses were indexed by QNAME,		Previously, cached negative responses were indexed by QNAME, QCLASS,
	QCLASS, QTYPE, and the setting of the CD bit (see RFC4035 section		QTYPE, and the setting of the CD bit (see RFC4035 section 4.7) and
	4.7) and only queries matching the index would be answered from the		only queries matching the index would be answered from the cache.
	cache. With aggressive negative caching, the resolver, in addition		With aggressive negative caching, the resolver, in addition to
	to checking to see if the answer is in its cache before sending a		checking to see if the answer is in its cache before sending a query,
	query, checks to see whether any cached and validated NSEC record		checks to see whether any cached and validated NSEC record denies the
	denies the existence of the sought record(s).		existence of the sought record(s).
	Using aggressive negative caching, a resolver will not make		Using aggressive negative caching, a resolver will not make queries
	queries for any name covered by a cached and validated NSEC record.		for any name covered by a cached and validated NSEC record.
	Furthermore, a resolver answering queries from clients will		Furthermore, a resolver answering queries from clients will
	synthesize a negative answer whenever it has an applicable		synthesize a negative answer whenever it has an applicable validated
	validated NSEC in its cache [unless the CD bit was set on the		NSEC in its cache unless the CD bit was set on the incoming query.
	incoming query?].
	7. Overlapping DLV Domains		7. Overlapping DLV Domains
	It is possible to have multiple DLV domains targeting overlapping		It is possible to have multiple DLV domains targeting overlapping
	portion of the DNS hierarchy. For example, two DLV domains,		portion of the DNS hierarchy. For example, two DLV domains, perhaps
	perhaps operated by different parties, might target the same zone,		operated by different parties, might target the same zone, or one DLV
	or one DLV domain might target the root while another targets .org.		domain might target the root while another targets .org.
	The choice of precedence in these cases is left up to the		If a resolver supports multiple DLV domains, the choice of precedence
	implementation and MAY be exposed as a configuration option to the		in case of overlap is left up to the implementation and SHOULD be
	user. As a default, it is suggested that the most specific DLV		exposed as a configuration option to the user. As a default, it is
	domain be given precedence.		suggested that the most specific DLV domain be given precedence.
	8. Optimization		8. Optimization
	This section proposes an immature and untested proposed		This section proposes an immature and untested proposed optimization
	optimization to further reduce query load on DLV servers.		to further reduce query load on DLV servers and improve resolver
			response time. This is not intended to be an optional extension --
			if included in the final DLV specification, it must be supported by
			all DLV-aware name servers and resolvers.
	Resolver side: resolvers, when making a DLV query, should ask for		Authoritative servers, when processing a query for a DLV RRset,
	the most specific DLV record first.		should include all DLV RRsets potentially applicable to a query in
			the Additional section of the response as well as NSEC records
			proving the non-existence of any other applicable DLV records in the
			DLV domain.
	Authoritative server side: authoritative servers, when processing a		Resolvers still seek out of the closest enclosing DLV RRset first.
	DLV query, should include all DLV RRsets potentially applicable to		Should they receive any data about other DLV RRsets in the zone, they
	a query in the Additional[???] section of the response as well as		may cache and use it (assuming that it validates), thus avoiding
	NSEC records proving the non-existence of any other applicable		further round-trips to the DLV domain's authoritative servers.
	DLV records with the DLV domain.
	This optimization may preclude the use the delegations within a DLV		This optimization may preclude the use the delegations within a DLV
	domain.		domain.
	9. Security Considerations		9. Security Considerations
	Resolvers MUST NOT use a DLV record unless it has been successfully		Resolvers MUST NOT use a DLV record unless it has been successfully
	authenticated. Normally, resolvers will have a trust anchor for		authenticated. Normally, resolvers will have a trust anchor for the
	the DLV domain and use DNSSEC to validate the data in it.		DLV domain and use DNSSEC to validate the data in it.
	Aggressive negative caching increases the need for resolvers do		Aggressive negative caching increases the need for resolvers do some
	some basic validation of incoming NSEC records before caching them.		basic validation of incoming NSEC records before caching them. In
	In particular, the 'next name' field in the NSEC record must be		particular, the 'next name' field in the NSEC record must be within
	within the zone that generated (and signed) the NSEC. Otherwise, a		the zone that generated (and signed) the NSEC. Otherwise, a
	malicious zone operator could generate an NSEC that reaches out of		malicious zone operator could generate an NSEC that reaches out of
	its zone -- into its ancestor zones, even up into the root zone --		its zone -- into its ancestor zones, even up into the root zone --
	and use that NSEC to spoof away any name that sorts after the name		and use that NSEC to spoof away any name that sorts after the name of
	of the NSEC. We call these overreaching NSECs. More insidiously,		the NSEC. We call these overreaching NSECs. More insidiously, an
	an attacker could use an overreaching NSEC in combination with a		attacker could use an overreaching NSEC in combination with a signed
	signed wildcard record to substitute a signed positive answer in		wildcard record to substitute a signed positive answer in place of
	place of the real data. This checking is not a new requirement --		the real data. This checking is not a new requirement -- these
	these attacks are a risk even without aggressive negative caching.		attacks are a risk even without aggressive negative caching.
	However, aggressive negative caching makes the checking more		However, aggressive negative caching makes the checking more
	important. Before aggressive negative caching, NSECs were cached		important. Before aggressive negative caching, NSECs were cached
	only as metadata associated with a particular query. An		only as metadata associated with a particular query. An overreaching
	overreaching NSEC that resulted from a broken zone signing tool or		NSEC that resulted from a broken zone signing tool or some
	some misconfiguration would only be used by a cache for those		misconfiguration would only be used by a cache for those queries that
	queries that it had specifically made before. Only an overreaching		it had specifically made before. Only an overreaching NSEC actively
	NSEC actively served by an attacker could cause misbehavior. With		served by an attacker could cause misbehavior. With aggressive
	aggressive negative caching, an overreaching NSEC can cause more		negative caching, an overreaching NSEC can cause more broader
	broader problems even in the absence of an active attacker. This		problems even in the absence of an active attacker. This threat can
	threat can be easily mitigated by checking the bounds on the NSEC.		be easily mitigated by checking the bounds on the NSEC.
	As a reminder, resolvers MUST NOT use the mere presence of an		As a reminder, resolvers MUST NOT use the mere presence of an RRSIG
	RRSIG or apex DNSKEY RRset as a trigger for doing validation,		or apex DNSKEY RRset as a trigger for doing validation, whether
	whether through the normal DNSSEC hierarchy or DLV. Otherwise, an		through the normal DNSSEC hierarchy or DLV. Otherwise, an attacker
	attacker might perpetrate a downgrade attack by stripping off those		might perpetrate a downgrade attack by stripping off those RRSIGs or
	RRSIGs or DNSKEYs.		DNSKEYs.
			RFC4034 Section 8 describes security considerations specific to the
			DS RR. Those considerations are equally applicable to DLV RRs. Of
			particular note, the key tag field is used to help select DNSKEY RRs
			efficiently, but it does not uniquely identify a single DNSKEY RR.
			It is possible for two distinct DNSKEY RRs to have the same owner
			name, the same algorithm type, and the same key tag. An
			implementation that uses only the key tag to select a DNSKEY RR might
			select the wrong public key in some circumstances.
			For further discussion of the security implications of DNSSEC see
			RFC4033, RFC4034, and RFC4035.
	10. IANA Considerations		10. IANA Considerations
	IANA has assigned DNS type code X to the DLV resource record from the		This document has no IANA actions.
	Specification Required portion of the DNS Resource Record Type
	registry, as defined in RFC2929.
	The DLV resource record reuses the same algorithm and digest type		DLV makes use of the DLV resource record previously assigned by IANA.
	registries already used for the DS resource record, currently known
	as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
	Numbers" registries.
	11. References		11. References
	[INI19] Weiler, S. Deploying DNSSEC Without a Signed Root.		11.1. Normative References
	Technical Report 1999-19, Information Networking
	Institute, Carnegie Mellon University, April 2004.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and		[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	S. Rose, "DNS Security Introduction and Requirements",		"DNS Security Introduction and Requirements", RFC 4033,
	RFC 4033, March 2005.		March 2005.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and		[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	S. Rose, "Resource Records for the DNS Security		"Resource Records for the DNS Security Extensions", RFC 4034,
	Extensions", RFC 4034, March 2005.		March 2005.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and		[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	S. Rose, "Protocol Modifications for the DNS Security		"Protocol Modifications for the DNS Security Extensions",
	Extensions", RFC 4035, March 2005.		RFC 4035, March 2005.
	[EPSILON] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records		[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	and DNSSEC On-line Signing",		Levels", BCP 14, RFC 2119, March 1997.
	draft-ietf-dnsext-dnssec-online-signing-00 (work in
	progress), May 2005.
	Acknowledgements		[5] Andrews, M. and S. Weiler, "The DNSSEC Lookaside Validation
			(DLV) DNS Resource Record", draft-andrews-dlv-dns-rr-01 (work in
			progress), December 2005.
	David Conrad is to blame for the general idea of off-tree		11.2. Informative References
	publication of trust anchors.
	Paul Vixie, Suzanne Woolf, and Johan Ihren contributed		[6] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and
	significantly to the exploration of possible resolver algorithms		DNSSEC On-line Signing",
	that led to this design. More about those explorations is		draft-ietf-dnsext-dnssec-online-signing-02 (work in progress),
	documented in [INI19].		January 2006.
	Johan Ihren and the editor share the blame for aggressive negative		[7] Laurie, B., "DNSSEC Hash Authenticated Denial of Existence",
	caching.		draft-ietf-dnsext-nsec3-03 (work in progress), October 2005.
			[8] Weiler, S., "Deploying DNSSEC Without a Signed Root", Technical
			Report 1999-19, Information Networking Institute, Carnegie
			Mellon University, April 2004.
			Author's Address
			Samuel Weiler
			SPARTA, Inc.
			7075 Samuel Morse Drive
			Columbia, Maryland 21046
			US
			Email: weiler@tislabs.com
End of changes. 49 change blocks.
	205 lines changed or deleted		205 lines changed or added
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/