Subject: [netmod] Working Group Last Call: An NETCONF- and NETMOD-based Architecture for Network Management

From: David Partain <[email-masked]>
Date: Thu, 6 May 2010 14:57:09 +0200

Greetings,

This is an eleven-day working group last call on the current working group 
document:

Title:  An NETCONF- and NETMOD-based Architecture for Network Management
URL: http://tools.ietf.org/html/draft-ietf-netmod-arch-05

This WGLC will end on May 17, 2010.  Please review the document and post 
your comments on the mailing list.  Please use an appropriate Subject line so 
that the chairs and editor can easily keep track of the issues that need to 
be dealt with.

NOTE:  It is very important that the chairs can judge whether the Working 
Group thinks we're finished or not.  As such, please provide your comments, 
even if it is only to say "It's fine. Ship it!" 

Thanks.

David^2

---

From: David Partain <[email-masked]>
Date: Thu, 6 May 2010 15:07:22 +0200

> URL: http://tools.ietf.org/html/draft-ietf-netmod-arch-05

Hi,

First comment... Contrib hat on.

The title needs to be changed.  The current one is gramatically incorrect (/An 
NETCONF/A NETCONF/ is non-negotiable :-)), but I actually think it should be:

A NETCONF- and YANG-based Architecture for Network Management

or

An Architecture for Network Management using NETCONF and YANG

I personally prefer the latter.

NETMOD Is not the technology name and I think that's what should be in the 
title.

Cheers,

David

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 09:30:46 -0400

>> This is an eleven-day working group last call on the current working group

I like it.  Ship it.

>NETMOD Is not the technology name and I think that's what should be in the 

+1

Thanks,
 Phil

---

From: David Partain <[email-masked]>
Date: Wed, 12 May 2010 13:25:42 +0200

Greetings,

So far, there have been very few comments on this WGLC for the architecture 
draft.  The same is true of the usage draft (not going to send separate mail 
for that).

The chairs would be very grateful if folks would read and react to this 
documents by Monday.  Again, "It's fine. Ship it!" is much better than 
silence.

Cheers,

David

On Thursday 06 May 2010 14.57.09 David Partain wrote:
> your comments on the mailing list.  Please use an appropriate Subject line
> so that the chairs and editor can easily keep track of the issues that need
> to be dealt with.
>

---

From: "Ray S. Atarashi" <[email-masked]>
Date: Mon, 17 May 2010 13:33:26 +0900

Hi,

I read the architecture draft. It's fine for me. Section 3.1 is useful 
to understand the architecture.

Ray

(2010/05/12 20:25), David Partain wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 May 2010 11:04:52 +0200 (CEST)

Hi,

I have reviewed this document, and I think it is fine.  I have some
mostly minor editorial comments, and some YANG/XML corrections.

------------------------------
1. 

Since the title is being changed to "An Architecture for Network
Management using NETCONF and YANG", and this section also talks about
NETCONF, shouldn't this section be called "Origins of NETCONF and
YANG"?

BTW, you may want to expand NETCONF.
------------------------------

2.2

  namespace http://example.org/netconf/ospf;

The argument must be quoted, otherwise the // marks a line comment:

  namespace "http://example.org/netconf/ospf";

The same namespace issue exists in the model in 2.2.3.
------------------------------

2.2

  A leaf node that can appear as multiple times

s/as//

s/Define a/Defines a/
s/Incorporate the/Incorporates the/

(to match the other entries in the table)
------------------------------

2.2.2

s/The "deviation" give/The "deviation" statement gives/
------------------------------

2.2.3

Remove the <protocols> element from the XML.  It doesn't match the
data models.
------------------------------

3.4

  The modeler's role constructing a model based on their in-depth
  knowledge of the problem domain being modeled.

s/role constructing/role is constructing/  ?
------------------------------

3.5

  The reviewer role is perhaps the more important

most important?

I assume the idea that the XSLT script runs on the YIN module?  Maybe
you should make this clear.
------------------------------

3.7.3

You shoudn't use the ietf- prefix for an example model, so
s/ietf-bgpvpn/example-bgpvpn/
------------------------------

4.1

s/behave as is if the/behave as if the/

(I realized that this text was quoated from the YANG spec, and the
same error was there as well; now fixed).
------------------------------

4.1

   If a data value is given as part of those instructions is the
   default value,

s/value is given/value that is given/
------------------------------

4.2

s/describes it a state data/describes it as state data/
------------------------------

4.2

   An implementation that emits an integer leaf as
   "cow" would be difficult to manage, but applications must expect to
   encounter such misbehaving devices in the field.

I think you should remove the last part.  I think it says that
applications should not crash if given invalid data.
------------------------------

4.3.3.2 and 4.3.3.3

I am not too happy with these sections - they document the discussion
we had, but is the intention that readers of this spec should take
these options into account and create their own <get-ops> rpcs etc?

I would prefer these sections to be removed, but if the WG wants to
keep them I can live with that.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 May 2010 09:44:13 -0400

>mostly minor editorial comments, and some YANG/XML corrections.

Thank you for the review.  I have made all corrections, except
where indicated below.

>BTW, you may want to expand NETCONF.

Expand in what way?  "The Network Configuration Protocol (NETCONF)"?
Or do you mean expand the section/contents?

>s/The "deviation" give/The "deviation" statement gives/

This sentence uses the word "flexibility" in a bad way, so I
changed it to:

   The "deviation" statement allows the device, to indicate parts
   of a YANG module which the device does not faithfully implement.

>applications should not crash if given invalid data.

I think this is more than just "should not crash".  I think an app
needs to think about how it will deal with devices that do not toe
the line.  If some developer writes "none" were the spec says it's
a number, then having your app throw an exception when it sees that
data is a valid implementation choice.  If you app store the value
in an integer field in a database, that may be your only choice.
But if the meaning of this field is not vital to your app, then
using a string to hold the value may be sufficient to allow you to
continue to perform the apps job in the face of a non-compliant
device.

Basically when the device emits a clearly bad value, the app writer
can choose between purity and functionality, and it's a grey scale.

Should I add some of these words to make the point more plain?

>keep them I can live with that.

The sections were added at the specific request of the WG.  IMHO
this is still an open problem and we do not have a reasonable answer.
The section presents (if briefly) the unreasonable ones, why they
aren't reasonable, and why we're not really concerned.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 May 2010 08:22:11 -0700

> Should I add some of these words to make the point more plain?

I do not agree with the idea of classifying
the type of non-conformance in sec. 4.2:

   o  [strict compliance] behavior that follow the model completely

   o  [modeled deviations] behavior that follows within deviations
      allowed by the model

   o  [allowable deviations] behavior that falls outside the model, but
      can still be handled

   o  [unacceptable deviations] behavior that is not at all consistent
      with the model

The YANG and NETCONF WGs have not agreed on such a classification.
IMO, this list is misleading.  It suggests that the client
can automatically make reasonable decisions based on the syntax
patches that deviations represent.  There is no explanation how
they are standard or why they are needed.

If the server makes arbitrary changes to the syntax and or
semantics of a YANG data model, then it has already broken
the contract. 

I strongly object to the notion that the deviations represent
a new contract.  They exist in YANG to describe
how the contract has been broken.  Especially bullet 2.
There are no deviations allowed by the model.  That is the
empty set.  If you mean if-feature or when-stmt is 'false',
then that is part of the model, but deviations are never
part of the data model.

There are only 2 bullets:

   o  [strict compliance] behavior that follows the model completely

   o  [non-compliance] behavior that includes any deviation-stmts
      applied to the model

> aren't reasonable, and why we're not really concerned.

I agree with Martin.
This is an informational overview.
Sec. 4.3.2 (named 'Definitions') goes beyond
the scope of this draft and should be removed.
The WG has not agreed to 1 view of the NETCONF server.
That is why there are :candidate, :writable-running, :startup,
and :with-defaults capabilities.

>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 May 2010 11:18:44 -0400

>The YANG and NETCONF WGs have not agreed on such a classification.

This is from email on the mailing list, and represents my impression
of the WG thought.  If anyone else disagrees, please speak up.

>semantics of a YANG data model, then it has already broken

Yup, that's what the draft says.

>a new contract.

The draft does not say this.

>the scope of this draft and should be removed.

The WG asked this section be added, and I've added it.  If
the WG votes to remove it, I'll remove it.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 May 2010 09:06:14 -0700

This bullet does imply that there are deviations that
somehow fall within the model.  This will confuse
people learning YANG, because YANG defines a deviation
as being outside the model.  They are being presented
in this section as if some deviations are part of the model.
This bullet is wrong.  There are never any deviations allowed
by the model.

The excuse 'well, maybe the client implementation
will not care about that specific object' is not relevant
because the YANG module is a representation of the
conceptual data model, not any particular implementation.

There are no examples of any of these classifications either,
making the section even less helpful.

   Rarely, implementations may make decisions that prevent compliance
   with the standard.  Such occasions are regrettable, but they remain a
   part of reality, and modelers and application writers ignore them at
   their own risk.  An implementation that emits an integer leaf as
   "cow" would be difficult to manage, but applications must expect to
   encounter such misbehaving devices in the field.

This entire section seems to be suggesting that YANG
module compliance is a nice goal, but here is a different
view of compliance -- the 'close enough for jazz' architecture.

I do not agree that the IETF should be suggesting that
servers which implement the string 'cow' instead of a number
are acceptable, and client applications need to work with
servers that demonstrate a blatant disregard for interoperability.

I think the entire section 4.2 should be removed.
It is actually harmful to interoperability and
contradicts information in the YANG spec.

> the WG votes to remove it, I'll remove it.

I am voting to remove it.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 May 2010 12:12:14 -0400

>   o  [modeled deviations] behavior that follows within deviations

Overloaded the word "deviations", since the predated the statement's
creation.  This refers to "features", since that's a mechanism for
the modeler to describe how the contract can vary.  I'll choose a
better word.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 May 2010 09:41:38 -0700

> the modeler to describe how the contract can vary.  I'll choose a

IMO, this section needs more than a 1 word fix.
I would not be surprised if the IESG thinks so as well.

YANG deviations are good because they can describe
the way a server is non-compliant.  It is completely
data-model dependent how relevant a particular deviation
will be to implementations of that data model.

For example, for something like a standard MTU value,
changing the default by even a few bytes could have
a big impact on the network.  For a ping retry interval,
changing the default by a few seconds may not have
any impact at all on operations.

This is what this section should say about deviations:

   Deviations describe non-compliant behavior.
   It is up to the client application developer to
   examine each deviation on a case-by-case basis,
   to determine if and how the deviation can be tolerated
   within the application.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 May 2010 22:19:55 +0200 (CEST)

> Expand in what way?  "The Network Configuration Protocol (NETCONF)"?

Yes.

>    of a YANG module which the device does not faithfully implement.

Ok.

> Should I add some of these words to make the point more plain?

I still would prefer if the part from "but applications..." was
removed.  Ok, you do not say "MUST expect ..." but then what does the
"must" mean?  I agree with Andy that we should not encourage people to
ignore the contract that the YANG module is.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 May 2010 14:27:41 -0700

> ignore the contract that the YANG module is.

I support deviations.
I fully implemented them, and the NETCONF/YANG based
'server view customization' is 1000 times better than
SNMP or CLI ever had.  It works fine for interactive CLI
by showing the operator the exact data model the server
claims it supports.  Not so much for scripts so far, but
not impossible, just way harder.

But I strongly object to the characterization of the YANG
deviation statement as having anything to do with altering
YANG module conformance.

YANG has only 2 actual conformance mechanisms.
The starting point for conformance is everything
included in the module, except:
     - any data-def-stmt covered by an if-feature-stmt
     - any data-def-stmt that is config=false and mandatory=false

Those 2 classifications are optional-to-implement for the server.

I prefer to have text like the preceding paragraph in the
conformance section of the ARCH spec, and have a separate
section called 'Deviations', that gives actual examples,
and explains that the developer must evaluate each deviation
impact on the client implementation (not the model!).

IMO, my example about MTU vs. retry-interval is a good
example of why just altering 'default 1500' to 'default 1497'
is just pure syntax, devoid of semantics.

The '4 degrees of deviation conformance' are totally unacceptable.

Andy