Hi Dhruv,

> On Oct 20, 2022, at 7:49 AM, Dhruv Dhody <d...@dhruvdhody.com> wrote:

[…snip…]

> ### Section 3.2, paragraph 2
> ```
>      The LSP Extended Flags field is an array of units of 32 flags, to be
>      allocated starting from the most significant bit.  The bits of the
>      LSP Extended Flags field will be assigned by future documents.  This
>      document does not define any flags.  Unassigned flags MUST be set to
>      zero on transmission and MUST be ignored on receipt.  Implementations
>      that do not understand any particular flag MUST ignore the flag.
> ```
> What "unassigned flags" are will change as assignments are made, so this text
> would require implementations to (closely) track IANA assignments. Did you 
> maybe
> mean "flags that an implementation is not supporting" instead?
> 
> Dhruv: I dont think so!
> 
> This text is already covered as part of section 3.1 when describing the LSP 
> Extended Flags with "
> Unassigned bits MUST be set to zero
> 
> on transmission and MUST be ignored on receipt." The text makes sure that the 
> backward compatibility is maintained when we assign new bits. 
> 
> We can remove the text from 3.2 if it seems confusing! 

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.

I don’t think the text as it stands creates any actual risk of 
misunderstanding, you have to wilfully misunderstand it :-) based on a 
legalistically literal reading. But, there is scope for eliminating even that 
tiny ambiguity.

$0.02,

—John
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to