Re: [apps-discuss] apps-team review of draft-ietf-netmod-arch

[Phil Shafer <[e-mail]>]

Carsten Bormann writes:
>I have been selected as the Applications Area Review Team reviewer

Thank you for your review.

>Section 3.2, which reads like a list of selling points, is somewhat
>opaque (e.g., what is the semantics of "text-friendly"?) and contains
>some statements that are not supported by the rest of the document.

"text-friendly" means I can use the text-oriented tools mentioned
in RFC3535 ("can be made with arbitrary text processing tools",
"text processing tools such as diff, and version management tools
such as RCS or CVS, can be used to process configurations").  The
ability to post a diff or brief section of a module to a mailing
list is also crucial.  By comparison, binary protocols are not
friendly to these tools, and posting a diff of a binary file would
not be friendly.

>Where does the list of item headings come from?  (Not from RFC 3535,
>e.g. section 5, which would be a natural source.)  A better
>introduction might adjust the expectations of the reader to fit what
>is there now.

The headers are based on 3535, but in a more brief format, e.g. "Dump
and restore" instead of:

   7.  A mechanism to dump and restore configurations is a primitive
       operation needed by operators.  Standards for pulling and pushing
       configurations from/to devices are desirable.

>But sentences such as:
>
>       NETCONF and YANG are solid and reliable technologies.
>
>simply are not RFC material (even if my personal opinion does happen
>to agree).

Perhaps "NETCONF and YANG are designed to be robust and reliable
technologies, with attention paid to real world use case and
operator scenarios."?

>For me, the introduction appears slightly optimistic about the value
>of data modeling languages -- "A client knows how to create valid data
>for the server, and knows what data will be sent from the server.  A
>server knows the rules that govern the data and how it should behave."
>Of course, this can only be true within the limits of what the data
>modeling language can describe (or more precisely: the limits of what we
>can expect modelers to be able to describe through this language).

I see this as a more generic description, not an optimistic one.  We
build models to describe not only the domain being modeled but the
interactions between parties manipulating elements of those models.
The model tries to fully describe the domain in a way that removes
surprises from that interaction.  If the model says a leaf is an
integer, then neither side should feel that "cow" is an acceptable
value.

>(And this, BTW, is exactly the most important reason why a data
>modeling language benefits from being adapted to the problem domain; a
>reason not otherwise given in the introduction.)

This is mentioned:

    The use of NETCONF operations
    place requirements on the data content that are not shared with the
    static document problem domain addressed by schema languages like XSD
    or Relax NG.

>The Description for "delete-config" in the table of operations says:
>    Delete a portion of a configuration datastore
>To me, section 7.4 of RFC 4741 reads as if the operation can be used
>to delete an entire configuration datastore.

Good catch.  I was thinking of the delete attribute, not the RPC.
Will fix.

>The XML example in 2.2.3 misses the namespace declaration for the
>namespace prefix "vendorx".  [Have all examples been validated?]

Will fix.

>Section 2.3.2 mentions RELAX NG in the title and is then silent about
>that in the text.  Contrary to the second paragraph, DSDL is a
>*family* of schema languages, not a single standard (and
>draft-ietf-netmod-dsdl-map-07.txt does address the family, not just
>RELAX NG).

DSDL includes Relax NG, and Relax NG has far better name recognition,
so it was added in parens.  I can add text to fully describe this
relationship.

>We dont have a good way to reference the genesis of an IETF activity
>in RFCs.  This draft makes two mistakes in handling this difficult =
>problem:
>-- it references an expired Internet-Draft by just giving a draft
>   name (draft-presuhn-rcdml-03.txt).  There is no really good
>   solution to this problem (except turning this document into another
>   RFC, which the WG may have decided not to do).

This is an unfortunate side effect of allowing drafts to expire.
Is there a more proper way to reference this?  I was to at least
give something an interested reader can google to get complete
information.

>-- it references an [e-mail] email message by giving a URI to a
>   random mail archiving site.  This message, if it is as useful for
>   this document as it seems to be, should be either cited through its
>   ietf.org URI
>   (http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html)
>   or, preferably (if the message author concurs), it should instead
>   be replicated in an annex.

I'll correct the URL.  The message is merely a historical note
and is not worth replicating IMHO.

>Is the intention to publish this document in a cluster with the
>referenced documents:
>-- [RFCYANG] draft-ietf-netmod-yang-13,
>-- [RFCYANGDSDL] draft-ietf-netmod-dsdl-map-06,
>-- [RFCYANGTYPES] draft-ietf-netmod-yang-types-09.txt, and
>-- [RFCYANGUSAGE] draft-ietf-netmod-yang-usage-10.txt?
>If not, the reference labels should probably not be called "RFCXXX".

Yes, and I believe all these documents are in last call.

>Section 1: "This brings NETCONF to a point where is can be used to
>develop standards within the IETF." -- I assume this statement is
>about data model standards?  Or what kind of standard?

Yes, standards that contain data models.  I'll correct it to
"standard data models".

>Section 3.3.3.2 entraps itself by first using "over the wire" and then
>having to add a strange retraction that in fact the wire will only see
>encrypted material.  But the point here is not the wire, but the fact
>that NETCONF implementations can "ascertain whether a specific NETCONF
>payload is obeying the rules".  Strike the "over the wire".

Changed to "XML encoding for data sent via NETCONF."

>  -- The document has a disclaimer for pre-RFC5378 work, but was first
>     submitted on or after 10 November 2008.  Does it really need the
>     disclaimer?

I was surprised that id-nits complains about this, but work predates
200902.  Please let me know if there's a more appropriate setting than
the current one (<rfc ipr="pre5378Trust200902" ...).

>  =3D=3D Outdated reference: A later version (-07) exists of
>     draft-ietf-netmod-dsdl-map-06

A consequence of the number of drafts the WG is producing.

Thanks,
 Phil