Subject: [netmod] deprecated and conformance

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Jul 2008 09:16:23 +0200 (CEST)

Hi,

As we have discussed earlier, we don't currently have a fine grained
agent conformance mechanism, and it seems consensus is to not do this now
(with the possible exception of when-capability).

This means that a server that claims conformance to a module must
implement it fully (modulo when-capability).

But this makes a 'deprected' object problematic.  If an object is
deprecated, it means:

   "deprecated" indicates an obsolete definition, but it permits
   new/continued implementation in order to foster
   interoperability with older/existing implementations.

So a client knows that a server fully implements a module, but if
there are any deprecated objects, it doesn't know if those objects are
implemented or not.

Can we remove 'deprected' and use 'current' and 'obsolete' only?

/martin

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Jul 2008 09:42:04 +0200

> Can we remove 'deprected' and use 'current' and 'obsolete' only?

The assumption that every implementation will implement modules fully
is an illusion if you ask me. I think the distinction between obsolete
and deprecated has been useful in the SMI space and so I would not
easily give it up.

/js

-- 
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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 02 Jul 2008 01:41:41 -0700

> and deprecated has been useful in the SMI space and so I would not

deprecated serves a very useful purpose -- it means the
feature is supported now, but it will go away in the future.
It is needed to phase out old API mechanisms, instead of
eliminating them abruptly from version N to N+1.

> /js

Andy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Jul 2008 17:41:42 +0800

+1

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, July 02, 2008 3:42 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: Re: [netmod] deprecated and conformance
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 02 Jul 2008 12:37:01 +0200 (CEST)

> and deprecated has been useful in the SMI space and so I would not

I agree with both statements.

But I also think there is a real problem with the current spec.  W/o
any explicit conformance rules in the YANG spec, can a server claim
conformance to a module if it implements one single object from the
module?  Do we really believe that we'll get interoperable
configuration management from this?  How is a client supposed to adapt
to a server that - without any rules - implements some subset of a
module?

I think the best solution would be to have some kind of
agent-capabilities, which a conformant server that implements a subset
of a module would have to use.

At a minimum, I think we need to write down in the spec what a
conformant server can and must do while still claiming conformance to
a module.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Jul 2008 13:00:46 +0200

> conformant server can and must do while still claiming conformance to

I believe we should get YANG 1.0 out and worry about this later. YANG
module authors can still use English language to write down what needs
to be implemented to be compliant and what is optional. We do this for
protocols all the time.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Jul 2008 14:23:32 +0200

Yes, and also - aren't we missing module compliance with agent
capabilities. In SMI it is not the agent capabilities macro that
dictates compliance, and one cannot claim compliance with a certain
compliance profile without implementing all objects described in the
respective compliance module. If we go on the agent-capabilities line,
this would rather refer to the sum of different modules that the server
complies to. 

Dan
(speaking as contributor) 

> Sent: Wednesday, July 02, 2008 2:01 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> I believe we should get YANG 1.0 out and worry about this 
> later. YANG module authors can still use English language to 
> write down what needs to be implemented to be compliant and 
> what is optional. We do this for protocols all the time.
> 
> /js
> 
> --

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Jul 2008 14:25:09 +0200

s/missing/mixing/ 

> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Wednesday, July 02, 2008 3:24 PM
> To: [email-masked]; Martin Bjorklund
> Cc: [email-masked]
> Yes, and also - aren't we missing module compliance with 
> agent capabilities. In SMI it is not the agent capabilities 
> macro that dictates compliance, and one cannot claim 
> compliance with a certain compliance profile without 
> implementing all objects described in the respective 
> compliance module. If we go on the agent-capabilities line, 
> this would rather refer to the sum of different modules that 
> the server complies to. 
> 
> Dan
> later. YANG