[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
iesg@ietf.org or ietf@ietf.org 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 netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>