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,
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
--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
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
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
randy,
the RFC is what will be used, RRP version 1.1.0 is in the OTE (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:
--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 OTE (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
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
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
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 i
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
--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
[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
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
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
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. Let's defer comments on the I-D fade out
policy.
The IETF
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
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
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
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
"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,
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
22 matches
Mail list logo
