On 25th May 2011, at 14:33:47 -0400, Thomas Narten wrote in part: > I personally think the IETF has gotten too formal wanting > the word MAY when it ends up being stilted English.
I agree with the above -- and I believe that this is a pretty widespread perspective among IETF participants. RFC-2119 is helpful, but some folks take an overly strict line that those are the only phrasings that one can use and often it impedes readability for discussions or topics that either aren't normative or don't need to be expressed in formal language (e.g. an aside that some item is optional). > % For general purpose devices, RFC 4429 is not > % considered to be necessary at this time. > > Earlier, on 25th May 2011, at 21:22:35 +05:00, Jari Arkko wrote in part: > > Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more > > the norm than exception today. At the very least, I'd again use the > > MAY keyword for this specification. The above sounds almost like > > recommending to not implement it. > > Just how much time does 4429 shave of the restarting of a device? not > much I think. Couple of seconds? In reality, devices that are > sleeping/waking take more than that to restore their state ... > > Also, just who has implemented 4429? > Do we actually have real experience with it? All good questions. I agree that there is not sufficient operational experience with RFC-4429 to justify changing the text in this draft. If at some future point sufficient operational experience is demonstrated, then that experience might justify a change. However, we ought not hold up this draft while waiting for that experience to magically appear. > > (And based on my own experience of running non-IPv4 networks > > that desperately need DNS discovery, somewhere in Section 7 > > I think you should require that routers with attached hosts > > actually support both (stateless) DHCP and RA-based DNS discovery.) > > The trouble with routers being required to implement stateless > is that they don't need to. You can have one DHC server for an > entire site, with relay agents relaying packets to it... (I'm not sure what precisely was meant by "non-IPv4" above, perhaps that meant to read "non-IPv6" or perhaps it meant IPX ?) Anyway, I am personally very sympathetic to the observation that DNS Discovery is operationally important. My operational experience (from back when I led an access engineering group at a multi-continent broadband residential ISP) was that nearly all of our customers were unable to distinguish between "link down", "network down", and "DNS server misconfigured or down". In all 3 scenarios, they'd call Customer Service to open a trouble ticket and would tell the CSR "Internet is completely down". That said, Thomas has done a careful job of walking the tightrope between differing views within the WG about what ought or ought not be mandated in this draft. I suspect that changing the existing text in this area, as Jari proposes, might well decrease the consensus within the IPv6 WG. So I can't see making that change in this document at this time, despite my personal sympathy for the idea. Instead, perhaps there is a compelling case that it would be useful to have a separate informational document that describes the practical operational issues with DNS Discovery, including user perspective, operator perspective, and security perspective (e.g. authorisation to advertise DNS services, authentication of that advertisement). (One imagines such a draft might belong in the IPv6 Ops WG, as it would be about operational issues. :-) Yours, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
