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

[<[e-mail]>]

Hi Ben,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Ben Campbell [mailto:[e-mail]]
>Envoyé : jeudi 3 juillet 2014 21:18
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [e-mail]; gen-
>[e-mail] Team ([e-mail]); [e-mail] list
>Objet : Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-
>arch-update-05
>
>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.
>
>
[Med] see below.


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

[Med] Ok, will add some text. This text will also address the previous comment. 

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

[Med] OK, added a note as suggested.

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

[Med] I added "Then" to the new text.

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

[Med] We don't think a disclaimer is needed because we quote old text + the new one is largely the same. If the RFC editor re-raises the point, we will clarify our position and then discuss. This is what I meant by " leave this point for the RFC Editor." 

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