> > > John Levine wrote: > >> The problem isn't just "inability to use" -- it's that other parties > >> exist who may claim the usage right, and provide citations to RFCs to > >> back up their claim. > > > > There are several ICANN documents describing the new process that > > include a set of recommendations to guide the process. You must have > > read them, since you are concerned about this proposal. Do you think > > that recommendations 3, 4, and 20 are adequate to address this > > problem? If not, why not? > > > John, et al, > > While I think it entirely appropriate to check whether any of us has a clue > about what ICANN is actually doing, I do suggest that reference to a document > > warrants providing a specific citation, particularly when there are so many > possible choices at the ICANN cite. > > I'm guessing you mean: > > <http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm#_Toc43 > 798015> > > and specifically the Recommendations table. > > If so... > > No. 3 is about legal infringement. That seems wholly irrelevant to the scope > of > IETF work, although I agree that the ietf list thread has started using langu > age > that sounds related. > > No. 4 says "Strings must not cause any technical instability." which sounds > exactly within IETF scope covers the gist of the technical aspects of the iet > f > list discussion. We need "cannot be used in a manner that causes technical instablitity. Known causes include, but are not limited to, adding A, AAAA and MX records at the zone apex." > No. 20 seems to have to do with failing a popularity contest. Probably a goo > d > escape clause to include, but not all that relevant to our I discussion... I > hope. > > Let me stress that I do think language like "claim the usage right" makes No. > 3 > sound appropriate, but that the scope of IETF RFCs is technical specification > s, > rather than "rights". While yes, one can say that reserving a name or > proscribing against the use of a name -- such as a single, top-level label as > a > standalone name -- can be interpreting as declaring a "right", I suggest that > an > IETF discussion will fare much better by focusing on the technical issues tha > t > lead to the constraints, rather than attempting a quasi-pseudo-meta-legal > discussion. > > Simply put: If an IETF specification has gone through the IETF consensus > process and been approved, the requirements and constraints imposed are almos > t > by definition technical requirements. > > Violating one of them invites instability, if only because it invites variabl > e > implementations. At the least, treating such constraints as subject to creat > ive > interpretation by another body renders all output of the IETF fluid. > > And just to press this to a logical conclusion, albeit not one that seems to > be > at issue... yet: If ICANN believes that the IETF has issued a problematic > specification, then ICANN needs to ask the IETF to fix it, rather than to hav > e > ICANN, or anyone else, issue a modification/clarification. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf