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

[Randall Gellens <[e-mail]>]

I'd be happy to delete all the explanatory and background text, and just 
point to the NENA document.  The text was added by request.

--Randall

On 8 Mar 2020, at 13:28, Pete Resnick wrote:

> Hi Randy,
>
> We probably at some core level disagree about whether "informational 
> text that explains how it is expected to be used" is in-and-of-itself 
> "normative"; I think in IETF documents, that's really all that it 
> means. But that might be moot: If the NENA document is going to be 
> updated to describe the how clients and servers are to use the tag, 
> why not simply remove sections 3 & 4 from this document and put in a 
> reference to the NENA document as "Work In Progress"? If the IETF is 
> not defining how the tag is going to be used, then point to the 
> document that will.
>
> In its current state, the document reads like protocol to me and 
> therefore worthy of standards track. If you truly want simply a 
> registration, make the reference and it will be a perfectly reasonable 
> Informational document.
>
> pr
>
> On 8 Mar 2020, at 15:22, Randall Gellens wrote:
>
>> 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