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

From: "Kathleen Moriarty" <[email-masked]>
Date: Sat, 04 Apr 2015 17:55:56 -0700

Kathleen Moriarty 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:
----------------------------------------------------------------------

I found the discussion on the SecDir review interesting, so thanks for
the more detailed explanations.  I do agree that the draft already does
state that this is a certificate fingerprint, but don't see (maybe point
me to where it is if I missed it), that this is all local, per:
https://www.ietf.org/mail-archive/web/secdir/current/msg05526.html

I'm wondering why the yang model that was spilt out into another draft
isn't referenced as that would be helpful as well (last 2 paragraphs of
Tom's response):
https://www.ietf.org/mail-archive/web/secdir/current/msg05524.html

This is non blocking as I'd like to figure out if it's helpful to avoid
questions and link drafts where appropriate (unless I missed something).

Thanks,
Kathleen

---

From: t.petch <[email-masked]>
Date: Mon, 6 Apr 2015 12:33:53 +0100

----- Original Message -----
From: "Kathleen Moriarty" <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>;
<[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Sunday, April 05, 2015 1:55 AM

Kathleen

Yes.

Perhaps Netconf and YANG is one of those areas which, if you have not
followed the last 12 years of discussion, you never will quite
understand:-(

Netconf started out with SSH, SOAP and BEEP.  It gained TLS, got reverse
SSH, lost SOAP and BEEP, TLS added 'reverse', 'reverse' was renamed
'call home', it gained a Netconf server YANG model, TLS gained and lost
a YANG model, it added RESTCONF and RESTCONF call home.  Along the way,
TLS gained and lost PSK while SSH acquired certificates.

The current I-D structure was agreed in July 2014 and owes something to
engineering, something to history!  Currently it is netconf-5539bis,
netconf-server-model, netconf-call-home, netconf-restconf and
netconf-zerotouch (with a variety of authors, a variety of target
completion dates and, perhaps, a wish to limit inter-dependencies).

The issue of how to authenticate a client and derive an identifier for
it is awkward and not often tackled in the IETF (which tends to be more
concerned with server authentication and HTTP - this was an issue when
adding SSH/TLS to SNMP, as well); and it cuts across TLS, SSH with
certificates, call home and zero touch while its origins go back to isms
(SNMP).  I see no best place to put all the information nor is it easy
to partition it.

I had a break recently and when I came back to netconf-5539bis,
misunderstood it, because, to my mind, the procedural description
assumed an information model, and I had the wrong model in mind.
Juergen put me straight, and clarified netconf-5539bis but I still had a
lot of background knowledge which probably stopped me having more
misunderstandings.

So yes, a few more sentences could be helpful.  I was, for example,
surprised at the discussion on fingerprints since they have been that
way since isms (SNMP) -  for which Sam was security advisor - and had
not thought of an alternative interpretation.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Apr 2015 09:50:56 +0200

Kathleen,

if it helps readers, we can add the following sentence to the end of
section 7:

   The NETCONF server configuration data model
   [I-D.ietf-netconf-server-model] covers NETCONF over TLS and provides
   further details such as certificate fingerprint formats exposed to
   network configuration systems.

Note that this would be an informative reference for the orientation
of readers. I personally do not think this is actually needed - I
assume that people implementing a NETCONF server will be able to
locate the NETCONF server configuration data model without needing a
pointer in the TLS transport mapping (there is also no pointer in the
SSH transport mapping). But anyway, if people on the IESG feel
strongly that adding this sentence improves readability, I can easily
do so.

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 7 Apr 2015 19:26:30 -0400

Hello,

On Tue, Apr 7, 2015 at 3:50 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> I do think it's helpful to add a little more detail and pointers int he
draft to the other work that is assumed.  My comment is non-blocking, so
it's the editors choice with the WG and AD, but I do think a little more
text to provide this background is helpful.

Thank you,
Kathleen

-- 

Best regards,
Kathleen