Re: draft-ietf-shim6-proto-06 : Context confusion

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi,


El 23/11/2006, a las 20:52, Sébastien Barré escribió:

> marcelo bagnulo braun wrote:
> > El 22/11/2006, a las 23:38, Erik Nordmark escribió:
> >
> > > Sébastien Barré wrote:
> > >
> > > > Now, there is an extreme solution for both cases :
> > > > - if following current spec, send all locators, then tune with 
> > > > locators preferences (as proposed earlier in this mail)
> > >
> > > Why is this "extreme" in your mind?
> > > That's how the protocol is designed AFAICT.
> > >
> > > > - if supporting scenario 1, having a local configuration that 
> > > > enforces
> > > > disjoint locator sets to stay disjoint during the whole life of the 
> > > > system. This seems to be more or less the solution of virtual 
> > > > hosts, and could probably be dealt with entirely as an 
> > > > implementation problem (because the requirement to check the 
> > > > context tag *and* the destination locator could then be replaced by 
> > > > the use of separate context tag spaces).
> > >
> > > That seems like a sensible (and not "extreme") approach to me.
> >
> > i am ok with this option, just wanted to verify that we are all on 
> > the same on this....
> >
> > does anyone has a problem with this approach?
> - I think I am more or less ok with this option, too. The only problem 
> I see is that for privacy reasons (for example, maybe there are other 
> reasons), a host might want to hide some of his addresses to certain 
> peers, while showing them to other peers. If this can be statically 
> configured, then the (implementable) virtual host is sufficient.
> But in this case, it will be *prohibited* by the specification to ever 
> announce addresses from both sets. What I want to emphasize is that if 
> a host decides to separate addresses by using a virtual host concept, 
> it will be absolutely impossible next (unless changing the global 
> configuration, and accepting possible unrecoverable context 
> confusions) to mix the two sets. I see this like a limitation, but if 
> everyone agrees with that, I won't insist more... :-)

i think that the point w.r.t. to privacy is interesting, however, i 
think we should send this asap as we agreed in san diego.
So i will suggest that we send the draft in its current form and if 
some more people thinks this is an issue, we can address it with the 
issues that will probably show during the iesg review, ok?

> - Another, less problematic, thing, is that probably it could be 
> useful to clearly specify somewhere in the draft the requirement to 
> send all locators to all peers (As I discovered this requirement only 
> by deduction after careful analysis). Or is it already done ?

the draft states that:
   The confusion can be detected when I2/I2bis/R2 is received since we
   require that those messages MUST include a sufficiently large set of
   locators in a Locator List option that the peer can determine whether
   or not two contexts have the same host as the peer by comparing if
   there is any common locators in Ls(peer).

this is a weaker limitation that including the complete sets but this 
is what is needed afaict. including all the locators, would of course 
do the trick, but is not necesarily needed.


> > (i will be shipping the next version of the draft this weekend, i am 
> > already one week late from what we agreed on san diego :-(
> yes, my apologies to have sent my comments so late...

your comments are very helpful and please send more

thanks, marcelo


> regards,
>
> Sébastien.
> > Regards, marcelo
> >
> >
> > >    Erik