I went through the other review COMMENTs and the diff, and found two additional
minor points to capture in 09:
1. In Section 9:
OLD:
Object. The documents which will specific these flags must discuss
NEW:
Object. The documents which will specify these flags must discuss
I.e., change “specific” to “specify”. (I know Roman’s review had “specific”,
the minor grammar error is his, but we should fix it.)
2. In his review Paul Wouters had said about Section 9, "It feels that it is
trying to say "these flags are protected by the TLS recommendation", but it
could probably say that a bit more clearly.” I don’t see any changes to take
this on board. It is optional for you to make any change, but if you want to,
you could add one sentence to the end of Section 9, perhaps “If that
recommendation is followed, then the flags will be protected by TLS."
Thanks,
—John
> On Oct 22, 2022, at 1:05 PM, John Scudder <j...@juniper.net> wrote:
>
> 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, xiong.q...@zte.com.cn 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 <j...@juniper.net>
>> To: Dhruv Dhody <d...@dhruvdhody.com>;
>> Cc: Lars Eggert <l...@eggert.org>;The IESG
>> <i...@ietf.org>;draft-ietf-pce-lsp-extended-fl...@ietf.org
>> <draft-ietf-pce-lsp-extended-fl...@ietf.org>;pce-cha...@ietf.org
>> <pce-cha...@ietf.org>;pce@ietf.org <pce@ietf.org>;
>> 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 <d...@dhruvdhody.com> 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 <l...@eggert.org> wrote:
>>> On 2022-10-20, at 16:51, John Scudder <j...@juniper.net> 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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
