Hi Ben,
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : Ben Campbell [mailto:ben(_at_)nostrum(_dot_)com]
Envoyé : jeudi 3 juillet 2014 21:18
À : BOUCADAIR Mohamed IMT/OLN
Cc :
draft-ietf-6man-multicast-addr-arch-update(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-
art(_at_)ietf(_dot_)org Team (gen-art(_at_)ietf(_dot_)org);
ietf(_at_)ietf(_dot_)org 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, <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.
[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.)
[...]