Subject: Re: [netmod] js review of draft-ietf-netmod-arch-05.txt

From: Phil Shafer <[email-masked]>
Date: Wed, 16 Jun 2010 15:40:16 -0400

Juergen Schoenwaelder writes:
>this is my WG last call review of <draft-ietf-netmod-arch-05.txt>.

Many thanks for the comments.  All have been made except the following:

>d) p4: Did operators really ask for "low implementation costs"? I
>       would understand if they ask for "low deployment costs" - low
>       implementation costs is something vendors usually worry about.

The term "implementation costs" is used in rfc3535, so assumably
the workshoppers were comfortable with this term:

  5. Consolidated Observations
   ...
   16. The implementation costs have to be low on devices.
   17. The implementation costs have to be low on managers.

>r) p9: I would replace the import with two imports since that is a
>       more likely organization
>
>        import ospf-types      { prefix ospf-types; }
>        import interface-types { prefix if-types; }
>
>       and then use ospf-types:area-id and if-types:interface-name.

The example refers to nodes, not types, so I'm leaving it unchanged.

>z) p14: Add a new section "2.X Usage Guidelines" that briefly points
>        to the usage guidelines document and explains that these
>        guidelines must be followed by (IETF) standard data models.

I could not find suitable words in the current rev, so I made
up some words:

  ** IETF Guidelines

  A set of additional guidelines are defined that indicate desirable
  usage for authors and reviewers of standards track specifications
  containing YANG data model modules (^RFCYANGUSAGE^).  These
  guidelines should be used as a basis for reviews of other YANG data
  model documents.

>W) p19: Should the section describing the device modeler not mention
>        that the developer should write deviation statements in cases
>        where his implementation puts restrictions on the data model?

I'm iffy here, since we want to discourage deviations.

>5) p27: Add the following section:
>
>   4.3.3.4 Introduction of Meta-Data Tags
>
>      The NETCONF protocol might be extended to carry meta-data tags
>      (for example encoded in XML attributes) that identify whether an
>      XML element carries configuration data, operational state data,
>      or statistical data. This approach allows responses to <get>
>      operations to contain mixed data, making it easy for clients to
>      separate configuration data from operational state data. Servers
>      may be allowed to skip over any non-config data supplied by
>      clients in <edit-config> or <copy-config> operations.

I do not want to add this text, since this not a workable solution
in the current YANG/NETCONF world.  We certainly don't want to
encourage modelers to step in this direction at this time.

>6) p27: Does section 4.3 belong into this document? Unfortunately, as
>        long as the WGs have not converged to a solution, I believe it
>        is necessary to keep this text since we right now leave it to
>        the data modelers to figure out what to do. I believe this is
>        actually a bad idea but lets be honest about it.

Section 4.3 was added at your request.  I am not happy with it,
since it doesn't contain any useful direction to modelers other
than "we don't know either".  I'd be happy to remove it, if that
is the concensus of the WG.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Jun 2010 23:42:27 +0200

>    17. The implementation costs have to be low on managers.
 
The workshop was not just attended by operators, see RFC 3535 for the
details. The sentence in question talks about operators, not the
workshop attendees and thus my question remains valid.

> I'm iffy here, since we want to discourage deviations.

I thought we introduced the deviation statement since we believe a
honest description of what an implementation does is worth to have.
So if there are deviations, I think they should be documented. Or
are you saying that it is better to not document them?

> encourage modelers to step in this direction at this time.

We do exactly this now to identify defaults in explicit config
implementations - so if this is not workable, we should remove the
attributes from with-defaults.

> is the concensus of the WG.

My preference would be that 4.3 is not needed. However, since we do
not seem to move into the direction of answering the question how we
prefer to represent operational state, the second best choice for me
still is to make the problem clear and to describe the solution space.
This will help data modelers to understand the issue and pick one of
the solutions.

/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: Andy Bierman <[email-masked]>
Date: Wed, 16 Jun 2010 15:18:08 -0700

> This will help data modelers to understand the issue and pick one of

I do not think the NETCONF WG or the NETMOD WG has agreed
on any standard classifications for data nodes other than
the YANG config-stmt (=T/F).   If people think the NETCONF
operation set is wrong they should post comments on 4741bis.

As it stands, if the operator is allowed to alter the value
of a data node, it better be config=true.  If the operator
is never allowed to alter the value of operational data,
then it really is config=false, and it has to be returned
in a <get> operation.  We have known for years that
there is stuff that falls in between, and have always
decided not to bother doing anything about it.
Why it this the time, especially since YANG considered
this and rejected it, insisting that config-state is a boolean.

I don't think sec. 4.3 belongs in this Informational document.
If  any standard NETCONF behavior related to operational state
is ever done, then these definitions can be added then.

> /js

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 17 Jun 2010 01:17:07 -0400

>workshop attendees and thus my question remains valid.

I'll change "operator's needs" to "observations".

>are you saying that it is better to not document them?

Nope, just that I think this needs to be discussed in the
section dedicated to it, instead of an brief mention earlier
in the doc.

>attributes from with-defaults.

The other three options can be chosen and implemented within
the current NETCONF/YANG framework with little effort.  The
introduction of these attributes is not a valid choice for
the modeler.

In fact, the first option ("data models that explicitly differentiate
between configuration data and operational state data") is probably
the only realistic choice for modelers.

>This will help data modelers to understand the issue and pick one of

Given that we can't agree sufficiently to give guidance, how will
this section help the typical modeler.  This section reads more
like an apologist view of why this issue is hard and why we didn't
decide, but I'm not sure that has any real value to our audience.

Perhaps the best fix is to add a conclusion that gives the "explicitly
differentiated" as the only realistic current answer and push
modelers in this direction.

Thanks,
 Phil