[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] Issue #54: section 3.7 requirements on maintainers of additional registries (Apps #7)



On 2009/05/25 7:33, Randy Presuhn wrote:
Hi -

From: "Alexey Melnikov"<alexey.melnikov at isode.com>
To: "LTRU Working Group"<ltru at ietf.org>
Cc: "Martin J. Dürst"<duerst at it.aoyama.ac.jp>; "Randy Presuhn"<randy_presuhn at mindspring.com>
Sent: Sunday, May 24, 2009 5:23 AM
Subject: Additional issues with 4646bis raised by an Apps Review Team review
...
7). In Section 3.7:

    Failure to maintain this record, maintain the corresponding registry,
    or meet other conditions imposed by this section of this document MAY
    be appealed to the IESG [RFC2028] under the same rules as other IETF
    decisions (see [RFC2026]) and MAY result in the authority to maintain
    the extension being withdrawn or reassigned by the IESG.
It is not clear to whom this procedure applies. If it meant to apply to
IANA, then it seems to contradict IETF agreement with IANA as specified
in RFC 2860.
...

As a technical contributor:

This text pertains to a "maintaining authority" for a registry referenced from
the IANA-maintained "extensions registry".  The "this record" refers to
information maintained by that outside "maintaining authority" in the
previous paragraph.

[as a technical contributor]

I concur with Randy and others that it is clear enough that this is an outside maintaining agency.

I think the comment could potentially be germane in the hypothetical case
where one of these "maintaining authorities" somehow ended up being
IANA itself.

Very, very potentially, yes. But even then, if IANA weren't able to keep a record of it's own address, or otherwise keep a registry, the IETF would potentially have much bigger problems than a language tag extension. (there are quite a few registries that are in a bit of a mess, but when that's the case, it's a problem on the IETF side, not on the IANA side). In the highly unlikely case that an appeal against IANA would reach the IESG, I expect the IESG to be clever enough to work out how to apply (or NOT) the relevant provisions to IANA, and if that doesn't help, I expect Subsection 4.2 of RFC 2860 (http://tools.ietf.org/html/rfc2860#page-3) to kick in and solve the problem.



[co-chair hat on]

I conclude that there is consensus in the WG that no fix to this text is necessary.

Regards,   Martin.


--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.