Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Inf

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 ?
cook(_at_)cookreport(_dot_)com                     See also Lessig's Code: and
Other  Laws of Cyberspace  http://cookreport.com/lessigbook.shtml
****************************************************************