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