Hi Ran, Tony, See one inline. > On Mar 26, 2025, at 12:19 AM, <chen.ran@xxxxxxxxxx> <chen.ran@xxxxxxxxxx> wrote: > > 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. > > 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-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
