Gary Winiger wrote: > Evan writes: > >> Gary Winiger wrote: >> >>>> IPv6 NAT for IP Filter >>>> >>>> Overview >>>> ======== >>>> This change request aims to provide IPv6 NAT capabilities for IP Filter. >>>> The requested release binding is micro/patch. >>>> >>>> >>> >>> >>>> Customer impact >>>> =============== >>>> A customer which uses ioctl SIOCGNATL and SIOCSTPUT to access IPv4 NAT >>>> sessions in kernel needs to rebuild their program due to the changes of >>>> structure "nat_t" and "natlookup_t" in /usr/include/netinet/ip_nat.h. >>>> >>>> >>> What is the taxonomy of these ioctls. If it is above Volatile, >>> how is the incompatible change mitagated for the requested >>> release binding? >>> >>> >>> >> It's "External Stable". Does it mean for functionality extension we need to >> provide new ioctl? Are the header files changable? Or we need to provide new >> header files? Can we add new structures into the old header files as long as >> we guarantee that no recompiling action is required for original customers? >> > > I'm not sure what "External Stable" is, so I'll take it as the > former Stable which is the current Committed. And I'll ask again: > "How is the incompatible change mitagated for the requested Patch > release binding?" > > Darren write: > >> There are a few things going on here... >> 1) management isn't interested in investing in a non-ioctl API >> unless there is significant interest outside of engineering >> (there is some interest), meaning that internal changes that >> get reflected in changes to the ioctls either cost engineers >> a whole bunch of extra work or cause customers a bunch of >> pain/work; >> >> 2) the changes to support ipv6 NAT, in the external code base >> are being made as part of the next major release (4.x -> 5.x) >> but we're not doing that here... >> >> Feel free to accost said mangler when he returns O:-) >> > > I'm not sure what the reasons are, or if they really matter > unless the architecture is wrong and then I'd leave that up > to the Case Owner and the Case Submitter to work out before > submitting the Fast Track. > > I'm asking the naive question presuming the Case Owner has approved > of the general architecture and that's less up for discussion. > If ioctls are the wrong architecture, the Case Owner should just > derail or withdraw the case.
As an intern, am I able to derail it? As far as I'm aware I'm not able to but I would support a member doing so. Darren
