Thank you Deborah I'm not entirely convinced. In my view the change is likely to have an impact on existing implementations (error handling part). From that point of view I feel Update wouldn't hurt in the sense that someone implementing 8231 might want to know that impact in advance. But we are down in the foggy subtleties of "Updates". It might more be the case for an "Extends/Extended by".
Thank you for discussing my comment. -m Le 2019-09-30 à 22:45, BRUNGARD, DEBORAH A a écrit : > Hi, > > RFC8231 implementations do not need to be aware of this RFC's capability. > Only for those wanting to support this new capability, they will follow this > RFC. > > As the capability is optional - not required for RFC8231 implementations - to > me that's an "extension", not an "update". > > Thanks! > Deborah > > > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Dhruv Dhody > Sent: Monday, September 30, 2019 7:28 AM > To: Martin Vigoureux <[email protected]> > Cc: pce-chairs <[email protected]>; [email protected]; The IESG <[email protected]>; > [email protected]; Hariharan Ananthakrishnan > <[email protected]> > Subject: Re: Martin Vigoureux's No Objection on > draft-ietf-pce-lsp-control-request-09: (with COMMENT) > > Hi Martin, > > Thanks for your review, request authors to chime in as needed. > > On Mon, Sep 30, 2019 at 3:23 PM Martin Vigoureux via Datatracker > <[email protected]> wrote: >> >> Martin Vigoureux has entered the following ballot position for >> draft-ietf-pce-lsp-control-request-09: 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg >> _statement_discuss-2Dcriteria.html&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r >> =6UhGpW9lwi9dM7jYlxXD8w&m=KTlgQC1T5yVjjuykht4r_tb9Z8KmolfZvjbnrdrTltE& >> s=-lWEB25n3fmFCK0XDlsLE5aD_o2TOZgcVBAwzBsEYDk&e= >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf. >> org_doc_draft-2Dietf-2Dpce-2Dlsp-2Dcontrol-2Drequest_&d=DwIBaQ&c=LFYZ- >> o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=KTlgQC1T5yVjjuykht4r_tb9Z >> 8KmolfZvjbnrdrTltE&s=bK1VoQrU3l_ECgvjAVBHkS2ioansSJs0DE0by5fo3bg&e= >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Hi, >> >> thank you for this document. >> This document indicates: >> "...MUST NOT trigger the error condition for unknown PLSP-ID in an LSP >> update request as per [RFC8231] ...". "...MUST NOT trigger the error >> handling as specified in [RFC8231] ...". >> >> Yet, it also says: >> The procedures for granting and relinquishing control of the LSPs are >> specified in accordance with the specification [RFC8231]. >> > > Maybe we can add - "...unless explicitly set aside in this document." > >> So >> 1/ it seems to me that the latter sentence, considering the first two, >> is not strictly correct. 2/ the rationale is well described, so I'm >> fine with not respecting the original rules of 8231, but then I wonder >> if this document shouldn't update 8231. >> >> > > I am not sure if this rises to the level of "update" (as I understand it and > not taking the ongoing discussion on the topic); to me it is a normal > extension of a protocol 'business as usual'! > > I think maybe it is time for some AD guidance on this :) > > Thanks! > Dhruv > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
