From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Bob Hinden <bob.hinden@gmail.com>
Subject: Re: Review of draft-ietf-6man-rfc4291bis-03
Thread-Topic: Review of draft-ietf-6man-rfc4291bis-03
Thread-Index: AQHR4RC/gIxoqSEV1kin6MBX2xegsaBu0O6AgA2pZwCABLJYgIAAGvuA
Date: Mon, 19 Sep 2016 14:44:42 +0000
Message-ID: <8D24FBE1-A40B-4883-9E7E-F441E864CBCC@jisc.ac.uk>
References: <563E68A2-582C-46E3-BFEF-42C0FD746101@jisc.ac.uk>
 <37149AAE-B306-4EE0-9E0F-3BE1365C11AC@gmail.com>
 <7A80169F-43F5-4B40-84DC-65EFFB13852D@jisc.ac.uk>
 <70B52FF2-2EC2-4E98-88FD-692B8146D4A2@gmail.com>
In-Reply-To: <70B52FF2-2EC2-4E98-88FD-692B8146D4A2@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:a88:d510:1101:58e3:61f8:a49:b8b9]
x-ms-office365-filtering-correlation-id: 37b1da79-53d0-40c5-830c-08d3e09b7e0d
x-microsoft-exchange-diagnostics: 1; DBXPR07MB461;
 20:4GjUAhJsFpCWxrRKo41hInRCfJvUf9GO582q3LatV/4k4qNEUGUz/W42lfHBox/hrw5ZLTjWOU6yQBCwPs02rF3yMxwcPjxdtloXYW+ZcAfzqOTDZsvia+iIySCgqHdlVJ//lO2CbT111JjDZhLCJHZTVA8ZkQIkAWtJRbTrGuQ=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB461;
x-microsoft-antispam-prvs: <DBXPR07MB461BB093B569F90C48E3BC8D6F40@DBXPR07MB461.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(274715658323672)(278428928389397)(100405760836317); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
 RULEID:(102415321)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);
 SRVR:DBXPR07MB461; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB461; 
x-forefront-prvs: 0070A8666B
x-forefront-antispam-report: SFV:NSPM;
 SFS:(10009020)(6009001)(7916002)(199003)(66654002)(51914003)(24454002)(51444003)(377454003)(189002)(54534003)(19580395003)(19580405001)(93886004)(74482002)(7736002)(4326007)(230783001)(36756003)(8676002)(82746002)(87936001)(99936001)(110136003)(6116002)(102836003)(105586002)(106356001)(106116001)(586003)(50986999)(7846002)(101416001)(83716003)(305945005)(76176999)(81166006)(81156014)(2950100001)(33656002)(5660300001)(77096005)(10400500002)(86362001)(2900100001)(68736007)(122556002)(2906002)(57306001)(3660700001)(8936002)(50226002)(5002640100001)(97736004)(3280700002)(92566002)(189998001)(3826002)(104396002);
 DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB461;
 H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;
 A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: jisc.ac.uk does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed;
 boundary="Apple-Mail=_F3E3B5D7-377D-4517-AFC3-7C027DB97FFD";
 protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2016 14:44:42.7318 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB461
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-4oS_GavaftetqVZGI882cmC85o>
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>,
 <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
 <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2016 14:44:56 -0000

--Apple-Mail=_F3E3B5D7-377D-4517-AFC3-7C027DB97FFD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Bob,

> On 19 Sep 2016, at 14:11, Bob Hinden <bob.hinden@gmail.com> wrote:
>=20
> Hi Tim,
>=20
>> On Sep 16, 2016, at 6:24 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>>=20
>> Hi Bob,
>>=20
>> Many thanks. Just a few responses in-line. Other items pruned for =
brevity.
>=20
> Thanks!
>=20
>>=20
>>> On 7 Sep 2016, at 21:50, Bob Hinden <bob.hinden@gmail.com> wrote:
>>>=20
>>> Hi Tim,
>>>=20
>>> Thanks for the review.  Comments below.
>>>=20
>>> Bob
>>>=20
>>>> On Jul 18, 2016, at 9:23 AM, Tim Chown <Tim.Chown@jisc.ac.uk> =
wrote:
>>>>=20
>>>> Hi again,
>>>>=20
>>>> Ole asked me to review draft-ietf-6man-rfc4291bis-03 as well.
>>>>=20
>>>> This document also appears to be close to being ready. It seems to =
meet the criteria of RFC6410 as a candidate for advancement to IS.
>>>>=20
>>>> A general question exists as per the other two -bis documents as to =
whether new material that=E2=80=99s incorporated should include =
references for the RFCs the updates draw from. Again, that seems a =
little inconsistent in this document. Two other general questions are =
whether ULAs should be explicitly called out here (as a replacement for =
site-locals), and whether we should add IANA registry pointers in the =
IANA section (no action for IANA, but a reader will then know which =
registries are in use).  There is no mention of ULAs in the change log, =
so it=E2=80=99s not clear if it=E2=80=99s been discussed and rejected, =
or not.
>>>=20
>>> See specific answers to these topics below.
>>=20
>> It was also inconsistent in 2460-bis as to whether something was =
cited in the main body, or just referred to in note form in the =
Appendix. And there=E2=80=99s quite a few RFCs mentioned in Appendix B =
of 4291-bis not cited in the main body, but also quite a few that are. =
We didn=E2=80=99t resolve this consistency issue in the Berlin =
discussion, but it was noted.
>=20
> I used my editorial judgement as to which ones were cited in the text =
or in the appendix.  In general I didn=E2=80=99t cite in the text it if =
the change was fully incorporated, and did cite it if there were more =
considerations.  The history of how we got to rfc4291bis is best left =
for the Appendix.

Well, it=E2=80=99s not so much a history, just ensuring we give the =
reader pointers to references for further reading. If there is nothing =
further to read, then I agree with you. Whatever we do, having the =
Appendix as a change log is valuable.

> I am starting to think when the bis documents (rfc2460bis, rfc4291bis, =
rfc1981bis) are further along in the process, these sections might be =
better rewritten as just a summary of the changes instead of the per =
draft changes.  A thought for later.

Something to consider when all documents are otherwise ready, perhaps. =
But I think I agree.

>>>=20
>>>> p.9 and p.10 - is there a requirement to add a reference to RFC4193 =
for ULAs here? They are defined at Global scope, but have a specific =
binary prefix that could be added to the table on p.9. While treated in =
principle by applications as Global scope addresses, their handling/use =
can differ, e.g. through RFC6724-based address selection.  That said, I =
note that RFC4193 does not say it formally updates RFC4192.
>>>=20
>>> No, I don=E2=80=99t think there is a requirement.  Much earlier =
version of this document (e.g., RFC2373) had specific entries in this =
table, but the working group decided to remove them.  The authoritative =
place to see all defined prefixes is to look is the IANA registry, not =
this document.  This section points to the IANA registries where =
specific prefix types are defined.  There are, of course, other formats =
in the IANA registries that are not in RFC2460 or the bis document =
either.
>>>=20
>>> Also, ULAs are defined in RFC4193 as having global scope (that is, =
not =E2=80=9Ctreated" as global scope).
>>=20
>> I agree with Brian=E2=80=99s follow-up on this. There were two =
questions in Berlin - one was removal of mention of site-local (which =
was agreed), the other was whether to specifically add reference to ULAs =
(for which I think Ole added an issue tracker entry).
>=20
> Looking back at the deprecating document RFC3879, it says:
>=20
>   The references to site local addresses should be removed as soon as
>   practical from the revision of the Default Address Selection for
>   Internet Protocol version 6 [RFC3484], the revision of the Basic
>   Socket Interface Extensions for IPv6 [RFC3493], and from the =
revision
>   of the Internet Protocol Version 6 (IPv6) Addressing Architecture
>   [RFC3513].
>=20
> I think that would justify removing it from rfc4291bis.  I am thinking =
of leaving the section, have it say it is deprecated (combine first and =
third paragraph), remove the format diagram, and keep the new ULA =
paragraph (from -04).

I would suggest complete removal. The prior inclusion of site-locals =
should be mentioned in the Appendix change log. There was, from memory, =
no strong consensus either way on inclusion of ULAs when this was raised =
in Berlin. I can see arguments either way, but I would generally agree =
with Brian Carpenter=E2=80=99s view.

>>>> p.11 pragmatically, should there be a mention of RFC7421 (Why /64?) =
at the end of Section 2.4?  Because assumptions *are* now made about the =
64-bit boundary 10 years on from the original publication of 4291.
>>>=20
>>> RFC7421 is informational, and while very useful, I don=E2=80=99t =
think it needs to be cited here.  Nor does it update RFC4291.
>>=20
>> Though I=E2=80=99d argue in practice the 64-bit boundary for host =
subnets is a significant element of the v6 addressing architecture
>=20
> OK, I could add a sentence to the end of the forth paragraph in =
Section 2.4.1
>=20
>>=20
>>>> p.14 again, should the site-local section be replaced with ULAs?
>>>=20
>>> Not replaced given how we deprecated site-local, but I think adding =
few sentences pointing to the ULA spec would make sense.  This would be =
an informational reference.
>>=20
>> Maybe Ole needs to nudge the issue tracker entry here to get WG =
consensus.
>=20
> See above.
>=20
>>=20
>>>> p.16 there is no reference to RFC7371 (multicast address =
architecture update) or RFC7346 (multicast scopes); should these be =
added?
>>>=20
>>> For RFC73712, see the answer to next issue.
>>>=20
>>> For RFC7346, the changes were incorporated (and noted in Appendix =
B).  RFC7346 was very clear on the change it wanted in RFC4291bis.  =
RFC7346 also updates RFC4007, that is included as a reference.    I =
don=E2=80=99t see any harm adding a reference, but not much value =
either.
>>=20
>> As above, it=E2=80=99s not just a matter of relative importance, but =
I feel t=E2=80=99s good to be consistent. Some readers may not note =
Appendix B and expect to read the main body standalone, and the citation =
would help them.
>=20
> Seem to me that an implementor who wants to implement multicast, will =
need to read all of the multicast specifications, but as I said I =
don=E2=80=99t see any harm adding another reference here, so I will do =
that.
>=20
>>=20
>>>> p.17 a good chunk of this page is copied from RFC7346, without =
citing it.
>>>>=20
>>>> Section 3 (IANA):
>>>=20
>>> The purpose of =E2=80=9CIANA Considerations=E2=80=9D is to tell the =
IANA to do something.  Since we aren=E2=80=99t asking IANA to do =
anything, we don=E2=80=99t need to tell them to do something.  I don=E2=80=
=99t think we need to describe the current state of the IANA registries =
as they will change over time.
>>>=20
>>>> p.21 there is no mention of RFC5453, which created the IANA =
registry for reserved IPv6 interface identifiers. Should there be?
>>>>=20
>>>> p.21  there is no mention of the IANA IPv6 Special-Purpose Address =
Registry, as per RFC6890. Should there be?
>>>>=20
>>>> p.21 should Section 6 of RFC7346 be captured here?
>>>=20
>>> I went back and looked at the current IANA considerations in the =
draft, and it is left over from RFC4291.  It should be removed for the =
reasons I cite above.
>>=20
>> I think your email of yesterday on  helps clear this up, or will at =
least get us to a good resolution.
>=20
> Good.  It will be in the next version.

Great.

Thanks,
Tim

>=20
> Thanks,
> Bob
>=20
>>=20
>> Best wishes,
>> Tim
>>=20
>=20


--Apple-Mail=_F3E3B5D7-377D-4517-AFC3-7C027DB97FFD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJX3/rJAAoJELg9LkJo0sOWIFcP/Aj1hpdwVTPgteOtenkJqjt9
Xfr980j1M1XKM9c6YkbPMBbvm6Cbjdge/rMXb4a5ypxsAl5wwAUZtJeONXVGV0DF
5BWCkfFsEiy/6Ma88Qg2cBLxCshFj6VPVlPAuPRc7IyvlDd7milcKwpnmAF9t9zF
nO3RiZsdInMwhSVJoceQdUMc45YnAMYnMa9DRYp9OdEe0pSbTzXjZ+UyUFsJZs/U
/IKLRwIdtDGmV2SdWSs4c465Rsu84Bos3BkSuMj5KAZfbxMbITojgZi2zx8tG+rb
BHsm9ym3Y8y0s1X5gRn+18RkaOfb3AezNMiK/A5DsQV7zIvNNhw7jQj5UTOMF6D6
BYZzcsKlBu0DfIJdljr+RtL9O0O6dmG6R0IRFOVndnWP31Ucqebu+0ufWZtfoBQi
jXdiKjuMneH/31TGHR2QSgYTNYtcmkeNuE4KQOCOQgJo0YAuSmXcS6HjYHg20QUi
/6QrdcIcyHejK4uSM4RTD4cBL822gH4WpwC0FDLJ0AG6VC+v0i58l0s+J5yZsXvn
7cUsyQZP7EHEuyc1/HMH1kje0GUDA0HtUvci9nv2GnSo4K47FXGuHdSxgGpwzeYf
YPiJ5hIIdluqOu8YdS3T5oBh5nI969ZJ0IJDlWLSvNg38L5+djOxudl0B1+Pgpts
emC9sDuTBqdZ++bttvNF
=jqze
-----END PGP SIGNATURE-----

--Apple-Mail=_F3E3B5D7-377D-4517-AFC3-7C027DB97FFD--