Subject: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

From: Martin Vigoureux via Datatracker <[email-masked]>
Date: Mon, 30 Sep 2019 02:53:01 -0700

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/

----------------------------------------------------------------------
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].

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 30 Sep 2019 16:58:13 +0530

Hi Martin,

Thanks for your review, request authors to chime in as needed.

> https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/

Maybe we can add - "...unless explicitly set aside in this document."

> respecting the original rules of 8231, but then I wonder if this document

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

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 30 Sep 2019 20:45:05 +0000

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-masked]> On Behalf Of Dhruv Dhody
Sent: Monday, September 30, 2019 7:28 AM
To: Martin Vigoureux <[email-masked]>
Cc: pce-chairs <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]; Hariharan Ananthakrishnan <[email-masked]>
Subject: Re: Martin Vigoureux's No Objection on draft-ietf-pce-lsp-control-request-09: (with COMMENT)

Hi Martin,

On Mon, Sep 30, 2019 at 3:23 PM Martin Vigoureux via Datatracker <[email-masked]> wrote:
> 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=
> 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=
>
>
>
> "...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].
>

> 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'!

Thanks!
Dhruv