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

From: Ian Jackson <[email-masked]>
Date: Tue, 4 Jan 2000 17:21:52 +0000 (GMT)

The IESG writes ("Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to 	 Informational"):
> 
> The IESG has received a request to consider Registry Registrar Protocol
> (RRP) Version 1.1.0 <draft-hollenbeck-rrp-00.txt> as an Informational
> RFC.  This has been reviewed in the IETF but is not the product of an
> IETF Working Group.
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by January 13, 2000.

I can see at least the following problems with this protocol, in
addition to those described in it:

* The TRANSFER command, when used to approve a transfer, does not
specify to which registrar the domain is to be transferred.  The
document says that the details of transfer arrangements should be
handled out-of-band by eg electronic mail.  However, that would not
prevent a domain mistakenly or maliciously being transferred to the
wrong new registrar.  It is essential that this deficiency in the
protocol is corrected or worked around forthwith, as currently a
malicious registrar who is able to manipulate unsecured out-of-band
email may be able to cause the domain to be transferred to themselves
instead of to the intended recipient registrar.

A workaround would be for the intended recipient to send (via another
protocol) to the donor an authenticated confirmation to the that it
had successfully lodged the transfer request, so that if the donor is
willing to transfer to that registrar it can safely approve the
transfer.  However, the technical integrity of this scheme depends on
the registry never unexpectedly losing or timing out transfer
requests, and on donors to keep a record of all recent transfer
requests to ensure that the right request is accepted; the sociolegal
integrity of such a workaround may depend on extremely complicated
contractual issues, which is not my field of expertise.  In any case
this caveat should be addressed in any Information RFC.

* The use of passwords for identifying registrars rather than the
certificate information corresponding to the SSL session is very
unwise.  The secret(s) which identify a registrar should never leave
that registrar.  For example, a security compromise at the registry
would require all the registrars' passwords to be changed, and
redistributed via secure out-of-band channels.  Furthermore, the use
of passwords makes it impossible to use secure hardware to store the
critical key material.  This misfeature should be fixed in future
versions and implementations.

* The use of registry local time in time stamps is absurd (and will
likely lead to daylight saving change bugs etc.).  The time used
should be in UTC, or preferably elapsed civil time measured as the
number of non-leap seconds since a suitable epoch.  This misfeature
should be fixed in a future protocol version.

* The use of SSL, rather than individually authenticating requests and
responses (or batches of them), means that there is no audit trail,
verifiable by a third party, for resolving disputes.  This bug should
be fixed in a future protocol version.

I think that any Informational RFC describing this protocol should at
the very least mention these deficiencies as well as those it already
lists.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Tue, 4 Jan 2000 17:21:52 +0000 (GMT)

Ian.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 04 Jan 2000 18:54:48 +0100

--On 2000-01-04 17.21 +0000, Ian Jackson <[email-masked]> 
wrote:

> specify to which registrar the domain is to be transferred.

If I remember correctly from a presentation NSI have had for me, the 
transfer is always to the registrar issuing the command, but I might be 
wrong.

Regardless, thanks for the comments. They are taken into consideration.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 04 Jan 2000 18:54:48 +0100

paf

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 13:20:01 -0800

> Regardless, thanks for the comments. They are taken into consideration.

Patrik:

"If I remember correctly from a presentation NSI have had for me" is
a good name for the RAB [1] meetings we attended I presume, in the
euphemisms that these discussions have turned into.

However, IMO it would be unfitting to the IETF to proceed discussions
on NSI's proposed RFC without NSI disclosing and making public all
the RAB meeting minutes, as "supporting" documentation.

Further, reading NSI's RFC and Karl's comments here, I am grateful that
neither the RAB  nor its members were mentioned in the RFC, nor a
cknowledged, even though the RFC is on the very same Shared
Registry Protocol we were called to help verify and provide free but
otherwise professional advice.

You will recognize in Karl's comments a rerun of some of my
own comments and also of Stef's and Steve's, I am sure, just
to cite a few. Race conditions, log traces, actions on log
traces, reliable timestamps, the need for well-defined states
with well-defined variables, slamming precautions, transfer
problems, correct internationalization, UTC time, message
text limit, etc. were also all mentioned and advised about
more than once; and they are in the RAB Minutes.  They
need to be made public since NSI is requesting public
comments.  They are also part of the mandates of Amendment
11, which I wish to interpret technically -- no politically by
euphemisms of  a "presentation NSI have had for me".

Cheers,

Ed Gerck

[1] http://www.nsiregistry.com/history/rab.html :

 Mission Statement The Network Solutions Registry Advisory Board (RAB) was formed to provide Network
   Solutions with independent external advisory review of the design and testing of the NSI Shared Registration
   System. Members of the RAB were selected to provide a balance of diverse technology and regional
   perspectives. The Board existed through 30 September 1999 to review, participate, and advise in testing of
   the technology aspects of the Shared Registration System, and to suggest improvements to Network Solutions
   to better meet the mandates of Amendment 11.

   Members

          External Members
          David Conrad
          Patrik Fältström
          Katherine Fithen
          Dr. Edgardo Gerck
          Dr. Johan Hjelm
          Michael Rotert
          Einar "Stef" Stefferud
          Dr. Stephen Wolff

                         NSI Members
                         David Holtzmann
                         Aristotle Balogh
                         Scott Hollenbeck
                         Neeran Saraf

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 13:20:01 -0800

Patrik:

Cheers,

Ed Gerck

   Members

          External Members
          David Conrad
          Patrik Fältström
          Katherine Fithen
          Dr. Edgardo Gerck
          Dr. Johan Hjelm
          Michael Rotert
          Einar "Stef" Stefferud
          Dr. Stephen Wolff

                         NSI Members
                         David Holtzmann
                         Aristotle Balogh
                         Scott Hollenbeck
                         Neeran Saraf

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 04 Jan 2000 22:32:09 +0100

> otherwise professional advice.

If RAB was mentioned, I would have been more careful with the document, but 
as the RAB only had limited input to the actual design of the protocol, the 
RAB should not, and is not, mentioned.

In this case though, the document will specify "the NSI R-R protocol", 
nothing else. It is often organizations do present and make specifications 
available of their private inventions through publications of Informational 
RFCs, so this is nothing special.

The IETF in this case must differentiate between input to the NSI on 
whether the protocol is good or bad, and maybe on how to make the protocol 
better in the future, and whether the document specifies what is currently 
in use.

The last call in the IETF is regarding the latter, not the quality of the 
protocol.

The IESG can still make a recommendation to NOT publish the (private) 
protocol as informational RFC, for example if the protocol damages the 
functionality of the Internet. In this case, where we talk about one 
specific application, that is probably not the case.

So, you are talking about (like we did in the RAB) the quality of the 
protocol, while I now as AD and member of the IESG is asking whether this 
document is correctly describing what is in use.

I ask you Ed, and all others, to please differentiate between those two 
issues, and come with comments on the correctness of the document. Comments 
on the protocol can be sent directly to NSI.

    Patrik Fältström
    Area Director, Applications Area

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 04 Jan 2000 22:32:09 +0100

Patrik Fältström

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 14:11:31 -0800

> on the protocol can be sent directly to NSI.

IMO you  are following a very slippery slope here.  You seem
now to be moving into "explanation mode" in order to say that 
the  protocol's effectiveness is not important, just its perfunctory 
functions.

In other words, you as AD and member of the IESG are saying
that protocols are to be published as RFCs even if knowingly
technically wrong, inefficient, outdated and insecure -- provided
they are "in use".

Well, I may be a little less pragmatic than you and I question exactly
the correctness of the document, as well as its effectiveness.

And, since our names are still in NSI's page for the Registry Advisory
Board (RAB) and we were involved with it, I also think that the IETF
should know that the SRP being proposed by NSI as an RFC and
being followed through IETF under yours (a former member of the
RAB) apparent approval is not what the RAB discussed and
formally requested to change as documented in the RAB minutes locked
under NDA. The RAB in Ammendment 11 has thus become a mock review 
process locked under NDA, even though the RAB was officially called by 
the USG to "review, participate, and advise in testing of the technology
aspects of the Shared  Registration System, and to suggest improvements
to Network Solutions to better meet the mandates of Amendment 11."

The least I suggest is to make the RAB Metting Minutes, together with
its Action Plan, public -- before furthering this RFC in the IETF. Why
should other people need to reinvent the same comments again?  The hope
that some will not be reinvented is IMO ill-founded as security
experience shows all the time -- obscurity is not a basis for
security.

Now, of course, if NSI wants to keep the protocol private then I
have no further comments.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 14:11:31 -0800

Cheers,

Ed Gerck

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 4 Jan 2000 15:05:49 -0800 (PST)

IESG:

I hate to add a "me too" but I must. I believe that the RAB minutes would
be very useful if they were published. Having participated with many
Registrars and participated in changes and suggestions to the RRP protocol
through the ICANN Testbed process I welcome Ed's comments.

I am glad that NSI has published the I-D for their protocol, now does it
need to go beyond that and become an RFC, IMHO, no.

The IETF does not need to publish broken implementations of one companies 
view of the shared gTLD registration process. Having an AD that sat on the
RAB  promote the I-D and offer no reasoning as to why it
*should be* published as an Informational RFC reminds me of the bad taste
left by the IAHC and all the processes related.

I would request that the IESG let this draft expire and create a WG to
tackle the problem. I would be interested in hearing just why the IESG
thinks this document should be published. The document exists as an I-D,
the cat is out of the bag, why should it be an RFC? Its broken and of bad
design we don't need that kind of thing published any further than it has
been.

regards,

-rick

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 4 Jan 2000 15:05:49 -0800 (PST)

IESG:

regards,

-rick

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 4 Jan 2000 15:34:23 -0800 (PST)

> need to go beyond that and become an RFC, IMHO, no.

Since I-Ds still officially vanish after a while, we need to move it to
RFC to maintain its visibility.  <Let's defer comments on the I-D fade out
policy.>

> view of the shared gTLD registration process.

We can learn from the flaws of the past.  And this RRP certainly gives us
a lot to learn from.

I would hope that having an Informational RFC on the RRP would motivate
some folks to think up, write down, and publish "A Better RRP".  Your own
work on the representing the whois data using XML is perhaps a good start.

(I can imagine that many sites with big zone files might find it useful to
have a tool using "A Better RRP" to distribute the administration of their
zone.)

By-the-way, I think that the IETF has already jumped through enough hoops
regarding the mis-perception by some that the letters "RFC" are some sort
of seal of approval.

		--karl--

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 4 Jan 2000 15:34:23 -0800 (PST)

--karl--

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 04 Jan 2000 15:35:42 -0800

>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.

>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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 04 Jan 2000 15:35:42 -0800

--Paul Hoffman, Director

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 4 Jan 2000 15:58:37 -0800 (PST)

Paul,

In short you are suggesting that the I-D be published to document a
bad but current practice? It seems counter-intutative but I am certainly
not "in the know" as to how these things work.

think the IESG could at least put a "bad bad protocol" sitcker on it when
they its published, or better yet give it a negative RFC number starting with 
negative RFC numbers would at least put it firmly into the minds of
readers that the RFc should *not* be followed.

I doubt I'd implement RFC -1 ;-)

regards,

-rick

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 4 Jan 2000 15:58:37 -0800 (PST)

Paul,

regards,

-rick

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 04 Jan 2000 16:09:56 -0800

At 03:58 PM 1/4/00 -0800, Rick H Wesson wrote:
>bad but current practice?

A review of the Informational RFCs issued in the past few years would 
reveal a few RFCs that match that description quite well.

>  It seems counter-intutative but I am certainly

It is a bit counter-intuitive until you look at the alternative. There 
isn't a good, central, free, open repository for these things other than 
RFCs. This isn't to say that every protocol should go there. I would say 
that only "important" (either due to politics or the number of 
implementations using the protocol) protocols should qualify.

--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 04 Jan 2000 16:09:56 -0800

--Paul Hoffman, Director

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 04 Jan 2000 16:29:32 -0800

Rick,

> be very useful if they were published. 

Has any other organization interested in publishing an informational RFC
needed to also publish the internal discussions that led to the implementation
of their proprietary protocol?

> need to go beyond that and become an RFC, IMHO, no.

I-Ds expire.
 
> view of the shared gTLD registration process. 

Then you were unhappy that (oh, say) Cisco submitted RFC 2281 as an
informational RFC (not saying HSRP is "broken", but I'm sure someone would).

> left by the IAHC and all the processes related.

I find this offensive.  I was among those who encouraged NSI to publish the
RRP as an informational RFC as I felt it would be in the best interests of
everybody to have the RRP protocol publically examined and I feel NSI should
be commended for documenting their protocol.  However, INFORMATIONAL RFCS DO
NOT IMPLY ENDORSEMENT.  The draft is a representation of an existing, in use
proprietary protocol.  No further justification should be necessary for
documenting it as an informational RFC.
 
Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 04 Jan 2000 16:29:32 -0800

Rick,

I-Ds expire.

 
Rgds,
-drc

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 17:37:48 -0800

"David R. Conrad" wrote:

> I was among those who encouraged NSI to publish the
> be commended for documenting their protocol.

I too encouraged NSI to publish the RRP protocol, and I believe I was actually
the first that said so to NSI.  This is however IMO irrelevant here -- the issue is what
is being presented by NSI to be an informational IETF RFC, not whether we should
commend  NSI for doing or not doing anything in their own benefit.  This is yet not
the Internet Marketing Study Group.

Given the secret (but not private) nature of the RAB Meeting Minutes, I am effectively
barred to comment further  -- even though I would just be repeating my own comments.
However, to anyone versed in technical work it is clear that if the references to a work
are missing, and if those references actually *deny* the work being presented, then
there is  something basically wrong with the entire process. This is what happens here
and that is why I am not convinced that the NSI RFC should be published by the IETF
unless the very references to that work which resulted from a US Government contract
be made available and public as well, as "supporting" documentation missing in the
RFC.

Note also that the RAB, its meeting Minutes and its Action Points are also not the
result of an NSI private initiative as we know, Conrad, but an obligation upon NSI by
an  oversight body and a regulating US agency in a legal contract.  I imagine that the
Freedom of Information Act could be used to make those notes public since they
were mandated by the direct act of a US agency, who also has copies of them.  And I
see no benefit to the Internet community if they continue to be secret to some (RAB,
NSI, USG, ICANN) while the  RRP that they comment on intends to be published by
the IETF -- without the comments!  So, on a more humorous tone, this is not a RFC as a
"Request For Comments" ...  this is a "Requiem For Comments" ;-)

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 17:37:48 -0800

Cheers,

Ed Gerck

---

From: Gordon Cook <[email-masked]>
Date: Tue, 4 Jan 2000 20:43:21 -0500

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?

>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.
>
>He said that about three times; please re-read the past few messages 
>with slightly clearer eyes.
>
>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.
>
>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

****************************************************************
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-masked]                     See also Lessig's Code: and
Other  Laws of Cyberspace  http://cookreport.com/lessigbook.shtml
****************************************************************

---

From: Gordon Cook <[email-masked]>
Date: Tue, 4 Jan 2000 20:43:21 -0500

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Jan 2000 17:52:43 -0800

>of their proprietary protocol?

No.

Informational RFCs for proprietary protocols have been published many 
times.  The IETF portion of the process to publish such documents is simply 
to ensure that we avoid confusion with IETF work.  That is amply obtained 
through the suggested title change.

The topic really does not warrant nearly as much discussion as it is getting.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Dave Crocker <[email-masked]>
Date: Tue, 04 Jan 2000 17:52:43 -0800

No.

d/

=-=-=-=-=

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 4 Jan 2000 18:38:51 -0800 (PST)

David,

I appologise if you found my comments offensive, they were not intend to
be. I'm gald you encouraged NSI to publish RRP, I'm gald they published
it. I also needed to discuss with the RAB issues about RRP durring the
testbed but was prevented by NSI by NDA. Remember in Berlin I asked if I
could talk to the RAB and that the testbed registrars have some problems
with RRP?

We all know that the entire development of rrp was sub-optimal and yes
Informational does not implay Endorsement but that is a fact that most of
the world does not understand and is an entirely different thread.

I have atempted as have others to outline many issues we have had with the
RRP protocol and its developemnt. I realy can't do more than that. 

-rick

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 4 Jan 2000 18:38:51 -0800 (PST)

David,

-rick

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 04 Jan 2000 19:28:26 -0800

Ed,

> the issue is what
> is being presented by NSI to be an informational IETF RFC, not whether 
> we should commend  NSI for doing or not doing anything in their own 
> benefit.  This is yet not the Internet Marketing Study Group.

Nor is it the Internet Inquisition ("No one expects the Internet
Inquistion...").  NSI was under no obligation to publish the RRP.  That they
have done so is to the benefit of folks who are interested in this sort of
thing.  Requiring anyone who submits a proprietary protocol to the IETF for
publication as an informational RFC to also publish the minutes of internal
discussions that led to the development of that protocol sounds like a really
good way to keep anyone from publishing proprietary protocols.

NSI should be treated no differently than others who publish proprietary
protocols as an informational RFC.
 
> However, to anyone versed in technical work it is clear that if the 
> references to a work are missing, and if those references actually 
> *deny* the work being presented, then there is  something basically 
> wrong with the entire process. 

You might want to acquaint yourself with the process before declaring it
"wrong".

> Note also that the RAB, its meeting Minutes and its Action Points are also 
> not the result of an NSI private initiative as we know, Conrad, but an 
> obligation upon NSI by an  oversight body and a regulating US agency in a 
> legal contract.  

While it is true, Gerck, that the RRP is a requirement of the Amendment 11, I
do not believe NSI was under any obligation to publish _anything_ outside of a
license agreement with NSI and, in fact, the USG is required "to protect the
confidentiality of such data, software and documentation so delivered".

Rgds,
-drc

---

From: "David R. Conrad" <[email-masked]>
Date: Tue, 04 Jan 2000 19:28:26 -0800

Ed,

 

Rgds,
-drc

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 20:24:51 -0800

> protocols as an informational RFC.

Conrad:

Of course.  The IETF process is IMO actually a way of providing for
controlled release of private  information into public knowledge and use --
thus, a good thing.

However, I regret that this whole DNS area is so politicized and polarized that
instead of simply saying "I know this from the review work with NSI" even an
IETF AD such as Patrik has to say round-about things like "If I remember
correctly from a presentation NSI have had for me" and others like you feel
compelled to say that NSI "should be commended for documenting their
protocol."

Gosh, if this is really a 'call' and the IETF really wants the opinion of those
that help "make the Internet" ... and suffer with it, then can we please stay
on the technical  aspects?

The technical aspect here is that the RRP protocol documented in the
RFC proposed by NSI to the IETF is *not* what is being used by NSI
and is also *not* what should be used.

Thus, my viewpoint is that this is a "show stopper" in regard to the very
purposes of informational RFCs (pls insert copy and paste from IETF
charter) and the IETF should thus send NSI back to the drawing board.

IETF RFCs, even informational and even not more than a bag of bytes in
a server, should not be bureaucratic milestones in a chart but real
contributions -- where it is OK to be wrong since in Science a NO is
also an answer.  But, an RFC should not be fictional or clearly wrong.

Regarding your personal comment -- You might want to acquaint yourself
with the process before declaring it "wrong" -- I take it as a compliment,
because the only reason why I decided to say something here (after
a week-old message to Scott when he did release the proposed RFC)
is exactly because I am acquainted with the process but not as comfortable
with it as you seem to be.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 20:24:51 -0800

Conrad:

Cheers,

Ed Gerck

---

From: "John W. Noerenberg" <[email-masked]>
Date: Tue, 4 Jan 2000 21:49:25 -0800

>the cat is out of the bag, why should it be an RFC?

Well, to continue the Request For Comment, I suppose.

The ideas in an RFC are not cast in stone.  The words may not change, 
but that doesn't mean the ideas can't evolve and be improved.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   But now I know our world is no more permanent
   than a wave rising on the ocean.
   -- Arthur Golden, "Memoirs of a Geisha", 1997
   ----------------------------------------------------------------------

---

From: "John W. Noerenberg" <[email-masked]>
Date: Tue, 4 Jan 2000 21:49:25 -0800

john noerenberg
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 10:05:39 +0100

> and is also *not* what should be used.

If this is your view, please let me know, as AD, what the differences and 
errors are in the document.

As you say, this is the showstopper, nothing else.

The whole RRP process and many others that NSI has had (with USG, 
Registrars etc) led to a protocol which NSI has designed, and one which do 
(I claim) contain architectual mistakes, bugs, security flaws and what not.

The process is though completely irrelevant at this stage in time. Can 
people _please_ try to understand that.

NSI have approached the IETF and asks for publication of an informational 
RFC specifying their private Registry-Registrar protocol.

To be sure (I could, as AD, skipped this step!) that the protocol specified 
is what is in use, I asked for a last call to explain exactly this.

I therefore ask for input on this last question:

- Do the specification specify the protocol which NSI is using?

All responses so far has been "yes" until I found this sentence in an email 
by Ed, with no explanation at all.

I thereofore ask Ed to come with explicit references to paragraphs in the 
specification which is wrong, explanation what is happening in the protocol 
which is in use, and suggested new wording which explains the way the 
protocol works.

Without this input, I have to ignore the mail from Ed.

All other discussions is completely irrelevant, and will be ignored.

As Paul wrote, there are some ideas (separated from this discussion) on how 
to come up with _THE_ RRP which IETF endorses, and the process for that is 
to ask relevant organisations to create a buissness level functional 
requirement on such a protocol, and then develop the protocol in the IETF. 
That work has been initiated, and I see a lot of discussions here, now, 
have to do with design of a protocol, and not review of a soon-to-be 
informational RFC.

Because of that, please hold your horses!

As Dave Crocker wrote, this discussion has taken just far to much bandwidth 
already with irrelevant stuff.

We are neither discussing the quality of the NSI RRP, nor are we discussing 
how NSI ended up with that version of the protocol.

    Patrik Fältström
    Area Director, Applications Area, IETF

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 10:05:39 +0100

Patrik Fältström

---

From: Ed Gerck <[email-masked]>
Date: Wed, 05 Jan 2000 01:29:52 -0800

> As you say, this is the showstopper, nothing else.

Yes. There are two separate points in this issue.

1. The proposed RFC is not what is being used as NSI's RRP:
Catch22 -- if I point it out I may be seen to be infringing NSI's
NDA, even though I would be mostly quoting myself.  To solve
this potential problem and to avoid controversy, I just resent to
NSI the following request which intends to allow me to freely
answer your question:

 On ocasion of NSI's publication of the RFC with the
 Shared Registry Protocol, per enclosed copies, I
 hereby request my formal release from any Non-Disclosure
 obligations to NSI.  Please send me the release declaration
 by mail, and confirm by email.

Alternatively, you may verify your mailbox of RAB messages and
decide by yourself.  Also, NSI may verify the discrepancies by
themselves.

2. The proposed RFC is not what should be used:
This has become rather obvious here.  But, alternatively, I may be
released of the NDA and then comment, or you may verify your
RAB mailbox and decide by yourself, or NSI may verify it by
themselves.

I hope thus to have answered the question to your satisfaction.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 05 Jan 2000 01:29:52 -0800

Cheers,

Ed Gerck

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 10:47:44 +0100

> decide by yourself.  Also, NSI may verify the discrepancies by

As the I-D didn't exist when the RAB existed (the date of the I-D is 
December of 1999), it is plain impossible to have discussed where the I-D 
differs from what was in use.

Please try again.

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 10:47:44 +0100

Please try again.

   paf

---

From: Ed Gerck <[email-masked]>
Date: Wed, 05 Jan 2000 02:37:23 -0800

> differs from what was in use.

Try again?  No, pls just follow what I suggested -- compare the December
1999 I-D (which you have, let me call this "Evidence A") with the RAB
archives and documents from March 1999 to October 1999 (which you
also have, let me call this "Evidence B").  Then, comparing Evidence A
with Evidence B you may draw your own conclusions about Evidence A
being actually *outdated* (time warp?) when compared with Evidence B
even though Evidence B was issued much *earlier*.  What we have in the
proposed RFC is thus an outdated spec -- problems that were actually
reported *solved* in the March-October 1999 timeframe appear again
*unsolved* in the December 1999 timeframe.

Regarding  Evidence C (what is actually used today), it is thus quite possible
to infer that it does differ from Evidence A (the proposed RFC), since Evidence
A is outdated even when compared to Evidence B which predates Evidence C.
In other words, the proposed RFC and the actual RRP protocol seem to have a
larger distance than even that between the proposed RFC and the RAB
Minutes/Documents -- which is probably not zero as you yourself say above.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 05 Jan 2000 02:37:23 -0800

Cheers,

Ed Gerck

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 11:44:15 +0100

--On 2000-01-05 02.37 -0800, Ed Gerck <[email-masked]> wrote:

> What we have in the

In real life, I have not checked whether NSI really _uses_ what we talked 
about in the timeframe March-October, and in some cases (timestamps for 
example) it is already clear that they use what is specified in the I-D and 
NOT what the RAB proposed, i.e. what is in the email archives of RAB.

So, in what order the specifications were created have nothing to do with 
what we are checking today. We are checking the I-D with what is used. 
Nothing else.

Have you been using the protocol that is in use today?

If not, I ask myself how you can state that the protocol is different from 
what is specified in the I-D.

    paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 11:44:15 +0100

paf

---

From: Ed Gerck <[email-masked]>
Date: Wed, 05 Jan 2000 02:54:17 -0800

> NOT what the RAB proposed, i.e. what is in the email archives of RAB.

How can you say " in some cases (timestamps for example) it is already
clear that they use what is specified in the I-D"?  Did you test it? Have you
been using the protocol that is in use today?

If not, I ask myself how you can state that the protocol is what is specified
in the I-D.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 05 Jan 2000 02:54:17 -0800

Cheers,

Ed Gerck

---

From: Ian Jackson <[email-masked]>
Date: Wed, 5 Jan 2000 12:17:21 +0000 (GMT)

> transfer is always to the registrar issuing the command, but I might be 

That's right, but the command I was talking about was the transfer
_approval_, which is also performed with the TRANSFER command with a
different syntax.  The transfer is approved by the donor, but there is
no way to find out or specify the intended recipient.

Ian.

---

From: Ian Jackson <[email-masked]>
Date: Wed, 5 Jan 2000 12:17:21 +0000 (GMT)

Ian.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 05 Jan 2000 09:01:28 -0500

I think it is important to the openness of the process to maintain the
tradition of a relatively light editorial hand on Informational RFCs
that document non-IETF protocols.  The minimal substantive part of
this review increasingly seems to be done by the IESG instead of the
RFC Editor.

From:  Gordon Cook <[email-masked]>
Message-Id:  <v04210102b49844c2f1c5@[192.168.0.1]>
In-Reply-To:  <[email-masked]>
References:  <[email-masked]>
	     <[email-masked]>
Date:  Tue, 4 Jan 2000 20:43:21 -0500

>common practice to do this with an informational rfc). ....

Although extremely brief RFC-Editor/IESG comments (as in one or two
sentences) are sometimes included in a non-IETF Informational RFC, I
know of no case in which some third party's general comments have been
included.  Such third parties can write up their comments as a
separate Informational document and submit it to the RFC Editor for
publication if they want.

>clueless party  as an endorsement?

To the extent that the IESG undertook to do a detailed quality review
of non-IETF Informational RFC protocols and includes the results of
such a review in the RFC, it would thereby assume legal liability.
The way to avoid such liability is maintain as minimal a review as
possible.

> ....

Donald
===================================================================
 Donald E. Eastlake 3rd   +1 914-276-2668   [email-masked]
 65 Shindegan Hill Rd, RR#1
 Carmel, NY 10512 USA

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 05 Jan 2000 09:01:28 -0500

Donald

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 15:27:30 +0100

--On 2000-01-05 02.54 -0800, Ed Gerck <[email-masked]> wrote:

> clear that they use what is specified in the I-D"?  Did you test it? Have
> you been using the protocol that is in use today?

Because I have already received some comments on the last-call from some 
parties which definitely _are_ using the RRP today, and it is confirmed 
with NSI.

All comments are not sent in public, you know, but most do answer the 
question I, as AD, asks according to the process in the IETF.

    Patrik Fältström

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 15:27:30 +0100

Patrik Fältström

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Jan 2000 06:42:12 -0800

> 2. The proposed RFC is not what should be used:

this is not relevant to the publication of *this* rfc, the intent of which
is to document what IS used not what SHOULD BE used.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Jan 2000 06:42:12 -0800

randy

---

From: Rick H Wesson <[email-masked]>
Date: Wed, 5 Jan 2000 07:04:58 -0800 (PST)

randy,

the RFC is what will be used, RRP version 1.1.0 is in the OT&E (test
environemnt) slated to be put into general availability on Jan 15th.

The current version in production is RRP 1.0.6

-rick

---

From: Rick H Wesson <[email-masked]>
Date: Wed, 5 Jan 2000 07:04:58 -0800 (PST)

randy,

-rick

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 16:17:15 +0100

> The current version in production is RRP 1.0.6

The I-D in question states in the first sentence of section 1:

    This document describes the specifications for the Registry Registrar
    Protocol (RRP) version 1.1.0

That is enough for me, as John points out.

    Patrik Fältström

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 05 Jan 2000 16:17:15 +0100

Patrik Fältström

---

From: [email-masked]
Date: Wed, 05 Jan 2000 14:31:59 -0500

> readers that the RFc should *not* be followed.

For a moment, I thought "but you can do that now..."

Then I took a look at RFC2026 in closer detail, and section 3.3 (e)
defines a "Not Recommended" status, just like I remembered.

Unfortunately, that seems to be strictly applicable to standards-track
documents only, not 'informational'.  Whether this is a bug or a feature
I'll let others decide - it looks like a giant economy sized can-o-worms.

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: [email-masked]
Date: Wed, 05 Jan 2000 14:31:59 -0500