Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Jari Arkko]

Thanks for the review, Jouni!

I see that the newer versions have corrected at least some of the issues 
discussed here; didn’t check all but it seems fine enough now for me to ballot 
no-objection. Which I have done.

Jari

On 19 Aug 2016, at 19:19, Jouni Korhonen  wrote:

> David,
> 
> 8/15/2016, 7:01 AM, Black, David kirjoitti:
>> Hi Jouni,
>> 
>> Three quick responses:
>> 
>> IPv6 NATs - Ah, now I see the concern.  We'll rewrite the middlebox material 
>> on IPv6 zero checksums to avoid using NATs as examples.
>> 
>> The "MUST" for the "MAY" requirement in RFC 6936 (#9) doesn't do anything 
>> aside from telling people to go read that requirement in the context of the 
>> rest of RFC 6936, which seems useful.
>> 
> o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
> known to be
>  congestion-controlled.. I would be interested in knowing how to enforce 
> this “MUST”
>  specifically in the Internet case.
 
 In contrast, this is effectively a rhetorical question - there is no 
 plausible
>>> protocol mechanism to enforce this, as a Congestion-Controlled header flag 
>>> is
>>> about as realistic as the Evil header flag
>> [... snip ...]
>>> Ok. Knowing this MUST has no meaning is real world I would then consider not
>>> having the MUST here.. that would be a waste of precious capital letters ;)
>> 
>> That's not quite right.  There are no protocol means to enforce this, but it 
>> does clearly tell an operator not to do this, which does have meaning in the 
>> real world ;-).
> 
> I kind of agree on that. However, in that case I would reword the use of MUST 
> differently. Since there is no "protocol way" etc to enforce the MUST I would 
> reword text here more clearly as a deployment guidance. Something along lines 
> "a deployment using a default GRE-in-UDP tunnel MUST take any precautions not 
> to forward traffic that is not known to be congestion controlled into the 
> GRE-in-UDP tunnel". Clumsy English but something to that direction..
> 
> - Jouni
> 
> 
>> 
>> Please be patient with us - I'm trying to take vacation this week and have a 
>> bunch of drafts that need attention "in the queue" ahead of this one, so it 
>> may take a couple of weeks to do the editing and post a new version.
>> 
>> Thanks, --David
>> 
>>> -Original Message-
>>> From: Jouni [mailto:jouni.nos...@gmail.com]
>>> Sent: Sunday, August 14, 2016 8:49 PM
>>> To: Black, David
>>> Cc: gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp-
>>> encap@ietf.org
>>> Subject: Re: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
>>> 
>>> Hi David,
>>> 
>>> See inline.
>>> 
>>> 
 On 12 Aug 2016, at 12:25, Black, David  wrote:
 
 Hi Jouni,
 
 Thanks for the review.  I have a few comments as draft shepherd (anything 
 that
>>> I don't comment on below is editorial and will likely just be fixed in the 
>>> next
>>> version):
 
>  - It repeats.. the same statements multiple times.
 
 If you have specific examples of repeated statements that caught your eye,
>>> please let us know.  Otherwise, the response will be "Thank you for your 
>>> input" ;-
>>> ).
>>> 
>>> 
>>> Stuff like this..
>>> 
>>> 1. Introduction:
>>> 
>>>  "This document specifies a generic GRE-in-UDP encapsulation for..”
>>>  ..
>>>  "This document specifies GRE-in-UDP tunnel requirements for two..”
>>>  ..
>>> 
>>> 2. Applicability Statement
>>> 
>>>  "This document specifies GRE-in-UDP tunnel usage in the general..”
>>> 
>>> It is mostly about the writing style - so very subjective. Specifically in 
>>> the Intro
>>> could be condensed into fewer fewer paragraphs. It is more like I’d like to 
>>> see
>>> what this document specifies in one place and not reading multiple 
>>> paragraphs
>>> saying again “this document specifies..”.
>>> 
 
>  - When reading the document I get the feeling it is actually two 
> documents. The
>technical specification (which is very short) and the general 
> deployment
>considerations document. I would have split it to two but that is just 
> me.
 
 Well, that suggests that something important is missing.
 
 As specified in full generality, the GRE-in-UDP protocol is not safe for 
 general
>>> deployment in the public Internet.  Therefore, two different applicability
>>> scenarios are specified in Section 2:
- Default: Restrict the protocol implementation and usage to that which 
 is
>>> safe for general deployment in the public Internet.
- Traffic Managed Controlled Environment (TMCE): Restrict the nature of
>>> the network so that the general protocol is safe to deploy.
 This is why the two specifications have to go together - the protocol spec 
 by
>>> itself is not safe to deploy in the public Internet, and hence needs the
>>> deployment material.  In 20/20 hindsight, I think this should 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-cose-msg-18

[Jim Schaad]

 

 

From: Meral Shirazipour [mailto:meral.shirazip...@ericsson.com] 
Sent: Tuesday, September 27, 2016 11:27 PM
To: draft-ietf-cose-msg@tools.ietf.org; gen-art@ietf.org
Subject: Gen-ART Last Call review of draft-ietf-cose-msg-18

 

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-cose-msg-18

Reviewer: Meral Shirazipour

Review Date: 2016-09-27

IETF LC End Date:  2016-09-28

IESG Telechat date: 2016-09-29

 

 

 

Summary:

This draft is ready to be published as Standards Track RFC but I have some
comments.

 

Major issues:

Minor issues:

 

"

The JOSE working group produced a set of documents

   [RFC7515][RFC7516][RFC7517][RFC7518] using JSON that specified how to

   process encryption, signatures and message authentication (MAC)

   operations, and how to encode keys using JSON.  This document defines

   the CBOR Object Encryption and Signing (COSE) standard which does the

   same thing for the CBOR encoding format.

"

 

Was there a reason to not have multiple documents for CBOR? It would be good
to add this reason to section 1 in the above mentioned paragraph.

 

[JLS] The JOSE documents were divided up in part because the solutions came
into the group separately.  At one point the idea was to think about
combining them later into two documents, but the group ran out of energy
long before we could get to that point.  COSE is a single document in part
to an overreaction to that experience and because it had only a single set
of authors, unlike the JOSE documents.  My original plan was to split it
into two documents before WGLC but the group did not want that to happen.

 

I don't think that since this is an emotional rather than technical reason
for the change that there documenting that fact make sense.

 

 

Nits/editorial comments:

 

-[Page 5], "services for IoT, using CBOR">"services for IoT, and using
CBOR"

[JLS] done

 

-[Page 5], "[RFC7515][RFC7516][RFC7517][RFC7518]" , please check hyperref
for 2nd and 4th reference (they don't appear in html view
https://tools.ietf.org/html/draft-ietf-cose-msg-18)

[JLS] Please speak to the tool developers not me on this.  

 

-[Page 5], "message authentication (MAC)">"Message Authentication Code
(MAC)"

[JLS] done

 

-[Page 6], "There currently is">"There is currently"

[JLS] done

 

-[Page 7], "For this, reason">"For this reason,"

[JLS] done

 

-[Page 8] "this works consider">"this works, consider"

[JLS] done

 

-general, in many section, e.g. 16.2: when listing terms+ definition, it
would be clearer to add ":" in front of the term. 

[JLS] I'll take with the RFC Editor about this.  It is partly a matter of
style.

 

-Section 19.2 refrences to be updated

e.g.

[I-D.greevenbosch-appsawg-cbor-cddl], is not v09

[JLS] Hey - it got published after my draft did - no fair.

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson Research

www.ericsson.com  

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

[Gen-art] Review of draft-ietf-pals-rfc4447bis-05.txt

[Ralph Droms]

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>.
Each review must include a summary statement chosen from or adapted from the 
following list:

This draft is ready for publication as a Standards Track RFC.

I have only two small editorial comments:

Figure 2 appears to be missing a couple of backslashes in the ASCII art drawing.

The sentence "This document has been written to address errata in a previous 
version of this standard.” probably ought to be moved to section 2.  A broader 
statement in the Abstract to the effect that this document is a rewrite of RFC 
4447 for publication as an Internet Standard might be more helpful.

- Ralph

___
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-core-etch-02

[Christer Holmberg]

Hi Peter,

I am happy with your reply, so I'll wait for the updated version of the draft :)

Regards,

Christer

-Original Message-
From: peter van der Stok [mailto:stokc...@xs4all.nl] 
Sent: 28 September 2016 13:34
To: Christer Holmberg 
Cc: draft-ietf-core-etch@tools.ietf.org; gen-art@ietf.org
Subject: Re: Gen-ART review of draft-ietf-core-etch-02

Hi Christer,

Thanks for your suggestions and comments.
A bit late reaction due to holidays.

See my answers below. It is not excluded that my co-author may refine
(improve) my answers.

Peter

Christer Holmberg schreef op 2016-09-20 13:34:
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> 
> 
> Document:   draft-ietf-core-etch-02
> Reviewer:   Christer Holmberg
> 
> Review Date:20 September 2016
> IETF LC End Date:7 September 2016
> IETF Telechat Date: 13 October 2016
> 
> 
> Summary:
> 
> The document is well written, and is almost ready for publication as 
> standards track RFC. However, I have a number of editorial issues that 
> I¹d like the authors to address.
> 
> Major Issues:   None
> 
> Minor Issues:   None
> 
> Editorial Issues:
> 
> 
> Q1 (Abstract):
> 
> The Abstract says:
> 
>   "The existing Constrained Application Protocol (CoAP) 
> methods only allow access to a
>complete resource, not to parts of a resource.²
> 
> I suggest to say ³The CoAP methods  defined in RFC 7252 only 
> allowŠ²Because as possible new CoAP methods are defined in the future, 
> the ³existing methods² statement may no longer be true. This also 
> makes it clear that, when the document was written, RFC 7252 was the 
> only spec you used as input for existing methods.

 True 
> 
> 
> Q2 (Abstract):
> 
> In general, I think the Abstract contains too much detail. Wouldn¹t it 
> be enough to keep the 1st paragraph, and add the first paragraph of 
> section 1?
> 
> Something like:
> 
>   "The Constrained Application Protocol (CoAP) methods defined 
> in RFC 7252 only
>allow access to a complete resource, not to parts of a 
> resource.  In
>case of resources with larger or complex data, or in 
> situations where
>a resource continuity is required, replacing or requesting 
> the whole
>resource is undesirable.  Several applications using CoAP 
> will need
>to perform partial resource accesses.
> 
>This specification defines the new Constrained Application 
> Protocol (CoAP)
>methods, FETCH, PATCH and iPATCH, which are used to access 
> and update parts
>of a resource.²
> 
> The rest of the Abstract text belongs e.g., in the Introduction 
> section, in my opinion.

IMO, you are right, and your suggestion is an improvement 
> 
> 
> Q3 (Introduction):
> 
> I think you need more background text before you start talking about 
> the methods. As suggested in Q2, move some text from the Abstract to 
> the Introduction.

will do, but I like to keep the fetch and patch introductions separate as they 
are.

> 
> 
> Q4 (Section 2):
> 
> The text says: "Implementations MAY use a request body of any content 
> type with the FETCH method;²
> 
> First, I am not sure whether ³MAY² (uppercase) is appropriate here. 
> What
> about saying ³can² och ³may² (lowercase)?

We mean "MAY" as we can envisage different content formats for the future (e.g. 
one including query specifications) and we have a concrete case today.

> 
> Second, would it be better to say ³attach a body² instead of ³use a 
> body²?
 I have no opinion on this, may be Carsten? 
> 
> Third, I think it would be good to add text about "safe and 
> idempotent² also to the Security Considerations section.

That would go to section 1 before section 1.1; to provide the background.

> 
> 
> Q5 (Section 2.2.2):
> 
> Please add reference for Content-Format option.
 section 5.10.3 to be added
> 
> 
> Q6 (Section 2.5):
> 
> Is there a reason this text is not in Section 4?

section 2.5 is about FETCH, while section 4 is about having 3 methods.
Renaming section 4 to "CoAP method set" may help?

> 
> 
> Q7 (Section 2.6):
> 
> First, why not simply calling the section ³Example² or ³FETCH Example²?
> The same comment apply to
> section 3.1 for PATCH/iPATCH examples.

The examples are really simple, and we did not want to raise too high 
expectations.
May be I am over sensitive on this point.
Just " example" will do as well.

> 
> Second, is the first paragraph really Example text? Isn¹t it normative 
> text that should be somewhere else?

I like the suggestion to put it before section 2.1 or generate a separate 
subsection.

> 
> Third, is a reference for JSON needed on first occurrence?

Agree; good catch

> 
> Fourth, I don¹t think you need to say ³might² in the "JSON document 
> that might be returned by 

Re: [Gen-art] Gen-ART review of draft-ietf-core-etch-02

[peter van der Stok]

Hi Christer,

Thanks for your suggestions and comments.
A bit late reaction due to holidays.

See my answers below. It is not excluded that my co-author may refine 
(improve) my answers.


Peter

Christer Holmberg schreef op 2016-09-20 13:34:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Document:   draft-ietf-core-etch-02
Reviewer:   Christer Holmberg

Review Date:20 September 2016
IETF LC End Date:7 September 2016
IETF Telechat Date: 13 October 2016


Summary:

The document is well written, and is almost ready for publication as
standards track RFC. However,
I have a number of editorial issues that I¹d like the authors to 
address.


Major Issues:   None

Minor Issues:   None

Editorial Issues:


Q1 (Abstract):

The Abstract says:

  "The existing Constrained Application Protocol (CoAP) methods
only allow access to a
   complete resource, not to parts of a resource.²

I suggest to say ³The CoAP methods  defined in RFC 7252 only
allowŠ²Because as possible new CoAP methods
are defined in the future, the ³existing methods² statement may no 
longer

be true. This also makes it clear
that, when the document was written, RFC 7252 was the only spec you 
used

as input for existing methods.


 True 



Q2 (Abstract):

In general, I think the Abstract contains too much detail. Wouldn¹t it 
be

enough to keep the 1st paragraph, and
add the first paragraph of section 1?

Something like:

  "The Constrained Application Protocol (CoAP) methods defined 
in

RFC 7252 only
   allow access to a complete resource, not to parts of a
resource.  In
   case of resources with larger or complex data, or in 
situations

where
   a resource continuity is required, replacing or requesting 
the

whole
   resource is undesirable.  Several applications using CoAP 
will

need
   to perform partial resource accesses.

   This specification defines the new Constrained Application
Protocol (CoAP)
   methods, FETCH, PATCH and iPATCH, which are used to access 
and

update parts
   of a resource.²

The rest of the Abstract text belongs e.g., in the Introduction 
section,

in my opinion.


IMO, you are right, and your suggestion is an improvement




Q3 (Introduction):

I think you need more background text before you start talking about 
the

methods. As suggested in Q2, move some
text from the Abstract to the Introduction.


will do, but I like to keep the fetch and patch introductions separate 
as they are.





Q4 (Section 2):

The text says: "Implementations MAY use a request body of any content 
type

with the FETCH method;²

First, I am not sure whether ³MAY² (uppercase) is appropriate here. 
What

about saying ³can² och ³may² (lowercase)?


We mean "MAY" as we can envisage different content formats for the 
future (e.g. one including query specifications) and we have a concrete 
case today.




Second, would it be better to say ³attach a body² instead of ³use a 
body²?

 I have no opinion on this, may be Carsten? 


Third, I think it would be good to add text about "safe and idempotent²
also to the Security Considerations section.


That would go to section 1 before section 1.1; to provide the 
background.





Q5 (Section 2.2.2):

Please add reference for Content-Format option.

 section 5.10.3 to be added



Q6 (Section 2.5):

Is there a reason this text is not in Section 4?


section 2.5 is about FETCH, while section 4 is about having 3 methods.
Renaming section 4 to "CoAP method set" may help?




Q7 (Section 2.6):

First, why not simply calling the section ³Example² or ³FETCH Example²?
The same comment apply to
section 3.1 for PATCH/iPATCH examples.


The examples are really simple, and we did not want to raise too high 
expectations.

May be I am over sensitive on this point.
Just " example" will do as well.



Second, is the first paragraph really Example text? Isn¹t it normative
text that should be somewhere else?


I like the suggestion to put it before section 2.1 or generate a 
separate subsection.




Third, is a reference for JSON needed on first occurrence?


Agree; good catch



Fourth, I don¹t think you need to say ³might² in the "JSON document 
that

might be returned by GET² sentence. It¹s
an example, so simply say "JSON document returned by GET².


agree




Q8 (Section 2 general):

Is there a reason there is no ³Error Handling² subsection for FETCH?


section 2.1 is sufficient in this case, because there are no issues that 
we are aware of.





Q9 (Section 3):

As far as I know, HTTP (and CoAP, I assume) method names are case
insensitive. Even though it sounds cool and trendy, so
you really need to say ³iPATCH², and not ³IPATCH²? Implementers may not
thing that one MUST use lowercase ³i², which I
assume is not correct, and I am not aware of any other 

[Gen-art] Gen-ART Last Call review of draft-ietf-cose-msg-18

[Meral Shirazipour]

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-cose-msg-18
Reviewer: Meral Shirazipour
Review Date: 2016-09-27
IETF LC End Date:  2016-09-28
IESG Telechat date: 2016-09-29



Summary:
This draft is ready to be published as Standards Track RFC but I have some 
comments.

Major issues:
Minor issues:

"
The JOSE working group produced a set of documents
   [RFC7515][RFC7516][RFC7517][RFC7518] using JSON that specified how to
   process encryption, signatures and message authentication (MAC)
   operations, and how to encode keys using JSON.  This document defines
   the CBOR Object Encryption and Signing (COSE) standard which does the
   same thing for the CBOR encoding format.
"

Was there a reason to not have multiple documents for CBOR? It would be good to 
add this reason to section 1 in the above mentioned paragraph.




Nits/editorial comments:

-[Page 5], "services for IoT, using CBOR">"services for IoT, and using CBOR"
-[Page 5], "[RFC7515][RFC7516][RFC7517][RFC7518]" , please check hyperref for 
2nd and 4th reference (they don't appear in html view 
https://tools.ietf.org/html/draft-ietf-cose-msg-18)
-[Page 5], "message authentication (MAC)">"Message Authentication Code 
(MAC)"
-[Page 6], "There currently is">"There is currently"
-[Page 7], "For this, reason">"For this reason,"
-[Page 8] "this works consider">"this works, consider"
-general, in many section, e.g. 16.2: when listing terms+ definition, it would 
be clearer to add ":" in front of the term.
-Section 19.2 refrences to be updated
e.g.
[I-D.greevenbosch-appsawg-cbor-cddl], is not v09

Best Regards,
Meral
---
Meral Shirazipour
Ericsson Research
www.ericsson.com
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art