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

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jun 16, 2010 at 09:40:16PM +0200, Phil Shafer wrote:
> 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.
 
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.

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

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?

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

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.

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

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: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>