Subject: Re: [netmod] [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light]

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Jun 2012 08:37:26 +0200

On Jun 14, 2012, at 3:37 AM, Alexander Clemm (alex) wrote:

> Hi,
> 
> here is one example:
> 
> The definition of identity allows to specify a base identity, allowing
> to build an "identity hierarchy".  However, if I subsequently want to
> specify a condition or a constraint that pertains to all identities that
> were derived from the same base identity, I need to enumerate every
> single one of the identities.  This makes the definition of the
> condition/constraint unnecessarily complex.  Even worse, every time I
> introduce a new identity that is derived from the same base identity, I
> need to update the conditions/constraints which may have been defined in
> an entirely different place.  This basically also defeats the purpose of
> using identities, instead of enums, to allow for extending a set of
> enumerated values without having to revise the original definition.

Yes, one of the proposed XPath extension functions is derived-from(). The others are:

- deref() (for dereferencing instance identifiers),
- is-bit-set(),
- if-feature()
- if-module()
- if-capability()

>  
> 
> For example, think of the following identity hierarchy:
> flow
> +-- audioflow
>    +-- pandora
>    +-- rhapsody
>    +-- spotify
>    +-- ...
> 
> If I have a constraint that pertains to audioflows, I need to enumerate
> a long list of subidentities instead of the single base identity, and
> need to update that constraint whenever a new identity that identifies a
> new audioflow is introduced.  
> 
> (Maybe this part of the thread actually belongs on the netmod mailer,
> not netconf)

Right, so I am moving it to the netmod list.

Lada

> --- Alex
> 
> 
> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]] 
> Sent: Wednesday, June 13, 2012 2:13 AM
> To: Alexander Clemm (alex); Carl Moberg
> Cc: Netconf
> Subject: RE: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying
> aconsensus on the way forwardwithNetconf-Light]
> 
> "Alexander Clemm (alex)" <[email-masked]> writes:
> 
>> Just my 2 cents, one aspect that seems a bit clumsy in YANG concerns
> the
>> specification of conditions and constraints.  While it is certainly
>> possible to argue that it does the job, it is fairly hard to use.  If
> it
> 
> Could you be more specific? What is exactly hard? Is it that, for
> example, one needs to carefully count the number of double dots in order
> to get to a remote node? Or missing semantics?
> 
>> is hard to use, things might be left up to implementations while they
>> really should be captured in the spec.  It might be worthwhile to
>> consider possible alternatives to the current scheme, such as being
> able
>> to refer to a more "procedural" way to refer to constraints, rather
> than
>> the declarative way it is now.
> 
> We have been discussing the addition of several new XPath functions, but
> mainly for supporting special YANG data types, so nothing really
> procedural. Can you give some examples?
> 
> Thanks, Lada
> 
>> --- Alex
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Carl Moberg
>> Sent: Tuesday, June 12, 2012 6:52 AM
>> To: Ladislav Lhotka
>> Cc: Netconf
>> Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying
>> aconsensus on the way forwardwithNetconf-Light]
>> 
>> 
>> On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote:
>> 
>>> Carl Moberg <[email-masked]> writes:
>>>> For the record; I don't actually see any strong suggestions that
>> there are any features that are "too heavy-weight, clumsy or broken"
> in
>> NETCONF or YANG. At least I have never heard that type of feedback
> from
>> the implementations that we've been working with. Sure, there are
> issues
>> and challenges with implementing server-side NETCONF (and YANG)
>> particularly around retrofitting it on top of existing software
>> infrastructure, but I have no experience that there are show stopping
>> aspects to it that must be fixed.
>>> 
>>> OK, let me mention one thing: the design of <edit-config> is wrong. A
>> standard approach would be to have one expression for locating the
> node
>> to be updated and another one for specifying the changes. This is how
> it
>> is done e.g. in XQuery Update or in databases. <edit-config> attempts
> to
>> do both steps in one shot which doesn't really work all that great.
>> While this may not be a showstopper, it certainly causes problems -
> cf.
>> the parallel discussion in the NETMOD list regarding keys for route
>> lists. With a separate locator expression, the NETCONF client wouldn't
>> have to care about list keys all that much and just use any
> appropriate
>> attributes for selecting a list entry.
>> 
>> 
>> 
>> I agree that it's not perfect. It's about as good/bad as some other
>> protocols (e.g. SNMP). But the point that I come back to is that it's
>> certainly good enough (even with that imperfection and others) that it
>> has the potential to radically improve the way we do configuration
>> management in networks. Making it a moving target instead of widely
>> applying what we have would be a case of over optimization IMHO.
>> 
>> Now, this looks like one dead horse :-)
>> 
>> --
>> Carl Moberg, Tail-f Systems
>> mailto:[email-masked]
>> twitter: @cmoberg
>> http://www.tail-f.com/
>> 
>> _______________________________________________
>> Netconf mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netconf
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 14 Jun 2012 15:26:14 -0700

Hello Ladislav,

exactly; those extension functions that you describe would make a huge
difference. deref() seems of particular relevance as well.  

Regards
--- Alex

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2012 11:37 PM
To: Alexander Clemm (alex)
Cc: [email-masked]
Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying

> enumerated values without having to revise the original definition.

Yes, one of the proposed XPath extension functions is derived-from().
The others are:

Lada