Re: Review of draft-ietf-6man-rfc4291bis-03

[Tim Chown <[e-mail]>]

Hi Bob,

> On 19 Sep 2016, at 14:11, Bob Hinden <[e-mail]> wrote:
> 
> Hi Tim,
> 
>> On Sep 16, 2016, at 6:24 AM, Tim Chown <[e-mail]> wrote:
>> 
>> Hi Bob,
>> 
>> Many thanks. Just a few responses in-line. Other items pruned for brevity.
> 
> Thanks!
> 
>> 
>>> On 7 Sep 2016, at 21:50, Bob Hinden <[e-mail]> wrote:
>>> 
>>> Hi Tim,
>>> 
>>> Thanks for the review.  Comments below.
>>> 
>>> Bob
>>> 
>>>> On Jul 18, 2016, at 9:23 AM, Tim Chown <[e-mail]> wrote:
>>>> 
>>>> Hi again,
>>>> 
>>>> Ole asked me to review draft-ietf-6man-rfc4291bis-03 as well.
>>>> 
>>>> 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.
>>>> 
>>>> A general question exists as per the other two -bis documents as to whether new material that’s 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’s not clear if it’s been discussed and rejected, or not.
>>> 
>>> See specific answers to these topics below.
>> 
>> 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’s 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’t resolve this consistency issue in the Berlin discussion, but it was noted.
> 
> I used my editorial judgement as to which ones were cited in the text or in the appendix.  In general I didn’t 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’s 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.

>>> 
>>>> 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.
>>> 
>>> No, I don’t 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.
>>> 
>>> Also, ULAs are defined in RFC4193 as having global scope (that is, not “treated" as global scope).
>> 
>> I agree with Brian’s 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).
> 
> Looking back at the deprecating document RFC3879, it says:
> 
>   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].
> 
> 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’s 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.
>>> 
>>> RFC7421 is informational, and while very useful, I don’t think it needs to be cited here.  Nor does it update RFC4291.
>> 
>> Though I’d argue in practice the 64-bit boundary for host subnets is a significant element of the v6 addressing architecture
> 
> OK, I could add a sentence to the end of the forth paragraph in Section 2.4.1
> 
>> 
>>>> p.14 again, should the site-local section be replaced with ULAs?
>>> 
>>> 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.
>> 
>> Maybe Ole needs to nudge the issue tracker entry here to get WG consensus.
> 
> See above.
> 
>> 
>>>> p.16 there is no reference to RFC7371 (multicast address architecture update) or RFC7346 (multicast scopes); should these be added?
>>> 
>>> For RFC73712, see the answer to next issue.
>>> 
>>> 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’t see any harm adding a reference, but not much value either.
>> 
>> As above, it’s not just a matter of relative importance, but I feel t’s 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.
> 
> 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’t see any harm adding another reference here, so I will do that.
> 
>> 
>>>> p.17 a good chunk of this page is copied from RFC7346, without citing it.
>>>> 
>>>> Section 3 (IANA):
>>> 
>>> The purpose of “IANA Considerations” is to tell the IANA to do something.  Since we aren’t asking IANA to do anything, we don’t need to tell them to do something.  I don’t think we need to describe the current state of the IANA registries as they will change over time.
>>> 
>>>> p.21 there is no mention of RFC5453, which created the IANA registry for reserved IPv6 interface identifiers. Should there be?
>>>> 
>>>> p.21  there is no mention of the IANA IPv6 Special-Purpose Address Registry, as per RFC6890. Should there be?
>>>> 
>>>> p.21 should Section 6 of RFC7346 be captured here?
>>> 
>>> 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.
>> 
>> I think your email of yesterday on  helps clear this up, or will at least get us to a good resolution.
> 
> Good.  It will be in the next version.

Great.

Thanks,
Tim

> 
> Thanks,
> Bob
> 
>> 
>> Best wishes,
>> Tim
>> 
>