Skip to main content

NETCONF Call Home and RESTCONF Call Home
draft-ietf-netconf-call-home-17

Yes

(Benoît Claise)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Joel Jaeggli)
(Terry Manderson)

Note: This ballot was opened for revision 11 and is now closed.

Benoît Claise Former IESG member
Yes
Yes (for -11) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-10-20 for -11) Unknown
In Section 2.1, C5:

       This validation MAY be accomplished by certificate
       path validation or by comparing the host key or certificate to a
       previously trusted or "pinned" value.

It's a finnicky point, but I think it's an important one:  You list two methods for validation: (1) cert path validation, and (2) comparing to a pinned value.  Is it (A) acceptable for the validation to be done by other methods as well as those two?  Or is it (B) required that one of those two be used, but either is acceptable?

If (A), then the text is fine as it is.  But if (B), the text as written doesn't require the use of one of the specified methods, because "MAY" is optional.  If you mean (B), you should write it as "MUST be accomplished either by [...] or by [...]."  Alternatively, you could just add it to the previous sentence, as, '...client MUST validate the server's presented host key or certificate, either using certificate path validation or by comparing the host key or certificate to a previously trusted or "pinned" value.'

(That wasn't a DISCUSS point because I think implmentors are likely to get it right anyway.  But I do think the text needs to be tightened up in order to make it fully clear.)

In Section 2.1, C8, an even more finnicky and not very important point:

       Once the SSH or TLS connection is established, the NETCONF/
       RESTCONF client MUST immediately start using either the NETCONF-
       client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf]
       protocol.

What *else* might the client do, which merits a MUST here?  I think all you should say here is, "Once the SSH or TLS connection is established, the NETCONF/RESCONF client starts using either [...the protocols...]."

Continuing...

       Assuming the use of the IANA-assigned ports, the
       NETCONF-client protocol is started when the connection is
       accepted on either port PORT-X or PORT-Y and the RESTCONF-client
       protocol is started when the connection is accepted on port PORT-
       Z.

But no: the (NETCONF/RESCONF)-client protocol is NOT started when the connection is accepted (that was in C2), but when the SSH/TLS connection/session is established.  Which you already said in the previous sentence, and C1 already said what ports the client listens on.  Why is this sentence even here?  Why not just remove it?

These same two comments apply to S6 in Section 3.1.
Ben Campbell Former IESG member
No Objection
No Objection (2015-10-20 for -11) Unknown
One comment and a question:

- 3.1, S1:

If the client MAY be configured to listen on a non-standard port, doesn’t that imply that the server MUST be _capable_ of being configured to connect to a non-standard port?

- 4:

I'm curious why people felt it necessary to reverse the usual TLS or SSH client and server roles. Did the working group consider having the NETCONF/RESTCONF server act as the TLS or SSH client? If so, can the reasons be summarized in a sentence or two?
Deborah Brungard Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2015-10-22 for -11) Unknown
The answer to the question from Gen-ART reviewer Suresh Krishnan might also be a useful addition to the document.
Joel Jaeggli Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2015-12-14 for -15) Unknown
Thank for addressing my prior discuss points!


In section 1.3, please add a sentence that points to the threat/security analysis for use of this function with NETCONF and RESTCONF after the last sentence:

   In such circumstances, allowing the SSH/TLS server to contact the
   SSH/TLS client would open new vulnerabilities.  Any use of call home
   with SSH/TLS for purposes other than NETCONF or RESTCONF will need a
   thorough, contextual security analysis.
Martin Stiemerling Former IESG member
No Objection
No Objection (2015-10-21 for -11) Unknown
Three points in decreasing order of importance:
1) Why is this parapraph below (and subsequently the other similar ones)  using RFC 2119 language with respect to the port numbers
       The NETCONF/RESTCONF client listens for TCP connection requests
       from NETCONF/RESTCONF servers.  The client SHOULD listen for
       connections on the IANA-assigned ports defined in section
       Section 5, but MAY be configured to use a non-standard port.

Using the right port number is not something that influences the interoperability of the protocol per se, but is an operational parameter. Checking other protocol specifications, e.g. HTTP/1.1, there is no RFC 2119 language about the usage of specific port numbers.  

2) I am not a fan of having different port numbers to differentiate different vanilla flavors of a protocol. However, I can understand the why this is happening this way. But what is happening if there is X-over-TLS/SSH/foo coming after RESTCONF? Are you again in need of more port numbers? This does not look like a 	tactical wise and sustainable way. 

3) This document will benefit from an overview figure that details who is the server/client on what level for what.
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-10-20 for -11) Unknown
In this text:

   C1  The NETCONF/RESTCONF client listens for TCP connection requests
       from NETCONF/RESTCONF servers.  The client SHOULD listen for
       connections on the IANA-assigned ports defined in section
       Section 5, but MAY be configured to use a non-standard port.
       
are SHOULD/MAY mutually exclusive here, or can you do both? I'd be guessing if I said I knew, from this text. Could you provide "as well as" or "instead of" guidance?
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2015-11-24 for -12) Unknown
Thanks for addressing my discuss points. Just a couple of nits
remain that I can see.

- Typo: "SSH and clients may not be as robust" is missing a TLS 
I guess.

-Saying "don't use Verisign" seems a bit wrong, maybe re-word
that.
Terry Manderson Former IESG member
No Objection
No Objection (for -11) Unknown