Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt

From: [email-masked]
Date: Fri, 10 Jan 2014 05:30:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : A YANG Data Model for Routing Management
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-routing-cfg-13.txt
	Pages           : 95
	Date            : 2014-01-10

Abstract:
   This document contains a specification of three YANG modules.
   Together they form the core routing data model which serves as a
   framework for configuring and managing a routing subsystem.  It is
   expected that these modules will be augmented by additional YANG
   modules defining data models for individual routing protocols and
   other related functions.  The core routing data model provides common
   building blocks for such extensions - routing instances, routes,
   routing information bases (RIB), routing protocols and route filters.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Jan 2014 14:38:03 +0100

Hi,

changes in this revision mainly resulted from Martin’s review, I believe all his comments were addressed.

Appendix B is new, it describes a minimum implementation of the core routing data model.

Lada 

Begin forwarded message:

> From: [email-masked]
> Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt
> Date: 10 Jan 2014 14:30:16 GMT+1
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 11 Jan 2014 13:36:34 +0100 (CET)

Hi,

> his comments were addressed.

I have reviewed this version, and I think all my comments are
addressed.  Thank you!

I have one question about a change that I believe was not discussed on
the list:

   o Remove "when" statement for IPv6 router interface operational	
     state - it was dependent on a config value that may not be	
     present.	
		
I do not think is correct.  If the ipv6 container exists, the
'enabled' leaf has the default value of 'true', and default values are
taken into account when XPath expressions are evaluated.  But maybe I
misunderstood the problem?

I noticed one thing that may or may not be intentional.  The grouping
"outgoing-interface" has a leaf with a leafref, where the path uses
non-prefixed identifiers.  If this grouping is ever used from another
module, it means that that module must have the same data hierarchy
(/routing-state/...) as this module.  These identifiers should
probably use prefixes.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 11 Jan 2014 14:31:08 +0100

> I have reviewed this version, and I think all my comments are

Good, thanks!

> misunderstood the problem?

If it is a system-controlled interface, there may be no entry for it in /if:interfaces/if:interface, and the default then doesn’t apply.

> (/routing-state/...) as this module.  These identifiers should

That grouping is actually intended only for local use. Modules for routing protocols might also define outgoing-interface but they should use relative path so as to limit the choice only to interfaces assigned to the ancestor routing instance. It is done so already for the “static” protocol.

Maybe the “outgoing-interface” grouping could be made local by moving it under “routing-state” but that seems detrimental to the module organization - the definition of the grouping would be harder to find.

Lada