> > 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
