Rob - Inline.
> -----Original Message----- > From: Rob Wilton (rwilton) <[email protected]> > Sent: Wednesday, September 21, 2022 1:32 AM > To: Les Ginsberg (ginsberg) <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected] > Subject: RE: Robert Wilton's No Objection on > draft-ietf-lsr-isis-rfc5316bis-04: > (with COMMENT) > > Hi Les, > > Please see inline ... > > > -----Original Message----- > > From: Les Ginsberg (ginsberg) <[email protected]> > > Sent: 21 September 2022 05:49 > > To: Rob Wilton (rwilton) <[email protected]>; The IESG <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected]; > > [email protected]; [email protected] > > Subject: RE: Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis- > 04: > > (with COMMENT) > > > > Rob - > > > > Please see inline. > > > > > -----Original Message----- > > > From: Robert Wilton via Datatracker <[email protected]> > > > Sent: Tuesday, September 20, 2022 2:07 AM > > > To: The IESG <[email protected]> > > > Cc: [email protected]; [email protected]; > > > [email protected]; > > > [email protected]; [email protected]; [email protected] > > > Subject: Robert Wilton's No Objection on > > > draft-ietf-lsr-isis-rfc5316bis-04: > > > (with COMMENT) > > > > > > Robert Wilton has entered the following ballot position for > > > draft-ietf-lsr-isis-rfc5316bis-04: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > > > positions/ > > > for more information about how to handle DISCUSS and COMMENT > > > positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > I support Alvaro's discuss. > > > > > [LES:] I have responded to Alvaro - please let me know if my response > > addresses your concern. > > Not really. > > For this scenario having a SHOULD is okay, but it would then be helpful to > describe the exact conditions when that SHOULD isn't effectively a MUST. > But personally, I would find it clearer if the constraint was something like > MUST be the same as TLV 134 when TLV 134 is also advertised. > > But I will let Alvaro carry the Discuss. I.e., if you get agreement from him > (as > a RTG AD) then that will be sufficient for me as well. > > > > > > I would like to thank Menachem for the OPSDIR review. > > > > > [LES:] I addressed Menachem's comments in V4 of the draft. Please let me > > know if those changes are satisfactory. > > Yes, they look fine, thanks. > > > > > > I also have a few minor nits for the authors to consider: > > > > > > (1) p 3, sec 2. Problem Statement > > > > > > Two methods for determining inter-AS paths are currently being > > > discussed. > > > > > > It was unclear what is meant by this, please clarify. I.e., Do you mean > > > described in this document? Or there is ongonig discussion in the WG? > Or > > ... > > > > [LES:] I am unclear as to what is causing your confusion. The text in > > Section > 2 > > states: > > > > "Two methods for determining inter-AS paths are currently being > discussed. > > The per-domain method [RFC5152] determines the path one domain at a > > time. The backward recursive method [RFC5441] uses cooperation > between > > PCEs to determine an optimum inter-domain path. The sections that follow > > examine how inter-AS TE link information could be useful in both cases." > > > > The two methods are explicitly named and an RFC reference provided for > > each. Section 2.2 then discusses the per-domain method in more detail and > > Section 2.3 discusses the backward recursive method in more detail. > > > > Please help me understand why you find this confusing. > > Perhaps it is a difference in interpretation between UK vs US English. As I > said in my comment, I naturally read that sentence to mean that there is > current discussion occurring somewhere (e.g., in a WG), not that the > document is describing two methods. I would find this clearer as "Two > methods for determining inter-AS paths are supported: The per-domain ...", > or something similar. But all my ballot comments are just comments are > hence you are free to ignore it if you wish. > [LES:] OK - thanx - I understand now. At the time RFC 5316 was published one of the methods was still in draft form - so "being discussed" made sense at the time.. Now both are RFCs. I have changed the text to say: "Two methods for determining inter-AS paths have been described elsewhere." Les > Thanks, > Rob _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
