Skip to main content

State Machines for the Protocol for Carrying Authentication for Network Access (PANA)
RFC 5609

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    pana mailing list <>, 
    pana chair <>
Subject: Document Action: 'State Machines for Protocol for 
         Carrying Authentication for Network Access (PANA)' to 
         Informational RFC 

The IESG has approved the following document:

- 'State Machines for Protocol for Carrying Authentication for Network 
   Access (PANA) '
   <draft-ietf-pana-statemachine-12.txt> as an Informational RFC

This document is the product of the Protocol for carrying Authentication 
for Network Access Working Group. 

The IESG contact persons are Jari Arkko and Ralph Droms.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

   This document defines the state machines for Protocol Carrying
   Authentication for Network Access (PANA) [RFC5191]. There are state
   machines for the PANA client (PaC) and for the PANA Authentication
   Agent (PAA). Each state machine is specified through a set of
   variables, procedures and a state transition table.

Working Group Summary

  The WG has reviewed this document at length. It has also been
  presented and discussed at several WG meetings. Two WG last calls have
  also been run on it. The WG is satisfied with the quality of the
  document and there is consensus on publishing it.

Document Quality

   Implemenrations of PANA protocol itself exist. This I-D is intended
   to be published as an Informational RFC. It captures the state
   machine of the PANA protocol.

   The document was revised per AD review comments in March 2009.


  The responsible Area Director is Jari Arkko. The document shepherd
  is Basavaraj Patil.

RFC Editor Note

  Please add the following text the last paragraph of Section 7.3:

  Note that this specification does not support silently discarding EAP
  messages. They are treated as fatal errors instead. This may have an
  impact on denial-of-service resistance.

RFC Editor Note