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 On 12/04/16 09:48, Scharf, Michael (Nokia - DE) wrote: > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
