[08:06:39] --- hichem.maalaoui has joined
[08:07:49] --- bpjab1@jabber.org has joined
[08:07:53] --- amy has joined
[08:08:09] <bpjab1@jabber.org> Alper providing an update on the document status
[08:08:25] <bpjab1@jabber.org> The PANA SNMP draft has been ready for WG LC for a while
[08:08:32] --- rstory has joined
[08:08:44] <bpjab1@jabber.org> Need to make sure that we have enough people to review and comment on the I-D
[08:08:53] <bpjab1@jabber.org> The next I-D is the PANA state machine.
[08:09:08] <bpjab1@jabber.org> When is the state-machine I-D ready for LC?
[08:09:34] <bpjab1@jabber.org> Victor Fajardo said that he would prefer to wait for rev 15 of the base protocol
[08:09:47] <bpjab1@jabber.org> After rev 15 of the base protocol is completed, the SM I-D will be ready for LC
[08:09:55] <bpjab1@jabber.org> Other 4 WG drafts are far behind.
[08:10:01] <bpjab1@jabber.org> Milestones have been revised.
[08:10:16] <bpjab1@jabber.org> The dates for milestones have been updated
[08:10:24] <bpjab1@jabber.org> More realistic and we would like to stick with these.
[08:10:37] <bpjab1@jabber.org> Questions on status of WG and docs?
[08:10:45] <bpjab1@jabber.org> Main agenda item
[08:11:23] <bpjab1@jabber.org> Yoshi to discuss the base protocol issues identiied as part of AD review
[08:11:37] <bpjab1@jabber.org> Yoshi presenting the slides which have been uploaded to the proceedings page
[08:11:58] <bpjab1@jabber.org> The I-D is being further simplified. Yoshi Ohba now presenting.
[08:12:04] <bpjab1@jabber.org> Issue 1: Rate limiting
[08:12:30] <bpjab1@jabber.org> Need explicit text between rate limiting and pinging for dead-peer detection
[08:13:28] <bpjab1@jabber.org> Clarify that duplicate detection is always performed
[08:13:43] <bpjab1@jabber.org> In some cases packets may be dropped as a result of rate limiting
[08:14:11] <bpjab1@jabber.org> Issue 2: Reliable vs in-order delivery
[08:14:32] <bpjab1@jabber.org> Currently we have reliable transport all PANA messages except 1
[08:15:04] <bpjab1@jabber.org> Design choice is to support reliable delivery
[08:15:17] <bpjab1@jabber.org> In such a case sequence number is the only field required
[08:15:47] <bpjab1@jabber.org> If reliable and unreliable transport is considered then there are at least 3 parameters that would be needed.
[08:16:16] <bpjab1@jabber.org> Conclusion is to go with design choice 1
[08:16:30] <bpjab1@jabber.org> Another simplification/issue
[08:16:34] <bpjab1@jabber.org> Message type reduction
[08:16:53] <bpjab1@jabber.org> Currently we have 9 message types.. Mark (AD) has asked if the num of messages can be reduced
[08:17:01] <bpjab1@jabber.org> There can be 2 types of merging
[08:17:13] <bpjab1@jabber.org> 1. Mergiing the messages related to handshake and auth phase
[08:17:35] <bpjab1@jabber.org> 2. The PSR, PSA and PBR/PBA
[08:18:40] <bpjab1@jabber.org> Merge of message proposal as shown in the slides.
[08:19:16] <bpjab1@jabber.org> Define a couple of flags to be defined for merging
[08:19:42] <bpjab1@jabber.org> Victor: Does this mean that the semantics of PSR and PSA will change?
[08:19:54] <bpjab1@jabber.org> Yoshi: No. They will be treated the same way
[08:20:06] <bpjab1@jabber.org> Next issue: Stateless handshake
[08:20:20] <bpjab1@jabber.org> Is important to avoid resource consumption and DoS attacks.
[08:20:57] <bpjab1@jabber.org> 2. Also to support stateless handshake,
[08:21:09] <bpjab1@jabber.org> ..... <missed>...
[08:21:42] <bpjab1@jabber.org> Proposed resolution on the slide 6
[08:22:21] <bpjab1@jabber.org> Next one is Explicit vs implicit update
[08:23:28] <bpjab1@jabber.org> Between implicit and explicit update possibilities, the explicit update method would be more future proof
[08:23:45] <bpjab1@jabber.org> Any thoughts or preference?
[08:24:24] <bpjab1@jabber.org> Lionel Morand: In the case of the IP address change, should the implicit case be handled by the PAA?
[08:24:51] <bpjab1@jabber.org> Yoshi: We can describe this in the base spec so that other L2 can take advantage of it
[08:25:19] <bpjab1@jabber.org> Lionel: We should describe a method by which the PAA can notify the PAC
[08:25:41] <bpjab1@jabber.org> Yoshi: At lease IP address change should be documented?
[08:25:49] <bpjab1@jabber.org> Linonel: Yes
[08:26:49] <bpjab1@jabber.org> Raj recommending the use of the explicit method
[08:26:55] <bpjab1@jabber.org> Alper: Agrees with Raj
[08:27:28] <bpjab1@jabber.org> Alper: Mark and Jari have recommended that for the purpose of simplification we get rid of this flag
[08:28:09] <bpjab1@jabber.org> Conclusion to incorporate explicit notification and provide feedback to ADs
[08:28:17] <bpjab1@jabber.org> Next issue: PANA-ping
[08:28:43] <bpjab1@jabber.org> See slide for issue clarification.
[08:28:47] <bpjab1@jabber.org> Slide no 8
[08:29:10] <bpjab1@jabber.org> Keep it as is
[08:29:21] <bpjab1@jabber.org> Next issue: Peer identification in PCI
[08:29:58] <bpjab1@jabber.org> PCI is not used in session ID
[08:30:16] <bpjab1@jabber.org> Slide 10: Error on authenticator failure
[08:30:16] <bpjab1@jabber.org> Corner case
[08:30:37] <bpjab1@jabber.org> Current specification says silently discard the message or it may send an error message
[08:30:52] <bpjab1@jabber.org> Recommendation is to not send any error message and rely on messaging timing out
[08:31:06] <bpjab1@jabber.org> Last one: NAT and UDP port num
[08:31:15] <bpjab1@jabber.org> Current proposal uses well known port
[08:31:20] <bpjab1@jabber.org> Does not work with NAT
[08:32:22] <bpjab1@jabber.org> To make it easier, just describing the rules on which entity is initiating the pana session
[08:33:18] <bpjab1@jabber.org> Victor has tested the new rule proposed on the slide
[08:34:03] <bpjab1@jabber.org> And the basic rule would be as shown on the slide (slide 10)
[08:34:45] <bpjab1@jabber.org> Lionel: In the PAA what will be the content of the binding?
[08:35:10] <bpjab1@jabber.org> Yoshi: PAC IP address is part of binding
[08:35:36] --- hichem.maalaoui has left
[08:35:54] <bpjab1@jabber.org> Yoshi
[08:36:10] --- townsley@jabber.psg.com has joined
[08:36:13] <bpjab1@jabber.org> : The binding should contain not only the IP address but also something else like the port num
[08:37:47] <bpjab1@jabber.org> Lionel is satsified with the current situation
[08:37:58] <bpjab1@jabber.org> Issues discussion complete
[08:38:06] <bpjab1@jabber.org> Alper back at the mike
[08:38:48] <bpjab1@jabber.org> As Alper said earlier, we will run them by the ADs
[08:38:52] <bpjab1@jabber.org> Next steps:
[08:39:03] <bpjab1@jabber.org> We will revise the base spec and framework IDs and submit them
[08:39:22] <bpjab1@jabber.org> State machine I-D will be gated till Rev 15 of the base spec is published
[08:39:38] <bpjab1@jabber.org> Meeting is closed
[08:40:45] <bpjab1@jabber.org> Next meeting will be in Chicago
[08:40:57] <bpjab1@jabber.org> Solicit people to review the IDs.
[08:41:24] --- amy has left
[08:41:30] --- bpjab1@jabber.org has left
[08:44:38] --- ShoichiSakane has joined
[08:48:53] --- rstory has left
[09:00:11] --- ShoichiSakane has left
[09:45:51] --- townsley@jabber.psg.com has left