OK, it seems that we can safely say that it's not our problem. I am fine with reducing the information to just one bit (perhaps in PANA header?) to indicate POPA acquisition is needed.
Yoshihiro Ohba On Fri, Oct 06, 2006 at 04:08:28PM +0300, Alper Yegin wrote: > > > Section 8.12: > > > > > > > o PPAC AVP: Post-PANA-Address-Configuration AVP. Used to indicate > > > > the available/chosen IP address configuration methods that can be > > > > used by the PaC after successful PANA authentication. > > > > > > Why does PANA need to control or announce this policy/capability? > > > Once authentication is finished, the PaC or PAA should be able to issue > > a > > > DHCP Inform or do whatever it likes to obtain a new IP address, and it > > is > > > up to > > > the policy of that protocol to be rejected or not. This kind of > > > "list of possible other protocols you can run after PANA" creates layer > > > bindings that I don't think you want the PANA protocol to have to > > maintain. > > > What if the IP address is being allocated by IPCP? What about some > > future > > > version of IKE or some other configuration? What about some other > > > type of tunnel that can configure IP addresses? I don't see the > > advantage > > > of constraining yourself here, or poking into the rest of the IP stack > > > in this manner. > > > > If we don't define PPAC AVP, how the PaC can/should choose the IP > > address method for obtaining POPA address? > > The answer to that could be "how does any host choose it today?" > Meaning, maybe this is not our problem. > > I wonder if there is any PANA-specific aspect here that suggests us solving > this "discovery and selection" problem for the PaCs. > > One thing though... In case the PRPA and POPA are different (a PANA aspect), > the PAA still needs to tell the PaC to configure POPA. Maybe all we need is > one bit of information (a Boolean). > > Alper > > > > > > > > > > > _______________________________________________ > Pana mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
