Subject: [Lager] [lager] #5 (): Add text about potential effects of recursive rules

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

#5: Add text about potential effects of recursive rules

 LGRs might include rules that could create situations where the evaluation
 of certain labels does never terminate because of recursive definitions.
 The syntax of the LGR does not prevent definitions of such recursive
 rules.

 Additionally, the presence of such rules is not fully detectable at the
 time the LGRs are being parsed, and might only be triggered once the
 implementation validates specific labels.

 Therefore, text should be added to the Security Considerations section
 explaining that situation.

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

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

---

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

Comment (by [email-masked]):

 See also ticket:1

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

Ticket URL: <http://trac.tools.ietf.org/wg/lager/trac/ticket/5#comment:1>
lager <http://tools.ietf.org/lager/>

---

From: Asmus Freytag <[email-masked]>
Date: Wed, 22 Jul 2015 23:39:07 -0700

>   explaining that situation.

Pardon me if I appear dense for a moment.

How would I set up a recursive rule?

In order to nest a rule inside another, it needs to be declared (named). 
While I'm parsing the declaration of a named rule, I have the choice (in 
principle) of allowing the name to exist before the body of the rule is 
fully parsed. If I do that, then I can set up recursion. If I don't 
allow the name to "exist" until the body of the rule is fully parsed, 
then the body of the rule can only nest rules defined earlier.

With such lack of forward declaration, there wouldn't be a way to set up 
recursion.

I think that is what we want, because there seems to be no use case in 
the LGR to have any recursion in the first place.

If that analysis is correct, then I suggest the text to be added is a 
clarification that there are no forward declaration and that nesting a 
rule inside itself isn't allowed either, and therefore recursion is not 
supported.

In any case, this is a restriction that I have implemented in my tool, 
but I see that there isn't language in 5.3.1 to that effect.

The current text says:

"A named rule may be incorporated into another rule by reference. "

I think it should be restricted:

"A previously encountered named rule may be incorporated into another 
rule by reference. "

and with that recursion would be off the table.

A./

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 23 Jul 2015 19:20:45 +0900

Hello Asmus,

Your reasoning below seemed straightforward, but then I read Marc's 
notes, where the possibility to cross-reference (rules in) files is 
mentioned. I don't know how rules currently are referenced across files, 
but if this is done directly using URIs/IRIs with fragment ids (which 
would be the most straightforward way on the Web), then recursion would 
still be possible.

Regards,   Martin.

On 2015/07/23 15:39, Asmus Freytag wrote:
> _______________________________________________
> Lager mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lager
>

---

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

> On Jul 23, 2015, at 3:20 AM, Martin J. Dürst <[email-masked]> wrote:
> 
> Your reasoning below seemed straightforward, but then I read Marc's notes, where the possibility to cross-reference (rules in) files is mentioned. I don't know how rules currently are referenced across files, but if this is done directly using URIs/IRIs with fragment ids (which would be the most straightforward way on the Web), then recursion would still be possible.

There is no grammar for cross-referencing or including other LGRs in the spec as written. The assumption has been that while importing other LGRs is desirable (and indeed essential for the Root Zone LGR), it would be done by an LGR-aware tool that would mechanically merge the LGRs, check for conflicts, and produce a compilation.

kim

---

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

> There is no grammar for cross-referencing or including other LGRs in the spec as written. The assumption has been that while importing other LGRs is desirable (and indeed essential for the Root Zon…

I agree, this isn't supported now and I see no good reason to allow such 
referencing.

A./

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 23 Jul 2015 22:41:30 +0200

On 23 Jul 2015, at 21:16, Asmus Freytag wrote:

>>> mentioned. I don't know how rules currently are referenced across 
>>> files, but if this is done directly using URIs/IRIs with fragment 
>>> ids (which would be the most straightforward way on the Web), then 
>>> recursion would still be possible.
>> There is no grammar for cross-referencing or including other LGRs in 
>> the spec as written. The assumption has been that while importing 
>> other LGRs is desirable (and indeed essential for the Root Zone LGR), 
>> it would be done by an LGR-aware tool that would mechanically merge 
>> the LGRs, check for conflicts, and produce a compilation.
>>
>>
>
> I agree, this isn't supported now and I see no good reason to allow 
> such referencing.

well, I think the overall expressed concern was that we shall carefully 
investigate if possible looping by a lazy implementation might happen, 
and if found possible (even for an incorrect xml file, but still xml 
validating), then some paragraph describing the case and providing the 
warning would be appropriate to add. And also a test vector would be 
useful for implementations to test against. This is just good guidance 
to implementations, not a comment on the grammer needs to be changed or 
not.

Marc.

---

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

On 7/23/2015 1:41 PM, Marc Blanchet wrote:
>>> other LGRs is desirable (and indeed essential for the Root Zone 
>>> LGR), it would be done by an LGR-aware tool that would mechanically 
>>> merge the LGRs, check for conflicts, and produce a compilation.
>>>
>>>
>>
> well, I think the overall expressed concern was that we shall 
> carefully investigate if possible looping by a lazy implementation 
> might happen, and if found possible (even for an incorrect xml file, 
> but still xml validating), then some paragraph describing the case and 
> providing the warning would be appropriate to add. And also a test 
> vector would be useful for implementations to test against. This is 
> just good guidance to implementations, not a comment on the grammer 
> needs to be changed or not.

I completely understand.

The language that needs to be added, in effect is to clearly state that 
the value for a "by-ref" attribute must be predefined when it is 
encountered.

This is something that I don't think you can catch with XML validation 
alone. (There are some other validation issues that only an LGR aware 
implementation can catch: "when" attributes refer to rules that are not 
defined at the point the "when" attribute is specified, but for the LGR 
to be valid, the corresponding rule must be defined.)

I can go through the text and figure out what the language needs to be.

Test vectors are a good idea.

A./