Subject: Re: [Netconf] draft-ietf-netconf-call-home-05.txt

From: Alan Luchuk <[email-masked]>
Date: Fri, 22 May 2015 15:59:27 -0400 (EDT)

Hello,

I have fairly closely read draft-ietf-netconf-call-home-05.  

I think document could be advanced as-is.  That said, I have included 
a few comments below.  Most of the comments are stylistic or wording 
preferences, that can be ignored, included, or omitted as appropriate.  
The first three comments are more substantial.

Regards,
--Alan

Page 5, starting in section 2, subsection 2.1, item C1:
-------------------------------------------------------

The text reads:

   C1  The NETCONF/RESTCONF client listens for TCP connection requests
       from NETCONF/RESTCONF servers.  The client SHOULD listen for

I suggest adding the following text as the last paragraph in the 
Introduction, (Section 1):

   In this document, the term "NETCONF/RESTCONF" is used as an 
   abbreviation in place of the text "the NETCONF or the RESTCONF".  
   The NETCONF/RESTCONF abbreviation is not intended to require or 
   to imply that a client or client or server must implement both 
   the NETCONF standard and the RESTCONF standard.

Page 6, section 2.1, item C5:
-----------------------------

The text reads:

       validation data (e.g., pinning, using the entire host key or
       certificate as the lookup key) or via certificate path validation

Perhaps delete the word "pinning"?  

Upon first read, I was not sure what "pinning" meant.  Upon a second read,
I assume that "pinning" is defined by the rest of the phrase in parenthesis.

As an unrelated issue, the phrase suggests the _entire_ certificate is used 
as the lookup key.  Is this what was intended?

Page 4, section 1, last paragraph:
----------------------------------

s/to also support call home/to support call home also/

The phrase "to also support" is a split infinitive, which once upon
a time was considered bad grammer.

The rest of the comments are stylistic or wording preferences, that can
be ignored, included, or omitted as appropriate.

Page 3, Section 1, third paragraph:
-----------------------------------

s/TLS, same as the RESTCONF protocol/TLS, the same as the RESTCONF protocol/
                                          ^^^

Page 3, Section 1, fifth paragraph:
-----------------------------------

s/protocol stacks, as when/protocol stacks, as/
                      ^^^^

Page 4, first paragraph on the page under section 1:
----------------------------------------------------

s/TCP layer; that is, in which/TCP layer; that is, which/
                      ^^

Page 4, second paragraph on the page under section 1:
-----------------------------------------------------

I suggest splitting the first sentence into to sentences, from:

   For example, a network element is traditionally the TCP-server
   however, when calling home, the network element becomes the TCP-

to:

   For example, a network element is traditionally the TCP-server.
   However, when calling home, the network element becomes the TCP-

Page 5, Section 2.1, item C1:
-----------------------------

The last part of thelast sentence reads:

       Section 5, but MAY be configured to use a non-default port.

Would changing "non-default" to "non-standard" or "non-IANA-assigned"
be clearer?

This same comment applies to the second sentence under item S1 in
Section 3.1 on Page 7.

Page 6, Section 2.2, first sentence:
------------------------------------

Would changing:

   How to configure a NETCONF or RESTCONF client is outside the scope of

to:

   How a NETCONF or RESTCONF client is configured is outside the scope of

be a little clearer?

This same comment applies to the first sentence of Section 3.1 on Page 7.

---

From: Kent Watsen <[email-masked]>
Date: Sat, 30 May 2015 00:02:22 +0000

Hi Alan,

Thanks again for another great review.  Below are my responses to your
comments.  I was hoping to receive more comments before posting an updated
draft, but went ahead and posted -06 just now to reflect this update.

Regards,
Kent

>Page 5, starting in section 2, subsection 2.1, item C1:

Done!  - I added a section called "The NETCONF/RESTCONF Convention"

>Page 6, section 2.1, item C5:

I addressed this specific issue by changing the wording to "...to a
previously trusted or 'pinned' value".  So it becomes self-defining.  Is
this is acceptable?

>as the lookup key.  Is this what was intended?

Yes, but looking at it more carefully, I felt that the entire bullet point
wasn't clear enough and hence rewrote that section.  Please see the
diff for details: 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-06.txt

>Page 4, section 1, last paragraph:
Suggestion incorporated

>Page 3, Section 1, third paragraph:
Suggestion incorporated

>Page 3, Section 1, fifth paragraph:
Suggestion incorporated

>Page 4, first paragraph on the page under section 1:
Suggestion incorporated

>Page 4, second paragraph on the page under section 1:
Suggestion incorporated

>Page 5, Section 2.1, item C1:

Yes. I changed it to "non-standard" in both locations.

>Page 6, Section 2.2, first sentence:

Yes, I think so. I incorporated your suggestion in both locations.

Thanks again,
Kent