Subject: Re: [Ltru] Issue #43: AD #10 - section 5.1 vs 3.2 on File-Date value

From: "Doug Ewell" <[email-masked]>
Date: Sun, 7 Jun 2009 15:13:57 -0600

Can someone give an example scenario with example dates, to help me 
understand what the problem is?

Remember that:

1.  It isn't expected to be possible to tell, just by looking at a given 
version of the Registry, whether IANA has processed all of the changes 
submitted to them.

2.  Modifications to existing records do not cause an update to the 
Added date, so the passage in 5.1 about a new File-Date record having "a 
later date than the record being inserted or modified" often does apply.

3.  As stated previously, Michael and I usually batch the requests 
together before submitting them to IANA, even if they were originally 
submitted a few days apart or their review periods ended on different 
days for some reason.  It would be very unusual for us to send IANA a 
few requests on Monday, a few more on Tuesday, and so on.

4.  IANA usually tends to ignore the File-Date records attached to the 
replacement records anyway, and instead applies the date on which they 
process the changes and release the new Registry.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: Kent Karlsson <[email-masked]>
Date: Sun, 07 Jun 2009 23:27:10 +0200

> process the changes and release the new Registry.

I don't think there is any actual problem in current practice, just that the
formal handling is not calling for this actual handling and leaves a hole
open for the possible problem of not being formally "guaranteed" to be able
to use the file-date alone to determine if a local copy is up-to-date or
not. Plugging that hole seem to not change actual current practice, just to
reinforce it.

    /kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 7 Jun 2009 15:41:18 -0600

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

> I don't think there is any actual problem in current practice, just 
> that the formal handling is not calling for this actual handling and 
> leaves a hole open for the possible problem of not being formally 
> "guaranteed" to be able to use the file-date alone to determine if a 
> local copy is up-to-date or not. Plugging that hole seem to not change 
> actual current practice, just to reinforce it.

You should always be able to use the File-Date to determine whether a 
local copy is up to date.  A later revision of the Registry will always 
have an later File-Date than an earlier version, unless (a) somebody 
makes a mistake or (b) IANA generates two revisions in a single day. 
Both (a) and (b) are possible, but about equally unlikely.

I'm glad our efforts to work out the big problems have been so 
successful that we have to resort to hypothetical cases like this to 
find flaws in the process.