Re: [Pce] FW: New Version Notification for draft-stone-pce-local-protection-enforcement-00.txt

["Stone, Andrew (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Dhruv,

Thanks again for your feedback. Document update has been posted: https://tools.ietf.org/rfcdiff?url2=draft-stone-pce-local-protection-enforcement-02.txt

Thanks
Andrew

On 2020-07-27, 9:33 AM, "Dhruv Dhody" <[e-mail]> wrote:

    Hi Andrew,

    From my point of view, to mark "updates RFC", you need to -
    - Update the metadata (https://tools.ietf.org/html/rfc7322#section-4.1.4)
    - Mention that you are updating the RFC 5440 in your abstract/introduction
    - Clarify what text is being updated in RFC 5440 and provide the updated text
    - Backward compatibility

    One easy reference would be to look at the recent RFC 8786 that
    updates RFC 8231.

    Not sure about a process document that describes these. I remember
    there was another individual draft to clarify on what it means to
    update an RFC and have more descriptive tags - update/amend/extend an
    RFC but we could ignore that for now :)

    Dhruv


    On Mon, Jul 27, 2020 at 6:17 PM Stone, Andrew (Nokia - CA/Ottawa)
    <[e-mail]> wrote:
    >
    > Hi Dhruv,
    >
    > Thanks for the feedback.
    >
    > The documents aim is extending new functionality, with also adding additional language to implementation behaviour of the existing flag so I suppose it would be an update to RFC5440. Are there other differences to make, other than xml meta data in the document to indicate it updates RFC5440?  (if there's a link that describes that is required that you can point me to that would be appreciated).
    >
    > Regarding backwards compatibility, good point: the doc includes PCC backwards compatibility comments in section 5 but does indeed not discuss PCE backwards compatibility. From my point of view, I don't see a capability exchange being required. I see support of 'L' flag being an independent interop clarification and 'E' flag being similar to adding another kind of 'constraint' to a path.  I don't think would require a capability exchange to inform the PCC whether or not pce supports a given constraint type. I think the important thing is an existing pce would not error out if it did receive 'E' flag set, and fortunately RFC5440 has that covered with 'Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.'  I'll add a remark in the document that comments on this.
    >
    > Thanks again,
    > Andrew
    >
    > On 2020-07-26, 8:06 AM, "Dhruv Dhody" <[e-mail]> wrote:
    >
    >     Hi Andrew,
    >
    >     Do you think an update to RFC 5440 is required (with meta-data set in
    >     the document header)?
    >     Based on the description of the flag field it feels like an update
    >     would be needed -
    >
    >       o  L flag: As defined in [RFC5440] and further updated by this
    >           document.  When set, protection is desired.  When not set,
    >           protection is not desired.  The enforcement of the protection is
    >           identified via the E-Flag.
    >
    >
    >     BTW, thanks for section 4 it helps!
    >
    >     Maybe add an explicit backward compatibility section. Consider a PCC
    >     that supports your extension, and sets the E flag to 1 and a PCE that
    >     does not support your extension will ignore it and behave as before
    >     and thus not enforce local protection, and there would be no way for
    >     the PCC to know about it! Not sure if we need some sort of capability
    >     exchange here?
    >
    >     Thanks!
    >     Dhruv
    >
    >     On Fri, Mar 6, 2020 at 10:45 PM Stone, Andrew (Nokia - CA/Ottawa)
    >     <[e-mail]> wrote:
    >     >
    >     > Hi PCE WG,
    >     >
    >     > This draft was updated to include the following:
    >     >
    >     > - Draft renamed to reflect this is for "local" protection enforcement (used to be called path-protection)
    >     > - new co author
    >     > - Added more text regarding the various use cases / why a user may want these options
    >     > - Added text discussing situations of no preference / "no not care"
    >     >
    >     > Thanks
    >     > Andrew
    >     >
    >     >
    >     >
    >     > On 2020-03-02, 11:32 AM, "[e-mail]" <[e-mail]> wrote:
    >     >
    >     >
    >     >     A new version of I-D, draft-stone-pce-local-protection-enforcement-00.txt
    >     >     has been successfully submitted by Andrew Stone and posted to the
    >     >     IETF repository.
    >     >
    >     >     Name:               draft-stone-pce-local-protection-enforcement
    >     >     Revision:   00
    >     >     Title:              Local Protection Enforcement in PCEP
    >     >     Document date:      2020-03-02
    >     >     Group:              Individual Submission
    >     >     Pages:              8
    >     >     URL:            https://www.ietf.org/internet-drafts/draft-stone-pce-local-protection-enforcement-00.txt
    >     >     Status:         https://datatracker.ietf.org/doc/draft-stone-pce-local-protection-enforcement/
    >     >     Htmlized:       https://tools.ietf.org/html/draft-stone-pce-local-protection-enforcement-00
    >     >     Htmlized:       https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement
    >     >
    >     >
    >     >     Abstract:
    >     >        This document aims to clarify existing usage of the local protection
    >     >        desired bit signalled in Path Computation Element Protocol (PCEP).
    >     >        This document also introduces a new flag for signalling protection
    >     >        strictness in PCEP.
    >     >
    >     >
    >     >
    >     >
    >     >     Please note that it may take a couple of minutes from the time of submission
    >     >     until the htmlized version and diff are available at tools.ietf.org.
    >     >
    >     >     The IETF Secretariat
    >     >
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > Pce mailing list
    >     > [e-mail]
    >     > https://www.ietf.org/mailman/listinfo/pce
    >