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, <mohamed(_dot_)boucadair(_at_)orange(_dot_)com>
<mohamed(_dot_)boucadair(_at_)orange(_dot_)com> 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.
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.
[...]
-- 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.
-- 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.
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?
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.)
[...]