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