Subject: [tcpinc] Confirmation of consensus to adopt API document

From: Kyle Rose <[email-masked]>
Date: Mon, 11 Apr 2016 08:09:46 -0400

At the TCPINC session in Buenos Aires, there appeared to be consensus
for the WG to adopt the API document, "Interface Extensions for
TCP-ENO" (https://datatracker.ietf.org/doc/draft-bittau-tcpinc-api/):
the chairs called for a show of hands, and somewhere around 8-10 hands
were in favor with none opposed.

We need to confirm this outcome on the list, so if you are opposed to
adoption please post to the list by Friday April 15 at 20:00 GMT so we
know to re-open the question. Otherwise, we'll consider the matter
decided.

Adopting this document will complete the second of the WG's four milestones.

Thanks,
Kyle (for David and Mirja)

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 11 Apr 2016 12:36:00 +0000

Has the WG discussed the applicability of https://www.ietf.org/iesg/statement/writable-mib-module.html to Section 2.2?

I know that this question may be a bit unusal for TSV area and even more unusal for this specific use case ;-)

Also, it may not apply to an informational document. But it could be worthwile to review if CLI ("sysctl") is indeed the only known method in industry for configuration of network elements implementing TCP.

Michael

> -----Original Message-----
> From: Tcpinc [mailto:[email-masked]] On Behalf Of EXT Kyle
> Rose
> Sent: Monday, April 11, 2016 2:10 PM
> To: tcpinc
> Subject: [tcpinc] Confirmation of consensus to adopt API document
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: David Mazieres <[email-masked]>
Date: Mon, 11 Apr 2016 09:52:01 -0700

"Scharf, Michael (Nokia - DE)" <[email-masked]> writes:

> Has the WG discussed the applicability of
> https://www.ietf.org/iesg/statement/writable-mib-module.html to
> Section 2.2?
>
> I know that this question may be a bit unusal for TSV area and even
> more unusal for this specific use case ;-)
>
> Also, it may not apply to an informational document. But it could be
> worthwile to review if CLI ("sysctl") is indeed the only known method
> in industry for configuration of network elements implementing TCP.

To be clear, the API document presents an abstract API.  The suggestion
of sysctl is for OSes that already do a bunch of TCP configuration via
sysctl.  For an OS that loads TCP configuration in some other way, or
user-level implementations that cannot extend sysctl, the same knobs
will have to be made available through a different mechanism.

The goal is to ensure that whatever mechanism provides these
configuration knobs, roughly the same knobs will be available everywhere
so that configurations can easily be translated between OSes.

If we believe devices currently configured with netconf will someday
support TCPINC, then we can include a paragraph explaining how the API
would map to netconf.  Presumably this would specify some XML path under
which to mount the system-wide options?  Is there precedent for
configuring other TCP parameters with netconf, and if so what does it
look like?  Do you want to suggest some language to include?

Thanks,
David

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 12 Apr 2016 08:48:56 +0000

Inline <ms>

-----Original Message-----
From: EXT David Mazieres [mailto:[email-masked]] 
Sent: Monday, April 11, 2016 6:52 PM
To: Scharf, Michael (Nokia - DE); EXT Kyle Rose; tcpinc
Subject: Re: [tcpinc] Confirmation of consensus to adopt API document

> in industry for configuration of network elements implementing TCP.

To be clear, the API document presents an abstract API.  The suggestion of sysctl is for OSes that already do a bunch of TCP configuration via sysctl.  For an OS that loads TCP configuration in some other way, or user-level implementations that cannot extend sysctl, the same knobs will have to be made available through a different mechanism.

<ms> In IETF terminology, Section 2.2 does not describe an abstract API but a device configuration datastore, even if that specific terminology may not be widely used for TCP stack configuration. And formally there is the IESG statement and that statement could apply to Section 2.2. Thus, the WG may have to consider whether how to deal with this IESG statement. One option is a statement that it does not apply but this should be agreed upon explicitly, not implicitly.

The goal is to ensure that whatever mechanism provides these configuration knobs, roughly the same knobs will be available everywhere so that configurations can easily be translated between OSes.

<ms> Yes, but this is known to be difficult. When RFC 6897 was written, the consensus in the MPTCP WG was that "sysctl" statements are too implementation specific to be documented by the IETF. The TCPINC WG can obviously come to a different conclusion, but given the past consensus in the MPTCP WG in my opinion this is requires explicit discussion, e.g., what may be different between TCPINC and MPTCP.

If we believe devices currently configured with netconf will someday support TCPINC, then we can include a paragraph explaining how the API would map to netconf.  Presumably this would specify some XML path under which to mount the system-wide options?  Is there precedent for configuring other TCP parameters with netconf, and if so what does it look like?  Do you want to suggest some language to include?

<ms> It is up to the TCPINC WG consensus to determine how to deal with this IESG statement. In my reading it is a recommendation only and not mandatory. That IESG statement was not in place when I wrote RFC 6897, so I assume there is no precedence how to deal with this.

Michael

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Apr 2016 10:54:58 +0100

Michael,

Which of the IESG statements listed at [1] do you mean?
That's not clear to me, sorry,
S.

[1] https://www.ietf.org/iesg/statement.html

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Apr 2016 11:00:25 +0100

> That's not clear to me, sorry,

Ah sorry now I see the URL:-)

I doubt that there'll be a problem for this draft from the
IESG, other than the usual nitpicking. That is, unless
someone here wants to write a MIB module I guess but I
didn't think that was suggested.

S.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 12 Apr 2016 10:05:07 +0000

The link is in my first e-mail: https://www.ietf.org/iesg/statement/writable-mib-module.html

The relevant sentence is: "IETF working groups are therefore encouraged to use the NETCONF/YANG standards for configuration, especially in new charters."

Section 2.2 of draft-bittau-tcpinc-api-01 includes what one could call "configuration", so the applicability of that IESG statement seems to me a reasonable question.

The TCPINC charter is not clear whether configuration is in scope of the document, or not. Given that, I believe WG adoption is formally the right time to discuss this formal question.
 
Michael

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of EXT Stephen Farrell
Sent: Tuesday, April 12, 2016 11:55 AM
To: Scharf, Michael (Nokia - DE); David Mazieres expires 2016-07-10 PDT; EXT Kyle Rose; tcpinc
Subject: Re: [tcpinc] Confirmation of consensus to adopt API document

Michael,

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Apr 2016 08:10:53 -0700

> Section 2.2 of draft-bittau-tcpinc-api-01 includes what one could call "configuration", so the applicability of that IESG statement seems to me a reasonable question.

The IESG statement is worded poorly at best. It appears to me to imply
"when picking between MIB and Netconf/YANG models, pick the latter".

I do not read this as "configuration APIs should be described in terms
of Netconf/YANG."

An abstract API should never need to get into such a level of detail to
require a particular implementation. If you're aiming for something
beyond that, IMO the IETF is the wrong place (e.g., a better place would
be POSIX).

Joe

---

From: Kyle Rose <[email-masked]>
Date: Tue, 12 Apr 2016 11:17:00 -0400

> "when picking between MIB and Netconf/YANG models, pick the latter".

This is how I read it, as well.

> beyond that, IMO the IETF is the wrong place (e.g., a better place would

To this point, does it make sense to use a common implementation as an
illustration of how an abstract API might be implemented? This is how
I read the ENO API document: not as a specification for a particular
API, but as a description of what such an API must cover, with the
Linux/POSIX configuration interfaces used as an illustration.

Kyle

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 12 Apr 2016 16:32:34 +0000

> > An abstract API should never need to get into such a level of detail 
> > to require a particular implementation. If you're aiming for something 
> > beyond that, IMO the IETF is the wrong place (e.g., a better place 
> > would be POSIX).

> To this point, does it make sense to use a common implementation as an illustration of how an abstract API might be implemented? This is how I read the ENO API document: not as a specification for a particular API, but as a description of what such an API must cover, with the Linux/POSIX configuration interfaces used as an illustration.

For what it is worth, for the content of Section 2.2, another applicable term for what you describe would be "information model" (see RFC 3444). This is well-known IETF terminology but perhaps not used in that way e.g. by operating system kernel developers. One challenge with Section 2.2 is that even basic terminology will be very different depending on the context.

I just share this so that the WG can make an informed choice. For an informational document this may all not matter, and thus I will stop here with further comments.

Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Apr 2016 10:02:41 -0700

On 4/12/2016 8:17 AM, Kyle Rose wrote:
> illustration of how an abstract API might be implemented? 

Not in an RFC, IMO. Doing so sets details of the interface in stone,
whether by declaration or implication.

If you can't do it without that sort of example, IMO you have not
succeeded in the "abstract" part of an abstract API.

Joe

---

From: Kyle Rose <[email-masked]>
Date: Wed, 13 Apr 2016 10:20:41 -0400

> succeeded in the "abstract" part of an abstract API.

Is there an example you'd recommend of an RFC that does this the right way?

Kyle

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 13 Apr 2016 14:39:30 +0000

RFC 6897 Section 6.3 lists all related RFCs that I was aware of at when writing that one.

Michael

-----Original Message-----
From: Tcpinc [mailto:[email-masked]] On Behalf Of EXT Kyle Rose
Sent: Wednesday, April 13, 2016 4:21 PM
To: Joe Touch
Cc: tcpinc; Scharf, Michael (Nokia - DE); David Mazieres expires 2016-07-10 PDT; EXT Stephen Farrell
Subject: Re: [tcpinc] Confirmation of consensus to adopt API document

Kyle

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Apr 2016 09:07:44 -0700

> Is there an example you'd recommend of an RFC that does this the right way?

The best one is one of the oldest - RFC793, but that focuses on data
plane events and connection status, rather than parameters for
extensions such as this.

However, IMO, it's still a good reference.

Joe

---

From: Kyle Rose <[email-masked]>
Date: Thu, 14 Apr 2016 08:42:42 -0400

That's helpful feedback. Thanks, Joe. (For those who haven't, take a
quick look at section 3.8 of RFC 793.)

The milestone as-worded does not make reference to "abstract", but I
think there is understanding among the chairs and the authors that
this is implied; once adopted, the WG can come to consensus on what
constitutes an abstract API, and rework the document to meet this
definition. (We can also reword the milestone to specify "abstract"
explicitly, though I'm not sure that's really necessary.)

Kyle