Skip to main content

Last Call Review of draft-ietf-core-problem-details-04
review-ietf-core-problem-details-04-opsdir-lc-jaeggli-2022-06-06-00

Request Review of draft-ietf-core-problem-details
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2022-06-10
Requested 2022-05-27
Authors Thomas Fossati , Carsten Bormann
I-D last updated 2022-06-06
Completed reviews I18ndir Last Call review of -05 by Harald T. Alvestrand (diff)
Artart Last Call review of -05 by Harald T. Alvestrand (diff)
Opsdir Last Call review of -04 by Joel Jaeggli (diff)
Genart Last Call review of -05 by Gyan Mishra (diff)
Secdir Telechat review of -05 by Yoav Nir (diff)
Assignment Reviewer Joel Jaeggli
State Completed
Request Last Call review on draft-ietf-core-problem-details by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/IaPVbNyTTyqgRQ6K8jApmCoiKfM
Reviewed revision 04 (document currently at 08)
Result Ready
Completed 2022-06-06
review-ietf-core-problem-details-04-opsdir-lc-jaeggli-2022-06-06-00
I reviewed draft-ietf-core-problem-details on behalf of the  ops directorate. I
nsummar y this draft is largely ready. I have one perhaps clarifying question.

in the regards to the following statement:

   Consumers of a Concise Problem Details data item MUST ignore any
   Custom Problem Detail entries, or keys inside the Custom Problem
   Detail entries, that they do not recognize; this allows Custom
   Problem Detail entries to evolve and include additional information
   in the future.  The assumption is that this is done in a backward and
   forward compatible way.

This seems like less of a gesture at compatibility as opposed to simply
ignoring conditions that would otherwise produce errors by the receiving
parties. it would see likely that coap problem detail collectors may collect
such data for processing by other systems since the whole collection pipline
may not move in lock step or doesn't it?