Hi Lionel, Thank you for reviewing the draft. Please see my comments inline.
On Fri, Nov 23, 2007 at 12:54:31PM +0100, MORAND Lionel RD-CORE-ISS wrote: > Hi Yoshi, > > Please find here a feedback after a brief review of the draft > draft-ohba-pana-netsel-00. > > I would be in favor to separate NAP-ISP separate authentication aspects > from ISP selection. > In particular, I don't see why the ISP selection should rely on the > presence/absence of the "N" bit in the Flags field. > > I think the "N" flag should just indicate to the pana client that there > is an explicite NAP authentication in addition to the ISP > authentication. The indication will be therefore clear for the pac > receiving the message. If we don't use 'N' bit for ISP selection, then the PaC that does not support ISP selection will silently discard PAR that contains a new AVP defined in this draft without falling back to the base protocol operation without ISP selection. That is why the draft uses 'N' bit for both ISP selection as well as NAP and ISP separate authentication. > > Moreover, we should describe that, if the pac doesn't support the new > feature "NAP-ISP authentication", it will likely ignore the new flag > even if set to 1 (otherwise we should clearly state the correct > behaviour) and will not set the flag in the PNA-Auth-Answer. When this > occurs, what is the behaviour of the PAA? We may assume that if NAP If the PaC does not support the new feature, the PAA will detect it based on 'N' bit of the PAN returned by the PaC, the PANA session should continue without the new feature (i.e., neither NAP and ISP separate authentication nor ISP selection is used). (This behavior corresponds to older revisions of PANA that had NAP and ISP separate authentication.) We can add clarification text on this in the next revision. > authentication is locally required (and not supported by the pana > client), the PAA may send the last PANA-Auth-Request with a result code > PANA_AUTHORIZATION_REJECTED, as a network configuration option. This can > be only an optional behaviour as we should consider separate NAP and ISP > authentication as two independent procedures, as it was stated in > previous versions of the pana draft: > > "Within separate NAP and ISP authentication, the NAP authentication > and the ISP authentication are considered completely independent. > Presence or success of one should not effect the other. Making a > network access authorization decision based on the success or failure > of each authentication is a network policy issue." I agree that when NAP and ISP separate authentication is used, the NAP authentication and ISP authentication should be completely independent. We can add the clarification text on this in the next revision. > > Both above points should be taken into account in the draft. > > For the ISP selection, as said above, we should just rely on the support > and the use of the new "ISP-Information" AVP, specifically by the > presence of this AVP in messages sent by the pana client. The "N" flag > seems to be not needed for this procedure. The issue with your suggestion is that if the PaC does not understand ISP-Information AVP, it will discard the entire message according to Section 5.5 of PANA specification. I believe that not including new AVPs until negotiation on extended features that use the new AVPs is completed is the way to maintain backwards compability. Since PANA does not have a Version field or Mandatory flag in AVP header, use of bits in Flags field would be the only way to negotiate on any extended feature. > By the way, we should indicate that if the pana client inserts more than > one ISP-Information AVP, the PAA should reject the request. For now, it > is just stated that: > > "The PANA-Auth-Answer message sent in response to this PANA-Auth-Request > message carries at most one ISP-Information AVP to indicate the ISP > chosen by the PaC" OK. > > Final comment: if the "N" flag only to advertise explicite NAP > authentication, the following restriction described in section 2.1 will > not be needed: "The PANA session used for ISP authentication MUST NOT > carry a NAP-Information AVP.". Both AVPs could be therefore used at any > time, even if useless or just for information. Even if only one ISP is > available, even if separate NAP-ISP authentication is not performed. > This could be easier from a implementation point of view. It would be > also useful to have an update of the AVP occurrence table provided in > the pana protocol specification. As I commented above, the 'N' bit should be used for advertising network selection function including both NAP and ISP separate authentication and ISP selection. Best Regards, Yoshihiro Ohba > > I hope that my review was not too brief ;) > > Best Regards, > > Lionel Morand > Orange Labs > > > > _______________________________________________ > Pana mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
