Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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, please let me know, as AD, what the differences and errors are in the document. As you say, this is the showstopper, nothing else. Yes. There are two separate points in this issue. 1. The proposed RFC is not what is being used as NSI's RRP: Catch22 -- if I point it out I may be seen to be infringing NSI's NDA, even though I would be mostly quoting myself. To solve this potential problem and to avoid controversy, I just resent to NSI the following request which intends to allow me to freely answer your question: On ocasion of NSI's publication of the RFC with the Shared Registry Protocol, per enclosed copies, I hereby request my formal release from any Non-Disclosure obligations to NSI. Please send me the release declaration by mail, and confirm by email. Alternatively, you may verify your mailbox of RAB messages and decide by yourself. Also, NSI may verify the discrepancies by themselves. 2. The proposed RFC is not what should be used: This has become rather obvious here. But, alternatively, I may be released of the NDA and then comment, or you may verify your RAB mailbox and decide by yourself, or NSI may verify it by themselves. I hope thus to have answered the question to your satisfaction. Cheers, Ed Gerck
Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 the I-D is December of 1999), it is plain impossible to have discussed where the I-D differs from what was in use. Please try again. Try again? No, pls just follow what I suggested -- compare the December 1999 I-D (which you have, let me call this "Evidence A") with the RAB archives and documents from March 1999 to October 1999 (which you also have, let me call this "Evidence B"). Then, comparing Evidence A with Evidence B you may draw your own conclusions about Evidence A being actually *outdated* (time warp?) when compared with Evidence B even though Evidence B was issued much *earlier*. 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. Regarding Evidence C (what is actually used today), it is thus quite possible to infer that it does differ from Evidence A (the proposed RFC), since Evidence A is outdated even when compared to Evidence B which predates Evidence C. In other words, the proposed RFC and the actual RRP protocol seem to have a larger distance than even that between the proposed RFC and the RAB Minutes/Documents -- which is probably not zero as you yourself say above. Cheers, Ed Gerck
Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
--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 checked whether NSI really _uses_ what we talked about in the timeframe March-October, and in some cases (timestamps for example) it is already clear that they use what is specified in the I-D and NOT what the RAB proposed, i.e. what is in the email archives of RAB. So, in what order the specifications were created have nothing to do with what we are checking today. We are checking the I-D with what is used. Nothing else. Have you been using the protocol that is in use today? If not, I ask myself how you can state that the protocol is different from what is specified in the I-D. paf
Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 timeframe. In real life, I have not checked whether NSI really _uses_ what we talked about in the timeframe March-October, and in some cases (timestamps for example) it is already clear that they use what is specified in the I-D and NOT what the RAB proposed, i.e. what is in the email archives of RAB. 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? If not, I ask myself how you can state that the protocol is what is specified in the I-D. Cheers, Ed Gerck
Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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
Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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: 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
Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
--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 sentence of section 1: This document describes the specifications for the Registry Registrar Protocol (RRP) version 1.1.0 That is enough for me, as John points out. Patrik Fältström Area Director, Applications Area, IETF
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 RFc should *not* be followed. For a moment, I thought "but you can do that now..." 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. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 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 PROTECTED]
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 in the IETF but is not the product of an
IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
[EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by January 13, 2000.
I can see at least the following problems with this protocol, in
addition to those described in it:
* The TRANSFER command, when used to approve a transfer, does not
specify to which registrar the domain is to be transferred. The
document says that the details of transfer arrangements should be
handled out-of-band by eg electronic mail. However, that would not
prevent a domain mistakenly or maliciously being transferred to the
wrong new registrar. It is essential that this deficiency in the
protocol is corrected or worked around forthwith, as currently a
malicious registrar who is able to manipulate unsecured out-of-band
email may be able to cause the domain to be transferred to themselves
instead of to the intended recipient registrar.
A workaround would be for the intended recipient to send (via another
protocol) to the donor an authenticated confirmation to the that it
had successfully lodged the transfer request, so that if the donor is
willing to transfer to that registrar it can safely approve the
transfer. However, the technical integrity of this scheme depends on
the registry never unexpectedly losing or timing out transfer
requests, and on donors to keep a record of all recent transfer
requests to ensure that the right request is accepted; the sociolegal
integrity of such a workaround may depend on extremely complicated
contractual issues, which is not my field of expertise. In any case
this caveat should be addressed in any Information RFC.
* The use of passwords for identifying registrars rather than the
certificate information corresponding to the SSL session is very
unwise. The secret(s) which identify a registrar should never leave
that registrar. For example, a security compromise at the registry
would require all the registrars' passwords to be changed, and
redistributed via secure out-of-band channels. Furthermore, the use
of passwords makes it impossible to use secure hardware to store the
critical key material. This misfeature should be fixed in future
versions and implementations.
* The use of registry local time in time stamps is absurd (and will
likely lead to daylight saving change bugs etc.). The time used
should be in UTC, or preferably elapsed civil time measured as the
number of non-leap seconds since a suitable epoch. This misfeature
should be fixed in a future protocol version.
* The use of SSL, rather than individually authenticating requests and
responses (or batches of them), means that there is no audit trail,
verifiable by a third party, for resolving disputes. This bug should
be fixed in a future protocol version.
I think that any Informational RFC describing this protocol should at
the very least mention these deficiencies as well as those it already
lists.
Ian.
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 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
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
--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 called to help verify and provide free but otherwise professional advice. If RAB was mentioned, I would have been more careful with the document, but as the RAB only had limited input to the actual design of the protocol, the RAB should not, and is not, mentioned. In this case though, the document will specify "the NSI R-R protocol", nothing else. It is often organizations do present and make specifications available of their private inventions through publications of Informational RFCs, so this is nothing special. The IETF in this case must differentiate between input to the NSI on whether the protocol is good or bad, and maybe on how to make the protocol better in the future, and whether the document specifies what is currently in use. The last call in the IETF is regarding the latter, not the quality of the protocol. The IESG can still make a recommendation to NOT publish the (private) protocol as informational RFC, for example if the protocol damages the functionality of the Internet. In this case, where we talk about one specific application, that is probably not the case. 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 issues, and come with comments on the correctness of the document. Comments on the protocol can be sent directly to NSI. Patrik Fältström Area Director, Applications Area
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
[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 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
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 issues, and come with comments on the correctness of the document. Comments on the protocol can be sent directly to NSI. IMO you are following a very slippery slope here. You seem now to be moving into "explanation mode" in order to say that the protocol's effectiveness is not important, just its perfunctory functions. In other words, you as AD and member of the IESG are saying that protocols are to be published as RFCs even if knowingly technically wrong, inefficient, outdated and insecure -- provided they are "in use". Well, I may be a little less pragmatic than you and I question exactly the correctness of the document, as well as its effectiveness. And, since our names are still in NSI's page for the Registry Advisory Board (RAB) and we were involved with it, I also think that the IETF should know that the SRP being proposed by NSI as an RFC and being followed through IETF under yours (a former member of the RAB) apparent approval is not what the RAB discussed and formally requested to change as documented in the RAB minutes locked under NDA. The RAB in Ammendment 11 has thus become a mock review process locked under NDA, even though the RAB was officially called by the USG 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." The least I suggest is to make the RAB Metting Minutes, together with its Action Plan, public -- before furthering this RFC in the IETF. Why should other people need to reinvent the same comments again? The hope that some will not be reinvented is IMO ill-founded as security experience shows all the time -- obscurity is not a basis for security. Now, of course, if NSI wants to keep the protocol private then I have no further comments. Cheers, Ed Gerck
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 that NSI has published the I-D for their protocol, now does it need to go beyond that and become an RFC, IMHO, no. The IETF does not need to publish broken implementations of one companies view of the shared gTLD registration process. Having an AD that sat on the RAB promote the I-D and offer no reasoning as to why it *should be* published as an Informational RFC reminds me of the bad taste left by the IAHC and all the processes related. I would request that the IESG let this draft expire and create a WG to tackle the problem. I would be interested in hearing just why the IESG thinks this document should be published. The document exists as an I-D, the cat is out of the bag, why should it be an RFC? Its broken and of bad design we don't need that kind of thing published any further than it has been. regards, -rick On Tue, 4 Jan 2000, Ed Gerck wrote: 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 issues, and come with comments on the correctness of the document. Comments on the protocol can be sent directly to NSI. IMO you are following a very slippery slope here. You seem now to be moving into "explanation mode" in order to say that the protocol's effectiveness is not important, just its perfunctory functions. In other words, you as AD and member of the IESG are saying that protocols are to be published as RFCs even if knowingly technically wrong, inefficient, outdated and insecure -- provided they are "in use". Well, I may be a little less pragmatic than you and I question exactly the correctness of the document, as well as its effectiveness. And, since our names are still in NSI's page for the Registry Advisory Board (RAB) and we were involved with it, I also think that the IETF should know that the SRP being proposed by NSI as an RFC and being followed through IETF under yours (a former member of the RAB) apparent approval is not what the RAB discussed and formally requested to change as documented in the RAB minutes locked under NDA. The RAB in Ammendment 11 has thus become a mock review process locked under NDA, even though the RAB was officially called by the USG 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." The least I suggest is to make the RAB Metting Minutes, together with its Action Plan, public -- before furthering this RFC in the IETF. Why should other people need to reinvent the same comments again? The hope that some will not be reinvented is IMO ill-founded as security experience shows all the time -- obscurity is not a basis for security. Now, of course, if NSI wants to keep the protocol private then I have no further comments. Cheers, Ed Gerck
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 does not need to publish broken implementations of one companies view of the shared gTLD registration process. We can learn from the flaws of the past. And this RRP certainly gives us a lot to learn from. I would hope that having an Informational RFC on the RRP would motivate some folks to think up, write down, and publish "A Better RRP". Your own work on the representing the whois data using XML is perhaps a good start. (I can imagine that many sites with big zone files might find it useful to have a tool using "A Better RRP" to distribute the administration of their zone.) By-the-way, I think that the IETF has already jumped through enough hoops regarding the mis-perception by some that the letters "RFC" are some sort of seal of approval. --karl--
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 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 RFc should *not* be followed. I doubt I'd implement RFC -1 ;-) regards, -rick On Tue, 4 Jan 2000, Paul Hoffman / IMC wrote: 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 Informational RFCs that document interesting (for some value of interesting) protocols that were not developed in the IETF but are of interest to the Internet community. In my mind NSI's RRP certainly qualifies. As long as the protocol does not directly harm the Internet on a technical level (not a political level; they all do that), the IESG might want to see it published.
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 protocol? 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. I-Ds expire. The IETF does not need to publish broken implementations of one companies view of the shared gTLD registration process. Then you were unhappy that (oh, say) Cisco submitted RFC 2281 as an informational RFC (not saying HSRP is "broken", but I'm sure someone would). Having an AD that sat on the RAB promote the I-D and offer no reasoning as to why it *should be* published as an Informational RFC reminds me of the bad taste left by the IAHC and all the processes related. I find this offensive. 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. However, INFORMATIONAL RFCS DO NOT IMPLY ENDORSEMENT. The draft is a representation of an existing, in use proprietary protocol. No further justification should be necessary for documenting it as an informational RFC. Rgds, -drc
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 could talk to the RAB and that the testbed registrars have some problems with RRP? We all know that the entire development of rrp was sub-optimal and yes Informational does not implay Endorsement but that is a fact that most of the world does not understand and is an entirely different thread. I have atempted as have others to outline many issues we have had with the RRP protocol and its developemnt. I realy can't do more than that. -rick On Tue, 4 Jan 2000, David R. Conrad wrote: I find this offensive. 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. However, INFORMATIONAL RFCS DO NOT IMPLY ENDORSEMENT. The draft is a representation of an existing, in use proprietary protocol. No further justification should be necessary for documenting it as an informational RFC.
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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
Inquistion..."). NSI was under no obligation to publish the RRP. That they
have done so is to the benefit of folks who are interested in this sort of
thing. Requiring anyone who submits a proprietary protocol to the IETF for
publication as an informational RFC to also publish the minutes of internal
discussions that led to the development of that protocol sounds like a really
good way to keep anyone from publishing proprietary protocols.
NSI should be treated no differently than others who publish proprietary
protocols as an informational RFC.
However, to anyone versed in technical work it is clear that if the
references to a work are missing, and if those references actually
*deny* the work being presented, then there is something basically
wrong with the entire process.
You might want to acquaint yourself with the process before declaring it
"wrong".
Note also that the RAB, its meeting Minutes and its Action Points are also
not the result of an NSI private initiative as we know, Conrad, but an
obligation upon NSI by an oversight body and a regulating US agency in a
legal contract.
While it is true, Gerck, that the RRP is a requirement of the Amendment 11, I
do not believe NSI was under any obligation to publish _anything_ outside of a
license agreement with NSI and, in fact, the USG is required "to protect the
confidentiality of such data, software and documentation so delivered".
Rgds,
-drc
Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
"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, a good thing. However, I regret that this whole DNS area is so politicized and polarized that instead of simply saying "I know this from the review work with NSI" even an IETF AD such as Patrik has to say round-about things like "If I remember correctly from a presentation NSI have had for me" and others like you feel compelled to say that NSI "should be commended for documenting their protocol." Gosh, if this is really a 'call' and the IETF really wants the opinion of those that help "make the Internet" ... and suffer with it, then can we please stay on the technical aspects? 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. Thus, my viewpoint is that this is a "show stopper" in regard to the very purposes of informational RFCs (pls insert copy and paste from IETF charter) and the IETF should thus send NSI back to the drawing board. IETF RFCs, even informational and even not more than a bag of bytes in a server, 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. But, an RFC should not be fictional or clearly wrong. Regarding your personal comment -- You might want to acquaint yourself with the process before declaring it "wrong" -- I take it as a compliment, because the only reason why I decided to say something here (after a week-old message to Scott when he did release the proposed RFC) is exactly because I am acquainted with the process but not as comfortable with it as you seem to be. Cheers, Ed Gerck
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 protocol that may appear later. Agreed! Likewise. -- Kent Crispin "Do good, and you'll be [EMAIL PROTECTED] lonesome." -- Mark Twain
