Re: [Gen-art] [Last-Call] Genart last call review of draft-gellens-lost-validation-05

[Ben Campbell]

(doffs shepherd hat)

I agree with Pete. There’s more to a protocol than the on-the-wire bits. 
Anything important for interop to work should be considered part of the 
protocol. Discovery is an important part of that. Changing discovery to spread 
functions across different servers is a change to the protocol.

Pete’s suggested fixes seem reasonable to me and relatively painless.

Ben.

> On Mar 8, 2020, at 2:59 PM, Pete Resnick  wrote:
> 
> Hi Randy,
> 
> Section 3 of the document defines the operations that one must perform in 
> order to use the tag. It explains how to go beyond what 5222 provides by 
> defining which order to look up the servers and what to do depending on the 
> results received. It changes the discovery procedure defined in 5222. The 
> fact that it is backwards compatible and doesn't break 5222 implementations 
> is good, but it doesn't make it any less a protocol. Indeed, if it is an 
> "optimization" of an existing protocol, that makes it a protocol. I can't see 
> any other way of describing section 3.
> 
> pr
> 
> On 8 Mar 2020, at 14:27, Randall Gellens wrote:
> 
>> Hi Pete,
>> 
>> I don't see this as a new protocol.  It is a new service tag that is 
>> optional to use.  Not using it won't break anything that wouldn't be broken 
>> without the tag being defined.  Using it is an optimization.  I see the 
>> draft as only adding a new tag, not defining a new protocol.
>> 
>> --Randall
>> 
>> On 7 Mar 2020, at 8:52, Pete Resnick via Datatracker wrote:
>> 
>>> Reviewer: Pete Resnick
>>> Review result: Not Ready
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> 
>>> .
>>> 
>>> Document: draft-gellens-lost-validation-05
>>> Reviewer: Pete Resnick
>>> Review Date: 2020-03-07
>>> IETF LC End Date: 2020-03-31
>>> IESG Telechat date: Not scheduled for a telechat
>>> 
>>> Summary:
>>> 
>>> Abstract, Scope, and Introduction do not accurately reflect the content of 
>>> the
>>> document, which is not simply a registration.
>>> 
>>> Major issues:
>>> 
>>> The Abstract and sections 1 & 2 (Scope and Introduction) indicate that this
>>> document is simply an IANA registration of an S-NAPTR Application Service 
>>> Tag.
>>> However, section 3 is quite clearly new protocol, some of which changes how 
>>> RFC
>>> 5222 implementations should operate if used in a particular context, and
>>> section 4 lays out the backward compatibility of this new protocol with 
>>> legacy
>>> RFC 5222 implementations. There is the implication that the NENA i3 
>>> documents
>>> will actually be the home of that protocol, but the current i3 document
>>> referenced here does not do so, making this document the canonical 
>>> statement of
>>> the protocol operations necessary to implement the i3 architecture. That
>>> doesn't seem appropriate for an Informational document that purports to 
>>> simply
>>> be a registration.
>>> 
>>> At the very least, the Abstract, Scope, and Intro would need to be updated 
>>> to
>>> reflect the actual contents of the document. I think things would be better
>>> served by making this a Proposed Standard document so that it gets the
>>> appropriate level of review. I understand from the Shepherd writeup that the
>>> ECRIT WG doesn't have the energy to really work on this document. However, 
>>> this
>>> is a simple enough extension to the LoST protocol that I think it's
>>> unproblematic to have it as an AD-sponsored standards track document.
> 
> 
> --
> Pete Resnick https://www.episteme.net/ 
> All connections to the world are tenuous at best
> 
> --
> last-call mailing list
> last-c...@ietf.org 
> https://www.ietf.org/mailman/listinfo/last-call 
> 


signature.asc
Description: Message signed with OpenPGP
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-sipcore-sip-push-21 - The pull request

[Ben Campbell]

This looks good to me. Please submit a new revision when you are ready.

Since these changes look minor and not likely to be controversial, I am going 
to go ahead and create a ballot for this. It will likely end up on the 10 
January telechat.

Thanks!

Ben.

> On Dec 21, 2018, at 2:50 AM, Christer Holmberg 
>  wrote:
> 
> Hi,
> 
> Based on the gen-art comments from Stewart, I have created a pull request for 
> the suggested changes.
> 
> https://github.com/cdh4u/draft-sip-push/pull/31 
> <https://github.com/cdh4u/draft-sip-push/pull/31>
> 
> Regards,
> 
> Christer
> 
> From: Christer Holmberg  <mailto:christer.holmb...@ericsson.com>>
> Date: Thursday, 20 December 2018 at 17.37
> To: Stewart Bryant  <mailto:stewart.bry...@gmail.com>>, "gen-art@ietf.org 
> <mailto:gen-art@ietf.org>" mailto:gen-art@ietf.org>>
> Cc: "sipc...@ietf.org <mailto:sipc...@ietf.org>"  <mailto:sipc...@ietf.org>>, "i...@ietf.org <mailto:i...@ietf.org>" 
> mailto:i...@ietf.org>>, 
> "draft-ietf-sipcore-sip-push@ietf.org 
> <mailto:draft-ietf-sipcore-sip-push@ietf.org>" 
>  <mailto:draft-ietf-sipcore-sip-push@ietf.org>>
> Subject: Re: [Gen-art] Genart last call review of 
> draft-ietf-sipcore-sip-push-21
> Resent-From: mailto:alias-boun...@ietf.org>>
> Resent-To: Christer Holmberg  <mailto:christer.holmb...@ericsson.com>>,  <mailto:michael.arn...@metaswitch.com>>, "A. Mahoney"  <mailto:maho...@nostrum.com>>, Brian Rosen  <mailto:b...@brianrosen.net>>, Ben Campbell  <mailto:b...@nostrum.com>>, "a...@nostrum.com <mailto:a...@nostrum.com>" 
> mailto:a...@nostrum.com>>,  <mailto:aamelni...@fastmail.fm>>, Brian Rosen  <mailto:b...@brianrosen.net>>
> Resent-Date: Thursday, 20 December 2018 at 17.37
> 
> Hi Stewart,
> 
> Thank You for the review! Please see inline.
> 
> >Summary: A well written document with some minor points that could use a 
> >little
> >attention.
> >
> >Major issues: None
> >
> >Minor issues:
> >
> >In Figure 1 the following is included:
> >
> > REGISTER sip:al...@example.com  SIP/2.0
> > Via: SIP/2.0/TCP alicemobile.example.com:5060 
> > <http://alicemobile.example.com:5060/>;branch=z9hG4bKnashds7
> > Max-Forwards: 70
> > To: Alice >
> > From: Alice >;tag=456248
> > Call-ID: 843817637684230@998sdasdh09
> > CSeq: 1826 REGISTER
> > Contact:  > ;
> >   pn-provider=acme;
> >   pn-param=acme-param;
> >   pn-prid=ZTY4ZDJlMzODE1NmUgKi0K>
> > Expires: 7200
> > Content-Length: 0
> >
> > SB> However I don't at this stage of the text see the relationship between 
> > the
> > SB> packet flow digram and the text that follows.
> 
> I could add the following:
> 
> “Below is an example of a SIP REGISTER request in Figure 1.”
> 
> =
> 
> >   Contact: IESG (i...@ietf.org <mailto:i...@ietf.org>)
> >
> > SB> Is the whole IESG the most appropriate first point of contact?
> 
> That is what I was told :)
> 
> Note that I have used it also for other documents.
> 
> =
> 
> >Nits/editorial comments:
> >Presumably the references to RFC  will be replaced by RFC  but
> >that does not seem to be noted in the text
> 
> I will add a note to the RFC editor about that.
> 
> “[RFC EDITOR NOTE: Please replace RFC with the RFC number of this 
> document.]”
> 
> 
> 
> > SB> As dicussed in [RFC4320] and [RFC4321], non-INVITE transactions must
> > SB> Typo s/dicussed/discussed/
> 
> I will fix as suggested.
> 
> 
> 
> >   Example: pn-prid = 00fc13adff78512
> >
> >   For more information about the APNs Topic and device token:
> >
> > SB> Is the following part of the example? If so it could usefully be 
> > delimited
> > SB> as such, otherwise, I don't understand why it is not a normal document
> > SB> reference.
> >
> >   https://developer.apple.com/library/archive/documentation/NetworkingI 
> > <https://developer.apple.com/library/archive/documentation/NetworkingI>
> >   nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html
> >
> > SB> Similarly in the following section
> 
> The link reference is not part of the example. Perhaps I could place to 
> reference before the examples, to make that more clear?
> 
> Are you suggesting that I add the link to the reference section, similar to 
> document references?
> 
> =
> 
> Regards,
> 
> Christer



signature.asc
Description: Message signed with OpenPGP
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-sipcore-sip-push-21

[Ben Campbell]

> On Dec 20, 2018, at 9:37 AM, Christer Holmberg 
>  wrote:
> 
> >   Example: pn-prid = 00fc13adff78512
> >
> >   For more information about the APNs Topic and device token:
> >
> > SB> Is the following part of the example? If so it could usefully be 
> > delimited
> > SB> as such, otherwise, I don't understand why it is not a normal document
> > SB> reference.
> >
> >   https://developer.apple.com/library/archive/documentation/NetworkingI 
> > 
> >   nternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html
> >
> > SB> Similarly in the following section
> 
> The link reference is not part of the example. Perhaps I could place to 
> reference before the examples, to make that more clear?
> 
> Are you suggesting that I add the link to the reference section, similar to 
> document references?
> 

One common approachto this  is to add a URL reference section after the normal 
references.

Thanks!

Ben.


signature.asc
Description: Message signed with OpenPGP
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-sipcore-originating-cdiv-parameter-05

[Ben Campbell]

Editorial comment:

Since “originating after CDIV” is effectively used as a compound adjective, it 
would be better to hyphenate it, as in “originating-after-CDIV session”. That 
might also make it less confusing to people unfamiliar with the terminology.

(Such a change can wait to be handled along with any IESG review comments.)

Thanks!

Ben.

> On Nov 6, 2018, at 12:57 AM, Vijay Gurbani  wrote:
> 
> Dear Marianne: OK, if the context of "originating after CDIV" is well 
> understood by the folks working in this area, then I am fine with leaving it 
> as is.
> Thanks.
> - vijay
> 
> On Mon, Nov 5, 2018 at 11:51 AM  wrote:
> Dear Vijay,
> 
> 
> 
> Actually, the « originating » is not qualifying something by itself in this 
> sentence, it has to be understood as a global wording for the new defined 
> session case which is "originating after CDIV" which is different for an 
> “originating call leg”.
> 
> 
> 
> If you don’t mind, I would prefer to keep this wording as it is because it is 
> used although the I-D and quoted in the Introduction section in the following 
> sentence:
> 
> "The sessioncase-param parameter of the P-Served-User header field is 
> extended with the "orig-cdiv" parameter for this "originating after CDIV" 
> session case."
> 
> 
> 
> Marianne
> 
> 
> 
> De : Vijay Gurbani [mailto:vijay.gurb...@gmail.com]
> Envoyé : lundi 5 novembre 2018 18:14
> À : MOHALI Marianne TGI/OLN
> Cc : gen-art@ietf.org; sipc...@ietf.org; i...@ietf.org; 
> draft-ietf-sipcore-originating-cdiv-parameter@ietf.org; Jean Mahoney; 
> b...@nostrum.com
> Objet : Re: Genart last call review of 
> draft-ietf-sipcore-originating-cdiv-parameter-05
> 
> 
> 
> Dear Marianne: Thank you, again, for attending to my comment.
> 
> 
> 
> Note that you still have a dangling verb "originating" in the sentence.  The 
> verb is not qualifying anything:
> 
> 
> 
>For this use case, this document creates a new parameter ("orig-cdiv") for
>the originating after CDIV session case to be embedded in the P-Served-User
>header field.
> 
> 
> 
> In my email, I had suggested adding "call leg" after the "originating" above. 
>  Otherwise, the sentence above is incomplete ... "originating" what?
> 
> 
> 
> Thanks.
> 
> 
> 
> 
> 
> On Mon, Nov 5, 2018 at 11:04 AM  wrote:
> 
> Thanks Vijay for your last feedback. I’m fine with your proposal and have 
> updated the I-D accordingly (v-07):
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/
> 
> BR,
> Marianne
> 
> De : Vijay Gurbani [mailto:vijay.gurb...@gmail.com]
> Envoyé : lundi 5 novembre 2018 17:45
> À : MOHALI Marianne TGI/OLN
> Cc : gen-art@ietf.org; sipc...@ietf.org; i...@ietf.org; 
> draft-ietf-sipcore-originating-cdiv-parameter@ietf.org
> Objet : Re: Genart last call review of 
> draft-ietf-sipcore-originating-cdiv-parameter-05
> 
> Dear Marianne: Thank you for attending to my comments.
> 
> I am fine with the text you added for S1.3.
> 
> Regarding "secase" and "regstate" being existing parameters, ok.  However, 
> since the I-D is defining the "orig-cdiv" parameter, I still think it makes 
> sense to mention this before S4.  You already have the text at the end of 
> S1.3 (the current sentence appears ambiguous).  Let me suggest an edit:
> 
> OLD:
> For this use case, this document creates a new parameter for the
>originating after CDIV session case to be embedded in the P-Served-
>User header field.
> 
> NEW:
> For this use case, this document creates a new parameter ("orig-cdiv") for the
>originating call leg to be embedded in the P-Served-User header field.
> Thanks.
> 
> On Mon, Nov 5, 2018 at 10:30 AM  wrote:
> Hi all,
> 
> Thanks Vijay for the GenArt review.
> I've just submitted a v-06 to address your comments and here is my feedbacks:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/
> 
> >Minor:
> >
> >- S1.3: I am not sure I follow the logic in the problem statement.  Who
> > is the "diverting" user?  The user to who the call was destined?  If so,
> > best to say that explicitly.  (To be sure, I looked into rfc5502 as well,
> > and it does not define "diverting" user either.)  A bit below (in S4), you
> > use the term "served" user to refer to the diverting user.  All in all, the
> > terminology here could be refined.  I suspect that the "originating" user
> > is the callee.
> >
> > Concretely, I think that the first paragraph of S1.3 should be re-written,
> > perhaps with a figure (?) to explain the call flow, or at least some
> > context using Alice, Bob and Carol as the example in S7.1 does (I suspect
> > that Carol is the "diverting" user here).
> 
> [MM] Indeed, I can see that for people not very aware of IETF and 3GPP 
> vocabulary for call diversion service, it can be confusing. I prefer not to 
> add a call flow in the problem statement section but I did some updates in 
> the wording and inserted the Alice, Bob and Carol users for a better 
> understanding.
> 
> >Nits, 

Re: [Gen-art] Genart last call review of draft-campbell-sip-messaging-smime-03

[Ben Campbell]

> On Oct 9, 2018, at 10:50 PM, Peter Yee  wrote:
> 
> Ben,
> 
>   Regarding the metadata, it would seem to that these intermediaries 
> would be inserting this metadata regardless of whether S/MIME was used or 
> not.  As the intermediaries can't read the S/MIME messages (assuming 
> encryption), they aren't revealing anything that the sender could have 
> protected more than is done with S/MIME over the message content.  If there's 
> a case where S/MIME induces the addition of metadata that would not be 
> otherwise attached, then I could see a problem.  It's just not clear to me 
> from the text given that this is the case.

Hi Peter,

The issue isn’t that S/MIME enables this; it’s that it doesn’t protect against 
it. The sender could go to great effort to encrypt their data so that only the 
receiver can read it, and find that the “network” adds it back in cleartext.

This can happen whether or not S/MIME encryption is used, but one assumes the 
sender uses it with an expectation of privacy.

Would it help to add something to the effect  of “The use of S/MIME encryption 
will not prevent privacy leaks introduced by header enrichment.” to the 
beginning of the paragraph?

> 
>   One more potential nit: Page 22, Section 12, 4th paragraph, 4th 
> sentence: verify that you really want UAS (i.e., User Agent Server) in that 
> sentence.  I'm not familiar enough with the context to know if you didn't 
> really mean UAs (User Agents) as was used in the previous sentence.

You are correct, it should be UAs. Good catch.

Thanks!

Ben.

> 
>   Thanks for considering my input.
> 
>   -Peter
> 
> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: Tuesday, October 09, 2018 9:55 AM
> To: Peter Yee
> Cc: gen-art@ietf.org; draft-campbell-sip-messaging-smime@ietf.org; 
> i...@ietf.org
> Subject: Re: Genart last call review of draft-campbell-sip-messaging-smime-03
> 
> Hi Peter, thanks for your review. Please see inline:
> 
> Ben.
> 
>> On Oct 8, 2018, at 9:57 PM, Peter Yee  wrote:
>> 
>> Reviewer: Peter Yee
>> Review result: Ready with Nits
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please treat these comments just like
>> any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>> 
>> Document: draft-campbell-sip-messaging-smime-03
>> Reviewer: Peter Yee
>> Review Date: 2018-10-08
>> IETF LC End Date: 2018-10-10
>> IESG Telechat date: 2018-10-25
>> 
>> Summary:  This draft updates and clarifies the use of S/MIME with SIP
>> and MSRP to provide end-to-end message protection.  A few nits should
>> be corrected and there are a couple of requests listed as minor
>> issues, but those can be safely ignored.  [Ready with nits]
>> 
>> Major issues: None
>> 
>> Minor issues:
>> 
>> Section 10/Appendix A:  It would be good to supply the private keys
>> used for signing and encryption in the example messages so that
>> implementers can test the correctness of their implementations against
>> the RFC.  As it stands, the examples mostly serve to show format.
> 
> The purpose was in fact to show format. We did not mean these to be test 
> vectors, and I don’t think this draft is the right place for that. At best, 
> we would be showing the output of a particular version of OpenSSL.
> 
>> 
>> Page 22, 2nd full paragraph, 2nd sentence: mention is made of
>> information that would have otherwise been encrypted.  It's not clear
>> how use of S/MIME is inducing that information to be sent in the clear 
>> rather than encrypted.
>> Perhaps a brief explanation would help rather than relying on "certain 
>> cases”.
> 
> The point is that the the intermediaries insert cleartext metadata that 
> includes information that the sending client might have preferred to be 
> encrypted.
> 
> How about the following:
> 
> OLD:
>   Certain messaging services, for example those based on CPM and RCS,
>   may include intermediaries that attach metadata to user generated
>   messages.  In certain cases this metadata may reveal information to
>   third parties that would have otherwise been encrypted.  Implementors
>   and operators should consider whether this metadata may create
>   privacy leaks.  Such an analysis is beyond the scope of this
>   document.
> 
> NEW:
>   Certain messaging services, for example those based on CPM and RCS,
>   may include interm

Re: [Gen-art] Genart last call review of draft-campbell-sip-messaging-smime-03

[Ben Campbell]

Hi Peter, thanks for your review. Please see inline:

Ben.

> On Oct 8, 2018, at 9:57 PM, Peter Yee  wrote:
> 
> Reviewer: Peter Yee
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-campbell-sip-messaging-smime-03
> Reviewer: Peter Yee
> Review Date: 2018-10-08
> IETF LC End Date: 2018-10-10
> IESG Telechat date: 2018-10-25
> 
> Summary:  This draft updates and clarifies the use of S/MIME with SIP and MSRP
> to provide end-to-end message protection.  A few nits should be corrected and
> there are a couple of requests listed as minor issues, but those can be safely
> ignored.  [Ready with nits]
> 
> Major issues: None
> 
> Minor issues:
> 
> Section 10/Appendix A:  It would be good to supply the private keys used for
> signing and encryption in the example messages so that implementers can test
> the correctness of their implementations against the RFC.  As it stands, the
> examples mostly serve to show format.

The purpose was in fact to show format. We did not mean these to be test 
vectors, and I don’t think this draft is the right place for that. At best, we 
would be showing the output of a particular version of OpenSSL.

> 
> Page 22, 2nd full paragraph, 2nd sentence: mention is made of information that
> would have otherwise been encrypted.  It's not clear how use of S/MIME is
> inducing that information to be sent in the clear rather than encrypted.
> Perhaps a brief explanation would help rather than relying on "certain cases”.

The point is that the the intermediaries insert cleartext metadata that 
includes information that the sending client might have preferred to be 
encrypted.

How about the following:

OLD:
   Certain messaging services, for example those based on CPM and RCS,
   may include intermediaries that attach metadata to user generated
   messages.  In certain cases this metadata may reveal information to
   third parties that would have otherwise been encrypted.  Implementors
   and operators should consider whether this metadata may create
   privacy leaks.  Such an analysis is beyond the scope of this
   document.

NEW:
   Certain messaging services, for example those based on CPM and RCS,
   may include intermediaries that attach metadata to user generated
   messages.  In some cases this metadata may include information
   that the sender might have preferred not to send in clear
   text. Operators should consider whether this metadata may create
   privacy leaks.  Such an analysis is beyond the scope of this
   document.

> 

> Nits/editorial comments:

I will fix the editorial issues, save one on which I have commented below:

> 
> Page 1, header: remove "RFC" in three places in the "Updates" header.  (Run
> idnits nad read through the output.  There's more.)
> 
> Page 3, Section 1, 5th paragraph, last sentence: append a comma after "RFC
> 3428".
> 
> Page 4, Section 3, 1st paragraph, 1st sentence: change "SIP based" to
> "SIP-based".
> 
> Page 4, Section 3, 4th paragraph, delete an extraneous space before "already".
> 
> Page 5, 1st paragraph, 1st sentence: change "send" to "sent".
> 
> Page 5, 2nd paragraph: append "to" after "intended".
> 
> Page 7, 2nd paragraph after "id-aes128-CBC", 1st sentence: append algorithm
> after "AES-128-WRAP" *or* change "AES-128-WRAP" to "AES-128 wrap" as given in
> RFC 3565.
> 
> Page 7, 3rd paragraph after id-aes128-wrap, 2nd sentence: append "algorithm"
> after (ECDH).  Do something similar for the next two sentences.
> 
> Page 7, Secion 4.3, 1st sentence: expand UAC here on first use.
> 
> Page 8, section 4.4.1, 1st paragraph: insert "as" before "a SIP URI".
> 
> Page 9, 6th paragraph: change "received" to "receive".
> 
> Page 9, 8th paragraph: change "out of band" to "out-of-band".
> 
> Page 10, Section 7.3, 1st paragraph, last sentence: insert a double quote
> before "Unsupported".
> 
> Page 12, Section 8.3, 3rd paragraph, 2nd to last sentence: change "s/mime" to
> "S/MIME".
> 
> Page 13, Section 8.4, 2nd paragraph, 2nd sentence: change "answer" to
> "answerer".
> 
> Page 13, Section 8.4, 2nd paragraph, 3rd sentence: delete duplicated "the".
> 
> Page 13, Section 8.5, 1st paragraph, 2nd sentence: delete duplicated "since".
> 
> Page 14, 1st full paragraph, last sentence: change "Intant" to "Instant".
> 
> Page 14, Section 9.2, 1st sentence: append a space after "mechanism".
> 
> Page 15, Section 10, 1st paragraph, 3rd sentence: join "over" and "running"
> into a single word.
> 
> Page 15, Section 10, 2nd paragraph: if you wish to be historically correct,
> insert "Mr." before "Watson".  That would, however, cause a painful exercise 
> in
> regenerating the examples, so feel free to ignore 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27

[Ben Campbell]

> On Jul 28, 2017, at 7:33 PM, Paul Kyzivat  wrote:
> 
> On 7/28/17 7:23 PM, Christer Holmberg wrote:
>> Hi Paul,
>> Regarding the reference to RFC 4572, the new text in section 10.2.1 
>> references RFC 4572. We earlier agreed we were not going to update that 
>> text, and keep an informative reference to RFC 4572.
> 
> OK, I guess I remember that now. Is it considered acceptable to issue a new 
> document with a reference to an obsolete document when it isn't to highlight 
> a difference from the current document?
> 
> Since this is a review for the teleconference, I'll just leave that for the 
> IESG folk to decide.

As far as I know, there’s no hard and fast rule about this. It really depends 
on whether the difference between the new and obsolete dependencies are 
material to the draft. I do think we (i.e. the IESG) would favor referencing 
the new RFC, but would be open to arguments about why a WG chose to reference 
the obsolete version

Does anyone recall the reasoning in this instance?

Thanks!

Ben.


> 
>   Thanks,
>   Paul
> 
>> Regards,
>> Christer
>> -Original Message-
>> From: Christer Holmberg [mailto:christer.holmb...@ericsson.com]
>> Sent: 29 July 2017 01:07
>> To: Paul Kyzivat ; 
>> draft-ietf-mmusic-dtls-sdp@ietf.org
>> Cc: General Area Review Team ; IETF MMUSIC WG 
>> 
>> Subject: RE: [Gen-art] Gen-ART Last Call review of 
>> draft-ietf-mmusic-dtls-sdp-27
>> Hi Paul,
>> Thanks for the review. I'll fix references.
>> Regards,
>> Christer
>> -Original Message-
>> From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
>> Sent: 28 July 2017 04:01
>> To: draft-ietf-mmusic-dtls-sdp@ietf.org
>> Cc: General Area Review Team ; IETF MMUSIC WG 
>> 
>> Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
>> Team (Gen-ART) reviews all IETF documents being processed by the IESG for 
>> the IETF Chair. Please wait for direction from your document shepherd or AD 
>> before posting a new version of the draft. For more information, please see 
>> the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> Document: draft-ietf-mmusic-dtls-sdp-27
>> Reviewer: Paul Kyzivat
>> Review Date: 2017-07-07
>> IETF LC End Date: 2017-07-24
>> IESG Telechat date: 2017-08-15
>> Summary:
>> This draft is basically ready for publication, but has nits that should be 
>> fixed before publication.
>> (These nits were reported by IdNits. I apologize for not noticing these 
>> during my Last Call review.)
>> Issues:
>> Major: 0
>> Minor: 0
>> Nits:  2
>> (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but no 
>> explicit reference was found in the text
>> This is now redundant because all the references in the text have been 
>> changed to draft-ietf-ice-rfc5245bis.
>> (2) NIT: Obsolete informational reference (is this intentional?): RFC 4572
>> This is now obsolete because it has been replaced by RFC8122. This draft 
>> should now be referencing that.
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-mohali-dispatch-cause-for-service-number-12

[Ben Campbell]

On 27 Jan 2017, at 11:15, marianne.moh...@orange.com wrote:


Hi Joel,

I have submitted a new version (v-13) of the draft.
I have addressed your comment for IPv6 addresses format in the 
example.

Concerning your major comment, the discussion is leaded by Ben.


To that point: Please note that version 13 adds a comment to the end of 
the introduction to make it clear that this draft documents something 
that another group (3GPP) does. It is not an IETF standard.


Thanks!

Ben.



I hope I have correctly address your comment.
https://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-service-number/

Best regards,
Marianne


-Message d'origine-
De : Joel Halpern [mailto:j...@joelhalpern.com]
Envoyé : vendredi 16 décembre 2016 04:57
À : gen-art@ietf.org
Cc : i...@ietf.org; draft-mohali-dispatch-cause-for-service-
number@ietf.org; dispa...@ietf.org
Objet : Review of draft-mohali-dispatch-cause-for-service-number-12

Reviewer: Joel Halpern
Review result: Ready with Issues

Major:
This document defines a new code for use in SIP, and specifies 
new behavior
both for the code itself and for its use in history-info.  I am thus 
confused as to
how this can be an informational RFC.  It looks like it either 
Proposed Standard
or experimental.  Yes, I see that RFC 4458, which this updates is 
Informational.
But just because we did it wrong before does not make that behavior 
correct
now.  In addition to my understanding of the roles of different RFCs, 
I note that
RFC 3969 and the IANA registry both state that this assignment must 
be made

by a standards track RFC.

Minor:
   Given our emphasis on IPv6 over IPv4, would it not make sense for 
the

examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, 
deforme ou falsifie. Merci.


This message and its attachments may contain confidential or 
privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and 
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have 
been modified, changed or falsified.

Thank you.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12

[Ben Campbell]

On 20 Dec 2016, at 17:27, Robert Sparks wrote:


I still think the shepherd's writeup caught this correctly:


draft-mohali-dispatch-service-number-translation
does not register a URI parameter; it just adds a reference
to an existing registration. The decision to keep these
documents informational is not intended to set precedent;
RFC 5727 remains the BCP for the SIP change process.


I personally see no win in trying to force this document to be PS (and 
fixing the things in it, and in what 3gpp plans to do with it to let 
it fly as PS) or in changing the registry at this point. This has an 
odor, but it is not really making the world worse, and the energy that 
it would require from ours and the 3gpp communities to remove the odor 
does not strike me as the right place to make our investements.


Hold your noses and let this go please.


In case it has been unclear from my other comments, this is my 
preference as an individual as well.


One thing for people to keep in mind is that, as mentioned in the quote 
above, all the registration change does is add this draft to the 
references for the entry that 4458 originally registered. Given that 
this draft updates 4458, that seems appropriate. The fact that 4458 
registered that incorrectly is a problem we might fix someday, but that 
doesn't mean _this_ draft has to fix it.





One more general comment inline below:

RjS




[...]



Keep in mind that the registry is not the only concern mentioned so 
far. Both 4458 and -mohali- define protocol. Reviewers have objected 
to that as well.
We have _MANY_ Informational documents that define protocol. That, by 
itself, is not the metric for "not Informational".


Would people find the informational status more palatable if the draft 
clarified that this is for 3GPP, and that we don't endorse it for other 
contexts?



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12

[Ben Campbell]

On 20 Dec 2016, at 16:49, Adam Roach wrote:


On 12/15/16 22:28, Ben Campbell wrote:
The gotcha is that RFC 4588 would not be possible as an informational 
today; it would not have standing to register the "cause" parameter. 
But at the time it was published, there was a lack of clarity around 
the "standards action" policy for the SIP URI parameters registry.


I don't think that's true. We're talking about a registry established 
by RFC 3969, which says:


  "SIP and SIPS URI parameters and values for these parameters MUST be
   documented in a standards-track RFC in order to be registered by
   IANA."

...and...

  "For the purposes of this registry, the parameter for which IANA
   registration is requested MUST be defined by a standards-track 
RFC."


These are not ambiguous statements. We just botched our communication 
with IANA.


For the record, I did not say the RFC was ambiguous. I said "we had a 
lack of clarity". I think having one policy listed in IANA and another 
in the RFC counts. I offer as evidence of said lack of clarity the fact 
that RAI got things wrong with 4458 (My typo of it as 4588 above 
upthread couldn't help, either) :-)


But I think we can do the right thing here without going back and 
fixing all of the issues with our ancestral documents. I mean, sure, 
maybe we should clean that up too, but I don't see the value in 
blocking new work on doing so.


In terms of publishing draft-mohali-dispatch-cause-for-service-number, 
I think there are two reasonable paths forward:


The first would be forming consensus that the two statements I quote 
from 3969 above -- and the reinforcing statement in 5727 -- were all 
incorrect, and that we want to explicitly (i.e., in a new document) 
reverse those statements and update the corresponding registration 
policy. Then, we publish -mohali- as informational.[1]


The second would be implicitly accepting established consensus around 
this registry, and consequently changing -mohali- to PS.


I think a potential third option is to consider whether -mohali- really 
needs to modify the registry. (I'm not saying it doesn't--I'm saying we 
should think about it.)




Rather than figuring out which of these is easier (clearly, the second 
is less work), I think the real question here is: do we think we got 
the registration policy for SIP URI parameters wrong?




Keep in mind that the registry is not the only concern mentioned so far. 
Both 4458 and -mohali- define protocol. Reviewers have objected to that 
as well.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-mohali-dispatch-cause-for-service-number-12

[Ben Campbell]

> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern <j...@joelhalpern.com> wrote:
> 
> I see your point about this adding a value to the entry created by RFC 4458.
> Is there a reason this can not simply be PS?  The fact that 4458 is 
> Informational does not, as far as I can tell, justify continuing the error.  
> While this is for a 3GPP usage, it appears to have been reviewed by the 
> Dispatch WG sufficiently to justify PS.
> One could argue that there is a down-ref issue,
> but the fact that the field is in a standards-track required registry would 
> seem to make that a moot point.
> 

Do you think it makes sense to make some new values for “cause” into a proposed 
standard when “cause” itself is informational?  That seems like a pretty big 
downref issue, as such issues go. (For the record, I could be convinced to 
re-run this LC as PS, but I suspect that would lead to objections in the 
opposite direction.)

Right now, the situation is a standards-action registry with a informational 
entry. That’s clearly broken, but I’m not sure that _this_ draft is the place 
to fix it.

Also, if it makes any difference—even there there was discussion in dispatch, 
this is not a dispatch work item.

> Yours,
> Joel
> 
> PS: It would seem that WG discussion of that sort is something we would like 
> to see in Shepherd writeups.

There’s two paragraphs on the subject in section (1) of the shepherd writeup 
:-)  (but it wasn’t a working group discussion per se.)

Thanks!

Ben.

> 
> On 12/15/16 11:28 PM, Ben Campbell wrote:
>> Hi Joel,
>> 
>> Thanks for the comments. There has been a fair amount of discussion
>> about the status of the draft. The situation is clearly not optimal, and
>> I welcome input on how to straighten it out.
>> 
>> The rational so far has been that this draft updates RFC 4588, which is
>> informational. It adds some additional values and related semantics for
>> the "cause" parameter from 4588. It does not register new parameters;
>> rather it adds itself as a reference in the existing "cause"
>> registration. This is mainly a courtesy to readers. (There is no
>> sub-registry for "cause" parameter values.) We might could get by
>> without that change, since in a perfect world people following the IANA
>> reference to 4588 would notice the "Updated by..." tag.
>> 
>> The gotcha is that RFC 4588 would not be possible as an informational
>> today; it would not have standing to register the "cause" parameter. But
>> at the time it was published, there was a lack of clarity around the
>> "standards action" policy for the SIP URI parameters registry. Making
>> the new values from _this_ draft standards track, when the parameter
>> itself is not, doesn't seem appropriate. We had some discussion about
>> whether we should promote 4588 to PS, but there was not consensus to do
>> so when it was published, and I don't see reason to expect that to have
>> changed.
>> 
>> This draft is primarily intended to meet a need in 3GPP, where I
>> understand they are effectively already doing this. Would it help to
>> more tightly scope this as "Here's something 3GPP is doing..." rather
>> than as a general mechanism?
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> On 15 Dec 2016, at 21:57, Joel Halpern wrote:
>> 
>>> Reviewer: Joel Halpern
>>> Review result: Ready with Issues
>>> 
>>> Major:
>>>This document defines a new code for use in SIP, and specifies new
>>> behavior both for the code itself and for its use in history-info.  I
>>> am thus confused as to how this can be an informational RFC.  It looks
>>> like it either Proposed Standard or experimental.  Yes, I see that RFC
>>> 4458, which this updates is Informational.  But just because we did it
>>> wrong before does not make that behavior correct now.  In addition to
>>> my understanding of the roles of different RFCs, I note that RFC 3969
>>> and the IANA registry both state that this assignment must be made by
>>> a standards track RFC.
>>> 
>>> Minor:
>>>   Given our emphasis on IPv6 over IPv4, would it not make sense for
>>> the examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-mohali-dispatch-cause-for-service-number-12

[Ben Campbell]

Hi Joel,

Thanks for the comments. There has been a fair amount of discussion 
about the status of the draft. The situation is clearly not optimal, and 
I welcome input on how to straighten it out.


The rational so far has been that this draft updates RFC 4588, which is 
informational. It adds some additional values and related semantics for 
the "cause" parameter from 4588. It does not register new parameters; 
rather it adds itself as a reference in the existing "cause" 
registration. This is mainly a courtesy to readers. (There is no 
sub-registry for "cause" parameter values.) We might could get by 
without that change, since in a perfect world people following the IANA 
reference to 4588 would notice the "Updated by..." tag.


The gotcha is that RFC 4588 would not be possible as an informational 
today; it would not have standing to register the "cause" parameter. But 
at the time it was published, there was a lack of clarity around the 
"standards action" policy for the SIP URI parameters registry. Making 
the new values from _this_ draft standards track, when the parameter 
itself is not, doesn't seem appropriate. We had some discussion about 
whether we should promote 4588 to PS, but there was not consensus to do 
so when it was published, and I don't see reason to expect that to have 
changed.


This draft is primarily intended to meet a need in 3GPP, where I 
understand they are effectively already doing this. Would it help to 
more tightly scope this as "Here's something 3GPP is doing..." rather 
than as a general mechanism?


Thanks!

Ben.

On 15 Dec 2016, at 21:57, Joel Halpern wrote:


Reviewer: Joel Halpern
Review result: Ready with Issues

Major:
This document defines a new code for use in SIP, and specifies new
behavior both for the code itself and for its use in history-info.  I
am thus confused as to how this can be an informational RFC.  It looks
like it either Proposed Standard or experimental.  Yes, I see that RFC
4458, which this updates is Informational.  But just because we did it
wrong before does not make that behavior correct now.  In addition to
my understanding of the roles of different RFCs, I note that RFC 3969
and the IANA registry both state that this assignment must be made by
a standards track RFC.

Minor:
   Given our emphasis on IPv6 over IPv4, would it not make sense for
the examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] IESG comments on draft-ietf-straw-b2bua-rtcp

[Ben Campbell]

Hi,

In case people haven't noticed, there are several IESG comments on 
draft-ietf-straw-b2bua-rtcp. I've seen a response to Stephen's comments, 
but haven't seen one to Alissa's discuss or Alia and Alvaro's comments. 
This is on Thursday's telechat; prior discussion would be helpful, even 
if things are not fully resolved by then.


Thanks!

Ben.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-straw-b2bua-rtcp-15

[Ben Campbell]

Hi Russ, please see inline:

Thanks!

Ben.

On 25 Nov 2016, at 14:30, Russ Housley wrote:


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-straw-b2bua-rtcp-15
Reviewer: Russ Housley
Review Date: 2016-11-25
IETF LC End Date: 2016-10-10
IESG Telechat date: 2016-12-01

Summary: Almost Ready


Major Concerns

I wonder if this ought to be a standards-track document.
I recognize that the STRAW WG charter calls for a standards-track
document, but it only contains a handfull of MUST statements that are
not repeats from another RFC.  Maybe this document should become a
Best Current Practice (BCP) instead of a standards-track document.


You may recall you and I had a private email discussion back in October, 
after your LC review concerning the PS status. We discussed that the 
working group had also informational or BCP, but decided to stick with 
PS. (This came up in my AD evaluation as well.) Unless you strongly 
object, I am inclined to let them stick with PS.





Minor Concerns

In Section 3.1, it says:

   ...  However, certain SDP attributes may
   lead to call failures when forwarded by a media relay.  Such
   attributes SHOULD NOT be forwarded.  One notable example is the
   'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
   state the port they're willing to use for RTCP.  ...

This SHOULD NOT statement is vague.  One example of an attribute that
should not be forwarded is given, and the previous sentence provides
some specific attributes that should be forwarded.  While I see why it
is difficult to not be vague, some better advice to the implementer
could be very helpful


While the authors attempted to clarify this, the current draft still got 
similar comments from Alissa and Alia in the IESG review. They've both 
proposed clarifying text--hopefully the combination will fix this.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24

[Ben Campbell]

On 17 Aug 2016, at 12:04, Elwyn Davies wrote:


Hi, Ben.

Having read Barry's proposed update for RFC 3967,  I would be happy 
for that to become the status quo.  However, I would distinguish 
between truly foundational documents that are produced in tandem with 
the protocol standards or subsequently (as mentioned in Barry's draft) 
and what one might call WG process documents such as requirements 
documents and problem statements. I was going to use the word 
'ephemera' to describe these latter types, but that is doing them a 
disservice:  Such documents, along with mailing list archives, can 
provide insight into the thought processes that went into the 
generation of the WG output for future reference.  Both the software 
industry and the standards industry is incredibly bad at remembering 
how decisions were reached - the concept of a 'design diary' never 
seems to have taken hold - with the result that we spend an awful lot 
of time reopening topics that were shown to be blind alleys and such 
like especially after the original participants have moved on.


That being said, I think that the 'design diary' category of documents 
probably ought to be archived elsewhere than the RFC series; 
additionally, it is unclear whether applying the RFC review processes 
and resources to an essentially random subset of WG's design thoughts 
is appropriate (that is a random set of WGs rather than a random set 
of thoughts from any one WG - I hope :-) ).  As mentioned below, it is 
not generally known in advance that parts of such documents might end 
up being key references in later standards which can affect both the 
way in which the documents are written (applicable in this case to 
some extent) and the rigour of review  (the WG seems to have done a 
good job in this case).


Up until last month, I think that the foundational documents extension 
would have covered the situation - RFC 6707 broke the mould, and I do 
not consider that foundational covers it.


Without prejudice to your points (many of which I agree with), can I 
safely assume that the discussion above this point is more around 
Barry's draft, that we don't need to hold draft-ietf-insipid-session-id 
hostage to the completion of that discussion?




Back to the current document:  I have reread s3 of RFC 7206 and there 
are some points that need to be sorted out:


- The term 'end-to-end' is given a slightly specialized meaning in RFC 
7206.  This is presumably carried through to the draft under review, 
but the need to refer to the end-to-end definition is not mentioned in 
the draft.


- The use of 'session' as a shorthand for the specific meaning of 
'communication session' defined in RFC 7206 ought to be emphasized 
within the draft since the shorthand in RFC 7206 is technically 
limited to the RFC (ok, this is somewhat nitpicking but easy to 
misinterpret.)


I agree with both of the above points. Authors?



- The last para of s3.1 of RFC 7206 states:


This definition, along with the constraints imposed by the
requirements in this document,
There is no explicit statement that this standard meets all the 
requirements, so this is difficult to verify and might be 
problematical in future.


I think that text, taken in context, is about the ability to use the 
session-id across protocols, not the definition of session-id in 
general. That is, even if the protocol fails to meet some of the 
requirements, the definition does not change.




Overall, I am of the opinion that in this sort of situation, I'd do a 
copy and paste exercise and tweak the text just a little to fit the 
context more accurately.


Noted, and I hope to discuss that point with the rest of the IESG, 
either via mail or on the telechat. (I note, however, that there were 
multiple comments suggesting a different draft on tomorrow's telechat 
should not have copied definitions forward. Now, that was a requirements 
draft referencing terms from other requirements/architecture/problem 
statement drafts, so the situation may be a bit different.




Cheers,

Elwyn

On 15/08/2016 21:48, Ben Campbell wrote:

Hi Elwyn:

Responsible AD Hat on:

I'm going to enter a DISCUSS position, to make sure this point gets 
discussion among the IESG before this progresses. The whole point of 
the repeated last call was to get feedback on the downref, and this 
certainly counts :-)



All hats off:

As an individual, I still disagree. Specifics inline:

On 12 Aug 2016, at 18:14, Elwyn Davies wrote:


Hi, Ben.
AFAICS there is only one really similar case (downref to RFC 6707) 
which was approved just last month (based on a problem statement).


I'm pretty sure there are more than that; the idea that terminology 
references may need to be normative has come up repeatedly during 
IESG reviews over the past year or so.


 My concern here is that the other framework and requirements 
documents are documents that continue to have a relevance (such as 
telling a network operator what

Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24

[Ben Campbell]

Hi Elwyn:

Responsible AD Hat on:

I'm going to enter a DISCUSS position, to make sure this point gets 
discussion among the IESG before this progresses. The whole point of the 
repeated last call was to get feedback on the downref, and this 
certainly counts :-)



All hats off:

As an individual, I still disagree. Specifics inline:

On 12 Aug 2016, at 18:14, Elwyn Davies wrote:


Hi, Ben.
AFAICS there is only one really similar case (downref to RFC 6707) 
which was approved just last month (based on a problem statement).


I'm pretty sure there are more than that; the idea that terminology 
references may need to be normative has come up repeatedly during IESG 
reviews over the past year or so.


 My concern here is that the other framework and requirements 
documents are documents that continue to have a relevance (such as 
telling a network operator what is necessary to allow deployment of 
some IETF-defined technology) rather than being something that defines 
what a WG is intending to work on (RFC 6707 and RFC 7206 are 
respectively a problem statement and a protocol requirements 
statement).  As we know, there has been some considerable discussion 
of whether we should really be publishing these documents as RFCs 
given that they are snapshots of a discussion position at a point in 
time and are only really of academic interest once the working group 
has done its work.


I agree that we should cut down on publication of "requirements", "use 
case", etc documents that do not have long term archival value. But I 
don't think there should be as hard of a line as you describe. In 
particular, sometimes they are valuable for nailing down especially 
hard-won consensus about requirements. I think that is true for RFC 
7206.


But in any case, I think this is a red herring. RFC 7206 has been 
published. This discussion isn't going to change that.


 Allowing them to be used as normative references further embeds them 
into the system.


I don't see why. Not every action creates a precedent. I do not propose 
that we add RFC to the downref registry.


I would also caution that terminology and such like as defined in 
(protocol) requirements and problem statements are generally written 
and approved prior to the standards documents in which the are 
referenced. Further, I am not totally convinced that the same degree 
of rigour is applied to the review of this type of document.  Thus it 
is vitally important to ensure that the definitions are still correct, 
complete and reflect what is needed for the standard(s):  The 
protocols don't always exactly match the requirements - and there may 
have been some subtle bending of the meaning of terms over time!
If the downref is to be accepted, then I (and other reviewers) need to 
go back and have a harder read of the definitions, unless they think 
they already did.


I believe the working group intent was that the definitions stated in 
RFC 7206 are the ones used in the protocol.


  One consequential question: Is it time for either an update or 
some commentary on RFC 3967 as there seems to be a relaxation of the 
statements in Section 2?


RFC 3967 section 2 makes no attempt to be exhaustive. It basically says 
"there are some reasons to make exceptions. Here are some examples."


(There actually is an ongoing discussion about relaxing bits of RFC 
3967. See draft-leiba-3967upd-downref-00, especially the third paragraph 
of section 1.)

   
However
My view is just that... if the authors, WG, you as AD and the IESG are 
happy with the downref and I am in a minority of one (or a very small 
number) of the IETF, then there is rough concensus and I'll be fine 
with the outcome.  It is only a gen-art revew...


It's a gen-art review on an IETF last call done _specifically_ for the 
downref, so I think the outcome is relevant :-)



Cheers,Elwyn
PSI note that it wouldn't be too late to undo the relaxation.. the 
draft referencing RFC 6707 is still with the RFC Editor ;-)

/E


[...]

Thanks!

Ben.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24

[Ben Campbell]

On 12 Aug 2016, at 10:40, Elwyn Davies wrote:


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-insipid-session-id-26.txt
Reviewer: Elwyn Davies
Review Date: 2016/08/12
IETF LC End Date: 2016/08/04
IESG Telechat date: 2016/08/18

Summary: (2nd Last Call and Telechat) Almost ready. The points from my 
review of -24 in the first Last Call have all been addressed - thanks 
- with the exception of the location of the key definitions of 
"session id" and "communication session".  The latest version (-26) 
refers the reader to RFC 7206 which needs to be a normative reference 
but is an Informational RFC, creating a downref.I cannot see that 
a requirements document meets the criteria for an allowable downref as 
described in Section 2 of RFC 3967. Reproducing the two definitions in 
the new draft (and ensuring that they are accurate for the standards 
document) seems to be a better solution IMO.


Hi Elwyn,

Thanks for all of your reviews on this so far. I agree with the original 
issue, but I disagree with what I understand to be your preferred 
solution.


I agree the definitions are needed to understand this draft. And if 
these were simple definitions, I would agree that this draft should 
simply copy them. But they are not, they are nuanced definitions with 
quite a bit of discussion text. Copying them into this draft would 
require the wholesale copying of 2 sections from RFC 7206, which contain 
about 20 paragraphs and one diagram. That's roughly 20% of the body of 
7206 (not counting front material or references.)


I disagree that this is not an allowable downref. The list in section 2 
of RFC 3967 is a list of examples, not an exhaustive list. We have lots 
of examples of approved RFCs with downrefs to informational RFCs because 
the referenced RFC defined terminology needed to understand the 
dependent document.


Thanks!

Ben.




Major issues:
None

Minor issues:
Downref to RFC 7206 - see above.

Editorial/Nits:
Missing definitions of "session id" and "communication session" - see 
above.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART / SecDir Review of draft-ietf-avtext-splicing-notification-07

[Ben Campbell]

On 2 Jun 2016, at 10:23, Matt Miller (mamille2) wrote:


I am the coincidentally-assigned Gen-ART and SecDir reviewer
for this draft. The General Area Review Team (Gen-ART) reviews all 
IETF
documents being processed by the IESG for the IETF Chair.  The 
Security

Directorate reviews all IETF documents being processed by the IESG for
the security area directors.  Please treat these comments just like 
any

other last call comments that arrived on time.

For more information on Gen-Art, please see the FAQ at

< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.

Document: draft-ietf-avtext-splicing-notification-07
Reviewer: Matthew A. Miller
Review Date: 2016-06-02
IETF LC End Date: 2016-06-01
IESG Telechat date: N/A

Summary:

This document is ready to be published as a Proposed Standard
once the nit is taken care of.

I reviewed a previous revision of this document (-04), and all of my
concerns from the earlier review are addressed herein.

I note this document includes normative references to two 
Informational

documents (RFCs 7201 and 7667).  The references are important to
properly understand some of the security considerations of this
document, but it appears the responsible AD is to add them to the
approved downrefs registry.


Just an observation: we did do a second IETF last call for to the 
normative downrefs.


[...]

Thanks!

Ben.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-campbell-art-rfc5727-update-02

[Ben Campbell]

On 29 Feb 2016, at 8:45, Vijay K. Gurbani wrote:


Ben Campbell wrote:

(+ART ADs)

On 26 Feb 2016, at 14:43, Vijay K. Gurbani wrote:


Minor: - S1, "Other RAI working groups develop extensions to SIP
that do not change the core protocol, new applications of SIP, and
other technologies for interactive communication among humans."

Are we intentionally limiting interactive communications only to
"humans"?  I would suspect that this would be limiting, no?  A
bunch of SIP SUBS/NOTs happen between automaton, or machines.
Surely we don't want to exclude these in the future.  My
suggestion would be to simply take out the phrase "among humans"


Hi Vijay,


Ben: Thank you for considering my comments.  Inline, please.


Actually, the "human" part was intentional. RFC5727 was primarily
about technologies for human communication. Certainly some of those
technologies may be dual use (e.g. XMPP, SIP-Events), but the reason
they were historically in the RAI area is that the primary use cases
under consideration involved humans, or supported those that did.


I suspect that your view as an AD may be more nuanced than mine, but I
must admit that I am not entirely comfortable with limiting ART to
"human communications", as would be implied by the text as currently
written.


We did not mean to imply that ART was limited to human communication. 
That was intended to describe a subset of ART (the historically RAI 
work; primarily the clusters of SIP, SDP,and RTP related groups plus a 
few higher-in-the-stack groups such as RTCWEB).





Certainly nothing in rfc3261 explicitly limits communications to 
humans.



Those boundaries are more blurred now since the merger of APP and RAI
into ART. But 5727 was primarily about the SIP change process. That
text in section 1 is intended to describe the scope of 5727, and in
section 3 to describe the subset of ART wgs that historically would
have been considered RAI.

(I do note the use of RAI that probably needs to be fixed, or at
least put into past tense.)


I believe that dropping the phrase "among humans" from the paragraph
does not impact any aspect that at least I can observe, and may indeed
have the benefit that no one in the future will claim that SIP cannot
be used for m2m communications because of the limiting phrase.


Would it help to characterize these as "historically among humans"?



Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@nokia.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: 
http://goo.gl/x3Ogq


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-campbell-art-rfc5727-update-02

[Ben Campbell]

(+ART ADs)

On 26 Feb 2016, at 14:43, Vijay K. Gurbani wrote:


Minor:
- S1, "Other RAI working groups develop extensions to SIP that do not
 change the core protocol, new applications of SIP, and other
 technologies for interactive communication among humans."

 Are we intentionally limiting interactive communications only to
 "humans"?  I would suspect that this would be limiting, no?  A
 bunch of SIP SUBS/NOTs happen between automaton, or machines.
 Surely we don't want to exclude these in the future.  My suggestion
 would be to simply take out the phrase "among humans".


Hi Vijay,

Actually, the "human" part was intentional. RFC5727 was primarily about 
technologies for human communication. Certainly some of those 
technologies may be dual use (e.g. XMPP, SIP-Events), but the reason 
they were historically in the RAI area is that the primary use cases 
under consideration involved humans, or supported those that did. A 
SUB/NOT protocol that was primarily intended for machine-to-machine use 
probably would not have ended up in RAI.


Those boundaries are more blurred now since the merger of APP and RAI 
into ART. But 5727 was primarily about the SIP change process. That text 
in section 1 is intended to describe the scope of 5727, and in section 3 
to describe the subset of ART wgs that historically would have been 
considered RAI.


(I do note the use of RAI that probably needs to be fixed, or at least 
put into past tense.)


Thanks!

Ben.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-codec-oggopus-10

[Ben Campbell]

On 18 Jan 2016, at 5:35, Harald Alvestrand wrote:


Hm. I was confused. This document is about embedding OPUS (a
standards-track document) inside of OGG (an informational); I was
thinking of the precedent of embeedding video formats (informational 
at

best) inside RTP (a standards-track), with the document specifying the
embedding being standards-track.

So the precedent is not a precedent. My apologies.


There may be another. The Ogg media type registrations (RFC 5334, and 
the obsoleted RFC 3534) are standards track, and normatively reference 
RFC 3533.


(I don't have a strong opinion on which way it should go, and am happy
to let the desire of the authors be a guideline.)


Den 17. jan. 2016 22:04, skrev Ron:

On Sun, Jan 17, 2016 at 08:15:33PM +0100, Harald Alvestrand wrote:

Den 15. jan. 2016 23:26, skrev Joel M. Halpern:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-codec-oggopus-10
 Ogg Encapsulation for the Opus Audio Codec
Reviewer: Joel M. Halpern
Review Date:
IETF LC End Date: 27-January-2016
IESG Telechat date: N/A

Summary:
 This document is nearly ready for publication as a Proposed 
Standard.

 The reviewer believes the status issues needs to be addressed, and
would like the minor issue identified below discussed.

Major issues:
 I do not see how we can have a standards track document for using 
an
Informational format.  RFC 3533 is Informational.  At the very 
least,
the last call needed to identify the downref to RFC 3533.  (It is 
not
clear whether the reference to RFC 4732 needs to be normative or 
could

be informative.)


I agree with the need to have the downref be explicit, but this has 
been
the norm since the IETF first decreed that RTP encapsulations should 
be

standards track.

I believe you were on the IESG at the time, too... it was that long 
ago.


I don't think anyone would have any objection to seeing RFC 3533 
progress
to standards track either, but our understanding was that this was 
not a
strict prerequisite for the CODEC WG publishing this document.  And 
it's

not quite clear if CODEC would actually be the right group to do that
work for 3533.  Maybe CELLAR would be a better fit of the currently
active groups?

For RFC 4732, informative seems correct to me.  Not everything in 
that
document is relevant to this situation, and there may be things 
relevant

to specific implementations or users of this spec which aren't wholly
covered there either (including novel attack methods that nobody has
thought of previously).  It's a topic that implementors should be 
aware
of, but we can't really mandate "if you do this you will be safe", 
nor
"if you don't do this, you won't" in a generally applicable way.  
Much

will depend on the specifics of the actual user and use case.

Cheers,
Ron


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-codec-oggopus-10

[Ben Campbell]

The last call announcement included the following  text:
> Please note that the document makes normative references to RFCs 3533 and 
> 4732, which are informational.
> 
Thanks!

Ben.

Sent from my iPhone

> On Jan 15, 2016, at 4:26 PM, Joel M. Halpern  wrote:
> 
> At the very least, the last call needed to identify the downref to RFC 3533.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Resolution on comments of draft-ietf-l2vpn-vpls-pe-etree-10

[Ben Campbell]

Hi,

This (I assume still unsubmitted) version addresses my IESG ballot 
comments.


Thanks!

Ben.

On 11 Dec 2015, at 5:16, Jiangyuanlong wrote:


Hi all,

Thanks a lot for your reviews.
Based on all the comments received during the IESG evaluation, we have 
prepared a tentative version 11 for this draft.
We believe all the comments are resolved, but please check whether you 
have any concerns with the texts in this version.


If there are no further comments, we will upload it as the formal 
revision 11 version.


Best regards,
Yuanlong


-Original Message-
From: BRUNGARD, DEBORAH A [mailto:db3...@att.com]
Sent: Thursday, December 03, 2015 11:03 PM
To: Jari Arkko
Cc: Jiangyuanlong; Russ Housley; 
draft-ietf-l2vpn-vpls-pe-etree@ietf.org; IETF

Gen-ART; IETF
Subject: Re: [Gen-art] Gen-ART Review of 
draft-ietf-l2vpn-vpls-pe-etree-10


Hi Jari,

Yes, we'll be doing a new revision for addressing other comments.

I've asked for today's telechat if no discusses to mark it as 
approved, revised

draft needed.

Much thanks Russ for your review!

Deborah


Sent from my iPhone


On Dec 3, 2015, at 1:08 PM, Jari Arkko  wrote:

Many thanks for your detailed review, Russ!

Yuanlong, will there be a new draft version or other edits before 
the draft

is approved?

Jari


On 17 Nov 2015, at 00:53, Jiangyuanlong 

wrote:


Russ,

Thanks a lot for your review and good observations.
Please see my comments in line.

Best regards,
Yuanlong


-Original Message-
From: Russ Housley [mailto:hous...@vigilsec.com]
Sent: Saturday, November 14, 2015 1:28 AM
To: draft-ietf-l2vpn-vpls-pe-etree@ietf.org
Cc: IETF Gen-ART; IETF
Subject: Gen-ART Review of draft-ietf-l2vpn-vpls-pe-etree-10

I am the assigned Gen-ART reviewer for this draft. The General 
Area Review
Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for
the IETF Chair. Please wait for direction from your document 
shepherd or AD

before posting a new version of the draft.

For more information, please see the FAQ at
.

Document: draft-ietf-l2vpn-vpls-pe-etree-10
Reviewer: Russ Housley
Review Date: 2015-11-13
IETF LC End Date: 2015-11-24
IESG Telechat date: unknown

Summary:  Almost Ready


Major Concerns: None


Minor Concerns:

Sections 4.1 and 5.3.1 inclues a reference to [802.1Q-2011].  
Should this be
the 2014 version of the document?  If not, please add the 
informative

reference for [802.1Q-2011].

[YJ] Yes, all these should refer to [802.1Q-2014].



Other Editorial Comments:

The Abstract should appear on the title page.

[YJ] OK.


Section 3 needs a reference for MEF 6.1:
s/Specification MEF 6.1/Specification MEF 6.1 [MEF6.1]/ Also, 
[MEF6.1]

needs to be added as a normative reference.

[YJ] All these will be updated to MEF 6.2.


Section 3 needs a reference for IEEE 802.1Q-2003:
s/B.1.3 of IEEE 802.1Q-2003/B.1.3 of IEEE 802.1Q-2003 
[802.1Q-2003]/ Also,

please add an informative reference for [802.1Q-2003].

[YJ] Yes, we will add an informative reference for [802.1Q-2003].

Third level section headings do not have space between the section 
number

and the section title.  For example:
s/5.3.1.PW Processing/5.3.1. PW Processing/

[YJ] OK.

In Fig 4, there is room to shift the figure to the right, this 
will allow the "AC"

labels to fit better on the left:

 ++
 |   VPLS-capable PE model|
 |   +---+  +--+  |
 |   |   |==|TVSI-1|
+---+  AC  |   |     | PWs
|CE |--| Bridge  |
+---+  |   |   | Root &   +--+  |
 |   | Module| Leaf VLAN   o  |
 |   |   | o  |
 |   |   | o  |
 |   |   | o  |
 |   |   | o  |
+---+  AC  |   |   |   VLAN-n +--+  |
|CE |--|   VSI-n |-
+---+  |   |   |==|  |- 
PWs

 |   |   | ^|  |-
 |   +---+ |+--+  |
 | |  |
 +-|--+
   LAN emulation Interface

 Figure 4  A VPLS PE Model for E-Tree with a Single T-VSI



[YJ] OK.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art 2nd LC review of draft-ietf-payload-vp8-16

[Ben Campbell]

On 30 Jul 2015, at 3:14, Harald Alvestrand wrote:

 Unfortunately this is vacation time in Scandinavia - won't do anything
 with this until mid-August, I'm afraid. (Henrik might.)

 So it'll have to wait another 2 telechats or so.

Understood, thanks!

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08

[Ben Campbell]

On 15 Apr 2015, at 4:38, Christer Holmberg wrote:


Hi,


Minor Issues: I previously gave the following comment:
 
“Regarding SDP, I think it would be good to have the ABNF syntax 
for
the a=fmtp parameter (currently you only have descriptive text of 
the

different parameters). It makes the life for the parser implementers
much easier :)”
 
I guess one, by reading section 7 and the examples, can figure out 
how

to encode the a=fmtp parameter, but I think it would to explicitly
define the syntax.


(For the record, I just recently took over responsibility for 
PAYLOAD, so if I'm misinterpreting things, someone please tell me :-) 
 )


While I can see that as a might be nice addition, I don't think 
it's something that we have required of other payload drafts.


After all my years of taking drafts through the IETF publication 
process, I have learned that there is no such thing as consistency :)




That is absolutely true. And I do think it's worth discussing whether 
future payload specs should do that. It's just a matter of who gets 
stuck with a new documentation requirement :-)


draft-ietf-payload-rtp (in RFC ed queue) says the following about 
ABNF for SDP parameters:


Not that commonly used in RTP payload formats but may be useful when 
defining Media Type parameters of some complexity.


If I'm reading correctly, the FMTP parameters in this draft fit the 
pretty common semicolon delimited list of parameter=value pairs, so 
I don't think this rises to the level of some complexity.


So unless you think the parameters in this draft are more complex 
than average, I don't think we need to add them at this late stage. 
It might be worth discussing whether we should ask authors of future 
payload drafts to include ABNF for this sort of thing.


I can live without any changes.


Thanks!



Regards,

Christer


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08

[Ben Campbell]

On 11 Apr 2015, at 8:23, Christer Holmberg wrote:


Minor Issues: I previously gave the following comment:
 
“Regarding SDP, I think it would be good to have the ABNF syntax for 
the a=fmtp parameter (currently you only have descriptive text of the 
different parameters). It makes the life for the parser implementers 
much easier :)”

 
I guess one, by reading section 7 and the examples, can figure out how 
to encode the a=fmtp parameter, but I think it would to explicitly 
define the syntax.


Hi Christer,

(For the record, I just recently took over responsibility for PAYLOAD, 
so if I'm misinterpreting things, someone please tell me :-)  )


While I can see that as a might be nice addition, I don't think it's 
something that we have required of other payload drafts. 
draft-ietf-payload-rtp (in RFC ed queue) says the following about ABNF 
for SDP parameters:


Not that commonly used in RTP payload formats but may be useful when 
defining Media Type parameters of some complexity.


If I'm reading correctly, the FMTP parameters in this draft fit the 
pretty common semicolon delimited list of parameter=value pairs, so I 
don't think this rises to the level of some complexity.


So unless you think the parameters in this draft are more complex than 
average, I don't think we need to add them at this late stage. It might 
be worth discussing whether we should ask authors of future payload 
drafts to include ABNF for this sort of thing.


Thanks!

Ben.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat review of draft-ietf-ippm-rate-problem-09

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ippm-rate-problem-09
Reviewer: Ben Campbell
Review Date: 2015-01-30
IETF LC End Date:
IESG Telechat date: 2015-02-05

Summary: Ready for publication as an informational RFC. Version 09 addresses 
all of my comments from my Gen-ART review of version 08 at IETF last call.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

None


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Last Call: draft-ietf-ippm-rate-problem-08.txt (Rate Measurement Test Protocol Problem Statement) to Informational RFC

[Ben Campbell]

Hi,

This version addresses the concerns from my GEN-ART review. I agree that it's 
reasonable to skip the figure numbers with only two small figures.

Thanks!

Ben.

 On Jan 9, 2015, at 5:33 PM, MORTON, ALFRED C (AL) acmor...@att.com wrote:
 
 Ben, Dan, Greg,
 
 Version 09 of -ippm-rate-problem draft addresses your comments
 to great extent.
 
 Although Ben's (GEN-ART) suggestion to clarify the figure in the Intro was
 adopted, it seems reasonable to leave out the Figure numbers 
 since the two figures are referenced one time each and they are
 only 3 lines high (so not likely to move far, if at all).
 
 Dan's (OPS-DIR) comments have been addressed (following e-mail
 exchange) by inserting a new section on Operational Considerations
 where we have compromised on the text.
 
 Greg's comments have been addressed to the extent possible without
 re-visiting the Toronto compromise which only involved section 5.
 Other comments cite WG agreements that have not actually been 
 discussed AFAIK, or refer to purely OPTIONAL features in the memo.
 
 regards,
 Al
 
 
 From: IETF-Announce [ietf-announce-boun...@ietf.org] On Behalf Of The IESG 
 [iesg-secret...@ietf.org]
 Sent: Monday, December 08, 2014 9:43 AM
 To: IETF-Announce
 Cc: i...@ietf.org
 Subject: Last Call: draft-ietf-ippm-rate-problem-08.txt (Rate Measurement 
 Test Protocol Problem Statement) to Informational RFC
 
 The IESG has received a request from the IP Performance Metrics WG (ippm)
 to consider the following document:
 - 'Rate Measurement Test Protocol Problem Statement'
  draft-ietf-ippm-rate-problem-08.txt as Informational RFC
 
 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 i...@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.
 
 Abstract
 
 
   This memo presents an access rate-measurement problem statement for
   test protocols to measure IP Performance Metrics.  The rate
   measurement scenario has wide-spread attention of Internet access
   subscribers and seemingly all industry players, including regulators.
   Key test protocol aspects require the ability to control packet size
   on the tested path and enable asymmetrical packet size testing in a
   controller-responder architecture.
 
 
 
 
 
 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/
 
 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem/ballot/
 
 
 No IPR declarations have been submitted directly on this I-D.
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnssd-requirements-04

[Ben Campbell]

 On Dec 23, 2014, at 1:45 PM, Kerry Lynn ker...@ieee.org wrote:
 
 On Mon, Dec 22, 2014 at 6:40 PM, Ben Campbell b...@nostrum.com wrote:
 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-dnssd-requirements-04
 Reviewer: Ben Campbell
 Review Date: 2014-12-22
 IETF LC End Date: 2015-01-07
 IESG Telechat date: (if known)
 
 Summary: This draft is basically ready for publication as an informational 
 RFC. Its well written and easy to understand.
 
 Thanks.
  
 Major issues:
 
 None
 
 Minor issues:
 
 The acronym is a bit unfortunate. I suspect that much of the target audience 
 already knows SSD as solid-state drive Of course, I don't really expect you 
 to change it at this point in the process. :-)
 
 This is really just a mnemonic device within this draft to eliminate the need 
 for us to spell out Scalable
 DNS-SD everywhere.  SSD, to the extent that it satisfies the requirements 
 enumerated in this draft, is
 the end goal of the WG.  I doubt it will ever be used outside of that context.

No problem. I mainly found it amusing that I did a double take when I ran into 
SSD later in the document, and had to go back to where it was defined. I really 
don't expect a change.

 
 Nits/editorial comments:
 
 -- IDNits reports a couple of out-of-date references.
 
 What is the proper way to handle this issue at this stage?  There were no 
 nits when I submitted -04,
 but the beat goes on.  Should we just wait until AUTH48 to resolve any out of 
 date references, or
 should I generate a -05 now?

I would check with your AD and/or shepherd. (This could also be done in the 
form of notes to the RFC editor.)

  
 -- REQ2:
 
 Am I correct in assuming that this would not apply to case C when used in 
 zero configuration mode?
 
 I think you are not correct.  My reading of REQ2 is that some configuration 
 mechanism must be provided
 in use case C to *allow* the end user to configure topologically-independent 
 zones if s/he so chooses.
 In the event the end user a) chooses not to use the mechanism (Zero 
 Configuration mode) and b) there
 are multiple zones, my opinion is that these will almost certainly be 
 topologically-dependent.

I don't think that's far off from what I meant. I just wanted to make sure 
there was no contradiction between the requirement that C allow a zero-conf 
mode, and the requirement for C to allow configuration.  As long as there are 
not contradicting assumptions that both be used at the same time, I think it's 
fine.

 
 HTH, -K-
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-lmap-use-cases-05

[Ben Campbell]

Thanks! More inline:

 On Dec 16, 2014, at 3:12 AM, philip.eard...@bt.com wrote:
 
 Thanks!
 phil
 
 
 OLD
 
 o Understanding the quality experienced by customers. Alongside
 benchmarking competitors, gaining better insight into the user's
 service through a sample panel of the operator's own customers.
 The ISP requires a performance viewpoint of the end-to-end
 perspective, which includes: home/enterprise networks; peering
 points; Content Delivery Networks (CDNs); etc.
 
 PROPOSED NEW
 
 o Understanding the quality experienced by customers. The
 network operator would like to gain better insight into the end-to-end
 performance experienced by its customers. This could incorporate home
 and enterprise networks, and the impact of peering, caching and Content
 Delivery Networks (CDNs).
 
 Looks good, but do you expect the last sentence to be exhaustive, or
 are those just examples?
 
 End-to-end could, for instance, incorporate home and enterprise networks, 
 and the impact of peering, caching and Content Delivery Networks (CDNs).
 

Works for me!

 
 
 
 - 3.1, 1st para:
 
 Can you provide a definition or reference for mean opinion score?
 
 Not addressed.
 
 If a reference is really needed, then i guess
 http://en.wikipedia.org/wiki/Mean_opinion_score will do.
 
 
 On a quick search, it looks like that's at least discussed (and maybe
 defined) in ITU-T P.800.
 
 http://www.itu.int/rec/T-REC-P.800-199608-I/en
 
 I'll add whichever reference you prefer - wiki or P.800 which is specifically 
 about telephony.
 The context is:
 This involves
   relating the pure network parameters to something like a 'mean
   opinion score' which will be service dependent (for instance web
   browsing QoE is largely determined by latency above a few Mb/s).

On reflection, given the context of this being a very informational 
reference, and that there doesn't seem to be an authoritative source for the 
term when used outside of telephony, it's not a big deal one way or another. 
The wiki link would be sufficient, as would a one sentence explanation along 
the lines as an aggregation of subjective user experience measurements.


 
 
 
 [...]
 
 
 -- 4.2, 3rd paragraph:
 Can you offer a definition for probes?
 Not addressed.
 
 I don't want to address this one. Formal terminology is in the LMAP
 framework, including the definition of measurement agent. In this
 document we used the more informal term probe, as it seems easy to
 understand without a formal definition. Since this use cases doc might
 have a wider readership, we wanted to avoid terminology and just give
 the reader the motivations and usages of LMAP measurement information.
 
 Could you offer an informal definition, or a such as [example] sort
 of thing? Probe has many meanings. Context might be enough for some
 readers, but possibly not all.
 
 In S3.1 probe is first mentioned. So then I'll add this text:-
 
 NEW
 (A probe is a device or piece of software that makes measurements and reports 
 the results, under the control of the measurement system. Implementation 
 options are discussed in Section 5.)
 
 And in S5
 OLD
 One way involves a special hardware device that is connected directly
   to the home gateway.
 ...
 Another approach involves implementing the measurement capability as
   a webpage or an app that end users are encouraged to download onto
   their mobile phone or computing device.
 
 NEW
 One type of probe is a special hardware device that is connected directly
   to the home gateway.
 ...
 Another type of probe involves implementing the measurement capability as
   a webpage or an app that end users are encouraged to download onto
   their mobile phone or computing device.

That helps, thanks!

 
 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-lmap-use-cases-05

[Ben Campbell]

Thanks for the response. I removed sections that do not seem to need further 
discusson.

 On Dec 15, 2014, at 4:32 PM, philip.eard...@bt.com philip.eard...@bt.com 
 wrote:
 

[...]

 OLD
 
  o Understanding the quality experienced by customers. Alongside
  benchmarking competitors, gaining better insight into the user's
  service through a sample panel of the operator's own customers.
  The ISP requires a performance viewpoint of the end-to-end
  perspective, which includes: home/enterprise networks; peering
  points; Content Delivery Networks (CDNs); etc.
 
 PROPOSED NEW
 
  o Understanding the quality experienced by customers. The network 
 operator would like to gain better insight into the end-to-end performance 
 experienced by its customers. This could incorporate home and enterprise 
 networks, and the impact of peering, caching and Content Delivery Networks 
 (CDNs).

Looks good, but do you expect the last sentence to be exhaustive, or are those 
just examples?


 - 3.1, 1st para:
 
 Can you provide a definition or reference for mean opinion score?
 
 Not addressed.
 
 If a reference is really needed, then i guess 
 http://en.wikipedia.org/wiki/Mean_opinion_score will do.
 

On a quick search, it looks like that's at least discussed (and maybe defined) 
in ITU-T P.800.

http://www.itu.int/rec/T-REC-P.800-199608-I/en

[...]

 
 -- 4.2, 3rd paragraph:
 Can you offer a definition for probes?
 Not addressed.
 
 I don't want to address this one. Formal terminology is in the LMAP 
 framework, including the definition of measurement agent. In this document 
 we used the more informal term probe, as it seems easy to understand 
 without a formal definition. Since this use cases doc might have a wider 
 readership, we wanted to avoid terminology and just give the reader the 
 motivations and usages of LMAP measurement information.

Could you offer an informal definition, or a such as [example] sort of thing? 
Probe has many meanings. Context might be enough for some readers, but 
possibly not all.

 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-opsec-dhcpv6-shield-04

[Ben Campbell]

Thanks for your response. Here's some additional comments. I removed sections 
that didn't seem to need further discussion.


 On Dec 2, 2014, at 5:03 AM, Fernando Gont fg...@si6networks.com wrote:

[...]

 Major issues:
 
 (Note: This is not so much a major issue as a meta-concern that
 doesn't fit well in the major/minor/nit structure.)
 
 I have questions about the intended status. The draft lists BCP. It's
 not clear to me if we intend to say that it's a best practice to
 implement DHCPv6 filtering, or that, if you do implement it, it's a
 best practice to do it like this. Given the strength of a BCP, I
 think it's worth clarifying that.
 
 BCP of implementing it, if you do.
 
 How about adding this text to the intro:
 
 This document specifies a Best Current Practice for the implementation
 of DHCPv6 Shield (DHCPv6)
 

That would help, thanks!

 
 
 Minor issues:
 
 -- abstract, last sentence:
 
 I didn't find this assertion in the body itself. It would be nice to
 see support for it (perhaps with citations).
 
 I guess one could provide references to some vendor's manuals? Is that
 what you have in mind? (although I'd prefer not to do so).

The citations part was more of a nice to have. But it would be worth putting 
some words around that in the body, even if there's nothing to reference.

 
 
 
 -- section 4:
 
 Am I correct in understanding that this is opt in only? You would
 disallow a rule of the form of allow on any port except [list]?
 
 Not sure what you mean.
 
 The idea is that if you want to enable dhcpv6 shield, you need to
 specify on which port(s) the dhcpv6 server(s) is/are connected.

Would a rule of the form Allow DHCPv6 on all ports except port X be allowed?


 
 
 
 Nits/editorial comments:
 
 -- section 1, 2nd paragraph:
 
 This is the first mention of DHCP-Shield I found, not counting the
 doc name and headers. It would be helpful to have an early mention
 that DHCP-Shield is the name of the thing that this draft defines.
 
 -- section 1, 3rd paragraph:
 
 It would be helpful to define what a DHCP-Shield device is, prior
 to talking about deploying and configuring them.
 
 How about adding (in Section 1) the following text:
 
This document specifies DHCPv6 Shield: a set of filtering
rules meant to mitigate attacks that employ DHCPv6-server
packets. Throughout this document we refer to a device
implementing the DHCPv6 Shield filtering rules as the DHCPv6
Shield device
 
 ?

Yes, thanks.


 
 
 -- section 3, paragraph ending with  with ... used as follows
 [RFC7112]:
 
 I'm a bit confused by the citation. Are these defined as follows,
 or in 7112?
 

You did not respond to this one. I note that my next few comments might no 
longer apply if the 7112 reference is clarified. Is the point to say that 7112 
contains the following definitions, which are repeated here for the sake of 
convenience?


 -- section 3, Extension Header
 
 -- these are IPv6 extension headers, right?
 
 Yes. Should we explicitly say so?

I think it would help. The 7112 reference bit might fix it, but as written the 
first explicit mention of IPv6 in the section is the IPv6 Header Chain 
subsection.

 
 
 
 -- section 3, IPv6 Header chain
 
 Is there a relevant citation for this?
 
 Other than RFC7112?

See 2nd comment back.

 
 
 
 Also, while this section talks about some aspects of header chains,
 it never actually defines the term.
 
 Which one?

The term header chain.  That is, something of the form of The IPv6 header 
chain is a linked-list of IPv6 headers. It contains 

 
 
 
 
 -- section 3, Upper-Layer Header
 
 Again, this section talks about the term without defining it.
 
 -- section 5, list entry 1: ... the IPv6 entire header chain ...
 
 Not sure what you mean: Section 3 is all about defining the terms. Am I
 missing something?

Again, the definition doesn't actually define the term. For example, An 
upper-layer header is a header belonging to an upper-layer protocol


[...]

 
 
 -- section 3, rational for item 1: An implementation that has such
 an implementation-specific limit MUST NOT claim compliance with this
 specification.
 
 That's an odd use of 2119 language; I assume this to be true anytime
 an implementation violates a MUST/MUST NOT assertion.
 
 You're right. Should we just change this to lowercase, or do you think
 we should remove the whole sentence?

Either would be okay. I guess it comes down to whether you think this 
requirement (parsing the entire chain) needs to be called out more strongly 
than any other MUST level requirement. 

 
 
 
 -- section 3, rational for list item 3:
 
 It would be helpful if this rational said why dropping unrecognized
 next header values is needed for the purpose, not just the fact that
 7045 allows it to be dropped.
 
 How about adding this at the end of the RATIONALE:
 
 An unrecognized Next Header value could possibly identify an IPv6
 Extension Header, and thus be leveraged to conceal a DHCPv6-server packet.
 
 

That 

[Gen-art] Gen-ART Telechat review of draft-ietf-lmap-use-cases-05

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-lmap-use-cases-05
Reviewer: Ben Campbell
Review Date: 2014-12-02
IETF LC End Date: 2014-10-07
ESG Telechat date: 2014-12-04

Summary: The draft is basically ready for publication as an informational RFC. 
All of the actionable issues from my last call review of version 04 have been 
addressed. There are a few remaining editorial issues, below:

Nits/editorial comments:

-- General: This version is much improved from 04. However it still tends to 
overuse parentheses in ways that are unnecessary and tend to break the flow of 
reading. These can probably be handled by the RFC editor.

The following are editorial comments from my original review that I think need 
further work:

[...]

 
 -- 2.1, third bullet, last sentence:
 
 The sentence hard to parse. Is the first comma intended?

The sentence needs work. Suggestion:

The ISP requires visibility into the end-to-end performance of home and 
enterprise networks,...

[...]

 
 -- 3.1, 1st para, sentence starting with The panel...
 
 I'm confused by the nested lists, nested parentheses, and unexplained 
 ellipses. Also, it seems to contain a comma splice. Are there missing words?

The comma splice is fixed. The nested lists and ellipses are still confusing. 
You might consider splitting lists out into separate For example sentences.

For example:
For example, the operator's access technology might include fiber, HFC, or 
DSL. It might offer broadband speeds of 

I also suggest dropping (say) and and the sentence-starting So... from 
later in the paragraph.

 
 
 - 3.1, 1st para:
 
 Can you provide a definition or reference for mean opinion score?

Not addressed.

 
 
 -- 3.2:
 
 Overly complex sentence structure. Consider breaking into bullet lists. 
 Something seems messed up near  along the lines... . Maybe a cut and paste 
 error?

The bullet list improves things. Bullet 2 still contains a list of examples  in 
the form of comma-spliced sentences.

[...]

 
 
 -- 4.1, 1st para, last sentence: ... mandate transparent information made 
 available...
 
 Should that be ... be made available...?

Fix attempted, but new typo imade introduced.

 
 -- 4.2, 3rd paragraph:
 
 Can you offer a definition for probes?

Not addressed.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-mpls-deprecate-bgp-entropy-label-01

[Ben Campbell]

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-mpls-deprecate-bgp-entropy-label-01
Reviewer: Ben Campbell
Review Date: 2014-11-03
IETF LC End Date:
IESG Telechat date: (if known)

Summary: Draft is ready for publication as a proposed standard. I have a few 
comments that might be worth considering if there are further updates, but 
should not block publication in any way.


Major issues: None

Minor issues:

Am I correct in understanding that this draft deprecates all applicability of 
RFC 6790 to BGP, but lets stand its use in all other protocol contexts? If so, 
an explicit mention of that might be helpful.

Nits/editorial comments:

-- Section 2:

Is the subsequent to the publication of this document disclaimer really 
needed? We update protocols all the time without offering date-based 
grandfather clauses.

-- Section 3:

There's a comma splice at the end of the paragraph. I suggest something to the 
effect of ... , _with_ reference _to_ this RFC.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-weirds-object-inventory-05

[Ben Campbell]

Thanks for the response. I have one further comment, otherwise your responses 
satisfy my concerns.

 On Oct 22, 2014, at 3:21 AM, Ning Kong nk...@cnnic.cn wrote:
 
 Every hyphen? This conflicts with example, where in abuse-mailbox, only one 
 of the hyphens indicated a continuation. (Also, using a continuation signal 
 that duplicates characters that actually appear in the data is confusing. 
 It's probably not worth fixing that at this stage, though.)
 Of course not every hyphen. We mean “Every hyphen as the suffix of each 
 string”. So only the hyphen at the end of a string is used as the special 
 symbol. We’ll try to clarify it in order to make it’s easier to be understood.


a suffix can be more than one character. I suggest A hyphen in the final 
position of a string...
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-weirds-object-inventory-05

[Ben Campbell]

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-weirds-object-inventory-05
Reviewer: Ben Campbell
Review Date: 2014-10-20
IETF LC End Date: 2014-10-24

Summary: This draft is almost ready for publication as an informational RFC. 
However, there are quite a number of editorial issues that probably should be 
considered first.

Major issues:

None

Minor issues:

-- section 4.5:

It may be worth mentioning that the data included instances where the same 
label was used for different objects by different registries.

-- 5.5, first bullet:

Can you elaborate on why nic.ccTLD may not have been a good choice? Does this 
limitation impact the value of the analysis?


Nits/editorial comments:

-- General: This draft needs another round of proofreading. The RFC editor 
could handle most of these, but it would be good to save them the effort. (Not 
to mention that every change made during the RFC editor stage has a slight 
potential to affect meaning.)

-- Abstract, 2nd sentence: ... and result of existing WHOIS information.

Do you mean results of the _analysis_ of existing WHOIS information?

-- section 1, first sentence

Please expand RIRs and DNRs on first mention in the body. (I know you did so in 
the abstract, but they should be re-expanded in the body.)

-- section 1, 2nd bullet:

Missing conjunction?

-- section 1, 6th paragraph:

Can you include a citation for RDAP?

-- section 1, 7th paragraph: 

Paragraph uses presence tense. I suggest if you are describing observations 
made in the past, it should use past tense. 

In number space...

Missing article.

Autonomous Systen Number (ASNs)

Singular term, but plural abbreviation


In domain name space...

Missing article

 A common understanding of all these data formats is critical.

Critical for what purpose?

-- section 1, last paragraph: Objects are classified and categories are 
viewed

Passive voice obscures the meaning. I'm not sure if you mean objects are 
classified and categories are viewed by your analysis, by standards, or by 
the registries.

-- section 3, general:

Inconsistent paragraph construction for the process steps. Some steps are 
imperative, others are descriptive.

-- section 3, first list, list entry  (1)

All the sentences but the last seem to belong with the introduction to the 
process. That is, they are not part of the actual process.

-- section 3, 2nd list, entry (1)

s/Responses of 106 ccTLDs/Responses for 106 ccTLDs

entry (2)

should ... registries that have ... responses be registries that send ... 
responses?

entry (3): ... collected by program...

Missing article.

entry (4): self-designed data elements

Does self-designed mean the same as privately specified?  (as used later in 
the conclusions.)

-- section 4, tables:

I suggest you number the tables, and refer to them by number. Things like the 
following table can cause confusion if some  rendering format (or future 
revision) changes the relative positions.. 

-- section 4.3, 2nd paragraph: ... some table unites ...

Wrong word?  (Unites)

... orderly placed ...'

Does this mean ... placed in order...

Every hyphen ... 

Every hyphen? This conflicts with example, where in abuse-mailbox, only one of 
the hyphens indicated a continuation. (Also, using a continuation signal that 
duplicates characters that actually appear in the data is confusing. It's 
probably not worth fixing that at this stage, though.)

-- section 4.3, table:

What do slashes and parentheses mean in the data? Are they literally in the 
data, or do they mean something else?

-- section 5.1 four ccTLDs and...

Capitalization error.

-- 5.2.2 : In domain name space...

Missing article.

-- 5.2.4, first paragraph after table: ... have 'Sponsoring Registrar' data 
element ...

Missing article.

-- 5.4.2, last paragraph

s/ just parts of all the objects  /  just some of all the objects 















___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-lmap-use-cases-04

[Ben Campbell]

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-lmap-use-cases-04
Reviewer: Ben Campbell
Review Date: 2014-10-07
IETF LC End Date: 2014-10-07

Summary: The draft is almost ready for publication as an informational RFC. 
There are some minor issues and a number of editorial issues that should be 
considered before publication.

Comment:

[I'm not listing this as an issue, because I don't expect any action based on 
it. ]

This draft does not really meet my expectations for a use case draft. The 
majority of this draft is spent on describing two user communities, and why 
they might want large scale end-to-end testing (i.e.. what they will use the 
data for). I would expect a use case draft to break things down more, and 
include more on the expected interactions between actors and systems in the 
actual process of testing. There's a little of that in the conclusions, and a 
good bit more either mentioned in passing or implied in the other sections. It 
would have been useful to have made that sort of thing more explicit.

On the other hand, the main value of such information would be to help build 
the framework draft, and I see that draft is already late in it's process. At 
this stage in the process, expanding the use-case analysis would probably serve 
no purpose.

It's also possible I've just been confused by the draft name; if it had been 
called something like User Communities for LMAP, I would probably have 
reacted differently. 

Major issues:

None

Minor issues:

-- section 2.1, 1st paragraph:

Is testing of service performance really in scope? I assume that would 
include testing the performance of the hosts providing services, in addition to 
the actual network performance.  (I'm not saying it shouldn't be in scope, but 
if it is it should be called out more strongly, since it probably implies 
different sorts of testing.)

-- section 7:

The first paragraph says that this document does not raise any security 
considerations. I would expect a document that talks about the needs of various 
user communities to include descriptions of security needs from the perspective 
of those communities. In fact, the draft does mention at least 2, namely 
privacy issues, and confidentiality of test data. 

I think there might be others; for example, is there a danger that tests will 
be interpreted as an attack? Do regulators need to worry about ISPs gaming the 
tests?

The section goes on to summarize security considerations from the framework 
draft, but those are not from the perspective of any particular user community.

-- references

There are no normative references. That seems strange, as it implies there are 
no references that the reader needs to read to understand this draft.  I'd at 
least expect the framework to be a normative dependency, since at least section 
7 leans heavily on it.

Nits/editorial comments:

-- General:

The draft suffers from a very complex and nested sentence structure that makes 
it harder to read than it needs to be.  In particular, I find a number of 
sentences that are effectively lists, where some or all list elements contain 
sub-lists of examples in parentheses. These would be much easier to read if 
they were formatted as actual bullet or numbered lists. I suggest making 
another edit pass with an eye towards simplifying the language.

-- section 1, 2nd and third sentences:

I gather these are intended to describe (or name) the use cases, but they sound 
more like motivation to have the use cases.

-- section 2:

I'm surprised at the assumption that last mile implies fixed access.

-- section 2, last sentence:

I suggest dropping also, as it makes it sound like you mean to add IPv4 and 
IPv6 to the list of access technologies earlier in the paragraph.

-- section 2.1, 2nd bullet:

Can you offer a reference or definition for over-the-top?

-- section 2.1, second bullet: Through identifying the end user experience...

Do you mean _measuring_ the end user experience?

-- 2.1, third bullet, last sentence:

The sentence hard to parse. Is the first comma intended?

-- 2.2, 2nd paragraph, first sentence.

The sentence is hard to read. Can it be broken up or otherwise simplified?

-- 2.2, paragraph 3: ... datasets that are able to compare...

I suggest ...datasets that can be used to compare...

-- 2.2, paragraph 4: ... show a performance...

Extraneous article a.

-- 3.1, 1st para, sentence starting with The panel...

I'm confused by the nested lists, nested parentheses, and unexplained ellipses. 
Also, it seems to contain a comma splice. Are there missing words?

- 3.1, 1st para:

Can you provide a definition or reference for mean opinion score?

-- 3.2:

Overly complex sentence structure. Consider breaking into bullet lists. 
Something seems messed up

Re: [Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

[Ben Campbell]

Hi Kevin,

For the record, based on your comments I now consider the SSRC text to be a 
minor issue rather than a major one. 

Comments inline (again, deleting parts that seem closed)

On Sep 18, 2014, at 10:30 AM, Igoe, Kevin M. kmi...@nsa.gov wrote:

[...]

  
 Does the source in each source mean the synchronization source?
  
 These terms get a little slippery, bit what I mean is the gear responsible
 for encrypting outgoing data. Let’s call this the originating box.
  
 I'm not entirely sure I follow you, but I read this to mean you avoid the 
 need for central management of SSRCs by not sharing keys between more than 
 one originator? (that is Assuming so (and my next comment will make no sense 
 otherwise): Wouldn't it make more sense to discourage shared keys, since such 
 sharing would create a need for central ssrc management, rather than suggest 
 ssrc management in the first place?
  
 Yes, but sadly key management is out-of-scope for srtp.  Also a stronger verb 
 that
 than “discourage” is needed, more like “prohibit”.

I don't think the fact that key management is out-of-scope for srtp in general 
prevents you from offering guidance security critical parts.


  
 Or do you expect communities to actually implement central ssrc management?
  
 If there is a small network of devices sharing the same key, say a video 
 conference with
 a handful of participants. One could envision giving each box entering the 
 conference
 a unique SSRC prefix it uses for any SSRCs it needs to create, once again 
 localizing the
 SSRC management (save for the task of handing out SSRC prefixes).
  
 The bottom line is that there are several ways to mitigate the need for 
 centralized
 SSRC magament.  I agree with you that the key management based approach is 
 far and
 away the cleanest approach.
  
 My sole concern is not reusing an (SRTP, key) pair.  Any robust mechanism 
 (i.e.
 not probabilistic) that achieves this goal is acceptable.

I guess my problem is that I took the text as written to suggest that 
centralized ssrc management was expected to be the normal case. I think it 
would be perfectly reasonable to say something to the effect of ... MUST not 
share keys unless a secure mechanism is used to guarantee that SSRC values 
never collide. I realize that is logically similar to MUST have [ssrc 
coordination] in order to share keys, but the spin is a bit different.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

[Ben Campbell]

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-avtcore-srtp-aes-gcm-14
Reviewer: Ben Campbell
Review Date: 2014-09-11
IETF LC End Date: 2014-09-11

Summary: This draft is almost ready for publication as a proposed standard, but 
there are open issues that should be addressed first.

Note: I have not attempted to verify the pseudocode fragments in this draft. 

Major issues:

[Note: I am on the fence on whether the following is a major or minor issue. I 
put it in the major section to draw attention to it, but I am prepared to 
downgrade it if discussion seems to suggest doing so.]

-- Section 9.4, SSRC Management

If I read this section correctly, the draft requires central management of SSRC 
values when you have a master key shared among endpoints in a SRTP session, and 
goes so far to require authentication of data a central SSRC manager. This 
seems like a pretty big architectural change to the handling of SSRC that would 
likely be an impediment to deployment.  I also have to wonder if such an SSRC 
manager could become a central point of attack.

I note that RFC 3711, section 9.1 talks about what I gather is the same issue, 
and does not seem to call for a central SSRC manager. Are the requirements here 
that different than for 3711?

Minor issues:

-- General:

There are a number of instances of 2119 normative language that I suspect do 
not define new normative requirements as much as repeat normative requirements 
from elsewhere (either in this draft, or from elsewhere.) This creates 
confusion on which text is authoritative, and creates an opportunity for 
inconsistent normative statements about the same thing. I strongly suggest that 
anytime you repeat or summarize normative text that is authoritatively stated 
elsewhere, you either use descriptive (non-normative) language (e.g., Foo is 
required to bar the baz), or clearly attribute the source (e.g. [XXX] says that 
foo MUST bar the baz.)

-- References:

The draft has normative down ref to RFC 3610. This was not explicitly mentioned 
in the IETF last call email, and does not appear to be included in the down ref 
registry.

-- 8.1:

If this draft contradicts normative language from RFC 3711, it should 
explicitly update 3711.

-- 8.2

Can you offer guidance on when it might be (or not be) necessary to disguise 
the length of the plaintext?  Especially how that might be known at the SRTP 
layer?

-- 14.1:

Does the master salt need to be kept secret? If the answer is it depends, can 
you offer guidance?

Also, can you offer a definition of properly erased?


Nits/editorial comments:

-- There is a citation of RFC2675, but it doesn't appear in the references.

-- The abstract is out of place (Should be at beginning.)

-- section 1, third paragraph: ... provides a high level of security ...

That may change over time. I suggest prefacing with At the time of this 
writing...

-- section 3, last paragraph:

Please expand IV on first mention.

-- section 5.3, last paragraph:

First and last sentence seem to contradict each other.

-- 15.1:

The IANA registration section for the SDES crypto-suites is oddly stated. That 
registry is just a table; the use of the srtp-crypto-suite-ext ABNF 
construction may be confusing.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-forces-model-extension-04

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-forces-model-extension-04
Reviewer: Ben Campbell
Review Date: 2014-08-27
IESG Telechat date: 2014-09-04

Summary: Ready for publication as a proposed standard

Note: This version, along with email correspondences, address all of the 
comments from my review of version 03 at IESTF last call.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] New Version Notification - draft-ietf-core-groupcomm-24.txt

[Ben Campbell]

On Sep 1, 2014, at 4:20 PM, Rahman, Akbar akbar.rah...@interdigital.com wrote:

 Hi Martin/Kathleen/Barry,
 
 
 
 We fixed one small but important point (in groupcomm-24):
 
   o  Clarified in section 2.6.1.2 (Configuring Members) that ABNF rules
  from Section 3.2.2 of [RFC 3986] should be used for the IP address
  parsing.
 
 
 Can you please review and tell us if you have any remaining comments on the 
 document?  

[...]

Hi,

Here's an update to my Gen-ART review at the IETF last call of version 21:

Summary: This version is almost ready for publication as an experimental RFC. I 
think there are still a few minor issues and nits that might be worth 
considering prior to final publication.

Note: Much of my original review has been addressed, especially through the 
move to experimental. I quoted comments from that review below. I removed those 
that did not seem to warrant further comment, and added a few additional 
comments.

  Major issues:

None. All major issues from my previous review have been addressed.

[...]

 


 
  Minor issues:
 

[...]

 
 -- 2.6:
 
 I think the Resource Directory reference needs to be normative.  (I see the 
 discussion of this from Barry's AD review, where the authors argued that the 
 reference is optional for implementations. But our definition of normative 
 references also includes things necessary to fully understand this draft. 
 Fully understanding even optional features is part of that.)
 

 -- 2.7.1, 2nd paragraph:
 
 Does this imply a need to coordinate pre-configured group addresses to avoid 
 collisions?
 
 -- 2.7.2.1: 2nd 2 last paragraph:
 
 Are there any scenarios where a missing port might be determined from DNS, 
 rather than just assuming the default?
 
 -- 2.7.2.6, 1st paragraph: This operation MUST only be used to delete or 
 update group membership objects for which the CoAP client, invoking this 
 operation, is responsible
 
 Do I understand correctly that this replaces the entire set? Is it possible 
 for two different clients to be responsible for two different subsets? If so, 
 how?
 

It's more clear to me now that this replaces the entire set. It's still not 
clear if different clients can manage different subsets.

[...]

 
 
  Nits/editorial comments:

[...]

 -- 2.2, 4th paragraph:  ... it is recommended ... 
 
 Was that intended as normative? 
 
 Along those lines, I see a number of sections where 2119 words are used in 
 lower case where it looks like they were not intended as normative (e.g., 
 where you talk about normative requirements from RFC 7252), but in other 
 areas it's not as clear (like this one.) It would be best to either avoid 
 lower case versions of 2119 words, or make it very clear whether they should 
 be interpreted normatively or not.

I see there is a new disclaimer in the 2119 section, pointing out that lower 
case words are not normative. Personally, I don't like that approach, because 
1) It's confusing, and 2) lots of people ignore such disclaimers. But that's 
just a personal opinion, and I've seen an number of RFCs that do exactly this.

[...]

 
 -- 2.7.2.1, paragraph after examples:
 
 You mention an optional port for a attributes, but not for n attributes. 
 The BNF for group-name seems to allow an optional port. (and you mention an 
 optional port for n later.
 
 
[...]


-- Additional Nit: 

You have several citations to RFCs that include a space in the tag (i.e. [RFC 
] ), while the references do not have the space (i.e. [RFC]). 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-forces-model-extension-03

[Ben Campbell]

Hi,

This version addresses all of the concerns from my gen-art review.

Thanks,

Ben.

On Aug 21, 2014, at 5:26 PM, Haleplidis Evangelos eha...@ece.upatras.gr wrote:

 Greetings Ben,
 
 Thank you very much for the review and the discussion.
 I have made all the relevant changes and have submitted (just in time it
 seems) the new version.
 
 Regards,
 Evangelos Haleplidis.
 
 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Thursday, August 21, 2014 1:22 AM
 To: Haleplidis Evangelos
 Cc: draft-ietf-forces-model-extension@tools.ietf.org; gen-
 a...@ietf.org; i...@ietf.org
 Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03
 
 
 On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos
 eha...@ece.upatras.gr wrote:
 
 
 [ΕΗ] I discussed with Joel with regards to the copyright issues.
 The short answer is that this document draws directly from RFC5812
 and
 relies on RFC5812 for such issues (as it uses the same boilerplate).
 
 Is this satisfactory?
 
 
 Hrmm. So it does. I somehow had it in my head it had the older
 boilerplate. I must have gotten that from one of the draft versions So,
 never mind :-)
 
 (It's interesting that IDNits apparently looked at the date of
 publication of the first 00 draft, not the RFC. I'm curious the history
 of what happened with RFCs that were in-process works and had changes
 in authorship at the time 5378 was published--but that's not this
 draft's problem and should probably happen in a bar discussion.)
 
 [...]
 
 
 In this particular case, it's not clear to me if the MUST actually
 constrains a choice vs being a statement of fact. If you believe it
 to be the former then I am okay with it. The rewording might help.
 
 
 [ΕΗ] I reworded it and provided also an example. The text now reads:
 
 When optional access type for components within a struct are
 defined,
 these components's access type MUST override the access type of the
 struct. For example if a struct has an access type of read-write but
 has a component that is a read-only counter, the counter's access
 type MUST be read-only.
 
 I believe that it is an implementation constraint as there are two
 possibilities (override or not). With the MUST we constrain it to
 one (override).
 
 I also changed the two it MUST be ignored to the access type MUST
 be ignored to better specify what it is.
 
 
 This helps.
 
 For the record, my suggestion on more active voice was to say what must
 do the ignoring. But I think what you've got is good enough.
 
 [...]
 
 
 
 No, I am not one.  Hopefully this will get a SecDir review as well.
 But that sort of review usually goes better if the Security
 Consideration section shows your reasoning, along the lines of
 listing the high-level types of changes, and for each, why it has no
 new security impact. Your response contains more of that sort of
 thing; it might help to add it (or parts of it) to the draft.
 
 I was a bit concerned that the default version for inheritance could
 be an issue, but you addressed that elsewhere.
 
 [...]=
 
 [ΕΗ] Ok, added part of this. Now the security considerations read the
 following:
 
 This document adds only a few constructs to the initial model defined
 in RFC5812, namely namely a new event, some new properties and a way
 to define optional access types and complex metadata. These
 constructs
 do not change the nature of the the initial model. In addition this
 document addresses and clarifies an issue with the inheritance model
 by introducing the version of the derivedFrom LFB class.
 Thus the security considerations defined in RFC5812 applies to this
 document as well as the changes proposed here are simply constructs
 to
 write XML library definitions, as where in RFC5812 and have no effect
 on security semantics with the protocol.
 
 
 You might consider adding something to say that the inheritance model
 change also does not change the security considerations. (Maybe it
 makes things better, by removing the potential for choosing a wrong
 parent class? Not sure if that's a security issue, unless there was
 some kind of parent-assertion attack.)
 
 It does seem like the inheritance change is a bona-fide extension, not
 just a clarification, since you added the version attribute.=
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-forces-model-extension-03

[Ben Campbell]

On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos eha...@ece.upatras.gr wrote:

 
 [ΕΗ] I discussed with Joel with regards to the copyright issues.
 The short answer is that this document draws directly from RFC5812 and
 relies on RFC5812 for such issues (as it uses the same boilerplate).
 
 Is this satisfactory?
 

Hrmm. So it does. I somehow had it in my head it had the older boilerplate. I 
must have gotten that from one of the draft versions So, never mind :-)

(It's interesting that IDNits apparently looked at the date of publication of 
the first 00 draft, not the RFC. I'm curious the history of what happened with 
RFCs that were in-process works and had changes in authorship at the time 5378 
was published--but that's not this draft's problem and should probably happen 
in a bar discussion.)

[...]

 
 In this particular case, it's not clear to me if the MUST actually
 constrains a choice vs being a statement of fact. If you believe it to
 be the former then I am okay with it. The rewording might help.
 
 
 [ΕΗ] I reworded it and provided also an example. The text now reads:
 
 When optional access type for components within a struct are defined, these
 components's access type MUST override the access type of the struct. For
 example if a struct has an access type of read-write but has a component
 that is a read-only counter, the counter's access type MUST be read-only.
 
 I believe that it is an implementation constraint as there are two
 possibilities (override or not). With the MUST we constrain it to one
 (override).
 
 I also changed the two it MUST be ignored to the access type MUST be
 ignored to better specify what it is.
 

This helps. 

For the record, my suggestion on more active voice was to say what must do the 
ignoring. But I think what you've got is good enough.

[...]


 
 No, I am not one.  Hopefully this will get a SecDir review as well. But
 that sort of review usually goes better if the Security Consideration
 section shows your reasoning, along the lines of listing the high-level
 types of changes, and for each, why it has no new security impact. Your
 response contains more of that sort of thing; it might help to add it
 (or parts of it) to the draft.
 
 I was a bit concerned that the default version for inheritance could be
 an issue, but you addressed that elsewhere.
 
 [...]=
 
 [ΕΗ] Ok, added part of this. Now the security considerations read the
 following:
 
 This document adds only a few constructs to the initial model defined in
 RFC5812, namely namely a new event, some new properties and a way to define
 optional access types and complex metadata. These constructs do not change
 the nature of the the initial model. In addition this document addresses and
 clarifies an issue with the inheritance model by introducing the version of
 the derivedFrom LFB class.
 Thus the security considerations defined in RFC5812 applies to this document
 as well as the changes proposed here are simply constructs to write XML
 library definitions, as where in RFC5812 and have no effect on security
 semantics with the protocol.
 

You might consider adding something to say that the inheritance model change 
also does not change the security considerations. (Maybe it makes things 
better, by removing the potential for choosing a wrong parent class? Not sure 
if that's a security issue, unless there was some kind of parent-assertion 
attack.)

 It does seem like the inheritance change is a bona-fide extension, not just a 
clarification, since you added the version attribute.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21

[Ben Campbell]

On Aug 14, 2014, at 5:12 PM, Rahman, Akbar akbar.rah...@interdigital.com 
wrote:

 Hi Ben,
 
 
 Thank you for your thorough review.  Here is my initial feedback on the
 two major issues that you raised:
 
 
 The draft contains significant material that I do not believe is
 appropriate for an informational RFC, at least without some clear
 explanations about why it appears. It purports to clarify the normative
 stuff in RFC 7252 concerning multicast, but it does quite a bit more
 than that.  Section 2.7 defines protocol ...
 
 Response:
 -
 The majority of the document is geared towards explaining how RESTful
 group communications protocol should work based on the protocol
 primitives defined in CoAP (RFC 7252).  This was certainly the original
 intent of the document (i.e. expand and explain CoAP group
 communications protocol processing defined in RFC 7252 but do not
 introduce any new functionality).  Then at a late(r) stage of
 development of the document, the WG decided that we should also include
 some management aspects of CoAP group communications.   This resulted
 in addition of Sections 2.6, 2.7, 3.6, 6.1,  6.2.  The offending (new)
 functionality is pretty clearly limited to these sections.
 
 Therefore, I think we have two possible options to address your comment:
 1) Remove Sections 2.6, 2.7  3.6 that focus on the management aspects
 from the current document and spawn a new document (or potentially
 migrate them to I-D.ietf-core-resource-directory if that makes sense).
 2) Change the status of the document from Informational to Standards
 Track or BCP (and clearly indicate that the new functionality beyond RFC
 7252 is introduced in Sections 2.6, 2.7, 3.6, 6.1,  6.2).
 
 Ben/Barry - Can you give us some guidance here?

I think this is really up to you and Barry, but I think either approach would 
be okay. Option 1 would allow you to treat different sections differently, 
which might have some advantage. If you chose option 2, Standards Track seems 
the better option as long as the new functionality is included.

 
 
 
 
 The security aspects of group CoAP are pretty bad. To its credit, the
 draft does a pretty good job of calling that out, and that work is in
 progress to improve it. But I have to wonder if we would be better off
 not encouraging multicast CoAP at all until such improvements are
 available.
 
 Response:
 -
 Well, I think that we could definitely add stronger language
 recommending not to use CoAP group communication until stronger security
 solutions are developed in IETF.  However, as you noted, the fact is
 that RFC 7252 already allows the current unsecured CoAP group
 communications.  So I don't really appreciate how this could be a
 blocking issue on progression of this document.

I agree that 7252 already has this issue. It also has some normative language 
around not using it without some type of authentication, but IIRC it doesn't 
say much about protection from eavesdroppers or privacy issues. 

I understood one of the purposes of this draft is to clarify the usage of group 
CoAP. I think it's reasonable to expect such clarification to include(normative 
or otherwise) guidance on how to use it safely.  I recognize that there is some 
guidance there already, but I think you could take a stronger position on some 
aspects. 

For example, you mention how the smart grid example may be high risk. It would 
be helpful to also point out how it by nature cannot be secured by the 
mitigation approaches mentioned in section 5, nor the minimal scope 
recommendation in section 5.4. Therefore, perhaps group CoAP should not be used 
for that application?

 
 
 
 Looking forward to your response,
 
 
 Akbar
 
 
 -Original Message-
 From: core [mailto:core-boun...@ietf.org] On Behalf Of Ben Campbell
 Sent: Thursday, August 14, 2014 5:06 PM
 To: draft-ietf-core-groupcomm@tools.ietf.org
 Cc: gen-art@ietf.org Team (gen-art@ietf.org); c...@ietf.org
 Subject: [core] Gen-ART LC Review of draft-ietf-core-groupcomm-21
 
 (Oops, I screwed up the CC list the first try. Please send any replies
 to this distribution. Apologies for the repeat.)
 
 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-core-groupcomm-21
 Reviewer: Ben Campbell
 Review Date: 2014-08-14
 IETF LC End Date: 2014-08-14
 IESG Telechat date: 
 
 Summary: This draft is not ready for publication as an informational
 RFC. It has some significant issues, detailed below.
 
  Major issues:
 
 -- The draft contains significant material that I do not believe is
 appropriate for an informational RFC, at least without some clear
 explanations about why it appears. It purports to clarify the normative
 stuff in RFC 7252 concerning multicast, but it does quite a bit more

[Gen-art] Gen-ART LC Review of draft-ietf-core-groupcomm-21

[Ben Campbell]

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-core-groupcomm-21
Reviewer: Ben Campbell
Review Date: 2014-08-14
IETF LC End Date: 2014-08-14
IESG Telechat date: 

Summary: This draft is not ready for publication as an informational RFC. It 
has some significant issues, detailed below.

 Major issues:

-- The draft contains significant material that I do not believe is appropriate 
for an informational RFC, at least without some clear explanations about why it 
appears. It purports to clarify the normative stuff in RFC 7252 concerning 
multicast, but it does quite a bit more than that.

Section 2.7 defines protocol, in the form of a RESTful methods and attributes 
to manage multicast group membership.I agree in some cases it makes sense for 
an informational RFC to define protocol. A common example is when we want to 
document a proprietary protocol for some reason. As written, this does not seem 
to fall unto such a case. If the authors and working group believe it does, it 
would be helpful to add text explaining that, and how the reader should 
interpret the section. (I recognize that this interface is optional--but I 
don't think making it optional changes whether it should be standards track.)

In addition to that, the draft contains quite a bit of guidance that might be 
more appropriate BCP. For example, there is guidance here where not following 
it might do harm to the network. Additionally, I don't see how anyone could 
expect to achieve interoperability the multicast features of RFC 7252 without 
understanding this draft.  (I have to wonder why RFC 7252 did not have a 
normative dependency on this draft.)

-- The security aspects of group CoAP are pretty bad. To its credit, the draft 
does a pretty good job of calling that out, and that work is in progress to 
improve it. But I have to wonder if we would be better off not encouraging 
multicast CoAP at all until such improvements are available. Section 5.3 calls 
out some reasonable examples of mitigation approaches, but I am a little 
concerned at the guidance that one should worry about these for sensitive or 
safety-critical data. People are not good at knowing what data is sensitive 
until it gets used against them. I think this is especially true for IoT 
applications where we have less deployment experience.

Along those lines, the Pervasive Monitoring Considerations section (kudos for 
having one, btw), tries to balance application needs vs protecting information. 
But the smart-grid example seems to be a case where the two are really at odds. 
I am afraid people will interpret this along the lines of well, the smart-grid 
application requirements force me to send unprotected data all over the place, 
when I think the right answer is Group CoAP should not be used for this sort 
of application until we can protect the data.




 Minor issues:

-- 2.2, 5th paragraph: For sending nodes, it is recommended to use the IP 
multicast address literal in a group URI.

Can you elaborate on why? I can guess, but anytime we suggest using literal IP 
addresses rather than DNS names, it's worth elaborating.

-- 2.4:  ... if the resource being POSTed to has been designed to cope with 
the unreliable and lossy nature of IP multicast.

Can you elaborate on what it means to be designed to cope...? (Or reference 
something that does?)

-- 2.6:

I think the Resource Directory reference needs to be normative.  (I see the 
discussion of this from Barry's AD review, where the authors argued that the 
reference is optional for implementations. But our definition of normative 
references also includes things necessary to fully understand this draft. Fully 
understanding even optional features is part of that.)

-- 2.7.1, 2nd paragraph:

Does this imply a need to coordinate pre-configured group addresses to avoid 
collisions?

-- 2.7.2.1: 2nd 2 last paragraph:

Are there any scenarios where a missing port might be determined from DNS, 
rather than just assuming the default?

-- 2.7.2.6, 1st paragraph: This operation MUST only be used to delete or 
update group membership objects for which the CoAP client, invoking this 
operation, is responsible

Do I understand correctly that this replaces the entire set? Is it possible for 
two different clients to be responsible for two different subsets? If so, how?

-- 2.8 and (especially) 2.9:

Lack of 2119 language in the additional guidlines seems inconsistent with 
other parts of this draft that do use 2119 language. (I agree the places where 
you talk about what 7252 already says should not use 2119 language.) I can 
maybe see the difference for 2.8, but the congestion-avoidance stuff in 2.9 
seems as appropriate for 2119 language as most anything else in the draft.

(To be clear, I'm

[Gen-art] Gen-ART LC Review of draft-ietf-core-groupcomm-21

[Ben Campbell]

(Oops, I screwed up the CC list the first try. Please send any replies to this 
distribution. Apologies for the repeat.)

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-core-groupcomm-21
Reviewer: Ben Campbell
Review Date: 2014-08-14
IETF LC End Date: 2014-08-14
IESG Telechat date: 

Summary: This draft is not ready for publication as an informational RFC. It 
has some significant issues, detailed below.

 Major issues:

-- The draft contains significant material that I do not believe is appropriate 
for an informational RFC, at least without some clear explanations about why it 
appears. It purports to clarify the normative stuff in RFC 7252 concerning 
multicast, but it does quite a bit more than that.

Section 2.7 defines protocol, in the form of a RESTful methods and attributes 
to manage multicast group membership.I agree in some cases it makes sense for 
an informational RFC to define protocol. A common example is when we want to 
document a proprietary protocol for some reason. As written, this does not seem 
to fall unto such a case. If the authors and working group believe it does, it 
would be helpful to add text explaining that, and how the reader should 
interpret the section. (I recognize that this interface is optional--but I 
don't think making it optional changes whether it should be standards track.)

In addition to that, the draft contains quite a bit of guidance that might be 
more appropriate BCP. For example, there is guidance here where not following 
it might do harm to the network. Additionally, I don't see how anyone could 
expect to achieve interoperability the multicast features of RFC 7252 without 
understanding this draft.  (I have to wonder why RFC 7252 did not have a 
normative dependency on this draft.)

-- The security aspects of group CoAP are pretty bad. To its credit, the draft 
does a pretty good job of calling that out, and that work is in progress to 
improve it. But I have to wonder if we would be better off not encouraging 
multicast CoAP at all until such improvements are available. Section 5.3 calls 
out some reasonable examples of mitigation approaches, but I am a little 
concerned at the guidance that one should worry about these for sensitive or 
safety-critical data. People are not good at knowing what data is sensitive 
until it gets used against them. I think this is especially true for IoT 
applications where we have less deployment experience.

Along those lines, the Pervasive Monitoring Considerations section (kudos for 
having one, btw), tries to balance application needs vs protecting information. 
But the smart-grid example seems to be a case where the two are really at odds. 
I am afraid people will interpret this along the lines of well, the smart-grid 
application requirements force me to send unprotected data all over the place, 
when I think the right answer is Group CoAP should not be used for this sort 
of application until we can protect the data.




 Minor issues:

-- 2.2, 5th paragraph: For sending nodes, it is recommended to use the IP 
multicast address literal in a group URI.

Can you elaborate on why? I can guess, but anytime we suggest using literal IP 
addresses rather than DNS names, it's worth elaborating.

-- 2.4:  ... if the resource being POSTed to has been designed to cope with 
the unreliable and lossy nature of IP multicast.

Can you elaborate on what it means to be designed to cope...? (Or reference 
something that does?)

-- 2.6:

I think the Resource Directory reference needs to be normative.  (I see the 
discussion of this from Barry's AD review, where the authors argued that the 
reference is optional for implementations. But our definition of normative 
references also includes things necessary to fully understand this draft. Fully 
understanding even optional features is part of that.)

-- 2.7.1, 2nd paragraph:

Does this imply a need to coordinate pre-configured group addresses to avoid 
collisions?

-- 2.7.2.1: 2nd 2 last paragraph:

Are there any scenarios where a missing port might be determined from DNS, 
rather than just assuming the default?

-- 2.7.2.6, 1st paragraph: This operation MUST only be used to delete or 
update group membership objects for which the CoAP client, invoking this 
operation, is responsible

Do I understand correctly that this replaces the entire set? Is it possible for 
two different clients to be responsible for two different subsets? If so, how?

-- 2.8 and (especially) 2.9:

Lack of 2119 language in the additional guidlines seems inconsistent with 
other parts of this draft that do use 2119 language. (I agree the places where 
you talk about what 7252 already says should not use 2119 language.) I can 
maybe see the difference for 2.8, but the congestion

[Gen-art] Gen-ART LC Review of draft-ietf-forces-model-extension-03

[Ben Campbell]

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-forces-model-extension-03
Reviewer: Ben Campbell
Review Date: 2014-08-08
IETF LC End Date: 2014-09-09

Summary: Nearly ready for publication as a proposed standard, but there are 
some issues that should be considered first, and some editorial issues that 
might also be worth consideration.

Note 1: I am not an expert in xml schema specifications. I hope assume others 
have reviewed the schema, and mechanically verified them. 

Note 2: I notice that the Adrian's AD review commented about the lack of 
working group review, while the shepherd writeup comments that the working 
group had a solid consensus on this draft. On the surface, those comments seem 
to conflict. (I don't expect the author to take any action on this)

Major issues: 

-- IDNits points out that this draft may need the pre-RFC5378 boilerplate, due 
to content from RFC 5812. It does appear to include substantial amounts of XML 
schema from 5812. While the publication date of 5812 post-dates RFC5378, there 
were many revisions of the draft form that pre-date 5378 by some time. So 
unless the author has gotten permission from all 5812 authors (and I note that 
author list changed several times prior to publication), this draft and any 
resulting RFC may well need the boilerplate.

Minor issues:

-- section 2.3, 3rd paragraph:

The 2119 language in this paragraph seems more like description of procedures. 
You really only need 2119 language when you want to constrain some choice an 
implementor might make. Also, in the two cases of MUST be ignored, please 
consider using active voice? (That is, who or what must ignore it?)

-- section 2.4, 2nd paragraph:

This also seems like a description of general procedures that doesn't really 
need 2119 language.

-- section 2.4, bulleted paragraph:

Is this similar to saying that eventBecomesEqualTo effectively becomes an 
eventChanged after achieving the target value? Once the value changes from the 
target by V or more, does it reset the becomesEqualTo trigger?

-- 2.6, 2nd paragraph: ... derivedFrom will always select the latest version.

What if a newer version of the parent is created after the child is defined? 
Can it cause backwards compatibility issues if the parent class changes out 
from under the child?

-- section 6:

The assertion that the changes in this draft have no effect on security is a 
bit of a red flag. This draft introduces new kinds of properties and events 
that can be expressed, as well as a change to the inheritance model. Are you 
sure none of those have a security impact? It would at least be good to 
mention, for each of these changes, why you think it does not affect the prior 
model security considerations.


Nits/editorial comments: 

-- Abstract, 2nd paragraph: 

Please expand LFP on first use.
s/ ... update RFC5812 ... / ... updates RFC5812 ...

-- section 1, first paragraph:

Please expand FEs on first use . (I know you did in the abstract, but the 
body and abstract should each be able to stand alone.)

-- section 1, 2nd paragraph, last sentence

Sentence appears to be missing one or more commas.

-- section 2.1, 2nd paragraph:  ... can be seen in the OpenFlow switch 1.1 ...

I assume you mean the OpenFlow1.1 specification, not any particular switch.

-- 2.1, paragraph 5:

The proximity of the description of figure 2 and the beginning of figure 1 may 
be confusing. I suggest moving figure 1 to immediately after it's description 
in the first paragraph of the section.

-- section 2.2, 2nd paragraph: ... allows optional to add ...

I suggest allows the optional addition or allows the option to add

-- section 2.2, paragraph after Figure 4: Additionally this document appends 
to the declaration of the AtomicType from Figure 5 to Figure 6 to allow default 
values to Atomic datatypes.

Sentence is difficult to parse.

-- section 2.3, 1st paragraph: 

2nd sentence is awkward. It seems to agree with previous sentence in spite of 
however. Also, what is antecedent of it's?

-- section 2.3, 2nd paragraph, first sentence:  With this extension is it 
allowed to define...

I suggest This extension allows the definition ...

-- section 2.4, first paragraph: ... when the value is exactly ...

s / is / becomes

-- section 2.4, last paragraph:

I can't parse take into account to use. Do you mean consider using...?

-- section 2.5, 1st paragarph:

By current model, do you mean prior to this update? Keep in mind that once 
this is published, the updated version will be the current one. Also, 
sent/received should be sent and received or sent or received.

-- 2.5, 2nd paragraph:

s / defines / specifies 

Also, what does it mean to target LFB properties. Do you mean refer to...?

-- Figure 13, caption:

Missing of after

[Gen-art] Gen-ART Telechat Review of draft-ietf-6man-multicast-addr-arch-update-07

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-6man-multicast-addr-arch-update-07
Reviewer: Ben Campbell
Review Date: 2014-08-05
IETF LC End Date: 2014-07-02
IESG Telechat date: 2014-08-07

Summary: Ready for publication as proposed standard. All of my last-call 
comments from version 05 have been addressed.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06

[Ben Campbell]

Hi Lucy,

I apologize for the late response. I somehow missed your mail when it came in 
originally. Comments inline. I've deleted sections where I don't have further 
comment.

Thanks!

Ben.

On Jul 15, 2014, at 3:18 PM, Lucy yong lucy.y...@huawei.com wrote:
 

[...]

 -- I suggest removing the 2119 language. Ignoring the general controversies 
 over whether informational RFCs should use 2119 language, I don't think it 
 fits for _this_ draft. In particular, all the small number of normative 
 language instances seems to be either statements of fact or restatements of 
 requirements that are defined elsewhere. These would all be better served 
 with descriptive language. 
 [Lucy] OK. I will change as you suggested.
 

The 2119 language has been removed, but you still have a reference to RFC 2119 
in the reference section.

[...]

 
 5.2 seems like the same gap as discussed in 5.1, just from a perspective of 
 CA role vs forwarding constraint. Handing around constraints vs roles seem 
 more like solution questions than requirements or architecture questions.
 [Lucy] One is assigned the role at AC that impacts the forwarding; another is 
 to convey or advertise the assigned AC role. Since these may relate to 
 different techniques used in L2VPN, it is good to keep them in different 
 sections. 
 

Okay

[...]

 Nits/editorial comments:
 
 -- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One
   role is Root and another is Leaf.
 
 Are these the same usages as defined in this document? If so, it might be 
 helpful to attribute these in the terminology section.
 [Lucy] We define Root AC and Leaf AC in terminology and use them in the 
 framework. Will that be OK?
 

My comment was that _this_ document defines the roles, but also says that MEF 
defines them. If those definitions are the same, then it would useful for the 
definitions in this draft to mention that the usage is the same as defined by 
MEF, or say in section 2.2. that MEF defines these terms the same way as this 
draft.

[...]

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-l2vpn-etree-frwk-07

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-l2vpn-etree-frwk-07
Reviewer: Ben Campbell
Review Date: 2014-08-05
IETF LC End Date: 2014-07-15
IESG Telechat date: 2014-08-07

Summary: Ready for publication as informational. All of the substantive 
comments from my last call review of version 06 have been addressed.


Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- References: 2119 language has been removed, but there's still a reference to 
RFC 2119.

-- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles...

This draft defines the AC roles in the terminology section. It would be helpful 
to mention if the MEF definitions are the same as used here, either in this 
section or in the respective terminology section entries.

-- 5.1, 1st sentence:

The change due to one of my previous comments renders the beginning of the 
sentence as  IP/MPLS L2VPN architecture has no distinction role on Attachment
   Circuit ... Should distinction be distinctive? If not, I'm not sure how 
to parse the sentence.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Last Call Review of draft-ietf-l2vpn-etree-frwk-06

[Ben Campbell]

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-l2vpn-etree-frwk-06
Reviewer: Ben Campbell
Review Date: 2014-07-14
IETF LC End Date: 2014-07-15

Summary: This draft is almost ready for publication as an RFC, but I have a few 
minor issues and editorial comments that may be worth consideration prior to 
publication.

Major issues:

None

Minor issues:

-- I suggest removing the 2119 language. Ignoring the general controversies 
over whether informational RFCs should use 2119 language, I don't think it fits 
for _this_ draft. In particular, all the small number of normative language 
instances seems to be either statements of fact or restatements of requirements 
that are defined elsewhere. These would all be better served with descriptive 
language. 

-- Section 4, paragraph after Table 1: If direct Layer 2 Leaf-to-Leaf 
communication needs to be prohibited, E-Tree should be used.

That sounds more like advocacy than architecture/framework. Do you mean to 
suggest that other potential solutions (if any) should not be used, or that 
E-Tree is somehow the best solution?  Or did you mean to say E-Trees are 
appropriate for whenever...?

-- Similarly, 2 paragraphs down: An E-Tree service can meet these use case 
requirements.

That also sounds like advocacy. This draft doesn't seem to do a requirements 
analysis for those use cases, beyond an assumption that they need inter-leaf 
isolation at Layer 2. Something to the effect of E-Trees can meet the common 
requirement to avoid the exchange of frames between Leaf CAs. would be more 
appropriate.

-- 5.1 and 5.2:

5.2 seems like the same gap as discussed in 5.1, just from a perspective of 
CA role vs forwarding constraint. Handing around constraints vs roles seem more 
like solution questions than requirements or architecture questions.

-- 5.3, First sentence:

The first sentence seems like yet a further restatement of the issue from 5.1 
and 5.2.  (The rest of the section seems reasonably distinct from the others.)

-- Security Considerations:

The security considerations mostly say that e-trees have to act like e-trees. I 
think there is room for more discussion. Are the e-tree rules sufficient for 
scenarios where inter-leaf isolation is critical for security reasons? Does it 
remove needs for higher layer protections? (I hope not.) The guidance to use 
IPSec if additional security is required is not entirely satisfying here--how 
would an higher layer protocol know whether or not it had a fully protected 
path?

Are there trust issues between PEs? Can one PE assume that another will enforce 
the leave/root constraints? Can it trust that the other PE has the same idea of 
what should be a leaf vs root? Is there a need for one PE to determine if 
another supports E-Trees at all?


Nits/editorial comments:

-- 2.2, 4th paragraph: Furthermore, MEF also defines AC roles. One
   role is Root and another is Leaf.

Are these the same usages as defined in this document? If so, it might be 
helpful to attribute these in the terminology section.

-- 2.3, 2nd paragraph: ... distinct differentiation for multicast groups in 
one VPN.

I suggest ... distinct differentiation among multicast groups in the same VPN.

-- 3: Figure 1

The figure is two pages from the paragraph that describes it. I suggest moving 
Figure 1 to either before or after the first paragraph in the section.

-- 3, first paragraph This implies that an Ethernet frame from CE01, CE02, etc 
will be treated as a frame originated from a Root AC; a frame
   from CE03, CE04, etc will be treated as a frame originated from a Leaf AC.

Treated by what? (Consider restating in active voice).

-- 3, last paragraph before Figure 1:  A VSI on a PE corresponds to an E-Tree 
instance ...

This can be read to imply a 1-to-1 cardinality between A VSI on a PE and an 
E-Tree instance. I don't think that is intended.

Also, is an E-Tree instance the same thing as and E-Tree service instance, 
as mentioned elsewhere?

-- Section 4, paragraph after Table 1:

Can you provide a reference and/or expansion for LTE X2?  (I think LTE may be 
on the well-known abbreviation list, but I'm not sure about X2).

-- Section 4, last paragraph:

Unless you mean to say that broadcast video is a significant driver for this 
work, this paragraph seems off topic.

-- Section 5 and subsections

Section 5  needs additional proof reading for missing articles and 
singular/plural mismatches.

-- Normative References:

The two IEEE references seem more like informative rather than normative ones.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05

[Ben Campbell]

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

Thanks!

Ben.

On Jul 8, 2014, at 1:14 AM, mohamed.boucad...@orange.com 
mohamed.boucad...@orange.com wrote:

 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
 
 -Message d'origine-
 De : Ben Campbell [mailto:b...@nostrum.com]
 Envoyé : lundi 7 juillet 2014 23:29
 À : BOUCADAIR Mohamed IMT/OLN
 Cc : draft-ietf-6man-multicast-addr-arch-update@tools.ietf.org; gen-
 a...@ietf.org Team (gen-art@ietf.org); i...@ietf.org list
 Objet : Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-
 arch-update-05
 
 Hi,
 
 Please see inline (I deleted parts that don't appear to need further
 comment)
 
 On Jul 4, 2014, at 8:44 AM, mohamed.boucad...@orange.com wrote:
 [...]
 
 -- 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.
 
 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.
 
 
 
 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.)
 
 [...]
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05

[Ben Campbell]

Hi,

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

On Jul 4, 2014, at 8:44 AM, mohamed.boucad...@orange.com wrote:
[...]
 
 -- 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. 

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.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05

[Ben Campbell]

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.boucad...@orange.com 
mohamed.boucad...@orange.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.)  

[...]
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-6man-multicast-addr-arch-update-05

[Ben Campbell]

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.




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Fwd: Gen-ART Telechat Review of draft-kelsey-intarea-mesh-link-establishment-06

[Ben Campbell]

Oops, I accidentally sent the first attempt to gen-art-private:

Begin forwarded message:

 From: Ben Campbell b...@nostrum.com
 Subject: Gen-ART Telechat Review of 
 draft-kelsey-intarea-mesh-link-establishment-06
 Date: June 23, 2014 at 2:31:56 PM CDT
 To: draft-kelsey-intarea-mesh-link-establishment@tools.ietf.org
 Cc: Private Gen-ART Mailing List gen-art-priv...@ietf.org, i...@ietf.org 
 list i...@ietf.org
 
 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 wait for direction from your document shepherd
 or AD before posting a new version of the draft.
 
 Document: draft-kelsey-intarea-mesh-link-establishment-06
 Reviewer: Ben Campbell
 Review Date:  2014-06-23
 IESG Telechat date: 2014-06-26
 
 Summary: This draft is ready for publication as a proposed standard. My 
 comments on version 05 at IETF last call have been addressed to my 
 satisfaction.
 
 
 Major issues:
 
 None.
 
 Minor issues:
 
 None.
 
 Nits/editorial comments:
 
 None.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review

[Ben Campbell]

(disclaimer: This landed in my inbox on the gen-art list, so I'm responding 
from that perspective. I was _not_ involved in the review. I haven't followed 
the draft, so my comments may be completely off-base due to lack of context.)

On May 7, 2014, at 10:55 AM, Dale R. Worley wor...@ariadne.com wrote:

 [as an author]
 
 From: DRAGE, Keith (Keith) keith.dr...@alcatel-lucent.com
 
 13.  User Agent Behaviour
 
   The User Agent (UA) MUST produce a reasonable rendering
   regardless of the combination of URIs (of any schemes) in the
   Alert-Info header field.
 
 This MUST is not well defined to be implementable. How can
 conformance or violation of this requirement can be tested? I
 suggest you avoid using RFC 2119 language here.
 
 The authors agree and will change the MUST to must.
 
 Can we avoid lower case forms of RFC 2119 language as this just
 leaves the reader with the question as to whether there was an
 editing error.
 
 I would suggest The User Agent (UA) is expected to produce...
 
 It's a tricky matter.  What we really want is MUST, that this is a
 constraint on the UA, particularly that it must be prepared to cope
 with any sequence of syntactically-correct URIs, and it must do
 something that is reasonable in the eyes of the user.  The problem is
 that this criterion isn't testable in any absolute way, despite the
 fact that there are a large number of actions that everybody would
 agree are violations.

It may not be absolutely testable, but one can do some degree of testing by 
supplying weird URLs and seeing what happens. If people have a sense of a 
large number of actions that 'everybody' would agree are violations, can the 
language be recast in terms of those actions?

 
 So the Gen-Art reviewer didn't like MUST.  Unfortunately, he didn't
 suggest an alternative.
 
 As far as I can tell, must is fairly common in RFCs.  Over half the
 RFCs from 6000 to 6999 use must (outside of boilerplate language).
 Many of them use it in a more-or-less normative way.
 
 RFC 2119 gives this guidance, for what it's worth:
 
   6. Guidance in the use of these Imperatives
 
   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for

If an implementation does things unreasonable in the eyes of the user when 
receiving a perfectly valid URL, is that not an interop problem?

 
 At this time, I prefer must over MUST, but I prefer MUST over
 is expected to or anything that is similarly indirect.
 
 Dale
 
 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-radext-dtls-11

[Ben Campbell]

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-radext-dtls-11
Reviewer: Ben Campbell
Review Date: 2014-04-30
IETF LC End Date: 2014-04-30

Summary: This draft is almost ready for publication as an experimental RFC. 
There are a few minor issues that should be considered prior to publication.

Note: I as assigned version 10, but 11 came out as I was working on the review. 
This review is for version 11.

Note: This review is incremental to an early (pre-submission) review I did for 
versions 7 and 8. Any comments from that review not repeated here have been 
addressed either in the text or in correspondence.

Major Issues:

None.

Minor Issues:

-- 3.2, last paragraph:

I'm still confused about how this is a bid down attack. 

[The author replied that, when secure and insecure packets are allowed from the 
same client, a
malicious or broken client can choose the insecure one.  That's bad,
when the intent is to use DTLS.]

While I agree that's bad, I don't see how it qualifies as a bid-down attack. 
One assumes a malicious client already has access to the cleartext messages. 
Are we talking about an MiTM client? Are there attacks where a third party 
can induce the client or server to send unprotected packets, even with no 
signaled negotiation? I can imagine one for the specific case where a node 
falls back to clear text if DTLS packets fail; an attacker could induce 
failures for DTLS packets, but that is covered elsewhere.
Comment not addressed.

-- 6, 2nd and 3rd paragraph:

The RECOMMENDation to allow administrative entry of keys and to derive keys 
from a PRNG seem contradictory.


[The author responded that it's a requirement that implementors allow 
administrators to enter
strong keys. but I don't get that from the text, which both RECOMMENDS that the 
interface allow people to enter human readable hex strings, and that keys 
should be derived from a PRNG instead of letting administrators make up keys. 
How can it be both?

I don't see how an interface could prevent administrators from entering better 
keys. Perhaps the intent is to offer or interface with tools for random 
generation, or to scan entered keys for things with insufficient entropy?]
 
-- 10.3, 2nd paragraph:

This is redundant and inconsistent with previous normative requirements in 
5.1.1. 

[Author replied that it's worth reiterating security issues, and that the 
sections were now consistent. But there's still conflicting normative 
statements here. 5.1.1 says implementations SHOULD monitor number of sessions. 
This section says MUST.

And I still assert that, even if the security issue is worth reiterating, it 
should not be reiterated _normatively_.  Doing so creates confusion about which 
text is authoritative, especially when they conflict. Even if they don't 
conflict now, it's easy for future updates to accidentally create conflicts.]

-- 10.4 5th and 6th paragraphs:

Paragraph 5 says credentials should be manually configured, and strongly tied 
to a host name. It is not clear to me from the text whether using a certificate 
(perhaps issued by a trusted CA) to bind the credentials to the hostname is 
permissible. The use of manual would seem to disallow that. But paragraph 6 
talks about configuring trusted CAs.

[The author commented that dynamic discovery was out of scope--but I don't 
think anything about this implies dynamic discovery. (e.g. configuring a client 
to talk to foo.example.com, then using using a CA to validate that a server 
certificate to ensure that that server really is foo.example.com is not the 
same as dynamic discovery.]

-- 10.5, last paragraph:

This seems to be making normative statements about RADIUS/UDP. It's not 
appropriate to make those statements here unless this draft normatively updates 
RADIUS/UDP. (Which and experimental rfc shouldn't do.)

Nits and Editorial Comments:


-- idnits reports: The document seems to use 'NOT RECOMMENDED' as an RFC 2119 
keyword, but
 does not include the phrase in its RFC 2119 key words list.



-- 6.1, first paragraph: subsystem does not need to multiple
   multiple sessions on one socket

I think one instance of multiple was intended as a different word?



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-dtls-11

[Ben Campbell]

Thanks for the quick response. Comments inline, with sections that do not 
appear to need further content removed.


On Apr 30, 2014, at 8:38 PM, Alan DeKok al...@deployingradius.com wrote:

 Ben Campbell wrote:
 -- 3.2, last paragraph:
 
 I'm still confused about how this is a bid down attack. 
 
 [The author replied that, when secure and insecure packets are allowed from 
 the same client, a
 malicious or broken client can choose the insecure one.  That's bad,
 when the intent is to use DTLS.]
 
 While I agree that's bad, I don't see how it qualifies as a bid-down attack. 
 One assumes a malicious client already has access to the cleartext messages. 
 Are we talking about an MiTM client? Are there attacks where a third party 
 can induce the client or server to send unprotected packets, even with no 
 signaled negotiation? I can imagine one for the specific case where a node 
 falls back to clear text if DTLS packets fail; an attacker could induce 
 failures for DTLS packets, but that is covered elsewhere.
 Comment not addressed.
 
  The point of DTLS isn't just to protect from malicious clients.  It's
 to protect clients and servers from malicious third parties.  Those
 parties can read all RADIUS/UDP traffic now.  They will not be able to
 read RADIUS/DTLS traffic.
 
  These third parties could actively cause DTLS to fail, and force the
 client and server to use an insecure transport.  This sounds like a
 downbidding attack to me.
 
  Do you have another definition for downbidding which you are using?
 Or would another term be acceptable here?

I tend to think of a bid-down attack as one in which security parameters are 
negotiated, and an attacker removes a more secure security mechanism to force 
endpoints to fall back to a less secure. But an outright failure of the DTLS 
handshake is more likely something less subtle--an outright impersonation 
attack, or a MiTM modification of content.

 
 -- 6, 2nd and 3rd paragraph:
 
 The RECOMMENDation to allow administrative entry of keys and to derive keys 
 from a PRNG seem contradictory.
 
 
 [The author responded that it's a requirement that implementors allow 
 administrators to enter
 strong keys. but I don't get that from the text, which both RECOMMENDS that 
 the interface allow people to enter human readable hex strings, and that 
 keys should be derived from a PRNG instead of letting administrators make up 
 keys. How can it be both?
 
  Because the administrators have to enter the same key on both the
 client and server.  If one machine auto-generated a secure pseudo-random
 number, it would still have to be transported to the other, and entered
 in an administration UI... via the method suggested in the document.

I think it's reasonable to say that good administration practices involve 
random key generation, and that the interface should not prevent the entry of 
arbitrary hex strings. But the text says things like 

When creating keys, it is RECOMMENDED that keys be derived from a 
cryptographically secure pseudo-random number generator (CSPRNG) instead of 
allowing administrators to invent secure keys on theur  [sic--add that as an 
editorial comment] own.  

That part seems to say explicitly that the implementation shouldn't let admins 
enter their own keys. (Which makes the bit about entering the key on the peer 
seem difficult.)

 
 I don't see how an interface could prevent administrators from entering 
 better keys. Perhaps the intent is to offer or interface with tools for 
 random generation, or to scan entered keys for things with insufficient 
 entropy?]
 
  Have you ever entered a password in a poorly designed on-line form?
 special characters like !, %, , $, etc. are not allowed.  Vendors do
 this today with RADIUS systems, for the shared secret.  Such idiocy
 should be discouraged.

I accept that, and my real concern is not about allowing the admin to enter 
arbitrary hex strings. My concern is that it also says the admin should not be 
able to enter their own keys (see above.) How do you expect the interface to 
prevent the use of invented on their own keys, while allowing arbitrary hex 
strings?

[...]

 -- 10.4 5th and 6th paragraphs:
 
 Paragraph 5 says credentials should be manually configured, and strongly 
 tied to a host name. It is not clear to me from the text whether using a 
 certificate (perhaps issued by a trusted CA) to bind the credentials to the 
 hostname is permissible. The use of manual would seem to disallow that. 
 But paragraph 6 talks about configuring trusted CAs.
 
 [The author commented that dynamic discovery was out of scope--but I don't 
 think anything about this implies dynamic discovery. (e.g. configuring a 
 client to talk to foo.example.com, then using using a CA to validate that a 
 server certificate to ensure that that server really is foo.example.com is 
 not the same as dynamic discovery.]
 
  I'm not sure what the objection here is.
 
  The point is that when a client connects to a server

Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-v6ops-64share-09

[Ben Campbell]

Hi,

Version 10 addresses all of my comments on version 09.

Thanks!

Ben.

On Apr 1, 2014, at 6:14 PM, Vízdal Aleš ales.viz...@t-mobile.cz wrote:

 Dear Ben, all,
  
 Many thanks for your review. An updated I-D has been submitted.
  
 Please see inline.
  
  -Original Message-
  From: Ben Campbell [mailto:b...@nostrum.com]
  Sent: Friday, March 21, 2014 8:25 PM
  To: draft-ietf-v6ops-64share@tools.ietf.org
  Cc: gen-art@ietf.org Team (gen-art@ietf.org)
  Subject: Gen-ART LC/Telechat Review of draft-ietf-v6ops-
  64share-09
 
  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 wait for direction from your document shepherd or AD
  before posting a new version of the draft.
 
  Document: draft-ietf-v6ops-64share-09
  Reviewer: Ben Campbell
  Review Date: 2014-03-21
  IETF LC End Date: long time ago
  IESG Telechat date: 2014-03-27
 
  Note: I somehow missed this assignment at last call time.
  Therefore this review serves as both a last call and an IESG
  telechat review.
 
  Summary: This draft is mostly ready for publication as an
  informational RFC. I have a few editorial comments that might
  be worth considering prior to publication.
 
  Major issues: None
 
  Minor issues: None
 
  Nits/editorial comments:
 
  -- Section 1, paragraph 1:
 
  Can you elaborate on what it means to extend The prefix to
  a LAN link? Are we talking about routing IPv6 traffic from
  other local devices (on the LAN) across the 3gpp link, for
  example, like one might do when tethering devices to a phone
  or mobile hotspot?
  
 Yes, this is the case.
  
  Can you offer a reference for the 3GPP specification?
 
  Can you offer a reference for the 3GPP specification?
  
 Done.
  
  -- paragraph 2: This can be achieved by receiving the Router
  Advertisement (RA) [RFC4861] announced globally unique /64
  IPv6 prefix from the 3GPP radio interface and then
  advertising
 
  What does these things. The UE?
  
 Yes, the UE. Ref to the UE has been added.
  
  Please expand RA on first mention.
  
 Done.
  
 
  -- section 3, R-1:
 
  Please expand SLAAC on first use.
  
 Done.
  
  -- section 4.2, 1st paragraph: The 3GPP RA /64 prefix
  information is used to configure NDP on the LAN and assigns
  itself an address on the LAN link.
 
  The prefix information assigns itself an address? I don't
  think that's what you mean to say.
  
 Fixed, please review.
  
  -- section 4.2, step 7:
 
  Please expand DAD on first use.
  
 Done.
  
 Cheers,
 Ales
 
 Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při 
 sjednávání smluv, jsou uvedeny zde http://www.t-mobile.cz/zasady. Není-li v 
 zásadách uvedeno jinak, nepředstavuje tato zpráva konečný návrh na uzavření 
 či změnu smlouvy ani přijetí takového návrhu. The communication principles 
 which T-Mobile Czech Republic a.s. applies when negotiating contracts are 
 defined here http://www.t-mobile.cz/principles. Unless otherwise stated in 
 the principles, this message does not constitute the final offer to contract 
 or an amendment of a contract or acceptance of such offer.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Early Review of draft-hoffman-xml2rfc-04

[Ben Campbell]

Hi, thanks for the quick response. Comments inline; sections that do not seem 
to need further comment are deleted, and marked with [...]

Thanks!

Ben.

On Apr 5, 2014, at 8:10 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:

[...]

 
 -- Section 1, paragraph 2:
 
 I find it confusing that we have two drafts in parallel, one for V2 that is 
 obsoleted by this draft, and this draft for V3. With this draft copying much 
 of V2 forward, which is authoritative?
 
 Both. the v2 draft is authoritative for that version of the format (which is 
 still in use); this draft will be definitive for v3 when v3 is implemented. 
 Unlike a regular protocol, this format is not going to be immediately 
 implemented when the draft goes to the RFC Editor.

It's not clear to me that updates to regular protocols always get immediately 
implemented, at least not to the point of immediately replacing older version.  
Especially we we are talking about formally incrementing version numbers.

I think my real question is whether V3 really obsoletes V2 in the usual sense. 
Do we allow further updates (e.g. an updates draft with bug fixes) to V2 once 
it becomes an RFC? If so, do those updates, assuming they impact common 
parts, affect V3? Would that be automatic, or would V3 require a parallel 
update? Do we intend to allow V2 to evolve independently of V3?

 
 -- 1.1, entry for tident
 
 THANK YOU I think faking indented text using the list work around was 
 one of the most annoying things about previous versions.
 
 Hrm; I'm not used to seeing that in GenArt reviews. :-)
 
 And, to be fair, lots of the new features have been suggested by many people 
 on the RFC Editor's design team and in the bigger community.

Okay, change that to THANK Y'ALL

 
 --2.2:
 
 Can I have more than one of any given address sub-element? If so, how should 
 it render?
 
 Yep; unclear. There are a lot of things in this draft (and the in the v2 
 draft) where the rendering is undefined. We may or may not clarify those in 
 the doc before we are finished; if not, it will be up to the programmers.

I accept that different rendering decisions might be okay. But would you also 
leave whether a specific sub-element can be repeated to the implementors? Seem 
like that could lead to xml2rfc code that is correct for one processor but 
incorrect for another.

[...]

 
 -- 2.7:
 
 It seems like b (and also i)  is just as much format dependent as things 
 like width. Wouldn't something like em be more useful for this purpose, 
 where you have an abstract concept of emphasis that can be rendered 
 differently for different formats?
 
 In some senses, yes, but given that we know the main expected types of 
 non-canonical output (HTML, PDF, EPUB), they all handle bold and italic and 
 fixed-width fonts just fine. There are plenty of people who would think that 
 emphasis means bold, and plenty who would think it means italic.
 
 This seems like a place where our use cases are different than those for 
 HTML, where markup is usually rendered by browsers that have similar font 
 display capabilities.
 
 No, our use cases very much align with HTML here: that's a design choice.

Well, HTML _does_ have em. I realize it's not very useful in HTML, since you 
rarely render HTML to a format that can't do bold or italics. But to test the 
assertion, do you consider typesetting a common use case for HTML? Is it not 
one for xml2rfc?

 
 In particular, what happens to btext.b when rendered into ASCII text?
 
 Nothing. Just like today, there is a lot of formatting that is lost in the 
 text output.

There are some common conventions here; they just seemed to have fallen by the 
wayside. For example, a title of a long-format work gets italicized when that's 
supported, but underlined on an old fashioned typewriter. There are more modern 
simulations like _this_ and *this*.  

OTOH, I guess an ascii rendering processor could make those same choices for 
i and b as well as for em, so maybe I just countered my own argument. But 
from a typesetting perspective, abstractions like em allow one to separate 
the intent of the author (I want this to be emphasized) from the intent of 
the editor/publisher.(This is how our 'style' renders emphasis.)

 
 -- 2.9:
 
 Why does the cite attribute have different requirements than, say, xref? 
 In particular, why wouldn't I want to cite a reference in the current doc, 
 rather than a URL?
 
 It can do both: the URL can be a fragment that points to a reference in the 
 current doc.

How would you do that? Is there a way to construct a URL that points to an 
xml2rfc anchor?

 
 -- 2.9.1:
 
 How would one reference an auto generated anchor identifier? If it doesn't 
 exist until processing time...?
 
 Correct, so you can't. You can only use target attributes to named anchors.

If you can't reference an auto-generated anchor, why do you have them? What 
else do you do with anchors?

 
 --2.33.2
 
 Is it possible to continue numbering from a 

Re: [Gen-art] Gen-ART Early Review of draft-hoffman-xml2rfc-04

[Ben Campbell]

On Apr 7, 2014, at 2:42 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:

 Comment-on-comments below. I now have one new action item.
 
 --Paul Hoffman
 
 On Apr 7, 2014, at 11:37 AM, Ben Campbell b...@nostrum.com wrote:
 
 

[...]

 
 --2.2:
 
 Can I have more than one of any given address sub-element? If so, how 
 should it render?
 
 Yep; unclear. There are a lot of things in this draft (and the in the v2 
 draft) where the rendering is undefined. We may or may not clarify those in 
 the doc before we are finished; if not, it will be up to the programmers.
 
 I accept that different rendering decisions might be okay. But would you 
 also leave whether a specific sub-element can be repeated to the 
 implementors? Seem like that could lead to xml2rfc code that is correct 
 for one processor but incorrect for another.
 
 Nope. The format is the format: it allows multiple sub-elements, and it would 
 be wrong for a processor to reject an input based on that. It is probably 
 fine for a processor to not render them all, although it would be better if 
 it issued a warning. It would be best if we had rules for how processors 
 should render each entity, but we haven't gone to that level of detail yet.
 

Well, that was the original question--are multiple of the same sub-element 
allowed :-)

I guess a better followup question than how do you render it would be are 
there cases where multiples of the same sub-type clearly does or does not make 
sense according to RFC style.


 
 [...]
 
 
 -- 2.7:
 
 It seems like b (and also i)  is just as much format dependent as 
 things like width. Wouldn't something like em be more useful for this 
 purpose, where you have an abstract concept of emphasis that can be 
 rendered differently for different formats?
 
 In some senses, yes, but given that we know the main expected types of 
 non-canonical output (HTML, PDF, EPUB), they all handle bold and italic and 
 fixed-width fonts just fine. There are plenty of people who would think 
 that emphasis means bold, and plenty who would think it means italic.
 
 This seems like a place where our use cases are different than those for 
 HTML, where markup is usually rendered by browsers that have similar font 
 display capabilities.
 
 No, our use cases very much align with HTML here: that's a design choice.
 
 Well, HTML _does_ have em. I realize it's not very useful in HTML, since 
 you rarely render HTML to a format that can't do bold or italics. But to 
 test the assertion, do you consider typesetting a common use case for HTML? 
 Is it not one for xml2rfc?
 
 No to both.
 
 
 
 In particular, what happens to btext.b when rendered into ASCII text?
 
 Nothing. Just like today, there is a lot of formatting that is lost in the 
 text output.
 
 There are some common conventions here; they just seemed to have fallen by 
 the wayside. For example, a title of a long-format work gets italicized when 
 that's supported, but underlined on an old fashioned typewriter. There are 
 more modern simulations like _this_ and *this*.  
 
 OTOH, I guess an ascii rendering processor could make those same choices for 
 i and b as well as for em, so maybe I just countered my own argument.
 
 That was my first reaction. :-)
 
 But from a typesetting perspective, abstractions like em allow one to 
 separate the intent of the author (I want this to be emphasized) from the 
 intent of the editor/publisher.(This is how our 'style' renders emphasis.)
 
 In an ideal world where authors understood typesetting, yes. That's the world 
 I began work in 35 years ago. (Cue the DEC formatting language theme 
 music...) But that's not what is typical among IETF authors who are, not 
 surprisingly, often literal-minded and goal-oriented.

Okay, I give in on this one.

 
 
 
 -- 2.9:
 
 Why does the cite attribute have different requirements than, say, xref? 
 In particular, why wouldn't I want to cite a reference in the current doc, 
 rather than a URL?
 
 It can do both: the URL can be a fragment that points to a reference in the 
 current doc.
 
 How would you do that? Is there a way to construct a URL that points to an 
 xml2rfc anchor?
 
 blockquote cite=#anchorname, I believe.
 
 
 
 -- 2.9.1:
 
 How would one reference an auto generated anchor identifier? If it doesn't 
 exist until processing time...?
 
 Correct, so you can't. You can only use target attributes to named 
 anchors.
 
 If you can't reference an auto-generated anchor, why do you have them? What 
 else do you do with anchors?
 
 After the RFC is published, other documents can reference the anchor. 
 Currently, the document only specifies this for blockquote and cref, but 
 it has been mentioned for other elements as well.

I think this means that, at least for blockquote, even if you leave out anchor 
attribute in the xml, you will get whatever sort of identifier makes sense in 
the rendered output (e.g. an id attribute in HTML)? I read it to mean that the 
processor would auto generate

Re: [Gen-art] Gen-ART Early Review of draft-hoffman-xml2rfc-04

[Ben Campbell]

Okay on all topics save the one below.

Thanks!

Ben.

On Apr 7, 2014, at 4:34 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:

[...]

 
 -- 5, security considerations
 
 I wonder if the possibility of executable content existing in an RFC or 
 draft is worth mention here? For an extreme example, see RFC6716, 
 Appendix A. But more realistically, 2.5.5 mentions the possibility of 
 in-lined binary content, and 2.5.6 allows the identification of code in 
 a way that a naive processor implementation might take as an invitation 
 to interpret said code.
 
 Yup, and (as above) I added a paragraph about this.
 
 Also, does the need for a processor to potentially render binary content 
 in general (in-lined or otherwise) expand the attack surface over that 
 for previous versions of XML2RFC?
 
 Not in any way I can think of.
 
 For example (just thinking out loud), if a processor could insert JPEG 
 artwork, does it need to worry about buffer overflow attacks on the JPEG 
 format, as well as attacks on the xml itself? If so, does it matter if the 
 artwork was in-lined vs referenced? 
 
 Um, maybe. I'm not at all sure how to word a security consideration about 
 that that would be more useful than a processor should not be stupid when 
 doing includes.
 
 Just as a strawman example:
 
 Unlike previous versions, XML2RFC V3 allows the inclusion of potentially 
 binary content via the src attribute of the artwork element. Processor 
 implementors should bear in mind that such content may have vulnerabilities 
 of its own. For example, certain JPEG renderers have been vulnerable to 
 buffer-overflow attacks. An xml2rfc processor that allows the inclusion of 
 artwork in JPEG format might be subject to buffer overrun attacks on both 
 its XML parser and in its JPEG rendering code.
 
 It really depends on what you mean by binary. The v2 format supports 
 inclusion of files in a few places already; a malicious submitter could make 
 those files binary.

Were those files likely to be binary in normal usage? 

(I also note that the v2 security considerations are almost identical to the V3 
ones, except for a disclaimer that they are probably incomplete :-)  )

 Further, a processor doesn't render anything: it puts out files.

That's an interesting point that I hadn't considered. I think it's probably 
true most of the time, but not all the time. On minimal thinking, I can imagine 
a processor that converts artwork to some preferred format. Or maybe some sort 
of just in time render that combines xml processing with direct display or 
printing.

 So, at best, the advice is don't have a buffer overrun when including a file 
 that you might output, which seems dumb. I'm still open to adding a security 
 consideration, but I guess I feel it has to at least be marginally useful.

I still think it might be useful to say something to the effect of While most 
of these security considerations apply to the interpreting of XML and rendering 
into various output formats, implementors may find that they are interpreting 
things other than XML, and should remember that those things may have 
additional security considerations.

The situation that seems most worthy of mention is that, if someone writes a 
processor that pulls in other (perhaps downloadable) libraries, plug-ins, OS 
functions, etc to process input beyond the XML itself,  they may inherit any 
security issues of those things. I realize that's a true statement about 
computing in general--but it seems more relevant for V3 processors than for 
previous versions. The fact that people keep finding vulnerabilities in such 
architectures suggests that the horse is not quite dead.

Obviously, this is all personal opinion, and carries no more weight than those 
of any other commenter (and probably less than those who have actually been 
working on updating xml2rfc).



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Early Review of draft-hoffman-xml2rfc-04

[Ben Campbell]

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 comments
you may receive.

Document: draft-hoffman-xml2rfc-04
Reviewer: Ben Campbell
Review Date:  2014-04-03
IETF LC End Date: Not in last call

Note: This is an early review, rather than the usual Gen-ART review at IETF 
last call. The Gen-ART processes do not precisely apply.

Summary: This draft is on the right track. I have a few comments and questions 
that may or may not be worth consideration.

*** Major Issues: ***

None

*** Minor issues: ***

-- General:

There are a few to do items left in the draft.  (Not surprising for an early 
review.)

-- Section 1, paragraph 2:

I find it confusing that we have two drafts in parallel, one for V2 that is 
obsoleted by this draft, and this draft for V3. With this draft copying much of 
V2 forward, which is authoritative?

-- 1.1, entry for tident

THANK YOU I think faking indented text using the list work around was one 
of the most annoying things about previous versions.

--2.2:

Can I have more than one of any given address sub-element? If so, how should it 
render?

-- 2.5.3:

If height ought to be avoided, should it be deprecated?

Also, what's the unit for height?

(Same questions apply to width)

-- 2.5.5:

An example of how to use inlined graphics files might be helpful.

-- 2.5.6:

A generic code value might be useful. Otherwise, how do you expect these to 
be used? Syntax highlighting? I assume the processor should never actually try 
to interpret code based on the type attribute. (Are there security 
considerations there?)

-- 2.7:

It seems like b (and also i)  is just as much format dependent as things 
like width. Wouldn't something like em be more useful for this purpose, 
where you have an abstract concept of emphasis that can be rendered differently 
for different formats? This seems like a place where our use cases are 
different than those for HTML, where markup is usually rendered by browsers 
that have similar font display capabilities.

In particular, what happens to btext.b when rendered into ASCII text?

-- 2.9:

Why does the cite attribute have different requirements than, say, xref? In 
particular, why wouldn't I want to cite a reference in the current doc, rather 
than a URL?

-- 2.9.1:

How would one reference an auto generated anchor identifier? If it doesn't 
exist until processing time...?

-- 2.15.2

What is the format for Month? Must you write it out? Abbreviate? Number?)

-- 2.26

An example might be helpful

--2.33.2

Is it possible to continue numbering from a previous list?

-- 2.43.5

The text says that iprExtract is used to reference a specific section Can 
you elaborate on how? E.g. do you reference an anchor? Are you allowed to have 
more than one as-is section?

-- 2.44.2:

Why are numberless subsections disallowed? It's pretty common to see documents 
that have non-numbered sub-heads inside numbered sections.

-- 2.44.5:

The default for the TOC attribute is default? Does that mean the actual 
meaning of default is controlled elsewhere?

Also, is there a way to limit the depth for ToCs?

-- 2.45 (and subsections)

Should the seriesInfo name values match the table from 2.40?

-- 2.54:

Is it possible to select the symbol to be used for an unordered list?

-- 5, security considerations

I wonder if the possibility of executable content existing in an RFC or draft 
is worth mention here? For an extreme example, see RFC6716, Appendix A. But 
more realistically, 2.5.5 mentions the possibility of in-lined binary content, 
and 2.5.6 allows the identification of code in a way that a naive processor 
implementation might take as an invitation to interpret said code.

Also, does the need for a processor to potentially render binary content in 
general (in-lined or otherwise) expand the attack surface over that for 
previous versions of XML2RFC?


*** Nits/editorial comments: ***

-- 1, paragraph 3:

I find the paragraph a little confusing. Saying certain elements will not be 
used in text generation may be a bit overstated, in that the generation of 
metadata may well become part of the process of generating the final text. It 
might be more correct to say may not affect the rendering of the final text.  
(And in the case of the example of index generation, I see that the text of 
this draft has an imbedded index--so I assume the related elements _were_ used 
in generating the text.

-- 1.1:

Is the section on changes from V2 intended to remain in the final RFC? Often 
such sections are removed, but there is info in here (esp 1.1.1) that may be 
useful in the long run.

-- 1.1, bulleted list of changes:

I find the past tense a bit confusing. I assume that the list represents 
incremental differences from V2, but the past tense made me wonder if it was 
meant as ways that V2 is different than V3.  (I suspect

Re: [Gen-art] New Version Notification - draft-ietf-radext-ieee802ext-12.txt

[Ben Campbell]

(Adding Gen-ART, for the record)

This version looks good to me.

Thanks!

Ben.

On Mar 29, 2014, at 3:09 AM, Benoit Claise bcla...@cisco.com wrote:

 Ben, Jari,
 
 Final final check on your comment.
 
 Regards, Benoit
 A new version (-12) has been submitted for draft-ietf-radext-ieee802ext:
 http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802ext-12.txt
 
 
 The IETF datatracker page for this Internet-Draft is:
 https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext/
 
 Diff from previous version:
 http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ieee802ext-12
 
 Please note that it may take a couple of minutes from the time of submission
 until the htmlized version and diff are available at tools.ietf.org.
 
 IETF Secretariat.
 
 .
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-radext-ieee802ext-11

[Ben Campbell]

[Apologies, I wrote this up earlier in the week then seem to have failed to 
send it.]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-radext-ieee802ext-11
Reviewer: Ben Campbell
Review Date: 2014-03-25
IETF LC End Date:
IESG Telechat date: 2014-03-17


Summary: This draft is ready for publication as a proposed standard. All of my 
previous comments have been addressed in correspondence.

Major issues:

None

Minor issues:

none

Nits/editorial comments:

-- While by no means a show stopper, I think it might be helpful to add a 
little of the explanation that the authors offered in email to address my 
original questions about sections 2.1 and 2.2.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10

[Ben Campbell]

I'm satisfied with the responses. I think it would not hurt to add some of the 
explanations from the various emails into the draft, but that's by no means a 
show stopper.

Thanks!

Ben.

On Mar 26, 2014, at 7:17 AM, Bernard Aboba bernard_ab...@hotmail.com wrote:

 In 802.1X-2010, the EAP Key Name is  actually needed to calculate the session 
 keys. So if it is unavailable, the NAS won't be able to decrypt traffic. 
 Therefore treating the Accept as a Reject is probably the only viable option.
 
 On Mar 26, 2014, at 5:42 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:
 
 
 I don't think there is anything that needs to be done for 2.2. It is
 a normal capability exchange type of mechanism.
 
 The text is IMHO clear:
 in situations where the Attribute is required to provision service..
 
 Then the lack of EAP-Key-Name means the service cannot be provisioned
 and the NAS can safely interpret that as an Access-Reject, when 
 appropriate by the deployment.
 
 NAS doesn't include the attribute if it is not needed. And if it does,
 the current text allows still accepting the service regardless the
 lack of the attribute in the Access-Accept.
 
 
 - Jouni
 
 
 On Mar 26, 2014, at 8:55 AM, Jari Arkko jari.ar...@piuha.net wrote:
 
 Thanks for the review. I did not see a response or change regarding 2.1 or 
 2.2. Does this need to be addressed? Authors?
 
 Jari
 
 On Feb 27, 2014, at 9:08 PM, Benoit Claise bcla...@cisco.com wrote:
 
 Dear authors,
 
 Can you please follow up on that one.
 
 Regards, Benoit
 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-radext-ieee802ext-10
 Reviewer: Ben Campbell
 Review Date: 2014-01-31
 IETF LC End Date: 2014-02-04
 
 Summary: This draft is almost ready for publication as a standards track 
 RFC. I have a small number of minor comments that may be worth 
 considering prior to publication.
 
 Major issues: None
 
 Minor issues:
 
 -- 2.1, last paragraph:
 
 Does the last sentence imply Allowed-Called-Station-Id actually should 
 (or SHOULD) not be used in non-wireless scenarios? (I note that the 
 Network-Id-Name section talks about how 802.1X NID-Names should not be 
 included in Called-Station-Id, but rather put in Network-Id-Name. Does 
 that apply here as well?
 
 -- 2.2, last paragraph: Since a NAS will typically only include a 
 EAP-Key-Name Attribute in an Access-Request in situations where the 
 Attribute is required to provision service, if an EAP-Key-Name Attribute 
 is included in an Access-Request but is not present in the Access-Accept, 
 the NAS SHOULD treat the Access-Accept as though it were an 
 Access-Reject. 
 
 Is there a backwards compatibility issue? What if a NAS sends the field 
 to a server that doesn't implement this draft? Is there an assumption 
 that a NAS that supports this draft will only work with a server that 
 also supports it?
 
 Or more to the point, is the ...typically only include...where 
 required... strong enough to require a normative SHOULD? Seems like this 
 would discourage the inclusion of EAP-Key-Name in the non-typical case of 
 it _not_ being required. Is that the intent?
 
 Nits/editorial comments:
 
 -- section 2.8:
 
 It might be worth expanding EAPoL
 
 
 
 .
 
 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art
 
 
 ___
 Gen-art mailing list
 Gen-art@ietf.org
 https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC/Telechat Review of draft-ietf-v6ops-64share-09

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-v6ops-64share-09
Reviewer: Ben Campbell
Review Date: 2014-03-21
IETF LC End Date: long time ago
IESG Telechat date: 2014-03-27

Note: I somehow missed this assignment at last call time. Therefore this review 
serves as both a last call and an IESG telechat review.

Summary: This draft is mostly ready for publication as an informational RFC. I 
have a few editorial comments that might be worth considering prior to 
publication.

Major issues: None

Minor issues: None

Nits/editorial comments:

-- Section 1, paragraph 1:

Can you elaborate on what it means to extend The prefix to a LAN link? Are we 
talking about routing IPv6 traffic from other local devices (on the LAN) across 
the 3gpp link, for example, like one might do when tethering devices to a phone 
or mobile hotspot?
Can you offer a reference for the 3GPP specification?

Can you offer a reference for the 3GPP specification?

-- paragraph 2: This can be achieved by receiving the Router Advertisement 
(RA) [RFC4861] announced globally unique /64 IPv6 prefix from the 3GPP radio 
interface and then advertising

What does these things. The UE?

Please expand RA on first mention.

-- section 3, R-1:

Please expand SLAAC on first use.

-- section 4.2, 1st paragraph: The 3GPP RA /64 prefix information is used to 
configure NDP on the LAN and assigns itself an address on the LAN link.

The prefix information assigns itself an address? I don't think that's what you 
mean to say.

-- section 4.2, step 7:

Please expand DAD on first use.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-netext-pmip6-qos-11

[Ben Campbell]

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-netext-pmip6-qos-11

Reviewer: Ben Campbell
Review Date: 2014-03-20
IETF LC End Date: 2014-03-26

Summary: This draft is on the right track, but there are issues that need to be 
resolved prior to publication.


*** Major issues:

-- section 3, 1st paragraph: The access and the home network in the Proxy 
Mobile IPv6 domain are assumed to be DiffServ enabled, with every network node 
in the forwarding path for the mobile node’s IP traffic being Diffserv 
compliant.  The per-hop behavior for providing differential treatment based on 
the DiffServ marking in the packet is assumed to be consistent throughout the 
Proxy Mobile IPv6 domain.

That’s a really big assumption. Is the scope of this draft limited to 
situations where an operator controls the entire forwarding path? If so, that 
might be worth an applicability statement. 

Are there any implications for DSCP marking across the PMIP tunnel that should 
be discussed?(e.g. RFC2983)?


*** Minor issues:

-- Section 1, first paragraph:  Current standardization effort considers 
strong QoS classification and enforcement for cellular radio access 
technologies.

 What efforts? Can you reference something? Or do you mean this document?

-- 1, 2nd to last paragraph, last sentence:

Much of this draft seems fairly 3GPP specific. Do you expect it to be used by 
non-3GPP operators? 

-- 2.2, GBR: It is assumed that the network reserves the resources for 
supporting the GBR parameter.

Can this be more precise than the network? Is this assumed to be useful 
across the network between the LMA and MAG? How might one express a per-flow 
GBR in DSCP?

-- 2.2, Service Identifier:

RFC5149 seems like it should be a normative reference, but it’s listed as 
informational.

-- 3, 1st paragraph The Quality of Service support in Proxy Mobile IPv6 
specified in this document is based on the Differentiated-Services 
architecture...

That seems a little misleading. The list of QoS attributes seems very much 
based on 3GPP mobile data network architectures.

-- 3: 3rd paragraph:

Can you insert definitions or references for charging profile and subscriber 
profile?

-- 3, paragraph before figure 1: The signaling related to QoS services is 
strictly between the mobility entities and does not result in per-flow state, 
or signaling to any other node in the network.

I am confused by the assertion that QoS signaling does not result in per-flow 
state, as it seem to specify several per-flow attributes that certainly create 
per-flow state.

-- 4.2.1, general:

I'm concerned that the QoS requests are per-session, but there are attributes 
that can effect more than one mobile session. This seems error prone. It seems 
like you could easily get a conflicting per-mobile-node requests on different 
sessions that effect the same mobile node.

Does  Per-MN-Agg-Max-DL-Bit-Rate really need a resolution of bits per second? 
With a 32 bit field, this limits you to expressing values up to the 4 gig 
range.  (Maybe I am more optimistic than the authors about the future of mobile 
network bandwidth?)  [This applies to all of the various bit-rate expressions.]


-- 4.2.1, last paragraph before packet format diagram:

There could be multiple operators involved here, couldn't there? Is there an 
assumption that they have a shared idea of this policy? Seems like there could 
be unexpected side effects if not.

-- 4.2.3, last paragraph before packet diagram:

Should the per mobile node version also say this?

- 4.2.3, Service Flag

Rather than have a modifier that turns a per-session attribute into something 
bigger, wouldn't it be better to a separate attribute type for controlling all 
sessions in a service at once? What if you get disagreeing attributes on 
different sessions?

-- 4.2.3, (E) flag : When the (E) flag is set to a value of (0), then there 
is no special effect on the receiver

No special effect is vague. Pleased describe the expected behavior when E is 
not set. [Issue appears in multiple times.]

-- 4.2.5, priority levels: Values 1 to 8 should only be assigned for services 
that are authorized to receive prioritized treatment within an operator domain.

Can you elaborate on the meaning of that? Are we assuming a single operator 
domain?

Values 9 to 15 may be assigned to resources that are authorized by the home 
network and thus applicable when a mobile node is roaming.

Does this imply two separate independent ranges? Is 8 always higher priority 
than 9? That is, are all mobile operator priorities higher than home network 
priorities?

-- 4.2.5, Premption-Capability and Preemption-Vulnerablity

Can PC and PV deadlock? Seems odd to have both.

-- 4.2.6:

How is Aggregate-Max-DL-Bit-Rate used with no traffic selector

[Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10

[Ben Campbell]

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-radext-ieee802ext-10
Reviewer: Ben Campbell
Review Date: 2014-01-31
IETF LC End Date: 2014-02-04

Summary: This draft is almost ready for publication as a standards track RFC. I 
have a small number of minor comments that may be worth considering prior to 
publication.

Major issues: None

Minor issues: 

-- 2.1, last paragraph:

Does the last sentence imply Allowed-Called-Station-Id actually should (or 
SHOULD) not be used in non-wireless scenarios? (I note that the Network-Id-Name 
section talks about how 802.1X NID-Names should not be included in 
Called-Station-Id, but rather put in Network-Id-Name. Does that apply here as 
well?

-- 2.2, last paragraph: Since a NAS will typically only include a EAP-Key-Name 
Attribute in an Access-Request in situations where the Attribute is required to 
provision service, if an EAP-Key-Name Attribute is included in an 
Access-Request but is not present in the Access-Accept, the NAS SHOULD treat 
the Access-Accept as though it were an Access-Reject. 

Is there a backwards compatibility issue? What if a NAS sends the field to a 
server that doesn't implement this draft? Is there an assumption that a NAS 
that supports this draft will only work with a server that also supports it? 

Or more to the point, is the ...typically only include...where required... 
strong enough to require a normative SHOULD? Seems like this would discourage 
the inclusion of EAP-Key-Name in the non-typical case of it _not_ being 
required. Is that the intent?

Nits/editorial comments:

-- section 2.8:

It might be worth expanding EAPoL



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-Art Early Review of draft-ietf-radext-dtls-07

[Ben Campbell]

Jouni poked me to review 08. In the process of doing that, I found your email 
that I had somehow missed. Apologies for the late response. I've removed 
sections that do not seem to require further discussion or comment.

Thanks!

Ben.

On Jan 23, 2014, at 1:05 PM, Alan DeKok al...@deployingradius.com wrote:

 Ben Campbell wrote:
 *** Major issues:

[...]

 -- section 3, 2nd paragraph:  ... long-term use of RADIUS/UDP is NOT 
 RECOMMENDED. 
 
 While I agree with the sentiment, that's not an appropriate assertion for an 
 experimental RFC. It would either need to go into an standards-track update 
 to the RADIUS spec, or a BCP.
 
  OK.

Version 08 partially addresses this by changing NOT RECOMMENDED to lower 
case. I don't think that's sufficient; it's not a good idea to rely on case 
alone to distinguish normative from non-normative text. I propose changing the 
sense of the statement to something along the lines of The author 
recommends 

(Unlike some reviewers, I will not go so far as to say the word should should 
never be used non-normatively, since the resulting text tends to be awkward. 
But I think the NOT RECOMMENDED/not recommended difference can be handled with 
more clearly non-normative text without introducing the same awkwardness.)

 
 (Also applies to the reiteration in 10.1)
 
  I'm less sure of that.  10.1 doesn't re-iterate the point above.  It
 makes a security recommendation.  i.e. allowing secure and insecure
 traffic from the same client is bad.
 
  This imposes no change on existing RADIUS/UDP clients, as they will
 only be sending RADIUS/UDP.  It does impose security requirements on
 RADIUS/DTLS clients and servers, which is the intent of the section.
 

The text to which I refer says It is RECOMMENDED that all RADIUS clients and 
servers implement this specification, or [RFC6614]. That seems to to apply a 
new normative statement to all RADIUS clients and servers, and does not in any 
way seem scoped to RADIUS/DTLS clients and servers.


 *** Minor issues:
 
 -- General:  It might be worth some text on why this is experimental rather 
 than informational. Is there any plan to evaluate the implementation 
 results? Is there an expectation that a future RADIUS/DTLS spec could become 
 standards-track? Is there any plan to evaluate the outcome of this document?
 
  It's probably easiest to reference Section 1.3 of RFC 6614.  The
 issues are the same.

I don't think that's the best approach. That discussion is specific to 6614. 
Referencing it would leave the reader to infer how that discussion would apply 
to this draft. I think it would be better to include a similar discussion here.

 
 -- Section 1, 2nd paragraph:
 
 Isn't this true for almost any use of IPSec? Is there some specific reason 
 this is worse for RADIUS than for other protocols?
 
  It's true for most protocols.

It's worth mentioning that.

[...]

 The firewall rule recommendations in the 3rd sentence seems odd, since it 
 seems like any protocol over DTLS would pass. Also, does this imply a 
 recommendation that firewalls with DPI be used in the first place, since the 
 absence of such a firewall has the same effect as having one that doesn't 
 enforce the protocol? (Is there a reason a protocol spec should recommend 
 firewall rules in the first place, other than to mention places where 
 certain firewall rules might prevent interfere with operation?)
 
  I'll clarify it, and move it to the Security Considerations section.

The clarification added at the end of  section 10 in version 08 mostly 
addresses this. But I assume that the point is to make sure no one sends 
non-protected RADIUS over that port, but it doesn't prevent someone from 
sending some other protocol over DTLS over the same port, correct? If so, I 
think that's worth a mention.

[...]

 -- 2.2 and children:
 
 I find this section confusing as to where to find the authoritative text. 
 Some, but not all, of the material from 6614 is repeated as normative text 
 in later sections.  The description of this draft as applying 'semantic 
 patches' to 6614 seems to imply you mean the 6114 text, with these patches 
 applied, to be normative, which creates some potential conflicts. If, on the 
 other hand, 2.2 (.x) is intended more as a informative description of the 
 differences, please say so.
 
  What conflicts occur?  The intent is show this specification as a
 revision / patch from 6614.

On a quick re-review, I have not found a specific example of conflicting or 
redundant normative text in version 08. I thought I had run into some around 
peer authentication before, but either I was mistaken or the 08 updates 
corrected it.

[...]

 
 If so, it might make more sense to refer to the port by role rather than 
 number when discussing port related behavior. (I note that 6614 only 
 mentions the port number in the initial assignment, the IANA considerations, 
 and the appendix.)
 
  Maybe.  That makes the text a bit more awkward.  UDP/2083 would

[Gen-art] Gen-ART Telechat Review of draft-ietf-avtcore-leap-second-07

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-avtcore-leap-second-07
Reviewer: Ben Campbell  
Review Date: 2014-01-06
IESG Telechat date: 2014-01-09

Summary: This draft is ready for publication as a proposed standard. All 
comments from my previous review of version 06 have been addressed.

Major issues: None

Minor issues: None

Nits/editorial comments: None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07

[Ben Campbell]

On Dec 24, 2013, at 5:21 PM, Paul Aitken pait...@cisco.com wrote:

 Benoit, Ben,
 
 As I understand it the context is that certain data elements can include 
 payload octets. This is subject to the security considerations in 5477, 
 which basically say don't include too much, because of guidance from 2804. 
 But my reading of 2804 does not give specific guidance things like how 
 much payload one can capture before it becomes too much.
 
 I think the simplest solution would be to keep the reference to the 5477 
 security considerations, and reiterate that this model is not intended for 
 gross capture of payloads, perhaps with an _informative_ reference to 2804.
 
 The informative reference would be in line with RFC 5477. So yes.
 Not sure if we need the reiteration.
 
 I think a sentence or two would save the reader from having to flip back and 
 forth between docs. But it's not a big deal one way or ahother.
 
 
 I've moved RFC2804 to an Informative reference, and changed the text to say:
 
 With sufficient length, this element also reports octets from the IP payload. 
 However full packet capture of arbitrary packet streams is explicitly out of 
 scope per the Security Considerations section of RFC5477 and RFC2804.

Works for me.

Thanks,

Ben.

(P.S. Happy [whichever holiday works for you] )
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-16

[Ben Campbell]

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-stable-privacy-addresses-16
Reviewer: Ben Campbell
Review Date: 2013-12-23
IETF LC End Date: 2013-12-25

Summary: Ready for publication as a standards track RFC. 

Note: I performed a Gen-ART review on version 06 of this draft at a previous 
IETF LC. While the draft has evolved quite a bit since then, this review is 
mostly incremental to that one. All of my comments from that review have been 
addressed.

Major issues:

None


Minor issues:

None

Nits/editorial comments:

None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-16

[Ben Campbell]

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-stable-privacy-addresses-16
Reviewer: Ben Campbell
Review Date: 2013-12-23
IETF LC End Date: 2013-12-25

Summary: Ready for publication as a standards track RFC. 

Note: I performed a Gen-ART review on version 06 of this draft at a previous 
IETF LC. While the draft has evolved quite a bit since then, this review is 
mostly incremental to that one. All of my comments from that review have been 
addressed.

Major issues:

None


Minor issues:

None

Nits/editorial comments:

None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-avtcore-leap-second-06

[Ben Campbell]

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-avtcore-leap-second-06
Reviewer: Ben Campbell
Review Date: 2013-12-6
IETF LC End Date: 2013-12-9

Summary: The draft is ready for publication as a standards track RFC

Major issues: None

Minor issues: None

Nits/editorial comments:

-- 3.3, last paragraph:

should second be seconds?

-- 5, last paragraph: the a warping technique 

extra article.

-- 5.1, title:

Should that say _RTCP_ Sender Reports?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-leiba-smime-type-registry-02

[Ben Campbell]

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-leiba-smime-type-registry-02
Reviewer: Ben Campbell
Review Date: 2013-11-15
IETF LC End Date: 2013-11-28

Summary: This draft is ready for publication as a proposed standard.

Note: The Gen-ART assignment was originally for version 01. Since version 02 
was already available at the time of my review, I reviewed it instead.


Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- It might be helpful to include the URL of the parent registry. I assume it's 
intended to be http://www.iana.org/assignments/media-types ?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-leiba-smime-type-registry-02

[Ben Campbell]

On Nov 25, 2013, at 1:41 PM, Barry Leiba barryle...@computer.org wrote:

 Hi, Ben, and thanks for the review.
 
 -- It might be helpful to include the URL of the parent registry. I assume
 it's intended to be http://www.iana.org/assignments/media-types ?
 
 Normally, I would be that specific.  But IANA are *SO* familiar with
 the media-types registry that there's no possibility of confusion
 here.
 

I figured as much; I only mentioned it out of habit. (I did say ready in the 
summary :-)  )


 Barry

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07

[Ben Campbell]

On Nov 21, 2013, at 5:45 AM, Benoit Claise bcla...@cisco.com wrote:

 Hi Ben,
 
 Thanks for your review.
 See in-line.
 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 wait for direction from your document shepherd
 or AD before posting a new version of the draft.
 
 Document: draft-ietf-ipfix-data-link-layer-monitoring-07
 Reviewer: Ben Campbell
 Review Date: 2013-11-19
 IESG Telechat date: 2013-11-21
 
 Summary: This draft is essentially ready for publication as a standards 
 track RFC. However, there is one issue that I unfortunately missed in my 
 last call review of version 06 that should be considered prior to 
 publication.
 
 Major issues:
 
 None
 
 Minor issues:
 
 There's a normative downref to RFC 2804, which is informational. That seems 
 a really odd draft for a normative reference. There may be precedent, as I 
 note that RFC 5477, referenced here for security considerations, does the 
 same thing.
 Actually RFC 5477 uses an informative reference to RFC 2804.

Oops sorry, missed that. But it does cite 2804 in the same context (i.e. 
capture payload octets, subject to [RFC 2804]

 I apologize for bringing this up this late in the process--I missed it in my 
 earlier review at last call.
 
 As I understand it the context is that certain data elements can include 
 payload octets. This is subject to the security considerations in 5477, 
 which basically say don't include too much, because of guidance from 2804. 
 But my reading of 2804 does not give specific guidance things like how much 
 payload one can capture before it becomes too much.
 
 I think the simplest solution would be to keep the reference to the 5477 
 security considerations, and reiterate that this model is not intended for 
 gross capture of payloads, perhaps with an _informative_ reference to 2804.
 The informative reference would be in line with RFC 5477. So yes.
 Not sure if we need the reiteration.

I think a sentence or two would save the reader from having to flip back and 
forth between docs. But it's not a big deal one way or ahother.

Thanks!

Ben.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-karp-ops-model-09

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-karp-ops-model-09
Reviewer: Ben Campbell
Review Date: 2013-11-19
IESG Telechat date: 2013-11-21

Summary: This draft is ready for publication as an informational RFC. All the 
issues from my last call review, have been addressed, save 1 below.

Major issues:

None

Minor issues:

-- My last call review included a concern about a possible need for additional 
guidance  around the idea of continuing to operate with an expired key. The 
author mentioned that the draft reflect working group consensus, and I'm okay 
with that. But I still think there might be value in documenting the tradeoffs 
that the working group considered reaching that consensus. I'm not sure that 
our correspondence on that matter reached a conclusion. I'm pasting the 
relevant discussion below:

 
   genart -- section 3.2, last paragraph: Implementations SHOULD
   genart permit a configuration i n which if no unexpired key is
   genart available, existing security associations continu e using
   genart the expired key with which they were established.
 
   genart This may need further guidance. For example, it seems risky
   genart to do this silently.
 
 I think this was explicitly discussed in the WG and is where we got in
 our discussions.
 There's discussion of alerts for security events elsewhere.
 However I think the current text represents a fairly informed WG
 consensus.
 
 You are correct that there is separate text on notification of security 
 events (section 6.2), and that even mentions certificate expiration. But it 
 doesn't explicitly mention continuing to use an expired key. I think that's 
 important enough that it should be explicitly considered.
 
 If it was explicitly discussed in the working group, it would be helpful to 
 document the trade-offs that were discussed.


Nits/editorial comments:

-- idnits reports some outdated references, please check.

-- section 1, paragraph 4, 2nd sentence:

s/routers/Routers
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-ipfix-data-link-layer-monitoring-07

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ipfix-data-link-layer-monitoring-07
Reviewer: Ben Campbell
Review Date: 2013-11-19
IESG Telechat date: 2013-11-21

Summary: This draft is essentially ready for publication as a standards track 
RFC. However, there is one issue that I unfortunately missed in my last call 
review of version 06 that should be considered prior to publication.

Major issues:

None

Minor issues:

There's a normative downref to RFC 2804, which is informational. That seems a 
really odd draft for a normative reference. There may be precedent, as I note 
that RFC 5477, referenced here for security considerations, does the same 
thing.  I apologize for bringing this up this late in the process--I missed it 
in my earlier review at last call.

As I understand it the context is that certain data elements can include 
payload octets. This is subject to the security considerations in 5477, which 
basically say don't include too much, because of guidance from 2804. But my 
reading of 2804 does not give specific guidance things like how much payload 
one can capture before it becomes too much.

I think the simplest solution would be to keep the reference to the 5477 
security considerations, and reiterate that this model is not intended for 
gross capture of payloads, perhaps with an _informative_ reference to 2804.

Nits/editorial comments:

None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-Art Early Review of draft-ietf-radext-dtls-07

[Ben Campbell]

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.

This is an early review at WGLC last call.

Document:   draft-ietf-radext-dtls-07
Reviewer: Ben Campbell
Review Date: 2013-11-18

Summary: This draft is on the right track, but there are significant open 
issues that should be resolved before it progresses.

[Note: This review is different from the usual Gen-ART review due to the fact 
that it's an early (as in prior to pubreq) review, and that the draft is 
intended to become an experimental RFC. The gen-ART review process is tuned for 
drafts at IETF last call or later. It's a little hard to figure out what 
criteria should be used for drafts at an earlier point in the life-cycle. That 
being said, I reviewed this as if it were near-final, and apologize if that 
turns out to be too strict for an early review.

I used similar review criteria as I would for a standards-track draft, since 
this draft still specifies protocol with the hope of interoperable 
implementations. The only difference comes from a few comments explicitly about 
the experimental status of the draft.]


*** Major issues:

-- General:

The draft needs an overhaul of it's use of normative language. There appears to 
be redundant (and possibly contradictory) language for the same requirements 
sprinkled throughout. There are also cases of normative language being used for 
internal implementation guidance, which is not appropriate as described by RFC 
2119. (See the minor issues section for details--most of the instances would 
not qualify as major issues by themselves, but I think they constitute a major 
issue in the aggregate.)

-- section 3, 2nd paragraph:  ... long-term use of RADIUS/UDP is NOT 
RECOMMENDED. 

While I agree with the sentiment, that's not an appropriate assertion for an 
experimental RFC. It would either need to go into an standards-track update to 
the RADIUS spec, or a BCP.

(Also applies to the reiteration in 10.1)


*** Minor issues:

-- General:  It might be worth some text on why this is experimental rather 
than informational. Is there any plan to evaluate the implementation results? 
Is there an expectation that a future RADIUS/DTLS spec could become 
standards-track? Is there any plan to evaluate the outcome of this document?

-- Section 1, 2nd paragraph:

Isn't this true for almost any use of IPSec? Is there some specific reason this 
is worse for RADIUS than for other protocols?

-- Section 1, 4th paragraph:

The second sentence mentions that firewall rules do not need to be changed. The 
following sentence recommends a change to firewall rules.

The firewall rule recommendations in the 3rd sentence seems odd, since it seems 
like any protocol over DTLS would pass. Also, does this imply a recommendation 
that firewalls with DPI be used in the first place, since the absence of such a 
firewall has the same effect as having one that doesn't enforce the protocol? 
(Is there a reason a protocol spec should recommend firewall rules in the first 
place, other than to mention places where certain firewall rules might prevent 
interfere with operation?)

-- section 2.1, 5th paragraph (3rd paragraph after bullet list) :  
Implementations MUST support encapsulated RADIUS packets of 4096 in length...

Please be more precise than MUST support. Specifically, does MUST support 
indicate you must support both sending and receiving of that size? (since 4096 
would generally exceed PMTU even for RADIUS/UDP)

-- 2.2 and children:

I find this section confusing as to where to find the authoritative text. Some, 
but not all, of the material from 6614 is repeated as normative text in later 
sections.  The description of this draft as applying 'semantic patches' to 
6614 seems to imply you mean the 6114 text, with these patches applied, to be 
normative, which creates some potential conflicts. If, on the other hand, 2.2 
(.x) is intended more as a informative description of the differences, please 
say so.

-- 3, 1st paragraph:

Can you elaborate on the resulting timeouts, lost traffic, and network 
instabilities?

-- 3.1: 

The section describes UDP/2083 as the default port. But later sections 
describe port related behavior in a way that makes it it look like the 
impementations must always use 2083, which makes it more than just a default. 
Is the administrator allowed to choose some other port for any reason? If so, 
it might make more sense to refer to the port by role rather than number when 
discussing port related behavior. (I note that 6614 only mentions the port 
number in the initial assignment, the IANA considerations, and the appendix.)


-- 3.2, last paragraph:

Can you elaborate on the bid down attack? Given that the use of dtls is 
configured, rather than negotiated, how would an attacker bid it down?

-- 4, 2nd paragraph:

Seems like an (or maybe even the) important point would be that a client should

Re: [Gen-art] Gen-ART LC Review of draft-ietf-ipfix-data-link-layer-monitoring-06

[Ben Campbell]

Hi,

The revised version addresses all of my Gen-ART review comments.

Thanks!

Ben.

On Nov 4, 2013, at 8:16 PM, Benoit Claise bcla...@cisco.com wrote:

 Ben,
 
 A new draft version has been posted
 https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/ 
 
 Regards, Benoit
 Thanks for the response. Those changes would address all of my comments.
 
 Thanks!
 
 Ben.
 
 On Oct 31, 2013, at 11:05 AM, Paul Aitken pait...@cisco.com wrote:
 
 Thanks for the review, Ben.
 
 As you pointed out, the description in 3.2.18 wrongly specified a delta 
 rather than a total; I've fixed it.
 
 I also clarified the third paragraph of the Introduction to say that the 
 existing models don't yet contain enough elements - which is the point of 
 this draft.
 
 Regarding section 4 / RFC 5477, the intention is that IANA's IPFIX registry 
 is the ultimate reference. We want to avoid new drafts updating old RFCs.
 The IPFIX AD is considering how to proceed with that.
 
 I'll publish a -07 with the changes.
 
 Thanks,
 P.
 
 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-ipfix-data-link-layer-monitoring-06
 Reviewer: Ben Campbell
 Review Date: 2013-22-10
 IETF LC End Date: 2013-23-10
 
 Summary: Ready for publication as a proposed standard, with  one problem 
 that should be easily fixed.
 
 Major issues:
 
 None
 
 Minor issues:
 
 3.2.18:
 
 Title of the data element suggests a total, but the description sounds 
 like a delta (i.e change since last report.)
 
 -- section 4 and subsections
 
 It looks like this draft updates at least RFC5477. If so, this should be 
 indicated in the header and in the abstract.
 
 
 
 Nits/editorial comments:
 
 -- section , 3rd paragraph:
 
 Do you mean to say the existing data models do not contain the elements 
 needed, or that the models do not provide the right foundation for the 
 needed elements? The wording seems to indicate the latter but I think you 
 mean the former.
 
 -- General:
 Watch for missing articles.
 .
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-ipfix-data-link-layer-monitoring-06

[Ben Campbell]

Thanks for the response. Those changes would address all of my comments.

Thanks!

Ben.

On Oct 31, 2013, at 11:05 AM, Paul Aitken pait...@cisco.com wrote:

 Thanks for the review, Ben.
 
 As you pointed out, the description in 3.2.18 wrongly specified a delta 
 rather than a total; I've fixed it.
 
 I also clarified the third paragraph of the Introduction to say that the 
 existing models don't yet contain enough elements - which is the point of 
 this draft.
 
 Regarding section 4 / RFC 5477, the intention is that IANA's IPFIX registry 
 is the ultimate reference. We want to avoid new drafts updating old RFCs.
 The IPFIX AD is considering how to proceed with that.
 
 I'll publish a -07 with the changes.
 
 Thanks,
 P.
 
 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-ipfix-data-link-layer-monitoring-06
 Reviewer: Ben Campbell
 Review Date: 2013-22-10
 IETF LC End Date: 2013-23-10
 
 Summary: Ready for publication as a proposed standard, with  one problem 
 that should be easily fixed.
 
 Major issues:
 
 None
 
 Minor issues:
 
 3.2.18:
 
 Title of the data element suggests a total, but the description sounds like 
 a delta (i.e change since last report.)
 
 -- section 4 and subsections
 
 It looks like this draft updates at least RFC5477. If so, this should be 
 indicated in the header and in the abstract.
 
 
 
 Nits/editorial comments:
 
 -- section , 3rd paragraph:
 
 Do you mean to say the existing data models do not contain the elements 
 needed, or that the models do not provide the right foundation for the 
 needed elements? The wording seems to indicate the latter but I think you 
 mean the former.
 
 -- General:
 Watch for missing articles.
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-ipfix-data-link-layer-monitoring-06

[Ben Campbell]

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-ipfix-data-link-layer-monitoring-06
Reviewer: Ben Campbell
Review Date: 2013-22-10
IETF LC End Date: 2013-23-10

Summary: Ready for publication as a proposed standard, with  one problem that 
should be easily fixed.

Major issues:

None

Minor issues:

3.2.18:

Title of the data element suggests a total, but the description sounds like a 
delta (i.e change since last report.)

-- section 4 and subsections

It looks like this draft updates at least RFC5477. If so, this should be 
indicated in the header and in the abstract.



Nits/editorial comments:

-- section , 3rd paragraph:

Do you mean to say the existing data models do not contain the elements needed, 
or that the models do not provide the right foundation for the needed elements? 
The wording seems to indicate the latter but I think you mean the former.

-- General:
Watch for missing articles.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-yusef-dispatch-ccmp-indication-06

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-yusef-dispatch-ccmp-indication-06
Reviewer: Ben Campbell
Review Date: 2013-10-08
IESG Telechat date: 2013-10-10

Summary: This draft is ready for publication as an informational RFC. This 
version addresses all the comments from my last call review of version 04. I do 
have a couple of new (or I missed the first time) editorial comments that might 
be worth addressing if there is a new version prior to approval.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- General:

idnits 2.12.18 reports some missing references--please check.

-- Abstract and Intro

Please expand UA and XCON on first mention (Both in Abstract and in Section 1).

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Telechat Review of draft-ietf-intarea-flow-label-balancing-02

[Ben Campbell]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-intarea-flow-label-balancing-02
Reviewer: Ben Campbell
Review Date: 2013-10-08
IESG Telechat date: 2013-10-10

Summary: This version is ready for publication as an informational RFC. All of 
the comments from my previous last call review have been addressed either in 
this version or in email correspondence. 

Major issues: None

Minor issues: None

Nits/editorial comments: None
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-l2vpn-pbb-vpls-interop-05

[Ben Campbell]

Hi Ali,

Those changes would resolve my comments. 

Thanks!

Ben.

On Oct 8, 2013, at 5:13 PM, Ali Sajassi (sajassi) saja...@cisco.com wrote:

 
 Ben,
 
 Thanks for your comments. I have incorporated all your comments in rev06
 of this draft.
 
 
 On 9/23/13 1:29 PM, Ben Campbell b...@nostrum.com wrote:
 
 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-l2vpn-pbb-vpls-interop-05
 Reviewer: Ben Campbell
 Review Date: 2013-09-23
 IETF LC End Date: 2013-09-24
 
 Summary: Ready for publication as an informational RFC.
 
 Major issues:
 
 None
 
 Minor issues:
 
 None
 
 Nits/editorial comments:
 
 -- Abstract:
 
 Please expand H-VPLS on first mention
 
 Done.
 
 
 -- section 1, 1st paragraph:
 
 Please expand VPLS on first mention.
 
 Done.
 
 
 -- section 4, 3rd to last paragraph: Different PBB access networks...
 
 The previous and subsequent paragraphs say PBBN access networks. Should
 this instance also say PBBN?
 
 Done.
 
 
 -- section 4.3:
 
 2nd paragraph says this scenario is applicable to Loosely Coupled
 Service Domains and Different Service Domains. The 4th paragraph
 mentions Tightly Does that mean the scenario also applies to
 Tightly Coupled Service Domains? (i.e. should it be added to the 2nd
 paragraph, or removed from the 4th?)
 
 
 Removed Tightly Š from the 4th paragraph.
 
 Cheers,
 Ali
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04

[Ben Campbell]

Hi Mary,

I similarly apologize for the delay in responding. It's been a busy week.

As I started to go over your responses one by one, I realized I had notated 
each one as WFM. So rather than send all that, I will summarize as I agree 
with all of your responses, and updates to these effects will resolve all of my 
concerns.

Thanks!

Ben.

On Sep 16, 2013, at 2:59 PM, Mary Barnes mary.ietf.bar...@gmail.com wrote:

 Hi Ben, 
 
 I apologize for the delay in responding.  I had initially missed this review 
 - it either got cached directly with gen-art reviews or the tools alias 
 burped.  I'm not on the main IETF list with this email address.
 
 Anyways, thank you very much for your thorough review.  Our responses are 
 below [MB].
 
 We have an update underway that addresses your's and other's LC comments.  We 
 can forward that to you to preview if you would like.
 
 Regards,
 Mary. 

[...]
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-l2vpn-pbb-vpls-interop-05

[Ben Campbell]

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-l2vpn-pbb-vpls-interop-05
Reviewer: Ben Campbell
Review Date: 2013-09-23
IETF LC End Date: 2013-09-24

Summary: Ready for publication as an informational RFC.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

-- Abstract:

Please expand H-VPLS on first mention

-- section 1, 1st paragraph:

Please expand VPLS on first mention.

-- section 4, 3rd to last paragraph: Different PBB access networks...

The previous and subsequent paragraphs say PBBN access networks. Should this 
instance also say PBBN?

-- section 4.3:

2nd paragraph says this scenario is applicable to Loosely Coupled Service 
Domains and Different Service Domains. The 4th paragraph mentions 
Tightly Does that mean the scenario also applies to Tightly Coupled 
Service Domains? (i.e. should it be added to the 2nd paragraph, or removed 
from the 4th?)


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-kelsey-intarea-mesh-link-establishment-05

[Ben Campbell]

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-kelsey-intarea-mesh-link-establishment-05
Reviewer: Ben Campbell
Review Date: 2013-09-16
IETF LC End Date: 2013-09-16

Summary: This draft is almost ready to be published as a proposed standard. 
There are a few minor issues that should be considered prior to publication.

General: The draft is well written, and easier to read than many internet 
drafts.

Major issues:

none

Minor issues:

-- Applicability Statement

The applicability statement seems a bit lightweight.   I understand it is 
needed for some other IETF work; it might be nice to mention the specifics here 
(or in the introduction.) The assertion that this extends 802.15.4 makes me 
wonder why this is an IETF effort rather than IEEE 802 effort--some IETF 
context would help.

-- section 5, 1st paragraph: To avoid the cost and complexity of adding a 
second security suite, MLE reuses that of 802.15.4.  This document describes 
two security suites...

The two sentences seem to contradict. Is this document describing security 
suites that are already in 802.15.4, or is it adding new ones?

-- section 7.8: Delay

Can you offer guidance on how to choose a delay value?

-- section 7.9,  paragraph starting with Update messages SHOULD...

What is the rational for SHOULDs instead of MUSTs? Can you offer guidance on 
when it might make sense to violate these? What might happen if one does?

-- section 8: Outgoing link configuration and advertisement messages SHOULD be 
secured...

Can you be more precise than secured? Does this mean signed, encrypted, 
or both? Also, what would be the consequences of violating the SHOULD?

-- section 8, paragraph 6: ... MUST be delayed by a random time between 0 and 
MAX_RESPONSE_DELAY_TIME seconds.

What's a reasonable resolution for that random time? I note that 
MAX_RESPONSE_DELAY_TIME is set to 1 second. I assume a random number between 
zero and one is not what you have in mind. :-)

-- section 8, paragraph 9: Because MLE messages do not require complex 
processing and are not relayed, a simple timeout scheme is used for 
retransmitting.

You mention forwarding multiple hops two paragraphs back; do you mean something 
different here? There are other mentions of forwarding in the draft that makes 
me wonder about the assertion that messages are not relayed.

-- section 8, last paragraph:

Can you offer guidance on an appropriate resolution for the random multiplier?

-- section 9, paragraph 3: Unsecured incoming messages SHOULD be ignored.

Why not MUST? Also does this imply the requirement to secure messages in the 
first place should have been MUST?

-- section 9, paragraph 4:  A device SHOULD maintain a separate incoming MLE 
frame counter for each neighbor.

What happens if it doesn't?

-- Security Considerations:

I'd like to see a bit more on the consequences of accepting unsecured messages. 
The normative requirement says SHOULD NOT accept unprotected messages, instead 
of MUST NOT, so I assume that you contemplate that implementations may have 
reasons to accept unsecured messages. 

It's also worth some discussion of securing at the 802.15.4 layer vs at the MLE 
layer, since that's mentioned a few times in the draft


Nits/editorial comments:

-- section 4.1, 1st paragraph:  ... (addresses, node capabilities, frame 
counters)...

Is that list exhaustive or exemplary? A that is or for example would help. 
Also, missing a conjunction before last element.

-- section 7.8, last line: Values to be confirmed...

Do you expect that to be removed prior to publication? If you think that IANA 
might not confirm the values, it might be better to use placeholders that refer 
back to the IANA Considerations section.  (Note that this occurs several times 
throughout the draft.)

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-dime-overload-reqs-11

[Ben Campbell]

Thanks, David!

On Aug 27, 2013, at 11:40 AM, Black, David david.bl...@emc.com wrote:

 The -11 version of this draft addresses all of the nits and editorial comments
 noted in the Gen-ART review of the -10 version.  It's ready for publication as
 an Informational RFC.
 
 Thanks,
 --David
 
 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Thursday, August 22, 2013 4:50 PM
 To: Black, David
 Cc: Eric McMurry; General Area Review Team (gen-art@ietf.org); i...@ietf.org;
 d...@ietf.org; bcla...@cisco.com
 Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
 
 Hi David,
 
 We agree on all your points, and will make the updates in the next version,
 pending shepherd instructions.  
 
 Thanks!
 
 Ben.
 
 On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote:
 
 Hi Eric,
 
 This looks good - comments follow ...
 
 a) I assume that overload control development work will derive more
 specific
 security requirements - e.g., as REQ 27 is stated at a rather high level.
 The discussion in security considerations section seems reasonable.
 
 We agree with this.  The thinking here was that we didn't want to specify 
 this
 in a way that would be specific to a particular type of mechanism.  It 
 might
 not hurt to state that assumption, either as a note on Req 27 or in the sec
 considerations.
 
 That would be good to add as a note on REQ 27.
 
 The intent was very much as you say, where requirements on individual node
 capabilities are hoped to result in better overall system behaviors. There 
 are
 also some requirements that are stated more at the system level (e.g. 7 and
 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
 insufficient server capacity at a cluster of servers behind a Diameter 
 agent
 can be treated as if the agent itself was overloaded.
 
 On the other hand, any mechanism we design will have to focus on actions of
 individual nodes, so the numbered requirements tend to focus on that. I'm 
 not
 sure where to change the balance here--do you have specific suggestions?
 
 I noted this as editorial rather than a minor issue, as I was mostly 
 concerned
 that the actual design work will be informed by a sufficient architectural 
 clue
 that the goal is better overall system behaviors, which your response 
 indicates
 will definitely be the case ;-).
 
 Rather than edit individual requirements, how about adding the following 
 sentence
 immediately following the introductory sentence in Section 7?:
 
 These requirements are stated primarily in terms of individual node
 behavior to inform the design of the improved mechanism;
 that design effort should keep in mind that the overall goal is
 improved overall system behavior across all the nodes involved,
 not just improved behavior from specific individual nodes.
 
 This inadequacy may, in turn, contribute to broader congestion collapse
 
 collapse is not the right word here - I suggest issues, impacts,
 effects or problems.
 
 We are fine with any of those alternatives.  How about impacts.
 
 That's fine.  FWIW, congestion collapse has a specific (rather severe)
 meaning over in the Transport Area, and that meaning was not intended here.
 
 23.843 is the least stable reference.  I don't have any issue with pointing
 that out.  The part of it we are referencing is historical front matter
 though.
 
 I'd note the reference as work in progress, and put the statement about 
 stable
 front matter (historical is a bad work to use here) in the body of the draft
 that cites the reference.
 
 I tried the web and downloaded versions of 2.12.17 and was not able to get 
 the
 warnings you saw (about the references).  What did it say?
 
 Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits 
 confusion
 manifested right at the top of the output, where everyone ignores it ...
 
  Attempted to download rfc272 state...
  Failure fetching the file, proceeding without it.
 
 You didn't reference RFC 272, so that output's apparently courtesy of idnits
 misinterpreting this reference:
 
 1195   [TS29.272]
 1196  3GPP, Evolved Packet System (EPS); Mobility 
 Management
 1197  Entity (MME) and Serving GPRS Support Node (SGSN) 
 related
 1198  interfaces based on Diameter protocol, TS 29.272 
 11.4.0,
 1199  September 2012.
 
 I was amused :-).
 
 Thanks,
 --David
 
 -Original Message-
 From: Eric McMurry [mailto:emcmu...@computer.org]
 Sent: Thursday, August 22, 2013 3:06 PM
 To: Black, David
 Cc: b...@nostrum.com; General Area Review Team (gen-art@ietf.org);
 i...@ietf.org; d...@ietf.org; bcla...@cisco.com
 Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
 
 Hi David,
 
 Thank you for the review.  Your time and comments are appreciated!
 
 comments/questions inline.
 
 
 Eric
 
 
 
 On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com wrote

Re: [Gen-art] Gen-ART review of draft-ietf-dime-overload-reqs-10

[Ben Campbell]

Hi David,

We agree on all your points, and will make the updates in the next version, 
pending shepherd instructions.

Thanks!

Ben.

On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote:

 Hi Eric,
 
 This looks good - comments follow ...
 
 a) I assume that overload control development work will derive more specific
 security requirements - e.g., as REQ 27 is stated at a rather high level.
 The discussion in security considerations section seems reasonable.
 
 We agree with this.  The thinking here was that we didn't want to specify 
 this
 in a way that would be specific to a particular type of mechanism.  It might
 not hurt to state that assumption, either as a note on Req 27 or in the sec
 considerations.
 
 That would be good to add as a note on REQ 27.
 
 The intent was very much as you say, where requirements on individual node
 capabilities are hoped to result in better overall system behaviors. There 
 are
 also some requirements that are stated more at the system level (e.g. 7 and
 17.) Also the text in section 2.2 that discusses Figure 5 talks about how
 insufficient server capacity at a cluster of servers behind a Diameter agent
 can be treated as if the agent itself was overloaded.
 
 On the other hand, any mechanism we design will have to focus on actions of
 individual nodes, so the numbered requirements tend to focus on that. I'm not
 sure where to change the balance here--do you have specific suggestions?
 
 I noted this as editorial rather than a minor issue, as I was mostly concerned
 that the actual design work will be informed by a sufficient architectural 
 clue
 that the goal is better overall system behaviors, which your response 
 indicates
 will definitely be the case ;-).
 
 Rather than edit individual requirements, how about adding the following 
 sentence
 immediately following the introductory sentence in Section 7?:
 
   These requirements are stated primarily in terms of individual node
   behavior to inform the design of the improved mechanism;
   that design effort should keep in mind that the overall goal is
   improved overall system behavior across all the nodes involved, 
   not just improved behavior from specific individual nodes.
 
 This inadequacy may, in turn, contribute to broader congestion collapse
 
 collapse is not the right word here - I suggest issues, impacts,
 effects or problems.
 
 We are fine with any of those alternatives.  How about impacts.
 
 That's fine.  FWIW, congestion collapse has a specific (rather severe)
 meaning over in the Transport Area, and that meaning was not intended here.
 
 23.843 is the least stable reference.  I don't have any issue with pointing
 that out.  The part of it we are referencing is historical front matter
 though.
 
 I'd note the reference as work in progress, and put the statement about stable
 front matter (historical is a bad work to use here) in the body of the draft
 that cites the reference.
 
 I tried the web and downloaded versions of 2.12.17 and was not able to get 
 the
 warnings you saw (about the references).  What did it say?
 
 Sorry, I didn't mean to send you on a wild goose chase :-).  The idnits 
 confusion
 manifested right at the top of the output, where everyone ignores it ...
 
   Attempted to download rfc272 state...
   Failure fetching the file, proceeding without it.
 
 You didn't reference RFC 272, so that output's apparently courtesy of idnits
 misinterpreting this reference:
 
 1195 [TS29.272]
 11963GPP, Evolved Packet System (EPS); Mobility Management
 1197Entity (MME) and Serving GPRS Support Node (SGSN) related
 1198interfaces based on Diameter protocol, TS 29.272 11.4.0,
 1199September 2012.
 
 I was amused :-).
 
 Thanks,
 --David
 
 -Original Message-
 From: Eric McMurry [mailto:emcmu...@computer.org]
 Sent: Thursday, August 22, 2013 3:06 PM
 To: Black, David
 Cc: b...@nostrum.com; General Area Review Team (gen-art@ietf.org);
 i...@ietf.org; d...@ietf.org; bcla...@cisco.com
 Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10
 
 Hi David,
 
 Thank you for the review.  Your time and comments are appreciated!
 
 comments/questions inline.
 
 
 Eric
 
 
 
 On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com wrote:
 
 
 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-dime-overload-reqs-10
 Reviewer: David L. Black
 Review Date: August 17, 2013
 IETF LC End Date: August 16, 2013
 IESG Telechat date: (if known)
 
 Summary:
 This draft is basically ready for publication, but has nits that should be
 fixed before publication.
 
 This draft describes scenarios in which Diameter overload can occur and 
 provides
 requirements for 

[Gen-art] Gen-ART LC Review of draft-ietf-karp-ops-model-07

[Ben Campbell]

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-karp-ops-model-07.txt
Reviewer: Ben Campbell
Review Date: 2013-08-16
IETF LC End Date: 2013-08-18
IESG Telechat date: 

Summary: This draft is almost ready for publication as an informational RFC. I 
have a few clarity related comments that might be worth considering prior to 
publication.

Major issues:

None.


Minor issues:

-- This abstract claims that this draft is a discussion of issues. From that 
perspective, I don't think the use of 2119 language is appropriate. There are 
some specific areas (mentioned below) where 2119 language is used in imprecise 
ways, and may do harm to the reader's understanding. There are other uses that 
may be more reasonable. But I think the draft would be better off dispensing 
with 2119 language altogether.

-- Section 3, paragraph 4:

This seems like a place where descriptive language would be better than 2119 
language. In particular, and so on leaves things too open ended and 
imprecise. Also, the use of 2119 language in an example seems a bit off.

-- section 3.1, last paragraph:

I'm not sure what guidance is intended in this paragraph. It offers an example, 
then refutes it. Are there better examples to offer? Is the point that one 
shouldn't make such checks?

-- section 3.2, paragraph 2:

What distinguishes SHOULD from desirable in this context? That is, why use 
2119 language for one and not the other?

-- section 3.2, last paragraph: Implementations SHOULD permit a configuration 
in which if no unexpired key is available, existing security associations 
continue using the expired key with which they were established.

This may need further guidance. For example, it seems risky to do this silently.

-- section 3.3, last paragraph: ... then there is complexity in key management 
protocols.

Can you elaborate? Too much complexity? Are there key management systems that 
are not complex?

-- section 4, 2nd to last paragraph:

Seems like other disadvantages are worth mentioning. For example, the potential 
impact of a compromised CA.

-- 4.1:

I understand why one might choose not to include a real-world example here, but 
is there something that can be referenced?

-- 4.4, 2nd paragraph: ... it will be critical to make sure that they are not 
required during routine operation or a cold-start of a network.

Can you elaborate on why?


Nits/editorial comments:

Abstract: Might be worth mentioning KARP and how this draft fits with others.

-- Section 1, paragraph 1: Please expand KARP on first mention.

-- Section 1, paragraph 3: Missing punctuation.

-- section 3: 
The text seems to rather abruptly start talking about key considered actions 
with little background. A quick summary of how these keys re used would be 
helpful.

-- section 3, paragraph 2: Each OSPF link needs to use the same authentication 
configuration, ...

Same configuration as what? The sentence appears to say keys must be the same 
among links but can be different.

-- section 3.2, first 2 paragraphs:

I'm not sure how a configuration management system and a configuration 
interface differ for the purposes of this discussion.

-- 4.1, paragraph 4: Preshared keys that are used via automatic key management 
have not been specified for KARP.

I'm not sure what's intended here--if they are not specified why does the 
paragraph go on to talk about them?

-- 4.4, 1st paragraph: ... like RADIUS or directories.

Is there a word missing? 

-- 5, bullet list of management objects:

There may be management objects implied by the second and third bullets, but 
they are not mentioned as such. Can you explicitly state them? For example, in 
bullet 2 is the peer the object being discussed? Or is it the name or key. 
In bullet 3, is group the managed object, rather than routing protocol?

-- 5, paragraphs 7 and 8:

s/what/which  (two occurrences)
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC/Telechat Review of draft-ietf-jcardcal-jcard-04

[Ben Campbell]

Thanks for the response. A few comments inline. I removed sections that don't 
seem to need further comment.

On Jul 22, 2013, at 6:55 AM, Philipp Kewisch kewi...@gmail.com wrote:

 
 On 7/17/13 12:27 AM, Ben Campbell wrote:

[...]

 -- 3.2.1.1:
 
 What happens for future versions of vCard? Do you simply use the new version 
 number, or would we need a new version of this spec? I suspect the latter. 
 If true, it might be worth mentioning that, or somewhere early in the draft 
 mention that this spec is for vCard 4.0 only.
 
 I'd love to hear from the WG here, but given vCard 5.0 can at least in theory 
 be completely different, I think the correct thing to do would be to restrict 
 this jCard document to 4.x and when 5.x comes around create a revision of the 
 document. Of course the text could be changed so that its valid until 
 revised by another document, in case the changes in 5.x are minor enough 
 that no change in jCard is needed.
 
 In any case, there should be a text change that any 4.x revision is allowed. 
 For example, I recently read a suggestion for signed vCards that might use a 
 version 4.0s.

Pending the opinions of the work group, I'm happy with that approach.

 -- sections 3.4.3 and 3.4.4:
 
 Is the included ABNF a quotation of that in the referenced RFCs, or is it 
 new and authoritative? If the former, it would be helpful to mention that in 
 the text. (I note you did say that about the ABNF in the appendix).
 
 The ISO specs don't provide a direct BNF for any of their constructs. Instead 
 they show examples in the form:
 Basic format: MMDD Example: 19850412
 Extended format: -MM-DD Example: 1985-04-12
 
 The ABNF in jCard mimics this format, so it is not new, but given it matches 
 I guess we could say its authoritative. Unless someone tells me otherwise 
 (I'm still a bit uncertain when something can be called authoritative), I'll 
 change it by changing the hangText ABNF Schema: to ABNF Schema 
 (authoritative): in both sections.

By authoritative, I don't mean anything particularly formal. It's really a 
matter of where the normative text lies. So, for someone implementing _this_ 
draft, would you expect them to look at the included ABNF only, or is it a case 
of the ABNF being here for convenience but a careful implementor should  also 
look at the ISO specs?


 
 -- 3.4.11:
 
 If RFC6350 says that use of the timezone offset is NOT RECOMMENDED, can you 
 elaborate on why it's included here? (I can guess it's because people may 
 still use it in vCards since it was a MUST NOT, but it would be good to 
 say something to that effect in the text.)

oops, I think I meant to say SHOULD NOT.

 
 There is no other vCard property that uses a utc-offset as a type, so this is 
 just for the sake of an example. RFC6350 Section 6.5.1 has the details, it 
 says utc-offset SHOULD NOT be used on a TZ property. The alternative would be 
 to use an x-property for the example, i.e
 
 [x-clock-offset, {}, utc-offset, -05:00]
 
 Do you think we should use this instead?

I don't have strong feelings either way, other than if you include a NOT 
RECOMMENDED example, it might be wise to put in a sentence or two giving the 
reasoning.

 
 
 Nits/editorial comments:
 
 -- Section 1, paragraph 1:
 
 Please expand JSON on first mention.
 
 Doing this in the introduction since you reference Section 1, paragraph 1. It 
 already appears in the abstract, should I expand it there instead/in addition?

I think the general approach is that the abstract doesn't count for this 
purpose. That is, if you separated the abstract and the body into two different 
documents, they should both still make sense.

 
 As the first mention uses JSON-based, I've reworded these two paragraphs:
 
 OLD:
As certain similarities exist between vCard and the iCalendar data
format [RFC5545], there is also an effort to define a JSON-based data
format for calendar information called jCal [I-D.ietf-jcardcal-jcal]
that parallels the format defined in this specification.
   
The purpose of this specification is to define jCard, a JSON format
for vCard data.  One main advantage to using a JSON-based format as
defined in [RFC4627] over the classic vCard format is easier
processing for JavaScript based widgets and libraries, especially in
the scope of web-based applications.
 
 NEW:
As certain similarities exist between vCard and the iCalendar data
format [RFC5545], there is also an effort to define a JSON-based data
format for calendar information called jCal [I-D.ietf-jcardcal-jcal]
that parallels the format defined in this specification.  The term
JSON describes the JavaScript Object Notation defined in [RFC4627].

The purpose of this specification is to define jCard, a JSON format
for vCard data.  One main advantage to using a JSON-based format over
the classic vCard format is easier processing for JavaScript based
widgets and libraries

Re: [Gen-art] Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

Thanks for the response! Comments inline:

Thanks!

Ben.


On Jun 21, 2013, at 4:35 PM, Michael Thornburgh mthor...@adobe.com wrote:

 hi Ben. thanks for your review. comments/replies inline.
 
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: Thursday, June 20, 2013 4:07 PM
 
 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-thornburgh-adobe-rtmfp-07
 Reviewer: Ben Campbell
 Review Date:  2013-06-20
 IETF LC End Date: 2013-06-25
 
 Summary: This draft is almost ready for publication as an informational RFC. 
 However, I have some
 concerns about the purpose and intended status of the document that I think 
 should be considered prior
 to publication.
 
 
 Note: This is an informational draft that describes what I understand to be 
 an existing protocol as
 implemented by commercial products. Therefore, this review does not attempt 
 to evaluate the protocol
 itself. I assume the protocol is what it is, and it is not up to the IETF to 
 agree or disagree with
 it.
 
 *** Major issues:
 
 -- Why does this need to be published as an IETF stream RFC?  If I 
 understand correctly, this
 documents an existing protocol as implemented by commercial products. I 
 agree with Martin's comment
 that there is value in publishing this sort of thing, but I applaud the 
 Adobe and the author for
 publishing it so other implementations can interoperate with their products. 
 But that could have done
 that in an independent stream document, or even in an Adobe published 
 document. (Perhaps even in a
 prettier format ;-)  )  If we publish this as an IETF stream document, then 
 I think it needs stronger
 clarification that it is not an IETF consensus doc than just its 
 informational status.
 
 this memo documents an existing network transport protocol that is widely 
 deployed and in widespread use in the Internet.  we felt that the IETF 
 community (and in particular the participants in the Transport and Services 
 Area) is the most appropriate community with which to share this work: 1) 
 members of this community have the necessary and relevant expertise not only 
 to understand the protocol, but to make use of it potentially in new 
 applications beyond Flash; 2) it is a transport protocol similar in many ways 
 to TCP and SCTP and widely deployed and used; 3) Adobe is interested in 
 pursuing standardization of this protocol (with all that entails) if there is 
 community interest, and the IETF is definitely the right place for that.
 
 we are very grateful that Martin Stiemerling chose to sponsor this document.
 
 with regard to comments in later messages in this thread, i'd be happy to 
 include some (IESG-supplied) boilerplate in the document to clarify that it 
 is not the product of an IETF WG.  however, note that both the title and 
 first sentence of the Introduction indicate that this is Adobe's 
 blahblahblah, consistent with other vendor-protocol RFCs and consistent with 
 IESG editorial insistence (as told to me by a former TSV AD).  see RFC 4332 
 and RFC 6802 for two examples of vendor-specific/supplied protocols.  see 
 also the IESG note in RFC 4332 as an example disclaimer that could be added.

Some additional text (whether IESG boilerplate or otherwise) that clarifies the 
purpose of the draft would help a lot.


 
 Along those lines:
 
  -- Is this document the authoritative specification? (I suspect not.) 
 Who owns change control? I
 assume that to be Adobe and/or the authors. What expectation do readers of 
 this draft have that it
 represents the current version of RTMFP at any point in time?
 
 this memo is the authoritative specification for Adobe's RTMFP.  Adobe owns 
 change control.  i believe the second and third paragraphs of the 
 Introduction indicate to a reader that this draft represents RTMFP as 
 deployed in the named Adobe products at the time of writing.

At the time of writing yes. My concern is how a future implementor can be 
confident that this doc describes RTMFP as used by Adobe at points in the 
future. When you say this is the authoritative specification, does that mean 
that Adobe does not plan to modify the protocol without timely publication of 
an update to this document?

 
  -- Under what circumstances would one desire to implement this? I can 
 infer that from the
 introduction, but it would be nice to see some sort of applicability 
 statement making it explicitly
 clear that this is not an IETF protocol, and that one would implement it in 
 order to interoperate with
 certain Adobe products. I know that some of this may be implied by the fact 
 that this is informational
 rather than standards track. But I don't expect readers who are not IETF 
 insiders to understand that
 subtlety without some explicit words to that effect

[Gen-art] Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

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-thornburgh-adobe-rtmfp-07
Reviewer: Ben Campbell
Review Date:  2013-06-20
IETF LC End Date: 2013-06-25

Summary: This draft is almost ready for publication as an informational RFC. 
However, I have some concerns about the purpose and intended status of the 
document that I think should be considered prior to publication.


Note: This is an informational draft that describes what I understand to be an 
existing protocol as implemented by commercial products. Therefore, this review 
does not attempt to evaluate the protocol itself. I assume the protocol is what 
it is, and it is not up to the IETF to agree or disagree with it.

*** Major issues:

-- Why does this need to be published as an IETF stream RFC?  If I understand 
correctly, this documents an existing protocol as implemented by commercial 
products. I agree with Martin's comment that there is value in publishing this 
sort of thing, but I applaud the Adobe and the author for publishing it so 
other implementations can interoperate with their products. But that could have 
done that in an independent stream document, or even in an Adobe published 
document. (Perhaps even in a prettier format ;-)  )  If we publish this as an 
IETF stream document, then I think it needs stronger clarification that it is 
not an IETF consensus doc than just its informational status.

Along those lines:

-- Is this document the authoritative specification? (I suspect not.) 
Who owns change control? I assume that to be Adobe and/or the authors. What 
expectation do readers of this draft have that it represents the current 
version of RTMFP at any point in time?

-- Under what circumstances would one desire to implement this? I can 
infer that from the introduction, but it would be nice to see some sort of 
applicability statement making it explicitly clear that this is not an IETF 
protocol, and that one would implement it in order to interoperate with certain 
Adobe products. I know that some of this may be implied by the fact that this 
is informational rather than standards track. But I don't expect readers who 
are not IETF insiders to understand that subtlety without some explicit words 
to that effect. In particular, it would be good to clarify the difference 
between this and the many not quite accepted as standards track by some 
working group nature of a number of our informational RFCs that describe 
protocols.

That all being said, this is overall a well written document. The rest of my 
comments are mostly pedantic nits.

*** Minor issues:

-- section 1.2: 

I find the use of MUST ONLY confusing. I gather it means you are _allowed_ 
to do X only under certain conditions rather than you are _required_ to do X 
under certain conditions. If correct, I think the words MAY ONLY would be 
more clear. If not, then I think the construct would be better handled using 
existing 2119 language.

-- section 3.2:

Do I understand correctly that all endpoints are expected to be able to present 
certificates? Do you find that common in the field? I realize the nature of the 
certs will depend on the security profiles.

-- sections 3.2 and 5

Do I assume correctly that endpoints need a common crypto profile to 
communicate? Is there a repository where one might find crypto profile 
documentation? Is there a commonly implemented one to which this draft could 
refer?

-- section 3.2: Multiple endpoints SHOULD NOT have the same identity.

Why not MUST? Will things not break if two endpoints do have the same identity?

-- Authenticity MAY comprise verifying an issuer signature chain in a public 
key infrastructure

Is that really normative, or just an observation of fact?

--  Canonical Endpoint Discriminators for distinct identities SHOULD be 
distinct.

What if they are not? Do things break? It might be worth making this a MUST, or 
adding some additional guidance about what might happen if the SHOULD is 
violated.

-- A comparison function MAY comprise performing a lexicographic ordering...

Is that really normative, or just an example of something one might do?

-- A test SHOULD comprise testing whether the certificates are identical.

What if it doesn't? Also, what constitutes identical? All fields match 
values? Bitwise match?  Is it simply including the same identity or identities? 
Maybe an identity function provided by the crypto profile?

-- 3.5, last paragraph:

Can you offer guidance on reasonable buffer size and number ranges?

-- 3.5.1.1.1, 3rd paragraph:

What are the consequences of having a tag with less than 8 bytes of length? Is 
the SHOULD reasonable here?

-- 3.5.1.1.1 throughout, and following sections:

Does the upper case AND have special meaning?

-- 3.5.1.4, Deployment Note

Re: [Gen-art] Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

On Jun 20, 2013, at 9:14 PM, Barry Leiba barryle...@computer.org wrote:

 -- Why does this need to be published as an IETF stream RFC?  If I understand 
 correctly, this documents an existing protocol as implemented by commercial 
 products. I agree with Martin's comment that there is value in publishing 
 this sort of thing, but I applaud the Adobe and the author for publishing it 
 so other implementations can interoperate with their products. But that could 
 have done that in an independent stream document, or even in an Adobe 
 published document. (Perhaps even in a prettier format ;-)  )  If we publish 
 this as an IETF stream document, then I think it needs stronger clarification 
 that it is not an IETF consensus doc than just its informational status.
 
  FWIW, the IESG has discussed this in the context of other documents, and is 
 looking at boilerplate that does not say that the document is a product of 
 the IETF, and makes it clear that the content is not a matter of IETF 
 consensus.  If that sort of boilerplate was used, do you think that would be 
 sufficient?
 

I think that would help, depending on the specific language. My concerns about 
change control, authoritative specs, etc might still apply depending on the 
boilerplate details.

Thanks!

Ben.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

[Ben Campbell]

On Jun 20, 2013, at 10:12 PM, John C Klensin john-i...@jck.com wrote:

 p.s. I started a much more detailed response to Ben, but I think
 the essence of it is above.  IMO, a discussion that amounts to
 whether or not an AD used bad judgment by choosing to sponsor an
 individual Informational submission (or whether ADs should have
 that power at all) should not become part of evaluating a
 particular document's appropriateness.

I certainly didn't mean this to be a discussion of AD judgement. I suspect this 
would not be the first time the IETF has published an informational RFC that 
describes a non-IETF protocol, so there's probably precedent for doing so. It 
might be worth discussing whether that's a good precedent.

I also recognize that the authors have done a _lot_ of work on this draft, so 
this entire discussion is probably a bit unfair to them. I actually do hope it 
gets published somewhere.

Thanks!

Ben.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-forces-interop-07

[Ben Campbell]

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-forces-interop-07
Reviewer: Ben Campbell
Review Date: 2013-05-13
IETF LC End Date: 2013-05-13
IESG Telechat date: 

Summary: This draft is almost ready for publication as an informational RFC. I 
have a few minor questions and editorial comments that may be worth considering 
prior to publication.

*** Major issues:

None.

*** Minor issues:

-- The draft mentions a couple of instances of tests that failed because of an 
incorrect implementation or differing encapsulation formats. Does this suggest 
that the specifications should be clarified? In particular, in the case of 
encapsulation format mismatch, should the specs include stronger requirements 
to be able to receive all encapsulation formats? Or should the number of 
options be reduced?

-- I have a mild concern that the use of origin country names for each 
implementation could confuse readers into thinking that the countries 
themselves officially participated, rather than organizations from each country.


-- section 4.4, last paragraph:

The text says that since the mentioned failures were likely the result of bugs, 
it doesn't indicate an interoperability problem in the specs. I have to point 
out that, it also doesn't prove interoperability in both directions for the 
particular test. It would also be worth commenting on whether the probably bugs 
were programming errors rather than misunderstandings of the specification.


*** Nits/editorial comments:

-- The draft uses inconsistent verb tense throughout. I found this a bit 
confusing, as I assume the draft talks entirely about tests that have already 
occurred.

-- IDNits points out that you have several references without explicit 
citations. I see that you called the references out by name in the text, but it 
would be better to include the citations.

-- Section 1, paragraph 6:

Please expand abbreviations on first mention.

-- Section 1.1:

Please expand FE on first mention.

-- section 2.2.2, paragraph 1: ... from China and Japan implementations...

Missing the.

Is it possible to add a reference for details on the Smartbits testing machine?

-- Figure 2:

Do you really want to publish the IP addresses used in an RFC? RFCs live 
forever...

-- Section 2.2.2, paragraph after figure 2: 

First sentence does not parse.


-- Figure 3:

The figure has some formatting issues, at least in the PDF version. Also, is it 
possible to avoid splitting the figure across the page break?

-- section 3.2, paragraph 3: Because of system deficiency to deploy IPSec over 
TML in Greece,...

Phrase doesn't parse.

-- section 3.2, paragraph 4: ... over IPSec channel.

Missing the.

...to have established...

to establish.

-- section 4 and subsections:

It seems like some of the test descriptions in 4.X may be redundant to the 
previous scenario descriptions.

-- section 4.1, notes on 28 and 29:

Sentence does not parse.

... notes on 30 and 31:

Missing articles.

-- section 5.1, last paragraph in list item 2.: The interoperability test 
witnessed that...

The test _showed_...   [or the _testers_ witnessed...]

-- section 9:

It would be worth mentioning that you explicitly tested for IPSec support.


 





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art