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.
