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

[Loa Andersson <[e-mail]>]

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

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

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

-- 


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