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

[Sheng Jiang <[e-mail]>]

Hi, Ran,

Thanks for your comments. They are helpful and will be integrated in next version among with other comments received during WGLC.

Best regards,

Sheng

>  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
>
>
>
>_______________________________________________
>renum mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/renum