Subject: [Netconf] Martin Stiemerling's No Objection on draft-ietf-netconf-call-home-11: (with COMMENT)

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 21 Oct 2015 13:40:01 -0700

Martin Stiemerling has entered the following ballot position for
draft-ietf-netconf-call-home-11: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/

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

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.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 21 Oct 2015 21:19:48 +0000

Hi Martin,

Thank you for your review.

>2119 language about the usage of specific port numbers.  

This is true.  I don’t see RFC 2119 language in RFC 4253 either.   That said, is it in any way wrong or bad?   I’m happy to change the text of course, just want to confirm...

>port numbers? This does not look like a 	tactical wise and sustainable

Joe Touch made a similar comment about a year and a half ago.   There was quite a debate about it then.   We discussed the option of having just one port for any number to TCP-based call home protocols.   In the end, the WG consensus was to use distinct ports as written in the current text.  Is this something you would like to raise again now?

>the server/client on what level for what.

I tred this before and the comment received was that it was confusing: http://www.ietf.org/mail-archive/web/netconf/current/msg09978.html.   But that was just one opinion.  What do you think about the diagram in the linked message?

Thanks again,
Kent

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Oct 2015 10:40:08 +0200

Dear all,
> Joe Touch made a similar comment about a year and a half ago.   There was quite a debate about it then.   We discussed the option of having just one port for any number to TCP-based call home proto…
We went through this already, and we had consensus on the decision.
I don't think we should revisit this now.

Regards, Benoit

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 26 Oct 2015 09:30:53 +0100

Hi Ken, all,

Am 21.10.15 um 23:19 schrieb Kent Watsen:
>> 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.
>>
>> 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.
>
> This is true.  I don’t see RFC 2119 language in RFC 4253 either.
> That said, is it in any way wrong or bad?   I’m happy to change the
> text of course, just want to confirm...

I would remove RFC 2119 language in those paragraphs, as this does not 
need RFC 2119 language.

>
>
>
>> 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.
>
> Joe Touch made a similar comment about a year and a half ago.   There
> was quite a debate about it then.   We discussed the option of having
> just one port for any number to TCP-based call home protocols.   In
> the end, the WG consensus was to use distinct ports as written in the
> current text.  Is this something you would like to raise again now?

No, as this has been discussed in the WG and there is consensus to do it 
as it is documented. This is just to state that this design is not 
future proof nor sustainable.

>
>
>
>>
>> 3) This document will benefit from an overview figure that details
>> who is the server/client on what level for what.
>
>
> I tred this before and the comment received was that it was
> confusing:
> http://www.ietf.org/mail-archive/web/netconf/current/msg09978.html.
> But that was just one opinion.  What do you think about the diagram
> in the linked message?

This would be good, may be it is worth saying that the arrows are 
pointing from the initiator away.

Thanks!

   Martin

> Thanks again, Kent

---

From: t.petch <[email-masked]>
Date: Mon, 26 Oct 2015 09:37:22 +0000

----- Original Message -----
From: "Martin Stiemerling" <[email-masked]>
To: "Kent Watsen" <[email-masked]>; "The IESG" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, October 26, 2015 8:30 AM

> I would remove RFC 2119 language in those paragraphs, as this does not

But RFC5426 says

" Syslog receivers MUST support accepting syslog datagrams on the well-
   known UDP port 514, but MAY be configurable to listen on a different
   port.  "

and I think that this is a better analogy than RFC4253, the former being
a network management protocol for operators running over a transport
which the reader may or may not be expert in, whereas the latter is
written by experts for experts.

Tom Petch

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Oct 2015 14:44:17 +0000

>written by experts for experts.

Hi Tom,

Thanks for pointing this out.  I actually like the RFC 5426 language more than the current text, it seems more precise to me.  So how about the following?  

OLD:

NEW:

    The NETCONF/RESTCONF client listens for TCP connection requests
    from NETCONF/RESTCONF servers. The client MUST support accepting
    TCP connections on the IANA-assigned ports defined in section
    Section 5, but MAY be configurable to listen on a different port.

Martin, does seeing RFC 5426 help?

>> pointing from the initiator away.

PS: I’m planning to add this diagram into the draft.

Thanks again,
Kent

---

From: t.petch <[email-masked]>
Date: Mon, 26 Oct 2015 15:14:29 +0000

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "The IESG" <[email-masked]>; "Martin
Stiemerling" <[email-masked]>
Sent: Monday, October 26, 2015 2:44 PM
> Thanks for pointing this out.  I actually like the RFC 5426 language
more than the current text, it seems more precise to me.  So how about
the following?
>     Section 5, but MAY be configurable to listen on a different port.

WFM

Martin seems to making a general comment that RFC2119 language is
inappropriate for the whole of s.2.1and s.3.1, a comment which I
disagree with.  As we are writing for operations-oriented people, who
may not be versed in the nuances of transport protocols, I think that
MUST, SHOULD and MAY makes things clearer so I would argue for keeping
them all in and  I think that that  needs resolving (and it is a No
Objection not a Discuss).

Making the change above to C1 moves it out of line with S1 so I would
revisit S1, currently (assuming that there are no changes from this
round of IESG comments)

OLD
 S1  The NETCONF/RESTCONF server initiates a TCP connection request to
       the NETCONF/RESTCONF client.  The server SHOULD connect to one of
       the IANA-assigned ports defined in section Section 5, but MAY be
       configured to use a non-standard port.  Using the IANA-assigned
       ports, the server connects to port PORT-X for NETCONF over SSH,
       port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF
       over TLS.

Perhaps
NEW
 S1  The NETCONF/RESTCONF server initiates a TCP connection request to
       the NETCONF/RESTCONF client.  The server MUST suppport
connections
       to one of
       the IANA-assigned ports defined in Section 5, but MAY be
       configurable to support
       connections to a non-standard port.  Using the IANA-assigned
       ports, the server connects to port PORT-X for NETCONF over SSH,
       port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF
       over TLS.

Tom Petch

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 30 Oct 2015 21:26:37 +0100

> Martin, does seeing RFC 5426 help?

That would work for me.

   Martin