Quoting Masataka Ohta on Friday November 12, 2021:
>
> > The operational decisions relating to these things have already been
> > made, as I understand it -- the delegations no longer exist. Kim and
> > Amanda's document seems to have two purposes: (1) to document this
> > operational reality, and (2) to update protocol specifications to
> > reflect that operational reality.
>
> I'm afraid (1) should be documented by a separate rfc maybe titled
> as "Relationship between IETF and IANA", which should clarify
> semantics of "IANA considerations" section of not only this but
> also other rfcs, which was not a problem when both of the rfc
> editor and IANA was the same person.
>
> Is the "IANA considerations" section just a recommendation from
> IETF/ISOC to IANA/ICANN or approved by IANA/ICANN during *modified*
> standardization process of IETF?
These are fair points and hopefully the language can be tweaked to make
it a little clearer. (RFC 2860 does define the relationship between IETF
and IANA, but the role of .INT was modified as a consequence of RFC
3172)
Most of the names in the draft were in the zone when we started the
inventory process a couple of years ago. For those that were lame
for over a year we removed them from the zone because they were
already functionally inoperable. For the remaining two that are in
there, there doesn't appear to be any sign that they are currently
configured to operate as documented. Specifically, {1..9}.tpc.int and
{0..9,a..f}.nsap.int all return NXDOMAIN.
Even if we are perhaps duly empowered to make such an operational
decision regarding these delegations, producing this draft and gaining
additional consensus on these actions I think will produce a better
result given the original delegations eminated from IETF work.
kim
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
