Re: [mpls] Rtgdir last call review of draft-ietf-mpls-rfc6374-sfl-08

["BRUNGARD, DEBORAH A" <[e-mail]>]

Much thanks Andy for your careful review-

Stewart - I agree can address these comments with other Last Call comments. The only comment which I noted, it would be good to expand a bit on the security section, but that also can be done when resolving Last Call comments as I'm sure we will have feedback on it.

I started IETF Last Call.

Thanks-
Deborah

-----Original Message-----
From: mpls <[e-mail]> On Behalf Of Stewart Bryant
Sent: Tuesday, December 29, 2020 10:48 AM
To: Andy Smith <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Stewart Bryant <[e-mail]>; Last Call <[e-mail]>
Subject: Re: [mpls] Rtgdir last call review of draft-ietf-mpls-rfc6374-sfl-08

Thank you

I will address  these when I resolve any other other LC comments.

Best regards

Stewart


> On 28 Dec 2020, at 21:23, Andy Smith via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Andy Smith
> Review result: Has Nits
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing ADs.
> For more information about the Routing Directorate, please see
> https://urldefense.com/v3/__http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir__;!!BhdT!36dEscgRCKrNiwTQMMxJ9wN5MoF_Ndcxp4zI9e_JtHVp8o7OtYuoofJbydBYN2w$ 
> 
> Although these comments are primarily for the use of the Routing ADs, it would
> be helpful if you could consider them along with any other IETF Last Call
> comments that you receive, and strive to resolve them through discussion or by
> updating the draft.
> 
> Document: draft-ietf-mpls-rfc6374-sfl-08.txt
> Reviewer: Andy Smith
> Review 28 December 2020
> IETF LC End Date: date-if-known
> Intended Status: Proposed Standard
> 
> Summary:
> 
> This document is basically ready for publication, but has nits that should be
> considered prior to publication.
> 
> Comments:
> 
> The document is easy to follow.   It is a novel idea that solves a reasonable
> to understand problem.
> 
> Major Issues:
> 
> Nothing obvious.
> 
> Minor Issues:
> 
> Section 5:
> 
> This it is proposed -> Thus it is proposed
> 
> Section 6:
> 
> large set of overlapping measurement type -> large set of overlapping
> measurement types
> 
> "increased operation and capital cost" -> do you really want to make this
> claim?   If so need to quantify it.
> 
> Section 7.1:
> 
> "when a packet had a delay relative to its predecessor of 2us both the up to
> 1us and the 2us counter"   doesn't make sense.  reword
> 
> Section 7.2:
> 
> "Characteristic’s 1 and 2"   no apostrophe needed
> 
> Section 7.3:
> 
> "create a large demand on storage in the instrumentation system" -> quantify
> this if this claim is going to be made
> 
> Section 9.1:
> 
> "Editor’s Note we" - Clarify who 'we' is.  The authors?  the WG?   don't use
> first person.
> 
> Nits:
> 
> A number of run-on sentences are in the document, especially in the
> Introduction.   While not fatal, it makes it a chore to read in parts.  
> Consider breaking some long sentences apart.
> 
> There is a lack of comma usage throughout the document, a nit, but hurts
> readability.
> 
> 
> 

_______________________________________________
mpls mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!BhdT!36dEscgRCKrNiwTQMMxJ9wN5MoF_Ndcxp4zI9e_JtHVp8o7OtYuoofJb6WGDRPY$