It is sufficiently clear that the antecedents are found in the
preceding paragraph and that this text is directed toward “The
maintaining authority of the extension”. The wording “appeal”
vs. “petition” may have room for improvement but is certainly good
enough.
IMO, no text in this section needs to be changed. This is purely
editorial, and IMO the issue should be resolved by the editors at their discretion.
Peter
From:
ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of CE
Whitehead
Sent: Wednesday, May 27, 2009 9:37 AM
To: ltru at ietf.org
Cc: alexey.melnikov at isode.com
Subject: Re: [Ltru] Issue #54: section 3.7 requirements on maintainers
of additional registries (Apps #7)
Hi,
I agree that it is not clear to whom the text in 3.7 (paragraph 5) refers;
it gave me a few problems on the first few reads (because it is IANA who is
maintaining the registry of allocated single-character subtags that is
mentioned right above this paragraph while the maintaining authority who
requests registration of a single-character subtag develops/maintains an
rfc/specification stating what is canonical, etc., but I realized from previous
text that it must be the maintaining authority!
Nevertheless, a revision stating this explicitly would be nice:
>>
> Failure on the part of the registering authority to
maintain the rfc described above,
{COMMENT: and what about
the record-jar format registry listing all single-character subtags allocated that
is maintained by IANA, right???}
>>
> or failure to 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.
I still don't like the passive "may be appealed to . . . "
I'm thinking that in this case "petition" is the word; someone
petitions the IESG when someone fails to do this; I'm not sure why it's called
an appeal; thus:
>>
> If the registering authority fails to maintain the rfc
described above,
{COMMENT: and what about
the record-jar format registry listing all single-character subtags allocated
that is maintained by IANA, right???}
>>
> or fails to meet other conditions imposed by this
section of this document, a petition MAY
>>
> be made 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.
(however I probably am not that informed; appeal may be the term you need
if it's what the IESG calls this petition) . . .
Best,
C. E. Whitehead
cewcathar at hotmail.com
From:
"Randy Presuhn" <randy_presuhn
at mindspring.com>
Date: Sun, 24 May 2009 15:33:50 -0700
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.
I think the comment could potentially be germane in the hypothetical case
where one of these "maintaining authorities" somehow ended up being
IANA itself.
Randy