Just one point which I have copied to the front ________________________________________ From: [email protected] <[email protected]> Sent: 24 December 2024 09:32 Hi Tom,
Thank you very much for your comments. Please see inline... <tp2> 'More generally, if a future implementation supports e.g five flags but the transmitting implementation only supports three, can the receiver tell? I think not which means that the zero state of a flag must cause no action, no change. Seems quite a burden, a pitfall that others may fall into in future. Ran: A node that only supports three flags receives five flags. This node only processes three of the flags, ignores the other two, and transparently transmits the five flags to other nodes. <tp2> I think that that behaviour needs spelling out explicitly. You are saying that an implementation must act on things it has no knowledge of, flags that as far as it is concerned have not been defined. I think that you need to say something like 'The flag field MUST be copied in its entirety to the outgoing message even when the implementation does not understand all the flags.' (or something along those lines). Tom Petch Best Regards, Ran Original RFrom: tompetch <[email protected]> To: Acee Lindem <[email protected]>;lsr <[email protected]>; Cc: [email protected] <[email protected]>; Date: 2024年12月23日 19:40 Subject: [Lsr] Re: IPR Call for WG Last Call on "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-ietf-lsr-ospf-prefix-extended-flags-03 Suive From: tom petch <[email protected]> Sent: 22 December 2024 17:24 From: Acee Lindem <[email protected]> Sent: 20 December 2024 18:26 This email begins a 2 week WG Last Call for the following draft: "Prefix Flag Extension for OSPFv2 and OSPFv3" - draft-ietf-lsr-ospf-prefix-extended-flags-03 Please review the document and indicate your support or objections by January 11th, 2025. The extra week is to allow for the holidays. <tp> First impression - needs tidying up 'there are not many undefined bits' How many? please work it out for me allowing for I-D work in progress and the like. Perhaps, 'At the time of writing, there are ...' better still, identify the bits Ran： Upadated to：and for OSPFv2, at the time of writing, only 4 bits remain undefined in the OSPFv2 Extended Prefix TLV. Please check. /flield/ field / 'that are undefined as shown in Table 1.' well, no; undefined does not figure in Table 1 (but it should IMHO) Ran： Upadated to：For OSPFv2, as defined in RFC7684, the length of the Flag field is 8 bits, and it has been defined the below flags as shown in Table 1. Please check. If no flags are defined is it valid to send the Sub-TLV? Ran：As an originating node, such Sub-tlv should not be sent. As an intermediate node, Sub-tlv should be transparently transmitted. 'An implementation that does not understand or support the Prefix Attribute Flags Sub-TLV MUST ignore the TLV.' which is fine if that behaviour is already in place. What is the expected behaviour for Sub-TLV that is not recognised? where is it defined? Ran：Upadated to：An implementation that does not recognize the Prefix Attribute Flags Sub-TLV MUST ignore the sub-TLV. Please check. And 'ignore the TLV' or 'ignore the Sub-TLV'? Ran: 'ignore the Sub-TLV'. <tp2> 'capabilities,by There is a character in there after the comma but it does not seem to be behaving the way I expect a space to | TBD | U | [I-D.ietf-lsr-igp-ureach-prefix-announce] | ** should be Normative IMHO Ran: [I-D.ietf-lsr-igp-ureach-prefix-announce] is only used for background. The extension of draft-ietf-ospf-prefix -extended flags doesn't depend on draft-lsr-igp-ureach-prefix-announce. In addition, ietf-lsr-igp-ureach-prefix-announce will be removed in next version becauese its extension is extended in OSPFv2 Prefix Attribute Flags(defined in this draft ) not in the OSPFv2 Extended Prefix TLV(defined in RFC7684). ' This document creates the variable length Prefix Attribute Flags Sub- TLVs for OSPFv2 and OSPFv3 respectively. ' Not really - it just creates the one for both so 'respectively ' confuses me Ran: It is two sub-TLVs, not one. Although the format is the same. ' It MUST be a multiple of 4 octets.' and if not? ignore the excess? ignore the sub-TLV? Ran: If not, the sub-TLV is invalid and the sub-TLV is ignored. what if the TLV appears twice, once valid and once invalid because someone realised they had made a mistake but did not clean up properly? Ran: Only the first one is valid, the others will be ignored Ditto for OSPFv3. 'Currently, no bits are defined in this document. Unassigned bits MUST be set to zero on transmission and MUST be ignored on receipt.' What is the difference between 'defined' and '(un)assigned'? Ran:The same meaning, the next version will uniformly change the allocation to undefined. 3, 'Flags that an implementation is not supporting MUST be set to zero on transmission' And if no flags are supported, is the Sub-TLV omitted or sent with zeros? Ran: Upadated to：Flags and Sub-TLV that an implementation are not supporting MUST be transmitted transparently. 'it currently supports or understands, ' What is the difference between supports and understands? 'understands' seems redundant Ran: Yes. 'understands' can deleted. 'as if they are set to 0' 'it MUST act as if the bits beyond the length were not set.' Is there a difference between not set and set to zero? I do not see one Ran: There is no difference between unset and set to zero. The next version will be unified: set to 0. More generally, if a future implementation supports e.g five flags but the transmitting implemenation only supports three, can the receiver tell? I think not which means that the zero state of a flag must cause no action, no change. Seems quite a burden, a pitfall that others may fall into in future. Ran: A node that only supports three flags receives five flags. This node only processes three of the flags, ignores the other two, and transparently transmits the five flags to other nodes. Tom Petch Thanks, Acee _______________________________________________ Lsr 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] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
