If we do not have agreement on what the meaning is for the relevant
terms, then either
1) The document should not be an IETF consensus document (which even
Informational publication is)
or
2) The document should be Experimental, indicating explicitly that there
is ambiguity in the terms, and one of the points of the experiment would
be to find out if that matters.
Yours,
Joel
On 10/15/2019 12:59 PM, John C Klensin wrote:
Joel,
Let me try one reason why this should not be Standards Track or,
if it should, it isn't ready. It uses, and is dependent on,
terminology for which there is no consensus definition and that
is used to describe different things in the wild. As I think I
suggested one of my earlier notes about this, it would be
possible to say "these terms mean whatever the registry says
they mean", explicitly anticipating that different registries
might use the extension for slightly different purposes. While
not a problem for an Informational document whose purpose is to
inform the community about what some registries are doing and
perhaps not for an Experimental one, neither that option nor
ignoring the definitional issue are consistent with our
expectations that standards track documents will at least lay a
foundation for interoperability. Even if it worked for each
registry that uses it taken separately, many of us have seen
situations in which companies with different definitions and
applicability for given named concepts merge and the
difficulties that result. For a standards track document,
creating such a situation would be, at least, a "known defect"
that requires exploration and explanation in the document, text
that is not present.
More details on these terminology issues in my two comments on
the Secdir review on the 13th.
best,
john
--On Tuesday, October 15, 2019 08:10 -0400 "Joel M. Halpern"
<jmh@xxxxxxxxxxxxxxx> wrote:
Regarding the document status, neither of the emails you
pointed to explains why the document is Informational. I
understand from that and other discussions that there is no
desire to make this standards track. As has been noted,
publication of usages of protocol by small groups is normally
handled by the Independent Stream. This document has been
processed by the working group.
It is very strange for a protocol document to be processed by
a working group, be accepted as not needing experimental
status, and not be published as a standards track document.
Reading teh dcouemtn, I see no reason for it not to be
standards track.
If there is concern that there may be problems with the
document, then Experimental status would be the normal way to
handle this document. With an explanation of what the
experiment is intended to represent.
If the working group feels there is a good reason for
informational publication, that should be document somewhere.
It is currently not documented in either the document itself
or the shepherd report.
The fact that proprietary extensions to EPP are allowed by the
protocol and registries is irrelevant. This document is an
IETF working group product and therefore is not a proprietary
extension.
With regard to the "b-dn:" elements of this document, I am now
more concerned than I was. I had thought those were a
reference to some other document that clearly defined the
syntax and semantics of those elements. I now understand that
the given prefix is used for the new elements defined in this
document. The structure that is used to describe the expected
and permitted content of these elements is qutie confusing.
The actual definition is only in the "formal syntax" section.
The descriptions are scattered embedded in descriptions of the
messages, expecting to user to determine the permitted and
required behavior from informal descriptive text. Yes, for
those who already know how it works and what it needs,
everything is hear. For a new implementor it is very hard to
follow.
