On May 20, 2024, at 8:12 PM, Orie Steele <orie@transmute.industries> wrote: > > On Mon, May 20, 2024 at 6:24 PM Alan DeKok <al...@deployingradius.com> > wrote: >> >> "It MUST only send a NAK TLV for a TLV which is marked mandatory." >> > > It MUST send a NAK TLV for any TLV which is marked mandatory but not > understood?
Yes. >> If all TLVs in a message >> are marked optional and none are understood by the peer, then a Result TLV >> SHOULD be sent to the other side in order to >> continue the conversation. It is also possible to send a NAK TLV when all >> TLVs in a message are marked optional. >> > > Seems better to me, perhaps strengthen the second part as well: > > If all TLVs in a message are marked optional and all are understood by the > peer, a NAK TLV SHOULD be sent. I'm not sure we'd want to send a NAK TLV is all TLVs are understood? > > [ re: PAC ] > > >> No. It should be handled as an unknown TLV. >> > > Perhaps "deprecated TLV are ignored, similar to Outer TLVs that are invalid > or contain unknown values" > > ``` > 1064 1. If Outer TLVs are invalid or contain unknown values, they will be > 1065 ignored. > ``` Sure, sounds good. >> I don't think so. This is the only deprecated TLV, and I don't think >> anyone implemented it. >> > > All the more reason to state explicitly that it should be silently ignored? Yes. I'll make that change > >>> Is the guidance in Section 4.2.12 of RFC7170 unchanged in this update? >> >> That section of 7170 describes how to use the PAC TLV. Since we're no >> longer using it, the guidance given previously can be safely ignored. >> > > Because the PAC TLV MUST be treated as invalid or containing unknown values? Yes. Alan DeKok. _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
