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

[Loa Andersson <[e-mail]>]

Adrian,

hello again :) !

On 2013-09-30 03:54, Adrian Farrel wrote:
> Hi again Loa,
>
>>>> 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.
>
> 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.
>
Well - I guess I have to explain to implementers that the code has not
gone away just because we are past the expiry date.
> [snip]
>
>>> 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 they do it.
>
> Oh, I see. Well, yes. There is no restriction on IANA sending emails to people.
Understood.
>
>>   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.
>
> OK. Well you can raise it as a nice-to-have feature for the tools team to put
> into the tracker.
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
>
> A
>

-- 


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