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. "
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