Re: New Version Notification for draft-farmer-6man-routing-64-02.txt

神明達哉 <jinmei@wide.ad.jp> Fri, 11 January 2019 19:56 UTC

MIME-Version: 1.0
References: <154681065615.17040.11409819739117044092.idtracker@ietfa.amsl.com> <CAN-Dau2mAKLjun0UEjFbnGr0tCFk1oyh2EhDrHAfarRwQD=Ckw@mail.gmail.com>
In-Reply-To: <CAN-Dau2mAKLjun0UEjFbnGr0tCFk1oyh2EhDrHAfarRwQD=Ckw@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Fri, 11 Jan 2019 11:56:32 -0800
Message-ID: <CAJE_bqcC5KnTkF6heaE6siwFLMR_FZv9mHfYw4hUU4ZnMT-qvA@mail.gmail.com>
Subject: Re: New Version Notification for draft-farmer-6man-routing-64-02.txt
To: David Farmer <farmer@umn.edu>
Cc: IPv6 IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000039b8ea057f341823"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-cFEZXZUe4WHjJYiM2-bycXysIM>
Precedence: list

At Tue, 8 Jan 2019 03:03:40 -0600,
David Farmer <farmer@umn.edu> wrote:

> The following are the changes in this version;
>
>    *Fixed typos, formatting and other editorial changes
>    *Further refined the argument for standard form of interface
identifiers.
>    *Added quote of RFC4291, Section 2.5, paragraph 1 in Section 2.2, CIDR,
> etc...
>    *Further developed the conclusion, providing an argument why
> a requirement is the incorrect relationship.
>
> Please take a look and provide any comments

I've read draft-farmer-6man-routing-64-02.  My high level question is:
what's the goal of this draft?  Is this an attempt of moving the
controversial part of rfc4291bis to a separate document so we can
promote rfc4291bis to IS?  Is it just for providing some guidance
based on the currently available standard (i.e. RFC4291)?  Or
something else?  Depending on its goal my subsequent feedback can
differ substantially, so basically I'll stop here.

One comment for now: I don't think it accurately describes the
relationship between SLAAC (RFC4862) and the "64-bit boundary".  The
draft generally reads as if RFC4862 assumes 64-bit IIDs.  For example,
Section 1 states:

   [...]  Autonomous address-configuration and most other aspects of
   the IPv6 specifications assume or depend on these standard forms.

On the contrary, RFC4862 intentionally avoids assuming a particular
length of IIDs.  Perhaps you (the author) didn't misunderstand this
point and tried to convey the point by using "or depend on", but I
think it's still quite misleading.  It's true that all currently
standardized IIDs used for SLAAC are 64 bits, but I don't think it
catches the subtlety if we just say "RFC4862 depends on 64-bit IIDs"
and is quite likely to give the reader the false impression that SLAAC
assumes 64-bit IIDs.  There are several other places in the doc that
have IMO the same kind of confusion.  Since it's quite subtle we need
very careful wording (if we decide to work on this doc as a WG I'm
willing to suggest text).

--
JINMEI, Tatuya

Fwd: New Version Notification for draft-farmer-6m… David Farmer
Re: New Version Notification for draft-farmer-6ma… 神明達哉
Re: New Version Notification for draft-farmer-6ma… David Farmer