Subject: [netmod] RFC 6020 errata 3288, 3289, 3290

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jul 2012 10:17:13 +0200

Hi,

Martin has posted errata 3288, 3289, 3290:

http://www.rfc-editor.org/errata_search.php?rfc=6020

Can people review and comment? Is there agreement that these are valid
technical errata?

Speaking as technical contributor, it seems 3289 and 3290 are
relatively clear cut fixes.

I am not so sure about 3288, in particular the augment case and the
meaningful usage of (multiple) augments in a uses substatement. I do
note that the errata brings the table in section 7.12.1 inline with
the grammar of uses-stmt.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 25 Jul 2012 11:00:40 +0200

> the grammar of uses-stmt.

I agree with Martin. Both augment and refine statements under a uses 
statement should have a cardinality of 0..n. Imagine a grouping with 
multiple container statements. A cardinality of 0..1 would mean that the 
user may choose to augment only one of them during uses expansion. What 
if the requirement is to add statements to two of such containers? Same 
goes for refine.
Note that this is the only way for a grouping or rather it's content to 
get augmented. And I can't imagine groupings with multiple subtrees 
being uncommon.

 From my perspective these are only typos. YANG grammar confirms it.

Jernej

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 25 Jul 2012 16:04:05 +0200

Dne 25.7.2012 11:00, piše Jernej Tuljak:
> multiple container statements. A cardinality of 0..1 would mean that 
> the user may choose to augment only one of them during uses expansion. 
> What if the requirement is to add statements to two of such 
> containers? Same goes for refine.
> Note that this is the only way for a grouping or rather it's content 
> to get augmented. And I can't imagine groupings with multiple subtrees 
> being uncommon.

Correction. You could just use a toplevel augment, but I think it's good 
to be able to do it from where the uses is. Perhaps it makes some cases 
more readable even though it's redundant.

module uses-augment {
     namespace "http://ns.example.com/uses-augment";
     prefix ua;
     revision 2012-07-25;
     grouping common {
         container one;
         container two;
     }
     container stuff {
         uses common {
             augment "two" {
                 leaf leafy-leaf {
                     type int32;
                 }
             }
             augment "one" {
                 leaf leafy-leaf {
                     type int32;
                 }
             }
         }
     }
     container redundant {
         uses common;
     }
     augment "/ua:redundant/ua:one" {
         leaf leafy-leaf {
             type int32;
         }
     }
     augment "/ua:redundant/ua:two" {
         leaf leafy-leaf {
             type int32;
         }
     }
}

Jernej

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jul 2012 07:16:09 -0700

> Can people review and comment? Is there agreement that these are valid

It looks fine to me.
I think yuma already implements all these corrections.
Multiple augment-stmts for the same target is not that
hard to implement.  You have to do that anyway because
a top-level augment from somewhere else can also add nodes.

> the grammar of uses-stmt.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jul 2012 07:28:05 -0700

...

You don't even need an example of multiple augments
this complicated.  Just add the when-stmt, that's
complicated enough :-)

  container foo {
      uses common {
          augment one {
             when "../two/some-leaf = 4";
             leaf mode4 { type string; }
          }
          augment one {
              leaf leafy-leaf { type string; }
          }
      }
  }

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Jul 2012 16:44:58 +0200

>               leaf leafy-leaf { type string; }

Yep, I have been confused. Speaking as technical contributor, it seems
all three erratas are valid.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Jul 2012 18:07:16 +0200

> Can people review and comment? Is there agreement that these are valid

I agree with all three changes. I also checked that 3288 does not affect the DSDL mapping procedure from RFC 6110.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C