Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05

[Ben Campbell <[e-mail]>]

Hi, thanks for the response. I've got some more comments inline, and I removed sections that do not seem to need further comment.

On Jul 3, 2014, at 6:20 AM, <[e-mail]> <[e-mail]> wrote:

[...]

>> Major issues: None
>> 
>> Minor issues:
>> 
>> -- Section 2
>> 
>> I'd like to see more motivation for the creation of ff2. The text says  it
>> "... allows addresses to be treated in a more uniform and generic way, and
>> allows for these bits to be defined in the future for different
>> purposes..."
>> 
>> That seems pretty vague to me. Can you offer specifics on what problem is
>> being solved here, and how you expect this new flags to be used? Most
>> importantly, are there likely to be interoperability issues for things
>> implemented prior to the definition of these?
> 
> [Med] Typical encountered issues are listed in section 3: e.g., some implementations do not treat the flag bits as separate bits, this leads in particular to not consider prefixes starting with fffx as RP-embedded.
> 

I understood those issues to motivate the clarifications on ff1. But if they explain why some of the reserved space is updated to be ff2, then I missed it.


> What is the purpose of
>> redefining them as flags prior to defining the meaning of the flags?
> 
> [Med] In fact we started by associating a meaning with an unreserved bit (http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-05)... but when that draft went to the IETF LC, it was decided that it is better to clarify first the usage of flag bits + define reserved bits as flag bits. The 6man draft is not overloaded with all these details, hence the generic sentence you quoted in your comment.   

It would be good to mention that in the draft as part of the motivation. It doesn't need a lot of detail, but a couple of sentences would make it easier for a reader to understand the reasons for defining ff2.

[...]

>> 
>> -- section 4.1, "old"
>> 
>> It would be nice to include a reference for [ADDRARCH]. I realize it's an
>> artifact of the quoted text, but I think it's still worth a [perhaps
>> informational] reference.
> 
> [Med] [ADDRARCH] is not listed in the reference list because this is a quoted text from RFC3306. BTW, [ADDRARCH] is obsoleted by RFC 4291 which is listed in the reference list. I have no problem to add [ADDRARCH] as an informative reference if you think this is helpful for the reader.
> 

I think it might be helpful, but on further reflection, I think it probably does no real harm to leave it as is. It might be better to simply add a line somewhere nearby to point out that [ADDRARCH] refers to the reference in that RFC, not this document, and that it has been since obsoleted.

>> 
>> -- section 4.2, 2nd "new" proposed text:
>> 
>> " P MUST be set to 1, and consequently T MUST be set to 1 ..."
>> 
>> Is this intended to be for all multicast addresses, or just those with R=1?
> 
> [Med] This context of this text is RFC3956: R=1. The text says explicitly the motivation for such setting ", as this is a special case of unicast-prefix
>   based addresses.". I do think the text is clear.

I understand that is the intent, but I think the text can be read otherwise. The old text unambiguously made the second sentence dependent on the first; the new text does not.

> 
>> The proposed text can be read to mean the former, but the old text seems to
>> mean the latter (due to the word "Then" which is dropped from the new
>> text.)
>> 

[...]

>> -- idNits complains about the lack of a pre-5378 disclaimer boilerplate. I
>> found a discussion in the 6man archives  ( http://www.ietf.org/mail-
>> archive/web/ipv6/current/msg20838.html ) indicating the authors preferred
>> not to contact all possible authors of pre-5378 text. Doesn't that mean the
>> draft should carry the boilerplate?
> 
> [Med] We prefer to leave this point for the RFC Editor.
> 

Do you mean that you prefer to leave the _decision_ to the RFC Editor, or that you recognize the pre-5378 boilerplate is needed, but would like the RFC editor to insert it?

If the former, The RFC editor will not have the background about the pre-5378 text needed to make that call. That's the responsibility of the authors. If there's text from pre-5378 IETF documents included, and the current authors have not verified that all authors of the original text agree to the BCP 78 and 79 terms, then the pre-5378 boilerplate needs to go in. This is important; getting it wrong involves misrepresentation of the license terms. 

If the latter, then the draft needs some directive to the RFC editor to add the boilerplate. (But keep in mind that the pre-5378 boilerplate requirement applies to all contributions. That is, I-Ds as well as RFCs -- so it's important to get this right in the _draft_, not just the final RFC.)  

[...]