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
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 RRP
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
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
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
13 matches
Mail list logo
