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

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

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.

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

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

A