Re: [Gen-art] Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13

[Suhas Nandakumar (snandaku)]

Hello Dan


 Many thanks for your review. Apologies for the delayed response ( I just got 
back from vacation)


Please see inline for responses to concerns raised (with [[Suhas]] Markings)



Cheers

Suhas Nandakumar


From: Romascanu, Dan (Dan) 
Sent: Monday, August 8, 2016 9:01 AM
To: General Area Review Team
Cc: draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org
Subject: Gen-ART LC review of draft-ietf-mmusic-sdp-mux-attributes-13


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



For more information, please see the FAQ at



https://trac.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-mmusic-sdp-mux-attributes-13

Reviewer: Dan Romascanu

Review Date: 8/8/16

IETF LC End Date: 8/10/16

IESG Telechat date: not known



Summary:



Ready with issues.



Major issues:

1.   My understanding is that this document undertakes the task of 
analyzing the multiplexing characteristics of the SDP attributes and 
classifying them based on this analysis. It also adds one new ‘Multiplexing 
Category’ registry, a ‘Mux Category’ column and new attributes to a number of 
SDP sub-registries. What is not clear to me is what is the process by which new 
attribute values are to be added. The sub-registries in 15.2.x – can new values 
be added? Or new  sub-registries created because of the need to support a new 
protocol that defined SDP attributes? What is the policy and the registration 
process? I hope that my question makes sense, in case it does not, please 
explain why.


[[Suhas]] - Section 15.XXX defines the following ways of dealing with the 
future extensions


a) Adding a new Multiplexing category

   The process here is to have a new specification that explains the new 
Multiplexing category and its purpose in the SDP Attribute multiplexing as 
defined in Section 15.1


b) Adding a new SDP attribute to any of the sub-registries

Any future specifications that defines new SDP attributes must analyze the 
multiplexing characteristics for the newly defined attribute and  specify the 
appropriate "Mux Category" for the same as well.


c) Updating the category assignments  (Say from TBD to something different)

 This needs a new specification with the updated category. (more details 
below)


Section 15.2 and its sub-sections defines how the Mux Category for the SDP 
attributes analyzed in the current draft are added to SDP Parameters IANA 
registry.


please let me know if we need to add more clarifications on any of the above




Minor issues:

1.   The use of B - ‘Both’ terminology used to indicate that an attribute 
is specified S - Session Level and M - Medial Level (e.g. in Section 5) may be 
confusing, as there is a third possible level SR - Source Level. Actually S + M 
would probably be more clear.


[[Suhas]] -- Good point Dan. I see 2 options to progress.


   Option 1 - Same as your suggestion of going with S+M

   Option 2 - Clarify the use of 'B' in Section 5's introductory paragraph as

  *   B -- Both ( implies attribute applies to both the Session and Media level)


The only positive thing about Option 2 is that the changes are minimal. Please 
advice.


2.   Section 5.54 includes a note referring to the TBD content. ‘As per 
section 9.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation],  there exists no 
publicly available specification that defines procedures for 
multiplexing/demultiplexing fax protocols flows over a single 5-tuple.  Once 
such a specification is available, the multiplexing category assignments for 
the attributes in this section could be revisited.’ Assuming the missing 
specification will be publicly available sometime in the future – how will this 
information be added? Revise this RFC? The question applies to other TBD marked 
in the ‘Mux Category’ column of the tables in Section 5 (in 5.42, 5.44, …)


[[Suhas]] -- Section 15 defines the following for adding a totally new 
multiplexing category

"Further entries can be registered on a first-come first-serve basis. Each 
registration needs to indicate the multiplexing category value to be added to 
the "Multiplexing Categories" subregistry as defined in this section.

Such a registration MUST also indicate the applicability of the newly defined 
multiplexing category value to various subregistries defined at "Session 
Description Protocol (SDP) Parameters"



For the attributes marked as "TBD" category,  the introductory paragraph 
mentions the following


" Future specifications can change the "TBD" entries to the correct value."


So the plan  of action would be a new specification will be defined to update 
the "Mux Category" of a given SDP attribute from "TBD" to whatever is 
appropriate. Thus an update to the current draft is not needed but a 

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

[Lucy yong]

Hi Jouni,

David and I work on it to address your comments.

Thanks,
Lucy 

-Original Message-
From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] 
Sent: Thursday, August 18, 2016 10:40 AM
To: Lucy yong; gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

Hi Lucy,

See inline ;)

8/12/2016, 2:10 PM, Lucy yong kirjoitti:
> Hi Jouni,
>
> OOPS, forget this one, sorry.
>
> o My “complaint” of this document is basically on the following.. these are 
> writing
>style things so feel free to neglect:
>- It repeats.. the same statements multiple times.
> Lucy: perhaps some can reference previous section.

See my response to Davin on this. Basically, when you say "this document 
specifies.." etc do not spread that to multiple paragraphs and sections. 
Keep them in one place and not in increamental style spread around.

>- 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.
> Lucy: When we were developing this document, we kindly became clear 
> ourselves, we need to address two parts and want to do in one document.

There's definitely wordsmithing to do here. Now the "guidelines" and protocol 
specification (the very short one) and kind of mixed, which to me makes reading 
a bit confusing experience. If you want to keep all in one document, it is fine 
by me. I was just expressing my personal opinion on structuring.

- JOuni

>
> Regards,
> Lucy
>
>
>
> -Original Message-
> From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
> Sent: Friday, August 12, 2016 1:51 AM
> To: gen-art@ietf.org (gen-art@ietf.org); 
> draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
> Subject: [Gen-art] Generate review of 
> draft-ietf-tsvwg-gre-in-udp-encap-16
>
> 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-tsvwg-gre-in-udp-encap-16
> Reviewer: Jouni Korhonen
> Review Date: 8/11/2016
> IETF LC End Date: 2016-08-12
> IESG Telechat date: (if known)
>
> Summary:  Ready with minor nits.
>
> Major issues: None.
>
> Minor issues: Read on..
>
> Editorials/nits:
>  o My “complaint” of this document is basically on the following.. these are 
> writing
>style things so feel free to neglect:
>- It repeats.. the same statements multiple times.
>- 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.
>
> The other nits.
>
>  o There are bunch of acronyms that are not expanded either never or on their 
> first use.
>Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
> these.
>  o In the Introduction give a reference to EtherType e.g., the repository 
> where they
>are maintained or by whom they are maintained.
>  o On line 129 is says:
>  This document specifies GRE-in-UDP tunnel requirements for two
>Based on the earlier text I would suggest saying “..document also 
> specifies..”
>  o On line 143 I would also (following the previous style in the paragraph) 
> capitalize
>“wide area networks” as well.
>  o In multiple places (lines 236, 887) the reference is after the full stop. 
> Place full
>stop after the reference.
>  o The document uses both tunnel ingress/egress and 
> encapsulator/decapsulator. Is there a
>specific reason to have this differentiation? If not use common 
> terminology throughout
>the document.
>  o On line 654 is says:
>   MUST comply with requirement 1 and 8-10 in Section 5 of
>How is this “MUST” enforced?
>  o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
> of IPv6. If
>you have a specific IPv6 NAT scenario in mind either spell it out or give 
> a reference
>to a specification that describes the technology/use case.
>  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.
>  o Line 909 typo “ether” -> “either”.
>
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Jouni Korhonen]

Hi Lucy,

See inline ;)

8/12/2016, 2:10 PM, Lucy yong kirjoitti:

Hi Jouni,

OOPS, forget this one, sorry.

o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
Lucy: perhaps some can reference previous section.


See my response to Davin on this. Basically, when you say "this document 
specifies.." etc do not spread that to multiple paragraphs and sections. 
Keep them in one place and not in increamental style spread around.



   - 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.
Lucy: When we were developing this document, we kindly became clear ourselves, 
we need to address two parts and want to do in one document.


There's definitely wordsmithing to do here. Now the "guidelines" and 
protocol specification (the very short one) and kind of mixed, which to 
me makes reading a bit confusing experience. If you want to keep all in 
one document, it is fine by me. I was just expressing my personal 
opinion on structuring.


- JOuni



Regards,
Lucy



-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - 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.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use.
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
 o On line 129 is says:
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
 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.
 o Line 909 typo “ether” -> “either”.

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



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

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

[Jouni Korhonen]

Hi Lucy,

Thank you for the response. Sorry for my slow response. I tried to be on 
a vacation last week/weekend so my checking of emails was sparse at best 
;) See inline.


8/12/2016, 1:51 PM, Lucy yong kirjoitti:

Hi Jouni,

Thank you for the review and correction. Pls see inline below.

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - 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.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use.
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
[Lucy] I will check.
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
[Lucy] I will put RFC7042 as the reference.


Or maybe  http://standards.ieee.org/regauth/ethertype/eth.txt
Either one works.


 o On line 129 is says:
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
[Lucy] ack.
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
[Lucy] ack.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
[Lucy] My mistake. Will correct them.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
[Lucy] I would prefer to use two teams in the document. Tunnel ingress and 
egress is the view from network perspective,
And encapsulator/decapsulator is the view at the ingress or egress. E.g. it is 
odd to say encapsulator IP address. I open to add a clarification if that 
causes a concern.


Maybe you should say this also in the draft?



 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
[Lucy] Do you concern on the wording or the implementation?


See the discussion I had with David.



 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
[Lucy] This section describes middlebox specialty on IPv6 traffic. Most UDP 
applications do not perform UDP checksum in IPv4 network; most UDP applications 
perform UDP checksum in IPv6 network because of IPv6 requirement [RFC2460]. 
Thus some middleboxes validate UDP checksum if it is in IPv6. [RFC6935] 
[RFC6936] relax the need to perform UDP checksum in some special cases, which 
is applicable to this draft. But we need to state out the potential impact that 
is specific in IPv6.


Here as well, see the discussion I had with David.


 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.
[Lucy] By IETF standard. :)  How about replace "MUST NOT" with "are not 
appropriate"? (match the wording in requirement 3 of Section 2.1.1)


Again, we did some more elaborations with David. Anyway, one concern I 
had was on having MUSTs on things that you cannot really guard or 
control using some protocol.. they are more like deployment 
recommendations or good wishes at best then.. which I think do not 
belong to a protocol spec.


- JOuni


 o Line 909 typo “ether” -> “either”.
[Lucy] ack. Thx.

Regards,
Lucy

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

Re: [Gen-art] [radext] Gen-ART LC review of draft-ietf-radext-datatypes-04.txt

[Jari Arkko]

Thanks for the review, Dan! And Alan for edits.

Jari




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 review of draft-ietf-kitten-aes-cts-hmac-sha2-10

[Jari Arkko]

Thanks for your review, Vijay.

And you have some good questions… to which I have not seen answers. Authors?

Jari



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] Combined Gen-art and secdir LC review: draft-ietf-manet-smc-sec-threats-05

[Jari Arkko]

Many thanks for your review, Robert.

Jari



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-jose-cfrg-curves-05

[Jari Arkko]

Thanks for your review, Roni!

Authors, did you observe the editorial suggestions?

Jari

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