Subject: RE: Review of draft-ietf-ipv6-2461bis-09.txt

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 5 Jan 2007 19:40:56 +1100

Hello again, 

This is a follow up on the comments we discussed earlier. Ralph, please let
me know if you're ok with my suggestions below. The document is waiting on
your response! The rest of your comments are all in the document.  

 >  > > I think this is general advice to people thinking about 
 >  > how ND applies
 >  > > to link layers other than, say, ethernet. Clearly, ND 
 >  > applies to all
 >  > > specs, unless superceded by another spec for a particular link
 >  > > layer. That is all that this section is (IMO) trying to 
 >  > say. I.e., to
 >  > > suggest when another spec might be needed and where not.
 >  > 
 >  > I think I understand the meaning the text is supposed to 
 >  > convey.  But the
 >  > text doesn't seem (to me, anyway) to convey that meaning 
 >  > very well; I note
 >  > your interpretation is qualified with "IMO" and perhaps 
 >  > another reader might
 >  > have a different opinion?
 >  > 
 >  > To be more concrete, it appears that the section is 
 >  > describing how or which
 >  > parts of ND should be implemented on links with certain 
 >  > attributes.  But the
 >  > last several entries don't seem to be very clear or precise. 
 > 
 > => Ok, does anyone object to removing that statement from the spec?
 > The statemement I'm referring to is the one Ralph refers to above:
 > "Neighbor Discovery should be implemented as described in 
 > this document."
 > It seems superfluous anyway. 

=> So here is the text for the section in question: 

  point-to-point - Neighbor Discovery handles such links just like
                   multicast links.  (Multicast can be trivially
                   provided on point-to-point links, and interfaces
                   can be assigned link-local addresses.)  

  multicast      - Neighbor Discovery supports multicast capable 
                   links as described in this document. 

 >  > Yeah, I agree the text means "don't draw any conclusions 
 > about on- or
 >  > off-link is L bit is not set".  What are the ramifications 
 >  > of the L bit not
 >  > being set; what other parts of this or other protocols 
 > are affected?
 > 
 > => If the L bit is not set a host cannot assume that an 
 > address is on-link, therefore it will send all packets to 
 > its Default router, unless a redirect is received for a 
 > particular address. 

=> I've clarified the definition a bit more:

   L              1-bit on-link flag.  When set, indicates that this
                  prefix can be used for on-link determination.  When
                  not set the advertisement makes no statement about
                  on-link or off-link properties of the prefix. In 
                  other words, if the L flag is not set a host MUST 
                  NOT assume that an addresse derived from the prefix 
                  is on-link unless it is explicitly told in another 
                  message (e.g. Redirect). For instance, the prefix 
                  might be used for address configuration with some 
                  of the addresses belonging to the prefix being on-
                  link and others being off-link.

Any objections?
 
 >  > Except for its use in supplying the initial for the 'A' 
 > bit in prefix
 >  > options...
 > 
 > => I agree. So how about we state in the document that the 
 > terms "stateless autoconfiguration" and "autonomous 
 > autoconfiguration" are used interchangeably? People are 
 > familiar with the meaning of the A flag and with the term 
 > "stateless autoconfig", removing either one is probably 
 > going to add more confusion than clarity. It might have to 
 > be one of those imperfections of a doc that developed over a 
 > long time. Is this ok?

=> Is this ok?

Hesham

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Fri, 05 Jan 2007 05:49:17 -0500

Hesham - you're suggested revisions are fine with me.

One typo - in the text for the on-link flag, s/addresse/address/

And, at the risk of being overly picky, after searching through the RFC for
occurrences of "autoconfiguration", it seems there is some inconsistency in
the use of other related terms, like autoconfiguration and address
autoconfiguration (used for both SLAAC and DHCP).

The definition in the terminology section seems OK:

     Address Autoconfiguration: How nodes automatically configure an
                address for an interface.

...referring to both stateless address autoconfiguration and DHCP.

Howvever, at the end of section 2.3:

                 (e.g., while verifying an address is unused
                 during address autoconfiguration [ADDRCONF])

While this is not normative text, I use it as an example.  If, in this case,
"address autoconfiguration" refers to just SLAAC, it should be "stateless
address autoconfiguration".  On the other hand, if "address
autoconfiguration" is correct, then there should be a reference to DHCPv6
(RFC 3315) as well as [ADDRCONF].

As another example, at the end of section 4.2:

      Prefix Information
                     These options specify the prefixes that are on-link
                     and/or are used for address autoconfiguration.

Here, the reference should be to "stateless address autoconfiguration"; the
prefix information is not used by a host using DHCP.

I apologize for noticing this issue at the last minute.  In response to the
question about "stateless autoconfiguration" and "autonomous
autoconfiguration", I wanted to see if there were other phrases using
"autoconfiguration".  That search lead to the discovery of the inconsistent
uses of "autoconfiguration".

- Ralph

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 5 Jan 2007 22:37:19 +1100

> Hesham - you're suggested revisions are fine with me.

=> Ok, thanks!

 > One typo - in the text for the on-link flag, s/addresse/address/

=> Done.

 > prefix information is not used by a host using DHCP.

=> Understood. I'll do a search and change it where it needs to be changed,
I'm assuming the above doesn't cover all places. 

 > uses of "autoconfiguration".

=> No problems, they're all good catches. Thanks for your feedback and quick
response. 
I intend to submit the draft tomorrow.

Hesham

---

From: Ralph Droms <[email-masked]>
Date: Fri, 05 Jan 2007 12:05:37 -0500

Hesham - thanks for all your hard work on the doc...

- Ralph

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Jan 2007 09:59:55 -0800

Hesham,

Regarding the new sentence under the 'L' bit definition:
              
>                   In 
>                   message (e.g. Redirect).

the on-link property of an address need not be due to a
message, e.g., it could be due to manual config. Suggest
rewriting as:

  "In other words, if the L flag is not set a host MUST NOT
   assume that an address derived from the prefix is on-link
   unless it is explicitly told through some other means
   (e.g. Redirect)."

Fred
[email-masked]

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 6 Jan 2007 11:43:20 +1100

Fred, 

Ok, thanks, I've made the change. 

Hesham 

 > -----Original Message-----
 > From: Templin, Fred L [mailto:[email-masked]] 
 > Sent: Saturday, January 06, 2007 5:00 AM
 > To: Hesham Soliman; Ralph Droms; Thomas Narten
 > Cc: [email-masked]; Brian Haberman; Erik Nordmark; Bob 
 > Hinden; William Allen Simpson
 > Subject: RE: Review of draft-ietf-ipv6-2461bis-09.txt 
 > 
 > Hesham,
 >

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 10 Jan 2007 10:08:55 -0500

Thank you for informing me of the re-write.  A few obvious editorial
corrections:

    EMail: [email-masked]
           [email-masked]

The former machine hasn't existed since circa 1994, and the latter since
circa 1998.  Easy Googling has given reviewers one of my half dozen
active emails (and notified me of this draft).  I've recently retired
[email-masked] that was on most recent RFCs, as that company
concluded bankruptcy some time ago.

Please replace with my more current email above!  (Hopefully, Gmail will
be useful for the next Internet Lifetime.)

The Introduction has a list of acknowledgments for reviewers.  They
aren't really introductory.  In the past, I've always included them in a
separate ACKNOWLEDGMENTS section, following more usual academic practice.
That also permits more explicit indication of which individuals proposed
which (mis-)features.

Please replace the rampant misuse of "e.g." and "i.e." with the more
appropriate "for example," "such as," "that is," "specifically," or in
many parentheticals simply eliminate it entirely!

Also, it would be better to follow the RFC writing practices that I've
developed for such things as describing state machines, later cited as
exemplary in the Guide for Internet Standards Writers (RFC 2360).  I'd
hoped that a draft derived from my earlier work would continue the clean
style and form, even as it deviates from the substance.

And speaking of substance, I'm not convinced this draft is ready for
prime time.  Far too much continues to be relegated to "further study".
For example, multi-homed hosts are fairly common in operational practice,
and my original 1992-1993 work included them.

After 15 years, greater experience ought to clarify, rather than muddy
the waters.  This should never have made it to Draft Standard.

Moreover, as I've stated before, I'm deeply disappointed that the substance
has departed from my original vision: virtually no configuration for hosts
or routers, other than identifiers and secrets necessary for security.
Although there have been modest improvements in this recent draft, the
elimination of explicit security support has retreated ever farther from
the goal.

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 10 Jan 2007 10:08:55 -0500