Thanks! Dan - got it?
Done. -- - Eric On Oct 31, 2011, at 11:36 AM, Miguel A. Garcia wrote: > Hi Eric: > > I think I understand your motivation, and I believe you now understand that > the IANA registry does not warrant any further interoperability. I think you > have convinced me that the registry may encourage developers to publish their > specifications, something that, otherwise, it won't happen. > > As long as you understand that there is no warranty for success, I have no > problem. Please proceed with the IANA registry. Make sure that the registry > itself contains a contact person and a pointer to the published specification. > > BR, > > Miguel > > > > On 31/10/2011 16:24, Eric Burger wrote: >> This is an area where I think we are violently agreeing. >> >> We do not require a specification. That meets FCFS requirements. To >> make a no-registration-required policy work, we need a self-organizing >> mechanism that avoids conflicts. Reverse DNS names seems to fit this >> bill. >> >> While we do not require a specification, we do ENCOURAGE publications >> of specifications. To make that sensible, and to have a place to refer >> to published specifications, we are establishing a registry. >> >> IANA has gotten really good at establishing registries. It no longer >> takes months or years for them to set one up. Moreover, this is the >> lowest-involvement kind of registry for them to run, so it is low >> impact on their operations. [These are two important items for me to >> consider with my IAOC hat on.] >> >> If we are getting into a dogmatic or religious discussion, we are more >> than willing to give up on asking for a registry that might improve >> long-term interoperability for the short term goal of getting MRCPv2 >> published. Even the ITU-T is waiting for this document to become an >> RFC. >> >> Thanks. >> >> On Oct 31, 2011, at 10:46 AM, Miguel A. Garcia wrote: >> >>> Hi Eric: >>> >>> Although this is a laudable effort, you won't get the expected >>> results. >>> >>> First, because the registry does not require a specification. The >>> policy (last thing we heard) is First Come First Served, and does >>> not require a specification. >>> >>> Second, a publicly available specification is something that >>> companies won't do if they don't want to disclose their own >>> extensions. Instead, they will simply create extensions identified >>> by their DNS names, and they won't need the IANA registration. >>> >>> So, I am even more confused than before. If you want to push >>> companies to public their specifications, they are not going to do >>> it because you say it in a standards document. IANA won't help you. >>> >>> /Miguel >>> >>> On 31/10/2011 14:46, Eric Burger wrote: >>>> Miguel - One thing I would like to be clear on. We do want a >>>> registry to encourage interoperability. By saying "use reverse DNS >>>> names" I do not mean "don't have a registry." Using reverse DNS >>>> names is a sufficient mechanism for avoiding naming collisions in >>>> the header space. However, avoiding collisions does not mean we >>>> foster interoperability. >>>> >>>> The reason we want a registry is we want to encourage developers >>>> of proprietary extension to document them. By having some >>>> documentation out there, the hope is people will learn from each >>>> other and hopefully, if something sticks, we can later do some >>>> standards track work. >>>> >>>> We did not mandate registration of an extension to use it. There >>>> is no protocol police, so there is no point mandating something >>>> that one cannot test. Using reverse DNS name space does give us a >>>> high probability of non-collisiion. >>>> >>>> Likewise, we did not say, "Developers MAY register proprietary >>>> headers." That gives people the easy out, and then we get no >>>> documentation benefits of the registry. >>>> >>>> One thing I would offer to additionally lower the bar on >>>> registration with the goal of improving registrations is to drop >>>> the requirement that the documentation for the header be published >>>> as an RFC. However, I would leave that determination up to the >>>> IESG. >>>> >>>> Does this work for you? -- - Eric >>>> >>>> >>>> On Oct 31, 2011, at 8:18 AM, Eric Burger wrote: >>>> >>>>> Now I get it. >>>>> >>>>> Let me put it this way: we can create a protocol parameters >>>>> space and ask IANA to create a registry full of opaque strings >>>>> that happen to look like DNS names. Collisions are avoided >>>>> because IANA manages these opaque strings that look like DNS >>>>> names. Or, we can use DNS names and ask IANA to do their day job >>>>> of ensuring that DNS names are unique, which they are. >>>>> >>>>> Therefore, simply saying MRCPv2 will use reverse DNS names is >>>>> sufficient to ensure a unique vendor name space. If there is a >>>>> collision, we can let ICANN run the full domain name dispute >>>>> resolution process. No need to get the IESG or an IETF expert >>>>> involved. >>>>> >>>>> I vote to simply use reverse DNS names. >>>>> >>>>> On Oct 31, 2011, at 7:44 AM, Dan Burnett wrote: >>>>> >>>>>> Since we are down to only this one comment we can just >>>>>> top-reply :) >>>>>> >>>>>> The reason we are using this syntactic structure is because >>>>>> that is what implementers of MRCPv1 are already used to. It >>>>>> is a convenient way to distinguish among different vendors' >>>>>> parameters. >>>>>> >>>>>> However, the registry is to ensure there are no conflicts. >>>>>> Merely recommending that vendors use a particular syntax does >>>>>> not ensure that they will do so. A (public) registry does, at >>>>>> least insofar as making it public when they violate the >>>>>> recommendation. >>>>>> >>>>>> -- dan >>>>>> >>>>>> >>>>>> On Oct 31, 2011, at 4:54 AM, Miguel A. Garcia wrote: >>>>>> >>>>>>> Hi Dan. >>>>>>> >>>>>>> First, I believe I agree with all your previous comments. >>>>>>> Thanks for addressing it. >>>>>>> >>>>>>> Now, back to this comment related to the IANA registration. >>>>>>> See below. >>>>>>> >>>>>>> On 31/10/2011 2:20, Dan Burnett wrote: >>>>>>>> I have removed all but one of your comments below. This >>>>>>>> comment had not yet been addressed. With this reply I >>>>>>>> believe I have addressed all of your comments. If you >>>>>>>> find that I have missed one please let me know. >>>>>>>> >>>>>>>> -- dan >>>>>>>> >>>>>>>> On May 3, 2011, at 2:39 AM, Miguel A. Garcia wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> - Section 13.1.6 describes a mechanism where >>>>>>>>> vendor-specific extensions use the reverse DNS >>>>>>>>> mechanism, for example., "com.example.foo". Then, if >>>>>>>>> the vendor-specific extension is connected to DNS to >>>>>>>>> avoid clashes in names, why is there a need for an >>>>>>>>> expert review policy prior to its registration? I see a >>>>>>>>> contradiction in having a self-managing registry by >>>>>>>>> avoiding clashes due to the connection to DNS, and then >>>>>>>>> having anything else than a volunteer registry. >>>>>>>>> >>>>>>>> >>>>>>>> In the next draft I will replace "Expert Review" with >>>>>>>> "First Come First Served". >>>>>>> >>>>>>> This does not solve my concern. My concerns is why do you >>>>>>> need at the same time: >>>>>>> >>>>>>> a) a self-managed registry, by linking reversed DNS names >>>>>>> to features >>>>>>> >>>>>>> b) an IANA-controlled registry. >>>>>>> >>>>>>> There is a redundancy here. The goal of both is to avoid >>>>>>> clashes of different features with the same name. If you >>>>>>> need an IANA registry, then features do not need to be >>>>>>> linked with their DNS names. If you need a reversed DNS >>>>>>> names for the features, then their names are self-managed >>>>>>> and need not be maintained by IANA. >>>>>>> >>>>>>> So, I still do not understand what you are trying to >>>>>>> achieve. >>>>>>> >>>>>>> BR, >>>>>>> >>>>>>> Miguel >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain >>>>>> >>>>> >>>> >>> >>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain >> > > -- > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
