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

[Loa Andersson <[e-mail]>]

All,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-cotton-rfc4020bis-01.txt
  Reviewer: Loa Andersson
  Review Date: 2013-08-31
  IETF LC End  2013-09-24
  Intended Status: Best Current Practice

Summary:
I have one major and some minor concerns about this document that I 
think should be resolved before publication.


Comments:

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.

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

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.

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

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.


Nits:

-

/Loa


-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]