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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf