Subject: Re: [paws] moving forward ...

From: Vincent Chen <[email-masked]>
Date: Tue, 4 Sep 2012 10:53:14 -0700

Thanks for the appointment as editor. I'll start immediately to merge the
draft-das and draft-wei documents, incorporating the agreements we have so
far.

On Fri, Aug 31, 2012 at 7:54 PM, <[email-masked]> wrote:

>  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****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince