Subject: [netmod] refinement-stmt ABNF

From: Andy Bierman <[email-masked]>
Date: Fri, 05 Dec 2008 14:58:47 -0800

Hi,

The ABNF for the refinement statement leads to another
one of those mandatory empty curly braces '{ }',
since all of the variants contain optional clauses.

So this is illegal:

    uses foo {
       refine a/b/c;
    }

But this is not:

    uses foo {
       refine a/b/c { }
    }

Not sure what you want to do about it.
(I just code 'em as I see 'em :-)

Andy

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 07 Dec 2008 15:49:45 +0100 (CET)

> Not sure what you want to do about it.

There's no obvious solution... We could state in the text that at
least one refinement sub statement must be present.  It does not seem
right to allow "refine a/b/c;" since it doesn't really mean anything.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Dec 2008 08:33:59 -0800

> right to allow "refine a/b/c;" since it doesn't really mean anything.

I coded it the same as grouping -- which allows empty groupings.

   grouping foo;

this reserves the name 'foo' at least.  a 'uses foo' will amount
to a NO-OP.

   refine a/b/c;

this doesn't do anything at all, but it doesn't
hurt anything either (just a waste of bytes)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 07 Dec 2008 21:59:48 +0100 (CET)

> I coded it the same as grouping -- which allows empty groupings.

You're right.  So maybe we should do the same for refine then.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Dec 2008 13:37:20 -0800

> You're right.  So maybe we should do the same for refine then.

yes.

I collapse all the refines with the same target together.

We treat duplicate clauses like config-stmt (inside a leaf)
as an error (e.g., [config-stmt] means zero or one),
so I guess we should treat any duplicate refinement-stmt
sub-clauses (after combining all refinements with the
same target) as an error.

E.g., this is an error:

   refine a/b/c {
     config true;
   }

   refine a/b/c {
     config true;
   }

This is just as much of an error:

   refine a/b/c {
     config true;
     config true;
   }

The exception of course is must-stmt, because zero or more
are allowed of them.  There is no rule against having
the same (redundant) must-stmt (or unique-stmt) either.
It is just a warning.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 07 Dec 2008 22:49:08 +0100 (CET)

> > You're right.  So maybe we should do the same for refine then.

ok.

> I collapse all the refines with the same target together.

I treat multiple refines of the same target as an error.  This was the
behavior of the old spec, see the thread "repeat refine-stmts".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Dec 2008 14:51:07 -0800

> behavior of the old spec, see the thread "repeat refine-stmts".

I only saw 2 emails, and I do object to this CLR:

   refine a/b/c {
     mandatory false;
   }

   refine a/b/c {
     description "leaf c constrained as follows...";
   }

This should not be an error.
Consider applications (like the awesome smidump) that
generate YANG.  What if different sub-apps are responsible
for generating their own refinement-stmts?  (E.g., a
conformance sub-app tweaks mandatory-stmt and must-stmt,
and some other sub-app generates description refinements.)

I realize this is a stretch, but why have a CLR if the
practice being forbidden by the rule does not really
hurt anything?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Dec 2008 00:04:32 +0100 (CET)

> This should not be an error.

[...]

> practice being forbidden by the rule does not really

The rules that define this "merging" behavior will be non-trivial.  Is
it really worth it?  

And the use case you mentioned - tools have the lowest priority, and
the code in the tool that generates the refine can do the merging
itself.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Dec 2008 15:14:15 -0800

> The rules that define this "merging" behavior will be non-trivial.  Is

They are trivial -- just a sentence that says that no matter
how many refinement-stmts are entered that refer to the same
target object within the grouping, each sub-statement may
only be entered at most once.  The ABNF cannot express it
either way.

> the code in the tool that generates the refine can do the merging

What if it is a human and not a tool?

The compiler can be clever and merge the refine clauses.

IMO, in general, it is always a bad idea to force implementations
to generate errors for things that are not problems.

(I object to MUST NOT instead of SHOULD NOT).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Dec 2008 08:35:53 +0100 (CET)

Andy Bierman <[email-masked]> wrote:
> only be entered at most once.

So this is illegal by your rule:

   refine a/b {
       must ". > ../c";
       must ". > ../d";
   }

Whatabout:

   refine a/b {
       config false;
   }
   refine a/b {
       config false;
   }

And whatabout must:

   refine a/b {
       must ". > ../c";
   }
   refine a/b {
       must ". > ../d";
   }

> to generate errors for things that are not problems.

Sure, but I think that this is a problem...  This merging is imo
confusing.

So why don't we this merging for other statements as well?  Why isn't
this ok:

  leaf a {
    type int32;
  }
  leaf a {
    deafult 42;
  }

Or at least this should be ok?

  leaf a {
    type int32;
  }
  leaf a {
    type int32;
  }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 01:43:19 -0800

> So this is illegal by your rule:

no because this rule is *(must-stmt) and N are allowed

>        config false;

this is an error.
Any duplicate sub-clause that is [sub-clause] ABNF.

> So why don't we this merging for other statements as well?  Why isn't

The refine-stmt and augment-stmt are consistent now.
The augment-stmt does not have this CLR.
The leaf-stmt does not have an XPath target.
Obviously, 2 'leaf a' statements are an error.
This has nothing to do with refine-stmt.

> Or at least this should be ok?

What does this have to do with the refine-stmt
sub-clause of uses-stmt?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Dec 2008 10:58:30 +0100 (CET)

> no because this rule is *(must-stmt) and N are allowed

Your rule says "each sub-statement may only be entered at most once".
'must' is a sub-statement, and thus may only be entered at most once
according to your rule.

This is why I said that a trivial rule like yours won't work.

> The augment-stmt does not have this CLR.

Augment behaves in another way.  Each augment adds a block of child
nodes to the target node.  The child nodes to add MUST NOT exist in
the target node.  But refine modifies properties, and you're saying
that a property can be changed once, but not twice.  Seems like an
arbitrary rule.

I think we can end this discussion here.  You and I obviously have
differing opinion on this issue.  Does anyone else have an opinion?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Dec 2008 02:08:19 -0800

> This is why I said that a trivial rule like yours won't work.

Add 3 words to previous simple sentence (except the must-stmt).

> that a property can be changed once, but not twice.  Seems like an

No, changing 'leaf foo' to 'refine leaf foo' was arbitrary.
The point of that exercise was to make the refinements look
just like the augments.

   uses foo {
      augment a/b/c {
        leaf x { type string; }
      }
       augment a/b/c {
        leaf y { type string; }
      }
   }

This is legal YANG.
It would be confusing to treat refine-stmt as an error
if it did the same sort of thing.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 8 Dec 2008 09:48:12 -0500

>right to allow "refine a/b/c;" since it doesn't really mean anything.

For tools that generate YANG from other content (like our internal
DDL), it is always nice to not have to sweat these "at least one"
requirements.  In this case, the expense is minimal (since you
wouldn't even start a "refine" without planning content), but in
general, allowing empty substatements is a help to YANG generators.

Thanks,
 Phil