The IESG has approved the following documents: - 'Protocol for Carrying Authentication for Network Access (PANA) ' <draft-ietf-pana-pana-18.txt> as a Proposed Standard - 'Protocol for Carrying Authentication for Network Access (PANA) Framework ' <draft-ietf-pana-framework-10.txt> as an Informational RFC These documents are products of the Protocol for carrying Authentication for Network Access Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-18.txt Technical Summary This document defines the Protocol for Carrying Authentication for Network Access (PANA), a network-layer transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP- based EAP lower layer that runs between the EAP peer and the EAP authenticator. Working Group Summary This working group has had an uphill battle since inception, and has persevered through it all. In May 2006, during IETF Last Call, there was a rather significant backlash against the documents, with constructive comments boiling down mostly to questions of scope and level of complexity in the protocol for the task at hand. The WG has since hunkered down and rewritten the specs over the last year, with improved results. The documents have been through a second round of IETF Last Call, pointing this out in the process. A summary of changes can be found here: http://panasec.org/docs/listof-changes.txt A second balloting by the IESG and third IETF last call was performed in Sept 2007. Protocol Quality The protocol was reviewed in depth by Mark Townsley and Jari Arkko after the first IETF Last Call. The protocol has improved markedly in terms of overall complexity. Note to RFC Editor In Section 4.1 of pana-pana, the original paragraph reads: The PaC may need to reconfigure IP address after successful authentication and authorization phase to obtain an IP address that is usable for exchanging data traffic through EP. In this case, the PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request messages in the authentication and authorization phase to indicate the PaC the need for IP address reconfiguration. How IP address reconfiguration is performed is outside the scope of this document. Change that to (by adding a reference): For reasons described in Section 3 of [I-D.ietf-pana-framework], the PaC may need to reconfigure IP address after successful authentication and authorization phase to obtain an IP address that is usable for exchanging data traffic through EP. In this case, the PAA sets the 'I' (IP Reconfiguration) bit of PANA-Auth-Request messages in the authentication and authorization phase to indicate the PaC the need for IP address reconfiguration. How IP address reconfiguration is performed is outside the scope of this document. Similarly, in Section 5.6 of pana-pana, the original paragraph reads: A PaC's IP address used for PANA can change in certain situations, e.g., when IP address reconfiguration is needed for the PaC to obtain an IP address after successful PANA authentication (see Section 4.1) or when the PaC moves from one IP link to another within the same PAA's realm. In order to maintain the PANA session, the PAA needs to be notified about the change of PaC address. Change that to: A PaC's IP address used for PANA can change in certain situations, e.g., when IP address reconfiguration is needed for the PaC to obtain an IP address after successful PANA authentication (see Section 3 of [I-D.ietf-pana-framework]) or when the PaC moves from one IP link to another within the same PAA's realm. In order to maintain the PANA session, the PAA needs to be notified about the change of PaC address. Based on concerns about the reserved value "0" please make the following changes: From: 10.2.1. Message Type The Message Type namespace is used to identify PANA messages. The range of values 0 - 65,519 are for permanent, standard message types, allocated by IETF Consensus [IANA]. This document defines the range of values 1 - 4. The same Message Type is used for both the request and the answer messages, except for type 1. The Request bit distinguishes requests from answers. See Section 7 for the assignment of the namespace in this specification. to: 10.2.1. Message Type The Message Type namespace is used to identify PANA messages. Message Type 0 is not used and not assigned by IANA. The range of values 1 - 65,519 are for permanent, standard message types, allocated by IETF Consensus [IANA]. This document defines the range of values 1 - 4. The same Message Type is used for both the request and the answer messages, except for type 1. The Request bit distinguishes requests from answers. See Section 7 for the assignment of the namespace in this specification. For the same reason, the 2nd paragraph of Section 10.3.1 should be revised from: AVP Code 0 is not used. This document defines the AVP Codes 1-9. See Section 8.1 through Section 8.9 for the assignment of the namespace in this specification. to: AVP Code 0 is not used and not assigned by IANA. This document defines the AVP Codes 1-9. See Section 8.1 through Section 8.9 for the assignment of the namespace in this specification. IANA Note Please note RFC Editor's note above on allocation of reserved value "0" _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
