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

[Asmus Freytag <[e-mail]>]

On 3/25/2016 1:14 AM, Alexey Melnikov wrote:
> 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.

Looked at the text in context. MAY ---> may is fine anyway, because the 
passage is somewhat introductory.
>>> 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.

I cleaned up the passage and added a note that makes the point about 
default actions being treated as if added past the last user defined 
action.  (See below).

A./


  7.6 Default Actions <#default_actions>

If a label does not trigger any of the actions defined explicitly in the 
LGR, the following implicitly defined default actions are evaluated. 
They are shown below in their relative order of precedence (seeSection 
7.4 <#precedence>). Default actions have a lower order of precedence 
than explicit actions (seeSection 8.3 <#determining_dispositions>).

The default actions for variant labels are defined as follows. The first 
set is triggered based on the standard variant type values of "invalid", 
"blocked", "allocatable", "activated":

     <action disp="invalid" any-variant="invalid"/>
     <action disp="blocked" any-variant="blocked"/>
     <action disp="allocatable" any-variant="allocatable"/>
     <action disp="activated" all-variants="activated"/>

A final default action sets the disposition to "valid" for any label 
matching the repertoire for which no other action has been triggered. 
This "catch-all" action also matches all remaining variant labels from 
variants that do not have a type value.

     <action disp="valid" comment="Catch-all if other rules not met"/>

Conceptually, the implicitly defined default actions act just like 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 thus be processed by the default actions as if they were 
present in the LGR. As the last default action is a "catch-all", all 
processing is guaranteed to end with a definite disposition for the label.


>
>
>
> _______________________________________________
> Lager mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lager