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