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. Thanks, Rob _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
