Last Call Review of draft-ietf-6man-multicast-addr-arch-update-05
review-ietf-6man-multicast-addr-arch-update-05-genart-lc-campbell-2014-07-02-00

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? What is the purpose of redefining them as flags prior
to defining the meaning of the flags?

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

-- section 3:

Please expand SSM on first use.

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

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

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

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