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

[Randall Gellens <[e-mail]>]

Interoperability isn't being changed.  RFC 5222 allows LoST servers to 
refuse to perform location validation.  Adding a tag just provides an 
optimization so that clients can avoid getting into a situation where 
the server they discovered refuses to do validation.

On 8 Mar 2020, at 13:22, Ben Campbell wrote:

> (doffs shepherd hat)
>
> I agree with Pete. There’s more to a protocol than the on-the-wire 
> bits. Anything important for interop to work should be considered part 
> of the protocol. Discovery is an important part of that. Changing 
> discovery to spread functions across different servers is a change to 
> the protocol.
>
> Pete’s suggested fixes seem reasonable to me and relatively 
> painless.
>
> Ben.
>
>> On Mar 8, 2020, at 2:59 PM, Pete Resnick <[e-mail]> 
>> 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/ <https://www.episteme.net/>
>> All connections to the world are tenuous at best
>>
>> --
>> last-call mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/last-call 
>> <https://www.ietf.org/mailman/listinfo/last-call>