OK Paul, lets give you the benefit of the doubt and say that your
assertions below are absolutely right. Please explain then why it
should become an informational RFC without having the comments of the
RAB members attached to it? (Even though as Patrick said it is not
common practice to do this with an informational rfc). Isn't this
such an egregious and high profile example that the IESG out to
choose to excercise some consumer protection here? NSI's own panel
of experts, its own RAB said the protocol was broken did they not?
Yet NSI went ahead and implemented it anyway. NSI is operating a
flawed protocol to handle a registration process for names that can
now command huge sums of money? The protocol is now under the
stewardship of ICANN which so far is allowing something to operate
which has a major potential to bring law suits down on its head .
Patrick who is now a member of the ICANN board and was a member of
the RAB and thus has ample reason to know how badly the protocol has
been designed is saying that the protocol should be published albeit
as a LOWLY INFORMATIONAL RFC with nothing in the packaging to
indicate that trouble lurks within?
Is it really the position of the IESG that they have NO obligation to
do anything to inform the unwary that this protocol is an invitation
for lawsuits against NSI, against ICANN, and possibly against the
IETF on the grounds that the RFC publication was perceived by the
clueless party as an endorsement?
I just saw David Conrads statement and I understand the point he
makes. Still I wonder how wise the insistence is on hewing to old
traditions in this case. Where do Patrick's obligations fall? To
the IESG in holding his nose in saying we won't break precedent and
even though we all undestand this is a series of disasters waiting to
happen we will publish the sucker as we always to without further
explanation? Or as an ICANN Board member does he have a legal and
fiduciary duty to ICANN as a corporation to act in such a way to see
thatin the future no internet ignorant corporation could ever step
forward and claim that - having been involved in the creation of a
flawed product - he had a duty to ICANN to label it as flawed and
should he chose not to he could find lawyers going after him. How
many ICANN board members understand what their personal legal
liability is?
>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
****************************************************************
The COOK Report on Internet Index to seven years of the COOK Report
431 Greenway Ave, Ewing, NJ 08618 USA http://cookreport.com
(609) 882-2572 (phone & fax) Is ICANN an IBM e-business ?
[EMAIL PROTECTED] See also Lessig's Code: and
Other Laws of Cyberspace http://cookreport.com/lessigbook.shtml
****************************************************************
