Subject: [Netconf] review of draft-ietf-netconf-rfc5539bis-03.txt

From: Martin Bjorklund <[email-masked]>
Date: Wed, 22 May 2013 20:27:58 -0700 (PDT)

Hi,

I have reviewed this document and have some (mostly minor) comments:

  o  2.4.1

    First paragraph says:

      "Particularly, the NETCONF client MUST check its understanding of the
      NETCONF server hostname"

    And last paragraph says:

      "If the NETCONF client has external information as to the expected
      identity of the NETCONF server, the hostname check MAY be
      omitted."

    First of all, it is not sure what "the hostname check" refers to?

    Second, if it refers to the first paragraph, it seems to be a
    contradiction.

  o  2.4.2.1

     s/cert-map list/cert-to-name list/

  o  3

     s/This organizations/This organization/

  o  leaf psk-identity

     This leaf says how a PSK identity MAY be encoded in UTF-8.

     How will a NETCONF client know how a server will encode a certain
     PSK identity, so that the NETCONF client can create a matching
     entry in the list?

  o  leaf not-valid-after

     s/not valid before/not valid after/

  o  5.1 & 5.2

     The prefix x509c2n is not defined, should be:

       xmlns:x509c2n=
         "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name"

     e.g. in the <netconf> element.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 23 May 2013 08:04:49 +0200

>     Second, if it refers to the first paragraph, it seems to be a

Yes. Note that this contradiction is copied from RFC 5539. I have
written down a TODO item on this since we might have to work on this
text anyway for call-home.
 
>      s/cert-map list/cert-to-name list/

fixed

>      s/This organizations/This organization/

fixed

>      PSK identity, so that the NETCONF client can create a matching

What about this:

             "The PSK identity encoded as a UTF-8 string. For
              details how certain common PSK identity formats can
              be encoded in UTF-8, see section 5.1. of RFC 4279.";

RFC 4279 is not very detailed, covering only two trivial cases and the
DNS name case somewhat superficially.
 
>      s/not valid before/not valid after/

fixed

>      e.g. in the <netconf> element.

fixed in 5.1, section 5.2 does not use the x509c2n prefix

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>