Subject: Re: [Netconf] [netmod] features and capabilities

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2008 10:18:30 +0100 (CET)

I moved this thread from netmod to the netconf list.

The issue is if the partial-lock spec should reuse the existing :xpath
capability or define a new :partial-lock-xpath capability.

The WG had this exact discussion when the notification spec was
written.  At that time I brought up this argument (I wanted a separate
capability for notification-xpath), but consensus was to reuse the
existing :xpath.

Of course the WG could change its mind, but since we already have
started to reuse the :xpath capability like this, I prefer to be
consistent and resue it also for partial locks.

/martin

Andy Bierman <[email-masked]> wrote:
> Phil Shafer wrote:
> > Balazs Lengyel writes:
> >   
> >> BALAZS: I could do that with introducing a new xpath-for-partial-lock
> >> capability. It is not more difficult to handle, then introducing "feature
> >> xpath" in the partial lock module. (
> >> On the other hand I don't want to control XPath handling for partial locking
> >> separately. It wou
> >> ld be confusing.)
> >>     
> >
> > Confusing .vs. not implementable.  In your current scheme, you
> > force devices that do one to do both.
> >
> > I feel we're beating the same horse again.  Do we need a concensus
> > call to move forward?  Didn't we already have (at least) one?
> >
> >   
> 
> I support Phil on this one.
> We do not want to force vendors to remove their :xpath advertisement
> for their compliant 4741 implementations, because they choose to
> implement :partial-lock but cannot adhere to all the bells and whistles
> that the partial lock draft adds to the :xpath capability.
> 
> To be more clear:
> 
>    A new capability MUST NOT add any requirements to an existing capability.
>  This rule is being violated by the partial-lock draft.
> 
> > Thanks,
> >  Phil
> >
> >
> >   
> Andy
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Dec 2008 10:18:30 +0100 (CET)

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2008 16:27:07 -0500

>consistent and resue it also for partial locks.

So in a few years, the :xpath capbility will be reused for the 57th
time in some new YANG module.  An implementor will need to decide
if they can afford to support the new module, given that they
supported :xpath on one of the 56 earlier uses.

This forces all-or-nothing decisions that I'd like to avoid and
even if we've made this mistake once, that should be enough.  I'd
vote for sanity over consistency.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Dec 2008 16:27:07 -0500

Thanks,
 Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 5 Dec 2008 11:57:43 -0500

Hi

The alternative is to have way too much granularity in capability
definitions . I think the current method of using the existing :xpath
advertisers makes the most sense.  Really, once an implementation
supports XPath for one (or 56 features), the cost of supporting xpath
for a single new capability is not the same as supporting it for the
first capability.

And should some new fancier version of XPath ever come out, we can just
create a new capability :xpath-fancy without having (3*57) capabilities.

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Phil Shafer
Sent: Thursday, December 04, 2008 4:27 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] [netmod] features and capabilities

>consistent and resue it also for partial locks.

So in a few years, the :xpath capbility will be reused for the 57th time
in some new YANG module.  An implementor will need to decide if they can
afford to support the new module, given that they supported :xpath on
one of the 56 earlier uses.

This forces all-or-nothing decisions that I'd like to avoid and even if
we've made this mistake once, that should be enough.  I'd vote for
sanity over consistency.

Thanks,
 Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 5 Dec 2008 11:57:43 -0500

Hi

Sharon

-----Original Message-----

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 05 Dec 2008 10:14:06 -0800

> create a new capability :xpath-fancy without having (3*57) capabilities.

I think Phil's proposal to make this a YANG feature is the right choice,
but if the NETMOD dependency is unacceptable, then a new capability
is needed instead.

It is a big deal to keep piling on an existing capability.
The WG decided to make some functionality optional,
so it should be optional.

Consider an agent implementation with sub-agents or even pluggable
YANG modules, so module X is written with no knowledge of module Y.
An NMS application relies on module X support of :xpath capability.
Now a new module (partial-lock) is added and a different NMS app
is used to control it.  Except the new module, being rushed to
market, is a bare-bones compliant implementation with no extras.

The vendor is now hosed one way or another.
Either advertise :xpath so the first app does not break,
or NOT advertise :xpath so the 2nd app does not break.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 05 Dec 2008 10:14:06 -0800

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 5 Dec 2008 13:17:24 -0500

Hi

Doesn't that violate the separation of the protocol from the data model?
How does this work for all the implementations that don't currently
support yang?

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, December 05, 2008 1:14 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Phil Shafer; Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] [netmod] features and capabilities

Sharon Chisholm wrote:
> And should some new fancier version of XPath ever come out, we can 
> just create a new capability :xpath-fancy without having (3*57)
capabilities.

I think Phil's proposal to make this a YANG feature is the right choice,
but if the NETMOD dependency is unacceptable, then a new capability is
needed instead.

It is a big deal to keep piling on an existing capability.
The WG decided to make some functionality optional, so it should be
optional.

Consider an agent implementation with sub-agents or even pluggable YANG
modules, so module X is written with no knowledge of module Y.
An NMS application relies on module X support of :xpath capability.
Now a new module (partial-lock) is added and a different NMS app is used
to control it.  Except the new module, being rushed to market, is a
bare-bones compliant implementation with no extras.

The vendor is now hosed one way or another.
Either advertise :xpath so the first app does not break, or NOT
advertise :xpath so the 2nd app does not break.

Andy

> time in some new YANG module.  An implementor will need to decide if 
> they can afford to support the new module, given that they supported 
> :xpath on one of the 56 earlier uses.
> 
> This forces all-or-nothing decisions that I'd like to avoid and even 
> if we've made this mistake once, that should be enough.  I'd vote for 
> sanity over consistency.
> 
> Thanks,
>  Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 5 Dec 2008 13:17:24 -0500

Hi

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Friday, December 05, 2008 1:14 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Phil Shafer; Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] [netmod] features and capabilities

capabilities.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 05 Dec 2008 10:28:48 -0800

> Doesn't that violate the separation of the protocol from the data model?

No, because the feature is defined as "XPath 1.0 support for partial-lock",
which puts it in the operations layer, not the protocol layer.

> How does this work for all the implementations that don't currently

An agent does not need to support YANG to construct a capability URI
with an extra "?features=xpath-lock" on the end of it.  But using a YANG feature
is not important enough to wait on the normative reference.

A separate capability is fine.  So far there are a handful of
standard capabilities and adding 1 more will not hurt.
There are read by machines anyway, so what does it matter
if there are 10 or a 100?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 05 Dec 2008 10:28:48 -0800

Andy