On Mon, May 04, 2020 at 03:20:00AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC7170, > "Tunnel Extensible Authentication Protocol (TEAP) Version 1". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6157 > > -------------------------------------- > Type: Technical > Reported by: Eliot Lear <l...@cisco.com> > > Section: 4.2.9 > > Original Text > ------------- > Status > > The Status field is one octet. This indicates the result if the > server does not process the action requested by the peer. > > Corrected Text > -------------- > Status > > The Status field is one octet. This indicates the result if the > party who receives this TLV does not process the action. > > Notes > ----- > The status field is carried in the "Request-Action" frame. As is repeatedly > stated in the chapeau of the section, the frame can be sent either by the > server or the peer.
This looks like one where I can't pick up on the needed context just from the section in question. The intent of the 'Status' field still seems unclear: this text seems to suggest that it's a sort of "fallback" error code to use if the request to perform an action is ignored. But that doesn't make much sense if I also look at the text about: Two Request-Action TLVs MUST NOT occur in the same TEAP packet if they have the same Status value. [...] Why am I not allowed to have two requests that would get the same treatment if the request was ignored? Thanks for helping me understand, Ben _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu