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

[Phil Shafer <[e-mail]>]

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