> 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
>At 09:38 PM 1/4/00 -0500, Gordon Cook wrote:
> > I carry a lot of ICANN data around in my head and I am generally
> >pretty good at it. However my attention has been called to the fact
> >that I screwed up on my association with Patrick as an ICANN board
> >member. Following a few URL trails
Normally I ignore Cook, and am grateful to have missed the original screed.
Technical contributions on the content of the draft-hollenbeck-rrp-00.txt
are nice, but deviations from content analysis are awkward.
Eric
At 09:38 PM 1/4/00 -0500, Gordon Cook wrote:
> I carry a lot of ICANN data around in my head and I am generally
>pretty good at it. However my attention has been called to the fact
>that I screwed up on my association with Patrick as an ICANN board
>member. Following a few URL trails I see
John Klensin wrote, in part:
> In summary, I believe that our advice to the IESG should be
> "make certain this document is clear about what it is and what
> it proports to be, and that the authors (or author organization)
> take responsibility for that being true. Make certain that,
> should a
--On Wednesday, 05 January, 2000 06:32 -0800 Ed Gerck
<[EMAIL PROTECTED]> wrote:
> Yes, but IMO IETF RFCs, even informational, 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. So, an RFC should no
--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:
>
>
Title: Vous constatez régulièrement
Vous constatez régulièrement
:
qu'il est difficile de
disposer de temps pour réunir la documentation nécessaire à la
constitution de vos dossiers ou simplement y acc
> 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
> If you send your nroff input file to the RFC editor as well as the
> nroff'd output file, which is the recommended practice, then modifying
> the ms macros themselves is not an option.
Well, sort of. You can .rm an existing macro and .de it differently.
I do that for the SH, H, XS, XA, XE, XE
John C Klensin wrote:
> Ed, I've followed your comments very carefully, but, applying
> your reasoning to what I see as long-standing principles for
> handling Info RFCs, I reach nearly opposite conclusions.
Then, we have gone full circle because your reasoning is exactly
mine in its gist -- a
--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've trimmed most of the cc's on the theory that everyone
relevant except possibly Scott are on the IETF or IESG lists.
Ed, I've followed your comments very carefully, but, applying
your reasoning to what I see as long-standing principles for
handling Info RFCs, I reach nearly opposite conclus
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
> > specify to which registrar the domain i
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
23 matches
Mail list logo
