Subject: [netmod] ACL example and module issues

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Mar 2015 15:33:52 +0100

Hi,

I tried to validate the example in the acl-model draft against the
ietf-acl module and found several issues with this example:

- As Martin pointed out in his review, the example contains several
  trivial errors, in particular the XML namespaces are completely wrong.

- Such an example probably shouldn't be an <edit-config> message, a
  reply to <get-config> makes more sense here.

- The data model contains no <top> element, it was probably copied by
  mistake from an example in RFC 6241.

- Elements <destination-ipv4-address> and <source-ipv4-address> should
  in fact be <destination-ipv4-network> and <source-ipv4-network>,
  respectively.

After correcting the above validity problems I ran into the following,
which is most likely a data model issue:

- Containers "source-port-range" and "destination-port-range" are both
  mandatory because the child leaf "lower-port" in each is mandatory. I
  think this wasn't intended. One solution would be to make both of them
  containers with presence.

BTW, my GitHub project YANG-I-D is intended to aid the development of an
I-D along with a set of YANG modules described therein, and it also
provides a make target for validating examples. It would discover all
the problems above.

https://github.com/llhotka/YANG-I-D

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

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 23 Mar 2015 16:08:40 +0000

Lada,

Please see inline

>  trivial errors, in particular the XML namespaces are completely wrong.

fixed
>  reply to <get-config> makes more sense here.

Why is that? Will an xml response help here?
<?xml version="1.0" encoding="UTF-8"?>
  <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <ok/>
  </rpc-reply>

>  mistake from an example in RFC 6241.
fixed
>  in fact be <destination-ipv4-network> and <source-ipv4-network>,
fixed
>  containers with presence.

actually we have fixed that by removing 'must' statement from the lower-port leaf and with upper-port leaf having 
      must ". >= ../lower-port" {
makes ports not mandatory.
> https://github.com/llhotka/YANG-I-D

thanks for the good tool.
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 24 Mar 2015 17:06:00 -0500

> On 23 Mar 2015, at 11:08, Dean Bogdanovic <[email-masked]> wrote:
> 
> Lada,
> 
> Please see inline

I think what you want to show here is the datastore content, and for that a reply to <get-config> is more appropriate. It is also used this way in other NETMOD drafts and RFCs.

> makes ports not mandatory.

I’d suggest to do all three:

- define both port ranges as containers with presence,

- make lower-port mandatory, and

- include that must statement.

I think this conveys the intentions in a clear way.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Mar 2015 08:54:44 -0500

> On 24 Mar 2015, at 17:17, Lisa (Yi) Huang <[email-masked]> wrote:
> 
> 
> 
> On 3/24/15, 3:06 PM, "Ladislav Lhotka" <[email-masked]> wrote:
> 
>> 
>> I think what you want to show here is the datastore content, and for that
>> a reply to <get-config> is more appropriate. It is also used this way in
>> other NETMOD drafts and RFCs.
> 
> We intend to show <edit-config>. What make you think get-config was the
> intension? Want to find out so we could add descriptions to avoid the
> confusion.

Validity constraints for <edit-config> are much weaker, for example nodes that are defined as mandatory in the data model needn’t be present in an <edit-config> (mostly).

Moreover, the “target” parameter just adds noise and obfuscates the data content, which is what you probably want to demonstrate.

Lada