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

["Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Dhruv,

thanks for your answer.

I like your proposed change.

I'll reply to Deborah's e-mail regarding the Update.
On that subject, have you seen:
https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag-01 ?

-m

Le 2019-09-30 à 13:28, Dhruv Dhody a écrit :
> 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
> <[e-mail]> 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://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].
>>
> 
> 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
>