At 03:05 PM 1/4/00 -0800, Rick H Wesson wrote:
The IETF does not need to publish broken implementations of one companies
view of the shared gTLD registration process.
True. They don't need to do anything. They have the *option* of continuing
the tradition of approving publication of Informational RFCs that document
interesting (for some value of interesting) protocols that were not
developed in the IETF but are of interest to the Internet community. In my
mind NSI's RRP certainly qualifies. As long as the protocol does not
directly harm the Internet on a technical level (not a political level;
they all do that), the IESG might want to see it published.
Given the somewhat obvious nature of the protocol's faults, I would think
that the community would welcome it being published openly and permanently;
that way they can always refer to in while improving it.
Having an AD that sat on the
RAB promote the I-D
Sorry, but this is garbage. Nothing that Patrik said promotes the protocol.
and offer no reasoning as to why it
*should be* published as an Informational RFC
He said that about three times; please re-read the past few messages with
slightly clearer eyes.
I would request that the IESG let this draft expire and create a WG to
tackle the problem.
It is not clear that the IETF is the proper place to tackle this problem.
From the number of mistakes in the NSI RRP, I believe that a better way to
create such a protocol is to start with a requirements document. A few
folks have kicked around the idea of creating an IETF WG, but it became
clear that the expertise to set down the *requirements* are more likely to
be in the ICANN DNSO, not the IETF. That is, ask the registrars and
registries, not a bunch of protocol-writers. After the requirements are
settled, the IETF could probably help write the protocol.
Having those directly involved in the field set down the requirements first
will delay the shipment of the new protocol, but it is very likely to cause
the outcome to be much better for all involved. This has been shown again
and again (with both positive and negative examples) in the IETF.
The document exists as an I-D,
the cat is out of the bag, why should it be an RFC?
To make it permanently and easily and freely accessible to the entire
Internet community forever. There are many Informational RFCs that have
been published for these reasons.
--Paul Hoffman, Director
--Internet Mail Consortium