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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
