Re: [DNA-BOF] Attachment Detection charter text for discussion

[Nicolas Montavont <montavont@clarinet.u-strasbg.fr>]

Hi,

Alper Yegin wrote:

 >>I would say "to work out what has been attached to" may be a part of
 >>DNA. But I don't have a strong opinion on that.
 >>
 >>Regarding the the post-attachment authorization phase, perhaps one
 >>approach would be to
 >>
 >>(1) Keep this primarily a problem of the folks who are doing it, such
 >>   as PANA. They could document the API requirements and implications
 >>   of back-off procedures etc. Or maybe already have done that. Alper?
 >>
 >>
 >
 >We don't have anything to that effect in the spec yet. Before PANA 
succeeds,
 >the host will have an "IP-enabled interface with limited access
 >authorization". An implementation can mark the interface with an 
appropriate
 >flag to indicate this state.
 >
 >Btw, another ad-hoc scheme in addition to web-based login is the VPN-based
 >access control. In that, a host is allowed to freely associate with 
the WLAN
 >link and given an IP address. But it cannot send any useful data traffic
 >except for connecting to the VPN gateway to access the enterprise network.
 >This is another scenario to consider...
 >
 >
 >
 >>(2) In addition, as we describe the link state and hints in DNA,
 >>   we'll add some clarifying text about post-attachment state and
 >>   hints. For instance, we could say that IP capability may not imply
 >>   connectivity, and that there may be additional tasks before
 >>   global signaling such as MIPv6 can take place. Name a few examples,
 >>   such as the login webpages, and say that details of these are
 >>   out of scope for DNA.
 >>
 >>   The purpose of this clarifying text is to alert the reader to
 >>   the issue, but not solve it in DNA.
 >>
 >>
 >
 >If we can somewhat abstract these interim steps and present how they 
should
 >be accounted in DNA algorithm, this would be good.
 >
 >
 >
 >
 >>(3) If we are going to talk about multihoming case, mention the
 >>   item 2 problem in that context as well. Might want to prefer
 >>   a slow link over fast but webpage-login-not-yet-done link ;-)
 >>
 >>
 >
 >I'm not sure we should be dealing with "interface selection" in this 
WG. I'd
 >think we should look at DNA on a given interface, not for the whole system
 >(host).
 >
I think too. DNA must give link description for any given interface,
i.e. define needed parameters and hint and say when to generate
triggers. But I don't think that DNA have to discuss how this
information can be used to manage multiple interfaces for example, it is
out of scope.

Nicolas

 >
 >
 >Alper
 >
 >
 >