Hi Ben, My apologies for the delay. You are pointing out a separate issue that might need to be opened, but I will do my best to discuss below:
> On 9 May 2020, at 02:20, Benjamin Kaduk <ka...@mit.edu> wrote: > > 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? I can’t answer this question authoritatively because I didn’t write the RFC (;-), and in general the language here is hard to parse. For instance, what does it mean for the request-action frame to have a PKCS#10 request in it? Does that mean that the receiving peer must either attempt to generate a PKCS#7 message or return the most fatal of (result(PKCS#7 generation),”Status”)? That doesn’t seem to make sense, because the conversation could continue if Status == non-fatal without the server having processed the request. On the other hand, sending a normal PKCS#10 frame seems to have nearly identical semantics. Eliot > > Thanks for helping me understand, > > Ben
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
