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

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 20 Feb 2014 14:41:30 +0100

Martin,

do you think your concerns have been addressed by Ladislav's
answer?

/js

On Sat, Jan 11, 2014 at 02:31:08PM +0100, Ladislav Lhotka wrote:
> 
> On 11 Jan 2014, at 13:36, Martin Bjorklund <[email-masked]> wrote:
> 
> > Hi,
> > 
> > Ladislav Lhotka <[email-masked]> wrote:
> >> Hi,
> >> 
> >> changes in this revision mainly resulted from Martin’s review, I believe all
> >> his comments were addressed.
> > 
> > I have reviewed this version, and I think all my comments are
> > addressed.  Thank you!
> 
> Good, thanks!
> 
> > 
> > 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?
> 
> 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.
> 
> > 
> > 
> > 
> > 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.
> 
> 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 
> 
> > 
> > 
> > 
> > /martin
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Feb 2014 14:51:29 +0100 (CET)

> do you think your concerns have been addressed by Ladislav's

See inline.

> > 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.

Ok!

> > 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.

I think it would be better to make it local to "routing-state".  As it
is now, it is defined in the middle of a bunch of reusable groupings,
when in fact this one is not intended to be reusable.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 21 Feb 2014 11:15:26 +0100

…

> when in fact this one is not intended to be reusable.

That would mean the "next-hop-content” has to be moved under “routing-state” as well, because it uses “outgoing-interface”, and that would make the definition of “routing-state” really clumsy.

How about adding “rt” prefixes to all parts of that “path” argument instead?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 21 Feb 2014 11:55:30 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> That would mean the "next-hop-content” has to be moved under
> “routing-state” as well, because it uses “outgoing-interface”, and
> that would make the definition of “routing-state” really clumsy.
> 

Ok for me.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 21 Feb 2014 12:07:25 +0100

>> How about adding “rt” prefixes to all parts of that “path” argument instead?

So if nobody is opposed, I will post a new revision with this change only.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Feb 2014 12:38:56 +0100

> So if nobody is opposed, I will post a new revision with this change only.

You can't since I-D submission is blocked right now.

Please keep this comment/change for the processing of IETF last call
comments. My plan is to send the document to Benoit so that he can
initiate the process to start the IETF last call.

I just wanted to make sure we have resolved this. My understanding
is that no further issues are pending on this document.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 21 Feb 2014 13:12:17 +0100

> initiate the process to start the IETF last call.

OK, I’ve already changed it in the SVN so it won’t get lost.

> is that no further issues are pending on this document.

Yes, I am not aware of any.

Thanks, Lada