Re: [Gen-art] Telechat review of draft-ietf-tsvwg-rfc5405bis-18

[Eggert, Lars]

Hi,

thanks for the review!

On 2016-10-11, at 21:21, Paul Kyzivat  wrote:
> (1) NIT: "RTT" is used without definition. (There used to be a definition but 
> it has been removed.)

I think this can be addressed by an RFC Editor Note.

> (2) NIT: unlinked references
> 
> I found a number of cases where, in the html format, references are not 
> hyperlinked:
> 
> [RFC4342] section 3
> [RFC6679] section 3.1.7
> [RFC1981] section 3.2
> [RFC6935] section 3.4.1

As mentioned before, these are due to bugs in the rfcmarkup tool. Please file a 
bug report.

Lars

___
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-avtcore-5761-update-05

[Elwyn Davies]

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-avtcore-5761-update-05.txt
Reviewer: Elwyn Davies
Review Date: 2016/10/11
IETF LC End Date: 2016/09/22
IESG Telechat date: 2016/10/13

Summary: Ready.  Thanks for fixing the couple of nits from last call.


Sent from Samsung tablet.___
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-ipsecme-safecurves-04

[Orit Levin]

Thanks, Yoav!
This addresses all my comments.
Best,
Orit.

-Original Message-
From: Yoav Nir [mailto:ynir.i...@gmail.com] 
Sent: Tuesday, October 11, 2016 12:46 PM
To: Orit Levin 
Cc: draft-ietf-ipsecme-safecurves@ietf.org; General Area Review Team 

Subject: Re: Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Hi, Orit.

I accepted most of your suggestions with a few exceptions below:

> On 28 Sep 2016, at 0:30, Orit Levin  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: review of draft-ietf-ipsecme-safecurves-04
> Reviewer: Orit Levin (mailto:or...@microsoft.com) Review Date: 
> 2016-09-27 IETF LC End Date: 2016-09-29 IESG Telechat date: unknown
> 
> Summary:
> This draft is basically ready for publication, but has nits that should be 
> fixed before publication. The nits are purely editorial, but fixing them will 
> improve the document's readability.
> 
> 1. Introduction
> Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement using 
> Diffie-Hellman".
> Par.2 "That document": Replace with the name of the document to make clear 
> which one is "that" document.
> Par.2 "free from": Replace with "resilient to".
> 
> 2. Curve25519 and Curve448
> Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL 
> follow the steps described in this section."
> Par.1 Replace "are inherited from" with "are compliant with".
> Par.2 Replace "goes as" with "is performed as"
> 
> 3. Use and Negotiation in IKEv2
> Consider replacing TBA1/TBA2 throughout the section with [to be replaced with 
> TBA1/TBA2 according to the IANA assignment].

I have left this as is. This worked for me in the past. I will make sure these 
were replaced during AUTH48.

> 3.2 Consider replace the first sentence with "Receiving and handling 
> of incompatible point formats MUST comply with [or MUST follow] 
> considerations/procedures described in section 5 of [RFC7748].”

I ended up with this:
3.2.  Recipient Tests

   Receiving and handling of incompatible point formats MUST follow the
   considerations described in section 5 of [RFC7748].  In particular,
   receiving entities MUST mask the most-significant bit in the final
   byte for X25519 (but not X448), and implementations MUST accept non-
   canonical values.

> 
> 4. Security Considerations
> Par.1 Replace the paragraph text to
> "For high-performance constant-time implementations, it is RECOMMENDED to use 
> Curve25519 and Curve448 which were designed for this purpose. Implementers 
> MUST/SHOULD NOT attempt to improve performance by reusing supposedly 
> ephemeral key pair across multiple key exchanges [because ...].”

Your suggested text says that reusing ephemeral keys is a bad thing. Reading 
over the original text I can see that it could be interpreted like that. This 
was not our intention. Reusing ephemeral keys is OK. You MUST use a 
constant-time implementation because otherwise each use of the same ephemeral 
key may leak a few bits. So if you are reusing the keys, it is especially 
important to use constant-time implementations, whereas if you only used each 
key once, it would be kind-of OK to use any implementation.  I’ve reworded the 
paragraph as follows:

   Curve25519 and Curve448 are designed to facilitate the production of
   high-performance constant-time implementations.  Implementors are
   encouraged to use a constant-time implementation of the functions.
   This point is of crucial importance especially if the implementation
   chooses to reuse its ephemeral key pair in many key exchanges for
   performance reasons.


> Par.3 In " ... the process used to pick these curves..." replace "these" with 
> the names to avoid confusion.
> Par.3 Replace " ...verification has been done..." with "verification can be 
> done".
> Par.4 Replace ",generated in a fully verifiable way," with "that are 
> generated in a fully verifiable way".
> 
> 6. Acknowledgements
> Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike".
> Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in RFC 
> 7748".
> 
> Thank you,
> Orit.
> 
> 
> 

___
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-ipsecme-safecurves-04

[Yoav Nir]

Hi, Orit.

I accepted most of your suggestions with a few exceptions below:

> On 28 Sep 2016, at 0:30, Orit Levin  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: review of draft-ietf-ipsecme-safecurves-04
> Reviewer: Orit Levin (mailto:or...@microsoft.com) 
> Review Date: 2016-09-27
> IETF LC End Date: 2016-09-29 
> IESG Telechat date: unknown
> 
> Summary:
> This draft is basically ready for publication, but has nits that should be 
> fixed before publication. The nits are purely editorial, but fixing them will 
> improve the document's readability.
> 
> 1. Introduction
> Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement using 
> Diffie-Hellman".
> Par.2 "That document": Replace with the name of the document to make clear 
> which one is "that" document.
> Par.2 "free from": Replace with "resilient to".
> 
> 2. Curve25519 and Curve448
> Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL 
> follow the steps described in this section."
> Par.1 Replace "are inherited from" with "are compliant with".
> Par.2 Replace "goes as" with "is performed as"
> 
> 3. Use and Negotiation in IKEv2
> Consider replacing TBA1/TBA2 throughout the section with [to be replaced with 
> TBA1/TBA2 according to the IANA assignment].

I have left this as is. This worked for me in the past. I will make sure these 
were replaced during AUTH48.

> 3.2 Consider replace the first sentence with 
> "Receiving and handling of incompatible point formats MUST comply with [or 
> MUST follow] considerations/procedures described in section 5 of [RFC7748].”

I ended up with this:
3.2.  Recipient Tests

   Receiving and handling of incompatible point formats MUST follow the
   considerations described in section 5 of [RFC7748].  In particular,
   receiving entities MUST mask the most-significant bit in the final
   byte for X25519 (but not X448), and implementations MUST accept non-
   canonical values.

> 
> 4. Security Considerations
> Par.1 Replace the paragraph text to
> "For high-performance constant-time implementations, it is RECOMMENDED to use 
> Curve25519 and Curve448 which were designed for this purpose. Implementers 
> MUST/SHOULD NOT attempt to improve performance by reusing supposedly 
> ephemeral key pair across multiple key exchanges [because ...].”

Your suggested text says that reusing ephemeral keys is a bad thing. Reading 
over the original text I can see that it could be interpreted like that. This 
was not our intention. Reusing ephemeral keys is OK. You MUST use a 
constant-time implementation because otherwise each use of the same ephemeral 
key may leak a few bits. So if you are reusing the keys, it is especially 
important to use constant-time implementations, whereas if you only used each 
key once, it would be kind-of OK to use any implementation.  I’ve reworded the 
paragraph as follows:

   Curve25519 and Curve448 are designed to facilitate the production of
   high-performance constant-time implementations.  Implementors are
   encouraged to use a constant-time implementation of the functions.
   This point is of crucial importance especially if the implementation
   chooses to reuse its ephemeral key pair in many key exchanges for
   performance reasons.


> Par.3 In " ... the process used to pick these curves..." replace "these" with 
> the names to avoid confusion.
> Par.3 Replace " ...verification has been done..." with "verification can be 
> done".
> Par.4 Replace ",generated in a fully verifiable way," with "that are 
> generated in a fully verifiable way".
> 
> 6. Acknowledgements
> Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike".
> Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in RFC 
> 7748".
> 
> Thank you,
> Orit.
> 
> 
> 

___
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-ipsecme-safecurves-04

[Yoav Nir]

Thanks for that.

For some reason gmail sent this to the spam folder.

Yoav

> On 7 Oct 2016, at 20:32, Kathleen Moriarty  
> wrote:
> 
> Orit,
> 
> Thanks for the review, making sure the editor see this.
> 
> Kathleen
> 
> On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin  > 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: review of draft-ietf-ipsecme-safecurves-04
> Reviewer: Orit Levin (mailto:or...@microsoft.com )
> Review Date: 2016-09-27
> IETF LC End Date: 2016-09-29
> IESG Telechat date: unknown
> 
> Summary:
> This draft is basically ready for publication, but has nits that should be 
> fixed before publication. The nits are purely editorial, but fixing them will 
> improve the document's readability.
> 
> 1. Introduction
> Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement using 
> Diffie-Hellman".
> Par.2 "That document": Replace with the name of the document to make clear 
> which one is "that" document.
> Par.2 "free from": Replace with "resilient to".
> 
> 2. Curve25519 and Curve448
> Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL 
> follow the steps described in this section."
> Par.1 Replace "are inherited from" with "are compliant with".
> Par.2 Replace "goes as" with "is performed as"
> 
> 3. Use and Negotiation in IKEv2
> Consider replacing TBA1/TBA2 throughout the section with [to be replaced with 
> TBA1/TBA2 according to the IANA assignment].
> 3.2 Consider replace the first sentence with
> "Receiving and handling of incompatible point formats MUST comply with [or 
> MUST follow] considerations/procedures described in section 5 of [RFC7748]."
> 
> 4. Security Considerations
> Par.1 Replace the paragraph text to
> "For high-performance constant-time implementations, it is RECOMMENDED to use 
> Curve25519 and Curve448 which were designed for this purpose. Implementers 
> MUST/SHOULD NOT attempt to improve performance by reusing supposedly 
> ephemeral key pair across multiple key exchanges [because ...]."
> Par.3 In " ... the process used to pick these curves..." replace "these" with 
> the names to avoid confusion.
> Par.3 Replace " ...verification has been done..." with "verification can be 
> done".
> Par.4 Replace ",generated in a fully verifiable way," with "that are 
> generated in a fully verifiable way".
> 
> 6. Acknowledgements
> Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike".
> Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in RFC 
> 7748".
> 
> Thank you,
> Orit.
> 
> 
> 
> 
> 
> 
> -- 
> 
> 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-tsvwg-rfc5405bis-18

[Paul Kyzivat]

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-tsvwg-rfc5405bis-18
Reviewer: Paul Kyzivat
Review Date: 2016-10-07
IETF LC End Date: 2016-05-31
IESG Telechat date: 2016-10-13

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Major: 0
Minor: 0
Nits:  2

Issues:

(1) NIT: "RTT" is used without definition. (There used to be a 
definition but it has been removed.)


(2) NIT: unlinked references

I found a number of cases where, in the html format, references are not 
hyperlinked:


[RFC4342] section 3
[RFC6679] section 3.1.7
[RFC1981] section 3.2
[RFC6935] section 3.4.1

___
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-13

[Lorenzo Miniero]

Hello Russ,

sorry for this late reply... thanks for reviewing the document! As to
the points you raised in your review, I've added a couple of comments
inline.


On Mon, 3 Oct 2016 15:26:30 -0400
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-13
> Reviewer: Russ Housley
> Review Date: 2016-10-03
> IETF LC End Date: 2016-10-10
> IESG Telechat date: unknown
> 
> 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.
> 


The standards-track scope of the document was also addressed and
discussed on the STRAW ML before LC, you can find the related
discussion here:

https://www.ietf.org/mail-archive/web/straw/current/msg00579.html 

which lead to no objection to keep the document's scope as it is. Do
you believe the scope should change nevertheless?


> 
> Minor Concerns: In Section 3.1, it says:
> 
>... It SHOULD NOT, though, forward SDP
>attributes that may lead to call failures (e.g., candidates,
>fingerprints, crypto, etc.) for different reasons out of scope to
>this document. ...
> 
> This SHOULD NOT statement if a bit vague.  The previous sentence lists
> specific attributes, and I see why that might be difficult to match
> here, but it does not tell an implementer what attributes to not
> forward.
> 


The SHOULD NOT statement is indeed a bit vague, but that's due to the
dynamic nature of SDP attributes, and the fact that new ones could be
added at any time. We tried to clarify what we meant by listing some of
the categories that, messed with improperly, could cause issues (the
candidates, fingerprints, crypto we mention in brackets), but an
exhaustive list is unfortunately impossible. Do you believe that making
the enumeration in brackets clearer, e.g.:

(e.g., attributes listing candidates, fingerprints, crypto,
etc.)

would make the sentence clearer, or do you still think that would need
work? Do you have any suggestion on how to improve the text here?

Thanks!
Lorenzo

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

Re: [Gen-art] Gen-art LC (and telechat) review for draft-ietf-regext-epp-rdap-status-mapping-01

[Robert Sparks]

Responses inline -


On 10/10/16 10:28 AM, Gould, James wrote:

Robert,

Thank you for your review and feedback.  I provide responses to your 
feedback below.


—


JG




*James Gould
*Distinguished Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com 

On Oct 5, 2016, at 4:58 PM, Robert Sparks > 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-regext-epp-rdap-status-mapping-01
Reviewer: Robert Sparks
Review Date: 5 Oct 2016
IETF LC End Date: 10 Oct 2016
IESG Telechat date: 13 Oct 2016

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


Major Issue:

Many of the descriptions describe only side-effects of the status 
instead of the status itself.


All of the descriptions for the new rdap status codes start with "For 
DNR that indicates". This implies that there is a "For not DNR" case 
that's not discussed. I don't think the phrase is necessary and each 
description should look more like the other descriptions already 
registered at 
http://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml.


For instance, at 'auto renew period' the document currently says:

"For DNR that indicates if the object is deleted by the registrar 
during this period, the registry provides a credit to the registrar 
for the cost of the auto renewal"


That discusses something (and not the only thing) that can happen 
while the object is in that state. It does not describe the state.


I suggest it should instead say (based on the text in 3915 and the 
current registry entry style):


"The object instance is in a grace period provided between when its 
registration period expires and when its registration is 
automatically renewed by the registry."


I don't think it's important to include the commentary about 
providing a credit if the entity is deleted by the registrar during 
this period, but since that commentary exists in 3915, you can 
include it if you want. The _important_ part to convey is the actual 
status.



The “For DNR that indicates” can be removed from the descriptions. 
 For example, the "addPeriod = add period; For DRN that indicates if 
the object is …”  mapping could be "addPeriod = add period; If the 
object is …”.  The purpose of this draft is to map the statuses 
defined in EPP and RDAP, so the status descriptions included in the 
draft where taken from the EPP RFC’s.  There is no intent to redefine 
the statuses included in the EPP RFC’s in anyway.
But you are not including the entire EPP definition for most of these - 
you are only copying in _part_ of it, and it's not the important part.

Looking at -02 of the draft, you currently have this:

   addPeriod = add period;  If the object is deleted by the client
   during this period, the server provides a credit to the client
   for the cost of the registration.

Where did you take the definition out of the EPP suite though?
On a fast skim, I assumed you took it from this statement in RFC3915:

   addPeriod: This grace period is provided after the initial
  registration of a domain name.  If the domain name is deleted by
  the registrar during this period, the registry provides a credit
  to the registrar for the cost of the registration.


You left out "The grace period is provided after the initial 
registration of a domain name" which is what the the status _is_. That's 
what the status code is conveying. The extra words about credit after 
deletion are commentary about things that can happen while the object is 
in that state.


(And you're already changing words by using "the client" instead of "the 
registrar".)


Maybe you took the state definition from some other place?

Many of the other definitions in this document have that same problem.





All of the descriptions will need similar attention. Some of them 
(such as clientUpdateProhibited) currently have 2119 words in the 
description. That doesn't make sense - this is a status, not an 
protocol instruction, and trying to put normative language in a 
registry will lead to confusion about where the behavior you are 
trying to describe is actually defined. (To be fair, 5731 has this 
same problem). Again, I suggest following the style that's already in 
the registry and say something like "The client has requested that 
any requests to update this object instance be rejected."





The clientUpdateProhibited status is defined as:

clientUpdateProhibited = client update prohibited;  For DNR that
indicates the client requested that requests to update the object
(other than to