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

[Alexey Melnikov <[e-mail]>]

Hi Asmus,

> On 24 Mar 2016, at 23:29, Asmus Freytag (t) <[e-mail]> wrote:
> 
> 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)

Ok, but isn't that true for pretty much all the features in the format? Why is this one special?

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

I thought your document was mostly targeting implementations. If not, having a separate section that covers authors might be a good idea.
> 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"

INHO, this is no better, because you are not telling who are they optional for.
>> 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.

Right, this is what I thought.
> 
> 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.

That would be great, thank you.