Hi Peter, Please see in line.
BR Daniele -----Original Message----- From: Peter Psenak <[email protected]> Sent: den 1 juni 2020 12:15 To: Daniele Ceccarelli <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: Rtgdir last call review of draft-ietf-ospf-te-link-attr-reuse-12 Hi Daniele, please see inline (##PP) On 29/05/2020 18:18, Daniele Ceccarelli via Datatracker wrote: > Reviewer: Daniele Ceccarelli > 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 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > 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-ospf-te-link-attr-reuse-12 > Reviewer: Daniele Ceccarelli > Review Date: 2020-05-29 > IETF LC End Date: date-if-known > Intended Status: Standard Track > > Summary: > > The readibility of the draft has been significantly improved since my > last review (v07), mostly the abstract and the introduction, which now > cleary state what is the scope of the draft. I also appreciated the > introduction of section > 3 where a description of the existing solution is described. > > Minor issues: > - Section 4.1 - Advantages with respect to RSVP-TE are described while > the text speaks about advantages with respect to RSVP-TE and GMPLS, > probably it could be changed into: advantages with respect to RSVP-TE > when used in packet networks and in GMPLS, something like this. ##PP I can change to something like this: "Advantages of Extended Link Opaque LSAs as defined in [RFC7684] for OSPFv2 and Extended Router-LSAs [RFC8362] for OSPFv3 with respect to advertisement of link attributes originally defined for RSVP-TE when used in packet networks and in GMPLS" Would that work? [DC] yes, perfect. > >- Section 5 - Why for the UDABM it doens't say the value MUST be 0,4,8 >but rather says "the legal values are" ? Is 8 octets future-proof >enough? or conversely, if only 3 values are defined why do we need 8 >octects as option? ##PP I have corrected that and use the same text (with MUST) for both SABM and UDABM. [DC] ok We did not limit the size at the beginning, but later due to limited size of ISIS TLVs we limited it to 8 bytes to leave some space for the attributes itself (draft-ietf-isis-te-app). We wanted to keep the consistency between ISIS and OSPF which also helps BGP-LS. 8 octets should be future-proof enough (64 apps). [DC] makes sense. > > >- Section 8 - I really find it hard to understand this small section. ##PP this section says that Extended TE Metrics can be advertised per application as well as application independent and suggests how that can be done. [DC] that's not super clear from the text, but now I understand what's the message that it conveys. I suggest a better phrasing to make it clear. > > Typos: > - Unidirectional Link Dela [RFC7471] ##PP fixed. thanks, Peter > > > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
