Re: [Pana] IESG Review of protocol and framework documents

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

Answering to Lars Eggert's comments:

>Lars Eggert:
>
>Comment [2007-06-20]:
>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?

In this case, the PaC will think that another PANA session is
initiated by the PAA it did not expect to get in response to its PCI
message.  For that PAA, the following rule in Section 4.1 shall apply:

"
   When the PaC receives the initial PANA-Auth-Request message from a
   PAA, it responds with a PANA-Auth-Answer message, if it wishes to
   continue the PANA session.
"

I think that we can further clarify the text to describe the behavior 
when it does not wish to continue the PANA session as follows:

"
   When the PaC receives the initial PANA-Auth-Request message from a
   PAA, it responds with a PANA-Auth-Answer message, if it wishes to
   continue the PANA session.  Otherwise, it silently discards the 
   PANA-Auth-Request 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.

How about revising Section 4.1 as follows?

from:

"
6.1.  IP and UDP Headers

   Any PANA message is unicast between the PaC and the PAA.

   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).  For any PANA message sent from the other peer, the source
   port is set to the assigned PANA port number (to be assigned by IANA)
   and the destination port is copied from the source port of the last
   received message.  In case both the PaC and PAA initiates the session
   (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request
   messages cross each other), then the PaC is identified as the
   initiator.  
"

to:

"
6.1.  IP and UDP Headers

   Any PANA message is unicast between the PaC and the PAA.

   For any PANA message sent from the peer that has initiated the PANA
   session, the UDP source port is set to any number on which the peer
   can receive incoming PANA messages and the destination
   port is set to the assigned PANA port number (to be assigned by
   IANA).  For any PANA message sent from the other peer, the source
   port is set to the assigned PANA port number (to be assigned by IANA)
   and the destination port is copied from the source port of the last
   received message.  In case both the PaC and PAA initiates the session
   (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request
   messages cross each other), then the PaC is identified as the
   initiator.  All PANA peers MUST listen on the assigned PANA port
   number (to be assigned by IANA).
"

>Section 7., paragraph 7:
>>    message-name     = PANA-name
>
>  ABNF warning: rule message-name previously referred to as Message-Name

OK, s/message-type/Message-Name/.

Best Regards,
Yoshihiro Ohba

On Fri, Jun 22, 2007 at 01:54:16PM +0200, Mark Townsley wrote:
> 
> PANA Folks,
> 
> Yesterday, the IESG balloted draft-ietf-pana-pana-17.txt (Proposed 
> Standard) and draft-ietf-pana-framework-09.txt (Informational RFC). 
> While there are a handful of DISCUSS positions that we need to work 
> through, all of you who worked hard on this revision should be 
> commended. In particular, a rare word of praise from Sam Hartman:
> 
> "[2007-06-21] First, I'd like to compliment Mark and the PANA working 
> group on the
> excellent work they have done over the last year.  I fully expected to
> be unable to support publication of PANA when it came to the IESG.
> While I do have some blocking comments, I think they are easy to
> resolve and expect to be able to remove my discuss when that happens.
> What an excellent job making PANA easier to understand and removing
> complexity."
> 
> I would like to especially thank Yoshi, Alper, Raj and Jari for all of 
> their hard work and perseverance, and the WG for their patience during 
> this process.
> 
> But there is still a final hurdle to leap. The IESG ballot (one ballot 
> for both documents) detail is here:
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1723&filename=draft-ietf-pana-framework
> 
> There are 3 Discuss positions which need to move to Yes or No-Obj for 
> the document to pass. If any one moves to Abstain, then the document 
> will be in danger of not passing as there are a number of "open 
> positions" here (all documents require 1 Yes and 2/3 of IESG members 
> voting Yes or No-Obj).
> 
> Dan is asking about SNMP. I understand that we have gone in circles with 
> respect to whether SNMP is required to be implemented or not, and it 
> looks like the result was confusing to Dan. We either need to revive the 
> SNMP document, or kill it off completely in the WG and in these specs.
> 
> Magnus has concerns about languages. I remember a review we did with the 
> ltru chairs which perhaps we never fully closed the loop on, please 
> contact Martin Duerst duerst at it.aoyama.ac.jp and Magnus directly to sort 
> this out.
> 
> Sam seems most concerned about:
> - Versioning
> - IP address reconfig
> - underlying link security
> - which messages need an AUTH attribute and which do not, explicitly
> - new hash algorithm migration
> - discussion in the security considerations, moving some "requirements" 
> to "tradeoffs"
> 
> I think all of these can be resolved with some discussion and one more 
> revision on the text, as such I have moved the documents to Revised ID 
> Needed. Once we have a new version which alleviates the concerns listed 
> here and the ADs have changed their position to Yes or No-Obj, the 
> documents will be approved.
> 
> - Mark
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Pana mailing list
> Pana at ietf.org
> https://www1.ietf.org/mailman/listinfo/pana
> 

_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana