Using the NETCONF Protocol over Secure Shell (SSH)
draft-ietf-netconf-rfc4742bis-08

[Ballot discuss]
In general I support publication of this document. However I would like to discuss the following issue before I can recommend its approval:

1) I support David's DISCUSS about lack of information about username extraction.

[Ballot comment]
I suspect I am disclosing my lack of netconf clue, but here goes:

Why is the example in section 4.2 (chunked encoding) declaring the base1.0 namespace?  I thought that base1.1 support is required of both the server and client to use chunked encoding...

[Ballot discuss]
In general I support publication of this document. However I would like to discuss the following issues before I can recommend its approval:

1) I support David's DISCUSS about lack of information about username extraction.

2)
3.1.  Capabilities Exchange

  The NETCONF server MUST indicate its capabilities by sending an XML
  document containing a  element as soon as the NETCONF session
  is established.  The NETCONF client can parse this message to
  determine which NETCONF capabilities are supported by the NETCONF
  server.

  The NETCONF client must also send an XML document containing a
    element to indicate the NETCONF client's capabilities to the
  NETCONF server.  The document containing the  element MUST be
  the first XML document that the NETCONF client sends after the
  NETCONF session is established.

These 2 paragraph look like they are repeating something already specified in the NETCONF spec itself,
which I think is misleading. If that is the case, then you need to make it clear that you are merely repeating requirements stated elsewhere, for example by writing "As specified in [NETCONF] ...".

3). Have you forgotten to register the new URN?

[Ballot comment]
This is updated to add two new comments from the SECDIR review.

#1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first paragraph be a "MUST"?

#2) Sec 4.2: Would any XML decoding error cause termination as stated at the end of 4.2? E.g. some unknown xmlns value or something?

#3) If it's worth changing the framing protocol at all, which I'm willing to accept as a given, it is far from obvious to me that the current negotiated upgrade is the right way to do it, as this will require implementation of the old bad mechanism forever.  Switching to a new SSH subsystem name seems like a much simpler solution.

#4) As a matter of stylistic consistency with the last several decades of Internet protocols, the delimiter sequence in the new framing protocol should have been , not .

[Ballot discuss]
This discuss position is not updated (but the comments are).

#1) You state a max for chunk-size in 4.2 but I think you need a MUST for what to do if a client or server sends something out-of-range (<=0 or >2^32-1). The idea is to get implementers not to leave buffer overrun vulnerabilities around. (Same thing for what to do if chunk-size does contain leading zeros, or is negative perhaps.) That may not be quite the same as saying "MUST terminate" at the very end of 4.2 if someone didn't consider the chunk-size part of the decoding process. Lastly, as a bit of a mad corner-case, if I send a chunk that's 2^32-2 long (which is allowed) and then another chunk that's 10 bytes, but both are the same XML element, i.e. the "" then is a server or client expected to be able to handle the overall  element that's 2^32+8 bytes long? Maybe just add text that implementations SHOULD include an upper-limit that ensures they're not vulnerable to buffer overruns or something.

#2) There's a mix of upper and lower case in the security considerations was this purposely done?  Specifically, it says "should" only be used with confidentiality. Maybe "SHOULD" is better there?  Also why isn't this a MUST?

[Ballot comment]
For the sake of clarity, I suggest changing " end tag" to " end tag" in Section 4.2.

Why do examples at the end of the Section 5 (top of page 9) contain LF? As far as I can see, those XML documents are not being chunked.

[Ballot discuss]
#1) You state a max for chunk-size in 4.2 but I think you need a MUST for what to do if a client or server sends something out-of-range (<=0 or >2^32-1). The idea is to get implementers not to leave buffer overrun vulnerabilities around. (Same thing for what to do if chunk-size does contain leading zeros, or is negative perhaps.) That may not be quite the same as saying "MUST terminate" at the very end of 4.2 if someone didn't consider the chunk-size part of the decoding process. Lastly, as a bit of a mad corner-case, if I send a chunk that's 2^32-2 long (which is allowed) and then another chunk that's 10 bytes, but both are the same XML element, i.e. the "" then is a server or client expected to be able to handle the overall  element that's 2^32+8 bytes long? Maybe just add text that implementations SHOULD include an upper-limit that ensures they're not vulnerable to buffer overruns or something.

#2) There's a mix of upper and lower case in the security considerations was this purposely done?  Specifically, it says "should" only be used with confidentiality. Maybe "SHOULD" is better there?  Also why isn't this a MUST?

[Ballot comment]
#1) Sec 3.1: 2nd para, 1st sentence: Should the "must" in the first paragraph be a "MUST"?

#2) Sec 4.2: Would any XML decoding error cause termination as stated at
the end of 4.2? E.g. some unknown xmlns value or something?

[Ballot discuss]
#1) You state a max for chunk-size in 4.2 but I think you need a
MUST for what to do if a client or server sends something
out-of-range (<=0 or >2^32-1). The idea is to get implementers not
to leave buffer overrun vulnerabilities around. (Same thing
for what to do if chunk-size does contain leading zeros, or is
negative perhaps.) That may not be quite the same as saying "MUST
terminate" at the very end of 4.2 if someone didn't consider the
chunk-size part of the decoding process. Lastly, as a bit of a
mad corner-case, if I send a chunk that's 2^32-2 long (which is
allowed) and then another chunk that's 10 bytes, but both are
the same XML element, i.e. the "" then is a server or
client expected to be able to handle the overall  element
that's 2^32+8 bytes long? Maybe just add text that implementations
SHOULD include an upper-limit that ensures they're not vulnerable
to buffer overruns or something.

#2) There's a mix of upper and lower case in the security considerations was this purposely done?  Specifically, it says "should" only be used with confidentiality. Maybe "SHOULD" is better there?  Also why isn't this a MUST?

[Ballot discuss]
1) 4741bis says: "The authentication process MUST result in an authenticated client
  identity whose permissions are known to the server.  The
  authenticated identity of a client is commonly referred to as the
  NETCONF username.  The algorithm used to derive the username is
  transport protocol specific and in addition specific to the
  authentication mechanism used by the transport protocol.  NETCONF
  transport protocols therefore MUST explain how a NETCONF username is
  derived from the authentication mechanisms supported by the transport
  protocol.

  The access permissions of a given client, identified by its NETCONF
  username, are part of the configuration of the NETCONF server.  These
  permissions MUST be enforced during the remainder of the NETCONF
  session.  The details how access control is configured is outside the
  scope of this document."

4742bis says: "How the NETCONF Server extracts the SSH user name from the SSH layer
  is implementation-dependent."

This is not an explanation. Assuming an operator must specify access control rights for a user in the configuration o fthe server, it is important that the operator understands what the netconf username(s) will be. That is presumably why it is important for the Netconf transport protocol specification to explain the algorithm for deriving the username.

RFC5592 defines an SSH subsystem for use with SNMP, and has had to deal with similar issues, including constraints about not changing the username associated with a session, allowing "user@host" style naming, etc.
Maybe those are not needed for netconf, but the above "implementation-dependent" explanations seems woefully inadequate.

[Ballot comment]
I suspect I am disclosing my lack of netconf clue, but here goes:

Why is the example in section 4.2 (chunked encoding) declaring the base1.0 namespace?  I thought that base1.1
support is required of both the server and client to use chunked encoding...

IANA understands that, upon approval of this document, two IANA Actions
are required to be completed.

First, in the IANA Port Numbers registry located at:

http://www.iana.org/assignments/port-numbers

The reference for port number 830 will be updated to [RFC-to-be]

netconf-ssh 830/tcp NETCONF over SSH
netconf-ssh 830/udp NETCONF over SSH
show quoted text
# [RFC-to-be]

Second, in the Connection Protocol Subsystem Names subregistry of the
Secure Shell (SSH) Protocol Parameters registry located at:

http://www.iana.org/assignments/ssh-parameters

the entry for netconf will be updated to reference [RFC-to-be] as follows:

Registry Name: Connection Protocol Subsystem Names
Reference: [RFC4250]
Registration Procedures: IETF Consensus

Registry:
Subsystem Name Reference
------------------------------ ---------
publickey [RFC4819]
snmp [RFC5592]
netconf [RFC-to-be]

IANA understands that these are the only IANA Actions required upon
approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Using the NETCONF Configuration Protocol over Secure Shell (SSH)) to Proposed Standard


The IESG has received a request from the Network Configuration WG
(netconf) to consider the following document:
- 'Using the NETCONF Configuration Protocol over Secure Shell (SSH)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc4742bis/

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

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


(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 is only one outdated reference (for
draft-ietf-netconf-4741bis).


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

      There is no data model in this document.


(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 Working Group.
      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. The workgroup agrees that this issue should be solved
      with an additional framing, which would lead to a new version
      incompatible with version v1.0. As described in the Security
      Considerations section the EOM sequence can cause operational
      issues however the workgroup believes the associated threat is
      not very high.  As the workgoup has only a mandate for bug fixing
      the document keeps using the EOM sequence to avoid
incompatibility

      with existing implementations.



      Document Quality

      Are there existing implementations of the protocol? Have a
      significant number of vendors indicated their plan to
      implement the specification? Are there any reviewers that
      merit special mention as having done a thorough review,
      e.g., one that resulted in important changes or a conclusion
      that the document had no substantive issues? If there was a
      MIB Doctor, Media Type or other expert review, what was its
      course (briefly)? In the case of a Media Type review, on
      what date was the request posted?

      Since SSH is mandatory transport for NETCONF there are numerous
      implementations of RFC 4742. 4742bis is doing only bug fixing and

      existing implementations can be updated once 4742bis becomes
      proposed standard.


Mehmet Ersue
Document Shepherd

State changed to AD is watching from Publication Requested.
At the request of the WG chairs the AD is watching while the WG debates the solution to the EOM problem which may lead to a revised ID.

Document write-up from shepherd Mehmet Ersue:

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


(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 is only one outdated reference (for draft-ietf-netconf-4741bis).
 

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

      There is no data model in this document.


(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 Working Group.
      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. The workgroup agrees that this issue should be solved
      with an additional framing, which would lead to a new version
      incompatible with version v1.0. As described in the Security
      Considerations section the EOM sequence can cause operational
      issues however the workgroup believes the associated threat is
      not very high.  As the workgoup has only a mandate for bug fixing
      the document keeps using the EOM sequence to avoid incompatibility
      with existing implementations.



      Document Quality

      Are there existing implementations of the protocol? Have a
      significant number of vendors indicated their plan to
      implement the specification? Are there any reviewers that
      merit special mention as having done a thorough review,
      e.g., one that resulted in important changes or a conclusion
      that the document had no substantive issues? If there was a
      MIB Doctor, Media Type or other expert review, what was its
      course (briefly)? In the case of a Media Type review, on
      what date was the request posted?

      Since SSH is mandatory transport for NETCONF there are numerous
      implementations of RFC 4742. 4742bis is doing only bug fixing and       
      existing implementations can be updated once 4742bis becomes
      proposed standard.