Subject: Re: review of draft-ietf-node-req-bis

From: RJ Atkinson <[email-masked]>
Date: Thu, 26 May 2011 09:31:40 -0400

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 May 2011 09:24:04 -0700

Ran,

> that experience to magically appear.

I don't have a strong opinion on the specifics of RFC-4429, but I want to point out the having sufficient operational experience isn't the only criteria for including something in node requirements.  It can be something we think everyone should implement.

For example, the recent consensus to change DHCPv6 to a SHOULD, was more about making sure that all hosts implement it given current deployment models.

Bob

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 26 May 2011 15:36:34 -0400

On 26  May 2011, at 12:24 , Bob Hinden wrote:
> I don't have a strong opinion on the specifics of RFC-4429,
> but I want to point out the having sufficient operational
> experience isn't the only criteria for including something
> in node requirements.  

I never said it was the ONLY criterion.
It is a VALID criterion to consider.

In contrast with RFC-4429, there is significant operational 
experience with DHCPv6 (e.g. in some enterprise environments).  
So drawing an analogue with DHCPv6 does not work for RFC-4429.

All IMHO,

Ran