On Tue, May 21, 2024 at 12:11 PM Alan DeKok <al...@deployingradius.com> wrote:
> 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? > Send Result TLV if all are optional and all are understood, and send NAK TLV if all are optional and any are not understood? The goal is to make the expected behavior clear, and not leave the response up to the peer. The options are send one or the other, depending on the conditions or just send one regardless of the conditions, perhaps the answer is to just send Result TLV regardless? > > > > [ 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. > > Thanks, for addressing my comments. OS, ART AD
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
