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 <[email protected]>
>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/emu
