Em seg., 29 de jun. de 2026 às 16:52, Acee Lindem <[email protected]> escreveu: > >>> 3. Since that type resolves to a hex-string, I believe a single leaf > >>> would be preferable to a leaf-list. > >> > >> At first I didn't agree with this but I see this constraint for the > >> sub-TLVs containing > >> extended-admin groups in RFC 9350: > >> > >> The IS-IS FAEAG sub-TLV MUST NOT appear more than once in a single > >> IS-IS FAD sub-TLV. If it appears more than once, the IS-IS FAD sub-TLV > >> MUST be ignored by the receiver.
Hi Acee, Initially I thought the leaf-list of hex-string was used to represent 4 bytes per entry, matching the wire format. But now I see the intention was to represent multiple sub-TLVs. > > Actually, we could keep it a leaf-list and indicate that if there is more > > than one IS-IS FAEAG sub-TLV, the IS-IS FAD sub-TLV is ignored. > > I'm going to make them leaves consistent with other IGP YANG models with > sub-TLVs that only have a single instance. > For example, ietf-ospfv3-extended-lsa.yang sub-TLVs for external LSAs > (route-tag). Sounds good to me. If we were to represent all TLV data faithfully, we would need to use lists and leaf-lists for everything. But the direction taken was to model only valid TLV information, which I think is the right call. It makes the data easier to consume, and leaves it to the implementation to report invalid TLVs by other means, such as logging or notifications. Best regards, -- Renato Westphal _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
