Subject: [Netconf] FW: Request to consider draft-ietf-netconf-4742bis-06 for publication as PS RFC

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 27 Jan 2011 12:18:10 +0100

Hi All,

since there were no additional comments, 4742bis is now back 
in AD review.

Cheers, 
Mehmet 

_____________________________________________
From: Ersue, Mehmet (NSN - DE/Munich) 
Sent: Thursday, January 27, 2011 12:15 PM
To: [email-masked]
Cc: Bert (IETF) Wijnen
Subject: Request to consider draft-ietf-netconf-4742bis-06 for
publication as PS RFC

Hi Dan, 

thank you for giving us some more time to fix the issue 
with the unsecure EOM.
We think v06 of the 4742bis now solves the issue and has 
near full WG consensus. The new document write-up contains 
a detailed summary of the WG discussion.

http://tools.ietf.org/html/draft-ietf-netconf-rfc4742bis-06 

Please find below the updated document write-up.

Mehmet Ersue
Document shepherd

------------------------------------------------------------------------
---

(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 Shepard 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 Bert Wijnen, Andy Bierman, Phil Shaefer,
     Martin Bjorklund, Lada Lothka, Wes Hardaker, Tom Petch, Ken 
     Watson, and Juergen Schoenwaelder. 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 split references into normative and informative. 

(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. The draft 
      requests to update the allocations, which have been done 
      for RFC 4742.

(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 ABNF rules for the chunked framing mechanism are correct 
      and follow RFC5234. 

(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 describes a method for invoking and running 
      the NETCONF protocol within a Secure Shell (SSH) session 
      as an SSH subsystem.

      Working Group Summary  

      This 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 WG. 
      The document incorporates all accepted errata against RFC4742.
After a 
      long debate the WG decided to have the way a NETCONF Server
extracts 
      the SSH user name from the SSH layer as implementation-dependent.
      
      There was a long discussion on the handling of the EOM character
sequence. 
      As the workgroup had only a mandate for bug fixing the workgroup
first 
      agreed to keep using the EOM sequence to avoid incompatibility
with existing 
      implementations. After the discussion on this issue in IETF #79 a
few WG 
      members proposed to figure out if a proper framing solution can be
found 
      now, while being backwards compatible with the rfc4742. 

      The old EOM framing has been seen as not secure enough:
      - RFC4742 assumes that the EOM sequence, ]]>]]>, cannot appear in
any 
      well-formed XML document, which turned out to be mistaken.  
      - The EOM sequence can cause operational problems and open space
for 
      attacks if sent deliberately in RPC messages.

      NETCONF co-chairs agreed to consider a solution only if there is a
real WG 
      consensus (i.e. near 100%) on such a change. First a possible
solution has 
      been discussed in a small team, which included most of the
implementers 
      for NETCONF-related tools and protocol code. The solution proposes
to 
      encode all NETCONF messages with a chunked framing (similar but
not equal 
      to HTTP chunked framing). The document still uses the EOM sequence
for the 
      initial <hello> message to avoid incompatibility with existing
implementations.  

      NETCONF co-chairs asked the AD to hold the documents for 4741bis
and 
      4742bis for a short period of time and the result of the
discussion in the small 
      team has been sent to the WG for consensus. 

      Some of the discussion points were:
      - The proposal makes it a little bit harder to do just an
SSH-session and then do 
      cut-and-paste input. The implementers believe that the proposed
solution for 
      proper/decent framing is acceptable and that most implementation
can/will 
      provide a simple scripting front-end to allow for some form of
cut-and-paste.
      - It came out that less experienced implementers find it as
helpful to see the 
      "invisible LineFeed" in the examples. The WG concluded that '\n'
is the most 
      common character for this purpose. One WG member though was
against '\n' 
      and wanted to use '}', which has been noted.
      - One WG member didn't want to stick the usage of the Chunked
Framing 
      Mechanism to capability "base:1.1" only and wanted rather to state
":base:1.1 
      or later". The WG concluded that we should stick to "base:1.1" and
extend it 
      with a new version, which most likely will introduce other
changes. 
      
      The changes have been accepted by the WG with some additional
discussion 
      and bug fixing. As the result of the WG discussion the WG
co-chairs concluded 
      near FULL consensus on the proposed edits and started a WGLC. The
WGLC 
      did raise only minor issues. After a short discussion in a small
team including 
      the WG co-chairs, the editor of 4742bis Margaret Wasserman,
editors of 4741bis 
      Martin Bjorklund, Andy Bierman and Juergen Schoenwaelder the
document 
      shepherd sent the collected bug fixing and change requests to
NETCONF ML 
      and announced it as the result of the WG last call. 
 
      Document Quality 

      Since SSH is mandatory transport for NETCONF there are numerous
      implementations of RFC 4742. It is expected that existing
implementations 
      will be updated based on the 4742bis document once it gets
published as 
      proposed standard.

Mehmet Ersue
Document Shepherd