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
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: 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 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 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: 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 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: > > 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
> 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 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 received some comments on the last-call from some parties which definitely _are_ using the RRP today, and it is confirmed with NSI. All comments are not sent in public, you know, but most do answer the question I, as AD, asks according to the process in the IETF. Patrik Fältström Area Director, Applications Area, IETF
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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: Gordon Cook <[EMAIL PROTECTED]> Message-Id:In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Date: Tue, 4 Jan 2000 20:43:21 -0500 >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 this with an informational rfc). Although extremely brief RFC-Editor/IESG comments (as in one or two sentences) are sometimes included in a non-IETF Informational RFC, I know of no case in which some third party's general comments have been included. Such third parties can write up their comments as a separate Informational document and submit it to the RFC Editor for publication if they want. >Is it really the position of the IESG that they have NO obligation to >do anything to inform the unwary that this protocol is an invitation >for lawsuits against NSI, against ICANN, and possibly against the >IETF on the grounds that the RFC publication was perceived by the >clueless party as an endorsement? To the extent that the IESG undertook to do a detailed quality review of non-IETF Informational RFC protocols and includes the results of such a review in the RFC, it would thereby assume legal liability. The way to avoid such liability is maintain as minimal a review as possible. > Donald === Donald E. Eastlake 3rd +1 914-276-2668 [EMAIL PROTECTED] 65 Shindegan Hill Rd, RR#1 Carmel, NY 10512 USA
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 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. That's right, but the command I was talking about was the transfer _approval_, which is also performed with the TRANSFER command with a different syntax. The transfer is approved by the donor, but there is no way to find out or specify the intended recipient. Ian.
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
--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 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 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. 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-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
--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. The whole RRP process and many others that NSI has had (with USG, Registrars etc) led to a protocol which NSI has designed, and one which do (I claim) contain architectual mistakes, bugs, security flaws and what not. The process is though completely irrelevant at this stage in time. Can people _please_ try to understand that. NSI have approached the IETF and asks for publication of an informational RFC specifying their private Registry-Registrar protocol. To be sure (I could, as AD, skipped this step!) that the protocol specified is what is in use, I asked for a last call to explain exactly this. I therefore ask for input on this last question: - Do the specification specify the protocol which NSI is using? All responses so far has been "yes" until I found this sentence in an email by Ed, with no explanation at all. I thereofore ask Ed to come with explicit references to paragraphs in the specification which is wrong, explanation what is happening in the protocol which is in use, and suggested new wording which explains the way the protocol works. Without this input, I have to ignore the mail from Ed. All other discussions is completely irrelevant, and will be ignored. As Paul wrote, there are some ideas (separated from this discussion) on how to come up with _THE_ RRP which IETF endorses, and the process for that is to ask relevant organisations to create a buissness level functional requirement on such a protocol, and then develop the protocol in the IETF. That work has been initiated, and I see a lot of discussions here, now, have to do with design of a protocol, and not review of a soon-to-be informational RFC. Because of that, please hold your horses! As Dave Crocker wrote, this discussion has taken just far to much bandwidth already with irrelevant stuff. We are neither discussing the quality of the NSI RRP, nor are we discussing how NSI ended up with that version of the protocol. Patrik Fältström Area Director, Applications Area, IETF
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 evolve and be improved. -- john noerenberg [EMAIL PROTECTED] -- But now I know our world is no more permanent than a wave rising on the ocean. -- Arthur Golden, "Memoirs of a Geisha", 1997 --
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
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
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
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 to the implementation >of their proprietary protocol? No. Informational RFCs for proprietary protocols have been published many times. The IETF portion of the process to publish such documents is simply to ensure that we avoid confusion with IETF work. That is amply obtained through the suggested title change. The topic really does not warrant nearly as much discussion as it is getting. d/ =-=-=-=-= Dave Crocker <[EMAIL PROTECTED]> Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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 this with an informational rfc). Isn't this such an egregious and high profile example that the IESG out to choose to excercise some consumer protection here? NSI's own panel of experts, its own RAB said the protocol was broken did they not? Yet NSI went ahead and implemented it anyway. NSI is operating a flawed protocol to handle a registration process for names that can now command huge sums of money? The protocol is now under the stewardship of ICANN which so far is allowing something to operate which has a major potential to bring law suits down on its head . Patrick who is now a member of the ICANN board and was a member of the RAB and thus has ample reason to know how badly the protocol has been designed is saying that the protocol should be published albeit as a LOWLY INFORMATIONAL RFC with nothing in the packaging to indicate that trouble lurks within? Is it really the position of the IESG that they have NO obligation to do anything to inform the unwary that this protocol is an invitation for lawsuits against NSI, against ICANN, and possibly against the IETF on the grounds that the RFC publication was perceived by the clueless party as an endorsement? I just saw David Conrads statement and I understand the point he makes. Still I wonder how wise the insistence is on hewing to old traditions in this case. Where do Patrick's obligations fall? To the IESG in holding his nose in saying we won't break precedent and even though we all undestand this is a series of disasters waiting to happen we will publish the sucker as we always to without further explanation? Or as an ICANN Board member does he have a legal and fiduciary duty to ICANN as a corporation to act in such a way to see thatin the future no internet ignorant corporation could ever step forward and claim that - having been involved in the creation of a flawed product - he had a duty to ICANN to label it as flawed and should he chose not to he could find lawyers going after him. How many ICANN board members understand what their personal legal liability is? >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. > >Given the somewhat obvious nature of the protocol's faults, I would >think that the community would welcome it being published openly and >permanently; that way they can always refer to in while improving it. > >>Having an AD that sat on the >>RAB promote the I-D > >Sorry, but this is garbage. Nothing that Patrik said promotes the protocol. > >>and offer no reasoning as to why it >>*should be* published as an Informational RFC > >He said that about three times; please re-read the past few messages >with slightly clearer eyes. > >>I would request that the IESG let this draft expire and create a WG to >>tackle the problem. > >It is not clear that the IETF is the proper place to tackle this >problem. From the number of mistakes in the NSI RRP, I believe that >a better way to create such a protocol is to start with a >requirements document. A few folks have kicked around the idea of >creating an IETF WG, but it became clear that the expertise to set >down the *requirements* are more likely to be in the ICANN DNSO, not >the IETF. That is, ask the registrars and registries, not a bunch of >protocol-writers. After the requirements are settled, the IETF could >probably help write the protocol. > >Having those directly involved in the field set down the >requirements first will delay the shipment of the new protocol, but >it is very likely to cause the outcome to be much better for all >involved. This has been shown again and again (with both positive >and negative examples) in the IETF. > >>The document exists as an I-D, >>the cat is out of the bag, why should it be an RFC? > >To make it permanently and easily and freely accessible to the >entire Internet community forever. There are many Informational RFCs >that have been published for these reasons. > >--Paul Hoffman, Director >--Internet Mail Consortium ***
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
"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 encouraged NSI to publish the RRP protocol, and I believe I was actually the first that said so to NSI. This is however IMO irrelevant here -- 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. Given the secret (but not private) nature of the RAB Meeting Minutes, I am effectively barred to comment further -- even though I would just be repeating my own comments. 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. This is what happens here and that is why I am not convinced that the NSI RFC should be published by the IETF unless the very references to that work which resulted from a US Government contract be made available and public as well, as "supporting" documentation missing in the RFC. 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. I imagine that the Freedom of Information Act could be used to make those notes public since they were mandated by the direct act of a US agency, who also has copies of them. And I see no benefit to the Internet community if they continue to be secret to some (RAB, NSI, USG, ICANN) while the RRP that they comment on intends to be published by the IETF -- without the comments! So, on a more humorous tone, this is not a RFC as a "Request For Comments" ... this is a "Requiem For Comments" ;-) Cheers, Ed Gerck
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
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. Given the somewhat obvious nature of the protocol's faults, I would think that the community would welcome it being published openly and permanently; that way they can always refer to in while improving it. > Having an AD that sat on the >RAB promote the I-D Sorry, but this is garbage. Nothing that Patrik said promotes the protocol. > and offer no reasoning as to why it >*should be* published as an Informational RFC He said that about three times; please re-read the past few messages with slightly clearer eyes. >I would request that the IESG let this draft expire and create a WG to >tackle the problem. It is not clear that the IETF is the proper place to tackle this problem. From the number of mistakes in the NSI RRP, I believe that a better way to create such a protocol is to start with a requirements document. A few folks have kicked around the idea of creating an IETF WG, but it became clear that the expertise to set down the *requirements* are more likely to be in the ICANN DNSO, not the IETF. That is, ask the registrars and registries, not a bunch of protocol-writers. After the requirements are settled, the IETF could probably help write the protocol. Having those directly involved in the field set down the requirements first will delay the shipment of the new protocol, but it is very likely to cause the outcome to be much better for all involved. This has been shown again and again (with both positive and negative examples) in the IETF. >The document exists as an I-D, >the cat is out of the bag, why should it be an RFC? To make it permanently and easily and freely accessible to the entire Internet community forever. There are many Informational RFCs that have been published for these reasons. --Paul Hoffman, Director --Internet Mail Consortium
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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-intutative but I am certainly >not "in the know" as to how these things work. It is a bit counter-intuitive until you look at the alternative. There isn't a good, central, free, open repository for these things other than RFCs. This isn't to say that every protocol should go there. I would say that only "important" (either due to politics or the number of implementations using the protocol) protocols should qualify. --Paul Hoffman, Director --Internet Mail Consortium
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
> 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 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
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
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
[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
--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
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 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
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 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
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
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
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: >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 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. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-hollenbeck-rrp-00.txt -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED]