>
>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
