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

From: Barry Leiba <[email-masked]>
Date: Sat, 7 Mar 2020 12:12:34 -0500

Thanks, Pete, for a very helpful review.

Barry

On Sat, Mar 7, 2020 at 11:52 AM Pete Resnick via Datatracker <
[email-masked]> 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.
>
>
>
>

---

From: Pete Resnick via Datatracker <[email-masked]>
Date: Sat, 07 Mar 2020 08:52:07 -0800

Reviewer: Pete Resnick
Review result: Not Ready

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.

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 08 Mar 2020 12:27:56 -0700

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

---

From: "Pete Resnick" <[email-masked]>
Date: Sun, 08 Mar 2020 14:59:01 -0500

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

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 08 Mar 2020 13:22:15 -0700

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:

> 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
>
>> 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
>>

---

From: Ben Campbell <[email-masked]>
Date: Sun, 8 Mar 2020 15:22:50 -0500

(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 <[email-masked]> 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
> 
>> 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
>> 
> Pete Resnick https://www.episteme.net/ <https://www.episteme.net/>
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>

---

From: "Pete Resnick" <[email-masked]>
Date: Sun, 08 Mar 2020 15:28:01 -0500

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:

> 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
>
>> 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
>>

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 08 Mar 2020 15:56:33 -0700

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.
>
>> https://www.ietf.org/mailman/listinfo/last-call 
>> <https://www.ietf.org/mailman/listinfo/last-call>

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 08 Mar 2020 15:59:06 -0700

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:

> "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.
>
>>> 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
>>>
>>>> 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
>>>>