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

[Vernon Schryver]

> From: [EMAIL PROTECTED]

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


I've been whining about such problems with informational RFC's for years.
It's clear that for familiar bureaucratic and social or political reasons,
the IETF will not in the foreseeable future do any real filtering of
Information (or even in many cases of standards track) RFC's.  Even I
admit that real filtering would have major problems and leads inevitably
to something even more like the ANSI, IEEE, and ITU than the IETF has
already become.

There is an alternative that would be more effective and easier.  That is
to do even less filtering than is done now.  Advancing many drafts like
draft-terrell-ip-spec-ipv7-ipv8-addr-cls-*.txt would go a long way to
removing the incentive for organizations to try to misappropriate the
cachet of the IETF with Informational RFC's.  Flooding the space with
RFC's that are other than influential would be more effective than any
disclaimers, more effective than filtering, and easier than the limited
filtering currently provided by the IESG and the RFC Editor.

I suspect analogous thinking but about the academic stuffed shirt syndrome
was one of the motivations for the early April Fool's RFC's.  Today, the
audience (and many of the authors) of RFC's are not capable of inferring
such an implication of new versions of Avian Carriers.  Something less
subtle is needed.

In other words, consider the ideas behind the censoring that has gotten
some ISP's into trouble and the lack of censoring that has protected
others.


Vernon Schryver[EMAIL PROTECTED]

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

[Valdis . Kletnieks]

On Tue, 04 Jan 2000 15:58:37 PST, Rick H Wesson said:
> 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.

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


 PGP signature

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Patrik Fältström]

--On 2000-01-05 07.04 -0800, Rick H Wesson <[EMAIL PROTECTED]> wrote:

> 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

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
Area Director, Applications Area, IETF

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Rick H Wesson]

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

On Wed, 5 Jan 2000, Randy Bush wrote:

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

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Randy Bush]

> 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

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Patrik Fältström]

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

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

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
Area Director, Applications Area, IETF

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

[Donald E. Eastlake 3rd]

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 PROTECTED]>
Message-Id:  
In-Reply-To:  <[EMAIL PROTECTED]>
References:  <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>
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). 

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.

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

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 PROTECTED]
 65 Shindegan Hill Rd, RR#1
 Carmel, NY 10512 USA

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

[Ian Jackson]

Patrik Fältström writes ("Re: Last Call: Registry Registrar Protocol (RRP) Version 
1.1.0 to   Informational"):
> --On 2000-01-04 17.21 +, Ian Jackson <[EMAIL PROTECTED]> 
> wrote:
> > * The TRANSFER command, when used to approve a transfer, does not
> > 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.

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.

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Ed Gerck]

Patrik Fältström wrote:

> --On 2000-01-05 02.37 -0800, Ed Gerck <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> 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.

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

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Patrik Fältström]

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

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

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

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Ed Gerck]

Patrik Fältström wrote:

> --On 2000-01-05 01.29 -0800, Ed Gerck <[EMAIL PROTECTED]> wrote:
>
> > Alternatively, you may verify your mailbox of RAB messages and
> > decide by yourself.  Also, NSI may verify the discrepancies by
> > themselves.
>
> 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.

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

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Patrik Fältström]

--On 2000-01-05 01.29 -0800, Ed Gerck <[EMAIL PROTECTED]> wrote:

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

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

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Ed Gerck]

Patrik Fältström wrote:

> --On 2000-01-04 20.24 -0800, Ed Gerck <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> 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.

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

Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Patrik Fältström]

--On 2000-01-04 20.24 -0800, Ed Gerck <[EMAIL PROTECTED]> wrote:

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

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

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

[John W. Noerenberg]

At 3:05 PM -0800 1/4/00, Rick H Wesson wrote:
>The document exists as an I-D,
>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 PROTECTED]
   --
   But now I know our world is no more permanent
   than a wave rising on the ocean.
   -- Arthur Golden, "Memoirs of a Geisha", 1997
   --

Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[Ed Gerck]

"David R. Conrad" wrote:

> NSI should be treated no differently than others who publish proprietary
> 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

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

[David R. Conrad]

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

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

[Rick H Wesson]

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


On Tue, 4 Jan 2000, David R. Conrad wrote:

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

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

[Dave Crocker]

At 04:29 PM 1/4/2000 , David R. Conrad wrote:
> > I hate to add a "me too" but I must. I believe that the RAB minutes would
> > 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?

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 PROTECTED]>
Brandenburg Consulting  
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA 

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

[Gordon Cook]

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

***

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

[Ed Gerck]

"David R. Conrad" wrote:

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

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

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

[David R. Conrad]

Rick,

> I hate to add a "me too" but I must. I believe that the RAB minutes would
> 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?

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

I-Ds expire.
 
> The IETF does not need to publish broken implementations of one companies
> 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).

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

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

[Paul Hoffman / IMC]

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

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

[Paul Hoffman / IMC]

At 03:58 PM 1/4/00 -0800, Rick H Wesson wrote:
>In short you are suggesting that the I-D be published to document a
>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
>not "in the know" as to how these things work.

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
--Internet Mail Consortium

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

[Rick H Wesson]

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


On Tue, 4 Jan 2000, Paul Hoffman / IMC wrote:

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

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

[Karl Auerbach]

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

Since I-Ds still officially vanish after a while, we need to move it to
RFC to maintain its visibility.  

> The IETF does not need to publish broken implementations of one companies 
> 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--

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

[Rick H Wesson]

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




On Tue, 4 Jan 2000, Ed Gerck wrote:

> 
> 
> Patrik Fältström wrote:
> 
> > 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.
> 
> 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
> 

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

[Ed Gerck]

Patrik Fältström wrote:

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

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

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

[Ed Gerck]

[resent from subscribed address, my apologies
if the TO list receives it twice]

Patrik Fältström wrote:

> --On 2000-01-04 17.21 +, Ian Jackson <[EMAIL PROTECTED]>
> wrote:
>
> > * The TRANSFER command, when used to approve a transfer, does not
> > 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

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

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

[Patrik Fältström]

--On 2000-01-04 13.20 -0800, Ed Gerck <[EMAIL PROTECTED]> wrote:

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

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

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

[Ed Gerck]

Patrik Fältström wrote:

> --On 2000-01-04 17.21 +, Ian Jackson <[EMAIL PROTECTED]>
> wrote:
>
> > * The TRANSFER command, when used to approve a transfer, does not
> > 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

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

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

[Patrik Fältström]

--On 2000-01-04 17.21 +, Ian Jackson <[EMAIL PROTECTED]> 
wrote:

> * The TRANSFER command, when used to approve a transfer, does not
> 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

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

[Ian Jackson]

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  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 PROTECTED] or [EMAIL PROTECTED] 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.

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

[Kent Crispin]

On Fri, Dec 31, 1999 at 02:09:39PM +0100, Patrik Fältström wrote:
> --On 99-12-31 02.39 +0100, Harald Tveit Alvestrand <[EMAIL PROTECTED]> 
> wrote:
> 
> > but think that the title should be "The NSI Registry Registrar Protocol,
> > version 1.1.0", to avoid confusion with any competing Registry/Registrar
> > protocol that may appear later.
> 
> Agreed!

Likewise.

-- 
Kent Crispin   "Do good, and you'll be
[EMAIL PROTECTED]   lonesome." -- Mark Twain

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

[Harald Tveit Alvestrand]

I support the publication of this document, but think that the title should 
be "The NSI Registry Registrar Protocol, version 1.1.0", to avoid confusion 
with any competing Registry/Registrar protocol that may appear later.

Harald A


At 14:22 30.12.99 -0500, The IESG wrote:

>The IESG has received a request to consider Registry Registrar Protocol
>(RRP) Version 1.1.0  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 PROTECTED] or [EMAIL PROTECTED] mailing lists by January 13, 2000.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-hollenbeck-rrp-00.txt

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[EMAIL PROTECTED]