Re: [Gen-art] Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

[Alissa Cooper]

Robert, thanks for your review. Huaimo, thanks for your responses. I think with 
the final change agreed between Huaimo and IANA, Section 8 should be good to 
go. I entered a No Objection ballot.

Alissa

> On Mar 1, 2018, at 10:43 AM, Robert Sparks  wrote:
> 
> I'm fine with the way you handled all my editorial suggestions.
> 
> I'm still uncomfortable with what you are asking IANA to do. I think at this 
> point you need to have a conversation with your AD.
> 
> As -14 is written, you are trying to put a value in a part of the class 
> names, class numbers, and class types registry at a codepoint that requires 
> "Standards Action" (Range 0-119). Maybe I'm misremembering, but I don't 
> _think_ you can do that with an Experimental document.
> 
> The language you have for the subregistry that you are _NOT_ asking IANA to 
> create at this time still implies that it exists as a registry (with 
> discussions of initial values and future assignment policies). Instead, I 
> think you need something like "During this experiment, the types of the new 
> subobjects are defined by the following table in this document. If the 
> concept proceeds to the standards track, these will move to an IANA 
> maintained registry" or some similar language.
> 
> Again, get your ADs advice on what to do next here.
> 
> RjS
> 
> 
> On 2/28/18 8:18 PM, Huaimo Chen wrote:
>> Hi Robert,
>> 
>> Thank you very much for your time and valuable comments.
>> Answers to them are inline below with prefix [HC].
>> Would you mind reviewing them to see if they address the issues?
>> 
>> Best Regards,
>> Huaimo
>> -Original Message-
>> From: Robert Sparks [mailto:rjspa...@nostrum.com]
>> Sent: Wednesday, February 21, 2018 12:20 PM
>> To: gen-art@ietf.org
>> Cc: i...@ietf.org; t...@ietf.org; 
>> draft-ietf-teas-rsvp-ingress-protection@ietf.org
>> Subject: Genart last call review of 
>> draft-ietf-teas-rsvp-ingress-protection-13
>> 
>> Reviewer: Robert Sparks
>> Review result: Not Ready
>> 
>> 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-teas-rsvp-ingress-protection-13
>> Reviewer: Robert Sparks
>> Review Date: 2018-02-21
>> IETF LC End Date: 2018-03-01
>> IESG Telechat date: 2018-03-08
>> 
>>  Summary: Not Ready for publication as an Experimental RFC
>> 
>> I found this document hard to read. I encourage a significant editorial pass 
>> that focuses on presenting the core ideas early, and simplifies the language 
>> used throughout the document.
>> [HC] We have presented the core ideas early and simplify the language used in
>> the document accordingly.
>> 
>> 
>> Major Issues:
>> 
>> 1) The IANA considerations section is unclear. You ask IANA to put something 
>> in "Class Names, Class Numbers, and Class Types" at 
>> .
>> But there is no registry with that title on that page. (Nor is there a 
>> registry with a structure matching the row you are asking IANA to add.) Did 
>> you mean the registry at 
>> ?
>> [HC] Yes. You are right. We have corrected it in the document.
>> 
>> 
>> If so, the number you are suggesting is in a "Reserved for Private Use" 
>> range.
>> If that _was_ your target, the structure of your requested record does not 
>> match the structure of the existing registry. Please clarify.
>> [HC] We are considering a new C-Type under the existing Protection Class.
>> The related text has be updated accordingly as below:
>> Upon approval of this document, IANA is requested to assign a new
>> Class Type or C-Type under Class Number 37 and Class Name PROTECTION
>> located at > rsvpparameters.xhtml#rsvp-parameters-39>, as follows:
>> 
>> Value Description   Reference
>> - ---   -
>>   4Type 4 INGRESS_PROTECTION   This Document
>> 
>> 
>> The instructions to IANA for what to do when this document moves to the 
>> standards track are inappropriate. You can say that you anticipate that the 
>> future document that moves the idea to the standard track expects to create 
>> a new registry under rsvp-te-parameters, but this document cannot instruct 
>> IANA to do so.
>> [HC] We have revised the text according to your suggestion as below:
>> It is anticipated that the future document that moves the idea to the
>> standard track expects IANA to create and maintain a new registry under
>> PROTECTION object class, Class Number 37, C-Type 4. Initial values for
>> the registry are given below. The 

Re: [Gen-art] Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

[Robert Sparks]

I'm fine with the way you handled all my editorial suggestions.

I'm still uncomfortable with what you are asking IANA to do. I think at 
this point you need to have a conversation with your AD.


As -14 is written, you are trying to put a value in a part of the class 
names, class numbers, and class types registry at a codepoint that 
requires "Standards Action" (Range 0-119). Maybe I'm misremembering, but 
I don't _think_ you can do that with an Experimental document.


The language you have for the subregistry that you are _NOT_ asking IANA 
to create at this time still implies that it exists as a registry (with 
discussions of initial values and future assignment policies). Instead, 
I think you need something like "During this experiment, the types of 
the new subobjects are defined by the following table in this document. 
If the concept proceeds to the standards track, these will move to an 
IANA maintained registry" or some similar language.


Again, get your ADs advice on what to do next here.

RjS


On 2/28/18 8:18 PM, Huaimo Chen wrote:

Hi Robert,

 Thank you very much for your time and valuable comments.
 Answers to them are inline below with prefix [HC].
 Would you mind reviewing them to see if they address the issues?

Best Regards,
Huaimo
-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]
Sent: Wednesday, February 21, 2018 12:20 PM
To: gen-art@ietf.org
Cc: i...@ietf.org; t...@ietf.org; 
draft-ietf-teas-rsvp-ingress-protection@ietf.org
Subject: Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

Reviewer: Robert Sparks
Review result: Not Ready

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-teas-rsvp-ingress-protection-13
Reviewer: Robert Sparks
Review Date: 2018-02-21
IETF LC End Date: 2018-03-01
IESG Telechat date: 2018-03-08

  Summary: Not Ready for publication as an Experimental RFC

I found this document hard to read. I encourage a significant editorial pass 
that focuses on presenting the core ideas early, and simplifies the language 
used throughout the document.
[HC] We have presented the core ideas early and simplify the language used in
the document accordingly.


Major Issues:

1) The IANA considerations section is unclear. You ask IANA to put something in "Class 
Names, Class Numbers, and Class Types" at 
.
But there is no registry with that title on that page. (Nor is there a registry with 
a structure matching the row you are asking IANA to add.) Did you mean the registry 
at 
?
[HC] Yes. You are right. We have corrected it in the document.


If so, the number you are suggesting is in a "Reserved for Private Use" range.
If that _was_ your target, the structure of your requested record does not 
match the structure of the existing registry. Please clarify.
[HC] We are considering a new C-Type under the existing Protection Class.
The related text has be updated accordingly as below:
Upon approval of this document, IANA is requested to assign a new
Class Type or C-Type under Class Number 37 and Class Name PROTECTION
located at , as follows:

Value Description   Reference
- ---   -
   4Type 4 INGRESS_PROTECTION   This Document


The instructions to IANA for what to do when this document moves to the 
standards track are inappropriate. You can say that you anticipate that the 
future document that moves the idea to the standard track expects to create a 
new registry under rsvp-te-parameters, but this document cannot instruct IANA 
to do so.
[HC] We have revised the text according to your suggestion as below:
It is anticipated that the future document that moves the idea to the
standard track expects IANA to create and maintain a new registry under
PROTECTION object class, Class Number 37, C-Type 4. Initial values for
the registry are given below. The future assignments are to be made through
IETF Review.


2) "After one approach is selected, the document SHOULD become proposed standard." is an 
innappropriate use of SHOULD, and doesn't correctly reflect the process that would be followed in 
any case. You could, instead, say "After one approach is selected, a document revising the 
ideas here to reflect that selection and any other items learned from the experiment is expected to 
be submitted for publication on the standards track."
[HC] We have updated the text accordingly as below:
After one approach is 

Re: [Gen-art] Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

[Huaimo Chen]

Hi Robert,

Thank you very much for your time and valuable comments.
Answers to them are inline below with prefix [HC].
Would you mind reviewing them to see if they address the issues?

Best Regards,
Huaimo
-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com] 
Sent: Wednesday, February 21, 2018 12:20 PM
To: gen-art@ietf.org
Cc: i...@ietf.org; t...@ietf.org; 
draft-ietf-teas-rsvp-ingress-protection@ietf.org
Subject: Genart last call review of draft-ietf-teas-rsvp-ingress-protection-13

Reviewer: Robert Sparks
Review result: Not Ready

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-teas-rsvp-ingress-protection-13
Reviewer: Robert Sparks
Review Date: 2018-02-21
IETF LC End Date: 2018-03-01
IESG Telechat date: 2018-03-08

 Summary: Not Ready for publication as an Experimental RFC

I found this document hard to read. I encourage a significant editorial pass 
that focuses on presenting the core ideas early, and simplifies the language 
used throughout the document.
[HC] We have presented the core ideas early and simplify the language used in
the document accordingly.


Major Issues:

1) The IANA considerations section is unclear. You ask IANA to put something in 
"Class Names, Class Numbers, and Class Types" at 
.
But there is no registry with that title on that page. (Nor is there a registry 
with a structure matching the row you are asking IANA to add.) Did you mean the 
registry at 
?
[HC] Yes. You are right. We have corrected it in the document. 


If so, the number you are suggesting is in a "Reserved for Private Use" range.
If that _was_ your target, the structure of your requested record does not 
match the structure of the existing registry. Please clarify.
[HC] We are considering a new C-Type under the existing Protection Class. 
The related text has be updated accordingly as below:
Upon approval of this document, IANA is requested to assign a new
Class Type or C-Type under Class Number 37 and Class Name PROTECTION
located at , as follows:

Value Description   Reference
- ---   -
  4Type 4 INGRESS_PROTECTION   This Document


The instructions to IANA for what to do when this document moves to the 
standards track are inappropriate. You can say that you anticipate that the 
future document that moves the idea to the standard track expects to create a 
new registry under rsvp-te-parameters, but this document cannot instruct IANA 
to do so.
[HC] We have revised the text according to your suggestion as below:
It is anticipated that the future document that moves the idea to the 
standard track expects IANA to create and maintain a new registry under
PROTECTION object class, Class Number 37, C-Type 4. Initial values for 
the registry are given below. The future assignments are to be made through 
IETF Review.


2) "After one approach is selected, the document SHOULD become proposed 
standard." is an innappropriate use of SHOULD, and doesn't correctly reflect 
the process that would be followed in any case. You could, instead, say "After 
one approach is selected, a document revising the ideas here to reflect that 
selection and any other items learned from the experiment is expected to be 
submitted for publication on the standards track."
[HC] We have updated the text accordingly as below:
After one approach is selected, the document will be revised 
to reflect that selection and any other items learned from 
the experiment. The revised document is expected to be submitted 
for publication on the standards track.


3) It is unclear until you get to section 5 (11 pages into the document) which 
elements provide and which elements consume the information in the proposed new 
object. The document is inconsistent about which messages the object can/should 
appear in. Moving the overview of behavior earlier in the document would help.
Simplifying the description of that behavior will help more. Making the other 
sections consistent with what that overview describes is necessary.
[HC] We have corrected the inconsistency and updated the document according to 
your suggestions.


Minor Issues:

a) It is not clear what the difference between source-detect and 
backup-source-detect really are (I agree with the comments in the rtgdir review 
on these sections). In section 2.1, where you say "reliably detect", do you 
really mean "verify"? The detection has already been