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

["Phillips, Addison" <addison at amazon.com>]

+1

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> Behalf Of "Martin J. Dürst"
> Sent: Friday, May 29, 2009 3:03 AM
> To: Randy Presuhn
> Cc: Alexey Melnikov; LTRU Working Group
> Subject: 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
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru