Re: [Pana] PANA relay implementation status

[Jari Arkko <[e-mail]>]

I have reviewed this specification and sent it forward for IETF Last
Call. I think the spec is in good shape. There are a couple of issues
below, however, and I hope that you can resolve them in some
satisfactory manner. I have decided to forward the draft for IETF last
call anyway.

> The PaC-Information AVP contains the PaC's IP address
>    and UDP port number. 

... IP address and UDP source port number used for sending the PANA
messages.

>    (b) The IP address and the port number contained in the PaC-
>    Information AVP are maintained in the PANA session attribute "IP
>    address and UDP port number of the PaC".
>   

Please make it clearer that you are talking about a conceptual data
structure at the PAA, not a new PANA protocol attribute on the wire.

>    When the PAA originates a PANA message for a relayed PANA session, it
>    sends a PRY message to the PRE's IP address and UDP port number.

... IP address and sets the destination UDP port number to the source
UDP port number used in the PRE message.

> The PAA-
> originated PANA message is sent to the PaC's IP address and UDP port
> number.
>   

As above. You might also consider adding text about reversing the port
numbers, i.e., that the message that you are sending comes from the
source port that the request was sent to.

> This specification assumes there is at most one PRE between the PaC
> and the PAA.  Performing relay operation on a PANA message that is
> already relayed (i.e., carried inside a PRY message) is out-of scope
> of this specification.
>   

This is problematic, as it may occur. At the very least, we should
specify what happens if you end up receiving an already relayed message.
Loops may also occur.

I don't mind that we skip specifying this functionality now. What I'm
worried about is the upgrade to doing something better in the future. If
we don't do something now, how do we know tomorrow that our messages are
being correctly relayed?

I would recommend the following behaviour, actually. If the relay
detects an already existing relay attributes or has no configuration to
actually be able to send something to a PAA, it would reply with the
relevant PANA message and set Result-Code to <TBD = Relay cannot route
message>. This would allow the client to at least know something is
wrong. This would also allow the relay to signal other erroneous
conditions to the client.

> The Relayed-Message (AVP Code 11) is of type OctetString and contains
> a relayed PANA message.
>   

Without the IP/UDP encapsulation, I assume?

Jari