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

[Randall Gellens <[e-mail]>]

Hi Pete,

The document adds a tag.  It also contains informational text that 
explains how it is expected to be used.  There isn't any normative text. 
  Once the tag is defined, then NENA i3 will be updated to refer to it, 
and to mandate how NENA-compliant clients and servers use it.  But a 
non-NENA-i3 client or server can use the tag or not as they wish.

--Randall

On 8 Mar 2020, at 12:59, Pete Resnick wrote:

> Hi Randy,
>
> Section 3 of the document defines the operations that one must perform 
> in order to use the tag. It explains how to go beyond what 5222 
> provides by defining which order to look up the servers and what to do 
> depending on the results received. It changes the discovery procedure 
> defined in 5222. The fact that it is backwards compatible and doesn't 
> break 5222 implementations is good, but it doesn't make it any less a 
> protocol. Indeed, if it is an "optimization" of an existing protocol, 
> that makes it a protocol. I can't see any other way of describing 
> section 3.
>
> pr
>
> On 8 Mar 2020, at 14:27, Randall Gellens wrote:
>
>> 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.
>
>
> -- 
> Pete Resnick https://www.episteme.net/
> All connections to the world are tenuous at best