Protocol for Carrying Authentication for Network Access (PANA)
draft-ietf-pana-pana-18

It might be wise to change occurrences of CFWS in the formal ABNF to:
   "[CRLF WSP] *WSP"
In order to avoid whitespace-only blank lines.  While this is not
particularly important for a formal language (as opposed to a machine
parsed language), that may better reflect how it will be used.

Section 4.1., paragraph 12:
>    It is possible that both the PAA and the PaC initiate the PANA
>    session at the same time, i.e., the PAA unsolicitedly sends the
>    initial PANA-Auth-Request message while the PaC sends a
>    PANA-Client-Initiation message.  To resolve the race condition, the
>    PAA MUST silently discard the PANA-Client-Initiation message received
>    from the PaC after it has sent the initial PANA-Auth-Request message.

  And what must the PaC do when it receives the PANA-Auth-Request from
  the PAA that it didn't expect to get in response to its
  PANA-Client-Initiation message?


Section 6.1., paragraph 2:

>    For any PANA message sent from the peer that has initiated the PANA
>    session, the UDP source port is set to any number and the destination
>    port is set to the assigned PANA port number (to be assigned by
>    IANA).


  "source port is set to any number" - it'd probably be good if the node
  were able to receive packets sent to that port.

  Also, to make this work, you need to also require that all peers
  listen on the PANA port.


Section 7., paragraph 7:
>    message-name     = PANA-name

  ABNF warning: rule message-name previously referred to as Message-Name

The PANA protocol document says that the derivation of keys for use in
setting up or binding to link or layer 3 security is out of scope.
That's fine and probably even a good idea.  however there needs to be
a single document that specifies this derivation that all the uses of
the PANA SA end up referring to.  IT would be inappropriate for the
PANA IPsec document to use one method and say a method to set up
preshared secrets for 802.11I to use another mechanism that might
interact badly with the ipsec mechanism.