Hi Quan, Thanks for the update. It looks like you missed one item from Lars’ DISCUSS:
#### Section 5, paragraph 2 ``` - not understood by an implementation would be ignored. It is expected - ^^^^^ + not understood by an implementation MUST be ignored. It is expected + ^^^^ ``` If you can push a version 09 with that change, I think we will be good to go. Thanks, —John > On Oct 22, 2022, at 10:55 AM, [email protected] wrote: > > > Hi Lars, John and Dhruv, > > > > Thanks for all your discussions and suggestions! I have updated the draft as > Lars' comments in version -08. > > I revised the texts in line with RFC2119 terminology as Lars' DISCUSS > suggested. > > A sentence was added in Section 3.1, paragraph 7 as Lars' COMMENT with "The > LSP Extended Flags field SHOULD use the minimal amount of space needed to > encode the flag > bits." > > I revised the text in Section 3.2, paragraph 2 as Lars' COMMENT with " > > Flags that an implementation is > not supporting MUST be set to zero on transmission. > > " > > A comma was added in Section 3.1, paragraph 2 as Lars' Nits with "Currently, > no bits are assigned." > > Hope that will help to improve this draft and let me know if you have other > suggestions. > > Thanks, > Quan > > > > > > > > > From: JohnScudder <[email protected]> > To: Dhruv Dhody <[email protected]>; > Cc: Lars Eggert <[email protected]>;The IESG > <[email protected]>;[email protected] > <[email protected]>;[email protected] > <[email protected]>;[email protected] <[email protected]>; > Date: 2022年10月22日 01:14 > Subject: Re: Lars Eggert's Discuss on draft-ietf-pce-lsp-extended-flags-07: > (with DISCUSS and COMMENT) > Hi Dhruv, > > The counterpoint is that if tradition was enough to forbid us from adopting > small improvements, there’d be a lot less progress. But it’s not a big deal, > we can leave it to the discretion of the WG and authors. Regardless, a new > version is needed to address Lars’s DISCUSS — I think all the necessary > conversation has taken place, we just need version 08 with the agreed changes. > > Thanks, > > —John > > > On Oct 21, 2022, at 12:43 AM, Dhruv Dhody <[email protected]> wrote: > > > > > > Thanks John and Lars! > > > > I wonder though if it is a good idea to change in this one place, when > > every other PCEP RFCs (including the base RFC 5440) uses - > > > > Unassigned flags MUST be set to zero on transmission and MUST be > > ignored on receipt. > > > > > > Thanks! > > Dhruv > > > > On Thu, Oct 20, 2022 at 9:04 PM Lars Eggert <[email protected]> wrote: > > On 2022-10-20, at 16:51, John Scudder <[email protected]> wrote: > > > > > > I read this comment differently. Here’s what I took it to mean. In the > > > clause "Unassigned flags MUST be set to zero on transmission”, if you > > > read that in the narrowest possible way, it might require an > > > implementation to know what flags are unassigned, so that it can set them > > > to zero on transmission. If the clause were changed to “Flags unsupported > > > by the implementation MUST be set to zero on transmission” I think that > > > would be responsive to (how I read) the comment. The same point would > > > apply to Section 3.1. > > > > > > That’s just my reading of course and Lars should clarify as needed. > > > > This is exactly what I was trying to express, thanks. > > > > Lars > > > > > > > > > > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
