Re: [Lager] Incoming AD review on draft-ietf-lager-specification-11.txt

[Asmus Freytag <[e-mail]>]

I'll let Kim address the issues with 4.3.5 and 11.3 (media type and 
registration).

Here some comments on the issues raised against 6.1 and 7.6.

A./

On 3/24/2016 10:46 AM, Alexey Melnikov wrote:
> In 6.1:
>
>> >A rule MAY contain the following as child elements:
> Nit: This is an invalid use of MAY, because it is not an implementation
> choice. I don't think you meant here that implementations don't have to
> support any of the listed child elements?

What is the specification aimed at? It's a file format. That means, 
there are different levels of requirements for authors (of what may be a 
single LGR document, which does not have to include all possible 
features) and implementations (that we would expect of being able to 
interpret any well-formed LGR document). It seems to me:

  * Implementations (readers, parsers, validators) MUST support all
    features, including OPTIONAL ones.
  * Authors MAY supply any features, except those that MUST NOT be
    present, and MUST supply all required features.

In that context, MAY or not MAY in the above example?

Aside from that, would it have been better to write:

"A rule may contain the following OPTIONAL child elements"

> In 7.6:
>
>> >If no actions are defined for the standard disposition values of
>> >"invalid", "blocked", "allocatable", "activated", then the following
>> >implicitly defined default actions are evaluated.
> Are default actions defined if none of the actions for recommended
> standard dispositions is defined or if any of them is not defined? For
> example, I was thinking whether it would be Ok to just automatically
> (and unconditionally) append these default actions to any LGR file for
> purposes of evaluation? If any action for standard disposition value is
> already defined and it would take precedence, so the corresponding
> default action would be ignored.
Yes, this can be improved.

I think it would be cleanest to describe the "implicitly defined default 
actions" as a block of <action> elements that is added (virtually) 
beyond the last of the user-supplied actions. Any label not processed by 
the user-supplied actions would be processed by these "implicitly 
defined default actions" as if they were present in the file. As the 
last one is a "catch-all", all processing is guaranteed to end with a 
definite disposition for the label.

Note that the phrase used in the existing description ("standard 
disposition values") is potentially misleading, because we now make the 
distinction between "types" (on variant mappings) and "dispositions" (as 
result of processing labels). We didn't use to and this wording may be a 
holdover.

I'll look at suggested wording.

A./