Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)
draft-ietf-netconf-beep-10

[Ballot discuss]
(Based on Gen-ART review by Elwyn Davies)

The base NETCONF protocol spec talks about 'client/server' instead of 'manager/agent'. This document uses 'manager/agent' but needs to be
consistent with the base spec.

The base NETCONF protocol spec requires (in section 2):

>    The transport protocol MUST provide a mechanism to indicate the
>    session type (client or server) to the NETCONF protocol layer.

So where does the BEEP mapping do this? If that isn't defined,
it's a bug.

[Ballot discuss]
Please add a bit to the discussion of the server certificate in the
  Security Considerations section.  I do not think that the client
  ought to accept configuration information from any party that has a
  certificate that can be validated to the trust anchor.  What subject
  name should the client expect in the server certificate?  Does this
  lead to a bit of configuration information that needs to in place
  before NETCONF can be used securely.

IANA Last Call Comments:
Upon approval of this document the IANA will register the beep profile
http://iana.org/beep/netconf in the following registry:
http://www.iana.org/assignments/beep-parameters

A TCP port number for NETCONF will also be registered in the following registry:
http://www.iana.org/assignments/port-numbers
In which range should this port number be registered?

AD review (see below) posted to the WG list.
Checking with WG chairs on next step.

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Wijnen, Bert (Bert)
Sent: Friday, July 29, 2005 21:20
To: Eliot Lear (E-mail); kcrozier@cisco.com
Cc: Netconf (E-mail)
Subject: AD review for: draft-ietf-netconf-beep-05.txt


Here is my complete review for this document.
Basically ready for IETF Last Call.
Pls take a look at my comments and let me know if you want
to respin a revision first.

Bert

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

AD review for: draft-ietf-netconf-beep-05.txt

- I think that there is one more IANA action, and that is the
  registration for the netconf BEEP profile as described in
  sect 2.5

nits/typos:

- It is best (RFC Editor will do it, but better do it
  ourselves) to expand acronyms when they are used for
  the first time.

- I find it a bit rude to state in IANA considerations
  "IANA will assign". I would rather state "IANA is requested
  to assign".

Checking the references and citations I get:

  !! Missing citation for Informative reference:
  P011 L042:    [10]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the

  !! Missing citation for Informative reference:
  P011 L046:    [11]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote



IDNIITS shows thie following (I Think that is acceptable for now):

$ idnits draft-ietf-netconf-beep-05.txt
idnits 1.74

draft-ietf-netconf-beep-05.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:
    Checking conformance with RFC 3978/3979 boilerplate...
    the boilerplate looks good.
  * There are 41 instances of too long lines in the document, the
    longest one being 1 character in excess of 72.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  - It seems as if not all pages are separated by form feeds - found 0
    form feeds but 14 pages

  Miscellaneous warnings:
    None.

    Run idnits with the --verbose option for more detailed information.