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

[Tim Chown <[e-mail]>]

Hi Bob,

Many thanks. Just a few responses in-line. Other items pruned for brevity.

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

>> 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

>> 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.

>> 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.

>> 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.

Best wishes,
Tim