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

[<[e-mail]>]

Dear Ben,

Thank you for the review.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Ben Campbell [mailto:[e-mail]]
>Envoyé : mercredi 2 juillet 2014 21:10
>À : [e-mail]
>Cc : [e-mail] Team ([e-mail]); [e-mail] list
>Objet : Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05
>
>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
>
><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>Please resolve these comments along with any other Last Call comments
>you may receive.
>
>Document:  draft-ietf-6man-multicast-addr-arch-update-05
>Reviewer: Ben Campbell
>Review Date: 2014-07-02
>IETF LC End Date: 2014-07-02
>
>Summary: This draft is almost ready for publication as a proposed standard.
>I have a few comments that I think should be considered prior to
>publication.
>
>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.

 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.   

>
>
>Nits/editorial comments:
>
>-- general:
>
>I found it visually difficult to tell when proposed update text ends, and
>additional text of _this_ document continues. Some way of visually
>separating those would be helpful. For example, in the first "new" section
>of 4.1, there's no visual distinction between between "Flag bits denote
>both ff1 and ff2" and "This document changes..."

[Med] Fixed with dedicated sub-sections for each change.

>
>-- section 3:
>
>Please expand SSM on first use.

[Med] Fixed. 

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

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

>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.)
>
>" This implies that for instance prefixes ff70::/12 and fff0::/12 are
>embedded RP prefixes."
>
>I assume you mean "...,for instance, prefixes..." (with commas). Otherwise
>I found myself wondering what was meant by an "instance prefix".

[Med] Fixed. Thanks.

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

>
>-- section 6: " Security considerations discussed in [RFC3956], [RFC3306]
>and [RFC4291] MUST be taken into account."
>
>That's kind of an odd application of 2119 language. What does the MUST
>apply to? I assume it doesn't apply to implementations. I suggest
>restating the sentence in active voice and/or removing the 2119 language.
>
[Med] Fixed. Thanks.