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

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 14:01:28 -0800

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

Patrik Fältström wrote:

> --On 2000-01-04 17.21 +0000, Ian Jackson <[email-masked]>
> 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

---

From: Ed Gerck <[email-masked]>
Date: Tue, 04 Jan 2000 14:01:28 -0800

Patrik:

Cheers,

Ed Gerck

   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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 5 Jan 2000 15:38:31 -0700 (MST)

> From: [email-masked]

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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 5 Jan 2000 15:38:31 -0700 (MST)