Well, i thought that .int was to be passed to some internet registry, which would
have made it probably more ICANN business as to what to do with it, but even then i am
not sure if we should not / could not seed it appropriately.
But one response i saw was that it would be kepy at IANA, which AFAIK would make the
seeding even more an (immutable without RFC) job of the IETF. Right ?
IMHO: Whether or not to allow reuse of such historic special domain names IMHO should certainly
a conscious choice on our side.
Cheers
Toerless
On Thu, Oct 20, 2022 at 11:56:41AM +1300, Brian E Carpenter wrote:
> Toerless,
>
> Most of your comments are not IETF business; the whole point of this long
> overdue action is to remove any remaining bit of IETF business from .int,
> so that we can forget about it and leave all the metaphysics to ICANN.
>
> I fully support both this draft and the accompanying deprecation of
> RFC1706 and RFC1528. Time to move on.
>
> Regards
> Brian Carpenter
>
> On 20-Oct-22 11:33, Toerless Eckert wrote:
> > a) Why does the draft say
> >
> > "intergovernmental organizations, which are organizations established by
> > international treaties between or among national governments
> > when rfc1591 says:
> > "organizations established by international treaties, (or international databases)"
> > This seems to be an intentional different/refined wording. Why ?
> >
> > For example there are laws for treaties between international organiations,
> > aka: another layer of indirection, which in my reading would be covered by
> > rfc1591 but not the draft wording.
> >
> > b) If we are going to want to refine the future use of .int (because
> > we want to be crisp about the purpose before passing it on to some operating
> > registry):
> >
> > Would https://en.wikipedia.org/wiki/Commonwealth_of_Nations be able to
> > get a .int domain ? The way i read wikipedia, there is no treaty involved,
> > but it is an association and formalized through a declaration
> > and later a statue. Or does this rightfully not deserve a .int domain
> > because it does not have the right (treaty) paperwork (and the DNS has the wrong
> > order for the brits anyhow ;-) ?
> >
> > Aka: if we have the freedom to make .int more useful maybe rethink / broaden
> > it permitted use with cases like this considered.
> >
> > IMHO: as broad as possible in the original spirit while still effectively prohibiting FCFS land grabs.
> >
> > Maybe something like international organizations established by national governments or their international organizations.
> >
> > c) "The documented uses of infrastructural identifiers in the "int"
> > domain were largely experimental and in practice obsolete."
> >
> > ... and are now in practice ...
> >
> > d) I suggest to replace the security considerations of
> >
> > "The operator of the "int" domain should be cautious about any potential
> > re-use of these domains for intergovernmental treaty organizations"
> >
> > with explicit text earlier, that these domain names must never be re-used
> > and maybe even instructions how to populate them with some appropriate NULL RR
> > (not sure what the best RR would be).
> >
> > Halloween horror story of the day: ITU gets ipv4.int and ipv6.int and uses it
> > for a new international database how to filter Internet traffic. Just saying.
> > Look up the EU presidents history of Internet filtering proposals...
> >
> > Note: It would be nice if ITU gets tpc.int and populates it with
> > the some official E164 database, but neither does ITU have this type of humor,
> > nor does domain availability change the business model that makes DNS
> > not desired for E164 space... unfortunately... i think).
> >
> > Cheers
> > Toerless
> >
> >
> > On Wed, Oct 19, 2022 at 05:34:40PM -0400, Michael Richardson wrote:
> > >
> > > The IESG <iesg-secretary@xxxxxxxx> wrote:
> > > > The IESG plans to make a decision in the next few weeks, and solicits
> > > > final comments on this action. Please send substantive comments to the
> > > > last-call@xxxxxxxx mailing lists by 2022-11-23. Exceptionally, comments
> > > > may be sent to iesg@xxxxxxxx instead. In either case, please retain the
> > > > beginning of the Subject line to allow automated sorting.
> > >
> > > > Abstract
> > >
> > >
> > > > The document marks as historic any "int" domain names that were
> > > > designated for infrastructure purposes, and identifies them for removal
> > > > from the "int" top-level domain. Any implementation that involves
> > > > these domains should be considered deprecated. This document also
> > > > marks RFC 1528 and RFC 1706 as historic.
> > >
> > > So, I understand that none of our infrastructure has been in .int for some
> > > years (decades even).
> > >
> > > The document says:
> > > In conjunction with this change, the eligibility for "int" domains was
> > > limited to only intergovernmental treaty organizations.
> > >
> > > I think that, after approval, that this use for int will remain, and the
> > > management of it will fall to, I guess, ICANN, as yet another TLD?
> > >
> > > At first reading, it seemed like we were removing int entirely, but upon more
> > > careful reading, I see that we are just removing our infrastructure
> > > delegations.
> > >
> >
> > > --
> > > ] Never tell me the odds! | ipv6 mesh networks [
> > > ] Michael Richardson, Sandelman Software Works | network architect [
> > > ] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
> > >
> > >
> > >
> >
> >
> >
> >
> > > --
> > > last-call mailing list
> > > last-call@xxxxxxxx
> > > https://www.ietf.org/mailman/listinfo/last-call
> >
> >
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
--
---
tte@xxxxxxxxx
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
