Re: [Teas] Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Les,

Thanks for accommodating.

Regards,
Rob


> -----Original Message-----
> From: Les Ginsberg (ginsberg) <[e-mail]>
> Sent: 21 September 2022 14:32
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-04:
> (with COMMENT)
> 
> Rob -
> 
> Inline.
> 
> > -----Original Message-----
> > From: Rob Wilton (rwilton) <[e-mail]>
> > Sent: Wednesday, September 21, 2022 1:32 AM
> > To: Les Ginsberg (ginsberg) <[e-mail]>; The IESG
> <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > 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) <[e-mail]>
> > > Sent: 21 September 2022 05:49
> > > To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> > > Cc: [e-mail]; [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > 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 <[e-mail]>
> > > > Sent: Tuesday, September 20, 2022 2:07 AM
> > > > To: The IESG <[e-mail]>
> > > > Cc: [e-mail]; [e-mail];
> [e-mail];
> > > > [e-mail]; [e-mail]; [e-mail]
> > > > 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