Re: Request for comments : IANA Policy for the Independent Stream

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

 



On Tue, Aug 13, 2019 at 12:12 PM Ned Freed <ned.freed@xxxxxxxxxxx> wrote:
>
> > On Tue, Aug 13, 2019 at 7:43 AM RFC ISE (Adrian Farrel)
> > <rfc-ise@xxxxxxxxxxxxxx> wrote:
> > >
> > > Hello IETF Community,
> > >
> > > Several people have recently asked me what the policy is for creating or
> > > modifying IANA registries using documents in the Independent Submissions
> > > Stream, and from time to time a document in the stream requests allocation
> > > of a code point from an existing registry.
> > >
> > > This document is an attempt to describe how I will act (as Independent
> > > Submissions Editor) when I am asked to publish such documents.
> > >
> > > I would very much appreciate comments and thoughts.
>
> > Thank you very much for writing this. I do have a question...
>
> > "RFC8126 - IANA Considerations Section in RFCs"
> > (https://tools.ietf.org/html/rfc8126) lists "IESG Approval" as one of
> > the possibilities for a registry.
> > Snippet:
> > "New assignments may be approved by the IESG.  Although there is no
> > requirement that the request be documented in an RFC, the IESG has the
> > discretion to request documents or other supporting materials on a
> > case-by-case basis.
> > IESG Approval is not intended to be used often or as a "common case";
> > indeed, it has seldom been used in practice." -- this then lists a few
> > cases, including RFC6275 and RFC5771.
> > RFC8126 goes on to say: "..., it is intended to be available in
> > conjunction with other policies as a fall-back mechanism in the case
> > where one of the other allowable approval mechanisms cannot be
> > employed in a timely fashion or for some other compelling reason."
>
> > Your draft specifically says that "a registry whose policy is "IETF
> > Review" or "Standards Action" [RFC8126] is not available to
> > Independent Stream documents.", but doesn't mention what happens with
> > "IESG Approval" registries. I would assume that these are also not
> > available to IS documents,
>
> That's not the case currently. One counterexample is standards tree media types
> in independent stream documents. RFC 6828 section 3.1 on standards tree
> registrations states:
>
>    Registrations published in non-IETF RFC streams are also allowed and
>    require IESG approval.  A registration can be either in a stand-alone
>    "registration only" RFC or incorporated into a more general
>    specification of some sort.
>

Yup, I fully agree that it doesn't need to be an IETF stream, but that
still says "require IESG approval" - this means that the ISE cannot
just approve assignment.
I guess I worded the above poorly -- it's not that "these are also not
available to IS documents", but rather that that the ISE would have to
work with the IESG / request that the IESG approve the registration
(the ISE cannot "guarantee" the assignment).
An interesting question for the IANA would be if they'd recognise
"IESG and / or ISE Approval" as type -- I cannot see why not...

> That said, I don't see anything in the document at hand that prevents
> this.
>
> > but in my view it would be entirely
> > appropriate for the ISE to be able to *request* that the IESG approve
> > allocation. In my *personal* view, a request from the ISE for
> > allocation under the IESG Approval procedure should be given extra
> > weight.
>
> > Whatever the case, I think that the document should cover the other
> > cases as well.
>
> Seems reasonable.
>
>                                 Ned



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux