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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 28 Sep 2013 23:44:16 +0100

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

---

From: Loa Andersson <[email-masked]>
Date: Sun, 29 Sep 2013 13:06:10 +0800

Adrian,

A comment on your comment on my comment on expiry inline. I fine with
the rest.
On 2013-09-29 06:44, Adrian Farrel wrote:
<snip>
> 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."

Well, yes but I think it would be better to have the date when the
entry was included in the registry. An old date would be an indication
to wg chairs that they need to push on the document authors to deliver.
If we indicate an expiry I know that this dives the wrong signal to
some implementers. There is a difference to see a statement that says
"Early allocation Nov 2007" from an entry that says "Expires Nov 2008".
I think I prefer the first.

Since we can't remove it if it been implemented
and deploy, there is no reason that 2nd generation should feel uncertain
about using code points that were "early" rather than "temporarily"
allocated.

> 2. IANA should poke the chairs: the chairs should not have to track
> this.

No that is not exactly what I say, what I say is that IANA is allowed to
poke the chairs if they find a reason to do it, but it is not required
that thay do it.

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

Well - we could put it in the data-tracker for the document; generates
a mail that tells the working group chairs that says "It now one year
since the following code points were "early" allocated". Do you want
them to remain in the registry. The working group chairs goes into the
and clicks and clicks on a button that says "refresh" or "remove".

Maybe next time the IANA contract is reviewed we could suggest that change.

That would work for me, but I think the tracking responsibility should
really be on the wg chairs, with IANA having the possibility to act
as triggers if they see the need.

/Loa
<snip>
/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 29 Sep 2013 20:54:47 +0100

Hi again Loa,

> entry was included in the registry.

The current draft says (section 3.1):

   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.

There is a punctuation typo here we are fixing, but the net is that both dates
will be recorded: the date of first allocation and the date of next expiry.

[snip]

> that they do it.

Oh, I see. Well, yes. There is no restriction on IANA sending emails to people.

>  I think the tracking responsibility should

OK. Well you can raise it as a nice-to-have feature for the tools team to put
into the tracker.

A

---

From: Loa Andersson <[email-masked]>
Date: Mon, 30 Sep 2013 11:23:18 +0800

Adrian,

hello again :) !

> will be recorded: the date of first allocation and the date of next expiry.
Well - I guess I have to explain to implementers that the code has not
gone away just because we are past the expiry date.
> Oh, I see. Well, yes. There is no restriction on IANA sending emails to people.
Understood.
> OK. Well you can raise it as a nice-to-have feature for the tools team to put
This was not about the tool for tracking - I still think that we should
say that the responsibility to track early allocations rests with the
wg chairs.

If we need tools for that, so be it.

/Loa

--