Re: [Gen-art] Genart last call review of draft-ietf-teas-actn-framework-13

[Alissa Cooper]

Peter, thanks for your reviews of this document. Authors, thanks for your 
responses. I have entered a No Objection ballot.

Alissa

> On May 10, 2018, at 11:40 AM, Peter Yee  wrote:
> 
> Works well enough for me.  Thank you again for considering my input.
>  
> -Peter
>  
> On 5/10/18, 8:14 AM, "Leeyoung"  > wrote:
>  
> Hi Peter,
>  
> Thanks for your further comments. It looks like the only remaining issue is 
> the following.
>  
> PEY> Yes, I meant the - and  lines.  They were explicitly defined in 
> Figure 9.  In Figure 10, one has to interpret the text above the figure and 
> intuit the meaning of the line thicknesses ( could be understood from the 
> top part of the diagram, while  requires one to make (reasonable) 
> assumptions based on the text).  If you labeled Figure 10 like you did Figure 
> 9, I think it would make comprehension easier.
>  
> Our resolution is to add as you suggested labels to explain what  and 
>  mean as below in Figure 10:
>  
> Where
>  
>   --- is a link
>   === is a virtual link
>  
> With that change, please review the diff file attached and let us know if all 
> your comments are incorporated in v14 (to be published after your approval). 
>  
> Thanks & Best regards,
> Young and Daniele
>  
> From: Peter Yee [mailto:pe...@akayla.com] 
> Sent: Thursday, May 10, 2018 4:40 AM
> To: Leeyoung ; gen-art@ietf.org
> Cc: draft-ietf-teas-actn-framework@ietf.org; i...@ietf.org; 
> t...@ietf.org; Daniele Ceccarelli 
> Subject: Re: Genart last call review of draft-ietf-teas-actn-framework-13
>  
> Young and Daniele,
>  
> Thanks for addressing my comments.  My apologies for not responding earlier – 
> I’m on the road at the moment.  I’ve made specific responses below prefaced 
> by PEY>.
>  
> Kind regards,
> -Peter
>  
> On 5/4/18, 8:07 AM, "Leeyoung"  > wrote:
>  
> Hi Peter, <>
>  
> Thanks a lot for your thorough review and providing us with a list of good 
> comments. 
>  
> We accepted all your comments and created a diff file for your convenience. 
>  
> Please see DC>> for our response to your comments. 
>  
> Let us know if you have any further comments. Thanks.
>  
> Best regards,
> Young and Daniele
>  
> > -Original Message-
> > From: Peter Yee [mailto:pe...@akayla.com ]
> > Sent: mercoledì 2 maggio 2018 07:21
> > To: gen-art@ietf.org 
> > Cc: draft-ietf-teas-actn-framework@ietf.org 
> > ; i...@ietf.org 
> > ; 
> > t...@ietf.org 
> > Subject: Genart last call review of draft-ietf-teas-actn-framework-13
> > 
> > Reviewer: Peter Yee
> > Review result: Ready with Issues
> > 
> > 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-actn-framework-13
> > Reviewer: Peter Yee
> > Review Date: 2018-05-01
> > IETF LC End Date: 2018-04-30
> > IESG Telechat date: 2018-05-24
> > 
> > Summary: This draft is a framework for taking an abstract look at how 
> > traffic engineered networks can be provisioned and controlled.  There 
> > are some issues with looseness in terms that make it more difficult to 
> > understand than it needs to be. [Ready with issues]
> > 
> > Major issues: None
> > 
> > Minor issues:
> > 
> > Page 12, Figure 2: Figure 1 and the preceding text say that it’s
> > Customer->Service Provider->Network Provider, but then here you have a 
> > Customer->business
> > boundary between a customer and a network provider.  I get that the 
> > model can be recursive, but I find it confusing that you’re discussing 
> > an architecture that throws out the part of the terminology of the 
> > model that was just presented two pages previously.  This is 
> > symptomatic of a problem I have with the looseness of the language in 
> > the document in which terms like (point, node) and (service provider, 
> > network provider, operator) are used interchangeably, even in 
> > contravention of how they are defined in the document.  This makes sections 
> > 2 and 3 somewhat confusing.
> > 
>  
> DC>>  Good point. ACTN is actually solving network operator’s problem – as 
> to how to control TE networks based on abstraction. 
> Since we introduced “operator” and “operations” in Introduction we’d like to 
> change “network provider” to 

Re: [Gen-art] Genart last call review of draft-ietf-tsvwg-iana-dscp-registry-05

[Gorry (erg)]

Happy to make this change - thanks for noting this.

Gorry 

> On 24 May 2018, at 13:44, Spencer Dawkins at IETF 
>  wrote:
> 
> Hi, Christer,
> 
>> On Wed, May 23, 2018 at 1:41 PM Christer Holmberg 
>>  wrote:
>> Reviewer: Christer Holmberg
>> Review result: Almost 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-tsvwg-iana-dscp-registry-05
>> Reviewer: Christer Holmberg
>> Review Date: 2018-05-23
>> IETF LC End Date: 2018-05-25
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary: The document is well written, and almost ready for publication. I 
>> have
>> one minor editorial comment that I'd like the authors to address.
>> 
>> Major issues: None
>> 
>> Minor issues: None
>> 
>> Nits/editorial comments:
>> 
>> The Abstract says:
>> 
>> "This update to RFC2474 changes the IANA assignment method..."
>> 
>> ...and the Introduction says:
>> 
>>  "To allow the IETF to utilise Pool 3 codepoints, this document
>>requests IANA to to manage Pool 3 assignments for DSCP values in Pool
>>3 via the Standards Action policy [RFC8126].  This assignment method
>>requires publication of a Standards Track or Best Current Practice
>>RFC."
>> 
>> I suggest to replace "method" with "policy".
> 
> I think that's right. https://tools.ietf.org/html/rfc8126#section-4 does call 
> these "assignment policies".
> 
> Gorry, if you agree, could you make that change? 
> 
> Thanks,
> 
> Spencer
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-tsvwg-iana-dscp-registry-05

[Spencer Dawkins at IETF]

Hi, Christer,

On Wed, May 23, 2018 at 1:41 PM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:

> Reviewer: Christer Holmberg
> Review result: Almost 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-tsvwg-iana-dscp-registry-05
> Reviewer: Christer Holmberg
> Review Date: 2018-05-23
> IETF LC End Date: 2018-05-25
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: The document is well written, and almost ready for publication. I
> have
> one minor editorial comment that I'd like the authors to address.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
>
> The Abstract says:
>
> "This update to RFC2474 changes the IANA assignment method..."
>
> ...and the Introduction says:
>
>  "To allow the IETF to utilise Pool 3 codepoints, this document
>requests IANA to to manage Pool 3 assignments for DSCP values in Pool
>3 via the Standards Action policy [RFC8126].  This assignment method
>requires publication of a Standards Track or Best Current Practice
>RFC."
>
> I suggest to replace "method" with "policy".
>

I think that's right. https://tools.ietf.org/html/rfc8126#section-4 does
call these "assignment policies".

Gorry, if you agree, could you make that change?

Thanks,

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