Re: [renum] Working Group Last Call: draft-ietf-6renum-enterprise-02.txt

[RJ Atkinson <[e-mail]>]

  I am not a member of the Renum mailing list, but I have
a few comments on this draft.

General:
	It would be helpful to use "might" when one means
	"possibility" and only use "may" when one means
	"permission".  In several places the meaning is
	a bit unclear, because "may" gets used in different
	ways in different parts of the document.  A
	little editing would help readability.


Section 4.1, "Usage of FQDN", 2nd paragraph:
	Please cite the mDNS and DNS-SD specifications,
	which are in the RFC Editor's publication queue,
        and add them to the REFERENCES section.


Section 4.2, page 10, "Reduce the DNS configuration lifetime":
	The section should note that it is practical and reasonable 
	for A, AAAA, and PTR records to be configured with very 
	short DNS TTL values (e.g. 0 seconds, 1 second), not
	only during renumbering events, but also for longer-term
	operation.

	Recent experimental work done at U. St Andrews [BA2011] 
        has verified much earlier trace-driven simulation 
        research done at MIT which noted that DNS caching is
	not really very effective. [JSBM2002]

        [BA2011] S. Bhatti, R. Atkinson, "Reducing DNS Caching", 
        Proc. 14th IEEE Global Internet Symposium (GI2011), 
        Shanghai, China. 15 April 2011.
        
	[JSBM2002] J. Jung, E. Sit, H. Balakrishnan, & R. Morris,
        "DNS Performance and the Effectiveness of Caching", 
        IEEE/ACM Trans. Netw., 10(5):589–603, 2002.


Section 4.3, page 12, "DNS record update and DNS configuration":
	See previous comment above about running DNS
	with very short TTLs.


Section 4.3, page 12, "Tunnel concentrator renumbering":

	It is NOT correct that IPsec necessarily will fail
	when a tunnel concentrator is renumbered.  As noted
	in RFC-5887, Section 5.2, IPsec works fine and adapts 
        to renumbering provided that any non IP-address name 
        is used for identity in one's IPsec key management system
	(e.g. with IKEv1, IKEv2; conceptually also Kerberos).
	RFC-4306, Section 3.5 lists several non-IP-address
	name types (ID_FQDN, ID_RFC822_ADDR, ID_DER_ASN1_DN,
	ID_DER_ASN1_GN, ID_KEY_ID), each of which would be
	sufficient to provide IPsec resilience in the event
	of an IP address renumbering event.  A similar set
	of non-IP-address identities was earlier defined
	for IKEv1, so this is NOT something new with IKEv2.

	Separately, RFC-2230 defines the KX record, which
	could be used to help locate the domain-name for
	a IPsec VPN concentrator associated with a site's
	domain name.

        
Thanks,

Ran