Subject: [Netconf] Request to publish draft-ietf-netconf-partial-lock-07 as Proposed Standard RFC

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Mon, 9 Mar 2009 13:44:38 +0100

Dan, please take this document to the next step. The WG has consensus
to request publication as a Proposed Standard RFC.

Document Shepherd Write-Up for draft-ietf-netconf-partial-lock-07. 
Template used was dated September 17, 2008.

    (1.a) Who is the Document Shepherd for this document? Has the 
          Document Shepherd personally reviewed this version of the 
          document and, in particular, does he or she believe this 
          version is ready for forwarding to the IESG for publication?

  Bert Wijnen is the document shepherd. 
  Yes, I have reviewed the document many times, including this version
  7, that I believe is ready for forwarding to the AD/IESG.

    (1.b) Has the document had adequate review both from key WG members 
          and from key non-WG members? Does the Document Shepherd have 
          any concerns about the depth or breadth of the reviews that 
          have been performed?

  The document has had wide review and re-reviews of NETCONF WG members
  and also from others. I do not have any concerns regarding the level
  of review for this document.

    (1.c) Does the Document Shepherd have concerns that the document 
          needs more review from a particular or broader perspective, 
          e.g., security, operational complexity, someone familiar with 
          AAA, internationalization or XML?

  I do not believe any extra special review (other than normal IETF
  Last Call) is needed.

    (1.d) Does the Document Shepherd have any specific concerns or 
          issues with this document that the Responsible Area Director 
          and/or the IESG should be aware of? For example, perhaps he 
          or she is uncomfortable with certain parts of the document, or 
          has concerns whether there really is a need for it. In any 
          event, if the WG has discussed those issues and has indicated 
          that it still wishes to advance the document, detail those 
          concerns here. Has an IPR disclosure related to this document 
          been filed? If so, please include a reference to the 
          disclosure and summarize the WG discussion and conclusion on 
          this issue.

  I do not have any specific concerns.
  No IPR disclosure been filed as far as we know.

    (1.e) How solid is the WG consensus behind this document? Does it 
          represent the strong concurrence of a few individuals, with 
          others being silent, or does the WG as a whole understand and 
          agree with it?

  The document has WG consensus and the WG wants the document to be
  published as a Proposed Standard.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
          discontent? If so, please summarise the areas of conflict in 
          separate email messages to the Responsible Area Director. (It 
          should be in a separate email because this questionnaire is 
          entered into the ID Tracker.)

  No-one has threatened with an appeal or expressed extreme discontent.

    (1.g) Has the Document Shepherd personally verified that the 
          document satisfies all ID nits? (See 
          http://www.ietf.org/ID-Checklist.html and 
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
          not enough; this check needs to be thorough. Has the document 
          met all formal review criteria it needs to, such as the MIB 
          Doctor, media type and URI type reviews?

  Document passes ID-nits (as shown by the IETF idnits tool:
     http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/
          draft-ietf-netconf-partial-lock-07.txt)

    (1.h) Has the document split its references into normative and 
          informative? Are there normative references to documents that 
          are not ready for advancement or are otherwise in an unclear 
          state? If such normative references exist, what is the 
          strategy for their completion? Are there normative references 
          that are downward references, as described in [RFC3967]? If 
          so, list these downward references to support the Area 
          Director in the Last Call procedure for them [RFC3967].

  References are split in Normative and Informative. All normative
  documents have been published.

    (1.i) Has the Document Shepherd verified that the document IANA 
          consideration section exists and is consistent with the body 
          of the document? If the document specifies protocol 
          extensions, are reservations requested in appropriate IANA 
          registries? Are the IANA registries clearly identified? If 
          the document creates a new registry, does it define the 
          proposed initial contents of the registry and an allocation 
          procedure for future registrations? Does it suggest a 
          reasonable name for the new registry? See [RFC5226]. If the 
          document describes an Expert Review process has Shepherd 
          conferred with the Responsible Area Director so that the IESG 
          can appoint the needed Expert during the IESG Evaluation?

  IANA considerations are present and complete. No new namespaces are
  created and so no new Expert is needed.

    (1.j) Has the Document Shepherd verified that sections of the 
          document that are written in a formal language, such as XML 
          code, BNF rules, MIB definitions, etc., validate correctly in 
          an automated checker?

  The XSD section has been checked by Mehmet Ersu (co-chair of the WG)
  and has been found to be valid.

    (1.k) The IESG approval announcement includes a Document 
          Announcement Write-Up. Please provide such a Document 
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval 
          announcement contains the following sections:

          Technical Summary 

             The NETCONF protocol defines the lock and unlock RPCs,
             used to lock entire configuration datastores.  In some
             situations, a way to lock only parts of a configuration
             datastore is required.  This document defines a
             capability-based extension to the NETCONF protocol for
             locking portions of a configuration datastore.

          Working Group Summary 

             The working group went over several versions of the 
             document. The comments and reviews helped improve the
             document a lot and brought us to consensus on the
             7th revision of the docuemnt.

          Document Quality
             There are prelimenary implementations of this protocol    
             and updates to comply with this spec are in plan. Others
             are planning to implement this spec too.

Bert Wijnen
Document Shepherd