Subject: [paws] moving forward ...

From: <[email-masked]>
Date: Sat, 1 Sep 2012 02:54:02 +0000

We had lots of discussions on the list since the Vancouver F2F, with mixed results. The chairs feel that it is time to move forward one way or the other.
We think the best way forward is to appoint an editor who will merge the non-controversial parts of the currently available two individual submissions, draft-das and draft-wei, including the agreements we have made so far on the list, with the intent to create a document for wg adoption. Vincent Chen has volunteered to take the very rewarding job of editor.
Here's a summary of what we have agreed so far and what is non-controversial and should be included into the merged document:
Intro, protocol description, protocol functionalities
There was no objection to have a DB initialization message, no controversy around the registration/ validation/query/reporting

We also agreed that the Discovery process should result in discovering both the URI of the DB and the regulatory domain. We have not agreed whether we should include the discovery as part of this document or have a separate document. We have also not agreed what mechanisms to use for discovery, LoST or the one in draft-Probasco. In my opinion, even if we use LoST, we'd need a document describing how to do LoST server discovery and define a parameter to be used for conveying the regulatory domain. Ie, either way, we need a document which describes these details (whether that document would stay as a standalone or rolled into the base solution doc is a separate discussion we could have). Any volunteer to generate such a document for the wg could discuss?
I propose the merged document to have a section on discovery and list at least the above assumptions.

We have not agreed on the encoding of the data elements. The chairs and the AD will soon come up with a process to help us choose between JSON and XML, unless we'll find good reasons to support and define both. For the time being, I'll ask the editor to at least put together from the two documents a list of parameters which we'll need to include into the protocol messages, noting the little agreements we made, like using ISO8601 format.

Regarding security, the proposals are to have the protocol be defined to handle both shared secrets and client certificates. Brian had a problem with the shared secret, saying that if we choose to support shared secrets but do not define a provisioning mechanism, the iesg may not like it. Brian has an AP to clarify this with the security experts within the iesg. Until this point is clarified, the editor should include the certificate part and have a placeholder for the shared secret part.

Let's start with the above. I am hoping to have a merged document produced by the editor in a relatively short period of time.

-          Gabor