Skip to main content

Last Call Review of draft-gellens-lost-validation-05
review-gellens-lost-validation-05-genart-lc-resnick-2020-03-07-00

Request Review of draft-gellens-lost-validation
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-03-31
Requested 2020-02-25
Authors Randall Gellens , Brian Rosen
Draft last updated 2020-03-07
Completed reviews Secdir Last Call review of -05 by Shawn M Emery (diff)
Genart Last Call review of -05 by Pete Resnick (diff)
Genart Last Call review of -08 by Pete Resnick (diff)
Assignment Reviewer Pete Resnick
State Completed
Review review-gellens-lost-validation-05-genart-lc-resnick-2020-03-07
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/8_aH7Qp7emk8HspvR0X-hXOgLGA
Reviewed revision 05 (document currently at 09)
Result Not Ready
Completed 2020-03-07
review-gellens-lost-validation-05-genart-lc-resnick-2020-03-07-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-gellens-lost-validation-05
Reviewer: Pete Resnick
Review Date: 2020-03-07
IETF LC End Date: 2020-03-31
IESG Telechat date: Not scheduled for a telechat

Summary:

Abstract, Scope, and Introduction do not accurately reflect the content of the
document, which is not simply a registration.

Major issues:

The Abstract and sections 1 & 2 (Scope and Introduction) indicate that this
document is simply an IANA registration of an S-NAPTR Application Service Tag.
However, section 3 is quite clearly new protocol, some of which changes how RFC
5222 implementations should operate if used in a particular context, and
section 4 lays out the backward compatibility of this new protocol with legacy
RFC 5222 implementations. There is the implication that the NENA i3 documents
will actually be the home of that protocol, but the current i3 document
referenced here does not do so, making this document the canonical statement of
the protocol operations necessary to implement the i3 architecture. That
doesn't seem appropriate for an Informational document that purports to simply
be a registration.

At the very least, the Abstract, Scope, and Intro would need to be updated to
reflect the actual contents of the document. I think things would be better
served by making this a Proposed Standard document so that it gets the
appropriate level of review. I understand from the Shepherd writeup that the
ECRIT WG doesn't have the energy to really work on this document. However, this
is a simple enough extension to the LoST protocol that I think it's
unproblematic to have it as an AD-sponsored standards track document.