--On Sunday, October 13, 2019 16:25 +0200 Barry Leiba
<barryleiba@xxxxxxxxxxxx> wrote:
>> The Abstract ans Section 1 say: "This is a non-standard
>> proprietary extension." I understand that this is not a
>> standards track document, so the "non-standard" part makes
>> sense. However, what is the point of publishing a
>> "proprietary" extension as an RFC. I would hope that
>> interoperable implementations is the goal of publication.
>
> I'm afraid this addition is my fault. Perhaps
> "proprietary" is the wrong word here: The point is that
> this is documenting an extension developed by one registry and
> not in use by others, with the idea that if others want to use
> it they can follow this to interoperable. It's rather like
> when we documented Apple Bonjour as Informational.
>
> Better word?
Barry,
Our traditional way of handling this sort of thing is to have
the title say "FooCompany's method of doing X" (presumably, in
this case, "CDNC Method for Domain Name Mapping Extension for
Strict Bundling Registration" (with or without the EPP
identification) and then identifying the companies or registries
that have implemented it in the Introduction. Some of the
latter information is included in Section 12 on Implementation
Status but not only is that section not referenced from the
Introduction, but there is a note requesting that the RFC Editor
remove it.
Most such documents have been handled as Independent
Submissions, rather than by the IESG and the IESG has generally
insisted on such titles and introductory material as well as the
usual "this is not a standard..." boilerplate. That list
specifically includes RFC 4290, an opinion piece on registration
procedures for IDNs that is referenced by this document, and
RFCs 3743 and 4713, which are the core JET and CDNC documents
respectively and which, while not referenced from this document,
appear to define and explain concepts essential to it.
If the Bonjour spec you are referring to is RFC 6886, while the
title does not reflect that status, the Abstract does indicate
its status and it was also handled as an Independent Submission.
Noting that there is a presumption of IESG Consensus for
anything published in the IETF Stream (even Informational
pieces), I suggest that if this is a non-standard, but
compatible, extension that is expected to be published in the
IETF Stream, the title should be adjusted to show the status as
above, the implementation status should be retained, and,
although it is unusual, an explicit statement should be included
that others are free to implement and use this extension without
any special arrangements with the authors or their
organizations.
Or toss it over the wall to the ISE with an explicit note
indicating that there has been BOF, WG, and mailing list
discussions (possibly by including the Shepherd's report), that
the WG is in favor of this being published, waiving further RFC
5742, and urging expedited handling. That would allow a quick
review through the ISE and associated processes, which are much
more familiar with this type of document than the IETF Stream
his historically been.
Technical comment: While this protocol extension appears to be
applicable only to "strict bundling" and calls that term out in
the title, the term is, AFAICT, not ever defined in a rigorous
way. The Introduction says "...strict bundling, which requires
all bundled names to share many same attributes". Ignoring the
inconvenient English, "many same" is not a definition without
either a list of attributes or quantification like "at least
five of the following list". When we get to Section 5, the
specification isn't talking about "strict bundling" any more,
but, even then, says "should share some parameter or attributes
associated with domain names", an even weaker and m0re vague
requirement. So readers of this document who are considering
implementing the extension is not able to determine whether it
is applicable to their needs (at least in the absence of
discussions with the designers). If "strict bundling" is really
whatever a particular registry says it is, that should be
explicit in the text.
best,
john
p.s. While I appreciate the acknowledgment which is possibly due
to my contributions to related work, I generally do not follow
EPP work (for reasons of which several of those copied on this
note are aware) and do not remember looking at this document, at
least in its present form, before it was called to my attention
by this correspondence. On the other hand, perhaps the authors
could anticipate the future and proactively acknowledged my
comments above :-)
