Subject: Re: Last Call: 'NETCONF Configuration Protocol' to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Nov 2005 16:25:53 +0200 (EET)

On Wed, 23 Nov 2005, The IESG wrote:
> The IESG has received a request from the Network Configuration WG to consider
> the following documents:
>
> - 'NETCONF Configuration Protocol '
>   <draft-ietf-netconf-prot-09.txt> as a Proposed Standard
> - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) '
>   <draft-ietf-netconf-ssh-05.txt> 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 any comments to the
> [email-masked] or [email-masked] mailing lists by 2005-12-07.

I have just browsed through the main spec, because of its length.

There is one potential procedural with it, as one normative reference:

    [5]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
         Unifying Syntax for the Expression of Names and Addresses of
         Objects on the Network as used in the World-Wide Web", RFC 1630,
         June 1994.

.. is Informational.  The rules have been stretched now and then 
(e.g., when referring to hash functions defined in informational RFCs 
but the function is really defined by some external document), not 
sure if this is one similar case.  Maybe a different ref would be 
findable on URIs?

...

As a comment on section 3 of the SSH spec,

     In order to allow NETCONF traffic to be easily identified and
     filtered by firewalls and other network devices, NETCONF servers MUST
     default to providing access to the "netconf" SSH subsystem only when
     the SSH session is established using the IANA-assigned TCP port
     <TBD>.  Servers SHOULD be configurable to allow access to the netconf
     SSH subsystem over other ports.

.. is this something that has already been implemented?  Is there 
experience that such a restriction is practical to implement?  It'd 
seem this would require running two different instances of sshd (with 
different configuration wrt subsystems) or pretty complex policies 
with just one process.  I'm not against this approach -- I'd just like 
to be sure there's implementer commitment to actually do so..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 29 Nov 2005 18:46:00 -0500

On the first point:

Pekka Savola wrote:
> .. is Informational.  The rules have been stretched now and then (e.g., 
> when referring to hash functions defined in informational RFCs but the 
> function is really defined by some external document), not sure if this 
> is one similar case.  Maybe a different ref would be findable on URIs?
> 

Is it really really necessary to refer back to RFC1630?    RFC3986
is the current URI syntax document, and has the benefit of
being standards-track.  Since the reference seems to be for the
purpose of "defining" the URI, surely the (current) syntax document
would be appropriate?

Leslie.