Dear Ben,
Thank you for the review.
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Envoyé : mercredi 2 juillet 2014 21:10
À :
draft-ietf-6man-multicast-addr-arch-update(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc : gen-art(_at_)ietf(_dot_)org Team (gen-art(_at_)ietf(_dot_)org);
ietf(_at_)ietf(_dot_)org 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.