> 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
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 th
--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
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:
>
>
> 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
--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 receive
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: G
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
> > spe
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 199
--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 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 (th
--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)
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
--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, w
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 ev
"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
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 Interne
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
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
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 th
"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 encour
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
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 Informatio
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-intu
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 bett
> 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
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 th
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
[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
--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
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 fo
--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 r
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
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/Re
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:
35 matches
Mail list logo
