Ben Campbell | 2 Sep 23:19 2014

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

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
Elwyn Davies | 2 Sep 15:20 2014

Gen-art telechat review of draft-ietf-ippm-lmap-path-05

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-lmap-path-05.txt
Reviewer: Elwyn Davies
Review Date: 29 August 2014
IETF LC End Date: 22 August 2014
IESG Telechat date: 4 September 2014

Summary:
Al Morton has shown me a set of changes that seem to address the points 
I made in my Last Call review.  Assuming they make it into -06 that'll 
be fine by me.

For the record, I didn't have the same problem as Barry and Adrian did 
with the term 'reference path'. My view was that it looked like a 
'reference point' and I know what one of those is.  But a little more 
explanation would doubtless help.

Regards,
Elwyn
Brian E Carpenter | 30 Aug 01:49 2014
Picon

Gen-ART telechat review of draft-ietf-forces-protoextension-05

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-protoextension-05.txt
Reviewer: Brian Carpenter
Review Date: 2014-08-30
IETF LC End Date: 2014-08-13
IESG Telechat date: 2014-09-04

Summary:  Ready
--------

Comment:
--------

Thanks for addressing my previous comments.
Meral Shirazipour | 29 Aug 02:23 2014
Picon

Gen-ART Telechat Call review of draft-ietf-pwe3-mspw-er-05

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-pwe3-mspw-er-05

Reviewer: Meral Shirazipour

Review Date: 2014-08-22

IETF LC End Date:   2014-08-22

IESG Telechat date: 2014-09-04

 

Summary: This draft is ready to be published as Standards Track RFC.

 

Please see LC review: http://www.ietf.org/mail-archive/web/gen-art/current/msg10531.html

 

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson

Research

www.ericsson.com

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
A. Jean Mahoney | 29 Aug 00:45 2014

Assignments for the 2014-09-04 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
------------------------------------------------------------------------------------

Ben Campbell        2014-08-09 draft-ietf-forces-model-extension-04 *

Brian Carpenter     2014-08-13 draft-ietf-forces-protoextension-05 *

Elwyn Davies        2014-08-07   draft-ietf-savi-dhcp-29 *
Elwyn Davies        2014-08-22   draft-ietf-ippm-lmap-path-05 **

Meral Shirazipour   2014-08-22   draft-ietf-pwe3-mspw-er-05 **

Martin Thomson      2014-08-05 draft-dukhovni-opportunistic-security-04 *
Martin Thomson      2014-08-22   draft-ietf-6lo-lowpan-mib-03 **

* Earlier draft reviewed
** Already reviewed

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

For your convenience, the review boilerplate template is included below.

Note that reviews should ideally be posted to the gen-art mailing list
by COB on Tuesday:
http://wiki.tools.ietf.org/area/gen/trac/wiki/

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
A. Jean Mahoney | 29 Aug 00:33 2014

A *new* batch of IETF LC reviews - 2014-08-28

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Alexey Melnikov   2014-09-11   draft-ietf-avtcore-aria-srtp-06

Ben Campbell      2014-09-11   draft-ietf-avtcore-srtp-aes-gcm-14

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Russ Housley | 24 Aug 21:23 2014

Gen-ART review of draft-ietf-jose-json-web-signature-31

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-jose-json-web-signature-31
Reviewer: Russ Housley
Review Date: 2014-08-24
IETF LC End Date: 2014-09-03
IESG Telechat date: unknown

Summary:  Not quite ready.  Some issues to resolve.

Major Concerns:  

- At first reading, I thought that Sections 2 and 3 were defining the
  same terms.  On the second or third reading, I figured it out.
  I think it would be more clear in Section 3 to state that a JWS is
  constructed from a sequence of the things that are already defined
  in Section 2.

- In Section 5.2, it says that in some cases, all must successfully
  validate, but in other cases, only a specific signature, MAC, or
  plaintext value needs to be successfully validated. How does the
  recipient know which case applies?

- In Section 8, why not say that TLS 1.2 or later MUST be supported?

- Section 10 says, "The entire list of security considerations is
  beyond the scope of this document..."  This reads like a red flag to
  me.  While it is not possible to discuss every possible implementation
  consideration that impacts security, the document should cover the
  topics discussed in RFC 3552.  At a minimum, I think the following
  need to be discussed:
    -- the consequences of compromise of the signer's private key
    -- the consequences of compromise of the MAC key
    -- the consequences of poor random numbers, which are needed for
       more than just key entropy with some algorithms like ECDSA
    -- awareness that cryptographic algorithms become weaker with time

Minor Concerns:

- Section 1, 1st paragraph says: "The JWS cryptographic mechanisms
  provide integrity protection for an arbitrary sequence of octets."
  This is true, but this is not the whole story.  A sentence or two
  should be added about when a signature mechanism is appropriate
  and when a MAC mechanism is appropriate.  Alternatively, a pointer
  to Section 10.4 could be included.

- In Section 4.1.4, should the value match the subject key identifier
  if an X.509 certificate is used?

- In Section 4.1.5, why is TLS required to fetch digitally signed
  X.509 certificates?

- Section 10.2 talks about chosen plaintext attacks.  However, there
  are much worse things than chosen plaintext attacks that will result
  if a third party can get a signer to sign a content of its choosing.

Other Comments:

- I suggest a rewording for a part of Section 2:

  OLD:

   JOSE Header
      JSON object containing the parameters describing the cryptographic
      operations and parameters employed.  The members of the JOSE
      Header are Header Parameters.

  NEW:

   JOSE Header
      JSON object containing the parameters describing the cryptographic
      operations and parameters employed.  The JOSE Header is composed
      of a set of Header Parameters.

- I think that Section 3.1 would be more clear by saying:

   In the JWS Compact Serialization, a JWS object is represented as:

      BASE64URL(UTF8(JWS Protected Header)) || "." ||
      BASE64URL(JWS Payload)  || "." ||
      BASE64URL(JWS Signature)

- I think that Section 3.1 would be more clear by saying:

   In the JWS JSON Serialization, a JWS object is represented as:

      BASE64URL(UTF8(JWS Protected Header)) || "." ||
      JWS Unprotected Header || "." ||
      BASE64URL(JWS Payload) || "." ||
      BASE64URL(JWS Signature)

   Then, the text needs to say that whitespace may appear anywhere.

- Some additional whitespace would make Section 7.2 easier to read.

- The IANA Considerations section requires the establishment of a new
  mail list: jose-reg-review <at> ietf.org.  The process for setting up the
  list is described at the bottom of this web page:
  http://www.ietf.org/list/nonwg.html.
Tom Taylor | 24 Aug 05:38 2014
Picon

Last Call Review of draft-ietf-oauth-json-web-token-25

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-oauth-json-web-token-25
Reviewer: Tom Taylor
Review Date: 23/08/2014
IETF LC End Date: 3/09/2014
IESG Telechat date: TBD

Summary: This draft is good to go. IDNits complains about the non-use of 
RFC 4648 (normative) but this is the Base64 specification invoked by 
"base64url". I did not re-verify the examples (done by the Document 
Shepherd).

Major issues:

Minor issues:

Nits/editorial comments:
Peter Yee | 23 Aug 09:07 2014

Gen-ART review of draft-ietf-soc-overload-rate-control-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 resolve these comments along with any other Last Call comments you
may receive.

Document: review of draft-ietf-soc-overload-rate-control-09
Reviewer: Peter Yee
Review Date: August-22-2014
IETF LC End Date: August-22-2014
IESG Telechat date: TBD

Summary: This draft is on the right track but has open issues, described in
the review. [Ready with issues]

The draft describes an alternate SIP overload control mechanism.  Instead of
the default, loss-based scheme, it proposes an optional, rate-based scheme.

The draft is mostly straightforward although the language is labored in some
places.  Coordination with draft-ietf-soc-overload-control should take place
before this draft advances to ensure proper alignment with the final form of
that draft.

Issues: 

Page 4, 4th paragraph: draft-ietf-soc-overload-control tends to speak of
parameters in the singular since they are being dealt with in a single Via
header field between a client and server.  In this particular case, the
wording ends up sounding like a single Via header field might have more than
one oc parameter.  Perhaps aligning with the base document would be best?

Page 6, 3rd paragraph: this whole paragraph is presumptive of all clients
performing rate-based overload control, but that presumption isn't stated.
Given that this document is introducing a second overload control algorithm,
it might not be realistic to assume that all clients implement or select the
same algorithm let alone any algorithm at all.  Also, there's an unspoken
assumption in the scenario that clients are not initiating any traffic
themselves.  Is that always going to be the case? 

Page 6, 5th paragraph: this paragraph is supposing that all clients of the
server support overload control and furthermore support rate-based control,
but these suppositions aren't mentioned.  The oc parameter should only be
returned to clients that have indicated they support overload control.  I
know you know this, but the wording isn't clear on that point.

Page 7, 1st full paragraph: what's being called "oc" in the formula isn't
really "oc" but rather "oc value".  While it's probably clear what you
meant, the base spec talks about the server inserting a value into this
parameter.

Page 14, Section 5, "algo-value" extension: This is currently called
algo-list in draft-ietf-soc-overload-control-15, the last version of that
spec.  RFC 3261 doesn't have an algo-value definition.

Nits:

Page 1, author block: far be it for me to tell an author what his name is,
but I would suggesting changing " Philip M Williams" to " Philip M.
Williams" unless M is that author's middle name.

Page 2, Introduction, 1st paragraph, 1st sentence: change "large scale" to
"large-scale".

Page 2, Introduction, 1st paragraph, 1st sentence: change "SIP based" to
"SIP-based".  Do this globally in the document.

Page 3, 1st paragraph, 1st sentence: insert "a" before "loss".

Page 3, 1st paragraph, 2nd sentence: append "scheme" after "control".
Insert "that" before "clients" and delete the subsequent "to".  

Page 3, 2nd paragraph, 1st sentence: insert "scheme" after "control".

Page 3, 2nd paragraph, last sentence: delete the comma after "client".

Page 3, 3rd paragraph: change "a rate based" to "a rate-based".  Append a
comma after "default".  Insert "scheme" between "control" and "in".

Page 4, 3rd paragraph: append a comma after "e.g.".  Do this globally and
also for "i.e.".

Page 4, 3rd paragraph: insert "or" between "utilization" and "queueing".
Delete the comma after "utilization".  Delete the ellipsis.

Page 4, Section 3.2, 1st paragraph, 1st sentence: capitalize "via".  Append
"field" after "header".

Page 5, 1st paragraph, 2nd sentence: insert "the" before "server".

Page 5, 1st paragraph, 3rd sentence: delete "conjunction for".

Page 5, Section 3.3, 1st paragraph, 1st sentence: insert "the" before "Via"
and append "field" after "header".

Page 5, Section 3.3, 1st paragraph, 3rd sentence: append "field" after
"header".

Page 5, Section 3.3, 1st paragraph, last sentence: change "rate based" to
"rate-based".

Page 5, Section 3.4, 3rd paragraph, 1st sentence: replace "max" with
"maximum".

Page 6, 1st partial paragraph: replace "the" with "a".

Page 6, 1st full paragraph: replace "cpu" with "CPU" in both uses.

Page 6, 2nd paragraph: delete the comma.

Page 6, 4th paragraph: delete the first comma.

Page 6, 4th paragraph: append to the paragraph something like " and that
rate-based control is in effect".  The server needs to indicate the rate (in
the oc parameter), but it must also inform the client which algorithm has
been selected.  

Page 6, 5th paragraph: append "the" after "use".

Page 6, section 3.5.1: move the definition of "T" to this paragraph from the
following one.  Or consider just saying "oc value" since that's what 1/T
(1/1/oc value) works out to.

Page 7, 1st partial paragraph: insert a space into "RFC5390".  Or place it
in square brackets as a reference.

Page 7, 2nd full paragraph: replace "out of scope" with "out-of-scope".

Page 7, 4th paragraph: replace "Leaky Bucket" with "leaky bucket" and use
the lower case version throughout the draft.  

Page 8, 2nd paragraph: there's a weird break in the paragraph that should be
fixed.  

Page 8, 2nd paragraph: last sentence: replace "burstyness" with
"burstiness".  This spelling seems to be more prevalent.

Page 9, 3rd paragraph: change "rate" to "rates".

Page 9, 4th paragraph: delete the commas.  Change "is" to "are".

Page 9, No priority case: TargetRate is not defined.  It should be noted
that it is the value of the oc parameter, as received from the server.  ta
might be more clearly defined as "arrival time of the most recent SIP
request received by the client".  The same applies to the prioritized case
further down.

Page 10, 1st paragraph, phrase after the colon: rewrite the first part as
"Requests that are candidates for reduction  and requests not subject to
reduction"

Page 10, 2nd paragraph: replace the first "Leaky" with "leaky" in all uses
except when used in the term "Leaky Bucket algorithm".

Page 10, 2nd paragraph first sentence: replace "requests candidate" with
"request candidates".

Page 10, 2nd paragraph, 3rd bullet item: insert "at or" before "above".

Page 10, 3rd paragraph, 1st sentence: the use of "<=" contradicts the
requirement for the Leaky Bucket algorithm as given 

Page 10, 4th paragraph: change "is" to "are".

Page 10, 5th paragraph: replace the "&" with "and".

Page 10, 6th paragraph: delete the commas and change "is" to "are".

Page 11, priority case, TAU1 definition: hyphenate "no priority".

Page 11, Section 3.5.3, second sentence: I understand what's trying to be
said, but the wording is difficult.  Consider rewording.

Page 12, 1st partial paragraph: delete the first comma.  

Page 12, 1st full paragraph, else clause: insert " let u be set to a random
value" before "uniformly".

Page 12, 4th paragraph, 4th bullet item: replace "At" with "As".

Page 12, Section 4: insert "the" before the reference.

Page 13, 1st full paragraph: append "field" after "header".

Page 13, 2nd paragraph, 1st sentence: replace both "---" with commas and
space appropriately.  Append "field" after "header".

Page 13, 2nd paragraph, 2nd sentence: drop all of the quotation marks.  They
aren't even used consistently in the sentence and don't add much.  Change
"rate based" to "rate-based".

Page 13, 3rd paragraph, 2nd sentence: change "seconds" to "second".

Page 16, Appendix B: insert "and" before "James".

Page 16, Eric Noel's address: change "200s Laurel Avenue" to "200 S Laurel
Avenue".  Change "Middletown, NJ, 07747" to "Middletown, NJ 07747".  Both
changes are made to conform to the USPS standard for address formats.
Aren't you sorry you asked? ;-)

Page 16, Philip M Williams' name.  See change requested on page 1.
Vijay K. Gurbani | 22 Aug 16:40 2014

Gen-ART review of draft-ietf-6lo-ghc-03

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-6lo-ghc-03
Reviewer: Vijay K. Gurbani
Review Date: Aug-22-2014
IETF LC End Date: Aug-29-2014
IESG Telechat date: Not scheduled yet

This document is ready as a Proposed Standard.

Major: 0
Minor: 0
Nits: 1

Editorial nits:

- S1.4, second line: s/in them the/in them, the/
         third line: s/formally speaking,/formally,/

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
A. Jean Mahoney | 21 Aug 23:43 2014

A *new* batch of IETF LC reviews - 2014-08-21

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Roni Even         2014-09-03   draft-ietf-jose-json-web-algorithms-31 *

Russ Housley      2014-09-03   draft-ietf-jose-json-web-signature-31 *

Scott Brim        2014-09-03   draft-ietf-jose-json-web-key-31 *

Suresh Krishnan   2014-09-03   draft-ietf-jose-json-web-encryption-31 *

Tom Taylor        2014-09-03   draft-ietf-oauth-json-web-token-25 *

Vijay Gurbani     2014-08-29   draft-ietf-6lo-ghc-03

Wassim Haddad     2014-09-01   draft-ietf-bfd-intervals-03

* The responsible AD said that these drafts could be assigned
   to individual reviewers. However, it may be useful to read
   draft-ietf-jose-json-web-algorithms first.

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

Gmane