Subject: [Netconf] FW: [www.ietf.org/rt #42804] AutoReply: Request to consider <draft-ietf-netconf-system-notifications> for publication as PS RFC

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 4 Nov 2011 16:05:34 +0100

FYI

Mehmet 

-----Original Message-----
From: ext IETF-IESG via RT [mailto:[email-masked]] 
Sent: Friday, November 04, 2011 3:28 PM
To: Ersue, Mehmet (NSN - DE/Munich)
Subject: [www.ietf.org/rt #42804] AutoReply: Request to consider <draft-ietf-netconf-system-notifications> for publication as PS RFC 

Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
	"Request to consider <draft-ietf-netconf-system-notifications> for publication as PS RFC", 
a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [www.ietf.org/rt #42804].

Please include the string:

         [www.ietf.org/rt #42804]

in the subject line of all future correspondence about this issue. To do so, 
you may reply to this message.

                        Thank you,
                        [email-masked]

-------------------------------------------------------------------------
Hi Dan, 

based on the consensus in the NETCONF WG and as discussed with 
my co-chair and the author of the draft NETCONF Base Notifications
we think that we are ready to bring the document to the next step.

I would like to please you to initiate the necessary process for 
the publication of draft-ietf-netconf-system-notifications (Network 
Configuration Protocol (NETCONF) Base Notifications).

Please find below the document write-up for 
http://tools.ietf.org/html/draft-ietf-netconf-system-notifications-06.

Thank you.

Best Regards,
Mehmet Ersue - Netconf co-chair and document-shepherd
Bert Wijnen - NetConf co-chair

 <<111104_NETCONF-Base-Notif-Doc-Writeup.txt>> 
[same text as attachment]

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

     I, Mehmet Ersue, am the Document Shepherd for this document. 
     I have personally reviewed this version of the document and I 
     believe it is ready for publication. 
      
     Adequate review has occurred from WG members, and it has been 
     reviewed especially by Martin Bjorklund, Muthumayan Madhayyan, 
     Randy Presuhn, Dan Romascanu, Phil Shaefer, Juergen Schoenwaelder, 
     Kent Watson, and Bert Wijnen. The issues raised in the reviews have

     been discussed on the mailing list and fixed in the last versions. 

(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 adequate review from working group and 
      non-working group members, mostly from NETCONF and NETMOD WGs.  
      I do not have any concerns about the depth or breadth of review.

(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? 
 
      No. 
 
(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.

      There are no concerns about the technical merit of the document. 
      There are no IPR disclosures filed on this document.

(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? 
  
      There is strong consensus in the WG to publish this document.

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

(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? 
      
      Yes. There are no nits in this draft.

(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]. 
 
      The document has only normative references. 

(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 complete and consistent with RFC 3688.
     The draft requests to register one XML namespace URN and one 
      module name in the 'YANG Module Names' registry.

(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 YANG module in the document has been checked for validity. 

(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  

      This document defines a YANG module that allows a NETCONF client 
      to receive notifications for some common system events. As such 
      the document supports the monitoring of base system events within 
      the NETCONF server.  

      Working Group Summary  

      The document has been longly discussed in the Working Group, 
      including several WG Last Calls. The comments and reviews helped 
      to improve the document a lot and the current version reflects the

      consensus of the Working Group. 
      There was some debate on the scope of the draft. Kent Watsen was
      the only person who proposed the document to cover a much bigger 
      scope. The system-startup notification has been removed after some

      discussion.   
      The last WGLC did raise only minor issues. The changes have been 
      accepted by the WG with some additional discussion and bug fixing.

      Document Quality 

      It is expected that NETCONF implementations will be extended once 
      this document gets published as proposed standard.

Mehmet Ersue
Document Shepherd