[Resend -- original copy did not show up in mailing list archive, 
but has already been replied to by Phil.]

I have been selected as the Applications Area Review Team reviewer for
draft-ietf-netmod-arch (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netmod-arch-09.txt
Reviewer: Carsten Bormann
Review Date: 2010-09-22
IETF Last Call Date: 2010-07-22 (draft-ietf-netmod-arch-07.txt)
IESG Telechat Date: 2010-09-23

SUMMARY: This draft is almost ready for publication as an
Informational RFC.  I believe the technical material is a sound
introduction and roadmap to the standards-track documents, and only a
few minor potential improvements remain.

MAJOR ISSUES:

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

MINOR ISSUES:

* Technical

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

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.

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

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

* Editorial

The draft is written in a clear and pleasant manner.
Not being a native speaker, I'm not going to try to review for style.
(A couple of editorial suggestions, including typos/grammar fixes,
have been sent directly to the author.)

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).
-- it references an ietf@ietf.org 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.

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

Apparently due to Lars Eggert's quite reasonable ballot comment, the
Introduction is no longer called Introduction (this upsets ID-Nits and
maybe later the RFC editor).

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?

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

* Relevant ID-nits comments

 Miscellaneous warnings:
 ----------------------------------------------------------------------------

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

 Checking references for intended status: Informational
 ----------------------------------------------------------------------------

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