Barry, Thanks, changes look good to me. Bob > On Feb 9, 2017, at 9:59 AM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: > > As a result of the discussion on the -19 version of the draft (where > "IANA" was replaced with "IANA Services" throughout, and related > changes were made), the IETF Trust agreed on the alternative of > putting a paragraph at the beginning (the second paragraph in the > Introduction in version -20), and then reverting most of the other > changes in -19. > > Version -20 now only has the paragraph that explains that we call > <this stuff> "IANA" in this document, plus a few minor changes that > came out in IESG Evaluation. > > We believe the document is now ready to publish, having been through > Last Call and IESG Evaluation, and ask Terry, as responsible AD, to > send this version off. > > Thanks, everyone, for the comments! > > Barry, document editor > > On Thu, Feb 9, 2017 at 9:52 AM, <internet-drafts@xxxxxxxx> wrote: >> >> A new version of I-D, draft-leiba-cotton-iana-5226bis-20.txt >> has been successfully submitted by Barry Leiba and posted to the >> IETF repository. >> >> Name: draft-leiba-cotton-iana-5226bis >> Revision: 20 >> Title: Guidelines for Writing an IANA Considerations Section in RFCs >> Document date: 2017-02-08 >> Group: Individual Submission >> Pages: 41 >> URL: https://www.ietf.org/internet-drafts/draft-leiba-cotton-iana-5226bis-20.txt >> Status: https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ >> Htmlized: https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-20 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-leiba-cotton-iana-5226bis-20 >> >> Abstract: >> Many protocols make use of points of extensibility that use constants >> to identify various protocol parameters. To ensure that the values >> used in these fields do not have conflicting uses, and to promote >> interoperability, their allocation is often coordinated by a central >> record keeper. For IETF protocols, that role is filled by the >> Internet Assigned Numbers Authority (IANA). >> >> To make assignments in a given registry prudently, guidance is needed >> for describing the conditions under which new values should be >> assigned, as well as when and how modifications to existing values >> can be made. This document defines a framework for the documentation >> of these guidelines by specification authors, in order to assure that >> the provided guidance for the IANA Considerations is clear and >> addresses the various issues that are likely in the operation of a >> registry. >> >> This is the third edition of this document; it obsoletes RFC 5226. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >
Attachment:
signature.asc
Description: Message signed with OpenPGP