Subject: [netmod] Status of draft-ietf-netmod-yang

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 7 May 2010 12:34:24 +0200

As expected, the I-D was not approved in the IESG telechat yesterday. It
is in status 'Revised-ID needed', which means that the editors and the
chairs need to continue to work with the ADs and clarify the issues
raised in their DISCUSSes, confirm the necessary edits, and then issue a
revised I-D that will include the edits that will allow the AD's to
clear the DISCUSSes. 

The issue that was mostly discussed in the call was the perceived
extra-flexibility of the deviation mechanism. To the concerns expressed
by Robert, Tim and other AD's added their own which made Robert move the
issue from a non-blocking COMMENT to the blocking list of issues in the
DISCUSS.  

 (Moved this to a discuss based on telechat conversation
  Tim plans to enter support when the tracker works for him)
The deviation mechanism seems too flexible to me. As
defined, someone could claim to implement standard X, but
use deviation statements to completely replace the contents
of X with something proprietary. Discussions with Dan
indicate that this was explicitly considered by the group
and deemed acceptable.  Is there any text that could be
added to more strongly discourage this kind of abuse of the
mechanism? In particular, what would help a client
implementor defend against a statement like 
"No, the spec says I can deviate this way, and you're at
non-interoperability-fault for not conforming to my
deviations" when the deviations are more extreme than the
simple policy and limit deviations shown as examples?

Please look carefully at this issue which (all other DISCUSS level
issues) needs to be clarified before the document is approved. 

We are very close. Thanks to all for the tremendous work done until now.

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 May 2010 12:44:08 +0200 (CEST)

> issues) needs to be clarified before the document is approved. 

Sean Turner suggested that we change the SHOULD to a MUST in the text
below:

  Device deviations are strongly discouraged and SHOULD only be used
  as a last resort.  Telling the application how a device fails to
  follow a standard is no substitute for implementing the standard
  correctly.

Was this not good enough?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 May 2010 12:54:50 +0200

> simple policy and limit deviations shown as examples?

Does the IESG feel this is worse than AGENT-CAPABILITIES in STD 58?
If so, why? Or is it that it is not deemed acceptable anymore what 
was acceptable back in 1999?

The phrase "completely replace the contents of X with something
proprietary" is also not very accurate. A vendor following that
approach would _formally_declare_ that he does not implement any of
the definitions of standard X. It does not matter whether the vendor
has proprietary replacement definitions since deviations only document
deviations, not replacements.

Please note that with SMIv2 AGENT-CAPABILITIES, I can list all objects
of a MIB module as "not-implemented". So if there is going to be abuse
of such a mechanism, we should have meanwhile some experience with
it. (Note that AGENT-CAPABILITIES were first introduced in 1993 if I
recall correctly - thats 17 years ago.)

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 May 2010 12:57:25 +0200

> Was this not good enough?

How do I implement this "MUST only as a last resort" - isn't the
complete phrase then equivalent to a SHOULD? But if it makes the IESG
happy, I am in favour of this change. ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 May 2010 13:00:23 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> complete phrase then equivalent to a SHOULD?

Right.  Not even "SHOULD" is really possible to implement.

But maybe MUST makes the statement seem more serious.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 07 May 2010 13:07:42 +0200

> But maybe MUST makes the statement seem more serious.

After looking at RFC 2119, I'd say the best formulation might be

Device deviations are strongly discouraged and SHALL only be used as a
last resort.

Lada

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

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 May 2010 05:01:26 -0700

> simple policy and limit deviations shown as examples?

I've said this about the deviation-stmt all along.
There seems to be a delusional fantasy that some level
of interoperability is maintained, even if deviations
are used by the server.  There is none.  You cannot
arbitrarily change data node definitions and expect
all clients to adjust correctly. 

On the contrary, simply using deviations at all is admitting that
your implementation is non-compliant and non-interoperable.
That's why I have concerns the <hello>
will not contain the deviations -- the server will
just lie about implementing the full YANG module.

> We are very close. Thanks to all for the tremendous work done until now.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 May 2010 14:10:27 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> are used by the server.

The spec clearly states:

> There is none.  You cannot

Correct.

> just lie about implementing the full YANG module.

Suppose server A implements parts of module foo, but not all mandatory
parts.  Such a server is non-compliant.

Now, suppose we didn't have deviations.  Server A advertises module
foo.  Server A is still non-compliant, and it is impossible for
clients to even know this.

Next, suppose we have deviations.  Server A advertises module foo, but
no deviations.  Server A is still non-compliant and makes it
impossible for clients to adapt.

Or, the server can advertise module foo plus deviations.  Such a
server is still non-compliant, BUT it makes it possible for clients to
adapt.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 May 2010 07:59:25 -0700

> server is still non-compliant, BUT it makes it possible for clients to

Even for the cleanest mechanism in deviations (not-supported),
it depends on the data model what impact omitting some of the
nodes will have.

For serious deviations, like changing mandatory to optional,
or changing an inet-address to a boolean, there is no predictability.
It is a case-by-case problem.

   1) Does the same deviation on 2 different servers insure that
       the 2 servers behave in the exact same way?

   2)  Will 2 different clients always handle a deviation the same way?
         It is obvious how to convert an inet-address to a boolean?

   3)  What are the reasonable expectations for a client application's
         ability to adapt to arbitrary deviations?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 May 2010 19:12:59 +0200

> all clients to adjust correctly. 

With deviations, a client can decide whether the deviation impacts the
client or not. Deviation in data nodes that are not used by this
particular client can be very well tolerated.
 
> your implementation is non-compliant and non-interoperable.

Yes, non-compliant. The client can decide whether the deviations can
cause problems or not.

> just lie about implementing the full YANG module.

So we need an RFC stating "you MUST not lie" and then by making this a
normative reference, we make this a better world. ;-)

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 May 2010 10:47:57 -0700

> particular client can be very well tolerated.

Of course -- changes to anything the client does not use
can be well tolerated.

> Yes, non-compliant. The client can decide whether the deviations can

Yes, and a YANG-aware CLI can present the operator
with a tailored input form for each specific server.
It may be semantic nonsense, and certainly scripts
will not deal with deviations well.

I am not arguing for removing them.
I am just pointing out that simply patching the YANG syntax
does little to solve the problem of vendors who
do not implement standards correctly.
It will still be a very labor-intensive 1-at-a-time problem.

> normative reference, we make this a better world. ;-)

No -- I am not arguing for changes.
Time will tell if this experiment works or not.
How many vendors bothered with AGENT-CAPABILITIES?
How many vendors want to advertise their lack-of-standards
every <hello> message, instead of burying it in user docs somewhere?

There is a certain leap-of-faith with the whole plan, but the
YANG spec is well-intentioned, so if vendors do not follow
the rules for not following the rules, it's not our fault. ;-)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 7 May 2010 09:57:15 -0400

>your implementation is non-compliant and non-interoperable.

Exactly.  Deviations say "I am not compliant with the spec and here
is exactly the places where I am misbehaving".  It's not a magic
wand to make broken implementations compliant, but a means of
declaring how broken they are.

>just lie about implementing the full YANG module.

Sure, and I'm sure public repositories will appear that will list
(in deviation format) how broken different implementations are.
Even having a means of listing these gives operators that power to
go to their vendors and give details about what's broken and MUST
be fixed (before the gear is even purchased).

Thanks,
 Phil