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: Back to the drawing board,was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 toInformational
John Klensin wrote, in part: In summary, I believe that our advice to the IESG should be "make certain this document is clear about what it is and what it proports to be, and that the authors (or author organization) take responsibility for that being true. Make certain that, should a RRP WG effort be launched, this document doesn't unreasonaby constrain it. If areas are identified in which the document isn't clear about what it calls for, get those fixed. Consider attaching a disclaimer that indicates the list of unresolved issues contains some fairly serious problems and that there may be equally serious issues not on that list. Then, since it is relevant and not obviously stupid, go ahead and publish the thing." I am in complete agreement with John on all of this. However, I would like to add a couple of additional points: (1) While it is true that publication as informational is sometimes misinterpreted as an endorsement, this is also something that is discussed a lot more than it actually happens. The RFC series contains many hundreds of documents describing protocols of dubious value and which don't receive a second glance by anybody, in some cases in spite of considerable marketing muscle being used to promote them. It isn't entirely clear why the publication == endorsement error happens in some cases, but it often involves some combination of people with no IETF standards experience, poor document labelling, a lack of a visible standards-track alternative or visible work underway on a standards-track alternative. In the present situation the first of these factors shouldn't apply and the second and third are things we control, so we should be able to minimize the risk of something bad happening. (2) The publication of protocol specifications in order to document the history of Internet protocol evolution is actually pretty important when you're actually doing protocol development work. I find it incredibly useful, for example, to refer to RFC 733, RFC 788, RFC 1049, RFC 1154, FIPS PUB 98, and many other documents when tring to figure out why Internet mail has ended up where it has and what makes sense for the future. (3) An alternative to putting a lot of comments about unresolved issues in given protocol document is to write a separate document critiquing the first and publish it as well. This approach used to be use quite a bit in the RFC series but has fallen into disuse in more recent times (probably because things move so fast these days). Perhaps this is an instance where the practice ought to be revived. Ned
Re: merde! blush Patrick F. and ICANN board error
Normally I ignore Cook, and am grateful to have missed the original screed. Technical contributions on the content of the draft-hollenbeck-rrp-00.txt are nice, but deviations from content analysis are awkward. Eric
Re: oh merde! blush Patrick F. and ICANN board error
At 09:38 PM 1/4/00 -0500, Gordon Cook wrote: I carry a lot of ICANN data around in my head and I am generally pretty good at it. However my attention has been called to the fact that I screwed up on my association with Patrick as an ICANN board member. Following a few URL trails I see that he and Goeff Huston were IETF nominees but that ETSI and W3C placed their folk on the board and IETF would up with only Vint. For the record, there is a PSO in the middle of that. IETF, ETSI, ITU, and W3C (the members of the PSO) each nominated various and sundry for the three board seats alloted to the PSO, and nominees from ETSI, W3C, and IETF were selected. ITU was, er, displeased. Wiping red face. For all you talk about ICANN, if the PSO involvement escaped you, your face deserves to be red. I am well aware of the PSO and that aspect did not escape me.what did escape me (in part i suppose because I was in nepal from oct 13 to nov 6 and totally off net from roughly the 18th of oct to november 3 (trekking near everest)) was that nomination by IETF of Cerf, Falstrom and Huston was not tantamount to election. please see http://cookreport.com/neptibalb.shtml for short photo essay and satire (the masked dancing of the monks at the tengboche monastery reminded me of ICANN). The COOK Report on InternetIndex to seven years of the COOK Report 431 Greenway Ave, Ewing, NJ 08618 USA http://cookreport.com (609) 882-2572 (phone fax)Is ICANN an IBM e-business ? [EMAIL PROTECTED] See also Lessig's Code: and Other Laws of Cyberspace http://cookreport.com/lessigbook.shtml
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]
jurisprudence
Title: Vous constatez régulièrement Vous constatez régulièrement : qu'il est difficile de disposer de temps pour réunir la documentation nécessaire à la constitution de vos dossiers ou simplement y accéder. que l'acquisition et le maintien d'un fonds documentaire exhaustif et actualisé représente un investissement important que ces deux contraintes nuisent au développement de votre activité Accessible par Internet, fax ou courrier, ADIéS se propose de prendre en charge vos recherches documentaires de tout ordre dans des délais rapides, AVEC OU SANS ABONNEMENT, et vous permet ainsi libérer du temps pour vous consacrer à l'essentiel de votre métier ou à de nouveaux dossiers. ADIéS s'adresse à tous les secteurs d'activité, dispose notamment d'un fonds documentaire actualisé quotidiennement et constitué de 1,2 million de références juridiques et législatives (jurisprudence, lois, décrets, directives européennes...) et fournit également un service de veille thématique personnalisé. Agence de Documentation et d'Intelligence Économique du Sud Technopole HELIOPARC-Bâtiment Einstein 2, av. du Pdt.-P.Angot 64000 PAU Tel : 05 59 14 71 11 Fax : 05 59 14 71 14 Website : http://www.vmgnet.com/adies e-mail:[EMAIL PROTECTED]
