On 12/04/16 10:54, Stephen Farrell wrote: > > Michael, > > Which of the IESG statements listed at [1] do you mean? > 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. > 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:[email protected]] >> 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)" <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/tcpinc >> > > > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
