Hi Ran, Tony, See one inline.
> On Mar 26, 2025, at 12:19 AM, <chen....@zte.com.cn> <chen....@zte.com.cn> > wrote: > > Hi Tony， > Thank you for your review and valuable feedback. Please see inline: > > > Original > From: TonyLiviaDatatracker <nore...@ietf.org> > To: ops-...@ietf.org <ops-...@ietf.org>; > Cc: draft-ietf-lsr-ospf-prefix-extended-flags....@ietf.org > <draft-ietf-lsr-ospf-prefix-extended-flags....@ietf.org>;last-c...@ietf.org > <last-c...@ietf.org>;lsr@ietf.org <lsr@ietf.org>; > 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 -- ops-...@ietf.org > To unsubscribe send an email to ops-dir-le...@ietf.org > _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
