Subject: Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Jul 2014 14:09:35 -0500

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.

---

From: <[email-masked]>
Date: Thu, 3 Jul 2014 11:20:13 +0000

Dear Ben,

Thank you for the review.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Ben Campbell [mailto:[email-masked]]
>Envoyé : mercredi 2 juillet 2014 21:10
>À : [email-masked]
>Cc : [email-masked] Team ([email-masked]); [email-masked] list
>Objet : Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05
>
>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.

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

>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.)
>
>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
[Med] Fixed. Thanks.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 3 Jul 2014 14:17:42 -0500

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, <[email-masked]> <[email-masked]> wrote:

[...]

> [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 fff…

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] 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…

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] [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…

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.

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

>> mean the latter (due to the word "Then" which is dropped from the new

[...]

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

[...]

---

From: <[email-masked]>
Date: Fri, 4 Jul 2014 13:44:41 +0000

Hi Ben,

Please see inline.

Cheers,
Med

>Envoyé : jeudi 3 juillet 2014 21:18
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [email-masked]; gen-
>[email-masked] Team ([email-masked]); [email-masked] 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.
>
>> [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.

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

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

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

>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.)
>
>[...]

---

From: <[email-masked]>
Date: Mon, 7 Jul 2014 06:40:19 +0000

Hi Ben,

An updated version that takes into account your comments is available online: http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-06 

A diff can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-06.txt 

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]]
>Envoyé : vendredi 4 juillet 2014 15:45
>À : Ben Campbell
>Objet : RE: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-
>arch-update-05
>
>Hi Ben,
>
>Please see inline.
>
>Cheers,
>Med
>
>>>> The proposed text can be read to mean the former, but the old text
>seems
>>to
>>>> -- idNits complains about the lack of a pre-5378 disclaimer
>boilerplate.
>>I
>[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."
>
>>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Jul 2014 16:29:22 -0500

Hi,

Please see inline (I deleted parts that don't appear to need further comment)

On Jul 4, 2014, at 8:44 AM, [email-masked] wrote:
[...]
> [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 i…

I think I'm with you for the "old" text, since that is made up of quoted text and attributed to the RFCs. But I'm a bit confused by the argument that the "new" text is largely the same as the old. That seems to support the idea that this draft derives text from those RFCs, which is exactly the situation the pre-5378 boilerplate is intended to address. 

In any case, I don't think the RFC editor can be expected to resolve the question, and the fact that the RFC editor might not bring up the issue doesn't mean there is no issue. At this point that responsibility seems to lie with the authors and the ADs.

---

From: <[email-masked]>
Date: Tue, 8 Jul 2014 06:14:59 +0000

Hi Ben,

A pre-5378 boilerplate is now present in -07. Please check this diff:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-07.txt 

Thank you for your careful review.

Cheers,
Med

>Envoyé : lundi 7 juillet 2014 23:29
>>>>> not to contact all possible authors of pre-5378 text. Doesn't that
>mean
>>> the
>> [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."
>
>I think I'm with you for the "old" text, since that is made up of quoted
>text and attributed to the RFCs. But I'm a bit confused by the argument
>that the "new" text is largely the same as the old. That seems to support
>the idea that this draft derives text from those RFCs, which is exactly the
>situation the pre-5378 boilerplate is intended to address.
>
>In any case, I don't think the RFC editor can be expected to resolve the
>question, and the fact that the RFC editor might not bring up the issue
>doesn't mean there is no issue. At this point that responsibility seems to
>lie with the authors and the ADs.
>
>>
>>>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Jul 2014 09:11:53 -0500

Version 7 addresses all of my concerns, and is IMO ready for publication.

Thanks!

Ben.