Hi Tony,
Thank you for your review and valuable feedback. Please see inline:
Original
From: TonyLiviaDatatracker <noreply@xxxxxxxx>
To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>;
Cc: draft-ietf-lsr-ospf-prefix-extended-flags.all@xxxxxxxx <draft-ietf-lsr-ospf-prefix-extended-flags.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;lsr@xxxxxxxx <lsr@xxxxxxxx>;
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.
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.
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
_______________________________________________
OPS-DIR mailing list -- ops-dir@xxxxxxxx
To unsubscribe send an email to ops-dir-leave@xxxxxxxx
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?
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.
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 -- ops-dir@xxxxxxxx
To unsubscribe send an email to ops-dir-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx