Re: [RTG-DIR] rtg-dir review of draft-cotton-rfc4020bis-01.txt

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

Hi Loa,

Thanks for doing the review.

> The document is very well written and clear. There is one thing I've
> thought about marking registries as open for early allocation. Some
> registries, e.g.:
> 
> BGP Error Subcodes RFC 4271
> Standards Action (Early Allocation available per RFC 4020)
> 
> Are marked that they are available that they are open for early
> allocation.
> 
> While others - that I understand is also open for early allocation e.g.:
> 
> MPLS Fault OAM Flag Registry RFC 6427
> Standards Action
> 
> are not.
> 
> I wonder if we wonder if we should request that IANA mark all
> registries (or part of the registries) that are open for early
> allocation the same way.

In fact, one of the changes (not highlighted) resulting from this document is that registries do not need to be specially marked. Thus any registry that satisfies 2a can support early allocation.

So the result of the point you make is that IANA should clean up and remove the flag from those registries that carry it.  Thus, a new paragraph in Section 4

   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.

> Major Issues:
> 
> Section 3.2 "Expiry"
> 
> I've recently shepherded a document for which the temporary allocation
> were made 2007 and was supposed expire 20078; however the allocations
> are still there. And no harm done. Existing practice is that the early
> allocation stays until permanently allocated or until the working group
> chairs to delete them. I think it would be better to document the
> existing practice.
> 
> I think it would be enough if the expiry section says:
> 
> "Once an temporary assignment is made it stays in the registry until
> the document for which they were made becomes an RFC, or until they
> are removed by working group chairs or the ADs.
> 
> IANA may request from working groups chairs if an early allocation
> should remain in the registry or not."

There are two things you are saying here.
1. The "temporary entry" should remain in the registry until explicitly removed. In fact, this is exactly what happens if the process described in the document is followed: the entry remains, but its date shows it has expired. Someone worried about the status could contact the chairs who would say "ooops I should have renewed that."
2. IANA should poke the chairs: the chairs should not have to track this. I can see the value in that, and we can discuss it further with IANA, but I suspect it would require IANA to run a tracking tool and it is outside the current scope of work for IANA. Maybe next time the IANA contract is reviewed we could suggest that change.

> Minor Issues:
> 
> There has been some comments on the IETF mailing list;
> 
> SM stumbled over the same words in section 2 as I did '"Specification
> Required" (where an RFC will be used as the stable reference)'
> I support Barry Leiba's resolution of that comment.

Yup we have been polishing this.

> Eric Rosen has also commented on the draft; however I believe that the
> draft the right approach as it is today.

You'll see a loooong response from me to Eric. I suspect you could have a great discussion with him about SDOs and codepoint squatting.

> Section 1 - line 3-4:
> "Many of these code point spaces  have registries..."
> Comment: I find it hard to follow the nomenclature sometimes,
> registry - name space - code point space. What are the relationships
> and differences.

I've asked Michelle to include a terminology section in 5226bis which is currently open on her desk.

Many thanks,
Adrian