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

[Scott W Brim <swb at employees.org>]

I am the assigned Gen-ART reviewer for draft-ietf-ipv6-2461bis-09.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.  Please
resolve these comments along with any other Last Call comments you may
receive.

Summary statement: This draft is basically ready for publication, but
has nits that should be fixed before publication.

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'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?  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."
      
  - Router advertisement: the phrase "on-link determination" has not
    appeared before.  It should be explained.
    
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.  

    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.  

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?  If so, how
    about changing the text to "is known to be available"?

  - "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 ...)"?

4.3 neighbor solicitation

  - "Source link-layer address

      The link-layer address for the sender.  MUST NOT be included
      when the source IP address is the unspecified address.
      Otherwise, on link layers that have addresses this option MUST
      be included in multicast solicitations and SHOULD be included in
      unicast solicitations."

  Same thing about SHOULD.  If it SHOULD be included, under what
  conditions is it expected that it would not be?

4.4 Neighbor advertisement

  - Override Flag: "It SHOULD NOT be set in solicited advertisements
    for anycast addresses and in solicited proxy advertisements.  It
    SHOULD be set in other solicited advertisements and in unsolicited
    advertisements.

    SHOULD and SHOULD NOT without explanation.  Should these be MUSTs?

  - Target link-layer address: "When responding to a unicast Neighbor
    Solicitation this option SHOULD be included."

    SHOULD.  When would you not?

4.5 Redirect  

  - "It SHOULD be included (if known).

    SHOULD.  When would you not?

6.2.1 router config variables

  - AdvCurHopLimit

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

    s/that/the/

6.2.6 processing router solicitations

  - "If the router already has a Neighbor Cache entry for the
    solicitation's sender, the solicitation contains a Source
    Link-Layer Address option, and the received link-layer address
    differs from that already in the cache, the link-layer address
    SHOULD be updated in the appropriate Neighbor Cache entry, and its
    reachability state MUST also be set to STALE."

    Unelaborated SHOULD?

6.3.4 processing received router advertisements

  - In a paragraph that begins "After extracting information" ...

    "If the advertisement contains a Source Link-Layer Address option
    the link-layer address SHOULD be recorded in the Neighbor Cache
    entry for the router ..."

    This seems to be another unexplained SHOULD.

Setting the solicited flag ...

  - 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 From ietf-bounces at ietf.org Thu Nov 09 13:06:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiECa-00066S-JV; Thu, 09 Nov 2006 13:00:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg7WQ-0004ii-Dx
	for ietf at ietf.org; Fri, 03 Nov 2006 17:28:22 -0500
Received: from mail7.exchange.microsoft.com ([131.107.1.27]
	helo=mail.exchange.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg7H1-0006zE-Kv
	for ietf at ietf.org; Fri, 03 Nov 2006 17:12:28 -0500
Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by
	DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft
	SMTP Server (TLS) id 8.0.685.10; Fri, 3 Nov 2006 14:12:27 -0800
Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by
	df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi;
	Fri, 3 Nov 2006 14:12:26 -0800
From: Rajesh Ramanathan <rajeshra at exchange.microsoft.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Date: Fri, 3 Nov 2006 14:11:29 -0800
Thread-Topic: Comments on new sipping drafts?
Thread-Index: Acb/lQNr1DxC5gPCSyWFolR8TRJqjw==
Message-ID: <DC3E2D9FA4974341A4EAF3540781DFDB53DEA0D246 at DF-GRTDANE-MSG.exchange.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
X-Mailman-Approved-At: Thu, 09 Nov 2006 13:00:24 -0500
Subject: Comments on new sipping drafts?
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

Hi all,

I haven't seen any comments on the following two drafts that were submitted=
 some time ago.

http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-605-00.txt
http://tools.ietf.org/wg/sipping/draft-rajesh-sipping-303-00.txt

Anyone have comments/feedback on this?

Thanks
Rajesh Ramanathan
Microsoft Corporation

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf