[Pana] draft-ohba-pana-relay-02.txt

[Margaret Wasserman <[e-mail]>]

Hi Pana Relay Authors,

I've been asked to shepherd draft-ohba-pana-relay-02.txt for RFC
publication as a standards track document.  As part of that process, I
am required to perform my own review of the document before doing a
document write-up.  During my review, I found several issues that
should be resolved before this draft is published.

I'll start with a question: Before I read this draft, I was under the
impression that the Pana Relay would forward Pana messages between an
unmodified Pana Client (PAC) and an unmodified Pana Authentication
Agent (PAA), allowing Pana to be used on networks, such as 6lowpan
networks, that have multi-hop links.  However, the mechanism in this
draft requires modifications to the PAA to support a new message type
for relayed messages.  Are the expected users of this technology
aware that an updated PAA will be required?  Is there reason to believe
that updated PAAs will be available?

Now onto issues with the document text...

SUBSTANTIVE ISSUES:

S1) It appears that this document should be held for a reference to a
document coming from outside the IETF, the Zigbee IP Specification.  I
don't think we have a very good mechanism to do that, and I am not
sure why it is desirable for this document to be held for that
document.  Why wouldn't a reference to the 6lowpan documents suffice?

S2) The document says:

    The relay operation requires that a PANA session is initiated by the
    PaC, i.e., the first message that the PRE relays for any PANA  
session
    is a PCI (PANA-Client-Initiation) message.

It also indicates that the PRE does not maintain any per-PAC state.  It
is unclear to me that the PRE can ensure that the above text is true
without maintaining per-PAC state.

S3) I am not sure I understand what this text means:

    (a) The PAA uses the source IP address and the source port number of
    the PCI and the source IP address and UDP port number of the PRY to
    identify the PaC among multiple PCI messages sent from different
    PaCs.

Does it mean that all four values are used to differentiate the request?
So that we can support more than one PaC with the same address/port  
pair,
as long as they use different PREs?  Or only that we would allow more  
than
one PaC to use the same PRE?  Further explanation would be helpful.

EDITORIAL ISSUES:

E1) Some of the references in this document do not have corresponding
references within the text.  Specifically, RFC2464 and RFC5226.  These
references need to be removed, or references need to be added in the
text.

E2) The reference to RFC 2119 should be normative, not informative.

E3) There are many places in the text where acronyms are spelled out
in parentheses after the acronym, e.g. "PANA (Protcol for carrying
Authentication for Network Access)".  RFCs do this the other way
"Protocol for Carrying Authentication for Network Access (PANA)".

E4) AVP is not defined the first time it is used.

Please produce a new version of this document to address these issues,  
as well as the issues raised by Rafa Marin Lopez on the Pana list.  In  
the meantime, I will attempt to solicit a security reviewer for this  
document.

Thanks,
Margaret