Brian, I did not see any comments on this, but in general I agree with your points below.
Comments in-line -----Original Message----- > I would be happy to see this published as-is, but I did notice > a few points. > > I think the Introduction needs a general warning something like: > > This document reflects the state of IPv6 standards at a particular > moment. Subsequent standards work and operational experience may > require changes to the recommendations in this document. This makes sense. > Also in the Introduction: > > > As it is not always possible for an implementer to know the exact > > usage of IPv6 in a node, an overriding requirement for IPv6 nodes is > > that they should adhere to Jon Postel's Robustness Principle: > > > > Be conservative in what you do, be liberal in what you accept from > > others [RFC0793]. > > Note that this is also present in RFC 1958, by which time > Jon had reformulated it slightly as: > > > Be strict when sending and tolerant when receiving. I always thought the 793 text was a bit more poetic, but I think either is fine. > In 4. Sub-IP Layer > > > In addition to traditional physical link-layers, it is also possible > > to tunnel IPv6 over other protocols. Examples include: > > Should we mention that basic v6/v4 tunnels are specified in [RFC4213]? > > And the examples > > > - Teredo: Tunneling IPv6 over UDP through Network Address > > Translations (NATs) [RFC4380] > > - Transmission of IPv6 over IPv4 Domains without Explicit Tunnels > > [RFC2529] > > may not be so well chosen. Teredo is not loved by operators, and > RFC 2529 is essentially unused today. Maybe 6rd (RFC 5969)and > hub-and-spoke (RFC 5571) would be better examples. Including 4213 makes sense, and I don't oppose dropping 2529. Terado support is a judgement call, IMO. > Two topics are not mentioned. > > 1. The flow label and RFC 3697. I think that is probably wise until > we produce 3697bis. I agree. > 2. DNSSEC. I don't recall whether we discussed that. If we did, > I'm sorry to raise it again. However, I suspect we will get pushback > in security review if it is not mentioned. Do we (6man) have any opinion here? > Nit: there should be a Replaces: 4294 header. Agree. John -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
