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

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Jun 2009 12:16:26 +0100

Section 3.1.2 in -22 says:

>    The first record in the registry is always the "File-Date" record.
>    This record occurs only once in the file and contains a single field
>    whose field-name is "File-Date".  The field-body of this record
>    contains a date (see Section 5.1) making it possible to easily
>    recognize different versions of the registry.

While this is an improvement, this didn't actually fully addressed my 
initial issue (see below).

Section 5.1 in -22 says:

>    Whenever an entry is created or modified in the registry, the 'File-
>    Date' record at the start of the registry is updated to reflect the
>    most recent modification date in the [RFC3339] "full-date" format:
>    included in any request to insert or modify records will be a new
>    File-Date record indicating the acceptance date of the record.  This
>    record is to be placed first in the registry, replacing the existing
>    File-Date record.  In the event that the File-Date record present in
>    the registry has a later date than the record being inserted or
>    modified, then the latest (most recent) record will be preserved.
>    IANA should attempt to process multiple registration requests in
>    order according to the File-Date in the form, since one registration
>    could otherwise cause a more recent change to be overwritten.

I think the document needs to be much clearer on how File-Date is to be 
used by various parties - IANA, Expert Reviewer, applications using the 
registry.
If section 3.1.2 is stating a requirement ("any changes (or a group of 
changes on the same date) must be detectable by examining the File-Date 
value in the registry"), then section 5.1 doesn't address this 
requirement. And I think it is indeed a very good requirement that must 
be addressed.
My problem is the following sentence in section 5.1:

   In the event that the File-Date record present in
   the registry has a later date than the record being inserted or
   modified, then the latest (most recent) record will be preserved.

This instruction makes some changes undetectable. For example if a 
registration request was accepted by the Expert Reviewer, but was missed 
by IANA for some reason, then once a newer registration forces update to 
registry's File-Date, then an application that checks the registry's 
File-Date has no way of detecting that a previously missed change was 
applied by IANA. This makes File-Date useless as far as I can see.

I can see a couple of ways of making this clearer:

1). Fix the process so that application of accepted changes with 
File-Date < registry's File-Date forces registry's File-Date to be 
updated (for example to the current date). This is my preferred 
resolution to this.

2). Document how File-Date can and can't be used. In particular document 
that it can't be used for detecting missed changes. I really dislike 
that solution, but I mention it anyway.

There might be other ways of addressing this that I've missed.

---

From: Kent Karlsson <[email-masked]>
Date: Sun, 07 Jun 2009 15:26:37 +0200

> There might be other ways of addressing this that I've missed.

Or, require that IANA changes the submitted File-Date to the date
IANA processes the given batch of changes actually applying them to the
registry and publishes the result, and also require that IANA processes at
most one batch of LSR changes per day (which I think you intended to include
as a requirement in order to achieve what you want, but did not state).

This way would be easy and not require a test of "given File-Date <
registry's File-Date" which may easily be missed to be tested. Nor would it
be very restrictive, given that batches of LSR changes do not occur very
often.

In the rare event that two (or more) batches come in on the same day,
they could either be merged into one batch (likely to have happened already
before they get to IANA) or they could be strung out one per day.

    /kent k

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Jun 2009 17:06:11 +0100

>be very restrictive, given that batches of LSR changes do not occur very
Indeed, this works as well.

>before they get to IANA) or they could be strung out one per day.
Right.

---

From: Peter Constable <[email-masked]>
Date: Mon, 8 Jun 2009 11:26:45 -0700

Sounds good to me.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Sunday, June 07, 2009 9:06 AM
To: Kent Karlsson
Cc: LTRU Working Group
Subject: Re: [Ltru] Issue #43: AD #10 - section 5.1 vs 3.2 on File-Date value

Right.

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 8 Jun 2009 11:47:23 -0700

Hi -

> From: "Alexey Melnikov" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Sunday, June 07, 2009 4:16 AM
> Subject: [Ltru] Issue #43: AD #10 - section 5.1 vs 3.2 on File-Date value
>
...

Issue is now re-opened in the tracker.
http://trac.tools.ietf.org/wg/ltru/trac/ticket/43

Randy

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Jun 2009 21:51:35 +0100

Doug Ewell <doug at ewellic.org> wrote:

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

A registrations request is sent on date T1 and approved by you on date
T2. You send a message to IANA saying that it was approved, the message
is eaten by IANA's antispam engine (or whatever). Another request
approved on date T3 (T3 > T2) is integrated to the registry, IANA
updates the registry date to be T3.
Then later on the first request is discovered to be lost and resend. If
IANA is to act according to the procedure as described in 4646bis right
now, IANA will not change the registry date, because T2 < T3 (== the
registry date)

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

This is fine.

Note, that this observation is not stated anywhere in the document.

> 2. Modifications to existing records do not cause an update to the 
> Added date,

Right.

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

I don't understand how you came to this conclusion. This probably means
that this sentence is already ambiguous.

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

I don't see a problem with that.

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

I agree that this is what IANA should do. In fact as per recent
discussion I think IANA MUST always do that.
But IANA is violating the procedure described in 4646bis as written.

So I am basically asking to align the document with the current
procedure Michael/you and IANA are already using.

================
In another message Doug Ewell <doug at ewellic.org> wrote:

> 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 agree that (a) is unlikely. Even if (b) is possible, I think it is Ok
stating this explicitly in the document.

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