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

[<[e-mail]>]

Hi Ben,

An updated version that takes into account your comments is available online: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-06 

A diff can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-06.txt 

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]]
>Envoyé : vendredi 4 juillet 2014 15:45
>À : Ben Campbell
>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 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.)
>>
>>[...]