Re: comments on the address selection API draft

2003-04-04 Thread Erik Nordmark
> > The psychological benefit of the two flags is that we don't have to choose > > the default; we can say that any application which has an explicit preference > > should always invoke the API to state that preference. > > I don't follow. This is true regardless of whether there is one bit or > t

Re: comments on the address selection API draft

2003-03-25 Thread Mika Liljeberg
On Tue, 2003-03-25 at 14:17, Erik Nordmark wrote: > > And if the application specifies both "X" and "not X"? > > That would be an error. Exactly. The kernel needs to test this and return an error ==> bloat. > So do we make the one bit PREFER_SRC_TMP or PREFER_SRC_PUBLIC? PUBLIC is the obvious

Re: comments on the address selection API draft

2003-03-25 Thread Erik Nordmark
> And if the application specifies both "X" and "not X"? That would be an error. > > An alternate API would be to have one flag per property and always require > a > get before a set. > > I think I would prefer this approach. This is clean, no special cases, > and allows simple checking of syst

Re: comments on the address selection API draft

2003-03-24 Thread Mika Liljeberg
On Mon, 2003-03-24 at 12:42, Erik Nordmark wrote: > Thus not specifying either of "X" and "not X" leaves the "X" property of > the address selection at the system default. And if the application specifies both "X" and "not X"? In a classic adventure game by Douglas Adams the ability to do this w

Re: comments on the address selection API draft

2003-03-24 Thread Erik Nordmark
> This is not really true. We can also specify the source address by > the IPV6_PKTINFO socket option or ancillary data item defined the > advanced API. This does not matter much, though, because we still > need to specify a particular source address. Good point. The issue is that the existing A

Re: comments on the address selection API draft

2003-03-23 Thread Samita Chakrabarti
> 1. Introduction > >Currently IPv6 socket API extensions does not provide a >mechanism to choose a particular source address other than simple >bind() operation. > > This is not really true. We can also specify the source address by > the IPV6_PKTINFO socket option or ancillary d

comments on the address selection API draft

2003-03-23 Thread JINMEI Tatuya / 神明達哉
I have some comments on draft-chakrabarti-ipv6-addrselect-api-00.txt, in addition to those already raised in this list (I'd apologize in advance if there's any duplication). 1. Introduction Currently IPv6 socket API extensions does not provide a mechanism to choose a particular source addr