Subject: [Netconf] Barry Leiba's No Objection on draft-ietf-netconf-rfc5539bis-09: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 23 Mar 2015 16:50:53 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-netconf-rfc5539bis-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Section 5 --

   presented X.509 certificate may also be considered valid if it
   matches a locally configured certificate fingerprint.  If X.509
   certificate path validation fails and the presented X.509 certificate
   does not match a locally configured certificate fingerprint,

It's probably worth it here to allow for things such as DANE, by slightly
changing the wording.  what do you think of this, perhaps?:

NEW
   presented X.509 certificate may also be considered valid if it
   matches one obtained by another trusted mechanism, such as
   using a locally configured certificate fingerprint.  If X.509
   certificate path validation fails and the presented X.509 certificate
   does not match a certificate obtained by a trusted mechanism,
END

Does something like that make sense?  Or is it better to limit it to
preconfigured certs?

-- Section 7 --

        Similarily, if the
        username does not comply to the NETCONF requirements on
        usernames [RFC6241] (i.e., the username is not representable in
        XML)

Checking: Is "not representable in XML" really the only way the username
would not comply?  That is, is "i.e." correct here, or do you mean
"e.g."?

-- Section 9 --

   If third-
   party authentication is needed, the SSH transport can be used.

Very small point: you have four citations to 6242 in two paragraphs in
Section 3, but none here.  This would probably be a good place to stick
another citation.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Mar 2015 18:29:30 +0100

I think your rewording suggestion makes a lot of sense in order to
future proof things.
 
> would not comply?  That is, is "i.e." correct here, or do you mean

My counter proposal is to simply remove the text in the parenthesis
entirely, implementors lookup what RFC6241 says anyway.

> Section 3, but none here.  This would probably be a good place to stick

Sure, this is easy to add.

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