Hi Tom, Thanks a lot for your review, the -03 version should address your prior comments. Please log any new comments against the -03 version.
Thanks, Mike. -----Original Message----- From: Pce <pce-boun...@ietf.org> On Behalf Of tom petch Sent: Saturday, February 20, 2021 7:33 AM To: julien.meu...@orange.com Cc: pce@ietf.org Subject: Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp From: Pce <pce-boun...@ietf.org> on behalf of tom petch <ie...@btconnect.com> Sent: 19 February 2021 12:30 To: julien.meu...@orange.com Cc: pce@ietf.org Subject: Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp From: julien.meu...@orange.com <julien.meu...@orange.com> Sent: 18 February 2021 10:35 Hi Tom, Thank you for your valuable feedback. <tp> The more I look, the less I like it. This I-D asks for an error code for missing mandatory TLV, a category which PCE has defined as Error-Type 6 and is referenced by such as pce-vn-association. Why does this I-D put missing mandatory TLV in a different Error-Type? I will raise some more issues next week. Tom Petch Some of the issues you point out are easy to address and we've already requested the authors to revise the I-D accordingly. To fully resolve your concern, could you please point any other specific parts where you feel you have to "interpret the words the way you think they should have been"? If you even have some text to suggest, that could smoothly ease the update. <tp> At a first glance, s.7.1 RFC8697 names three columns for the registry; those names do not appear here. The new association type is given a different identifier in different places. The preferred identifier needs to be nailed down since it is going into IANA forthwith and will be confusing to change thereafter. s.7.2 This requests new error values under Association Error and specifies a Type of 29. RFC8697 specifies a Type of 26 (29 is Path Computation Failure). 'Conflicting SRAG TLV' I find rather vague; conflicting with what? Likewise 'Multiple SRPAG from one LSP' s.7.3 This document defines five new TLVs That is TBD3, TBD4, TBD11, TBD5 and .... RFC8697 specifies the names of the fields in the registry, Those names are not used here. s.3.2 'as of the time of writing' will change its meaning as the I-D progresses; date needed s.4.1 'is only meant to be used' MUST NOT, SHOULD NOT, .....? 'Policy Identifiers uniquely identify.. Policy Identifiers consist of Color.. Endpoint, optionally the policy hame. So if one is Color red, Endpoint NY no policy name and then one is requested for Color red, Endpoint NY, policy name standby that is a different triplet and so valid. Mmm. I can see that being mis-implemented s.4.2 'is meant to strictly correspond' MUST, SHOULD, ? s.5 This document specifies four new TLVs... These five TLVs ..... These five TLVs encode the Policy Identifiers, SR Policy name, Candidate path identifiers, candidate path name and Candidate path preference.. That is five TLV. Wrong! That is four TLV and something completely different. When any of the mandatory TLVs Only one TLV is listed as mandatory SRPOLICY-CPATH-ID. s.5 At most only one .. can be carried and then goes on to describe the carriage of more than one; 'Only one ... SHOULD be present in a ... (whatever identifier you fix on) message. If more than one is present, only the first is processed and subsequent ones are silently discarded. A Normative Reference to an unadopted I-D that expires next week is not a good look:-) Like I said, the word that came to my mind was 'sloppy':-( Tom Petch Thanks, Dhruv & Julien On 17/02/2021 12:46, tom petch wrote: > <snip> > <tp> > I am sure that IANA will cope because they always do, but it will be by > reading between the lines, applying intelligence to what the authors may have > meant, and so on. Editorially this is a poor I-D (as yet), and that quality > verges on the technical aspects. > > Thus 7.3 says the I-D defines five new TLV and lists four; this also occurs > in the body of the I-D. A reader might also notice the absence of TBD2 and > wonder. > > Or the new Association. Thus needs an identifier. Trouble is, the I-D uses > (at least) three different ones; this looseness of terminology can lead to > problems down the line. (MPLS I see as a classic in how not to specify IANA > registries and I see this heading the same way). > > Likewise the identifiers used in s.7 do not match those in current use, a > good way of storing up future trouble. > > Is the specification adequate? Only if you do not take it literally and > interpret the words the way you think they should have been. > > Tom Petch > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
