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) <[email protected]> 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" <[email protected]> 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) > <[email protected]> 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, "[email protected]" > <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
