Hi Acee，Tony，
I agree with you, will update in next version. Many thanks!
Best Regards,
Ran
Original
From: AceeLindem <[email protected]>
To: 陈然00080434;
Cc: Mike Bishop via Datatracker <[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>;last-call
<[email protected]>;lsr <[email protected]>;
Date: 2025年03月27日 17:42
Subject: [Last-Call] Re: [OPS-DIR]Opsdir telechat review of
draft-ietf-lsr-ospf-prefix-extended-flags-06
Hi Ran, Tony,
See one inline.
> On Mar 26, 2025, at 12:19 AM, <[email protected]> <[email protected]>
> wrote:
>
> Hi Tony，
> Thank you for your review and valuable feedback. Please see inline:
>
>
> Original
> From: TonyLiviaDatatracker <[email protected]>
> To: [email protected] <[email protected]>;
> Cc: [email protected]
> <[email protected]>;[email protected]
> <[email protected]>;[email protected] <[email protected]>;
> Date: 2025年03月26日 06:13
> Subject: [OPS-DIR]Opsdir telechat review of
> draft-ietf-lsr-ospf-prefix-extended-flags-06
> Reviewer: Tony Li
> Review result: Has Nits
>
> OPSDIR Last Call Review of draft-ietf-lsr-ospf-prefix-extended-flags
>
> Reviewer: Tony Li
> Status: Has Nits
>
> Overall: Ready, but with a few nits.
>
> Details:
>
> Section 2:
>
> 1)
>
> OLD:
> This contains a variable number of 32-bit flags.
>
> NEW:
> This contains a variable number of flags, grouped in 4-octet
> blocks.
>
> Flags, by definition, are a single bit.
> >>Ran: OK. Thanks.
>
> 2) You write:
>
> If any trailing 32-bit block(s) are
> received without any bit being set in it, then the LSA MUST be
> considered malformed.
>
> This seems unnecessarily restrictive. Please consider dropping
> it. Postel's Law says that it should be accepted as it is semantically
> clear. Operationally, this will improve interoperability.
> >>Ran:You mean this sentence should be removed, right?
I agree with Tony that this should be removed. An implementation
could support 1 or more bits in a 32 bit block but they all could be clear./
We shouldn't require this block to be trimmed. Note that this restriction
is not present for the variable length capabilities TLVs in
RFC 7770 (which I added many moons ago).
https://datatracker.ietf.org/doc/html/rfc7770#section-2.4
Thanks,
Acee
>
> Section 5.1.1:
>
> OLD:
> * Bit number (counting from bit 0 as the most significant
> bit)
>
> NEW:
> * Bit number (counting from bit 0 as the most significant bit
> of the first block)
>
> There is no specification of which way the blocks of bits are ordered
> within the TLV. This is a subtle hint that we are consistently being
> big-endian. If you would like to be less subtle, I would also suggest
> explicit wording in section 2. Repeat this change in section 5.2.1 as
> well.
>
> >>Ran: Sure, and we will add the following text to see if it is appropriate:
> The bits are numbered starting from bit 0 as the most significant bit of the
> first 32-bit block.If a Prefix Attribute Flags field's length exceeds 4
> bytes, numbering for the additional bits picks up where the previous 32-bit
> block left off. For example, the most significant bit in the fifth byte of
> an 8-byte Prefix Attribute Flags is referred to as bit 32
>
> Best Regards,
> Ran
>
> _______________________________________________
> OPS-DIR mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--
last-call mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
