ietf
[Top] [All Lists]

RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

2006-12-04 06:36:25
Thanks for the comments! Sorry for the late reply. Some comments inline 


I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very 
important.
For the sake of new implementors I have a number of suggestions for
clarity.  Many of them have to do with the use of "SHOULD", since we
have been polishing up its use and advice to implementors.

=> I appreciate the effort; as a general comment I should highlight that
the main reason for this work was to fix known bugs in the spec in a
backward compatible manner. Some or all of the changes of SHOULD to MUST
below might not be backward compatible.
As I'm sure you're aware, this spec has been widely implemented on all
major platforms and doing things in a non- backward compatible manner is
essentially prohibited.

Also, in general, having to describe situations where the SHOULD in the
spec can be avoided is a very difficult task and not really helpful
given the wide implementations of the spec. It really comes down to how
big a document you want :) I think given the description of keywords, if
something is strongly recommended but the protocol will not break if
it's not done, then it deserves a SHOULD. We don't need to explain all
or a subset of situations where avoiding that SHOULD makes sense.
Implementers who need to avoid the SHOULD already know why they need
that. Those who don't know, should follow the SHOULD. 


I'll start with my protocol question:

  7.2.7 Anycast neighbor announcements
  
    - "Second, the Override flag in Neighbor Advertisements SHOULD be
      set to 0, so that when multiple advertisements are 
received, the
      first received advertisement is used rather than the most
      recently received advertisement."
  
    How does the Override flag work when you advertise an included
    prefix?  

=> I don't understand the question. The NA can only include a unicast
address. You can't include a prefix in the NA.

       In this case, I'm advertising a single route to you with
    the Override flag off.  What if you already have a route to a
    larger prefix that includes it?  Do I punch a hole?  Am I
    discarded?  Is this documented?

OK, onward to non-protocol issues.  



3.0 protocol overview

  - Duplicate address detection

     "Duplicate Address Detection: How a node determines that an
     address it wishes to use is not already in use by another node."

    should be

     "Duplicate Address Detection: How a node determines whether or
     not an address it wishes to use is already in use by another
     node."

=> ok.

      
  - Router advertisement: the phrase "on-link determination" has not
    appeared before.  It should be explained.

=> We can add a reference here.

    
4.1 router solicitation message

  - Source link-layer address

      "The link-layer address of the sender, if known.  MUST NOT be
      included if the Source Address is the unspecified address.
      Otherwise it SHOULD be included on link layers that have
      addresses."

    We've been tightening up "SHOULD"s recently.  RFC2119 says:
    
      SHOULD   This word, or the adjective "RECOMMENDED", mean that
      there may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a different
      course.
  
    In this draft, "otherwise ...  SHOULD" implies that there are
    situations in which the link layer address is known, and the
    source address is included, but the link layer address may be
    omitted.  RFC2119 says that deserves explanation.  As guidance to
    implementors, who are supposed to understand the full 
implications
    and carefully weigh them, when would this be appropriate?  For
    load balancing?  If so just say so.  For example down below in
    Router Advertisement Message, you say "A router MAY omit this
    option in order to enable inbound load sharing across multiple
    link-layer addresses."  Something like that would work here -- if
    nothing else add a pointer to text elsewhere.  

=> I'd appreciate comments on this from Thomas or Erik if they want to
add something here. Personally, while I appreciate the clarity
requirements, I think it's not necessary to always explain all possible
options for not following a SHOULD. From personal experience, I found
people using specs in ways that were not originally thought of, while
being legitimate (due to the use of MAYs and SHOULDs). So I'm inclined
to leave it as is but would like to hear if others see such ways of
clarification necessary.


    There are more issues with SHOULDs not being thoroughly explained
    below.  I'm only listing the ones where I believe naive
    implementors might benefit from explanation.  

=> Ok, I think there are lots (most of the shoulds) in the draft that
are not explained as you describe above.

4.2 router advertisement

  - "Note: If neither M nor O flags are set this indicates that no
    information is available via DHCPv6."

    This means that the responding router always knows if DHCPv6 is
    definitely available or definitely not available.  Is there any
    possibility that the responding router might not know?  

=> I don't think so. It should always know.

  - "SHOULD be sent on links that have a variable MTU (as 
specified in
    the document that describes how to run IP over the 
particular link
    type).  MAY be sent on other links."

    Same comment on undocumented SHOULD.  How about changing it to
    "MUST be sent ...  (where specified ...)"?

=> I have to give the same answer here. I don't think it's appropriate
to put MUST instead of the SHOULD above. The flexibility provided by the
SHOULD is important given the variety of link layers and *systems* (e.g.
3GPP, WiMAX ...etc) out there that define how IPv6 is used in their
environments. 
For the rest of the "SHOULD" comments I couldn't add or respond to your
comments any differently from my earlier comments. So I suggest we
handle all the "SHOULD" comments together at least initially. As I
mentioned earlier, in general, it's not a good idea to change SHOULDs to
MUSTs anywhere in the draft unless it's an obvious bug. 

6.2.1 router config variables

  - AdvCurHopLimit

      "The value should be set to that current diameter of the
      Intern iset."

    s/that/the/

=> ok.

  - In 7.2.5, "An advertisement's Solicited flag should only 
be set if
    the advertisement is a response to a Neighbor Solicitation."

    However, in 7.2.6, "The Solicited flag MUST be set to zero, in
    order to avoid confusing the Neighbor Unreachability Detection
    algorithm."

    Is there a consistency problem here?

=> None whatsoever, the title of 7.2.6 is "Sending Unsolicited Neighbour
Advertisements", so naturally the Solicited flag must not be set in this
case.

  - "In the Target Address field: the address to which subsequent
    packets for the destination SHOULD be sent."

    That's talking about the recipient of the redirect.  It's not
    about the sender's behavior, so this SHOULD should not be
    capitalized.

=> Hmm. That's true.

Hesham

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf