FW: Changes to complete draft-cotton-rfc4020bis

["Adrian Farrel" <[e-mail]>]

Michelle writes...

> I have just submitted a new version of draft-cotton-rfc4020bis.
> 
> The below changes were made and now appear in version 02.
> (see all instances of "MC" for my comments)
> 
> Robert Sparks
> General Area Review Team review
> 
>> Issue : Section 2 is very confusing. It starts out listing 4 things that
>> look like they all have to be met. But then the last sentence confuses
>> things.
>> Is just reinforcing that both a and b have to be met (if so, then
>> wouldn't things also stop if c and d weren't met? (see 3.1 step2)).
>> I suggest replacing "If conditions (a) or (b)" with "If any of the above
>> conditions"
> 
> MC: 
> Deleted the whole paragraph. 
> The text at the top of the section already completely covers this.
> 
>> Nit 1: Section 3.1 reads harshly at the transition from step 4 to
>> step 5. It leaves it implicit that the AD has to approve.
>> Step 3 has  "if steps 2 and 3 are satisfied". 4020 said "with the
>> approval of the Area Director(s)". Adding that text  to step 5 
>> would address the nit.
> 
> MC: 
> OLD
>    5.  The WG chairs request IANA to make an early allocation.
> NEW
>    5.  If the Area Directors approve step 4., the WG chairs request IANA to
>     make an early allocation.
> END
> 
>> Nit 2: The introduction contains a bit of text that it carried 
>> forward, slightly modified, from 4020 for which I suggest
>> further modification:
>> replace
>> "the IETF community wishes to retain tight control of the protocol"
>> with
>> "the IETF community has consensus to retain tight control of the
>> registry content"
> 
> MC: DONE
> 
>> Nit 3: Several reviewers have pointed to a lack of clarity in section
>> 2 a.
>> I suggest taking the change John Klensin proposed (with tweaks as
>> below)
>> 
>> 	The code points must normally be from a space designated
>> 	as "RFC Required", "IETF Review", or "Standards Action".
>> 	In addition, code points from a "Specification
>> 	Required" space are allowed if the specification will be
>> 	published as an RFC.
> 
> MC: 
> OLD
>    a.  The code points must be from a space designated as "Specification
>        Required" (where an RFC will be used as the stable reference),
>        "RFC Required", "IETF Review", or "Standards Action".
> NEW
>    a.  The code points must be from a space designated as  "RFC
>         Required", "IETF Review", or "Standards Action". Additionally
>         code points from a "Specification Required" space are
>         allowed if the specification will be published as an RFC.
> END
> 
> 
> ---
> 
> Tom Petch (et al.)
> 
>> Clarification of "deprecation".
>
> MC:
> 
> Section 3.2
> No change needed: it already points at 3.3 for a definition.
> 
> Section 3.3, replacement text
>
>    As described in Section 3.1, each Temporary assignment is recorded in
>    the registry with the date of expiry of the assignment. If an early
>    allocation expires before the document progresses to the point where
>    IANA normally makes allocations, the authors and WG chairs may repeat
>    the process in section 3.1 to request renewal of the code points.  At
>    most, one renewal request may be made; thus, authors should choose
>    carefully when the original request is to be made.
> 
>    As an exception to the above rule, under rare circumstances, more
>    than one allocation renewal may be justified.  All such further
>    renewal requests must be reviewed by the IESG.  The renewal request
>    to the IESG must include the reasons why such further renewal is
>    necessary, and the WG's plans regarding the specification.
> 
>    If a follow-up request is not made, or the document fails to progress
>    to an RFC, the assignment will remain visible in the registry but the
>    temporary assignment will be shown to have expired as indicated by
>    the expiry date.  The WG chairs are responsible for informing IANA
>    that the expired assignments are not required and that the code
>    points are to be marked "deprecated".
> 
>    A deprecated code point is not marked as allocated for use as
>    described in any document (that is, it is not allocated), and is not
>    available for allocation in a future document.
> 
>    The WG chairs may inform IANA that a deprecated code point can be
>    completely de-allocated (i.e., made available for new allocations) at
>    any time after it has been deprecated. Factors influencing this
>    decision will include whether there may be implementations using the
>    previous temporary allocation, and the availability of other
>    unallocated code points in the registry.
> 
>    Implementers and deployers need to be aware that this deprecation and
>    de-allocation could take place at any time after expiry, and an
>    expired early allocation is therefore best considered as deprecated.
> 
>    It is not IANA's responsibility to track the status of allocations,
>    their expiration, or when they may be re-allocated.
> 
>    Note that if a document is submitted for review to the IESG and at
>    the time of submission some early allocations are valid (not
>    expired), these allocations must not be consider to have expired
>    while the document is under IESG consideration or waiting in the RFC
>    Editor's queue after approval by the IESG.
> 
> 
> ---
> 
> Eric Rosen
> 
> MC: see continued discussion on mailing list.
>
> Section 2
> OLD
>    d.  There is sufficient interest in early (pre-RFC) implementation
>        and deployment in the community as judged by working group chairs
>        or ADs.
> NEW
>    d.  The working group chairs and ADs judge that there is sufficient
>        interest in the community for early (pre-RFC) implementation and
>        deployment, or that failure to make an early allocation might
>        lead to contention for the code point in the field.
> END
> 
> Section 3.1
> OLD
>    Note that Internet-Drafts should not include a specific value of a
>    code point until this value has been formally allocated by IANA.
> NEW
>    Note that Internet-Drafts should not include a specific value of a
>    code point until IANA has completed the early allocation for this
>    value.
> END
> 
> 
> ---
> 
> Loa Andersson
> Routing Directorate review
> 
> MC: The whole point is that all registries that comply with 2a support
> early allocation.
>
> Section 4
> NEW
>    This document removes the need for registries to be marked as
>    specifically allowing early allocation. IANA is requested to clean up
>    the registries by removing any such markings.
> END
> 
> 
> With the conversion of the registries to XML as the source, it is our
> intention to have a script run to alert us of expired temporary
> allocations.  We are not quite there yet, so I don't want to document
> that the assignments will be removed automatically by IANA.  What
> we do want to do is when IANA finds an assignment that has expired,
> we will contact the assignee to find out if it should be removed or if 
> the document is close to publication so that the date can be extended
> with AD/WG Chair approval.
> 
> He also struggled a bit with terminology. "
" I don't struggle (but I also don't speak Swedish). Perhaps 5026bis
> could
> sort out these terms and include them in a glossary?
> 
> 5226bis will be enhanced to include clarification of the terms "registry", 
> "name space", and "code point space."
> 
> 
> ---
> 
> Adrian Farrel
> 
> MC:
>
> Section 3.1
> OLD
>    6.  IANA makes an allocation from the appropriate registry, marking
>        it as "Temporary", valid for a period of one year from the date
>        of allocation.  The date of first allocation the date of expiry
>        should also be recorded in the registry and made visible to the
>        public.
> NEW
>    6.  IANA makes an allocation from the appropriate registry, marking
>        it as "Temporary", valid for a period of one year from the date
>        of allocation.  The date of first allocation and the date of expiry
>        are also be recorded in the registry and made visible to the
>        public.
> END
> 
> Section 3.2
> OLD
>     Allocation is then just a matter of removing the
>    "temporary" tag from the allocation description.
> NEW
>     Allocation is then just a matter of removing the
>    "Temporary" tag from the allocation description.
> END