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(_at_)ietf(_dot_)org
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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf