Re: [Gen-art] Genart last call review of draft-gellens-lost-validation-05

[Randall Gellens <[e-mail]>]

Hi Pete,

I don't see this as a new protocol.  It is a new service tag that is 
optional to use.  Not using it won't break anything that wouldn't be 
broken without the tag being defined.  Using it is an optimization.  I 
see the draft as only adding a new tag, not defining a new protocol.

--Randall

On 7 Mar 2020, at 8:52, Pete Resnick via Datatracker wrote:

> Reviewer: Pete Resnick
> Review result: Not Ready
>
> 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.