Subject: [Lager] [lager] #6 (): Should there be a registry of actions?

From: "lager issue tracker" <[email-masked]>
Date: Wed, 22 Jul 2015 18:40:50 -0000

#6: Should there be a registry of actions?

 Section 6.3 of the -10 draft contains a list of 4 actions. Will this be
 all that are ever needed? These may be suited to creating an IANA registry
 of actions that could provide a registration procedure so new actions can
 be added later independently of this specification. Discuss and decide.

-- 
---------------------------------+-----------------
Reporter:  [email-masked]  |      Owner:
    Type:  task                  |     Status:  new
Priority:  major                 |  Milestone:
 Version:                        |   Severity:  -
Keywords:                        |
---------------------------------+-----------------

Ticket URL: <http://trac.tools.ietf.org/wg/lager/trac/ticket/6>
lager <http://tools.ietf.org/lager/>

---

From: Asmus Freytag <[email-masked]>
Date: Wed, 22 Jul 2015 22:37:49 -0700

>   be added later independently of this specification. Discuss and decide.

The actions that are predefined in the specification are clearly defined 
as "default" actions, and specifically apply only to labels that trigger 
no actions defined in the LGR. Section 6.6 lists five of them (not four).

Both the set of actions, as well as the set of disposition values 
(section 6.3 recommends four values) are explicitly meant to be extensible.

The question I have with this comment is whether the suggested registry 
is really intended to register <action> elements, or whether it was 
rather the intent  to set up a registry of additional disposition values.

The latter would make more sense.

A disposition value speaks to a particular status for a label in the 
registration process. (The recommended values number four, which makes 
it more likely that they were meant, despite the reference to "action"). 
Further, the disposition values have no dependencies on each other, 
while <action> elements are always evaluated in the order they are 
present in the file (makes it awkward to create a registry for them).

Finally, <action> elements are triggered by rules and variant types that 
are specific to a given LGR document, again, making it less practical or 
useful to have an external registry.

I have no objection to a registry for label disposition values, so that 
the resulting label status after processing through a given LGR can be 
made more interoperable. If such a registry is desired, it should be 
defined outside this document though.

A./

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 23 Jul 2015 17:49:59 +0900

Hello Asmus,

> defined outside this document though.

I'm not sure how familiar you are with registries in the IETF. What 
usually happens is that a document defines the registries it needs. 
Here, "defines" means providing initial values, and criteria for 
updates. The actual registry is then maintained by IANA 
(http://www.iana.org).

In some cases, it's worth separating out registry stuff into a separate 
document, but for a simple registry with just four initial values that 
may not really be worth the trouble of creating a separate document.

Regards,   Martin.

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 23 Jul 2015 10:54:27 +0200

On 23 Jul 2015, at 10:49, Martin J. Dürst wrote:

> In some cases, it's worth separating out registry stuff into a 
> separate document, but for a simple registry with just four initial 
> values that may not really be worth the trouble of creating a separate 
> document.
>

yes. you wrote almost exactly what I was going to write.

Marc.

> Regards,   Martin.
>
> _______________________________________________
> Lager mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lager

---

From: Kim Davies <[email-masked]>
Date: Thu, 23 Jul 2015 15:35:52 +0000

Hi Asmus, Hi all,

On Jul 22, 2015, at 10:37 PM, Asmus Freytag <[email-masked]<mailto:[email-masked]>> wrote:

The question I have with this comment is whether the suggested registry is really intended to register <action> elements, or whether it was rather the intent  to set up a registry of additional disposition values.

Yes its the latter. I wrote that issue as it has been something on my mind but, as usual, didn’t use enough precision in my language :-)

I have no objection to a registry for label disposition values, so that the resulting label status after processing through a given LGR can be made more interoperable. If such a registry is desired, it should be defined outside this document though.

The thrust of my comment of having an IANA registry* is it would better allow for extensions to be documented independently without needing to rev the whole LGR spec. It would also give an explicit roadmap and expectation that if you do extend the LGR grammar in this way, you are expected to register your new verbs in this registry to ensure continued interoperability and avoid conflicts.

kim

* For those not familiar, it would be something like this: http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6 — the first six RCODEs were defined by the original DNS specification, but subsequent specifications added more to it.

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 23 Jul 2015 10:36:12 -0700

> values that may not really be worth the trouble of creating a separate 

OK, that makes sense

A./

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 23 Jul 2015 12:16:00 -0700

On 7/23/2015 8:35 AM, Kim Davies wrote:
>> The question I have with this comment is whether the suggested 
>> registry is really intended to register <action> elements, or whether 
>> it was rather the intent  to set up a registry of additional 
>> disposition values.
>>
> Yes its the latter. I wrote that issue as it has been something on my 
> mind but, as usual, didn’t use enough precision in my language :-)
>
OK, so a simple registry of "dispositions"  for labels.
>> I have no objection to a registry for label disposition values, so 
>> that the resulting label status after processing through a given LGR 
>> can be made more interoperable. If such a registry is desired, it 
>> should be defined outside this document though.
>
> The thrust of my comment of having an IANA registry* is it would 
> better allow for extensions to be documented independently without 
> needing to rev the whole LGR spec. It would also give an explicit 
> roadmap and expectation that if you do extend the LGR grammar in this 
> way, you are expected to register your new verbs in this registry to 
> ensure continued interoperability and avoid conflicts.

While you are thinking of these as verbs, others are thinking of them as 
status values; that's the disconnect that we are tracking in another 
item. We obviously need to resolve that issue first.

But otherwise, I agree with the thrust here, and if setting up a 
registry is "simple" I have no objection to having it done in the document.

A./
>
> kim
>
> * For those not familiar, it would be something like this: 
> http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6 — 
> the first six RCODEs were defined by the original DNS specification, 
> but subsequent specifications added more to it.
>
>
>

---

From: Kim Davies <[email-masked]>
Date: Thu, 23 Jul 2015 20:21:59 +0000

> While you are thinking of these as verbs, others are thinking of them as status values; that's the disconnect that we are tracking in another item. We obviously need to resolve that issue first.

My take is the imperative form is more appealing by being shorter and more direct; but I’ll admit to it being a bit of a bikeshed painting issue and I can go either way. Perhaps if anyone else here feels strongly about it they can chime in before we settle on an approach.

Option A (verbs): allocate / block / activate / invalid
Option B (consequential status): allocated / blocked / activated / invalid

kim

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 23 Jul 2015 16:21:17 -0700

On 7/23/2015 1:21 PM, Kim Davies wrote:
> My take is the imperative form is more appealing by being shorter and more direct; but I’ll admit to it being a bit of a bikeshed painting issue
I agree.
> and I can go either way. Perhaps if anyone else here feels strongly about it they can chime in before we settle on an approach.
>

Option C:  "allocatable" / "blocked" / "activated" / "invalid"

The reason for C (and the reason why I even care), is that for the Root 
Zone we are locked into "allocatable" and "blocked". It would be stupid 
to have to register aliases just for the root (and  as an have noticed, 
it surfaces when you do tools).

A./