Inline <ms> -----Original Message----- From: EXT David Mazieres [mailto:dm-list-tcpcr...@scs.stanford.edu] 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
"Scharf, Michael (Nokia - DE)" <michael.sch...@nokia.com> 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. <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 _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
