Re: [RTG-DIR] RtgDir Early Review: draft-ietf-pce-gmpls-pcep-extensions

[<[e-mail]>]

Hi all,

Dave, thank you for this careful review. Though I'd by fine to liaise to
ITU-T SG15 for information, I'm not that sure that our process requires
liaising "for review": PCEP isn't a controversial technology which would
need special treatment with respect to ITU-T. How strong do you feel on
that?

Cyril and authors, please make sure to address Dave's comments.

Cheers,

Julien


On 18/11/2018 14:48, David Sinicrope wrote:
>
> Hello
>
> I have been selected to do a routing directorate “early” review of
> this draft. 
> https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions
>
> The routing directorate will, on request from the working group chair,
> perform an “early” review of a draft before it is submitted for
> publication to the IESG. The early review can be performed at any time
> during the draft’s lifetime as a working group document. The purpose
> of the early review depends on the stage that the document has reached.
>
> As this document is in working group last call, my focus for the
> review was to determine whether the document is ready to be published.
> Please consider my comments along with the other working group last
> call comments.
>
> For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Document: draft-ietf-pce-gmpls-pcep-extensions-12.txt 
> Reviewer: David Sinicrope
> Review Date: November 17, 2018
> Intended Status: Standards Track
>
> *Summary:* 
>
>   * This document is basically ready for publication, but has nits and
>     clarifications that should be considered prior to being submitted
>     to the IESG.
>
> *Comments:*
>
> Although a bit terse on motivation the document is of good quality and
> detail providing the level of information needed for protocol
> specification and implementation.
>
> The comments provided below are aimed at improving readability,
> comprehension and consumption of the document by those that would use
> it for architecture, solution design and implementation.
>
>  
>
> Abstract.  Please provide some detail scope and purpose beyond one
> line.  This is supposed to answer why / whether I should delve into
> the document.
>
>  
>
> General Comments (no particular section)
>
> 1. Given that this document is providing the detail for the
> requirements in 7025, it might be advantageous to the reader to
> structure the document according to the requirements listed in 7025.
>
>  
>
> 2. The document gives a sparse highlight of what extensions are needed
> and why Section 1 and then launches into the details in section2 and
> on.  More elaboration on motivation and gaps and requirements would be
> helpful to better understand why the extensions are needed.
>
>  
>
> 3. This should be liaised to ITUT SG15 Q12 and Q14 for review.  Maybe
> Q11/15 too.
>
>  
>
> Sec 1.2 - RFC 7025 has 13 different requirements listed.  
>
>  
>
> 1. Why are they repeated here and not simply referenced? One must have
> both documents to fully understand the requirements this document is
> addressing, so there is no need to restate (and possibly misstate) the
> agreed requirements here for readability 
>
>  
>
> 2. Why is this only a subset of the requirements in RFC 7025?  Is
> there less covered here than in RFC7025?  If so this must be spelled
> out in terms of coverage.  Perhaps a table to explain the functions
> noted in 7025 vs what this document covers.
>
>  
>
>  
>
> Introduction - this document assumes a significant familiarity with
> rfc7025 and the other documents listed.  It should state this outright.
>
>  
>
>  
>
> Sec 1.3 - please correlate these to the requirements they are
> addressing.  Also please provide more explanation.  Some of these are
> seemingly contradictory the way they are listed currently. E.g.
> END-POINTS and ERO make it sound confused as to whether the 7025
> requirement on unnumbered interfaces is addressed  or not.
>
> Some examples would go a long way to providing clarity
>
> Note: I noted this is done later in the specific extensions, but could
> also be done here.
>
>  
>
> Sec 1.3 - PCEP objects, needs plural
>
>  
>
> Sec 1.3 - they can’t be shortcomings if they were not designed for the
> use noted.  Perhaps “gaps in functional coverage” or “areas for
> enhancement” is a better description.
>
>  
>
> Sec 1.3 - why is the infusion/exclusion of labels a shortcoming? 
> Please elaborate.
>
>  
>
> Sec 1.3 – Protection should be listed with the others “shortcomings”
> right now looks like a summary which it isn’t.  Indent this text.
>
>  
>
> Sec 1.3 covered pcep extensions - covered by what? This document?  If
> so, please say so. Also say/elaborate on why they are needed.  Note: I
> can see this is done much more in the individual sections describing
> the extension.  It would suffice then to add a note here that more
> detail on motivation is provided with each individual extension.
>
>  
>
> Sec 2.2 - excellent cross reference to RFC 7025. I see this is done
> elsewhere.  This makes addressing solution architecture most helpful.
>
> *Nits:*
>
> Miscellaneous warnings:
>
>  
> ----------------------------------------------------------------------------
>
>  
>
>   == Line 1206 has weird spacing: '...ted bit  routi...'
>
>  
>
>   -- The document date (September 27, 2018) is 52 days in the past. 
> Is this
>
>      intentional?
>
>  
>
>  
>
> *From: *DEBORAH BRUNGARD <[e-mail]>
> *Date: *Monday, October 15, 2018 at 12:07 PM
>
>  
>
> Hi Authors (and Shepherd),
>
>  
>
> I thought your document was well written and considering how long we
> have been waiting for this document😊, I have started IETF Last Call.
> I’ve started the IETF Last Call due to the window closing in on the
> next IETF meeting when the other Areas prefer not to have Last Calls
> overlapping. Dave Sinicrope will be the rtg-dir reviewer and will do
> his review in parallel with Last Call.
>
>  
>
> Please be sure to have one of you available as the main pen holder to
> be responsive to Dave, other Area Directorate reviewers comments, and
> IESG comments.
>
>  
>
> Thanks!
>
> Deborah
>
>  
>
>  
>


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.