Re: [Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07

[Phil Hunt]

Matt

Thanks for the great review. As Kathleen mentioned, there are some other 
changes we have to make that will push the draft back. Never-the-less I will 
take into account all the reviewer comments in the next draft. 

All your comments seem very reasonable to me. 

Thanks,

Phil

> On Dec 17, 2015, at 04:02, Kathleen Moriarty 
>  wrote:
> 
> Hi Matt,
> 
> Thank you for your review!  The editors will take these comments into
> consideration and discuss any updates.  I'll note that the draft was
> pulled from the telechat and will likely not go through last call
> again until sometime around Buenos Aires due to some other changes
> that came up.  You may see this one again.
> 
> Thanks,
> Kathleen
> 
> On Wed, Dec 16, 2015 at 9:28 PM, Matt Miller (mamille2)
>  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 treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> .
>> 
>> Document: draft-ietf-oauth-pop-architecture-07
>> Reviewer: Matthew A. Miller
>> Review Date: 2015-12-16
>> IETF LC End Date: 2015-12-15
>> IESG Telechat date: 2015-12-17
>> 
>> Summary: Almost ready.
>> 
>> I have several editorial nits, but also a couple of minor concerns that
>> I think would improve this document's readability.
>> 
>> I note that idnits complained about the lack of RFC 2119 boilerplate;
>> however, I think the text actually used in this document is most
>> appropriate and still conveys the intent.  The idnits also complained
>> about a reference to an obsolete RFC 5849; however, this reference
>> appears to be intentional and necessary.
>> 
>> -
>> 
>> Major issues:
>> 
>> Nnne.
>> 
>> Minor issues:
>> 
>> 1. In Section 1. Introduction, the last paragraph makes it seem the
>> document isn't organized properly.  It implies an order to read the
>> document that is not reflected in the outline:
>> 
>> * Section 1
>> * Section 2
>> * Section 3
>> * Section 4
>> * Section 6
>> * Section 7
>> * Section 5
>> 
>> Simply re-ording the document I think causes bigger problems.  While
>> the intro hints at the order to read, it makes more sense to me in
>> the order it actually is.  Ultimately, for me the problem arises with
>> the word "concludes".  It might simply be enough to change the last
>> participle from ", and concludes with a requirements list in Section 5."
>> to ", and lists requirements in Section 5."
>> 
>> 2. In several places, terms of art are used that have not been defined
>> in this document: "resource server", "protected resource", etc.  I
>> think it would help if Section 2. indicated where these terms are
>> defined or discussed, which is RFC 6749.
>> 
>> 
>> Nits/editorial comments:
>> 
>> * The reference to draft-ietf-oauth-proof-of-possession-08 should be
>> updated to its latest version, although I expect RFC Editor will
>> resolve this before publication.
>> 
>> * The reference to RFC 4347 should be updated to 6347; there's no clear
>> requirement for the older document.
>> 
>> * In Section 3.1 Preventing Access Token Re-Use by the Resource Server,
>> "with other resource server" should be either "with another resource
>> server" or "with other resource servers".
>> 
>> * In Section 3.2 TLS and DTLS Channel Binding Support, "entity entity"
>> should be "entity".
>> 
>> * In section 3.4 Offering Application Layer End-to-End Security, The
>> last sentence of the last paragraph seems out of place.  It seems it
>> would be better as the penultimate sentence of the previous paragraph.
>> 
>> * In section 4. Security and Privacy Threats under "Token
>> manufacture/modification", "causing resource server" should be "causing
>> the resource server".
>> 
>> * Also in Section 4. Security and Privacy Threats under "Token
>> manufacture/modification", the normative language here seems out of
>> place.  It seems to me that 'may' conveys just as much as 'MAY' for
>> how it is used here.
>> 
>> * In Section 5. Requirements under "Prevent the Domino Effect",
>> "Resource Server" is capitalized differently than all previous uses,
>> but it doesn't seem to be a different use.  I suggest changing it to
>> "resource server".
>> 
>> * In Section 6.3. Key Confirmation, uses the term "privacy key" where
>> I believe the common nomenclature is "private key".
>> 
>> * In Section 7. Client and Authorization Server Interaction, I find
>> most of the figures a little hard to follow.  While I appreciate the
>> attempt to go beyond strict perpendicularity, I find it distracting
>> from the information it is trying to convey.
>> 
>> * In Section 7.1 Symmetric Keys, I think the "three ways for
>> communicating this session key" would benefit having bullets or
>> outline numbers.
>> 
>> * In Section 10. Acknowledgements, the second paragraph discusses an
>> appendix tha

Re: [Gen-art] Genart Telechat review draft-ietf-p2psip-diagnostics-19

[Jari Arkko]

Thanks for your review, Alexey!

Authors, what say you?

Jari

On 15 Dec 2015, at 14:23, Alexey Melnikov  wrote:

> I deleted an incorrect recipient in my original review. Sorry about that.
> 
>> On 15 Dec 2015, at 11:19, Alexey Melnikov  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-p2psip-diagnostics-19
>> Reviewer: Alexey Melnikov
>> Review Date: 2015-12-15
>> IETF LC End Date:
>> IESG Telechat date: 2015-12-17
>> 
>> 
>> 
>> Summary: Nearly ready for publication as Proposed Standard
>> 
>> I think this document has a list of issues, but they should be easy to fix:
>> 
>> In Section 5.3:
>> 
>> The dMFlags field described above is a 64 bit field that allows
>>  initiator nodes to identify up to 62 items of base information to
>>  request in a request message (the first and last flags being
>>  reserved).
>> 
>> But the IANA registration section uses flags 1 and doesn't seem to
>> reserve the highest bit either. If this text is now wrong, it should be
>> deleted. If the IANA section is wrong, please fix it. If I am wrong,
>> please tell me :-).
>> 
>> In Section 5.3:
>> 
>> SOFTWARE_VERSION: A single value element containing a US-ASCII
>> string that identifies the manufacture, model, operating system
>> information and the version of the software.  Given that there are
>> very large number of peers in some networks, and no peer is likely
>> to know all other peer’s software, this information may be very
>> useful to help determine if the cause of certain groups of
>> misbehaving peers is related to specific software versions.  While
>> the format is peer-defined, a suggested format is as follows:
>> "ApplicationProductToken (Platform; OS-or-CPU) VendorProductToken
>> (VendorComment)".  For example: "MyReloadApp/1.0 (Unix; Linux
>> x86_64) libreload-java/0.7.0 (Stonyfish Inc.)".  The string is a
>> C-style string, and MUST be delimited by "\0".
>> 
>> Did you mean "terminated"? I don't see what can be delimited, as this
>> implies presence of multiple fields.
>> 
>> "\0" MUST NOT be
>> included in the string itself to prevent confusion with the
>> delimiter.
>> 
>> 
>> 
>> EWMA_BYTES_SENT (32 bits): A single value element containing an
>> unsigned 32-bit integer representing an exponential weighted
>> average of bytes sent per second by this peer. sent = alpha x
>> sent_present + (1 - alpha) x sent where sent_present represents
>> the bytes sent per second since the last calculation and sent
>> represents the last calculation of bytes sent per second.  A
>> suitable value for alpha is 0.8.  This value is calculated every
>> five seconds.
>> 
>> 
>> I don't understand the formula. What is "x"?
>> Should the formula be on its own line for ease of understanding?
>> 
>> BATTERY_STATUS
>> 
>> This flag doesn't seem to be defined in a useful fashion. You need to at
>> least provide some guidance here to insure interoperability.
>> 
>> In Sections 9.3-9.5: is RFC- this document or RFC 6940 (or something
>> else)?
>> 
>> Thank you,
>> Alexey
>> 
>> ___
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> 



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] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Manger, James]

Mike,

draft-ietf-jose-jws-signing-input-options-08 says:

   if used in environments in which all participants implement this extension, 
then "crit" need not be included

The clash here is whether such "environments" are reality, and if they are the 
audience of this IETF spec.
This sentence implies environment-specific JWS code, which rather goes against 
the point of a generic spec.

--
James Manger

-Original Message-
From: Mike Jones [mailto:michael.jo...@microsoft.com] 
Sent: Thursday, 17 December 2015 2:52 PM
To: Manger, James ; Robert Sparks 
; General Area Review Team ; 
j...@ietf.org; Ben Campbell ; Benoit Claise 

Subject: RE: [jose] Gen-Art LC review: 
draft-ietf-jose-jws-signing-input-options-06

James, as I see it, your proposal optimizes the Header Parameter requirements 
for the case in which the JWS isn't useful, rather than case in which it is.  
This seems backwards, from an engineering point of view.

The new "crit" language in -08 already ensures clean failure in all the cases 
in which failure should occur.  There's then no need to include an extra 
parameter intended to cause a failure in cases in which the failure cannot 
occur.

-- Mike

-Original Message-
From: Manger, James [mailto:james.h.man...@team.telstra.com] 
Sent: Thursday, December 17, 2015 3:08 AM
To: Mike Jones ; Robert Sparks 
; General Area Review Team ; 
j...@ietf.org; Ben Campbell ; Benoit Claise 

Subject: RE: [jose] Gen-Art LC review: 
draft-ietf-jose-jws-signing-input-options-06

Mike proposes the following:

   "Using "crit" with "b64"

   If a JWS using "b64" with a value of "false" might be processed by 
implementations not implementing this extension, then the "crit" Header 
Parameter MUST be included with "b64" in its set of values to cause such 
implementations to reject the JWS.  Conversely, if used in environments in 
which all participants implement this extension, then "crit" need not be 
included, since its inclusion would have no effect, other than increasing the 
JWS size and processing costs."


"crit":"xxx" is not needed once everyone understands xxx, for any value of xxx. 
This is the nature of "crit". draft-ietf-jose-jws-signing-input-options is 
precisely the case where "crit" should be used (new messages that can be 
misunderstood by old implementations). If it isn't used here, I doubt it will 
ever get used.

The fact Mike is pushing back so much on using "crit" despite being an author 
of the JWS spec defining "crit" is a sign that "crit" itself is a poor design 
for supporting extensibility. There were alternative versioning mechanisms 
discussed before JWS was published, but "crit" was picked.

Alternative suggested wording:

   The "crit" Header Parameter MUST be included with "b64" in its set of values 
to ensure the JWS is rejected (instead of being misinterpreted) by 
implementations that do not understand this specification.

If people need hope that the 13-char overhead ("crit":"b64",) will not last 
forever, perhaps add the following:

   A future specification might be able to relax this requirement if there is 
another mechanism to prevent misinterpretation, such as another "crit" value 
that also implies "b64" understanding, or the elimination of all old 
implementations.


Please don't add:

   "Implementations receiving JWSs using "b64" with a value of "false" will not 
be able to successful use those JWSs unless they support this extension, since 
they will be unable to obtain the payload value.  ... including "crit" is 
insufficient to enable the receiving implementation to use the JWS; that 
requires supporting this extension."

The last part is too obvious. The first part is either too obvious (if 
"successful" means from the senders point of view) or wrong (as the recipient 
thinks they have been successful when they have actually misinterpreted the 
message).

Please remove method 3: sending a payload with non-base64url chars. This makes 
too many assumptions about how a base64url-decoder will handle unexpected 
chars. Some will reject anything outside A-Za-z0-9-_, others will ignore 
whitespace, others will happily decode +/ and -_, others will ignore =, perhaps 
others ignore any unexpected chars.

--
James Manger

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

Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Mike Jones]

James, as I see it, your proposal optimizes the Header Parameter requirements 
for the case in which the JWS isn't useful, rather than case in which it is.  
This seems backwards, from an engineering point of view.

The new "crit" language in -08 already ensures clean failure in all the cases 
in which failure should occur.  There's then no need to include an extra 
parameter intended to cause a failure in cases in which the failure cannot 
occur.

-- Mike

-Original Message-
From: Manger, James [mailto:james.h.man...@team.telstra.com] 
Sent: Thursday, December 17, 2015 3:08 AM
To: Mike Jones ; Robert Sparks 
; General Area Review Team ; 
j...@ietf.org; Ben Campbell ; Benoit Claise 

Subject: RE: [jose] Gen-Art LC review: 
draft-ietf-jose-jws-signing-input-options-06

Mike proposes the following:

   "Using "crit" with "b64"

   If a JWS using "b64" with a value of "false" might be processed by 
implementations not implementing this extension, then the "crit" Header 
Parameter MUST be included with "b64" in its set of values to cause such 
implementations to reject the JWS.  Conversely, if used in environments in 
which all participants implement this extension, then "crit" need not be 
included, since its inclusion would have no effect, other than increasing the 
JWS size and processing costs."


"crit":"xxx" is not needed once everyone understands xxx, for any value of xxx. 
This is the nature of "crit". draft-ietf-jose-jws-signing-input-options is 
precisely the case where "crit" should be used (new messages that can be 
misunderstood by old implementations). If it isn't used here, I doubt it will 
ever get used.

The fact Mike is pushing back so much on using "crit" despite being an author 
of the JWS spec defining "crit" is a sign that "crit" itself is a poor design 
for supporting extensibility. There were alternative versioning mechanisms 
discussed before JWS was published, but "crit" was picked.

Alternative suggested wording:

   The "crit" Header Parameter MUST be included with "b64" in its set of values 
to ensure the JWS is rejected (instead of being misinterpreted) by 
implementations that do not understand this specification.

If people need hope that the 13-char overhead ("crit":"b64",) will not last 
forever, perhaps add the following:

   A future specification might be able to relax this requirement if there is 
another mechanism to prevent misinterpretation, such as another "crit" value 
that also implies "b64" understanding, or the elimination of all old 
implementations.


Please don't add:

   "Implementations receiving JWSs using "b64" with a value of "false" will not 
be able to successful use those JWSs unless they support this extension, since 
they will be unable to obtain the payload value.  ... including "crit" is 
insufficient to enable the receiving implementation to use the JWS; that 
requires supporting this extension."

The last part is too obvious. The first part is either too obvious (if 
"successful" means from the senders point of view) or wrong (as the recipient 
thinks they have been successful when they have actually misinterpreted the 
message).

Please remove method 3: sending a payload with non-base64url chars. This makes 
too many assumptions about how a base64url-decoder will handle unexpected 
chars. Some will reject anything outside A-Za-z0-9-_, others will ignore 
whitespace, others will happily decode +/ and -_, others will ignore =, perhaps 
others ignore any unexpected chars.

--
James Manger

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

Re: [Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07

[Kathleen Moriarty]

Hi Matt,

Thank you for your review!  The editors will take these comments into
consideration and discuss any updates.  I'll note that the draft was
pulled from the telechat and will likely not go through last call
again until sometime around Buenos Aires due to some other changes
that came up.  You may see this one again.

Thanks,
Kathleen

On Wed, Dec 16, 2015 at 9:28 PM, Matt Miller (mamille2)
 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 treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> .
>
> Document: draft-ietf-oauth-pop-architecture-07
> Reviewer: Matthew A. Miller
> Review Date: 2015-12-16
> IETF LC End Date: 2015-12-15
> IESG Telechat date: 2015-12-17
>
> Summary: Almost ready.
>
> I have several editorial nits, but also a couple of minor concerns that
> I think would improve this document's readability.
>
> I note that idnits complained about the lack of RFC 2119 boilerplate;
> however, I think the text actually used in this document is most
> appropriate and still conveys the intent.  The idnits also complained
> about a reference to an obsolete RFC 5849; however, this reference
> appears to be intentional and necessary.
>
> -
>
> Major issues:
>
> Nnne.
>
> Minor issues:
>
> 1. In Section 1. Introduction, the last paragraph makes it seem the
> document isn't organized properly.  It implies an order to read the
> document that is not reflected in the outline:
>
>  * Section 1
>  * Section 2
>  * Section 3
>  * Section 4
>  * Section 6
>  * Section 7
>  * Section 5
>
> Simply re-ording the document I think causes bigger problems.  While
> the intro hints at the order to read, it makes more sense to me in
> the order it actually is.  Ultimately, for me the problem arises with
> the word "concludes".  It might simply be enough to change the last
> participle from ", and concludes with a requirements list in Section 5."
> to ", and lists requirements in Section 5."
>
> 2. In several places, terms of art are used that have not been defined
> in this document: "resource server", "protected resource", etc.  I
> think it would help if Section 2. indicated where these terms are
> defined or discussed, which is RFC 6749.
>
>
> Nits/editorial comments:
>
> * The reference to draft-ietf-oauth-proof-of-possession-08 should be
> updated to its latest version, although I expect RFC Editor will
> resolve this before publication.
>
> * The reference to RFC 4347 should be updated to 6347; there's no clear
> requirement for the older document.
>
> * In Section 3.1 Preventing Access Token Re-Use by the Resource Server,
> "with other resource server" should be either "with another resource
> server" or "with other resource servers".
>
> * In Section 3.2 TLS and DTLS Channel Binding Support, "entity entity"
> should be "entity".
>
> * In section 3.4 Offering Application Layer End-to-End Security, The
> last sentence of the last paragraph seems out of place.  It seems it
> would be better as the penultimate sentence of the previous paragraph.
>
> * In section 4. Security and Privacy Threats under "Token
> manufacture/modification", "causing resource server" should be "causing
> the resource server".
>
> * Also in Section 4. Security and Privacy Threats under "Token
> manufacture/modification", the normative language here seems out of
> place.  It seems to me that 'may' conveys just as much as 'MAY' for
> how it is used here.
>
> * In Section 5. Requirements under "Prevent the Domino Effect",
> "Resource Server" is capitalized differently than all previous uses,
> but it doesn't seem to be a different use.  I suggest changing it to
> "resource server".
>
> * In Section 6.3. Key Confirmation, uses the term "privacy key" where
> I believe the common nomenclature is "private key".
>
> * In Section 7. Client and Authorization Server Interaction, I find
> most of the figures a little hard to follow.  While I appreciate the
> attempt to go beyond strict perpendicularity, I find it distracting
> from the information it is trying to convey.
>
> * In Section 7.1 Symmetric Keys, I think the "three ways for
> communicating this session key" would benefit having bullets or
> outline numbers.
>
> * In Section 10. Acknowledgements, the second paragraph discusses an
> appendix that borrows content from another document, but there is no
> appendix in this draft.  Is this text still relevant?
>
>
> --
> - m&m
>
> Matt Miller
> Cisco Systems, Inc.
>



-- 

Best regards,
Kathleen

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

[Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07

[Matt Miller (mamille2)]

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-oauth-pop-architecture-07
Reviewer: Matthew A. Miller
Review Date: 2015-12-16
IETF LC End Date: 2015-12-15
IESG Telechat date: 2015-12-17

Summary: Almost ready.

I have several editorial nits, but also a couple of minor concerns that
I think would improve this document's readability.

I note that idnits complained about the lack of RFC 2119 boilerplate;
however, I think the text actually used in this document is most
appropriate and still conveys the intent.  The idnits also complained
about a reference to an obsolete RFC 5849; however, this reference
appears to be intentional and necessary.

-

Major issues:

Nnne.

Minor issues:

1. In Section 1. Introduction, the last paragraph makes it seem the
document isn't organized properly.  It implies an order to read the
document that is not reflected in the outline:

 * Section 1
 * Section 2
 * Section 3
 * Section 4
 * Section 6
 * Section 7
 * Section 5

Simply re-ording the document I think causes bigger problems.  While
the intro hints at the order to read, it makes more sense to me in
the order it actually is.  Ultimately, for me the problem arises with
the word "concludes".  It might simply be enough to change the last
participle from ", and concludes with a requirements list in Section 5."
to ", and lists requirements in Section 5."

2. In several places, terms of art are used that have not been defined
in this document: "resource server", "protected resource", etc.  I
think it would help if Section 2. indicated where these terms are
defined or discussed, which is RFC 6749.


Nits/editorial comments:

* The reference to draft-ietf-oauth-proof-of-possession-08 should be
updated to its latest version, although I expect RFC Editor will
resolve this before publication.

* The reference to RFC 4347 should be updated to 6347; there's no clear
requirement for the older document.

* In Section 3.1 Preventing Access Token Re-Use by the Resource Server,
"with other resource server" should be either "with another resource
server" or "with other resource servers".

* In Section 3.2 TLS and DTLS Channel Binding Support, "entity entity"
should be "entity".

* In section 3.4 Offering Application Layer End-to-End Security, The
last sentence of the last paragraph seems out of place.  It seems it
would be better as the penultimate sentence of the previous paragraph.

* In section 4. Security and Privacy Threats under "Token
manufacture/modification", "causing resource server" should be "causing
the resource server".

* Also in Section 4. Security and Privacy Threats under "Token
manufacture/modification", the normative language here seems out of
place.  It seems to me that 'may' conveys just as much as 'MAY' for
how it is used here.

* In Section 5. Requirements under "Prevent the Domino Effect",
"Resource Server" is capitalized differently than all previous uses,
but it doesn't seem to be a different use.  I suggest changing it to
"resource server".

* In Section 6.3. Key Confirmation, uses the term "privacy key" where
I believe the common nomenclature is "private key".

* In Section 7. Client and Authorization Server Interaction, I find
most of the figures a little hard to follow.  While I appreciate the
attempt to go beyond strict perpendicularity, I find it distracting
from the information it is trying to convey.

* In Section 7.1 Symmetric Keys, I think the "three ways for
communicating this session key" would benefit having bullets or
outline numbers.

* In Section 10. Acknowledgements, the second paragraph discusses an
appendix that borrows content from another document, but there is no
appendix in this draft.  Is this text still relevant?


--
- m&m

Matt Miller
Cisco Systems, Inc.



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] Gen-art LC review of draft-ietf-nfsv4-minorversion2-dot-x-39

[Tom Haynes]

> On Dec 13, 2015, at 4:44 PM, 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-nfsv4-minorversion2-dot-x-39.txt
> Reviewer: Elwyn Davies
> Review Date: 2015-12-13
> IETF LC End Date: 2015-12-09
> IESG Telechat date: (if known) -
> 
> Summary: Ready with nits.  The XDR specification appears to be a superset of 
> the v4.1 XDR specification and combines a correction of the five remaining 
> discrepancies between v4.1 and v4.0bis ( definition and use of the 
> NFS4_OTHER_SIZE constant, addition and use of the ascii_REQUIRED4 type, 
> modification of the typedef of linktext4). The additions of the 4.2 interface 
> appears to match the specification in draft-ietf-nfsv4-minorversion2-39 
> except for two attribute typedef  items mentioned below.  One discrepancy 
> would have no operational effect as the type used in the other draft  is an 
> alias for the type used here but the clone_blksize error changes the size of 
> the type.
> 
> I have checked that the extracted code is accepted by rpcgen and generates 
> files as expected.
> 
> Major issues:
> None
> 
> Minor issues:
> None



Hi Elwyn,

Thanks for the review - sorry for the delay in responding, I’m just now 
surfacing from my job. :-)

Responses inline.

> 
> Nits/editorial comments:
> Observation:  It might be useful to note that this XDR specification is fully 
> upwards compatible with the v4.0bis with the minor exception of the 
> clientaddr4 structure which has been replaced by (strictly, aliased to) 
> netaddr4 which has the same members with the same purposes but the names have 
> changed (r_netid -> na_r_netid, r_addr ->na_r_addr).  This effectively fully 
> reconverges the v4.0bis and v4.1 strands of the XDR.
> 

Shamelessly stolen almost verbatim!

> Line 1145: In draft-ietf-nfsv4-minorversion2-39 we have typedef length4 
> fattr4_space_freed
>whereas in this draft we have   
> typedef uint64_t fattr4_space_freed

Fixed this in the XDR document.

> 
> Line 1149: In draft-ietf-nfsv4-minorversion2-39 we have typedef length4 
> fattr4_clone_blksize
>whereas in this draft we have   
> typedef uint32_t fattr4_clone_blksize


And for this one, I made the change to uint32_t in 
draft-ietf-nfsv4-minorversion2-39 .

Thanks again!
Tom

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

Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Manger, James]

Mike proposes the following:

   "Using "crit" with "b64"

   If a JWS using "b64" with a value of "false" might be processed by 
implementations not implementing this extension, then the "crit" Header 
Parameter MUST be included with "b64" in its set of values to cause such 
implementations to reject the JWS.  Conversely, if used in environments in 
which all participants implement this extension, then "crit" need not be 
included, since its inclusion would have no effect, other than increasing the 
JWS size and processing costs."


"crit":"xxx" is not needed once everyone understands xxx, for any value of xxx. 
This is the nature of "crit". draft-ietf-jose-jws-signing-input-options is 
precisely the case where "crit" should be used (new messages that can be 
misunderstood by old implementations). If it isn't used here, I doubt it will 
ever get used.

The fact Mike is pushing back so much on using "crit" despite being an author 
of the JWS spec defining "crit" is a sign that "crit" itself is a poor design 
for supporting extensibility. There were alternative versioning mechanisms 
discussed before JWS was published, but "crit" was picked.

Alternative suggested wording:

   The "crit" Header Parameter MUST be included with "b64" in its set of values 
to ensure the JWS is rejected (instead of being misinterpreted) by 
implementations that do not understand this specification.

If people need hope that the 13-char overhead ("crit":"b64",) will not last 
forever, perhaps add the following:

   A future specification might be able to relax this requirement if there is 
another mechanism to prevent misinterpretation, such as another "crit" value 
that also implies "b64" understanding, or the elimination of all old 
implementations.


Please don't add:

   "Implementations receiving JWSs using "b64" with a value of "false" will not 
be able to successful use those JWSs unless they support this extension, since 
they will be unable to obtain the payload value.  ... including "crit" is 
insufficient to enable the receiving implementation to use the JWS; that 
requires supporting this extension."

The last part is too obvious. The first part is either too obvious (if 
"successful" means from the senders point of view) or wrong (as the recipient 
thinks they have been successful when they have actually misinterpreted the 
message).

Please remove method 3: sending a payload with non-base64url chars. This makes 
too many assumptions about how a base64url-decoder will handle unexpected 
chars. Some will reject anything outside A-Za-z0-9-_, others will ignore 
whitespace, others will happily decode +/ and -_, others will ignore =, perhaps 
others ignore any unexpected chars.

--
James Manger

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

Re: [Gen-art] [jose] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Mike Jones]

Hi Jim,

Please see my replies to Robert and Richard.  I believe they cover the point 
you're making below.

-- Mike

-Original Message-
From: Jim Schaad [mailto:i...@augustcellars.com] 
Sent: Monday, December 14, 2015 10:42 PM
To: Mike Jones ; 'Robert Sparks' 
; 'General Area Review Team' ; 
i...@ietf.org; j...@ietf.org; draft-ietf-jose-jws-signing-input-opti...@ietf.org
Subject: RE: [jose] Gen-Art LC review: 
draft-ietf-jose-jws-signing-input-options-06

Mike,

This is interesting from a couple of points.

Why would you have an application that uses "b64":false as a parameter.
This is longer and thus would appear to be undesirable from that perspective.  
It might imply that the application is using both true and false for b64, but 
that is something that you have said is not recommended.

It would, of course, be perfectly acceptable to say that crit needs to be 
present only if b64 is true.  This would address your worry about it failing 
for the case of b64:false being included.

Jim

> -Original Message-
> From: jose [mailto:jose-boun...@ietf.org] On Behalf Of Mike Jones
> Sent: Sunday, December 13, 2015 8:05 PM
> To: Robert Sparks ; General Area Review Team 
> ; i...@ietf.org; j...@ietf.org;
draft-ietf-jose-jws-signing-input-
> opti...@ietf.org
> Subject: Re: [jose] Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-
> 06
> 
> Hi Robert,
> 
> You asked "_WHY_ is crit not sufficient? I think that's the thing 
> that's
missing as
> motivation."
> 
> There are two goals we're discussing, which are related:
> (a) Having an application that uses "b64":false work.
> (b) Having an application that receives a JWT with "b64":false not
misinterpret
> the payload content.
> 
> Including "crit":["b64"] would be sufficient to achieve (b), as it 
> would
cause the
> JWS to be rejected by implementations not supporting "b64".  But it 
> does
not
> achieve (a), since the JWS would be rejected.
> 
> In contrast, using an implementation that understands "b64" achieves 
> both
(a)
> and (b) without needing to include "crit".  That's why it's not required.
> 
> Does that make sense now?
> 
>   Best wishes,
>   -- Mike
> 
> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Sunday, December 13, 2015 1:11 PM
> To: Mike Jones ; General Area Review Team 
> ; i...@ietf.org; j...@ietf.org;
draft-ietf-jose-jws-signing-
> input-opti...@ietf.org
> Subject: Re: Gen-Art LC review:
draft-ietf-jose-jws-signing-input-options-06
> 
> Cutting away a bit to focus on the question:
> 
> On 12/12/15 8:32 PM, Mike Jones wrote:
> > Hi Robert.  Thanks for the useful review.  Replies are inline below...
> >
> >> -Original Message-
> 
> >>
> >>
> >> I would have been much more comfortable with a consensus to require
'crit'.
> >> (Count me in the rough if this proceeds with crit being optional).
> >>
> >> I assume there is a strong reason to allow for option 1. Please add 
> >> the motivation for it to the draft, and consider adding a SHOULD 
> >> use
'crit'
> >> requirement if option 1 remains.
> > It's a reasonable request to have the draft say why "crit" isn't
required.  My
> working draft adds the following new paragraph at the end of the 
> security considerations section to do this.  Unless I hear objections, 
> I'll plan on
publishing
> an updated draft with the paragraph shortly.
> >
> > "Note that methods 2 and 3 are sufficient to cause JWSs using this
extension
> to be rejected by implementations not supporting this extension but 
> they
are not
> sufficient to enable JWSs using this extension to be successfully used 
> by applications.
> The conclusion you draw here is not at all obvious.
> _WHY_ is crit not sufficient? I think that's the thing that's missing 
> as
motivation.
> 
> >   Thus, method 1 - requiring support for this extension - is the
preferred
> approach and the only means for this extension to be practically 
> useful to applications. Method 2 - requiring the use of crit -
> while theoretically useful to ensure that confusion between encoded 
> and unencoded payloads cannot occur, is not particularly useful in 
> practice,
since
> method 1 is still required for the extension to be usable. When method 
> 1
is
> employed, method 2 doesn't add any value and since it increases the 
> size
of the
> JWS, its use is not required by this specification."
> >
> >> Nits/editorial comments:
> >>
> >> In the security considerations, the last sentence of the first 
> >> paragraph needs to be simplified. I suggest replacing it with:
> >>
> >> "It then becomes the responsibility of the application to ensure 
> >> that payloads only contain characters that will not cause parsing 
> >> problems for the serialization used, as described in Section 5. The 
> >> application also incurs the responsibility to ensure that the 
> >> payload will not be modified during retransmission.
> > I 

Re: [Gen-art] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Mike Jones]

Hey Richard,

See my reply to Robert and the language being added to the spec.  I believe 
that the text requiring "crit" in all situations other than when it adds no 
value should address the point you're making.

Best wishes,
-- Mike

-Original Message-
From: Richard Barnes [mailto:r...@ipv.sx] 
Sent: Monday, December 14, 2015 5:23 PM
To: Robert Sparks 
Cc: Mike Jones ; General Area Review Team 
; i...@ietf.org; j...@ietf.org; 
draft-ietf-jose-jws-signing-input-opti...@ietf.org
Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

Hey Mike,

tl;dr: I agree "crit" needs to be required.

If I understand you correctly, you're observing that if the receiving 
implementation supports "b64":false, then there's no need for "crit":["b64"], 
so it's proper for the JWS to still verify.  That seems pretty tautological, 
given that the whole point of "crit" is to address implementations that *don't* 
support "b64".

This seems to hearken back to several debates we had in the initial JOSE round, 
where if you had some assumption outside the JOSE spec, then everything was OK. 
 As the SEC ADs pushed back at the time, so I'm pushing back now: The JOSE 
specs need to be themsleves internally consistent.  Yes, if you use "b64" 
without "crit" in a closed community where everyone supports "b64", then you'll 
be OK.  But that's not an interoperable behavior.  If one of these JWSs ever 
leaks
-- by error or malice -- then you're back in the case where you can have 
non-supporting recipients.

You could argue that the impact of interop failure isn't terrible here, because 
it fails closed -- it's unlikely that a signature over $CONTENT will verify 
with regard to base64($CONTENT).  I don't have a concrete attack scenario, but 
this seems to invite confused deputy problems of the same sort that arise in 
XML-DSIG.  Let's not go there.

--Richard


On Mon, Dec 14, 2015 at 11:11 AM, Robert Sparks  wrote:
> Mike -
>
> No, this still doesn't explain why crit is not sufficient.
>
> You are making a bare assertion that using crit doesn't achieve a). I 
> think it does. Please explain (in the draft) why it doesn't.
>
> You are making me guess, but I think you are only trying to avoid 
> having to include the few extra bits in the message. If you've _done_ 
> the work of ensuring all the applications understand using b64 through 
> some out-of-band magic, then including crit will just work. Are you 
> pushing back on anything _but_ the packet-bloat in this case?
>
> If you _haven't_ done this out-of-band work, and you send to a 
> receiver that understands the extension, then a) is achieved. If you 
> send to a receiver that doesn't understand, things _should_ fail - 
> arguably this also achieving a), though I suspect you are wincing at 
> perhaps not having a clear path to recovery in this case?
>
> I really think this boils down to you not wanting to pay the extra few 
> bits in the packet to say "crit".
> if that's not the case, please explain (and again, this needs to be in 
> the draft, not just an email thread).
>
> RjS
>
>
>
>
> On 12/13/15 10:04 PM, Mike Jones wrote:
>>
>> Hi Robert,
>>
>> You asked "_WHY_ is crit not sufficient? I think that's the thing 
>> that's missing as motivation."
>>
>> There are two goals we're discussing, which are related:
>> (a) Having an application that uses "b64":false work.
>> (b) Having an application that receives a JWT with "b64":false not 
>> misinterpret the payload content.
>>
>> Including "crit":["b64"] would be sufficient to achieve (b), as it 
>> would cause the JWS to be rejected by implementations not supporting 
>> "b64".  But it does not achieve (a), since the JWS would be rejected.
>>
>> In contrast, using an implementation that understands "b64" achieves 
>> both
>> (a) and (b) without needing to include "crit".  That's why it's not 
>> required.
>>
>> Does that make sense now?
>>
>> Best wishes,
>> -- Mike
>>
>> -Original Message-
>> From: Robert Sparks [mailto:rjspa...@nostrum.com]
>> Sent: Sunday, December 13, 2015 1:11 PM
>> To: Mike Jones ; General Area Review 
>> Team ; i...@ietf.org; j...@ietf.org; 
>> draft-ietf-jose-jws-signing-input-opti...@ietf.org
>> Subject: Re: Gen-Art LC review:
>> draft-ietf-jose-jws-signing-input-options-06
>>
>> Cutting away a bit to focus on the question:
>>
>> On 12/12/15 8:32 PM, Mike Jones wrote:
>>>
>>> Hi Robert.  Thanks for the useful review.  Replies are inline below...
>>>
 -Original Message-
>>
>> 


 I would have been much more comfortable with a consensus to require 
 'crit'.
 (Count me in the rough if this proceeds with crit being optional).

 I assume there is a strong reason to allow for option 1. Please add 
 the motivation for it to the draft, and consider adding a SHOULD 
 use 'crit'
 requirement if option 1 r

Re: [Gen-art] Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06

[Mike Jones]

Thanks for your thoughtful comments, Robert.  Replies are inline below...

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Monday, December 14, 2015 5:12 PM
> To: Mike Jones ; General Area Review Team
> ; i...@ietf.org; j...@ietf.org; draft-ietf-jose-jws-signing-
> input-opti...@ietf.org
> Subject: Re: Gen-Art LC review: draft-ietf-jose-jws-signing-input-options-06
> 
> Mike -
> 
> No, this still doesn't explain why crit is not sufficient.

I'll plan on adding something along these lines to the draft to explain this:

"Implementations receiving JWSs using "b64" with a value of "false" will not be 
able to successful use those JWSs unless they support this extension, since 
they will be unable to obtain the payload value.  If the JWS includes the 
"crit" Header Parameter with "b64" in the set of values, this will ensure that 
implementations not supporting this extension will reject the JWS, but 
including "crit" is insufficient to enable the receiving implementation to use 
the JWS; that requires supporting this extension."

> You are making a bare assertion that using crit doesn't achieve a). I think it
> does. Please explain (in the draft) why it doesn't.
> 
> You are making me guess, but I think you are only trying to avoid having to
> include the few extra bits in the message. If you've _done_ the work of
> ensuring all the applications understand using b64 through some out-of-
> band magic, then including crit will just work. Are you pushing back on
> anything _but_ the packet-bloat in this case?
> 
> If you _haven't_ done this out-of-band work, and you send to a receiver that
> understands the extension, then a) is achieved. If you send to a receiver that
> doesn't understand, things _should_ fail - arguably this also achieving a),
> though I suspect you are wincing at perhaps not having a clear path to
> recovery in this case?
> 
> I really think this boils down to you not wanting to pay the extra few bits in
> the packet to say "crit".
> if that's not the case, please explain (and again, this needs to be in the 
> draft,
> not just an email thread).

Yes, size matters, but that's not the primary thing that's in play here.  For 
the extension to be useful, all parties using the JWS must implement the 
extension, as explained in the new proposed text above.  And once the JWT with 
the extension is understood, "crit" adds nothing, because it's redundant.  
That's why the draft doesn't require it.

But based on your comments and those of other reviewers, since there seems to 
be demand for it, I plan to add the following text, which I think gets at the 
heart of the issue you're discussing:

"Using "crit" with "b64"

If a JWS using "b64" with a value of "false" might be processed by 
implementations not implementing this extension, then the "crit" Header 
Parameter MUST be included with "b64" in its set of values to cause such 
implementations to reject the JWS.  Conversely, if used in environments in 
which all participants implement this extension, then "crit" need not be 
included, since its inclusion would have no effect, other than increasing the 
JWS size and processing costs."

> RjS

Thanks again, Robert,
-- Mike

> On 12/13/15 10:04 PM, Mike Jones wrote:
> > Hi Robert,
> >
> > You asked "_WHY_ is crit not sufficient? I think that's the thing that's
> missing as motivation."
> >
> > There are two goals we're discussing, which are related:
> > (a) Having an application that uses "b64":false work.
> > (b) Having an application that receives a JWT with "b64":false not
> misinterpret the payload content.
> >
> > Including "crit":["b64"] would be sufficient to achieve (b), as it would 
> > cause
> the JWS to be rejected by implementations not supporting "b64".  But it does
> not achieve (a), since the JWS would be rejected.
> >
> > In contrast, using an implementation that understands "b64" achieves both
> (a) and (b) without needing to include "crit".  That's why it's not required.
> >
> > Does that make sense now?
> >
> > Best wishes,
> > -- Mike
> >
> > -Original Message-
> > From: Robert Sparks [mailto:rjspa...@nostrum.com]
> > Sent: Sunday, December 13, 2015 1:11 PM
> > To: Mike Jones ; General Area Review
> Team
> > ; i...@ietf.org; j...@ietf.org;
> > draft-ietf-jose-jws-signing-input-opti...@ietf.org
> > Subject: Re: Gen-Art LC review:
> > draft-ietf-jose-jws-signing-input-options-06
> >
> > Cutting away a bit to focus on the question:
> >
> > On 12/12/15 8:32 PM, Mike Jones wrote:
> >> Hi Robert.  Thanks for the useful review.  Replies are inline below...
> >>
> >>> -Original Message-
> > 
> >>>
> >>> I would have been much more comfortable with a consensus to require
> 'crit'.
> >>> (Count me in the rough if this proceeds with crit being optional).
> >>>
> >>> I assume there is a strong reason to allow for option 1. 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

> On Dec 7, 2015, at 1:31 PM 12/7/15, Stephane Bortzmeyer  
> wrote:
> 
> On Tue, Dec 01, 2015 at 01:55:46PM +,
> Ralph Droms (rdroms)  wrote
> a message of 128 lines which said:
> 
>> Would you consider adding a little text somewhere to make it clear
>> that the Appendix is intended as a guide to implementors?
> 
> Done,
> 
> 
>> My recommendation to improve the document would be the inclusion of
>> another appendix, describing the algorithm to use if zone cuts are
>> known.
> 
> It already exists, this is the second paragraph of section 2. (The
> ideal case.)

For the inexperienced implementor, a little more detail might be useful.

> But I do not find useful to add more text: for a real resolver, the
> algorithm in appendix A suffices (it works if the zone cuts are known,
> see step 1).
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



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

[Gen-art] Telechat review of draft-ietf-softwire-dslite-mib-12

[Matt Miller (mamille2)]

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-softwire-dslite-mib-12
Reviewer: Matthew A. Miller
Review Date: 2015-12-16
IETF LC End Date: 2015-11-15
IESG Telechat date: 2015-12-17

Summary: ready for publication as a Standards Track document.

I had reviewed the preceding version; that review can be found here:
< http://www.ietf.org/mail-archive/web/gen-art/current/msg12525.html >

This vision addressed all my concerns from the previous review.  I have
no other concerns.

Major issues:

NONE

Minor issues:

NONE

Nits/editorial comments:

NONE


--
- m&m

Matt Miller
Cisco Systems, Inc.



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] Gen-ART Last Call review of draft-ietf-ippm-active-passive-04

[Brian E Carpenter]

Hi Al, yes, that is much better IMHO.

Regards
   Brian

On 17/12/2015 01:48, MORTON, ALFRED C (AL) wrote:
> Thanks for your review, Brian.  I propose:
> 
>We note that [I-D.chen-ippm-coloring-based-ipfpm-framework] proposes
>a method similar to [I-D.tempia-opsawg-p3m], as ippm-list discussion
>revealed.
> 
> hope that does it,
> Al
> 
>> -Original Message-
>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>> Sent: Tuesday, December 15, 2015 8:43 PM
>> To: draft-ietf-ippm-active-passive@ietf.org; General Area Review
>> Team
>> Subject: Gen-ART Last Call review of draft-ietf-ippm-active-passive-04
>>
>> 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-ippm-active-passive-04.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2015-12-16
>> IETF LC End Date: 2015-12-24
>> IESG Telechat date:
>>
>> Summary: Almost ready
>> 
>>
>> Minor Issue:
>> 
>>
>>We note that [I-D.chen-ippm-coloring-based-ipfpm-framework] proposes
>>a method similar to [I-D.tempia-opsawg-p3m], and ippm-list discussion
>>indicates [I-D.chen-ippm-coloring-based-ipfpm-framework] may be
>>covered by the same IPR as [I-D.tempia-opsawg-p3m].
>>
>> I suggest removing the IPR comment. It may be an issue, but not for this
>> draft. We generally avoid taking a position on IPR applicablity (in
>> fact,
>> our lawyer tells us not to do so).

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

[Gen-art] Review: draft-ietf-hip-rfc5204-bis-06

[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-hip-rfc5204-bis-06
Host Identity Protocol (HIP) Rendezvous Extension
Reviewer: Joel M. Halpern
Review Date: 16-Dec-2015
IETF LC End Date: 28-Dec-2015
IESG Telechat date: N/A

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

Major issues:

Minor issues:
Appendix A states that this document was changed by "Added relaying 
of UPDATE packets to support double jump mobility scenario."  Searching 
the document for the word update, I do not find any such relaying 
description.


Nits/editorial comments:

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

Re: [Gen-art] Gen-ART review of

[Ronald Bonica]

Folks,

The authors of this draft have informed me this document is required by the wg 
charter. So, I withdraw any criticisms about this document's limited scope. The 
scope was dictated by the charter.

  Ron


> -Original Message-
> From: Ronald Bonica
> Sent: Tuesday, December 15, 2015 4:01 PM
> To: IETF Gen-ART ; 'draft-ietf-pals-congcons@ietf.org'
> 
> Subject: Gen-ART review of
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> 
> 
> Document:  draft-ietf-pals-congcons-01
> Reviewer:Ron Bonica
> Review Date:  2015-12-15
> IETF LC End Date:  2015-12-15
> IETF Telechat Date:  TBD
> 
> Summary:  This document is ready for publication
> 
> In summary, draft-ietf-congcons-01:
> 
> - applies only to pseudowires that run over something other than MPLS (e.g.,
> GRE)
> - concludes that no additional mechanisms are needed for elastic
> pseudowires
> - concludes that an inelastic pseudowire MAY shutdown when it experiences
> higher-than-acceptable loss, latency or jitter
> - observes that that for TDM PWs, as loss rate increases, higher-than-
> acceptable loss generally occurs before the fixed-rate TDM PW could cause
> serious problems for competing congestion-responsive traffic
> - Therefore, no additional mechanisms are needed for inelastic pseudowires,
> either
> 
> I see nothing objectionable in the draft. However, its scope is extremely
> limited and it conclusions are not earthshattering. Nonetheless, the work is
> sound and deserves publication.
> 
> Major Issues: None
> 
> Minor Issues: None
> 
> Editorial Issues:
> 
> Ron Bonica
> 

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

Re: [Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

[Alexey Melnikov]

Hi Ralph,

On 16/12/2015 16:19, Ralph Droms (rdroms) wrote:

On Dec 16, 2015, at 10:47 AM 12/16/15, Alexey Melnikov 
 wrote:

Hi Ralph,
Thank you for your review. Sorry I missed it earlier.

You're welcome.  Looks like we have agreement on my editorial comments and 
suggestions.  Will the edits you mention below appear in rev -15?

Yes.

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

Re: [Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

[Ralph Droms (rdroms)]

> On Dec 16, 2015, at 10:47 AM 12/16/15, Alexey Melnikov 
>  wrote:
> 
> Hi Ralph,
> Thank you for your review. Sorry I missed it earlier.

You're welcome.  Looks like we have agreement on my editorial comments and 
suggestions.  Will the edits you mention below appear in rev -15?

- Ralph

> 
> On 09/12/2015 20:47, Ralph Droms (rdroms) wrote:
>> Nits/editorial comments:
>> 
>> Nicely written, very clear document.
> Thank you.
>> idnits reports some lines too long and an unused reference.
> I fixed the reference in my copy. I hope RFC Editor can help with lines which 
> are too long.
>> In the third paragraph of the Introduction, I suggest removing the 
>> parentheses and editing the second sentence for clarity; specifically, what 
>> is "SCRAM data"?
> I meant SCRAM requests and responses.
>> You could probably omit the parentheses in the second paragraph of Setion 3, 
>> as well, I'm likely just arguing style.
> Barry picked on this as well, so this was rewritten for clarity.
>> The last sentence of the last paragraph of sectino 3 was unclear to me: 
>> which messages are referred to?
> Message is the same as 'decoded "data" attribute' in the previous sentence. I 
> clarified that.
>> I think, in the phrase "fail the authentication" in the fifth paragraph of 
>> section 8, you are using "fail" as a transitive verb, as in "the client 
>> considers the authentication of the message to have failed"
> ... and does whatever is appropriate in this case. Which might be closing the 
> connection, retrying or trying another (non SCRAM) mechanism.
>> .  If I have that write, I suggest rewriting the containing sentence to 
>> improve the clarity.
> 
> Best Regards,
> Alexey
> 
> 



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] Gem-Art review for draft-ietf-httpauth-scram-auth-14

[Alexey Melnikov]

Hi Ralph,
Thank you for your review. Sorry I missed it earlier.

On 09/12/2015 20:47, Ralph Droms (rdroms) wrote:

Nits/editorial comments:

Nicely written, very clear document.

Thank you.

idnits reports some lines too long and an unused reference.
I fixed the reference in my copy. I hope RFC Editor can help with lines 
which are too long.

In the third paragraph of the Introduction, I suggest removing the parentheses and 
editing the second sentence for clarity; specifically, what is "SCRAM data"?

I meant SCRAM requests and responses.

You could probably omit the parentheses in the second paragraph of Setion 3, as 
well, I'm likely just arguing style.

Barry picked on this as well, so this was rewritten for clarity.

The last sentence of the last paragraph of sectino 3 was unclear to me: which 
messages are referred to?
Message is the same as 'decoded "data" attribute' in the previous 
sentence. I clarified that.

I think, in the phrase "fail the authentication" in the fifth paragraph of section 8, you are using 
"fail" as a transitive verb, as in "the client considers the authentication of the message to 
have failed"
... and does whatever is appropriate in this case. Which might be 
closing the connection, retrying or trying another (non SCRAM) mechanism.

.  If I have that write, I suggest rewriting the containing sentence to improve 
the clarity.


Best Regards,
Alexey


___
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-ippm-active-passive-04

[MORTON, ALFRED C (AL)]

Thanks for your review, Brian.  I propose:

   We note that [I-D.chen-ippm-coloring-based-ipfpm-framework] proposes
   a method similar to [I-D.tempia-opsawg-p3m], as ippm-list discussion
   revealed.

hope that does it,
Al

> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Tuesday, December 15, 2015 8:43 PM
> To: draft-ietf-ippm-active-passive@ietf.org; General Area Review
> Team
> Subject: Gen-ART Last Call review of draft-ietf-ippm-active-passive-04
> 
> 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-ippm-active-passive-04.txt
> Reviewer: Brian Carpenter
> Review Date: 2015-12-16
> IETF LC End Date: 2015-12-24
> IESG Telechat date:
> 
> Summary: Almost ready
> 
> 
> Minor Issue:
> 
> 
>We note that [I-D.chen-ippm-coloring-based-ipfpm-framework] proposes
>a method similar to [I-D.tempia-opsawg-p3m], and ippm-list discussion
>indicates [I-D.chen-ippm-coloring-based-ipfpm-framework] may be
>covered by the same IPR as [I-D.tempia-opsawg-p3m].
> 
> I suggest removing the IPR comment. It may be an issue, but not for this
> draft. We generally avoid taking a position on IPR applicablity (in
> fact,
> our lawyer tells us not to do so).
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art