From vchen@google.com Tue Sep 4 10:53:16 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4338421F8499 for ; Tue, 4 Sep 2012 10:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Owd0cMfMUuYI for ; Tue, 4 Sep 2012 10:53:15 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 16F8921F8497 for ; Tue, 4 Sep 2012 10:53:14 -0700 (PDT) Received: by qadz3 with SMTP id z3so3439821qad.10 for ; Tue, 04 Sep 2012 10:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=sjkxbWbK8dOj2Ez7KSj/Iy7uOrC+IiPm671wEOE88X4=; b=UiZWBj9wFAcf1zXV52Wx5Evxov2jgZd6rwDDetI5NR4ZoSFRayRxXUWre1Yo0pOW1l j5eWr93quyGKHyC9HuI+2Oh+H2s6dYPCEKikzLnT5PwplW7uMv8eSjvTvx002obbKUtI KeQazOUf5Xo/EAm8dJHBvaLRAVLlgQjYvi6wD1461JLEFYjkBXlPgAGC0xQmVqDNQQrH F/UrcvpNJW1tGN9TT2tNKutS7Mbq1IGhUEFxin+V8OgmyZJGR0iqjfULFzq4f6rmOrxT JnrXJ1C9OVceULc4wanHBknjbpfOR2574NGWa4aDN1hLw03EP+2G6ouQYVsMJGTlx09m 0Ksw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=sjkxbWbK8dOj2Ez7KSj/Iy7uOrC+IiPm671wEOE88X4=; b=UgDKNsx1Gf64+OZOEFTD2VkMFLGGlf+Ax/WVXa/LW8EOjrRNYt6aXlAyih5SG6CINd sYGLvyD21Ug5bIa1DXgRE9yW7AlZhDZrCbJ//tfmYZIhtV1KX82b71viqo2gHaTqkpbM Z14EweYEkdxBp0H7zC2AMdd24lTtVwbEMNS6u313IlkddvZBQXsEu+5CXbHEk+1b/ZLA 7Hg0A0H1UhBCdLRvfSErSy835ubyFhw8Nc+v7JnKWc1qddj5vOx8ympD9/tYnn+tKiHN NKEYCP+/8BqJwL5AIB08z0FA9gG3tKbVEawDgEuROcWHkDhhTcDFZAJhg6Xn3/uZgisq aECA== Received: by 10.224.42.82 with SMTP id r18mr40996256qae.43.1346781194433; Tue, 04 Sep 2012 10:53:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.42.82 with SMTP id r18mr40996241qae.43.1346781194253; Tue, 04 Sep 2012 10:53:14 -0700 (PDT) Received: by 10.229.64.149 with HTTP; Tue, 4 Sep 2012 10:53:14 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601FFA162@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601FFA162@008-AM1MPN1-006.mgdnok.nokia.com> Date: Tue, 4 Sep 2012 10:53:14 -0700 Message-ID: From: Vincent Chen To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary=20cf3074d478ac74c304c8e3ee20 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmtv6aF+iWpTTGQ8/o0UDrxQ0T/RHFk5Z++oAvTJc6mtMyR/rWO19Y1xJr1SROk/43aJ3CElchw+FL5DDM+HwHHuAPU2BIB5EFZT9z6OgffdakLJFl0fbcxjh1BLt6bmPK0IUlYEFgR6Jy44o0WEEMF1PhrNqAMkH8OiD7oFXUIkCLAsQP6N7iTWIxoy8N3/lrY+kno Cc: paws@ietf.org Subject: Re: [paws] moving forward ... X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:53:16 -0000 --20cf3074d478ac74c304c8e3ee20 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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, 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 ma= de > 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=92s 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 controvers= y > 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 u= se > LoST, we=92d need a document describing how to do LoST server discovery a= nd > define a parameter to be used for conveying the regulatory domain. Ie, > either way, we need a document which describes these details (whether tha= t > 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 an= d > XML, unless we=92ll find good reasons to support and define both. For the > time being, I=92ll ask the editor to at least put together from the two > documents a list of parameters which we=92ll need to include into the > protocol messages, noting the little agreements we made, like using ISO86= 01 > 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 secret= s > but do not define a provisioning mechanism, the iesg may not like it. Bri= an > has an AP to clarify this with the security experts within the iesg. Unti= l > this point is clarified, the editor should include the certificate part a= nd > have a placeholder for the shared secret part.**** > > ** ** > > Let=92s start with the above. I am hoping to have a merged document produ= ced > by the editor in a relatively short period of time.**** > > ** ** > > **- **Gabor**** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --20cf3074d478ac74c304c8e3ee20 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the appointment as editor. I'll start immediately to merge t= he draft-das and draft-wei documents, incorporating the agreements we have = so far.

On Fri, Aug 31, 2012 at 7:54 PM, = <Gabor.Bajko@nokia.com> wrote:

We had lots of discussions on the list since the Van= couver F2F, with mixed results. The chairs feel that it is time to move for= ward one way or the other.

We think the best way forward is to appoint an edito= r 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 voluntee= red to take the very rewarding job of editor.

Here=92s 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 functionalitie= s

There was no objection to have a DB initialization m= essage, no controversy around the registration/ validation/query/reporting<= u>

=A0

We also agreed that the Discovery process should res= ult in discovering both the URI of the DB and the regulatory domain. We hav= e not agreed whether we should include the discovery as part of this docume= nt 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=92d need a docum= ent 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 so= lution doc is a separate discussion we could have). Any volunteer to genera= te such a document for the wg could discuss?

I propose the merged document to have a section on d= iscovery and list at least the above assumptions.

=A0

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

=A0

Regarding security, the proposals are to have the pr= otocol be defined to handle both shared secrets and client certificates. Br= ian had a problem with the shared secret, saying that if we choose to suppo= rt shared secrets but do not define a provisioning mechanism, the iesg may not like it. Brian has an AP to cla= rify this with the security experts within the iesg. Until this point is cl= arified, the editor should include the certificate part and have a placehol= der for the shared secret part.

=A0

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

=A0

-=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

=A0

=A0

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince --20cf3074d478ac74c304c8e3ee20-- From Gabor.Bajko@nokia.com Fri Sep 7 13:41:16 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC0921E80B8 for ; Fri, 7 Sep 2012 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 455UGjDNzUza for ; Fri, 7 Sep 2012 13:41:15 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E136921F853A for ; Fri, 7 Sep 2012 13:41:14 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q87KfBlO017858 for ; Fri, 7 Sep 2012 23:41:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Sep 2012 23:41:11 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.135]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 22:41:10 +0200 From: To: Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4w== Date: Fri, 7 Sep 2012 20:41:10 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.187.152] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 20:41:11.0882 (UTC) FILETIME=[1DF462A0:01CD8D39] X-Nokia-AV: Clean Subject: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 20:41:16 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The chairs discussed with the AD, and we came up with the following action = plan to drive this wg to a consensus on the json vs xml encoding: we'll collect an objections list for json and one for xml, listing what is = seen wrong/problematic with that encoding. The chairs and the wg will go th= rough that list and see if the objections are valid, then decide which enco= ding has more support and choose that one. If we end up with good objection= s list for both, we may choose to support both encodings, as that list will= justify the decision once the document advances to the iesg. I went through the emails and I found so far the following valid objections= : xml: too verbose, may be a problem to be supported in embedded devices current trend for APIs in the browsers is towards json json: some data structures are encoded in xml, a json encoding for those would n= eed to be defined (which is not impossible, but requires some extra work) If you have additional objections, send them to the list asap. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The chairs discussed with the AD, and we came up wit= h the following action plan to drive this wg to a consensus on the json vs = xml encoding:

we’ll collect an objections list for json and = one for xml, listing what is seen wrong/problematic with that encoding. The= chairs and the wg will go through that list and see if the objections are = valid, then decide which encoding has more support and choose that one. If we end up with good objections list for bo= th, we may choose to support both encodings, as that list will justify the = decision once the document advances to the iesg.

 

I went through the emails and I found so far the fol= lowing valid objections:

 

xml:

too verbose, may be a problem to be supported in emb= edded devices

current trend for APIs in the browsers is towards js= on

 

 

 

json:

some data structures are  encoded in xml, a jso= n encoding for those would need to be defined (which is not impossible, but= requires some extra work)

 

 

If you have additional objections, send them to the = list asap.

 

-     &= nbsp;    Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A008AM1MPN1007mg_-- From Gabor.Bajko@nokia.com Fri Sep 7 14:01:19 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC1921E80E0 for ; Fri, 7 Sep 2012 14:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY5WbdH6UhyH for ; Fri, 7 Sep 2012 14:01:18 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF221E80DF for ; Fri, 7 Sep 2012 14:01:17 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q87L1B6r024920 for ; Sat, 8 Sep 2012 00:01:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 8 Sep 2012 00:01:11 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.135]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0309.003; Fri, 7 Sep 2012 23:01:10 +0200 From: To: Thread-Topic: PAWS security Thread-Index: Ac2NOW8VXVfdMUhbQ7OY0lXuCEkQJw== Date: Fri, 7 Sep 2012 21:01:09 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.187.152] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2012 21:01:11.0222 (UTC) FILETIME=[E8D12560:01CD8D3B] X-Nokia-AV: Clean Subject: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:01:19 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the Vancouver F2F we had extensive discussions on the security model for= PAWS. Draft-das proposes to use shared secrets pre-provisioned in the mast= er devices for authentication, while draft-lei proposes to mandate client c= ertificates into master devices. There seemed to be an understanding that the credential types in use for au= thentication are a matter of a business model chosen by the provider which = deploys white space devices, rather than a protocol decision. Brian mentioned that the iesg may not allow a document to be published whic= h specifies how shared secrets are used, but does not have a provisioning m= echanism for the shared secrets defined. In my opinion, a mechanism for dis= tributing shared secrets does not necessarily have to be defined, as a shar= ed secret can be established using current practices to set up shared secre= ts with financial institutions (using the browser). Thus, my suggestion would be to describe in the document how a shared secre= t and how a client certificate is used to authenticate a master device. The= n, if we run into issues with iesg, in worst case we could remove the share= d secret part and keep the other one. I'd like to get additional views on this topic. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the Vancouver F2F we had extensive discussions on= the security model for PAWS. Draft-das proposes to use shared secrets pre-= provisioned in the master devices for authentication, while draft-lei propo= ses to mandate client certificates into master devices.

 

There seemed to be an understanding that the credent= ial types in use for authentication are a matter of a business model chosen= by the provider which deploys white space devices, rather than a protocol = decision.

 

Brian mentioned that the iesg may not allow a docume= nt to be published which specifies how shared secrets are used, but does no= t have a provisioning mechanism for the shared secrets defined. In my opini= on, a mechanism for distributing shared secrets does not necessarily have to be defined, as a shared secret can be= established using current practices to set up shared secrets with financia= l institutions (using the browser).

Thus, my suggestion would be to describe in the docu= ment how a shared secret and how a client certificate is used to authentica= te a master device. Then, if we run into issues with iesg, in worst case we= could remove the shared secret part and keep the other one.

 

I’d like to get additional views on this topic= .

 

-     &= nbsp;    Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D008AM1MPN1007mg_-- From stephen.farrell@cs.tcd.ie Fri Sep 7 15:16:49 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022BE21E80CB for ; Fri, 7 Sep 2012 15:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYHYk4i6jlTv for ; Fri, 7 Sep 2012 15:16:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id DBBB521E80AF for ; Fri, 7 Sep 2012 15:16:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5309417147B; Fri, 7 Sep 2012 23:16:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347056205; bh=F0STtnNZyEh1gX Z9pFszZCxPKLKXGiUHAy0w5apu/LQ=; b=uy3qhQWyB4hoa67nR791JfZb+JKzp7 4vqZaz3Qbe4qmQ51MvcEAniJNNAE73a+ZHKOGktt4cMcqWisV+88E4LB4vKHOGHm zs/nYdIkiu2PWUZcYTe0/z8RxBkGt8QFTqRf9E4tvyjNC/zo9FZIfmyKluiZk2g+ kjP/JjRQ1vvxHS5itou8WR5khKbRWTk82JAGBnTtKM6CI65LzAzUemR9I9I9l25t n0b44R305i1UUqoBrp2/PduqIPh3yJ9OnLsCIJZNhjiA9P9cdqEAD0027bjhoNBi 1Nq/jP7J3tByVLFxf8Mg2ien7v+t/wRPZWA9jWqlWhB7892OjWcQL9hQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fDR9u1Yvw2gJ; Fri, 7 Sep 2012 23:16:45 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.28.81]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0576C171477; Fri, 7 Sep 2012 23:16:44 +0100 (IST) Message-ID: <504A724C.8050706@cs.tcd.ie> Date: Fri, 07 Sep 2012 23:16:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D@008-AM1MPN1-007.mgdnok.nokia.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 22:16:49 -0000 On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the Vancouver F2F we had extensive discussions on the security model for PAWS. Draft-das proposes to use shared secrets pre-provisioned in the master devices for authentication, while draft-lei proposes to mandate client certificates into master devices. > > There seemed to be an understanding that the credential types in use for authentication are a matter of a business model chosen by the provider which deploys white space devices, rather than a protocol decision. > > Brian mentioned that the iesg may not allow a document to be published which specifies how shared secrets are used, but does not have a provisioning mechanism for the shared secrets defined. In my opinion, a mechanism for distributing shared secrets does not necessarily have to be defined, as a shared secret can be established using current practices to set up shared secrets with financial institutions (using the browser). > Thus, my suggestion would be to describe in the document how a shared secret and how a client certificate is used to authenticate a master device. Then, if we run into issues with iesg, in worst case we could remove the shared secret part and keep the other one. > > I'd like to get additional views on this topic. I can help a little here (depending on your definition of help:-) BCP 107 [1] is the one to look at when considering how to approach automated key management requirements. That has an IMO very good abstract: The question often arises of whether a given security system requires some form of automated key management, or whether manual keying is sufficient. This memo provides guidelines for making such decisions. When symmetric cryptographic mechanisms are used in a protocol, the presumption is that automated key management is generally but not always needed. If manual keying is proposed, the burden of proving that automated key management is not required falls to the proposer. For those that might be less familiar with IETF processes, the fact that that's a BCP means that its entirely valid for an AD to strenuously push back against a WG that wants to ignore what it says. Cheers, S. PS: I've not read the drafts, and couldn't make the session in Vancouver, so this might be entirely off topic, but in the case of PAWS I'd also argue that the regulators' apparent desire to force devices to authenticate is not necessarily the right one for the IETF to force upon all users of the PAWS protocol. So there could for example be a mode of operation where the DB signs stuff but doesn't care who's asking and that'd be a far far easier scenario in terms of automated key management. [1] http://tools.ietf.org/html/bcp107 From lei.zhu@huawei.com Mon Sep 10 00:58:56 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11121F84D2 for ; Mon, 10 Sep 2012 00:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ra5zo8YQzRX for ; Mon, 10 Sep 2012 00:58:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8AB21F84CD for ; Mon, 10 Sep 2012 00:58:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKM96799; Mon, 10 Sep 2012 07:58:53 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 08:57:53 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 08:58:52 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 15:58:42 +0800 From: Zhulei To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhA Date: Mon, 10 Sep 2012 07:58:40 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.180] Content-Type: multipart/alternative; boundary="_000_470F27D1263A1B4EB73491ED995DE62524991A23szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 07:58:56 -0000 --_000_470F27D1263A1B4EB73491ED995DE62524991A23szxeml504mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkFjdHVhbGx5LCBubyBzbyBtdWNoIGNvbW1lbnRzIG9uIHRoaXMgY2hvb3NpbmcuIEkg anVzdCBkbyBub3QgdGhpbmsgeG1sIGlzIGEgcHJvYmxlbSB0byBlbWJlZGRlZCBkZXZpY2VzLCBp biBmYWN0IHhtbCBpcyB3ZWxsIHN1cHBvcnRlZCBieSBkaWZmZXJlbnQgc29ydCBvZiBkZXZpY2Vz IGluIG15IHZpZXcuIFRoZSBpc3N1ZSBtYXkgYmUgc29tZSBwb3dlciBhbmQgYmFuZHdpZHRoIGNv bnN0cmFpbmVkIGRldmljZXMgKGUuZy4gc29tZSBzbWFydCBvYmplY3RzKSB0byBzdXBwb3J0IHR4 dCBiYXNlZCBpbmZvcm1hdGlvbi4gTGV0oa9zIGlnbm9yZSB0aGlzIGNhc2Ugc2luY2Ugd2UgYXJl IG5vdCB0byBkZWZpbmUgYmluYXJ5IGVuY29kaW5nIGF0IHRoZSBtb21lbnQuDQoNCkJlc3QgcmVn YXJkcywNClpodSBMZWkNCg0Kt6K8/sjLOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpw YXdzLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gR2Fib3IuQmFqa29Abm9raWEuY29tDQq3osvNyrG8 5DogMjAxMsTqOdTCOMjVIDQ6NDENCsrVvP7IyzogcGF3c0BpZXRmLm9yZw0K1vfM4jogW3Bhd3Nd IEpTT04gdnMgWE1MDQoNClRoZSBjaGFpcnMgZGlzY3Vzc2VkIHdpdGggdGhlIEFELCBhbmQgd2Ug Y2FtZSB1cCB3aXRoIHRoZSBmb2xsb3dpbmcgYWN0aW9uIHBsYW4gdG8gZHJpdmUgdGhpcyB3ZyB0 byBhIGNvbnNlbnN1cyBvbiB0aGUganNvbiB2cyB4bWwgZW5jb2Rpbmc6DQp3ZaGvbGwgY29sbGVj dCBhbiBvYmplY3Rpb25zIGxpc3QgZm9yIGpzb24gYW5kIG9uZSBmb3IgeG1sLCBsaXN0aW5nIHdo YXQgaXMgc2VlbiB3cm9uZy9wcm9ibGVtYXRpYyB3aXRoIHRoYXQgZW5jb2RpbmcuIFRoZSBjaGFp cnMgYW5kIHRoZSB3ZyB3aWxsIGdvIHRocm91Z2ggdGhhdCBsaXN0IGFuZCBzZWUgaWYgdGhlIG9i amVjdGlvbnMgYXJlIHZhbGlkLCB0aGVuIGRlY2lkZSB3aGljaCBlbmNvZGluZyBoYXMgbW9yZSBz dXBwb3J0IGFuZCBjaG9vc2UgdGhhdCBvbmUuIElmIHdlIGVuZCB1cCB3aXRoIGdvb2Qgb2JqZWN0 aW9ucyBsaXN0IGZvciBib3RoLCB3ZSBtYXkgY2hvb3NlIHRvIHN1cHBvcnQgYm90aCBlbmNvZGlu Z3MsIGFzIHRoYXQgbGlzdCB3aWxsIGp1c3RpZnkgdGhlIGRlY2lzaW9uIG9uY2UgdGhlIGRvY3Vt ZW50IGFkdmFuY2VzIHRvIHRoZSBpZXNnLg0KDQpJIHdlbnQgdGhyb3VnaCB0aGUgZW1haWxzIGFu ZCBJIGZvdW5kIHNvIGZhciB0aGUgZm9sbG93aW5nIHZhbGlkIG9iamVjdGlvbnM6DQoNCnhtbDoN CnRvbyB2ZXJib3NlLCBtYXkgYmUgYSBwcm9ibGVtIHRvIGJlIHN1cHBvcnRlZCBpbiBlbWJlZGRl ZCBkZXZpY2VzDQpjdXJyZW50IHRyZW5kIGZvciBBUElzIGluIHRoZSBicm93c2VycyBpcyB0b3dh cmRzIGpzb24NCg0KDQoNCmpzb246DQpzb21lIGRhdGEgc3RydWN0dXJlcyBhcmUgIGVuY29kZWQg aW4geG1sLCBhIGpzb24gZW5jb2RpbmcgZm9yIHRob3NlIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5l ZCAod2hpY2ggaXMgbm90IGltcG9zc2libGUsIGJ1dCByZXF1aXJlcyBzb21lIGV4dHJhIHdvcmsp DQoNCg0KSWYgeW91IGhhdmUgYWRkaXRpb25hbCBvYmplY3Rpb25zLCBzZW5kIHRoZW0gdG8gdGhl IGxpc3QgYXNhcC4NCg0KDQotICAgICAgICBHYWJvcg0K --_000_470F27D1263A1B4EB73491ED995DE62524991A23szxeml504mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 

Actually, no so much comments on this choosing. I just do not thi= nk xml is a problem to embedded devices, in fact xml is well supported by d= ifferent sort of devices in my view. The issue may be some power and bandwidth constrained devices (e.g. some smart= objects) to support txt based information. Let=A1=AFs ignore this case sin= ce we are not to define binary encoding at the moment.

 

Best regards,

Zhu Lei=

 

=B7=A2=BC=FE=C8=CB: paws-bo= unces@ietf.org [mailto:paws-bounces@ietf.org] =B4=FA= =B1=ED Gabor.Bajko@nokia.com
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C28=C8=D5 4:41
=CA=D5=BC=FE=C8=CB: paws@ietf.org
=D6=F7=CC=E2: [paws] JSON vs XML

 

The chairs discussed with the A= D, and we came up with the following action plan to drive this wg to a cons= ensus on the json vs xml encoding:

we=A1=AFll collect an objection= s list for json and one for xml, listing what is seen wrong/problematic wit= h that encoding. The chairs and the wg will go through that list and see if= the objections are valid, then decide which encoding has more support and choose that one. If we end up with good obje= ctions list for both, we may choose to support both encodings, as that list= will justify the decision once the document advances to the iesg.

 

I went through the emails and I= found so far the following valid objections:

 

xml:

too verbose, may be a problem t= o be supported in embedded devices

current trend for APIs in the b= rowsers is towards json

 

 

 

json:

some data structures are  = encoded in xml, a json encoding for those would need to be defined (which i= s not impossible, but requires some extra work)

 

 

If you have additional objectio= ns, send them to the list asap.

 

-  = ;      Gabor=

--_000_470F27D1263A1B4EB73491ED995DE62524991A23szxeml504mbschi_-- From Gabor.Bajko@nokia.com Mon Sep 10 09:51:27 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A2721F864D for ; Mon, 10 Sep 2012 09:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Qs-xe1PfhPJ for ; Mon, 10 Sep 2012 09:51:24 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89721F84D6 for ; Mon, 10 Sep 2012 09:51:23 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8AGpLWr015946 for ; Mon, 10 Sep 2012 19:51:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Sep 2012 19:51:21 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.135]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0309.003; Mon, 10 Sep 2012 18:51:20 +0200 From: To: Thread-Topic: F2F session at IETF85 in Atlanta Thread-Index: Ac2PdDKxV3nQ9+C+QhORZsf33FFydQ== Date: Mon, 10 Sep 2012 16:51:20 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602012484@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.118.134] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47602012484008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2012 16:51:21.0297 (UTC) FILETIME=[815D5C10:01CD8F74] X-Nokia-AV: Clean Subject: [paws] F2F session at IETF85 in Atlanta X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:51:27 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602012484008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, FYI, I just requested a 2.5 hour session for PAWS at the Atlanta meeting. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602012484008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

FYI, I just requested a 2.5 hour session for PAWS at= the Atlanta meeting.

 

-     &= nbsp;    Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47602012484008AM1MPN1007mg_-- From Peter.McCann@huawei.com Mon Sep 10 11:00:19 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD2421E8041 for ; Mon, 10 Sep 2012 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaOm8W5YUkTd for ; Mon, 10 Sep 2012 11:00:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7303E21E803C for ; Mon, 10 Sep 2012 11:00:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKN46527; Mon, 10 Sep 2012 18:00:16 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 18:57:35 +0100 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 18:58:35 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 10:58:29 -0700 From: Peter McCann To: Stephen Farrell , "Gabor.Bajko@nokia.com" Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4Ilw Date: Mon, 10 Sep 2012 17:58:29 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D@008-AM1MPN1-007.mgdnok.nokia.com> <504A724C.8050706@cs.tcd.ie> In-Reply-To: <504A724C.8050706@cs.tcd.ie> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:00:19 -0000 Personally, I think that manually provisioned symmetric keys will severely limit the ability for users to flexibly move from one database provider to another. It will require some secure out-of-band channel on which to transmit the secret key from one party to the other, and a mechanism for the user to push the secret key down into the master device. Provisioning of certificates does not require the secret channel, only one that is integrity protected. I think this is much easier to achieve in practice. -Pete Stephen Farrell wrote: >=20 >=20 > On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the Vancouver > F2F we had extensive discussions on the security model for PAWS. > Draft-das proposes to use shared secrets pre-provisioned in the master > devices for authentication, while draft-lei proposes to mandate client > certificates into master devices. >>=20 >> There seemed to be an understanding that the credential types in use > for authentication are a matter of a business model chosen by the > provider which deploys white space devices, rather than a protocol > decision. >>=20 >> Brian mentioned that the iesg may not allow a document to be > published > which specifies how shared secrets are used, but does not have a > provisioning mechanism for the shared secrets defined. In my opinion, a > mechanism for distributing shared secrets does not necessarily have to > be defined, as a shared secret can be established using current > practices to set up shared secrets with financial institutions (using > the browser). >> Thus, my suggestion would be to describe in the document how a shared > secret and how a client certificate is used to authenticate a master > device. Then, if we run into issues with iesg, in worst case we could > remove the shared secret part and keep the other one. >>=20 >> I'd like to get additional views on this topic. >=20 > I can help a little here (depending on your definition of help:-) >=20 > BCP 107 [1] is the one to look at when considering how to > approach automated key management requirements. That has an > IMO very good abstract: >=20 > The question often arises of whether a given security system requires > some form of automated key management, or whether manual keying is > sufficient. This memo provides guidelines for making such decisions. > When symmetric cryptographic mechanisms are used in a protocol, the > presumption is that automated key management is generally but not > always needed. If manual keying is proposed, the burden of proving > that automated key management is not required falls to the proposer. > For those that might be less familiar with IETF processes, the > fact that that's a BCP means that its entirely valid for an AD > to strenuously push back against a WG that wants to ignore what > it says. >=20 > Cheers, > S. >=20 > PS: I've not read the drafts, and couldn't make the session in > Vancouver, so this might be entirely off topic, but in the case of > PAWS I'd also argue that the regulators' apparent desire to force > devices to authenticate is not necessarily the right one for the > IETF to force upon all users of the PAWS protocol. So there could > for example be a mode of operation where the DB signs stuff but > doesn't care who's asking and that'd be a far far easier scenario > in terms of automated key management. >=20 > [1] http://tools.ietf.org/html/bcp107 > _______________________________________________ paws mailing list > paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Mon Sep 10 11:15:20 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8653121E8049 for ; Mon, 10 Sep 2012 11:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+Pk00f0gRJC for ; Mon, 10 Sep 2012 11:15:19 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 6C27C21E8041 for ; Mon, 10 Sep 2012 11:15:19 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 10 Sep 2012 14:15:14 -0400 From: Peter Stanforth To: Peter McCann , Stephen Farrell , "Gabor.Bajko@nokia.com" Date: Mon, 10 Sep 2012 14:15:08 -0400 Thread-Topic: [paws] PAWS security Thread-Index: Ac2PgDhWK/0pQQ/fSDKwv+s91vpOlQ== Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:15:20 -0000 Pete, I am not sure I believe in a use case where "users" move from one DB to another. The relationship is between the radio vendor and the DBA. The radio vendor may have multiple relationships and allow an end user to choose one, but it will be from the predefined list. As a DBA I don't think I would want, and in the USA we are not permitted, to establish a relationship with a user without a preexisting relationship with the radio vendor. So security should be primarily a radio vendor-DBA issue. Wearing my DBA hat I don't think I would want to service a radio that I do not have a preexisting relationship with it's manufacturer. I am not sure that user relationships are even within the scope of what PAWS should be defining. Peter S. On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" wrote: >Personally, I think that manually provisioned symmetric keys will >severely limit the ability for users to flexibly move from one >database provider to another. It will require some secure out-of-band >channel on which to transmit the secret key from one party to the >other, and a mechanism for the user to push the secret key down >into the master device. > >Provisioning of certificates does not require the secret channel, >only one that is integrity protected. I think this is much easier >to achieve in practice. > >-Pete > >Stephen Farrell wrote: >>=20 >>=20 >> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the Vancouver >> F2F we had extensive discussions on the security model for PAWS. >> Draft-das proposes to use shared secrets pre-provisioned in the master >> devices for authentication, while draft-lei proposes to mandate client >> certificates into master devices. >>>=20 >>> There seemed to be an understanding that the credential types in use >> for authentication are a matter of a business model chosen by the >> provider which deploys white space devices, rather than a protocol >> decision. >>>=20 >>> Brian mentioned that the iesg may not allow a document to be >> published >> which specifies how shared secrets are used, but does not have a >> provisioning mechanism for the shared secrets defined. In my opinion, a >> mechanism for distributing shared secrets does not necessarily have to >> be defined, as a shared secret can be established using current >> practices to set up shared secrets with financial institutions (using >> the browser). >>> Thus, my suggestion would be to describe in the document how a shared >> secret and how a client certificate is used to authenticate a master >> device. Then, if we run into issues with iesg, in worst case we could >> remove the shared secret part and keep the other one. >>>=20 >>> I'd like to get additional views on this topic. >>=20 >> I can help a little here (depending on your definition of help:-) >>=20 >> BCP 107 [1] is the one to look at when considering how to >> approach automated key management requirements. That has an >> IMO very good abstract: >>=20 >> The question often arises of whether a given security system requires >> some form of automated key management, or whether manual keying is >> sufficient. This memo provides guidelines for making such decisions. >> When symmetric cryptographic mechanisms are used in a protocol, the >> presumption is that automated key management is generally but not >> always needed. If manual keying is proposed, the burden of proving >> that automated key management is not required falls to the proposer. >> For those that might be less familiar with IETF processes, the >> fact that that's a BCP means that its entirely valid for an AD >> to strenuously push back against a WG that wants to ignore what >> it says. >>=20 >> Cheers, >> S. >>=20 >> PS: I've not read the drafts, and couldn't make the session in >> Vancouver, so this might be entirely off topic, but in the case of >> PAWS I'd also argue that the regulators' apparent desire to force >> devices to authenticate is not necessarily the right one for the >> IETF to force upon all users of the PAWS protocol. So there could >> for example be a mode of operation where the DB signs stuff but >> doesn't care who's asking and that'd be a far far easier scenario >> in terms of automated key management. >>=20 >> [1] http://tools.ietf.org/html/bcp107 >> _______________________________________________ paws mailing list >> paws@ietf.org https://www.ietf.org/mailman/listinfo/paws > > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Mon Sep 10 11:18:33 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973A521E805D for ; Mon, 10 Sep 2012 11:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ1f1y-RmqYy for ; Mon, 10 Sep 2012 11:18:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1272A21E8049 for ; Mon, 10 Sep 2012 11:18:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJN41165; Mon, 10 Sep 2012 18:18:24 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 19:18:18 +0100 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 19:18:23 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 11:18:19 -0700 From: Peter McCann To: Peter Stanforth , Stephen Farrell , "Gabor.Bajko@nokia.com" Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAB6rQD//4r34A== Date: Mon, 10 Sep 2012 18:18:17 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AFD1@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:18:33 -0000 This is a key question we need to answer. I thought we were defining a protocol that would allow a radio from any manufacturer to interoperate with a database of any database vendor. -Pete Peter Stanforth wrote: > Pete, > I am not sure I believe in a use case where "users" move from one DB > to another. The relationship is between the radio vendor and the DBA. > The radio vendor may have multiple relationships and allow an end user > to choose one, but it will be from the predefined list. As a DBA I > don't think I would want, and in the USA we are not permitted, to > establish a relationship with a user without a preexisting > relationship with the radio vendor. So security should be primarily a rad= io vendor-DBA issue. > Wearing my DBA hat I don't think I would want to service a radio that > I do not have a preexisting relationship with it's manufacturer. I am > not sure that user relationships are even within the scope of what > PAWS should be defining. > Peter S. >=20 > On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" > wrote: >=20 >> Personally, I think that manually provisioned symmetric keys will >> severely limit the ability for users to flexibly move from one database >> provider to another. It will require some secure out-of-band channel >> on which to transmit the secret key from one party to the other, and a >> mechanism for the user to push the secret key down into the master >> device. >>=20 >> Provisioning of certificates does not require the secret channel, >> only one that is integrity protected. I think this is much easier to >> achieve in practice. >>=20 >> -Pete >>=20 >> Stephen Farrell wrote: >>>=20 >>>=20 >>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the Vancouver >>> F2F we had extensive discussions on the security model for PAWS. >>> Draft-das proposes to use shared secrets pre-provisioned in the master >>> devices for authentication, while draft-lei proposes to mandate client >>> certificates into master devices. >>>>=20 >>>> There seemed to be an understanding that the credential types in > use >>> for authentication are a matter of a business model chosen by the >>> provider which deploys white space devices, rather than a protocol >>> decision. >>>>=20 >>>> Brian mentioned that the iesg may not allow a document to be >>> published which specifies how shared secrets are used, but does not >>> have a provisioning mechanism for the shared secrets defined. In my >>> opinion, a mechanism for distributing shared secrets does not >>> necessarily have to be defined, as a shared secret can be established >>> using current practices to set up shared secrets with financial >>> institutions (using the browser). >>>> Thus, my suggestion would be to describe in the document how a >>>> shared >>> secret and how a client certificate is used to authenticate a master >>> device. Then, if we run into issues with iesg, in worst case we could >>> remove the shared secret part and keep the other one. >>>>=20 >>>> I'd like to get additional views on this topic. >>>=20 >>> I can help a little here (depending on your definition of help:-) >>>=20 >>> BCP 107 [1] is the one to look at when considering how to approach >>> automated key management requirements. That has an IMO very good >>> abstract: >>>=20 >>> The question often arises of whether a given security system >>> requires some form of automated key management, or whether manual >>> keying is sufficient. This memo provides guidelines for making >>> such decisions. When symmetric cryptographic mechanisms are used in >>> a protocol, the presumption is that automated key management is >>> generally but not always needed. If manual keying is proposed, the >>> burden of proving that automated key management is not required >>> falls to the > proposer. >>> For those that might be less familiar with IETF processes, the fact >>> that that's a BCP means that its entirely valid for an AD to >>> strenuously push back against a WG that wants to ignore what it says. >>>=20 >>> Cheers, >>> S. >>>=20 >>> PS: I've not read the drafts, and couldn't make the session in >>> Vancouver, so this might be entirely off topic, but in the case of >>> PAWS I'd also argue that the regulators' apparent desire to force >>> devices to authenticate is not necessarily the right one for the IETF >>> to force upon all users of the PAWS protocol. So there could for >>> example be a mode of operation where the DB signs stuff but doesn't >>> care who's asking and that'd be a far far easier scenario in terms of >>> automated key management. >>>=20 >>> [1] http://tools.ietf.org/html/bcp107 >>> _______________________________________________ paws mailing list >>> paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Mon Sep 10 11:38:57 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2763D21F84CD for ; Mon, 10 Sep 2012 11:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFu2kmJetPBv for ; Mon, 10 Sep 2012 11:38:56 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C6A5F21F8623 for ; Mon, 10 Sep 2012 11:38:55 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8AIcmvh008483; Mon, 10 Sep 2012 21:38:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Sep 2012 21:38:48 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.135]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0309.003; Mon, 10 Sep 2012 20:38:47 +0200 From: To: Thread-Topic: [paws] PAWS security Thread-Index: Ac2NOW8VXVfdMUhbQ7OY0lXuCEkQJ///+IcAgARu14D//9euUA== Date: Mon, 10 Sep 2012 18:38:47 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602013D72@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D@008-AM1MPN1-007.mgdnok.nokia.com> <504A724C.8050706@cs.tcd.ie> <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2012 18:38:48.0536 (UTC) FILETIME=[8437F580:01CD8F83] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:38:57 -0000 - as individual- In a deployment using shared secrets, changing the provider should not requ= ire the shared secret to be transferred between providers. The master devic= e could set up a new shared secret with the new provider. Using client certificates is not problem free either: if the master device'= s certificate is not signed by a CA whose root cert is trusted by the new p= rovider, then trust has to be established or the master needs to enroll to = get a new cert from that provider. - Gabor -----Original Message----- From: ext Peter McCann [mailto:Peter.McCann@huawei.com]=20 Sent: Monday, September 10, 2012 10:58 AM To: Stephen Farrell; Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: RE: [paws] PAWS security Personally, I think that manually provisioned symmetric keys will severely = limit the ability for users to flexibly move from one database provider to = another. It will require some secure out-of-band channel on which to trans= mit the secret key from one party to the other, and a mechanism for the use= r to push the secret key down into the master device. Provisioning of certificates does not require the secret channel, only one = that is integrity protected. I think this is much easier to achieve in pra= ctice. -Pete Stephen Farrell wrote: >=20 >=20 > On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the Vancouver=20 > F2F we had extensive discussions on the security model for PAWS. > Draft-das proposes to use shared secrets pre-provisioned in the master=20 > devices for authentication, while draft-lei proposes to mandate client=20 > certificates into master devices. >>=20 >> There seemed to be an understanding that the credential types in use > for authentication are a matter of a business model chosen by the=20 > provider which deploys white space devices, rather than a protocol=20 > decision. >>=20 >> Brian mentioned that the iesg may not allow a document to be > published > which specifies how shared secrets are used, but does not have a=20 > provisioning mechanism for the shared secrets defined. In my opinion,=20 > a mechanism for distributing shared secrets does not necessarily have=20 > to be defined, as a shared secret can be established using current=20 > practices to set up shared secrets with financial institutions (using=20 > the browser). >> Thus, my suggestion would be to describe in the document how a shared > secret and how a client certificate is used to authenticate a master=20 > device. Then, if we run into issues with iesg, in worst case we could=20 > remove the shared secret part and keep the other one. >>=20 >> I'd like to get additional views on this topic. >=20 > I can help a little here (depending on your definition of help:-) >=20 > BCP 107 [1] is the one to look at when considering how to approach=20 > automated key management requirements. That has an IMO very good=20 > abstract: >=20 > The question often arises of whether a given security system requires > some form of automated key management, or whether manual keying is > sufficient. This memo provides guidelines for making such decisions. > When symmetric cryptographic mechanisms are used in a protocol, the > presumption is that automated key management is generally but not > always needed. If manual keying is proposed, the burden of proving > that automated key management is not required falls to the proposer. > For those that might be less familiar with IETF processes, the fact=20 > that that's a BCP means that its entirely valid for an AD to=20 > strenuously push back against a WG that wants to ignore what it says. >=20 > Cheers, > S. >=20 > PS: I've not read the drafts, and couldn't make the session in=20 > Vancouver, so this might be entirely off topic, but in the case of=20 > PAWS I'd also argue that the regulators' apparent desire to force=20 > devices to authenticate is not necessarily the right one for the IETF=20 > to force upon all users of the PAWS protocol. So there could for=20 > example be a mode of operation where the DB signs stuff but doesn't=20 > care who's asking and that'd be a far far easier scenario in terms of=20 > automated key management. >=20 > [1] http://tools.ietf.org/html/bcp107 > _______________________________________________ paws mailing list=20 > paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Mon Sep 10 11:40:54 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B6521F867A for ; Mon, 10 Sep 2012 11:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo4tO10JOd5B for ; Mon, 10 Sep 2012 11:40:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6428421F865B for ; Mon, 10 Sep 2012 11:40:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJN42292; Mon, 10 Sep 2012 18:40:52 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 19:40:46 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 19:40:51 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 11:40:48 -0700 From: Peter McCann To: "Gabor.Bajko@nokia.com" Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgACBSYD//4rcsA== Date: Mon, 10 Sep 2012 18:40:48 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E2B009@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D@008-AM1MPN1-007.mgdnok.nokia.com> <504A724C.8050706@cs.tcd.ie> <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602013D72@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47602013D72@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:40:55 -0000 Sure, a new shared secret can be assigned by the new provider. However, some sort of confidential channel must be provided to communicate the shared secret from one side to the other. In contrast, a certificate signing request does not need confidentiality, only integrity protection. -Pete Gabor.Bajko@nokia.com wrote: > - as individual- > In a deployment using shared secrets, changing the provider should not > require the shared secret to be transferred between providers. The > master device could set up a new shared secret with the new provider. > Using client certificates is not problem free either: if the master > device's certificate is not signed by a CA whose root cert is trusted > by the new provider, then trust has to be established or the master > needs to enroll to get a new cert from that provider. > - Gabor >=20 >=20 > -----Original Message----- > From: ext Peter McCann [mailto:Peter.McCann@huawei.com] > Sent: Monday, September 10, 2012 10:58 AM > To: Stephen Farrell; Bajko Gabor (Nokia-CIC/SiliconValley) > Cc: paws@ietf.org > Subject: RE: [paws] PAWS security >=20 > Personally, I think that manually provisioned symmetric keys will > severely limit the ability for users to flexibly move from one > database provider to another. It will require some secure out-of-band > channel on which to transmit the secret key from one party to the > other, and a mechanism for the user to push the secret key down into > the master device. >=20 > Provisioning of certificates does not require the secret channel, only > one that is integrity protected. I think this is much easier to > achieve in practice. >=20 > -Pete >=20 > Stephen Farrell wrote: >>=20 >>=20 >> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the Vancouver >> F2F we had extensive discussions on the security model for PAWS. >> Draft-das proposes to use shared secrets pre-provisioned in the master >> devices for authentication, while draft-lei proposes to mandate client >> certificates into master devices. >>>=20 >>> There seemed to be an understanding that the credential types in >>> use >> for authentication are a matter of a business model chosen by the >> provider which deploys white space devices, rather than a protocol >> decision. >>>=20 >>> Brian mentioned that the iesg may not allow a document to be >> published >> which specifies how shared secrets are used, but does not have a >> provisioning mechanism for the shared secrets defined. In my >> opinion, a mechanism for distributing shared secrets does not >> necessarily have to be defined, as a shared secret can be >> established using current practices to set up shared secrets with >> financial institutions (using the browser). >>> Thus, my suggestion would be to describe in the document how a > shared >> secret and how a client certificate is used to authenticate a master >> device. Then, if we run into issues with iesg, in worst case we >> could remove the shared secret part and keep the other one. >>>=20 >>> I'd like to get additional views on this topic. >>=20 >> I can help a little here (depending on your definition of help:-) >>=20 >> BCP 107 [1] is the one to look at when considering how to approach >> automated key management requirements. That has an IMO very good >> abstract: >>=20 >> The question often arises of whether a given security system >> requires some form of automated key management, or whether manual >> keying is sufficient. This memo provides guidelines for making such >> decisions. When symmetric cryptographic mechanisms are used in a >> protocol, the presumption is that automated key management is >> generally but not always needed. If manual keying is proposed, the >> burden of proving that automated key management is not required >> falls to the > proposer. >> For those that might be less familiar with IETF processes, the fact >> that that's a BCP means that its entirely valid for an AD to >> strenuously push back against a WG that wants to ignore what it says. >>=20 >> Cheers, >> S. >>=20 >> PS: I've not read the drafts, and couldn't make the session in >> Vancouver, so this might be entirely off topic, but in the case of >> PAWS I'd also argue that the regulators' apparent desire to force >> devices to authenticate is not necessarily the right one for the >> IETF to force upon all users of the PAWS protocol. So there could >> for example be a mode of operation where the DB signs stuff but >> doesn't care who's asking and that'd be a far far easier scenario in >> terms of automated key management. >>=20 >> [1] http://tools.ietf.org/html/bcp107 >> _______________________________________________ paws mailing list >> paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >=20 > From paul@marvell.com Mon Sep 10 11:44:15 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C5421F86FD for ; Mon, 10 Sep 2012 11:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uES65RyNOwYV for ; Mon, 10 Sep 2012 11:44:14 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6099A21F86F6 for ; Mon, 10 Sep 2012 11:44:10 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUE409UN3Y1cKaQ68tOjqFUUglBxt92q8@postini.com; Mon, 10 Sep 2012 11:44:14 PDT Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Sep 2012 11:39:51 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 10 Sep 2012 11:39:51 -0700 From: Paul Lambert To: Peter McCann , Stephen Farrell , "Gabor.Bajko@nokia.com" Date: Mon, 10 Sep 2012 11:39:56 -0700 Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAAKs8A= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E4681A73@SC-VEXCH2.marvell.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200FD5D@008-AM1MPN1-007.mgdnok.nokia.com> <504A724C.8050706@cs.tcd.ie> <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AF9B@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:44:15 -0000 > Personally, I think that manually provisioned symmetric keys will > severely limit the ability for users to flexibly move from one database > provider to another. It will require some secure out-of-band channel > on which to transmit the secret key from one party to the other, and a > mechanism for the user to push the secret key down into the master > device. Yes!!! Distributing symmetric keys is a really bad idea for PAWS. =20 They scale poorly, are more difficult to manage, and are more=20 readily subject to misuse. Paul >=20 > Provisioning of certificates does not require the secret channel, only > one that is integrity protected. I think this is much easier to > achieve in practice. >=20 > -Pete >=20 > Stephen Farrell wrote: > > > > > > On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the > Vancouver > > F2F we had extensive discussions on the security model for PAWS. > > Draft-das proposes to use shared secrets pre-provisioned in the > master > > devices for authentication, while draft-lei proposes to mandate > client > > certificates into master devices. > >> > >> There seemed to be an understanding that the credential types in use > > for authentication are a matter of a business model chosen by the > > provider which deploys white space devices, rather than a protocol > > decision. > >> > >> Brian mentioned that the iesg may not allow a document to be > > published > > which specifies how shared secrets are used, but does not have a > > provisioning mechanism for the shared secrets defined. In my opinion, > > a mechanism for distributing shared secrets does not necessarily have > > to be defined, as a shared secret can be established using current > > practices to set up shared secrets with financial institutions (using > > the browser). > >> Thus, my suggestion would be to describe in the document how a > shared > > secret and how a client certificate is used to authenticate a master > > device. Then, if we run into issues with iesg, in worst case we could > > remove the shared secret part and keep the other one. > >> > >> I'd like to get additional views on this topic. > > > > I can help a little here (depending on your definition of help:-) > > > > BCP 107 [1] is the one to look at when considering how to approach > > automated key management requirements. That has an IMO very good > > abstract: > > > > The question often arises of whether a given security system > requires > > some form of automated key management, or whether manual keying is > > sufficient. This memo provides guidelines for making such > decisions. > > When symmetric cryptographic mechanisms are used in a protocol, > the > > presumption is that automated key management is generally but not > > always needed. If manual keying is proposed, the burden of > proving > > that automated key management is not required falls to the > proposer. > > For those that might be less familiar with IETF processes, the fact > > that that's a BCP means that its entirely valid for an AD to > > strenuously push back against a WG that wants to ignore what it says. > > > > Cheers, > > S. > > > > PS: I've not read the drafts, and couldn't make the session in > > Vancouver, so this might be entirely off topic, but in the case of > > PAWS I'd also argue that the regulators' apparent desire to force > > devices to authenticate is not necessarily the right one for the IETF > > to force upon all users of the PAWS protocol. So there could for > > example be a mode of operation where the DB signs stuff but doesn't > > care who's asking and that'd be a far far easier scenario in terms of > > automated key management. > > > > [1] http://tools.ietf.org/html/bcp107 > > _______________________________________________ paws mailing list > > paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Mon Sep 10 11:44:47 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851B021F86F7 for ; Mon, 10 Sep 2012 11:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLLdXxT-Eb-I for ; Mon, 10 Sep 2012 11:44:46 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 225F121F86FD for ; Mon, 10 Sep 2012 11:44:45 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 10 Sep 2012 14:44:44 -0400 From: Peter Stanforth To: Peter McCann , Stephen Farrell , "Gabor.Bajko@nokia.com" Date: Mon, 10 Sep 2012 14:44:38 -0400 Thread-Topic: [paws] PAWS security Thread-Index: Ac2PhFebAKfZlP57T/eVzgHsbf3gCw== Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AFD1@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:44:47 -0000 I completely agree with your statement below. If we are good any radio will have the "Technical" capability to work with any database. BUT, and this is a big BUT, the regulation may not allow it - The FCC does not today. And as a DBA I only want to work with devices where I have a predefined relationship. Not least of which, because as I am authorized by a Regulator I want to make sure I am doing everything I can to avoid their wrath. This has come up before. PAWS is defining an API/Protocol, not the regulation nor the business cases at this time. So I still say that we can comply with your statement without considering a "User". On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" wrote: >This is a key question we need to answer. > >I thought we were defining a protocol that would allow a radio from any >manufacturer to interoperate with a database of any database vendor. > >-Pete > >Peter Stanforth wrote: >> Pete, >> I am not sure I believe in a use case where "users" move from one DB >> to another. The relationship is between the radio vendor and the DBA. >> The radio vendor may have multiple relationships and allow an end user >> to choose one, but it will be from the predefined list. As a DBA I >> don't think I would want, and in the USA we are not permitted, to >> establish a relationship with a user without a preexisting >> relationship with the radio vendor. So security should be primarily a >>radio vendor-DBA issue. >> Wearing my DBA hat I don't think I would want to service a radio that >> I do not have a preexisting relationship with it's manufacturer. I am >> not sure that user relationships are even within the scope of what >> PAWS should be defining. >> Peter S. >>=20 >> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" >> wrote: >>=20 >>> Personally, I think that manually provisioned symmetric keys will >>> severely limit the ability for users to flexibly move from one database >>> provider to another. It will require some secure out-of-band channel >>> on which to transmit the secret key from one party to the other, and a >>> mechanism for the user to push the secret key down into the master >>> device. >>>=20 >>> Provisioning of certificates does not require the secret channel, >>> only one that is integrity protected. I think this is much easier to >>> achieve in practice. >>>=20 >>> -Pete >>>=20 >>> Stephen Farrell wrote: >>>>=20 >>>>=20 >>>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the Vancouver >>>> F2F we had extensive discussions on the security model for PAWS. >>>> Draft-das proposes to use shared secrets pre-provisioned in the master >>>> devices for authentication, while draft-lei proposes to mandate client >>>> certificates into master devices. >>>>>=20 >>>>> There seemed to be an understanding that the credential types in >> use >>>> for authentication are a matter of a business model chosen by the >>>> provider which deploys white space devices, rather than a protocol >>>> decision. >>>>>=20 >>>>> Brian mentioned that the iesg may not allow a document to be >>>> published which specifies how shared secrets are used, but does not >>>> have a provisioning mechanism for the shared secrets defined. In my >>>> opinion, a mechanism for distributing shared secrets does not >>>> necessarily have to be defined, as a shared secret can be established >>>> using current practices to set up shared secrets with financial >>>> institutions (using the browser). >>>>> Thus, my suggestion would be to describe in the document how a >>>>> shared >>>> secret and how a client certificate is used to authenticate a master >>>> device. Then, if we run into issues with iesg, in worst case we could >>>> remove the shared secret part and keep the other one. >>>>>=20 >>>>> I'd like to get additional views on this topic. >>>>=20 >>>> I can help a little here (depending on your definition of help:-) >>>>=20 >>>> BCP 107 [1] is the one to look at when considering how to approach >>>> automated key management requirements. That has an IMO very good >>>> abstract: >>>>=20 >>>> The question often arises of whether a given security system >>>> requires some form of automated key management, or whether manual >>>> keying is sufficient. This memo provides guidelines for making >>>> such decisions. When symmetric cryptographic mechanisms are used in >>>> a protocol, the presumption is that automated key management is >>>> generally but not always needed. If manual keying is proposed, the >>>> burden of proving that automated key management is not required >>>> falls to the >> proposer. >>>> For those that might be less familiar with IETF processes, the fact >>>> that that's a BCP means that its entirely valid for an AD to >>>> strenuously push back against a WG that wants to ignore what it says. >>>>=20 >>>> Cheers, >>>> S. >>>>=20 >>>> PS: I've not read the drafts, and couldn't make the session in >>>> Vancouver, so this might be entirely off topic, but in the case of >>>> PAWS I'd also argue that the regulators' apparent desire to force >>>> devices to authenticate is not necessarily the right one for the IETF >>>> to force upon all users of the PAWS protocol. So there could for >>>> example be a mode of operation where the DB signs stuff but doesn't >>>> care who's asking and that'd be a far far easier scenario in terms of >>>> automated key management. >>>>=20 >>>> [1] http://tools.ietf.org/html/bcp107 >>>> _______________________________________________ paws mailing list >>>> paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws > > > From Peter.McCann@huawei.com Mon Sep 10 11:50:07 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A06621E8064 for ; Mon, 10 Sep 2012 11:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOmMN0DOsMm6 for ; Mon, 10 Sep 2012 11:50:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96E6F21E8049 for ; Mon, 10 Sep 2012 11:50:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKN49226; Mon, 10 Sep 2012 18:50:04 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 19:48:21 +0100 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Sep 2012 02:48:20 +0800 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 11:48:14 -0700 From: Peter McCann To: Peter Stanforth , Stephen Farrell , "Gabor.Bajko@nokia.com" Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAB6rQD//4r34IAAfUcA//+LN1A= Date: Mon, 10 Sep 2012 18:48:13 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E2B022@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AFD1@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:50:07 -0000 This restriction may hold today for the FCC, but I have a hard time believing that a pre-existing manufacturer-database relationship will be mandatory in every regulatory domain for the forseeable future. I think we should design to minimize the friction in changing database providers. -Pete Peter Stanforth wrote: > I completely agree with your statement below. If we are good any radio > will have the "Technical" capability to work with any database. > BUT, and this is a big BUT, the regulation may not allow it - The FCC > does not today. And as a DBA I only want to work with devices where I > have a predefined relationship. Not least of which, because as I am > authorized by a Regulator I want to make sure I am doing everything I > can to avoid their wrath. > This has come up before. PAWS is defining an API/Protocol, not the > regulation nor the business cases at this time. So I still say that we > can comply with your statement without considering a "User". >=20 > On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" > wrote: >=20 >> This is a key question we need to answer. >>=20 >> I thought we were defining a protocol that would allow a radio from any >> manufacturer to interoperate with a database of any database vendor. >>=20 >> -Pete >>=20 >> Peter Stanforth wrote: >>> Pete, I am not sure I believe in a use case where "users" move from >>> one DB to another. The relationship is between the radio vendor and >>> the DBA. The radio vendor may have multiple relationships and allow an >>> end user to choose one, but it will be from the predefined list. As a >>> DBA I don't think I would want, and in the USA we are not permitted, >>> to establish a relationship with a user without a preexisting >>> relationship with the radio vendor. So security should be primarily a >>> radio vendor-DBA issue. Wearing my DBA hat I don't think I would want >>> to service a radio that I do not have a preexisting relationship with >>> it's manufacturer. I am not sure that user relationships are even >>> within the scope of what PAWS should be defining. Peter S. >>>=20 >>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" >>> wrote: >>>=20 >>>> Personally, I think that manually provisioned symmetric keys will >>>> severely limit the ability for users to flexibly move from one >>>> database provider to another. It will require some secure >>>> out-of-band channel on which to transmit the secret key from one >>>> party to the other, and a mechanism for the user to push the >>>> secret key down into the master device. >>>>=20 >>>> Provisioning of certificates does not require the secret channel, >>>> only one that is integrity protected. I think this is much easier >>>> to achieve in practice. >>>>=20 >>>> -Pete >>>>=20 >>>> Stephen Farrell wrote: >>>>>=20 >>>>>=20 >>>>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the >>>>> Vancouver F2F we had extensive discussions on the security model for >>>>> PAWS. Draft-das proposes to use shared secrets pre-provisioned in >>>>> the master devices for authentication, while draft-lei proposes to >>>>> mandate client certificates into master devices. >>>>>>=20 >>>>>> There seemed to be an understanding that the credential types in >>> use >>>>> for authentication are a matter of a business model chosen by the >>>>> provider which deploys white space devices, rather than a >>>>> protocol decision. >>>>>>=20 >>>>>> Brian mentioned that the iesg may not allow a document to be >>>>> published which specifies how shared secrets are used, but does not >>>>> have a provisioning mechanism for the shared secrets defined. In my >>>>> opinion, a mechanism for distributing shared secrets does not >>>>> necessarily have to be defined, as a shared secret can be >>>>> established using current practices to set up shared secrets with >>>>> financial institutions (using the browser). >>>>>> Thus, my suggestion would be to describe in the document how a >>>>>> shared >>>>> secret and how a client certificate is used to authenticate a master >>>>> device. Then, if we run into issues with iesg, in worst case we >>>>> could remove the shared secret part and keep the other one. >>>>>>=20 >>>>>> I'd like to get additional views on this topic. >>>>>=20 >>>>> I can help a little here (depending on your definition of help:-) >>>>>=20 >>>>> BCP 107 [1] is the one to look at when considering how to >>>>> approach automated key management requirements. That has an IMO >>>>> very good >>>>> abstract: >>>>>=20 >>>>> The question often arises of whether a given security system >>>>> requires some form of automated key management, or whether manual >>>>> keying is sufficient. This memo provides guidelines for making >>>>> such decisions. When symmetric cryptographic mechanisms are used >>>>> in a protocol, the presumption is that automated key management >>>>> is generally but not always needed. If manual keying is >>>>> proposed, > the >>>>> burden of proving that automated key management is not required >>>>> falls to the >>> proposer. >>>>> For those that might be less familiar with IETF processes, the fact >>>>> that that's a BCP means that its entirely valid for an AD to >>>>> strenuously push back against a WG that wants to ignore what it says. >>>>>=20 >>>>> Cheers, >>>>> S. >>>>>=20 >>>>> PS: I've not read the drafts, and couldn't make the session in >>>>> Vancouver, so this might be entirely off topic, but in the case >>>>> of PAWS I'd also argue that the regulators' apparent desire to >>>>> force devices to authenticate is not necessarily the right one >>>>> for the IETF to force upon all users of the PAWS protocol. So >>>>> there could for example be a mode of operation where the DB signs >>>>> stuff but doesn't care who's asking and that'd be a far far >>>>> easier scenario in terms of automated key management. >>>>>=20 >>>>> [1] http://tools.ietf.org/html/bcp107 >>>>> _______________________________________________ paws mailing list >>>>> paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>=20 >>=20 >> From paul@marvell.com Mon Sep 10 12:14:58 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9245D21E808E for ; Mon, 10 Sep 2012 12:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1iClX5tPmkI for ; Mon, 10 Sep 2012 12:14:57 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id A615821E8089 for ; Mon, 10 Sep 2012 12:14:57 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUE47eYQ+TSjaeKEQUnx+Ev2uW7qGjEyv@postini.com; Mon, 10 Sep 2012 12:14:57 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 10 Sep 2012 12:03:01 -0700 From: Paul Lambert To: Peter McCann , Peter Stanforth , Stephen Farrell , "Gabor.Bajko@nokia.com" Date: Mon, 10 Sep 2012 12:03:05 -0700 Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAB6rQD//4r34IAAfUcA//+LN1CAAAMcAA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E4681A9A@SC-VEXCH2.marvell.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716E2AFD1@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E2B022@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2B022@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:14:58 -0000 =20 > This restriction may hold today for the FCC, but I have a hard time > believing that a pre-existing manufacturer-database relationship will > be mandatory in every regulatory domain for the forseeable future. I > think we should design to minimize the friction in changing database > providers. The least friction would be to hardwire devices with a=20 PK "root" for each regulatory domain that the device supports. Valid DBs would have credentials signed by the key holder of roots for each regulatory domain Paul > -Pete >=20 > Peter Stanforth wrote: > > I completely agree with your statement below. If we are good any > radio > > will have the "Technical" capability to work with any database. > > BUT, and this is a big BUT, the regulation may not allow it - The FCC > > does not today. And as a DBA I only want to work with devices where I > > have a predefined relationship. Not least of which, because as I am > > authorized by a Regulator I want to make sure I am doing everything I > > can to avoid their wrath. > > This has come up before. PAWS is defining an API/Protocol, not the > > regulation nor the business cases at this time. So I still say that > we > > can comply with your statement without considering a "User". > > > > On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" > > wrote: > > > >> This is a key question we need to answer. > >> > >> I thought we were defining a protocol that would allow a radio from > >> any manufacturer to interoperate with a database of any database > vendor. > >> > >> -Pete > >> > >> Peter Stanforth wrote: > >>> Pete, I am not sure I believe in a use case where "users" move from > >>> one DB to another. The relationship is between the radio vendor and > >>> the DBA. The radio vendor may have multiple relationships and allow > >>> an end user to choose one, but it will be from the predefined > list. > >>> As a DBA I don't think I would want, and in the USA we are not > >>> permitted, to establish a relationship with a user without a > >>> preexisting relationship with the radio vendor. So security should > >>> be primarily a radio vendor-DBA issue. Wearing my DBA hat I don't > >>> think I would want to service a radio that I do not have a > >>> preexisting relationship with it's manufacturer. I am not sure > that > >>> user relationships are even within the scope of what PAWS should be > defining. Peter S. > >>> > >>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" > >>> wrote: > >>> > >>>> Personally, I think that manually provisioned symmetric keys will > >>>> severely limit the ability for users to flexibly move from one > >>>> database provider to another. It will require some secure > >>>> out-of-band channel on which to transmit the secret key from one > >>>> party to the other, and a mechanism for the user to push the > secret > >>>> key down into the master device. > >>>> > >>>> Provisioning of certificates does not require the secret channel, > >>>> only one that is integrity protected. I think this is much easier > >>>> to achieve in practice. > >>>> > >>>> -Pete > >>>> > >>>> Stephen Farrell wrote: > >>>>> > >>>>> > >>>>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the > >>>>> Vancouver F2F we had extensive discussions on the security model > >>>>> for PAWS. Draft-das proposes to use shared secrets pre- > provisioned > >>>>> in the master devices for authentication, while draft-lei > proposes > >>>>> to mandate client certificates into master devices. > >>>>>> > >>>>>> There seemed to be an understanding that the credential types in > >>> use > >>>>> for authentication are a matter of a business model chosen by the > >>>>> provider which deploys white space devices, rather than a > protocol > >>>>> decision. > >>>>>> > >>>>>> Brian mentioned that the iesg may not allow a document to be > >>>>> published which specifies how shared secrets are used, but does > >>>>> not have a provisioning mechanism for the shared secrets defined. > >>>>> In my opinion, a mechanism for distributing shared secrets does > >>>>> not necessarily have to be defined, as a shared secret can be > >>>>> established using current practices to set up shared secrets with > >>>>> financial institutions (using the browser). > >>>>>> Thus, my suggestion would be to describe in the document how a > >>>>>> shared > >>>>> secret and how a client certificate is used to authenticate a > >>>>> master device. Then, if we run into issues with iesg, in worst > >>>>> case we could remove the shared secret part and keep the other > one. > >>>>>> > >>>>>> I'd like to get additional views on this topic. > >>>>> > >>>>> I can help a little here (depending on your definition of help:-) > >>>>> > >>>>> BCP 107 [1] is the one to look at when considering how to > approach > >>>>> automated key management requirements. That has an IMO very good > >>>>> abstract: > >>>>> > >>>>> The question often arises of whether a given security system > >>>>> requires some form of automated key management, or whether > manual > >>>>> keying is sufficient. This memo provides guidelines for > making > >>>>> such decisions. When symmetric cryptographic mechanisms are > used > >>>>> in a protocol, the presumption is that automated key > management > >>>>> is generally but not always needed. If manual keying is > >>>>> proposed, > > the > >>>>> burden of proving that automated key management is not > required > >>>>> falls to the > >>> proposer. > >>>>> For those that might be less familiar with IETF processes, the > >>>>> fact that that's a BCP means that its entirely valid for an AD to > >>>>> strenuously push back against a WG that wants to ignore what it > says. > >>>>> > >>>>> Cheers, > >>>>> S. > >>>>> > >>>>> PS: I've not read the drafts, and couldn't make the session in > >>>>> Vancouver, so this might be entirely off topic, but in the case > of > >>>>> PAWS I'd also argue that the regulators' apparent desire to force > >>>>> devices to authenticate is not necessarily the right one for the > >>>>> IETF to force upon all users of the PAWS protocol. So there could > >>>>> for example be a mode of operation where the DB signs stuff but > >>>>> doesn't care who's asking and that'd be a far far easier scenario > >>>>> in terms of automated key management. > >>>>> > >>>>> [1] http://tools.ietf.org/html/bcp107 > >>>>> _______________________________________________ paws mailing list > >>>>> paws@ietf.org https://www.ietf.org/mailman/listinfo/paws > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> paws mailing list > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >> > >> > >> >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Sep 10 12:18:43 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D0C21E8095 for ; Mon, 10 Sep 2012 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+j2PLFt3PDZ for ; Mon, 10 Sep 2012 12:18:42 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 562D521E808E for ; Mon, 10 Sep 2012 12:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347304824; x=1662655462; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Oo9oq+oTH33XJtu5YPPyN RYtjWZuu2v/uqQpj12LZ4w=; b=QZbB988jAs4AJk4nJApQNDwNfhaaPPi7R60U9 B5YzRlouTOBr1i2KrVAzAVjy7PZmmoYIoPJE/ulw+A4xAWUMQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.13554404; Mon, 10 Sep 2012 15:20:23 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 10 Sep 2012 15:18:28 -0400 From: "Rosen, Brian" To: 'Paul Lambert' , 'Peter McCann' , 'Peter Stanforth' , 'Stephen Farrell' , "'Gabor.Bajko@nokia.com'" Date: Mon, 10 Sep 2012 15:18:27 -0400 Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAB6rQD//4r34IAAfUcA//+LN1CAAAMcAIAABciB Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227D5@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: LQGCvC+mVBahx/tf5hi3jQ== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 19:18:43 -0000 VGhlIGVhc2llc3Qgd2F5IHRvIGRvIHRoaXMgaXMgdG8gaGF2ZSB0aGUgbWFudWZhY3R1cmVyIHB1 dCBhIGNlcnQgaW4gdGhlIGRldmljZSB0aGF0IGl0IHNpZ25zLiAgVGhlbiB0aGUgb25seSB0aGlu ZyB0aGUgZGF0YWJhc2UgbmVlZHMgaXMgdGhlIHB1YmxpYyBrZXkgb2YgdGhlIG1hbnVmYWN0dXJl ciwKCldoeSBkbyB3ZSB3YW50IHRvIG1ha2UgdGhpcyBoYXJkZXI/CgpCZWNhdXNlIHNvbWUgbWFu dWZhY3R1cmVycyB0aGluayBpdHMgdG9vIG11Y2ggd29yayB0byBkbyB0aGF0PwoKQnJpYW4KCg0K DQogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlQYXVsIExhbWJlcnQgW21haWx0 bzpwYXVsQG1hcnZlbGwuY29tXQ0KU2VudDoJTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgMDM6 MTUgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzoJUGV0ZXIgTWNDYW5uOyBQZXRlciBTdGFu Zm9ydGg7IFN0ZXBoZW4gRmFycmVsbDsgR2Fib3IuQmFqa29Abm9raWEuY29tDQpDYzoJcGF3c0Bp ZXRmLm9yZw0KU3ViamVjdDoJUmU6IFtwYXdzXSBQQVdTIHNlY3VyaXR5DQoNCiANCj4gVGhpcyBy ZXN0cmljdGlvbiBtYXkgaG9sZCB0b2RheSBmb3IgdGhlIEZDQywgYnV0IEkgaGF2ZSBhIGhhcmQg dGltZQ0KPiBiZWxpZXZpbmcgdGhhdCBhIHByZS1leGlzdGluZyBtYW51ZmFjdHVyZXItZGF0YWJh c2UgcmVsYXRpb25zaGlwIHdpbGwNCj4gYmUgbWFuZGF0b3J5IGluIGV2ZXJ5IHJlZ3VsYXRvcnkg ZG9tYWluIGZvciB0aGUgZm9yc2VlYWJsZSBmdXR1cmUuICBJDQo+IHRoaW5rIHdlIHNob3VsZCBk ZXNpZ24gdG8gbWluaW1pemUgdGhlIGZyaWN0aW9uIGluIGNoYW5naW5nIGRhdGFiYXNlDQo+IHBy b3ZpZGVycy4NCg0KVGhlIGxlYXN0IGZyaWN0aW9uIHdvdWxkIGJlIHRvIGhhcmR3aXJlIGRldmlj ZXMgd2l0aCBhIA0KUEsgInJvb3QiIGZvciBlYWNoIHJlZ3VsYXRvcnkgZG9tYWluIHRoYXQgdGhl IGRldmljZSBzdXBwb3J0cy4NCg0KVmFsaWQgREJzIHdvdWxkIGhhdmUgY3JlZGVudGlhbHMgc2ln bmVkIGJ5IHRoZSBrZXkgaG9sZGVyIG9mDQpyb290cyBmb3IgZWFjaCByZWd1bGF0b3J5IGRvbWFp bg0KDQpQYXVsDQoNCg0KPiAtUGV0ZQ0KPiANCj4gUGV0ZXIgU3RhbmZvcnRoIHdyb3RlOg0KPiA+ IEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IGJlbG93LiBJZiB3ZSBhcmUg Z29vZCBhbnkNCj4gcmFkaW8NCj4gPiB3aWxsIGhhdmUgdGhlICJUZWNobmljYWwiIGNhcGFiaWxp dHkgdG8gd29yayB3aXRoIGFueSBkYXRhYmFzZS4NCj4gPiBCVVQsIGFuZCB0aGlzIGlzIGEgYmln IEJVVCwgdGhlIHJlZ3VsYXRpb24gbWF5IG5vdCBhbGxvdyBpdCAtIFRoZSBGQ0MNCj4gPiBkb2Vz IG5vdCB0b2RheS4gQW5kIGFzIGEgREJBIEkgb25seSB3YW50IHRvIHdvcmsgd2l0aCBkZXZpY2Vz IHdoZXJlIEkNCj4gPiBoYXZlIGEgcHJlZGVmaW5lZCByZWxhdGlvbnNoaXAuIE5vdCBsZWFzdCBv ZiB3aGljaCwgYmVjYXVzZSBhcyBJIGFtDQo+ID4gYXV0aG9yaXplZCBieSBhIFJlZ3VsYXRvciBJ IHdhbnQgdG8gbWFrZSBzdXJlIEkgYW0gZG9pbmcgZXZlcnl0aGluZyBJDQo+ID4gY2FuIHRvIGF2 b2lkIHRoZWlyIHdyYXRoLg0KPiA+IFRoaXMgaGFzIGNvbWUgdXAgYmVmb3JlLiBQQVdTIGlzIGRl ZmluaW5nIGFuIEFQSS9Qcm90b2NvbCwgbm90IHRoZQ0KPiA+IHJlZ3VsYXRpb24gbm9yIHRoZSBi dXNpbmVzcyBjYXNlcyBhdCB0aGlzIHRpbWUuIFNvIEkgc3RpbGwgc2F5IHRoYXQNCj4gd2UNCj4g PiBjYW4gY29tcGx5IHdpdGggeW91ciBzdGF0ZW1lbnQgd2l0aG91dCBjb25zaWRlcmluZyBhICJV c2VyIi4NCj4gPg0KPiA+IE9uIE1vblNlcC8xMC8xMiBNb24gU2VwIDEwLCAyOjE4IFBNLCAiUGV0 ZXIgTWNDYW5uIg0KPiA+IDxQZXRlci5NY0Nhbm5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4g Pj4gVGhpcyBpcyBhIGtleSBxdWVzdGlvbiB3ZSBuZWVkIHRvIGFuc3dlci4NCj4gPj4NCj4gPj4g SSB0aG91Z2h0IHdlIHdlcmUgZGVmaW5pbmcgYSBwcm90b2NvbCB0aGF0IHdvdWxkIGFsbG93IGEg cmFkaW8gZnJvbQ0KPiA+PiBhbnkgbWFudWZhY3R1cmVyIHRvIGludGVyb3BlcmF0ZSB3aXRoIGEg ZGF0YWJhc2Ugb2YgYW55IGRhdGFiYXNlDQo+IHZlbmRvci4NCj4gPj4NCj4gPj4gLVBldGUNCj4g Pj4NCj4gPj4gUGV0ZXIgU3RhbmZvcnRoIHdyb3RlOg0KPiA+Pj4gUGV0ZSwgSSBhbSBub3Qgc3Vy ZSBJIGJlbGlldmUgaW4gYSB1c2UgY2FzZSB3aGVyZSAidXNlcnMiIG1vdmUgZnJvbQ0KPiA+Pj4g b25lIERCIHRvIGFub3RoZXIuIFRoZSByZWxhdGlvbnNoaXAgaXMgYmV0d2VlbiB0aGUgcmFkaW8g dmVuZG9yIGFuZA0KPiA+Pj4gdGhlIERCQS4gVGhlIHJhZGlvIHZlbmRvciBtYXkgaGF2ZSBtdWx0 aXBsZSByZWxhdGlvbnNoaXBzIGFuZCBhbGxvdw0KPiA+Pj4gYW4gZW5kIHVzZXIgIHRvIGNob29z ZSBvbmUsIGJ1dCBpdCB3aWxsIGJlIGZyb20gdGhlIHByZWRlZmluZWQNCj4gbGlzdC4NCj4gPj4+ IEFzIGEgREJBIEkgIGRvbid0IHRoaW5rIEkgd291bGQgd2FudCwgYW5kIGluIHRoZSBVU0Egd2Ug YXJlIG5vdA0KPiA+Pj4gcGVybWl0dGVkLCB0byBlc3RhYmxpc2ggYSByZWxhdGlvbnNoaXAgd2l0 aCBhIHVzZXIgd2l0aG91dCBhDQo+ID4+PiBwcmVleGlzdGluZyByZWxhdGlvbnNoaXAgd2l0aCB0 aGUgcmFkaW8gdmVuZG9yLiBTbyBzZWN1cml0eSBzaG91bGQNCj4gPj4+IGJlIHByaW1hcmlseSBh IHJhZGlvIHZlbmRvci1EQkEgaXNzdWUuIFdlYXJpbmcgbXkgREJBIGhhdCBJIGRvbid0DQo+ID4+ PiB0aGluayBJIHdvdWxkIHdhbnQgdG8gc2VydmljZSBhIHJhZGlvIHRoYXQgSSBkbyBub3QgaGF2 ZSBhDQo+ID4+PiBwcmVleGlzdGluZyByZWxhdGlvbnNoaXAgd2l0aCBpdCdzIG1hbnVmYWN0dXJl ci4gIEkgYW0gbm90IHN1cmUNCj4gdGhhdA0KPiA+Pj4gdXNlciByZWxhdGlvbnNoaXBzIGFyZSBl dmVuIHdpdGhpbiB0aGUgc2NvcGUgb2Ygd2hhdCBQQVdTIHNob3VsZCBiZQ0KPiBkZWZpbmluZy4g UGV0ZXIgUy4NCj4gPj4+DQo+ID4+PiBPbiBNb25TZXAvMTAvMTIgTW9uIFNlcCAxMCwgMTo1OCBQ TSwgIlBldGVyIE1jQ2FubiINCj4gPj4+IDxQZXRlci5NY0Nhbm5AaHVhd2VpLmNvbT4gd3JvdGU6 DQo+ID4+Pg0KPiA+Pj4+IFBlcnNvbmFsbHksIEkgdGhpbmsgdGhhdCBtYW51YWxseSBwcm92aXNp b25lZCBzeW1tZXRyaWMga2V5cyB3aWxsDQo+ID4+Pj4gc2V2ZXJlbHkgbGltaXQgdGhlIGFiaWxp dHkgZm9yIHVzZXJzIHRvIGZsZXhpYmx5IG1vdmUgZnJvbSBvbmUNCj4gPj4+PiBkYXRhYmFzZSBw cm92aWRlciB0byBhbm90aGVyLiAgSXQgd2lsbCByZXF1aXJlIHNvbWUgc2VjdXJlDQo+ID4+Pj4g b3V0LW9mLWJhbmQgY2hhbm5lbCBvbiB3aGljaCB0byB0cmFuc21pdCB0aGUgc2VjcmV0IGtleSBm cm9tIG9uZQ0KPiA+Pj4+IHBhcnR5IHRvIHRoZSBvdGhlciwgYW5kIGEgbWVjaGFuaXNtIGZvciB0 aGUgdXNlciB0byBwdXNoIHRoZQ0KPiBzZWNyZXQNCj4gPj4+PiBrZXkgZG93biBpbnRvIHRoZSBt YXN0ZXIgZGV2aWNlLg0KPiA+Pj4+DQo+ID4+Pj4gUHJvdmlzaW9uaW5nIG9mIGNlcnRpZmljYXRl cyBkb2VzIG5vdCByZXF1aXJlIHRoZSBzZWNyZXQgY2hhbm5lbCwNCj4gPj4+PiBvbmx5IG9uZSB0 aGF0IGlzIGludGVncml0eSBwcm90ZWN0ZWQuICBJIHRoaW5rIHRoaXMgaXMgbXVjaCBlYXNpZXIN Cj4gPj4+PiB0byBhY2hpZXZlIGluIHByYWN0aWNlLg0KPiA+Pj4+DQo+ID4+Pj4gLVBldGUNCj4g Pj4+Pg0KPiA+Pj4+IFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4g Pj4+Pj4gT24gMDkvMDcvMjAxMiAxMDowMSBQTSwgR2Fib3IuQmFqa29Abm9raWEuY29tIHdyb3Rl Oj4gQXQgdGhlDQo+ID4+Pj4+IFZhbmNvdXZlciBGMkYgd2UgaGFkIGV4dGVuc2l2ZSBkaXNjdXNz aW9ucyBvbiB0aGUgc2VjdXJpdHkgbW9kZWwNCj4gPj4+Pj4gZm9yIFBBV1MuIERyYWZ0LWRhcyBw cm9wb3NlcyB0byB1c2Ugc2hhcmVkIHNlY3JldHMgcHJlLQ0KPiBwcm92aXNpb25lZA0KPiA+Pj4+ PiBpbiB0aGUgbWFzdGVyIGRldmljZXMgZm9yIGF1dGhlbnRpY2F0aW9uLCB3aGlsZSBkcmFmdC1s ZWkNCj4gcHJvcG9zZXMNCj4gPj4+Pj4gdG8gbWFuZGF0ZSBjbGllbnQgY2VydGlmaWNhdGVzIGlu dG8gbWFzdGVyIGRldmljZXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlcmUgc2VlbWVkIHRvIGJl IGFuIHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgY3JlZGVudGlhbCB0eXBlcyBpbg0KPiA+Pj4gdXNl DQo+ID4+Pj4+IGZvciBhdXRoZW50aWNhdGlvbiBhcmUgYSBtYXR0ZXIgb2YgYSBidXNpbmVzcyBt b2RlbCBjaG9zZW4gYnkgdGhlDQo+ID4+Pj4+IHByb3ZpZGVyIHdoaWNoIGRlcGxveXMgd2hpdGUg c3BhY2UgZGV2aWNlcywgcmF0aGVyIHRoYW4gYQ0KPiBwcm90b2NvbA0KPiA+Pj4+PiBkZWNpc2lv bi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBCcmlhbiBtZW50aW9uZWQgdGhhdCB0aGUgaWVzZyBtYXkg bm90IGFsbG93IGEgZG9jdW1lbnQgdG8gYmUNCj4gPj4+Pj4gcHVibGlzaGVkIHdoaWNoIHNwZWNp ZmllcyBob3cgc2hhcmVkIHNlY3JldHMgYXJlIHVzZWQsIGJ1dCBkb2VzDQo+ID4+Pj4+IG5vdCBo YXZlIGEgcHJvdmlzaW9uaW5nIG1lY2hhbmlzbSBmb3IgdGhlIHNoYXJlZCBzZWNyZXRzIGRlZmlu ZWQuDQo+ID4+Pj4+IEluIG15IG9waW5pb24sIGEgbWVjaGFuaXNtIGZvciBkaXN0cmlidXRpbmcg c2hhcmVkIHNlY3JldHMgZG9lcw0KPiA+Pj4+PiBub3QgbmVjZXNzYXJpbHkgaGF2ZSB0byBiZSBk ZWZpbmVkLCBhcyBhIHNoYXJlZCBzZWNyZXQgY2FuIGJlDQo+ID4+Pj4+IGVzdGFibGlzaGVkIHVz aW5nIGN1cnJlbnQgcHJhY3RpY2VzIHRvIHNldCB1cCBzaGFyZWQgc2VjcmV0cyB3aXRoDQo+ID4+ Pj4+IGZpbmFuY2lhbCBpbnN0aXR1dGlvbnMgKHVzaW5nIHRoZSBicm93c2VyKS4NCj4gPj4+Pj4+ IFRodXMsIG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gZGVzY3JpYmUgaW4gdGhlIGRvY3VtZW50 IGhvdyBhDQo+ID4+Pj4+PiBzaGFyZWQNCj4gPj4+Pj4gc2VjcmV0IGFuZCBob3cgYSBjbGllbnQg Y2VydGlmaWNhdGUgaXMgdXNlZCB0byBhdXRoZW50aWNhdGUgYQ0KPiA+Pj4+PiBtYXN0ZXIgZGV2 aWNlLiBUaGVuLCBpZiB3ZSBydW4gaW50byBpc3N1ZXMgd2l0aCBpZXNnLCBpbiB3b3JzdA0KPiA+ Pj4+PiBjYXNlIHdlIGNvdWxkIHJlbW92ZSB0aGUgc2hhcmVkIHNlY3JldCBwYXJ0IGFuZCBrZWVw IHRoZSBvdGhlcg0KPiBvbmUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSdkIGxpa2UgdG8gZ2V0IGFk ZGl0aW9uYWwgdmlld3Mgb24gdGhpcyB0b3BpYy4NCj4gPj4+Pj4NCj4gPj4+Pj4gSSBjYW4gaGVs cCBhIGxpdHRsZSBoZXJlIChkZXBlbmRpbmcgb24geW91ciBkZWZpbml0aW9uIG9mIGhlbHA6LSkN Cj4gPj4+Pj4NCj4gPj4+Pj4gQkNQIDEwNyBbMV0gaXMgdGhlIG9uZSB0byBsb29rIGF0IHdoZW4g Y29uc2lkZXJpbmcgaG93IHRvDQo+IGFwcHJvYWNoDQo+ID4+Pj4+IGF1dG9tYXRlZCBrZXkgbWFu YWdlbWVudCByZXF1aXJlbWVudHMuIFRoYXQgaGFzIGFuIElNTyB2ZXJ5IGdvb2QNCj4gPj4+Pj4g YWJzdHJhY3Q6DQo+ID4+Pj4+DQo+ID4+Pj4+ICAgIFRoZSBxdWVzdGlvbiBvZnRlbiBhcmlzZXMg b2Ygd2hldGhlciBhIGdpdmVuIHNlY3VyaXR5IHN5c3RlbQ0KPiA+Pj4+PiAgICByZXF1aXJlcyBz b21lIGZvcm0gb2YgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50LCBvciB3aGV0aGVyDQo+IG1hbnVh bA0KPiA+Pj4+PiAgICBrZXlpbmcgaXMgc3VmZmljaWVudC4gIFRoaXMgbWVtbyBwcm92aWRlcyBn dWlkZWxpbmVzIGZvcg0KPiBtYWtpbmcNCj4gPj4+Pj4gICAgc3VjaCBkZWNpc2lvbnMuIFdoZW4g c3ltbWV0cmljIGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNtcyBhcmUNCj4gdXNlZA0KPiA+Pj4+PiAg ICBpbiBhIHByb3RvY29sLCB0aGUgcHJlc3VtcHRpb24gaXMgdGhhdCBhdXRvbWF0ZWQga2V5DQo+ IG1hbmFnZW1lbnQNCj4gPj4+Pj4gICAgaXMgZ2VuZXJhbGx5IGJ1dCBub3QgYWx3YXlzIG5lZWRl ZC4gIElmIG1hbnVhbCBrZXlpbmcgaXMNCj4gPj4+Pj4gcHJvcG9zZWQsDQo+ID4gdGhlDQo+ID4+ Pj4+ICAgIGJ1cmRlbiBvZiBwcm92aW5nIHRoYXQgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50IGlz IG5vdA0KPiByZXF1aXJlZA0KPiA+Pj4+PiAgICBmYWxscyB0byB0aGUNCj4gPj4+IHByb3Bvc2Vy Lg0KPiA+Pj4+PiBGb3IgdGhvc2UgdGhhdCBtaWdodCBiZSBsZXNzIGZhbWlsaWFyIHdpdGggSUVU RiBwcm9jZXNzZXMsIHRoZQ0KPiA+Pj4+PiBmYWN0IHRoYXQgdGhhdCdzIGEgQkNQIG1lYW5zIHRo YXQgaXRzIGVudGlyZWx5IHZhbGlkIGZvciBhbiBBRCB0bw0KPiA+Pj4+PiBzdHJlbnVvdXNseSBw dXNoIGJhY2sgYWdhaW5zdCBhIFdHIHRoYXQgd2FudHMgdG8gaWdub3JlIHdoYXQgaXQNCj4gc2F5 cy4NCj4gPj4+Pj4NCj4gPj4+Pj4gQ2hlZXJzLA0KPiA+Pj4+PiBTLg0KPiA+Pj4+Pg0KPiA+Pj4+ PiBQUzogSSd2ZSBub3QgcmVhZCB0aGUgZHJhZnRzLCBhbmQgY291bGRuJ3QgbWFrZSB0aGUgc2Vz c2lvbiBpbg0KPiA+Pj4+PiBWYW5jb3V2ZXIsIHNvIHRoaXMgbWlnaHQgYmUgZW50aXJlbHkgb2Zm IHRvcGljLCBidXQgaW4gdGhlIGNhc2UNCj4gb2YNCj4gPj4+Pj4gUEFXUyBJJ2QgYWxzbyBhcmd1 ZSB0aGF0IHRoZSByZWd1bGF0b3JzJyBhcHBhcmVudCBkZXNpcmUgdG8gZm9yY2UNCj4gPj4+Pj4g ZGV2aWNlcyB0byBhdXRoZW50aWNhdGUgaXMgbm90IG5lY2Vzc2FyaWx5IHRoZSByaWdodCBvbmUg Zm9yIHRoZQ0KPiA+Pj4+PiBJRVRGIHRvIGZvcmNlIHVwb24gYWxsIHVzZXJzIG9mIHRoZSBQQVdT IHByb3RvY29sLiBTbyB0aGVyZSBjb3VsZA0KPiA+Pj4+PiBmb3IgZXhhbXBsZSBiZSBhIG1vZGUg b2Ygb3BlcmF0aW9uIHdoZXJlIHRoZSBEQiBzaWducyBzdHVmZiBidXQNCj4gPj4+Pj4gZG9lc24n dCBjYXJlIHdobydzIGFza2luZyBhbmQgdGhhdCdkIGJlIGEgZmFyIGZhciBlYXNpZXIgc2NlbmFy aW8NCj4gPj4+Pj4gaW4gdGVybXMgb2YgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50Lg0KPiA+Pj4+ Pg0KPiA+Pj4+PiBbMV0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvYmNwMTA3DQo+ID4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHBhd3MgbWFp bGluZyBsaXN0DQo+ID4+Pj4+IHBhd3NAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBwYXdzIG1h aWxpbmcgbGlzdA0KPiA+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPj4NCj4gPj4NCj4gPj4NCj4gDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3 cyBtYWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Bhd3MNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From paul@marvell.com Mon Sep 10 13:04:51 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6B21F85F7 for ; Mon, 10 Sep 2012 13:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tTzPKb35UVS for ; Mon, 10 Sep 2012 13:04:50 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDD21F8600 for ; Mon, 10 Sep 2012 13:04:42 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKUE5H1Fh6YktFrwImkuCSk2MRetJfQQ9G@postini.com; Mon, 10 Sep 2012 13:04:49 PDT Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Sep 2012 13:02:22 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 10 Sep 2012 13:02:22 -0700 From: Paul Lambert To: "Rosen, Brian" , 'Peter McCann' , 'Peter Stanforth' , 'Stephen Farrell' , "'Gabor.Bajko@nokia.com'" Date: Mon, 10 Sep 2012 13:02:24 -0700 Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAB6rQD//4r34IAAfUcA//+LN1CAAAMcAIAABciBgAAHGvA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E4681AB7@SC-VEXCH2.marvell.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227D5@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227D5@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:04:51 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb3NlbiwgQnJpYW4gW21haWx0 bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0NCi4uLg0KPiBUaGUgZWFzaWVzdCB3YXkgdG8gZG8g dGhpcyBpcyB0byBoYXZlIHRoZSBtYW51ZmFjdHVyZXIgcHV0IGEgY2VydCBpbg0KPiB0aGUgZGV2 aWNlIHRoYXQgaXQgc2lnbnMuICBUaGVuIHRoZSBvbmx5IHRoaW5nIHRoZSBkYXRhYmFzZSBuZWVk cyBpcw0KPiB0aGUgcHVibGljIGtleSBvZiB0aGUgbWFudWZhY3R1cmVyLA0KWW91IGNhbm5vdCBw cmV2ZW50IHNwb29maW5nIG9mIGEgREIgd2l0aG91dCBoYXZpbmcgYSByb290DQpvZiBzb21lIHNv cnQgdGhhdCAiY2VydGlmaWVzIiByZWFsIGRiIHByb3ZpZGVycy4gIFRoaXMgaXMgYSBzbWFsbA0K bnVtYmVyIG9mIGNlcnRpZmljYXRlcyBpbnN0YWxsZWQgaW4gdGhlIHNlcnZlcnMuDQoNCkhhdmlu ZyBhIHBlci1kZXZpY2UgY2VydCBzaWduZWQgYnkgYSBtYW51ZmFjdHVyZXIgYW5kIGluc3RhbGxl ZA0KaW4gdGhlIGZhY3RvcnkgaXMgaGFyZGVyLiAgSXQncyBtb3JlIGNlcnRpZmljYXRlcyBhbmQg Y29tcGxpY2F0ZXMNCnRoZSBtYW51ZmFjdHVyaW5nIHByb2Nlc3MuICBUaGUgYXV0aGVudGljYXRp b24gdG8gYSBtYW51ZmFjdHVyZXINCmlzIG5vdCBuZWNlc3NhcmlseSB1c2VmdWwuIFRoZSBhdXRo ZW50aWNhdGlvbiBvZiB0aGUgbWFudWZhY3R1cmVycw0KRkNDIElEIGFuZCBkZXZpY2UgSWQgbWln aHQgYmUgb2YgaW50ZXJlc3QsIGJ1dCB0aGUgcmVndWxhdGlvbnMNCmRvIG5vdCBtYW5kYXRlIChB RkFJSykgdGhpcyBjb21wbGV4aXR5IG9mIGFzc2lnbm1lbnQgb2YgYQ0KZmV3IGJpdHMgb2YgcGVy IGRldmljZSByZWd1bGF0b3J5IGluZm9ybWF0aW9uLg0KDQo+IFdoeSBkbyB3ZSB3YW50IHRvIG1h a2UgdGhpcyBoYXJkZXI/DQpUaGVyZSBhcmUgdHdvIHJlcXVpcmVtZW50czoNCiAtIGF1dGhlbnRp Y2F0aW9uIG9mIG11bHRpcGxlIERCIHByb3ZpZGVycyB3aXRoaW4gYSByZWd1bGF0b3J5IGRvbWFp bg0KIC0gInNlY3VyZSIgdHJhbnNtaXNzaW9uIG9mIFJlZ3VsYXRvcnkgSUQgYW5kIERldmljZSBp ZGVudGlmaWNhdGlvbiANCiAgICB0byBEQg0KUHJvcG9zYWwgYmVsb3cgd2FzIHByaW1hcmlseSBm b2N1c2VkIG9uIHRoZSBmaXJzdCByZXF1aXJlbWVudA0KYWJvdmUuICBZb3VyIHByb3Bvc2FsIGZv ciBkZXZpY2UgY2VydHMgaXMgZm9yIHRoZSBzZWNvbmQuDQpCb3RoIG1pZ2h0IGJlIHJlcXVpcmVk IC4uLiBkZXZpY2UgY2VydHMgaGF2ZSBvdGhlciBvcHRpb25zIGFsc28NCnRoYW4gbWFudWZhY3R1 cmVyIG9yaWVudGVkIGNlcnRzIGFuZCBpcyBhIGxvbmdlciBkaXNjdXNzaW9uLg0KDQpQYXVsDQoN Cj4gQmVjYXVzZSBzb21lIG1hbnVmYWN0dXJlcnMgdGhpbmsgaXRzIHRvbyBtdWNoIHdvcmsgdG8g ZG8gdGhhdD8NCj4gDQo+IEJyaWFuDQo+IA0KPiANCj4gDQo+ICAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiAJUGF1bCBMYW1iZXJ0IFttYWlsdG86cGF1bEBtYXJ2ZWxsLmNvbV0N Cj4gU2VudDoJTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgMDM6MTUgUE0gRWFzdGVybiBTdGFu ZGFyZCBUaW1lDQo+IFRvOglQZXRlciBNY0Nhbm47IFBldGVyIFN0YW5mb3J0aDsgU3RlcGhlbiBG YXJyZWxsOw0KPiBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4gQ2M6CXBhd3NAaWV0Zi5vcmcNCj4g U3ViamVjdDoJUmU6IFtwYXdzXSBQQVdTIHNlY3VyaXR5DQo+IA0KPiANCj4gPiBUaGlzIHJlc3Ry aWN0aW9uIG1heSBob2xkIHRvZGF5IGZvciB0aGUgRkNDLCBidXQgSSBoYXZlIGEgaGFyZCB0aW1l DQo+ID4gYmVsaWV2aW5nIHRoYXQgYSBwcmUtZXhpc3RpbmcgbWFudWZhY3R1cmVyLWRhdGFiYXNl IHJlbGF0aW9uc2hpcCB3aWxsDQo+ID4gYmUgbWFuZGF0b3J5IGluIGV2ZXJ5IHJlZ3VsYXRvcnkg ZG9tYWluIGZvciB0aGUgZm9yc2VlYWJsZSBmdXR1cmUuICBJDQo+ID4gdGhpbmsgd2Ugc2hvdWxk IGRlc2lnbiB0byBtaW5pbWl6ZSB0aGUgZnJpY3Rpb24gaW4gY2hhbmdpbmcgZGF0YWJhc2UNCj4g PiBwcm92aWRlcnMuDQo+IA0KPiBUaGUgbGVhc3QgZnJpY3Rpb24gd291bGQgYmUgdG8gaGFyZHdp cmUgZGV2aWNlcyB3aXRoIGEgUEsgInJvb3QiIGZvcg0KPiBlYWNoIHJlZ3VsYXRvcnkgZG9tYWlu IHRoYXQgdGhlIGRldmljZSBzdXBwb3J0cy4NCj4gDQo+IFZhbGlkIERCcyB3b3VsZCBoYXZlIGNy ZWRlbnRpYWxzIHNpZ25lZCBieSB0aGUga2V5IGhvbGRlciBvZiByb290cyBmb3INCj4gZWFjaCBy ZWd1bGF0b3J5IGRvbWFpbg0KPiANCj4gUGF1bA0KPiANCj4gDQo+ID4gLVBldGUNCj4gPg0KPiA+ IFBldGVyIFN0YW5mb3J0aCB3cm90ZToNCj4gPiA+IEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHlv dXIgc3RhdGVtZW50IGJlbG93LiBJZiB3ZSBhcmUgZ29vZCBhbnkNCj4gPiByYWRpbw0KPiA+ID4g d2lsbCBoYXZlIHRoZSAiVGVjaG5pY2FsIiBjYXBhYmlsaXR5IHRvIHdvcmsgd2l0aCBhbnkgZGF0 YWJhc2UuDQo+ID4gPiBCVVQsIGFuZCB0aGlzIGlzIGEgYmlnIEJVVCwgdGhlIHJlZ3VsYXRpb24g bWF5IG5vdCBhbGxvdyBpdCAtIFRoZQ0KPiA+ID4gRkNDIGRvZXMgbm90IHRvZGF5LiBBbmQgYXMg YSBEQkEgSSBvbmx5IHdhbnQgdG8gd29yayB3aXRoIGRldmljZXMNCj4gPiA+IHdoZXJlIEkgaGF2 ZSBhIHByZWRlZmluZWQgcmVsYXRpb25zaGlwLiBOb3QgbGVhc3Qgb2Ygd2hpY2gsIGJlY2F1c2UN Cj4gPiA+IGFzIEkgYW0gYXV0aG9yaXplZCBieSBhIFJlZ3VsYXRvciBJIHdhbnQgdG8gbWFrZSBz dXJlIEkgYW0gZG9pbmcNCj4gPiA+IGV2ZXJ5dGhpbmcgSSBjYW4gdG8gYXZvaWQgdGhlaXIgd3Jh dGguDQo+ID4gPiBUaGlzIGhhcyBjb21lIHVwIGJlZm9yZS4gUEFXUyBpcyBkZWZpbmluZyBhbiBB UEkvUHJvdG9jb2wsIG5vdCB0aGUNCj4gPiA+IHJlZ3VsYXRpb24gbm9yIHRoZSBidXNpbmVzcyBj YXNlcyBhdCB0aGlzIHRpbWUuIFNvIEkgc3RpbGwgc2F5IHRoYXQNCj4gPiB3ZQ0KPiA+ID4gY2Fu IGNvbXBseSB3aXRoIHlvdXIgc3RhdGVtZW50IHdpdGhvdXQgY29uc2lkZXJpbmcgYSAiVXNlciIu DQo+ID4gPg0KPiA+ID4gT24gTW9uU2VwLzEwLzEyIE1vbiBTZXAgMTAsIDI6MTggUE0sICJQZXRl ciBNY0Nhbm4iDQo+ID4gPiA8UGV0ZXIuTWNDYW5uQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4N Cj4gPiA+PiBUaGlzIGlzIGEga2V5IHF1ZXN0aW9uIHdlIG5lZWQgdG8gYW5zd2VyLg0KPiA+ID4+ DQo+ID4gPj4gSSB0aG91Z2h0IHdlIHdlcmUgZGVmaW5pbmcgYSBwcm90b2NvbCB0aGF0IHdvdWxk IGFsbG93IGEgcmFkaW8NCj4gZnJvbQ0KPiA+ID4+IGFueSBtYW51ZmFjdHVyZXIgdG8gaW50ZXJv cGVyYXRlIHdpdGggYSBkYXRhYmFzZSBvZiBhbnkgZGF0YWJhc2UNCj4gPiB2ZW5kb3IuDQo+ID4g Pj4NCj4gPiA+PiAtUGV0ZQ0KPiA+ID4+DQo+ID4gPj4gUGV0ZXIgU3RhbmZvcnRoIHdyb3RlOg0K PiA+ID4+PiBQZXRlLCBJIGFtIG5vdCBzdXJlIEkgYmVsaWV2ZSBpbiBhIHVzZSBjYXNlIHdoZXJl ICJ1c2VycyIgbW92ZQ0KPiA+ID4+PiBmcm9tIG9uZSBEQiB0byBhbm90aGVyLiBUaGUgcmVsYXRp b25zaGlwIGlzIGJldHdlZW4gdGhlIHJhZGlvDQo+ID4gPj4+IHZlbmRvciBhbmQgdGhlIERCQS4g VGhlIHJhZGlvIHZlbmRvciBtYXkgaGF2ZSBtdWx0aXBsZQ0KPiA+ID4+PiByZWxhdGlvbnNoaXBz IGFuZCBhbGxvdyBhbiBlbmQgdXNlciAgdG8gY2hvb3NlIG9uZSwgYnV0IGl0IHdpbGwNCj4gYmUN Cj4gPiA+Pj4gZnJvbSB0aGUgcHJlZGVmaW5lZA0KPiA+IGxpc3QuDQo+ID4gPj4+IEFzIGEgREJB IEkgIGRvbid0IHRoaW5rIEkgd291bGQgd2FudCwgYW5kIGluIHRoZSBVU0Egd2UgYXJlIG5vdA0K PiA+ID4+PiBwZXJtaXR0ZWQsIHRvIGVzdGFibGlzaCBhIHJlbGF0aW9uc2hpcCB3aXRoIGEgdXNl ciB3aXRob3V0IGENCj4gPiA+Pj4gcHJlZXhpc3RpbmcgcmVsYXRpb25zaGlwIHdpdGggdGhlIHJh ZGlvIHZlbmRvci4gU28gc2VjdXJpdHkNCj4gc2hvdWxkDQo+ID4gPj4+IGJlIHByaW1hcmlseSBh IHJhZGlvIHZlbmRvci1EQkEgaXNzdWUuIFdlYXJpbmcgbXkgREJBIGhhdCBJIGRvbid0DQo+ID4g Pj4+IHRoaW5rIEkgd291bGQgd2FudCB0byBzZXJ2aWNlIGEgcmFkaW8gdGhhdCBJIGRvIG5vdCBo YXZlIGENCj4gPiA+Pj4gcHJlZXhpc3RpbmcgcmVsYXRpb25zaGlwIHdpdGggaXQncyBtYW51ZmFj dHVyZXIuICBJIGFtIG5vdCBzdXJlDQo+ID4gdGhhdA0KPiA+ID4+PiB1c2VyIHJlbGF0aW9uc2hp cHMgYXJlIGV2ZW4gd2l0aGluIHRoZSBzY29wZSBvZiB3aGF0IFBBV1Mgc2hvdWxkDQo+ID4gPj4+ IGJlDQo+ID4gZGVmaW5pbmcuIFBldGVyIFMuDQo+ID4gPj4+DQo+ID4gPj4+IE9uIE1vblNlcC8x MC8xMiBNb24gU2VwIDEwLCAxOjU4IFBNLCAiUGV0ZXIgTWNDYW5uIg0KPiA+ID4+PiA8UGV0ZXIu TWNDYW5uQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4+Pg0KPiA+ID4+Pj4gUGVyc29uYWxseSwg SSB0aGluayB0aGF0IG1hbnVhbGx5IHByb3Zpc2lvbmVkIHN5bW1ldHJpYyBrZXlzDQo+IHdpbGwN Cj4gPiA+Pj4+IHNldmVyZWx5IGxpbWl0IHRoZSBhYmlsaXR5IGZvciB1c2VycyB0byBmbGV4aWJs eSBtb3ZlIGZyb20gb25lDQo+ID4gPj4+PiBkYXRhYmFzZSBwcm92aWRlciB0byBhbm90aGVyLiAg SXQgd2lsbCByZXF1aXJlIHNvbWUgc2VjdXJlDQo+ID4gPj4+PiBvdXQtb2YtYmFuZCBjaGFubmVs IG9uIHdoaWNoIHRvIHRyYW5zbWl0IHRoZSBzZWNyZXQga2V5IGZyb20gb25lDQo+ID4gPj4+PiBw YXJ0eSB0byB0aGUgb3RoZXIsIGFuZCBhIG1lY2hhbmlzbSBmb3IgdGhlIHVzZXIgdG8gcHVzaCB0 aGUNCj4gPiBzZWNyZXQNCj4gPiA+Pj4+IGtleSBkb3duIGludG8gdGhlIG1hc3RlciBkZXZpY2Uu DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gUHJvdmlzaW9uaW5nIG9mIGNlcnRpZmljYXRlcyBkb2VzIG5v dCByZXF1aXJlIHRoZSBzZWNyZXQNCj4gY2hhbm5lbCwNCj4gPiA+Pj4+IG9ubHkgb25lIHRoYXQg aXMgaW50ZWdyaXR5IHByb3RlY3RlZC4gIEkgdGhpbmsgdGhpcyBpcyBtdWNoDQo+ID4gPj4+PiBl YXNpZXIgdG8gYWNoaWV2ZSBpbiBwcmFjdGljZS4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAtUGV0ZQ0K PiA+ID4+Pj4NCj4gPiA+Pj4+IFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCj4gPiA+Pj4+Pg0KPiA+ ID4+Pj4+DQo+ID4gPj4+Pj4gT24gMDkvMDcvMjAxMiAxMDowMSBQTSwgR2Fib3IuQmFqa29Abm9r aWEuY29tIHdyb3RlOj4gQXQgdGhlDQo+ID4gPj4+Pj4gVmFuY291dmVyIEYyRiB3ZSBoYWQgZXh0 ZW5zaXZlIGRpc2N1c3Npb25zIG9uIHRoZSBzZWN1cml0eQ0KPiBtb2RlbA0KPiA+ID4+Pj4+IGZv ciBQQVdTLiBEcmFmdC1kYXMgcHJvcG9zZXMgdG8gdXNlIHNoYXJlZCBzZWNyZXRzIHByZS0NCj4g PiBwcm92aXNpb25lZA0KPiA+ID4+Pj4+IGluIHRoZSBtYXN0ZXIgZGV2aWNlcyBmb3IgYXV0aGVu dGljYXRpb24sIHdoaWxlIGRyYWZ0LWxlaQ0KPiA+IHByb3Bvc2VzDQo+ID4gPj4+Pj4gdG8gbWFu ZGF0ZSBjbGllbnQgY2VydGlmaWNhdGVzIGludG8gbWFzdGVyIGRldmljZXMuDQo+ID4gPj4+Pj4+ DQo+ID4gPj4+Pj4+IFRoZXJlIHNlZW1lZCB0byBiZSBhbiB1bmRlcnN0YW5kaW5nIHRoYXQgdGhl IGNyZWRlbnRpYWwgdHlwZXMNCj4gPiA+Pj4+Pj4gaW4NCj4gPiA+Pj4gdXNlDQo+ID4gPj4+Pj4g Zm9yIGF1dGhlbnRpY2F0aW9uIGFyZSBhIG1hdHRlciBvZiBhIGJ1c2luZXNzIG1vZGVsIGNob3Nl biBieQ0KPiA+ID4+Pj4+IHRoZSBwcm92aWRlciB3aGljaCBkZXBsb3lzIHdoaXRlIHNwYWNlIGRl dmljZXMsIHJhdGhlciB0aGFuIGENCj4gPiBwcm90b2NvbA0KPiA+ID4+Pj4+IGRlY2lzaW9uLg0K PiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBCcmlhbiBtZW50aW9uZWQgdGhhdCB0aGUgaWVzZyBtYXkg bm90IGFsbG93IGEgZG9jdW1lbnQgdG8gYmUNCj4gPiA+Pj4+PiBwdWJsaXNoZWQgd2hpY2ggc3Bl Y2lmaWVzIGhvdyBzaGFyZWQgc2VjcmV0cyBhcmUgdXNlZCwgYnV0IGRvZXMNCj4gPiA+Pj4+PiBu b3QgaGF2ZSBhIHByb3Zpc2lvbmluZyBtZWNoYW5pc20gZm9yIHRoZSBzaGFyZWQgc2VjcmV0cw0K PiBkZWZpbmVkLg0KPiA+ID4+Pj4+IEluIG15IG9waW5pb24sIGEgbWVjaGFuaXNtIGZvciBkaXN0 cmlidXRpbmcgc2hhcmVkIHNlY3JldHMgZG9lcw0KPiA+ID4+Pj4+IG5vdCBuZWNlc3NhcmlseSBo YXZlIHRvIGJlIGRlZmluZWQsIGFzIGEgc2hhcmVkIHNlY3JldCBjYW4gYmUNCj4gPiA+Pj4+PiBl c3RhYmxpc2hlZCB1c2luZyBjdXJyZW50IHByYWN0aWNlcyB0byBzZXQgdXAgc2hhcmVkIHNlY3Jl dHMNCj4gPiA+Pj4+PiB3aXRoIGZpbmFuY2lhbCBpbnN0aXR1dGlvbnMgKHVzaW5nIHRoZSBicm93 c2VyKS4NCj4gPiA+Pj4+Pj4gVGh1cywgbXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBkZXNjcmli ZSBpbiB0aGUgZG9jdW1lbnQgaG93IGENCj4gPiA+Pj4+Pj4gc2hhcmVkDQo+ID4gPj4+Pj4gc2Vj cmV0IGFuZCBob3cgYSBjbGllbnQgY2VydGlmaWNhdGUgaXMgdXNlZCB0byBhdXRoZW50aWNhdGUg YQ0KPiA+ID4+Pj4+IG1hc3RlciBkZXZpY2UuIFRoZW4sIGlmIHdlIHJ1biBpbnRvIGlzc3VlcyB3 aXRoIGllc2csIGluIHdvcnN0DQo+ID4gPj4+Pj4gY2FzZSB3ZSBjb3VsZCByZW1vdmUgdGhlIHNo YXJlZCBzZWNyZXQgcGFydCBhbmQga2VlcCB0aGUgb3RoZXINCj4gPiBvbmUuDQo+ID4gPj4+Pj4+ DQo+ID4gPj4+Pj4+IEknZCBsaWtlIHRvIGdldCBhZGRpdGlvbmFsIHZpZXdzIG9uIHRoaXMgdG9w aWMuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBJIGNhbiBoZWxwIGEgbGl0dGxlIGhlcmUgKGRlcGVu ZGluZyBvbiB5b3VyIGRlZmluaXRpb24gb2YNCj4gPiA+Pj4+PiBoZWxwOi0pDQo+ID4gPj4+Pj4N Cj4gPiA+Pj4+PiBCQ1AgMTA3IFsxXSBpcyB0aGUgb25lIHRvIGxvb2sgYXQgd2hlbiBjb25zaWRl cmluZyBob3cgdG8NCj4gPiBhcHByb2FjaA0KPiA+ID4+Pj4+IGF1dG9tYXRlZCBrZXkgbWFuYWdl bWVudCByZXF1aXJlbWVudHMuIFRoYXQgaGFzIGFuIElNTyB2ZXJ5DQo+IGdvb2QNCj4gPiA+Pj4+ PiBhYnN0cmFjdDoNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICAgIFRoZSBxdWVzdGlvbiBvZnRlbiBh cmlzZXMgb2Ygd2hldGhlciBhIGdpdmVuIHNlY3VyaXR5IHN5c3RlbQ0KPiA+ID4+Pj4+ICAgIHJl cXVpcmVzIHNvbWUgZm9ybSBvZiBhdXRvbWF0ZWQga2V5IG1hbmFnZW1lbnQsIG9yIHdoZXRoZXIN Cj4gPiBtYW51YWwNCj4gPiA+Pj4+PiAgICBrZXlpbmcgaXMgc3VmZmljaWVudC4gIFRoaXMgbWVt byBwcm92aWRlcyBndWlkZWxpbmVzIGZvcg0KPiA+IG1ha2luZw0KPiA+ID4+Pj4+ICAgIHN1Y2gg ZGVjaXNpb25zLiBXaGVuIHN5bW1ldHJpYyBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMgYXJlDQo+ ID4gdXNlZA0KPiA+ID4+Pj4+ICAgIGluIGEgcHJvdG9jb2wsIHRoZSBwcmVzdW1wdGlvbiBpcyB0 aGF0IGF1dG9tYXRlZCBrZXkNCj4gPiBtYW5hZ2VtZW50DQo+ID4gPj4+Pj4gICAgaXMgZ2VuZXJh bGx5IGJ1dCBub3QgYWx3YXlzIG5lZWRlZC4gIElmIG1hbnVhbCBrZXlpbmcgaXMNCj4gPiA+Pj4+ PiBwcm9wb3NlZCwNCj4gPiA+IHRoZQ0KPiA+ID4+Pj4+ICAgIGJ1cmRlbiBvZiBwcm92aW5nIHRo YXQgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50IGlzIG5vdA0KPiA+IHJlcXVpcmVkDQo+ID4gPj4+ Pj4gICAgZmFsbHMgdG8gdGhlDQo+ID4gPj4+IHByb3Bvc2VyLg0KPiA+ID4+Pj4+IEZvciB0aG9z ZSB0aGF0IG1pZ2h0IGJlIGxlc3MgZmFtaWxpYXIgd2l0aCBJRVRGIHByb2Nlc3NlcywgdGhlDQo+ ID4gPj4+Pj4gZmFjdCB0aGF0IHRoYXQncyBhIEJDUCBtZWFucyB0aGF0IGl0cyBlbnRpcmVseSB2 YWxpZCBmb3IgYW4gQUQNCj4gPiA+Pj4+PiB0byBzdHJlbnVvdXNseSBwdXNoIGJhY2sgYWdhaW5z dCBhIFdHIHRoYXQgd2FudHMgdG8gaWdub3JlIHdoYXQNCj4gPiA+Pj4+PiBpdA0KPiA+IHNheXMu DQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBDaGVlcnMsDQo+ID4gPj4+Pj4gUy4NCj4gPiA+Pj4+Pg0K PiA+ID4+Pj4+IFBTOiBJJ3ZlIG5vdCByZWFkIHRoZSBkcmFmdHMsIGFuZCBjb3VsZG4ndCBtYWtl IHRoZSBzZXNzaW9uIGluDQo+ID4gPj4+Pj4gVmFuY291dmVyLCBzbyB0aGlzIG1pZ2h0IGJlIGVu dGlyZWx5IG9mZiB0b3BpYywgYnV0IGluIHRoZSBjYXNlDQo+ID4gb2YNCj4gPiA+Pj4+PiBQQVdT IEknZCBhbHNvIGFyZ3VlIHRoYXQgdGhlIHJlZ3VsYXRvcnMnIGFwcGFyZW50IGRlc2lyZSB0bw0K PiA+ID4+Pj4+IGZvcmNlIGRldmljZXMgdG8gYXV0aGVudGljYXRlIGlzIG5vdCBuZWNlc3Nhcmls eSB0aGUgcmlnaHQgb25lDQo+ID4gPj4+Pj4gZm9yIHRoZSBJRVRGIHRvIGZvcmNlIHVwb24gYWxs IHVzZXJzIG9mIHRoZSBQQVdTIHByb3RvY29sLiBTbw0KPiA+ID4+Pj4+IHRoZXJlIGNvdWxkIGZv ciBleGFtcGxlIGJlIGEgbW9kZSBvZiBvcGVyYXRpb24gd2hlcmUgdGhlIERCDQo+ID4gPj4+Pj4g c2lnbnMgc3R1ZmYgYnV0IGRvZXNuJ3QgY2FyZSB3aG8ncyBhc2tpbmcgYW5kIHRoYXQnZCBiZSBh IGZhcg0KPiA+ID4+Pj4+IGZhciBlYXNpZXIgc2NlbmFyaW8gaW4gdGVybXMgb2YgYXV0b21hdGVk IGtleSBtYW5hZ2VtZW50Lg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gWzFdIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2JjcDEwNw0KPiA+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fIHBhd3MgbWFpbGluZw0KPiA+ID4+Pj4+IGxpc3QgcGF3c0Bp ZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gPiA+ Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPiA+ ID4+Pj4gcGF3c0BpZXRmLm9yZw0KPiA+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wYXdzDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4NCj4gPg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBw YXdzIG1haWxpbmcgbGlzdA0KPiA+IHBhd3NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gcGF3c0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== From brian.rosen@neustar.biz Mon Sep 10 13:14:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED5911E809A for ; Mon, 10 Sep 2012 13:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyM2elT5VUDa for ; Mon, 10 Sep 2012 13:14:35 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A792311E808A for ; Mon, 10 Sep 2012 13:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347308353; x=1662651981; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=nxSOTbidfvFGrtExtIBeE 8t/d2OJVyzDTGmgZen/O58=; b=ELpugUK0AKt5aP6agmL+XxKVJoHjlqI/4Y0tH 6D+3eRuIiMRptkDRUUC8VDKopvx9JtLtE0ezbEq9hqtPs3r7Q== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.14028003; Mon, 10 Sep 2012 16:19:12 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 10 Sep 2012 16:14:23 -0400 From: "Rosen, Brian" To: 'Paul Lambert' , 'Peter McCann' , 'Peter Stanforth' , 'Stephen Farrell' , "'Gabor.Bajko@nokia.com'" Date: Mon, 10 Sep 2012 16:14:23 -0400 Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAB6rQD//4r34IAAfUcA//+LN1CAAAMcAIAABciBgAAHGvCAAAiH0Q== Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227D6@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: hHjUCzR5KcKuSDIiM0I4IA== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:14:36 -0000 SXQgd291bGQgYmUgZWFzeSB0byBkaXNjb3ZlciB0aGUgY2VydHMgb2YgdGhlIERCQXMsIGJlY2F1 c2UgdGhlcmUgYXJlIGZldyBvZiB0aGVtLCBhbmQgY29udHJvbGxlZCBieSByZWd1bGF0b3JzLiAg RGlzY292ZXJ5IG9mIHRoZSBzZXJ2ZXIgY2FuIGluY2x1ZGUgZGlzY292ZXJ5IG9mIHRoZSBjZXJ0 cy4gIFRoZSBvdGhlciB3YXkgaXMgaGFyZGVyIGZvciBtYW51ZmFjdHVyZXJzIGJlY2F1c2Ugb2Yg dGhlIGlzc3VlcyB5b3UgY2l0ZSwgYnV0IG92ZXJhbGwsIGl0J3MgbXVjaCBlYXNpZXIgdGhhbiBz aGFyZWQgc2VjcmV0cy4gIAoKSXQgaXMgYSByZXF1aXJlbWVudCB0byBhdXRoZW50aWNhdGUgYm90 aCBzaWRlcywgc28gd2UgbmVlZCBzb2x1dGlvbnMgZm9yIGJvdGguCgpCcmlhbgoKDQoNCiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogCVBhdWwgTGFtYmVydCBbbWFpbHRvOnBhdWxA bWFydmVsbC5jb21dDQpTZW50OglNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiAwNDowNCBQTSBF YXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOglSb3NlbiwgQnJpYW47ICdQZXRlciBNY0Nhbm4nOyAn UGV0ZXIgU3RhbmZvcnRoJzsgJ1N0ZXBoZW4gRmFycmVsbCc7ICdHYWJvci5CYWprb0Bub2tpYS5j b20nDQpDYzoJJ3Bhd3NAaWV0Zi5vcmcnDQpTdWJqZWN0OglSRTogW3Bhd3NdIFBBV1Mgc2VjdXJp dHkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb3NlbiwgQnJpYW4g W21haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0NCi4uLg0KPiBUaGUgZWFzaWVzdCB3YXkg dG8gZG8gdGhpcyBpcyB0byBoYXZlIHRoZSBtYW51ZmFjdHVyZXIgcHV0IGEgY2VydCBpbg0KPiB0 aGUgZGV2aWNlIHRoYXQgaXQgc2lnbnMuICBUaGVuIHRoZSBvbmx5IHRoaW5nIHRoZSBkYXRhYmFz ZSBuZWVkcyBpcw0KPiB0aGUgcHVibGljIGtleSBvZiB0aGUgbWFudWZhY3R1cmVyLA0KWW91IGNh bm5vdCBwcmV2ZW50IHNwb29maW5nIG9mIGEgREIgd2l0aG91dCBoYXZpbmcgYSByb290DQpvZiBz b21lIHNvcnQgdGhhdCAiY2VydGlmaWVzIiByZWFsIGRiIHByb3ZpZGVycy4gIFRoaXMgaXMgYSBz bWFsbA0KbnVtYmVyIG9mIGNlcnRpZmljYXRlcyBpbnN0YWxsZWQgaW4gdGhlIHNlcnZlcnMuDQoN CkhhdmluZyBhIHBlci1kZXZpY2UgY2VydCBzaWduZWQgYnkgYSBtYW51ZmFjdHVyZXIgYW5kIGlu c3RhbGxlZA0KaW4gdGhlIGZhY3RvcnkgaXMgaGFyZGVyLiAgSXQncyBtb3JlIGNlcnRpZmljYXRl cyBhbmQgY29tcGxpY2F0ZXMNCnRoZSBtYW51ZmFjdHVyaW5nIHByb2Nlc3MuICBUaGUgYXV0aGVu dGljYXRpb24gdG8gYSBtYW51ZmFjdHVyZXINCmlzIG5vdCBuZWNlc3NhcmlseSB1c2VmdWwuIFRo ZSBhdXRoZW50aWNhdGlvbiBvZiB0aGUgbWFudWZhY3R1cmVycw0KRkNDIElEIGFuZCBkZXZpY2Ug SWQgbWlnaHQgYmUgb2YgaW50ZXJlc3QsIGJ1dCB0aGUgcmVndWxhdGlvbnMNCmRvIG5vdCBtYW5k YXRlIChBRkFJSykgdGhpcyBjb21wbGV4aXR5IG9mIGFzc2lnbm1lbnQgb2YgYQ0KZmV3IGJpdHMg b2YgcGVyIGRldmljZSByZWd1bGF0b3J5IGluZm9ybWF0aW9uLg0KDQo+IFdoeSBkbyB3ZSB3YW50 IHRvIG1ha2UgdGhpcyBoYXJkZXI/DQpUaGVyZSBhcmUgdHdvIHJlcXVpcmVtZW50czoNCiAtIGF1 dGhlbnRpY2F0aW9uIG9mIG11bHRpcGxlIERCIHByb3ZpZGVycyB3aXRoaW4gYSByZWd1bGF0b3J5 IGRvbWFpbg0KIC0gInNlY3VyZSIgdHJhbnNtaXNzaW9uIG9mIFJlZ3VsYXRvcnkgSUQgYW5kIERl dmljZSBpZGVudGlmaWNhdGlvbiANCiAgICB0byBEQg0KUHJvcG9zYWwgYmVsb3cgd2FzIHByaW1h cmlseSBmb2N1c2VkIG9uIHRoZSBmaXJzdCByZXF1aXJlbWVudA0KYWJvdmUuICBZb3VyIHByb3Bv c2FsIGZvciBkZXZpY2UgY2VydHMgaXMgZm9yIHRoZSBzZWNvbmQuDQpCb3RoIG1pZ2h0IGJlIHJl cXVpcmVkIC4uLiBkZXZpY2UgY2VydHMgaGF2ZSBvdGhlciBvcHRpb25zIGFsc28NCnRoYW4gbWFu dWZhY3R1cmVyIG9yaWVudGVkIGNlcnRzIGFuZCBpcyBhIGxvbmdlciBkaXNjdXNzaW9uLg0KDQpQ YXVsDQoNCj4gQmVjYXVzZSBzb21lIG1hbnVmYWN0dXJlcnMgdGhpbmsgaXRzIHRvbyBtdWNoIHdv cmsgdG8gZG8gdGhhdD8NCj4gDQo+IEJyaWFuDQo+IA0KPiANCj4gDQo+ICAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiAJUGF1bCBMYW1iZXJ0IFttYWlsdG86cGF1bEBtYXJ2ZWxs LmNvbV0NCj4gU2VudDoJTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgMDM6MTUgUE0gRWFzdGVy biBTdGFuZGFyZCBUaW1lDQo+IFRvOglQZXRlciBNY0Nhbm47IFBldGVyIFN0YW5mb3J0aDsgU3Rl cGhlbiBGYXJyZWxsOw0KPiBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4gQ2M6CXBhd3NAaWV0Zi5v cmcNCj4gU3ViamVjdDoJUmU6IFtwYXdzXSBQQVdTIHNlY3VyaXR5DQo+IA0KPiANCj4gPiBUaGlz IHJlc3RyaWN0aW9uIG1heSBob2xkIHRvZGF5IGZvciB0aGUgRkNDLCBidXQgSSBoYXZlIGEgaGFy ZCB0aW1lDQo+ID4gYmVsaWV2aW5nIHRoYXQgYSBwcmUtZXhpc3RpbmcgbWFudWZhY3R1cmVyLWRh dGFiYXNlIHJlbGF0aW9uc2hpcCB3aWxsDQo+ID4gYmUgbWFuZGF0b3J5IGluIGV2ZXJ5IHJlZ3Vs YXRvcnkgZG9tYWluIGZvciB0aGUgZm9yc2VlYWJsZSBmdXR1cmUuICBJDQo+ID4gdGhpbmsgd2Ug c2hvdWxkIGRlc2lnbiB0byBtaW5pbWl6ZSB0aGUgZnJpY3Rpb24gaW4gY2hhbmdpbmcgZGF0YWJh c2UNCj4gPiBwcm92aWRlcnMuDQo+IA0KPiBUaGUgbGVhc3QgZnJpY3Rpb24gd291bGQgYmUgdG8g aGFyZHdpcmUgZGV2aWNlcyB3aXRoIGEgUEsgInJvb3QiIGZvcg0KPiBlYWNoIHJlZ3VsYXRvcnkg ZG9tYWluIHRoYXQgdGhlIGRldmljZSBzdXBwb3J0cy4NCj4gDQo+IFZhbGlkIERCcyB3b3VsZCBo YXZlIGNyZWRlbnRpYWxzIHNpZ25lZCBieSB0aGUga2V5IGhvbGRlciBvZiByb290cyBmb3INCj4g ZWFjaCByZWd1bGF0b3J5IGRvbWFpbg0KPiANCj4gUGF1bA0KPiANCj4gDQo+ID4gLVBldGUNCj4g Pg0KPiA+IFBldGVyIFN0YW5mb3J0aCB3cm90ZToNCj4gPiA+IEkgY29tcGxldGVseSBhZ3JlZSB3 aXRoIHlvdXIgc3RhdGVtZW50IGJlbG93LiBJZiB3ZSBhcmUgZ29vZCBhbnkNCj4gPiByYWRpbw0K PiA+ID4gd2lsbCBoYXZlIHRoZSAiVGVjaG5pY2FsIiBjYXBhYmlsaXR5IHRvIHdvcmsgd2l0aCBh bnkgZGF0YWJhc2UuDQo+ID4gPiBCVVQsIGFuZCB0aGlzIGlzIGEgYmlnIEJVVCwgdGhlIHJlZ3Vs YXRpb24gbWF5IG5vdCBhbGxvdyBpdCAtIFRoZQ0KPiA+ID4gRkNDIGRvZXMgbm90IHRvZGF5LiBB bmQgYXMgYSBEQkEgSSBvbmx5IHdhbnQgdG8gd29yayB3aXRoIGRldmljZXMNCj4gPiA+IHdoZXJl IEkgaGF2ZSBhIHByZWRlZmluZWQgcmVsYXRpb25zaGlwLiBOb3QgbGVhc3Qgb2Ygd2hpY2gsIGJl Y2F1c2UNCj4gPiA+IGFzIEkgYW0gYXV0aG9yaXplZCBieSBhIFJlZ3VsYXRvciBJIHdhbnQgdG8g bWFrZSBzdXJlIEkgYW0gZG9pbmcNCj4gPiA+IGV2ZXJ5dGhpbmcgSSBjYW4gdG8gYXZvaWQgdGhl aXIgd3JhdGguDQo+ID4gPiBUaGlzIGhhcyBjb21lIHVwIGJlZm9yZS4gUEFXUyBpcyBkZWZpbmlu ZyBhbiBBUEkvUHJvdG9jb2wsIG5vdCB0aGUNCj4gPiA+IHJlZ3VsYXRpb24gbm9yIHRoZSBidXNp bmVzcyBjYXNlcyBhdCB0aGlzIHRpbWUuIFNvIEkgc3RpbGwgc2F5IHRoYXQNCj4gPiB3ZQ0KPiA+ ID4gY2FuIGNvbXBseSB3aXRoIHlvdXIgc3RhdGVtZW50IHdpdGhvdXQgY29uc2lkZXJpbmcgYSAi VXNlciIuDQo+ID4gPg0KPiA+ID4gT24gTW9uU2VwLzEwLzEyIE1vbiBTZXAgMTAsIDI6MTggUE0s ICJQZXRlciBNY0Nhbm4iDQo+ID4gPiA8UGV0ZXIuTWNDYW5uQGh1YXdlaS5jb20+IHdyb3RlOg0K PiA+ID4NCj4gPiA+PiBUaGlzIGlzIGEga2V5IHF1ZXN0aW9uIHdlIG5lZWQgdG8gYW5zd2VyLg0K PiA+ID4+DQo+ID4gPj4gSSB0aG91Z2h0IHdlIHdlcmUgZGVmaW5pbmcgYSBwcm90b2NvbCB0aGF0 IHdvdWxkIGFsbG93IGEgcmFkaW8NCj4gZnJvbQ0KPiA+ID4+IGFueSBtYW51ZmFjdHVyZXIgdG8g aW50ZXJvcGVyYXRlIHdpdGggYSBkYXRhYmFzZSBvZiBhbnkgZGF0YWJhc2UNCj4gPiB2ZW5kb3Iu DQo+ID4gPj4NCj4gPiA+PiAtUGV0ZQ0KPiA+ID4+DQo+ID4gPj4gUGV0ZXIgU3RhbmZvcnRoIHdy b3RlOg0KPiA+ID4+PiBQZXRlLCBJIGFtIG5vdCBzdXJlIEkgYmVsaWV2ZSBpbiBhIHVzZSBjYXNl IHdoZXJlICJ1c2VycyIgbW92ZQ0KPiA+ID4+PiBmcm9tIG9uZSBEQiB0byBhbm90aGVyLiBUaGUg cmVsYXRpb25zaGlwIGlzIGJldHdlZW4gdGhlIHJhZGlvDQo+ID4gPj4+IHZlbmRvciBhbmQgdGhl IERCQS4gVGhlIHJhZGlvIHZlbmRvciBtYXkgaGF2ZSBtdWx0aXBsZQ0KPiA+ID4+PiByZWxhdGlv bnNoaXBzIGFuZCBhbGxvdyBhbiBlbmQgdXNlciAgdG8gY2hvb3NlIG9uZSwgYnV0IGl0IHdpbGwN Cj4gYmUNCj4gPiA+Pj4gZnJvbSB0aGUgcHJlZGVmaW5lZA0KPiA+IGxpc3QuDQo+ID4gPj4+IEFz IGEgREJBIEkgIGRvbid0IHRoaW5rIEkgd291bGQgd2FudCwgYW5kIGluIHRoZSBVU0Egd2UgYXJl IG5vdA0KPiA+ID4+PiBwZXJtaXR0ZWQsIHRvIGVzdGFibGlzaCBhIHJlbGF0aW9uc2hpcCB3aXRo IGEgdXNlciB3aXRob3V0IGENCj4gPiA+Pj4gcHJlZXhpc3RpbmcgcmVsYXRpb25zaGlwIHdpdGgg dGhlIHJhZGlvIHZlbmRvci4gU28gc2VjdXJpdHkNCj4gc2hvdWxkDQo+ID4gPj4+IGJlIHByaW1h cmlseSBhIHJhZGlvIHZlbmRvci1EQkEgaXNzdWUuIFdlYXJpbmcgbXkgREJBIGhhdCBJIGRvbid0 DQo+ID4gPj4+IHRoaW5rIEkgd291bGQgd2FudCB0byBzZXJ2aWNlIGEgcmFkaW8gdGhhdCBJIGRv IG5vdCBoYXZlIGENCj4gPiA+Pj4gcHJlZXhpc3RpbmcgcmVsYXRpb25zaGlwIHdpdGggaXQncyBt YW51ZmFjdHVyZXIuICBJIGFtIG5vdCBzdXJlDQo+ID4gdGhhdA0KPiA+ID4+PiB1c2VyIHJlbGF0 aW9uc2hpcHMgYXJlIGV2ZW4gd2l0aGluIHRoZSBzY29wZSBvZiB3aGF0IFBBV1Mgc2hvdWxkDQo+ ID4gPj4+IGJlDQo+ID4gZGVmaW5pbmcuIFBldGVyIFMuDQo+ID4gPj4+DQo+ID4gPj4+IE9uIE1v blNlcC8xMC8xMiBNb24gU2VwIDEwLCAxOjU4IFBNLCAiUGV0ZXIgTWNDYW5uIg0KPiA+ID4+PiA8 UGV0ZXIuTWNDYW5uQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+ID4+Pg0KPiA+ID4+Pj4gUGVyc29u YWxseSwgSSB0aGluayB0aGF0IG1hbnVhbGx5IHByb3Zpc2lvbmVkIHN5bW1ldHJpYyBrZXlzDQo+ IHdpbGwNCj4gPiA+Pj4+IHNldmVyZWx5IGxpbWl0IHRoZSBhYmlsaXR5IGZvciB1c2VycyB0byBm bGV4aWJseSBtb3ZlIGZyb20gb25lDQo+ID4gPj4+PiBkYXRhYmFzZSBwcm92aWRlciB0byBhbm90 aGVyLiAgSXQgd2lsbCByZXF1aXJlIHNvbWUgc2VjdXJlDQo+ID4gPj4+PiBvdXQtb2YtYmFuZCBj aGFubmVsIG9uIHdoaWNoIHRvIHRyYW5zbWl0IHRoZSBzZWNyZXQga2V5IGZyb20gb25lDQo+ID4g Pj4+PiBwYXJ0eSB0byB0aGUgb3RoZXIsIGFuZCBhIG1lY2hhbmlzbSBmb3IgdGhlIHVzZXIgdG8g cHVzaCB0aGUNCj4gPiBzZWNyZXQNCj4gPiA+Pj4+IGtleSBkb3duIGludG8gdGhlIG1hc3RlciBk ZXZpY2UuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gUHJvdmlzaW9uaW5nIG9mIGNlcnRpZmljYXRlcyBk b2VzIG5vdCByZXF1aXJlIHRoZSBzZWNyZXQNCj4gY2hhbm5lbCwNCj4gPiA+Pj4+IG9ubHkgb25l IHRoYXQgaXMgaW50ZWdyaXR5IHByb3RlY3RlZC4gIEkgdGhpbmsgdGhpcyBpcyBtdWNoDQo+ID4g Pj4+PiBlYXNpZXIgdG8gYWNoaWV2ZSBpbiBwcmFjdGljZS4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAt UGV0ZQ0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCj4gPiA+Pj4+ Pg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gT24gMDkvMDcvMjAxMiAxMDowMSBQTSwgR2Fib3IuQmFq a29Abm9raWEuY29tIHdyb3RlOj4gQXQgdGhlDQo+ID4gPj4+Pj4gVmFuY291dmVyIEYyRiB3ZSBo YWQgZXh0ZW5zaXZlIGRpc2N1c3Npb25zIG9uIHRoZSBzZWN1cml0eQ0KPiBtb2RlbA0KPiA+ID4+ Pj4+IGZvciBQQVdTLiBEcmFmdC1kYXMgcHJvcG9zZXMgdG8gdXNlIHNoYXJlZCBzZWNyZXRzIHBy ZS0NCj4gPiBwcm92aXNpb25lZA0KPiA+ID4+Pj4+IGluIHRoZSBtYXN0ZXIgZGV2aWNlcyBmb3Ig YXV0aGVudGljYXRpb24sIHdoaWxlIGRyYWZ0LWxlaQ0KPiA+IHByb3Bvc2VzDQo+ID4gPj4+Pj4g dG8gbWFuZGF0ZSBjbGllbnQgY2VydGlmaWNhdGVzIGludG8gbWFzdGVyIGRldmljZXMuDQo+ID4g Pj4+Pj4+DQo+ID4gPj4+Pj4+IFRoZXJlIHNlZW1lZCB0byBiZSBhbiB1bmRlcnN0YW5kaW5nIHRo YXQgdGhlIGNyZWRlbnRpYWwgdHlwZXMNCj4gPiA+Pj4+Pj4gaW4NCj4gPiA+Pj4gdXNlDQo+ID4g Pj4+Pj4gZm9yIGF1dGhlbnRpY2F0aW9uIGFyZSBhIG1hdHRlciBvZiBhIGJ1c2luZXNzIG1vZGVs IGNob3NlbiBieQ0KPiA+ID4+Pj4+IHRoZSBwcm92aWRlciB3aGljaCBkZXBsb3lzIHdoaXRlIHNw YWNlIGRldmljZXMsIHJhdGhlciB0aGFuIGENCj4gPiBwcm90b2NvbA0KPiA+ID4+Pj4+IGRlY2lz aW9uLg0KPiA+ID4+Pj4+Pg0KPiA+ID4+Pj4+PiBCcmlhbiBtZW50aW9uZWQgdGhhdCB0aGUgaWVz ZyBtYXkgbm90IGFsbG93IGEgZG9jdW1lbnQgdG8gYmUNCj4gPiA+Pj4+PiBwdWJsaXNoZWQgd2hp Y2ggc3BlY2lmaWVzIGhvdyBzaGFyZWQgc2VjcmV0cyBhcmUgdXNlZCwgYnV0IGRvZXMNCj4gPiA+ Pj4+PiBub3QgaGF2ZSBhIHByb3Zpc2lvbmluZyBtZWNoYW5pc20gZm9yIHRoZSBzaGFyZWQgc2Vj cmV0cw0KPiBkZWZpbmVkLg0KPiA+ID4+Pj4+IEluIG15IG9waW5pb24sIGEgbWVjaGFuaXNtIGZv ciBkaXN0cmlidXRpbmcgc2hhcmVkIHNlY3JldHMgZG9lcw0KPiA+ID4+Pj4+IG5vdCBuZWNlc3Nh cmlseSBoYXZlIHRvIGJlIGRlZmluZWQsIGFzIGEgc2hhcmVkIHNlY3JldCBjYW4gYmUNCj4gPiA+ Pj4+PiBlc3RhYmxpc2hlZCB1c2luZyBjdXJyZW50IHByYWN0aWNlcyB0byBzZXQgdXAgc2hhcmVk IHNlY3JldHMNCj4gPiA+Pj4+PiB3aXRoIGZpbmFuY2lhbCBpbnN0aXR1dGlvbnMgKHVzaW5nIHRo ZSBicm93c2VyKS4NCj4gPiA+Pj4+Pj4gVGh1cywgbXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBk ZXNjcmliZSBpbiB0aGUgZG9jdW1lbnQgaG93IGENCj4gPiA+Pj4+Pj4gc2hhcmVkDQo+ID4gPj4+ Pj4gc2VjcmV0IGFuZCBob3cgYSBjbGllbnQgY2VydGlmaWNhdGUgaXMgdXNlZCB0byBhdXRoZW50 aWNhdGUgYQ0KPiA+ID4+Pj4+IG1hc3RlciBkZXZpY2UuIFRoZW4sIGlmIHdlIHJ1biBpbnRvIGlz c3VlcyB3aXRoIGllc2csIGluIHdvcnN0DQo+ID4gPj4+Pj4gY2FzZSB3ZSBjb3VsZCByZW1vdmUg dGhlIHNoYXJlZCBzZWNyZXQgcGFydCBhbmQga2VlcCB0aGUgb3RoZXINCj4gPiBvbmUuDQo+ID4g Pj4+Pj4+DQo+ID4gPj4+Pj4+IEknZCBsaWtlIHRvIGdldCBhZGRpdGlvbmFsIHZpZXdzIG9uIHRo aXMgdG9waWMuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBJIGNhbiBoZWxwIGEgbGl0dGxlIGhlcmUg KGRlcGVuZGluZyBvbiB5b3VyIGRlZmluaXRpb24gb2YNCj4gPiA+Pj4+PiBoZWxwOi0pDQo+ID4g Pj4+Pj4NCj4gPiA+Pj4+PiBCQ1AgMTA3IFsxXSBpcyB0aGUgb25lIHRvIGxvb2sgYXQgd2hlbiBj b25zaWRlcmluZyBob3cgdG8NCj4gPiBhcHByb2FjaA0KPiA+ID4+Pj4+IGF1dG9tYXRlZCBrZXkg bWFuYWdlbWVudCByZXF1aXJlbWVudHMuIFRoYXQgaGFzIGFuIElNTyB2ZXJ5DQo+IGdvb2QNCj4g PiA+Pj4+PiBhYnN0cmFjdDoNCj4gPiA+Pj4+Pg0KPiA+ID4+Pj4+ICAgIFRoZSBxdWVzdGlvbiBv ZnRlbiBhcmlzZXMgb2Ygd2hldGhlciBhIGdpdmVuIHNlY3VyaXR5IHN5c3RlbQ0KPiA+ID4+Pj4+ ICAgIHJlcXVpcmVzIHNvbWUgZm9ybSBvZiBhdXRvbWF0ZWQga2V5IG1hbmFnZW1lbnQsIG9yIHdo ZXRoZXINCj4gPiBtYW51YWwNCj4gPiA+Pj4+PiAgICBrZXlpbmcgaXMgc3VmZmljaWVudC4gIFRo aXMgbWVtbyBwcm92aWRlcyBndWlkZWxpbmVzIGZvcg0KPiA+IG1ha2luZw0KPiA+ID4+Pj4+ICAg IHN1Y2ggZGVjaXNpb25zLiBXaGVuIHN5bW1ldHJpYyBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMg YXJlDQo+ID4gdXNlZA0KPiA+ID4+Pj4+ICAgIGluIGEgcHJvdG9jb2wsIHRoZSBwcmVzdW1wdGlv biBpcyB0aGF0IGF1dG9tYXRlZCBrZXkNCj4gPiBtYW5hZ2VtZW50DQo+ID4gPj4+Pj4gICAgaXMg Z2VuZXJhbGx5IGJ1dCBub3QgYWx3YXlzIG5lZWRlZC4gIElmIG1hbnVhbCBrZXlpbmcgaXMNCj4g PiA+Pj4+PiBwcm9wb3NlZCwNCj4gPiA+IHRoZQ0KPiA+ID4+Pj4+ICAgIGJ1cmRlbiBvZiBwcm92 aW5nIHRoYXQgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50IGlzIG5vdA0KPiA+IHJlcXVpcmVkDQo+ ID4gPj4+Pj4gICAgZmFsbHMgdG8gdGhlDQo+ID4gPj4+IHByb3Bvc2VyLg0KPiA+ID4+Pj4+IEZv ciB0aG9zZSB0aGF0IG1pZ2h0IGJlIGxlc3MgZmFtaWxpYXIgd2l0aCBJRVRGIHByb2Nlc3Nlcywg dGhlDQo+ID4gPj4+Pj4gZmFjdCB0aGF0IHRoYXQncyBhIEJDUCBtZWFucyB0aGF0IGl0cyBlbnRp cmVseSB2YWxpZCBmb3IgYW4gQUQNCj4gPiA+Pj4+PiB0byBzdHJlbnVvdXNseSBwdXNoIGJhY2sg YWdhaW5zdCBhIFdHIHRoYXQgd2FudHMgdG8gaWdub3JlIHdoYXQNCj4gPiA+Pj4+PiBpdA0KPiA+ IHNheXMuDQo+ID4gPj4+Pj4NCj4gPiA+Pj4+PiBDaGVlcnMsDQo+ID4gPj4+Pj4gUy4NCj4gPiA+ Pj4+Pg0KPiA+ID4+Pj4+IFBTOiBJJ3ZlIG5vdCByZWFkIHRoZSBkcmFmdHMsIGFuZCBjb3VsZG4n dCBtYWtlIHRoZSBzZXNzaW9uIGluDQo+ID4gPj4+Pj4gVmFuY291dmVyLCBzbyB0aGlzIG1pZ2h0 IGJlIGVudGlyZWx5IG9mZiB0b3BpYywgYnV0IGluIHRoZSBjYXNlDQo+ID4gb2YNCj4gPiA+Pj4+ PiBQQVdTIEknZCBhbHNvIGFyZ3VlIHRoYXQgdGhlIHJlZ3VsYXRvcnMnIGFwcGFyZW50IGRlc2ly ZSB0bw0KPiA+ID4+Pj4+IGZvcmNlIGRldmljZXMgdG8gYXV0aGVudGljYXRlIGlzIG5vdCBuZWNl c3NhcmlseSB0aGUgcmlnaHQgb25lDQo+ID4gPj4+Pj4gZm9yIHRoZSBJRVRGIHRvIGZvcmNlIHVw b24gYWxsIHVzZXJzIG9mIHRoZSBQQVdTIHByb3RvY29sLiBTbw0KPiA+ID4+Pj4+IHRoZXJlIGNv dWxkIGZvciBleGFtcGxlIGJlIGEgbW9kZSBvZiBvcGVyYXRpb24gd2hlcmUgdGhlIERCDQo+ID4g Pj4+Pj4gc2lnbnMgc3R1ZmYgYnV0IGRvZXNuJ3QgY2FyZSB3aG8ncyBhc2tpbmcgYW5kIHRoYXQn ZCBiZSBhIGZhcg0KPiA+ID4+Pj4+IGZhciBlYXNpZXIgc2NlbmFyaW8gaW4gdGVybXMgb2YgYXV0 b21hdGVkIGtleSBtYW5hZ2VtZW50Lg0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gWzFdIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2JjcDEwNw0KPiA+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIHBhd3MgbWFpbGluZw0KPiA+ID4+Pj4+IGxpc3Qg cGF3c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MN Cj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPj4+PiBwYXdzIG1haWxpbmcgbGlz dA0KPiA+ID4+Pj4gcGF3c0BpZXRmLm9yZw0KPiA+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4NCj4gPg0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBwYXdzIG1haWxpbmcgbGlzdA0KPiA+IHBhd3NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gcGF3c0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== From paul@marvell.com Mon Sep 10 13:38:44 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1792911E809C for ; Mon, 10 Sep 2012 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf7-fLKB5-1i for ; Mon, 10 Sep 2012 13:38:42 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 390C711E808A for ; Mon, 10 Sep 2012 13:35:01 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUE5O64WAioyiY/u74/YcyYPEE50WDo0O@postini.com; Mon, 10 Sep 2012 13:38:40 PDT Received: from sc-owa02.marvell.com (10.93.76.22) by sc-owa01.marvell.com (10.93.76.21) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Sep 2012 13:29:56 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 10 Sep 2012 13:29:56 -0700 From: Paul Lambert To: "Rosen, Brian" , 'Peter McCann' , 'Peter Stanforth' , 'Stephen Farrell' , "'Gabor.Bajko@nokia.com'" Date: Mon, 10 Sep 2012 13:30:00 -0700 Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaB1pnSSxrDykqv6I2JVxYOfJeD4IlwgAB6rQD//4r34IAAfUcA//+LN1CAAAMcAIAABciBgAAHGvCAAAiH0YAAAF8Q Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E4681ACD@SC-VEXCH2.marvell.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227D6@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227D6@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:38:44 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvc2VuLCBCcmlhbiBbbWFp bHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XQ0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAx MCwgMjAxMiAxOjE0IFBNDQouLi4NCj4gSXQgd291bGQgYmUgZWFzeSB0byBkaXNjb3ZlciB0aGUg Y2VydHMgb2YgdGhlIERCQXMsIGJlY2F1c2UgdGhlcmUgYXJlDQo+IGZldyBvZiB0aGVtLCBhbmQg Y29udHJvbGxlZCBieSByZWd1bGF0b3JzLiAgRGlzY292ZXJ5IG9mIHRoZSBzZXJ2ZXIgY2FuDQo+ IGluY2x1ZGUgZGlzY292ZXJ5IG9mIHRoZSBjZXJ0cy4gIFRoZSBvdGhlciB3YXkgaXMgaGFyZGVy IGZvcg0KPiBtYW51ZmFjdHVyZXJzIGJlY2F1c2Ugb2YgdGhlIGlzc3VlcyB5b3UgY2l0ZSwgYnV0 IG92ZXJhbGwsIGl0J3MgbXVjaA0KPiBlYXNpZXIgdGhhbiBzaGFyZWQgc2VjcmV0cy4NClNvLCB3 ZSBtYXkgYmUgaW4gYWdyZWVtZW50IDotKQ0KDQpUaGUgREJzIGNhbiBiZSBkaXNjb3ZlcmVkLCBi dXQgdGhleSBuZWVkIHNvbWUgY29tbW9uIHRydXN0IHBvaW50DQppbiB0aGUgZGV2aWNlcyBwZXIg cmVndWxhdG9yeSBhdXRob3JpdHkuDQoNCj4gDQo+IEl0IGlzIGEgcmVxdWlyZW1lbnQgdG8gYXV0 aGVudGljYXRlIGJvdGggc2lkZXMsIHNvIHdlIG5lZWQgc29sdXRpb25zDQo+IGZvciBib3RoLg0K TG9va2luZyBhdCB0aGUgc2VjdXJpdHkgc3R1ZmYgZG9jdW1lbnRlZCBieSB0aGlzIGdyb3VwLCB3 ZSBoYXZlDQphcyBhIHRocmVhdDoNCiAgICAzLjIuMS4gIEltcGVyc29uYXRpb24gb2YgYSBtYXN0 ZXIgZGV2aWNlDQpBIGxpdHRsZSBsYXRlIGZvciBtZSB0byBhcmd1ZSB0aGlzIHJlcXVpcmVtZW50 LCBzbyB5ZXMgd2UNCmhhdmUgY3JlYXRlZCBhIHJlcXVpcmVtZW50IGZvciBtYXN0ZXIgZGV2aWNl IGF1dGhlbnRpY2F0aW9uLg0KSSBkb24ndCBzZWUgd2h5IGEgUm9ndWUgZGV2aWNlIGV2ZW4gY2Fy ZXMgYWJvdXQgdGhlIERCLiAgVGhlDQpkZXZpY2VzIGFyZSAiY2VydGlmaWVkIiBhcyBjb21wbGlh bnQgdG8gdGhlIHJlZ3VsYXRvcnkgcnVsZXMuDQpFeHRyYSBjcnlwdG9ncmFwaHkgd2lsbCBub3Qg cHJldmVudCBSb2d1ZSBkZXZpY2VzIGZyb20gc2ltcGx5DQp0cmFuc21pdHRpbmcgaW4gd2hhdGV2 ZXIgY2hhbm5lbCB0aGV5IHdhbnQuICANCg0KR2l2ZW4gdGhpcyBjbGllbnQgYXV0aGVudGljYXRp b24gcmVxdWlyZW1lbnQgLSBJIHRvdGFsbHkgYWdyZWUNCnRoYXQgY2xpZW50IHB1YmxpYyBrZXlz IGFyZSBhIGxpdHRsZSBtb3JlIHdvcmssIGJ1dCBhbHdheXMgDQpiZXR0ZXIgdGhhbiBkaXN0cmli dXRpbmcgc2VjcmV0IGtleXMuDQoNClBhdWwNCg0KPiANCj4gQnJpYW4NCj4gDQo+IA0KPiANCj4g IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IAlQYXVsIExhbWJlcnQgW21haWx0 bzpwYXVsQG1hcnZlbGwuY29tXQ0KPiBTZW50OglNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiAw NDowNCBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCj4gVG86CVJvc2VuLCBCcmlhbjsgJ1BldGVy IE1jQ2Fubic7ICdQZXRlciBTdGFuZm9ydGgnOyAnU3RlcGhlbg0KPiBGYXJyZWxsJzsgJ0dhYm9y LkJhamtvQG5va2lhLmNvbScNCj4gQ2M6CSdwYXdzQGlldGYub3JnJw0KPiBTdWJqZWN0OglSRTog W3Bhd3NdIFBBV1Mgc2VjdXJpdHkNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBSb3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0N Cj4gLi4uDQo+ID4gVGhlIGVhc2llc3Qgd2F5IHRvIGRvIHRoaXMgaXMgdG8gaGF2ZSB0aGUgbWFu dWZhY3R1cmVyIHB1dCBhIGNlcnQgaW4NCj4gPiB0aGUgZGV2aWNlIHRoYXQgaXQgc2lnbnMuICBU aGVuIHRoZSBvbmx5IHRoaW5nIHRoZSBkYXRhYmFzZSBuZWVkcyBpcw0KPiA+IHRoZSBwdWJsaWMg a2V5IG9mIHRoZSBtYW51ZmFjdHVyZXIsDQo+IFlvdSBjYW5ub3QgcHJldmVudCBzcG9vZmluZyBv ZiBhIERCIHdpdGhvdXQgaGF2aW5nIGEgcm9vdCBvZiBzb21lIHNvcnQNCj4gdGhhdCAiY2VydGlm aWVzIiByZWFsIGRiIHByb3ZpZGVycy4gIFRoaXMgaXMgYSBzbWFsbCBudW1iZXIgb2YNCj4gY2Vy dGlmaWNhdGVzIGluc3RhbGxlZCBpbiB0aGUgc2VydmVycy4NCj4gDQo+IEhhdmluZyBhIHBlci1k ZXZpY2UgY2VydCBzaWduZWQgYnkgYSBtYW51ZmFjdHVyZXIgYW5kIGluc3RhbGxlZCBpbiB0aGUN Cj4gZmFjdG9yeSBpcyBoYXJkZXIuICBJdCdzIG1vcmUgY2VydGlmaWNhdGVzIGFuZCBjb21wbGlj YXRlcyB0aGUNCj4gbWFudWZhY3R1cmluZyBwcm9jZXNzLiAgVGhlIGF1dGhlbnRpY2F0aW9uIHRv IGEgbWFudWZhY3R1cmVyIGlzIG5vdA0KPiBuZWNlc3NhcmlseSB1c2VmdWwuIFRoZSBhdXRoZW50 aWNhdGlvbiBvZiB0aGUgbWFudWZhY3R1cmVycyBGQ0MgSUQgYW5kDQo+IGRldmljZSBJZCBtaWdo dCBiZSBvZiBpbnRlcmVzdCwgYnV0IHRoZSByZWd1bGF0aW9ucyBkbyBub3QgbWFuZGF0ZQ0KPiAo QUZBSUspIHRoaXMgY29tcGxleGl0eSBvZiBhc3NpZ25tZW50IG9mIGEgZmV3IGJpdHMgb2YgcGVy IGRldmljZQ0KPiByZWd1bGF0b3J5IGluZm9ybWF0aW9uLg0KPiANCj4gPiBXaHkgZG8gd2Ugd2Fu dCB0byBtYWtlIHRoaXMgaGFyZGVyPw0KPiBUaGVyZSBhcmUgdHdvIHJlcXVpcmVtZW50czoNCj4g IC0gYXV0aGVudGljYXRpb24gb2YgbXVsdGlwbGUgREIgcHJvdmlkZXJzIHdpdGhpbiBhIHJlZ3Vs YXRvcnkgZG9tYWluDQo+ICAtICJzZWN1cmUiIHRyYW5zbWlzc2lvbiBvZiBSZWd1bGF0b3J5IElE IGFuZCBEZXZpY2UgaWRlbnRpZmljYXRpb24NCj4gICAgIHRvIERCDQo+IFByb3Bvc2FsIGJlbG93 IHdhcyBwcmltYXJpbHkgZm9jdXNlZCBvbiB0aGUgZmlyc3QgcmVxdWlyZW1lbnQgYWJvdmUuDQo+ IFlvdXIgcHJvcG9zYWwgZm9yIGRldmljZSBjZXJ0cyBpcyBmb3IgdGhlIHNlY29uZC4NCj4gQm90 aCBtaWdodCBiZSByZXF1aXJlZCAuLi4gZGV2aWNlIGNlcnRzIGhhdmUgb3RoZXIgb3B0aW9ucyBh bHNvIHRoYW4NCj4gbWFudWZhY3R1cmVyIG9yaWVudGVkIGNlcnRzIGFuZCBpcyBhIGxvbmdlciBk aXNjdXNzaW9uLg0KPiANCj4gUGF1bA0KPiANCj4gPiBCZWNhdXNlIHNvbWUgbWFudWZhY3R1cmVy cyB0aGluayBpdHMgdG9vIG11Y2ggd29yayB0byBkbyB0aGF0Pw0KPiA+DQo+ID4gQnJpYW4NCj4g Pg0KPiA+DQo+ID4NCj4gPiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiAJ UGF1bCBMYW1iZXJ0IFttYWlsdG86cGF1bEBtYXJ2ZWxsLmNvbV0NCj4gPiBTZW50OglNb25kYXks IFNlcHRlbWJlciAxMCwgMjAxMiAwMzoxNSBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNCj4gPiBU bzoJUGV0ZXIgTWNDYW5uOyBQZXRlciBTdGFuZm9ydGg7IFN0ZXBoZW4gRmFycmVsbDsNCj4gPiBH YWJvci5CYWprb0Bub2tpYS5jb20NCj4gPiBDYzoJcGF3c0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6 CVJlOiBbcGF3c10gUEFXUyBzZWN1cml0eQ0KPiA+DQo+ID4NCj4gPiA+IFRoaXMgcmVzdHJpY3Rp b24gbWF5IGhvbGQgdG9kYXkgZm9yIHRoZSBGQ0MsIGJ1dCBJIGhhdmUgYSBoYXJkIHRpbWUNCj4g PiA+IGJlbGlldmluZyB0aGF0IGEgcHJlLWV4aXN0aW5nIG1hbnVmYWN0dXJlci1kYXRhYmFzZSBy ZWxhdGlvbnNoaXANCj4gPiA+IHdpbGwgYmUgbWFuZGF0b3J5IGluIGV2ZXJ5IHJlZ3VsYXRvcnkg ZG9tYWluIGZvciB0aGUgZm9yc2VlYWJsZQ0KPiA+ID4gZnV0dXJlLiAgSSB0aGluayB3ZSBzaG91 bGQgZGVzaWduIHRvIG1pbmltaXplIHRoZSBmcmljdGlvbiBpbg0KPiA+ID4gY2hhbmdpbmcgZGF0 YWJhc2UgcHJvdmlkZXJzLg0KPiA+DQo+ID4gVGhlIGxlYXN0IGZyaWN0aW9uIHdvdWxkIGJlIHRv IGhhcmR3aXJlIGRldmljZXMgd2l0aCBhIFBLICJyb290IiBmb3INCj4gPiBlYWNoIHJlZ3VsYXRv cnkgZG9tYWluIHRoYXQgdGhlIGRldmljZSBzdXBwb3J0cy4NCj4gPg0KPiA+IFZhbGlkIERCcyB3 b3VsZCBoYXZlIGNyZWRlbnRpYWxzIHNpZ25lZCBieSB0aGUga2V5IGhvbGRlciBvZiByb290cw0K PiBmb3INCj4gPiBlYWNoIHJlZ3VsYXRvcnkgZG9tYWluDQo+ID4NCj4gPiBQYXVsDQo+ID4NCj4g Pg0KPiA+ID4gLVBldGUNCj4gPiA+DQo+ID4gPiBQZXRlciBTdGFuZm9ydGggd3JvdGU6DQo+ID4g PiA+IEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IGJlbG93LiBJZiB3ZSBh cmUgZ29vZCBhbnkNCj4gPiA+IHJhZGlvDQo+ID4gPiA+IHdpbGwgaGF2ZSB0aGUgIlRlY2huaWNh bCIgY2FwYWJpbGl0eSB0byB3b3JrIHdpdGggYW55IGRhdGFiYXNlLg0KPiA+ID4gPiBCVVQsIGFu ZCB0aGlzIGlzIGEgYmlnIEJVVCwgdGhlIHJlZ3VsYXRpb24gbWF5IG5vdCBhbGxvdyBpdCAtIFRo ZQ0KPiA+ID4gPiBGQ0MgZG9lcyBub3QgdG9kYXkuIEFuZCBhcyBhIERCQSBJIG9ubHkgd2FudCB0 byB3b3JrIHdpdGggZGV2aWNlcw0KPiA+ID4gPiB3aGVyZSBJIGhhdmUgYSBwcmVkZWZpbmVkIHJl bGF0aW9uc2hpcC4gTm90IGxlYXN0IG9mIHdoaWNoLA0KPiA+ID4gPiBiZWNhdXNlIGFzIEkgYW0g YXV0aG9yaXplZCBieSBhIFJlZ3VsYXRvciBJIHdhbnQgdG8gbWFrZSBzdXJlIEkNCj4gYW0NCj4g PiA+ID4gZG9pbmcgZXZlcnl0aGluZyBJIGNhbiB0byBhdm9pZCB0aGVpciB3cmF0aC4NCj4gPiA+ ID4gVGhpcyBoYXMgY29tZSB1cCBiZWZvcmUuIFBBV1MgaXMgZGVmaW5pbmcgYW4gQVBJL1Byb3Rv Y29sLCBub3QNCj4gdGhlDQo+ID4gPiA+IHJlZ3VsYXRpb24gbm9yIHRoZSBidXNpbmVzcyBjYXNl cyBhdCB0aGlzIHRpbWUuIFNvIEkgc3RpbGwgc2F5DQo+ID4gPiA+IHRoYXQNCj4gPiA+IHdlDQo+ ID4gPiA+IGNhbiBjb21wbHkgd2l0aCB5b3VyIHN0YXRlbWVudCB3aXRob3V0IGNvbnNpZGVyaW5n IGEgIlVzZXIiLg0KPiA+ID4gPg0KPiA+ID4gPiBPbiBNb25TZXAvMTAvMTIgTW9uIFNlcCAxMCwg MjoxOCBQTSwgIlBldGVyIE1jQ2FubiINCj4gPiA+ID4gPFBldGVyLk1jQ2FubkBodWF3ZWkuY29t PiB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4+IFRoaXMgaXMgYSBrZXkgcXVlc3Rpb24gd2UgbmVl ZCB0byBhbnN3ZXIuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gSSB0aG91Z2h0IHdlIHdlcmUgZGVmaW5p bmcgYSBwcm90b2NvbCB0aGF0IHdvdWxkIGFsbG93IGEgcmFkaW8NCj4gPiBmcm9tDQo+ID4gPiA+ PiBhbnkgbWFudWZhY3R1cmVyIHRvIGludGVyb3BlcmF0ZSB3aXRoIGEgZGF0YWJhc2Ugb2YgYW55 IGRhdGFiYXNlDQo+ID4gPiB2ZW5kb3IuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gLVBldGUNCj4gPiA+ ID4+DQo+ID4gPiA+PiBQZXRlciBTdGFuZm9ydGggd3JvdGU6DQo+ID4gPiA+Pj4gUGV0ZSwgSSBh bSBub3Qgc3VyZSBJIGJlbGlldmUgaW4gYSB1c2UgY2FzZSB3aGVyZSAidXNlcnMiIG1vdmUNCj4g PiA+ID4+PiBmcm9tIG9uZSBEQiB0byBhbm90aGVyLiBUaGUgcmVsYXRpb25zaGlwIGlzIGJldHdl ZW4gdGhlIHJhZGlvDQo+ID4gPiA+Pj4gdmVuZG9yIGFuZCB0aGUgREJBLiBUaGUgcmFkaW8gdmVu ZG9yIG1heSBoYXZlIG11bHRpcGxlDQo+ID4gPiA+Pj4gcmVsYXRpb25zaGlwcyBhbmQgYWxsb3cg YW4gZW5kIHVzZXIgIHRvIGNob29zZSBvbmUsIGJ1dCBpdCB3aWxsDQo+ID4gYmUNCj4gPiA+ID4+ PiBmcm9tIHRoZSBwcmVkZWZpbmVkDQo+ID4gPiBsaXN0Lg0KPiA+ID4gPj4+IEFzIGEgREJBIEkg IGRvbid0IHRoaW5rIEkgd291bGQgd2FudCwgYW5kIGluIHRoZSBVU0Egd2UgYXJlIG5vdA0KPiA+ ID4gPj4+IHBlcm1pdHRlZCwgdG8gZXN0YWJsaXNoIGEgcmVsYXRpb25zaGlwIHdpdGggYSB1c2Vy IHdpdGhvdXQgYQ0KPiA+ID4gPj4+IHByZWV4aXN0aW5nIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBy YWRpbyB2ZW5kb3IuIFNvIHNlY3VyaXR5DQo+ID4gc2hvdWxkDQo+ID4gPiA+Pj4gYmUgcHJpbWFy aWx5IGEgcmFkaW8gdmVuZG9yLURCQSBpc3N1ZS4gV2VhcmluZyBteSBEQkEgaGF0IEkNCj4gPiA+ ID4+PiBkb24ndCB0aGluayBJIHdvdWxkIHdhbnQgdG8gc2VydmljZSBhIHJhZGlvIHRoYXQgSSBk byBub3QgaGF2ZQ0KPiBhDQo+ID4gPiA+Pj4gcHJlZXhpc3RpbmcgcmVsYXRpb25zaGlwIHdpdGgg aXQncyBtYW51ZmFjdHVyZXIuICBJIGFtIG5vdCBzdXJlDQo+ID4gPiB0aGF0DQo+ID4gPiA+Pj4g dXNlciByZWxhdGlvbnNoaXBzIGFyZSBldmVuIHdpdGhpbiB0aGUgc2NvcGUgb2Ygd2hhdCBQQVdT DQo+IHNob3VsZA0KPiA+ID4gPj4+IGJlDQo+ID4gPiBkZWZpbmluZy4gUGV0ZXIgUy4NCj4gPiA+ ID4+Pg0KPiA+ID4gPj4+IE9uIE1vblNlcC8xMC8xMiBNb24gU2VwIDEwLCAxOjU4IFBNLCAiUGV0 ZXIgTWNDYW5uIg0KPiA+ID4gPj4+IDxQZXRlci5NY0Nhbm5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+ ID4gPiA+Pj4NCj4gPiA+ID4+Pj4gUGVyc29uYWxseSwgSSB0aGluayB0aGF0IG1hbnVhbGx5IHBy b3Zpc2lvbmVkIHN5bW1ldHJpYyBrZXlzDQo+ID4gd2lsbA0KPiA+ID4gPj4+PiBzZXZlcmVseSBs aW1pdCB0aGUgYWJpbGl0eSBmb3IgdXNlcnMgdG8gZmxleGlibHkgbW92ZSBmcm9tIG9uZQ0KPiA+ ID4gPj4+PiBkYXRhYmFzZSBwcm92aWRlciB0byBhbm90aGVyLiAgSXQgd2lsbCByZXF1aXJlIHNv bWUgc2VjdXJlDQo+ID4gPiA+Pj4+IG91dC1vZi1iYW5kIGNoYW5uZWwgb24gd2hpY2ggdG8gdHJh bnNtaXQgdGhlIHNlY3JldCBrZXkgZnJvbQ0KPiA+ID4gPj4+PiBvbmUgcGFydHkgdG8gdGhlIG90 aGVyLCBhbmQgYSBtZWNoYW5pc20gZm9yIHRoZSB1c2VyIHRvIHB1c2gNCj4gPiA+ID4+Pj4gdGhl DQo+ID4gPiBzZWNyZXQNCj4gPiA+ID4+Pj4ga2V5IGRvd24gaW50byB0aGUgbWFzdGVyIGRldmlj ZS4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gUHJvdmlzaW9uaW5nIG9mIGNlcnRpZmljYXRlcyBk b2VzIG5vdCByZXF1aXJlIHRoZSBzZWNyZXQNCj4gPiBjaGFubmVsLA0KPiA+ID4gPj4+PiBvbmx5 IG9uZSB0aGF0IGlzIGludGVncml0eSBwcm90ZWN0ZWQuICBJIHRoaW5rIHRoaXMgaXMgbXVjaA0K PiA+ID4gPj4+PiBlYXNpZXIgdG8gYWNoaWV2ZSBpbiBwcmFjdGljZS4NCj4gPiA+ID4+Pj4NCj4g PiA+ID4+Pj4gLVBldGUNCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gU3RlcGhlbiBGYXJyZWxsIHdy b3RlOg0KPiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBPbiAwOS8wNy8yMDEy IDEwOjAxIFBNLCBHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6PiBBdCB0aGUNCj4gPiA+ID4+ Pj4+IFZhbmNvdXZlciBGMkYgd2UgaGFkIGV4dGVuc2l2ZSBkaXNjdXNzaW9ucyBvbiB0aGUgc2Vj dXJpdHkNCj4gPiBtb2RlbA0KPiA+ID4gPj4+Pj4gZm9yIFBBV1MuIERyYWZ0LWRhcyBwcm9wb3Nl cyB0byB1c2Ugc2hhcmVkIHNlY3JldHMgcHJlLQ0KPiA+ID4gcHJvdmlzaW9uZWQNCj4gPiA+ID4+ Pj4+IGluIHRoZSBtYXN0ZXIgZGV2aWNlcyBmb3IgYXV0aGVudGljYXRpb24sIHdoaWxlIGRyYWZ0 LWxlaQ0KPiA+ID4gcHJvcG9zZXMNCj4gPiA+ID4+Pj4+IHRvIG1hbmRhdGUgY2xpZW50IGNlcnRp ZmljYXRlcyBpbnRvIG1hc3RlciBkZXZpY2VzLg0KPiA+ID4gPj4+Pj4+DQo+ID4gPiA+Pj4+Pj4g VGhlcmUgc2VlbWVkIHRvIGJlIGFuIHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgY3JlZGVudGlhbA0K PiB0eXBlcw0KPiA+ID4gPj4+Pj4+IGluDQo+ID4gPiA+Pj4gdXNlDQo+ID4gPiA+Pj4+PiBmb3Ig YXV0aGVudGljYXRpb24gYXJlIGEgbWF0dGVyIG9mIGEgYnVzaW5lc3MgbW9kZWwgY2hvc2VuIGJ5 DQo+ID4gPiA+Pj4+PiB0aGUgcHJvdmlkZXIgd2hpY2ggZGVwbG95cyB3aGl0ZSBzcGFjZSBkZXZp Y2VzLCByYXRoZXIgdGhhbiBhDQo+ID4gPiBwcm90b2NvbA0KPiA+ID4gPj4+Pj4gZGVjaXNpb24u DQo+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4+Pj4+PiBCcmlhbiBtZW50aW9uZWQgdGhhdCB0aGUgaWVz ZyBtYXkgbm90IGFsbG93IGEgZG9jdW1lbnQgdG8gYmUNCj4gPiA+ID4+Pj4+IHB1Ymxpc2hlZCB3 aGljaCBzcGVjaWZpZXMgaG93IHNoYXJlZCBzZWNyZXRzIGFyZSB1c2VkLCBidXQNCj4gPiA+ID4+ Pj4+IGRvZXMgbm90IGhhdmUgYSBwcm92aXNpb25pbmcgbWVjaGFuaXNtIGZvciB0aGUgc2hhcmVk IHNlY3JldHMNCj4gPiBkZWZpbmVkLg0KPiA+ID4gPj4+Pj4gSW4gbXkgb3BpbmlvbiwgYSBtZWNo YW5pc20gZm9yIGRpc3RyaWJ1dGluZyBzaGFyZWQgc2VjcmV0cw0KPiA+ID4gPj4+Pj4gZG9lcyBu b3QgbmVjZXNzYXJpbHkgaGF2ZSB0byBiZSBkZWZpbmVkLCBhcyBhIHNoYXJlZCBzZWNyZXQNCj4g PiA+ID4+Pj4+IGNhbiBiZSBlc3RhYmxpc2hlZCB1c2luZyBjdXJyZW50IHByYWN0aWNlcyB0byBz ZXQgdXAgc2hhcmVkDQo+ID4gPiA+Pj4+PiBzZWNyZXRzIHdpdGggZmluYW5jaWFsIGluc3RpdHV0 aW9ucyAodXNpbmcgdGhlIGJyb3dzZXIpLg0KPiA+ID4gPj4+Pj4+IFRodXMsIG15IHN1Z2dlc3Rp b24gd291bGQgYmUgdG8gZGVzY3JpYmUgaW4gdGhlIGRvY3VtZW50IGhvdw0KPiA+ID4gPj4+Pj4+ IGEgc2hhcmVkDQo+ID4gPiA+Pj4+PiBzZWNyZXQgYW5kIGhvdyBhIGNsaWVudCBjZXJ0aWZpY2F0 ZSBpcyB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBhDQo+ID4gPiA+Pj4+PiBtYXN0ZXIgZGV2aWNlLiBU aGVuLCBpZiB3ZSBydW4gaW50byBpc3N1ZXMgd2l0aCBpZXNnLCBpbg0KPiB3b3JzdA0KPiA+ID4g Pj4+Pj4gY2FzZSB3ZSBjb3VsZCByZW1vdmUgdGhlIHNoYXJlZCBzZWNyZXQgcGFydCBhbmQga2Vl cCB0aGUNCj4gb3RoZXINCj4gPiA+IG9uZS4NCj4gPiA+ID4+Pj4+Pg0KPiA+ID4gPj4+Pj4+IEkn ZCBsaWtlIHRvIGdldCBhZGRpdGlvbmFsIHZpZXdzIG9uIHRoaXMgdG9waWMuDQo+ID4gPiA+Pj4+ Pg0KPiA+ID4gPj4+Pj4gSSBjYW4gaGVscCBhIGxpdHRsZSBoZXJlIChkZXBlbmRpbmcgb24geW91 ciBkZWZpbml0aW9uIG9mDQo+ID4gPiA+Pj4+PiBoZWxwOi0pDQo+ID4gPiA+Pj4+Pg0KPiA+ID4g Pj4+Pj4gQkNQIDEwNyBbMV0gaXMgdGhlIG9uZSB0byBsb29rIGF0IHdoZW4gY29uc2lkZXJpbmcg aG93IHRvDQo+ID4gPiBhcHByb2FjaA0KPiA+ID4gPj4+Pj4gYXV0b21hdGVkIGtleSBtYW5hZ2Vt ZW50IHJlcXVpcmVtZW50cy4gVGhhdCBoYXMgYW4gSU1PIHZlcnkNCj4gPiBnb29kDQo+ID4gPiA+ Pj4+PiBhYnN0cmFjdDoNCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiAgICBUaGUgcXVlc3Rpb24g b2Z0ZW4gYXJpc2VzIG9mIHdoZXRoZXIgYSBnaXZlbiBzZWN1cml0eQ0KPiBzeXN0ZW0NCj4gPiA+ ID4+Pj4+ICAgIHJlcXVpcmVzIHNvbWUgZm9ybSBvZiBhdXRvbWF0ZWQga2V5IG1hbmFnZW1lbnQs IG9yIHdoZXRoZXINCj4gPiA+IG1hbnVhbA0KPiA+ID4gPj4+Pj4gICAga2V5aW5nIGlzIHN1ZmZp Y2llbnQuICBUaGlzIG1lbW8gcHJvdmlkZXMgZ3VpZGVsaW5lcyBmb3INCj4gPiA+IG1ha2luZw0K PiA+ID4gPj4+Pj4gICAgc3VjaCBkZWNpc2lvbnMuIFdoZW4gc3ltbWV0cmljIGNyeXB0b2dyYXBo aWMgbWVjaGFuaXNtcw0KPiBhcmUNCj4gPiA+IHVzZWQNCj4gPiA+ID4+Pj4+ICAgIGluIGEgcHJv dG9jb2wsIHRoZSBwcmVzdW1wdGlvbiBpcyB0aGF0IGF1dG9tYXRlZCBrZXkNCj4gPiA+IG1hbmFn ZW1lbnQNCj4gPiA+ID4+Pj4+ICAgIGlzIGdlbmVyYWxseSBidXQgbm90IGFsd2F5cyBuZWVkZWQu ICBJZiBtYW51YWwga2V5aW5nIGlzDQo+ID4gPiA+Pj4+PiBwcm9wb3NlZCwNCj4gPiA+ID4gdGhl DQo+ID4gPiA+Pj4+PiAgICBidXJkZW4gb2YgcHJvdmluZyB0aGF0IGF1dG9tYXRlZCBrZXkgbWFu YWdlbWVudCBpcyBub3QNCj4gPiA+IHJlcXVpcmVkDQo+ID4gPiA+Pj4+PiAgICBmYWxscyB0byB0 aGUNCj4gPiA+ID4+PiBwcm9wb3Nlci4NCj4gPiA+ID4+Pj4+IEZvciB0aG9zZSB0aGF0IG1pZ2h0 IGJlIGxlc3MgZmFtaWxpYXIgd2l0aCBJRVRGIHByb2Nlc3NlcywNCj4gdGhlDQo+ID4gPiA+Pj4+ PiBmYWN0IHRoYXQgdGhhdCdzIGEgQkNQIG1lYW5zIHRoYXQgaXRzIGVudGlyZWx5IHZhbGlkIGZv ciBhbg0KPiBBRA0KPiA+ID4gPj4+Pj4gdG8gc3RyZW51b3VzbHkgcHVzaCBiYWNrIGFnYWluc3Qg YSBXRyB0aGF0IHdhbnRzIHRvIGlnbm9yZQ0KPiA+ID4gPj4+Pj4gd2hhdCBpdA0KPiA+ID4gc2F5 cy4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBDaGVlcnMsDQo+ID4gPiA+Pj4+PiBTLg0KPiA+ ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IFBTOiBJJ3ZlIG5vdCByZWFkIHRoZSBkcmFmdHMsIGFuZCBj b3VsZG4ndCBtYWtlIHRoZSBzZXNzaW9uDQo+IGluDQo+ID4gPiA+Pj4+PiBWYW5jb3V2ZXIsIHNv IHRoaXMgbWlnaHQgYmUgZW50aXJlbHkgb2ZmIHRvcGljLCBidXQgaW4gdGhlDQo+ID4gPiA+Pj4+ PiBjYXNlDQo+ID4gPiBvZg0KPiA+ID4gPj4+Pj4gUEFXUyBJJ2QgYWxzbyBhcmd1ZSB0aGF0IHRo ZSByZWd1bGF0b3JzJyBhcHBhcmVudCBkZXNpcmUgdG8NCj4gPiA+ID4+Pj4+IGZvcmNlIGRldmlj ZXMgdG8gYXV0aGVudGljYXRlIGlzIG5vdCBuZWNlc3NhcmlseSB0aGUgcmlnaHQNCj4gb25lDQo+ ID4gPiA+Pj4+PiBmb3IgdGhlIElFVEYgdG8gZm9yY2UgdXBvbiBhbGwgdXNlcnMgb2YgdGhlIFBB V1MgcHJvdG9jb2wuIFNvDQo+ID4gPiA+Pj4+PiB0aGVyZSBjb3VsZCBmb3IgZXhhbXBsZSBiZSBh IG1vZGUgb2Ygb3BlcmF0aW9uIHdoZXJlIHRoZSBEQg0KPiA+ID4gPj4+Pj4gc2lnbnMgc3R1ZmYg YnV0IGRvZXNuJ3QgY2FyZSB3aG8ncyBhc2tpbmcgYW5kIHRoYXQnZCBiZSBhIGZhcg0KPiA+ID4g Pj4+Pj4gZmFyIGVhc2llciBzY2VuYXJpbyBpbiB0ZXJtcyBvZiBhdXRvbWF0ZWQga2V5IG1hbmFn ZW1lbnQuDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gWzFdIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2JjcDEwNw0KPiA+ID4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18gcGF3cyBtYWlsaW5nDQo+ID4gPiA+Pj4+PiBsaXN0IHBhd3NAaWV0 Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4gPiA+ Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+DQo+ID4gPiA+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+Pj4+IHBhd3MgbWFpbGluZyBs aXN0DQo+ID4gPiA+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4gPiA+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPiA+IHBhd3NA aWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3 cw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gcGF3cyBtYWlsaW5nIGxpc3QNCj4gPiBwYXdzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From stephen.farrell@cs.tcd.ie Mon Sep 10 13:47:13 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B5611E80D7 for ; Mon, 10 Sep 2012 13:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.672 X-Spam-Level: X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e+UsbtLqXFm for ; Mon, 10 Sep 2012 13:47:12 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E050111E808A for ; Mon, 10 Sep 2012 13:47:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5799C171474; Mon, 10 Sep 2012 21:47:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347310030; bh=gYtVAl6pWYcIQ4 N0jCW0tRDnBVONiutSJHESjWeUdXc=; b=1Way1PnVI88WVyr//4eNzvkrfPwMLh lTw2hMoZgmKUrf5xe9WnB69PUXfz4KqrUJJFuoKLvOj3nUmuPH6vatsJ9TtPDFjz Y92Bt/y1FfWNn3eMePTBItXRYWcSFBSz+Ozuunp0AXHXR52RATaMNJaNRtSfll0i 4AoIhRZD7MoSyY+pttOhdY1CvvJ8wYlr2knagPtAxseqyPAbIlv4vXjU5RrJxDcG lHtyv5jDq1+nVXYaPedtjeLd4hXi0TxSBws5lepmppm6mNAD/TwM5OajZy5hseNu PHs/ohOhTR2WtQqI48hHrpSyWMk5WiaNv2HtJ05mNQgMJXajyfYXE7wA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id WOIMtzZFJn3l; Mon, 10 Sep 2012 21:47:10 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.29.198]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 21ED9171473; Mon, 10 Sep 2012 21:47:10 +0100 (IST) Message-ID: <504E51CD.7070606@cs.tcd.ie> Date: Mon, 10 Sep 2012 21:47:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Paul Lambert References: <55A5A9A87506CB4BA580BF9D531957DA690227D6@STNTEXCH01.cis.neustar.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E4681ACD@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E4681ACD@SC-VEXCH2.marvell.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:47:13 -0000 On 09/10/2012 09:30 PM, Paul Lambert wrote: > >> -----Original Message----- >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Monday, September 10, 2012 1:14 PM > ... >> It would be easy to discover the certs of the DBAs, because there are >> few of them, and controlled by regulators. Discovery of the server can >> include discovery of the certs. The other way is harder for >> manufacturers because of the issues you cite, but overall, it's much >> easier than shared secrets. > So, we may be in agreement :-) > > The DBs can be discovered, but they need some common trust point > in the devices per regulatory authority. > >> >> It is a requirement to authenticate both sides, so we need solutions >> for both. > Looking at the security stuff documented by this group, we have > as a threat: > 3.2.1. Impersonation of a master device Where's that? I only see a "MAY" in [1] for client auth (which I think is correct). S. [1] http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-08#section-8 > A little late for me to argue this requirement, so yes we > have created a requirement for master device authentication. > I don't see why a Rogue device even cares about the DB. The > devices are "certified" as compliant to the regulatory rules. > Extra cryptography will not prevent Rogue devices from simply > transmitting in whatever channel they want. > > Given this client authentication requirement - I totally agree > that client public keys are a little more work, but always > better than distributing secret keys. > > Paul > >> >> Brian >> >> >> >> -----Original Message----- >> From: Paul Lambert [mailto:paul@marvell.com] >> Sent: Monday, September 10, 2012 04:04 PM Eastern Standard Time >> To: Rosen, Brian; 'Peter McCann'; 'Peter Stanforth'; 'Stephen >> Farrell'; 'Gabor.Bajko@nokia.com' >> Cc: 'paws@ietf.org' >> Subject: RE: [paws] PAWS security >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> ... >>> The easiest way to do this is to have the manufacturer put a cert in >>> the device that it signs. Then the only thing the database needs is >>> the public key of the manufacturer, >> You cannot prevent spoofing of a DB without having a root of some sort >> that "certifies" real db providers. This is a small number of >> certificates installed in the servers. >> >> Having a per-device cert signed by a manufacturer and installed in the >> factory is harder. It's more certificates and complicates the >> manufacturing process. The authentication to a manufacturer is not >> necessarily useful. The authentication of the manufacturers FCC ID and >> device Id might be of interest, but the regulations do not mandate >> (AFAIK) this complexity of assignment of a few bits of per device >> regulatory information. >> >>> Why do we want to make this harder? >> There are two requirements: >> - authentication of multiple DB providers within a regulatory domain >> - "secure" transmission of Regulatory ID and Device identification >> to DB >> Proposal below was primarily focused on the first requirement above. >> Your proposal for device certs is for the second. >> Both might be required ... device certs have other options also than >> manufacturer oriented certs and is a longer discussion. >> >> Paul >> >>> Because some manufacturers think its too much work to do that? >>> >>> Brian >>> >>> >>> >>> -----Original Message----- >>> From: Paul Lambert [mailto:paul@marvell.com] >>> Sent: Monday, September 10, 2012 03:15 PM Eastern Standard Time >>> To: Peter McCann; Peter Stanforth; Stephen Farrell; >>> Gabor.Bajko@nokia.com >>> Cc: paws@ietf.org >>> Subject: Re: [paws] PAWS security >>> >>> >>>> This restriction may hold today for the FCC, but I have a hard time >>>> believing that a pre-existing manufacturer-database relationship >>>> will be mandatory in every regulatory domain for the forseeable >>>> future. I think we should design to minimize the friction in >>>> changing database providers. >>> >>> The least friction would be to hardwire devices with a PK "root" for >>> each regulatory domain that the device supports. >>> >>> Valid DBs would have credentials signed by the key holder of roots >> for >>> each regulatory domain >>> >>> Paul >>> >>> >>>> -Pete >>>> >>>> Peter Stanforth wrote: >>>>> I completely agree with your statement below. If we are good any >>>> radio >>>>> will have the "Technical" capability to work with any database. >>>>> BUT, and this is a big BUT, the regulation may not allow it - The >>>>> FCC does not today. And as a DBA I only want to work with devices >>>>> where I have a predefined relationship. Not least of which, >>>>> because as I am authorized by a Regulator I want to make sure I >> am >>>>> doing everything I can to avoid their wrath. >>>>> This has come up before. PAWS is defining an API/Protocol, not >> the >>>>> regulation nor the business cases at this time. So I still say >>>>> that >>>> we >>>>> can comply with your statement without considering a "User". >>>>> >>>>> On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" >>>>> wrote: >>>>> >>>>>> This is a key question we need to answer. >>>>>> >>>>>> I thought we were defining a protocol that would allow a radio >>> from >>>>>> any manufacturer to interoperate with a database of any database >>>> vendor. >>>>>> >>>>>> -Pete >>>>>> >>>>>> Peter Stanforth wrote: >>>>>>> Pete, I am not sure I believe in a use case where "users" move >>>>>>> from one DB to another. The relationship is between the radio >>>>>>> vendor and the DBA. The radio vendor may have multiple >>>>>>> relationships and allow an end user to choose one, but it will >>> be >>>>>>> from the predefined >>>> list. >>>>>>> As a DBA I don't think I would want, and in the USA we are not >>>>>>> permitted, to establish a relationship with a user without a >>>>>>> preexisting relationship with the radio vendor. So security >>> should >>>>>>> be primarily a radio vendor-DBA issue. Wearing my DBA hat I >>>>>>> don't think I would want to service a radio that I do not have >> a >>>>>>> preexisting relationship with it's manufacturer. I am not sure >>>> that >>>>>>> user relationships are even within the scope of what PAWS >> should >>>>>>> be >>>> defining. Peter S. >>>>>>> >>>>>>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" >>>>>>> wrote: >>>>>>> >>>>>>>> Personally, I think that manually provisioned symmetric keys >>> will >>>>>>>> severely limit the ability for users to flexibly move from one >>>>>>>> database provider to another. It will require some secure >>>>>>>> out-of-band channel on which to transmit the secret key from >>>>>>>> one party to the other, and a mechanism for the user to push >>>>>>>> the >>>> secret >>>>>>>> key down into the master device. >>>>>>>> >>>>>>>> Provisioning of certificates does not require the secret >>> channel, >>>>>>>> only one that is integrity protected. I think this is much >>>>>>>> easier to achieve in practice. >>>>>>>> >>>>>>>> -Pete >>>>>>>> >>>>>>>> Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the >>>>>>>>> Vancouver F2F we had extensive discussions on the security >>> model >>>>>>>>> for PAWS. Draft-das proposes to use shared secrets pre- >>>> provisioned >>>>>>>>> in the master devices for authentication, while draft-lei >>>> proposes >>>>>>>>> to mandate client certificates into master devices. >>>>>>>>>> >>>>>>>>>> There seemed to be an understanding that the credential >> types >>>>>>>>>> in >>>>>>> use >>>>>>>>> for authentication are a matter of a business model chosen by >>>>>>>>> the provider which deploys white space devices, rather than a >>>> protocol >>>>>>>>> decision. >>>>>>>>>> >>>>>>>>>> Brian mentioned that the iesg may not allow a document to be >>>>>>>>> published which specifies how shared secrets are used, but >>>>>>>>> does not have a provisioning mechanism for the shared secrets >>> defined. >>>>>>>>> In my opinion, a mechanism for distributing shared secrets >>>>>>>>> does not necessarily have to be defined, as a shared secret >>>>>>>>> can be established using current practices to set up shared >>>>>>>>> secrets with financial institutions (using the browser). >>>>>>>>>> Thus, my suggestion would be to describe in the document how >>>>>>>>>> a shared >>>>>>>>> secret and how a client certificate is used to authenticate a >>>>>>>>> master device. Then, if we run into issues with iesg, in >> worst >>>>>>>>> case we could remove the shared secret part and keep the >> other >>>> one. >>>>>>>>>> >>>>>>>>>> I'd like to get additional views on this topic. >>>>>>>>> >>>>>>>>> I can help a little here (depending on your definition of >>>>>>>>> help:-) >>>>>>>>> >>>>>>>>> BCP 107 [1] is the one to look at when considering how to >>>> approach >>>>>>>>> automated key management requirements. That has an IMO very >>> good >>>>>>>>> abstract: >>>>>>>>> >>>>>>>>> The question often arises of whether a given security >> system >>>>>>>>> requires some form of automated key management, or whether >>>> manual >>>>>>>>> keying is sufficient. This memo provides guidelines for >>>> making >>>>>>>>> such decisions. When symmetric cryptographic mechanisms >> are >>>> used >>>>>>>>> in a protocol, the presumption is that automated key >>>> management >>>>>>>>> is generally but not always needed. If manual keying is >>>>>>>>> proposed, >>>>> the >>>>>>>>> burden of proving that automated key management is not >>>> required >>>>>>>>> falls to the >>>>>>> proposer. >>>>>>>>> For those that might be less familiar with IETF processes, >> the >>>>>>>>> fact that that's a BCP means that its entirely valid for an >> AD >>>>>>>>> to strenuously push back against a WG that wants to ignore >>>>>>>>> what it >>>> says. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> S. >>>>>>>>> >>>>>>>>> PS: I've not read the drafts, and couldn't make the session >> in >>>>>>>>> Vancouver, so this might be entirely off topic, but in the >>>>>>>>> case >>>> of >>>>>>>>> PAWS I'd also argue that the regulators' apparent desire to >>>>>>>>> force devices to authenticate is not necessarily the right >> one >>>>>>>>> for the IETF to force upon all users of the PAWS protocol. So >>>>>>>>> there could for example be a mode of operation where the DB >>>>>>>>> signs stuff but doesn't care who's asking and that'd be a far >>>>>>>>> far easier scenario in terms of automated key management. >>>>>>>>> >>>>>>>>> [1] http://tools.ietf.org/html/bcp107 >>>>>>>>> _______________________________________________ paws mailing >>>>>>>>> list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> paws@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Sep 10 13:55:42 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98E11E80D5 for ; Mon, 10 Sep 2012 13:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+2lIInN49Kg for ; Mon, 10 Sep 2012 13:55:41 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A2C9B11E808A for ; Mon, 10 Sep 2012 13:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347310316; x=1662669504; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=x+DkTCbV6WzEIZII7g8d1 ACjq5bHucAUOvjCTGgbn+k=; b=WHH+2kd29dZf7orBaU9UAftqqyJUFHQ9jqmAG jiGJCz9Nb6ZSo3CqHgch6xzrLyZbilGDaJfigjcyGuv0taHQA== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.10854825; Mon, 10 Sep 2012 16:51:54 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 10 Sep 2012 16:55:34 -0400 From: "Rosen, Brian" To: 'Stephen Farrell' , 'Paul Lambert' Date: Mon, 10 Sep 2012 16:55:34 -0400 Thread-Topic: [paws] PAWS security Thread-Index: Ac2PlXhd5h4Ume5uRNazDVOpMlNLZwAAScYE Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227D8@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: efawRlaGQdHiH+2wPUhEqw== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:55:42 -0000 SSB0aGluayB0aGUgbWF5IGlzIHRoYXQgbm90IGFsbCBkb21haW5zIG5lZWQgaXQuICBTbyB0aGUg cHJvdG9jb2wgaGFzIHRvIGRlZmluZSBob3cgdG8gZG8gaXQsIGJ1dCBpbXBsZW1lbnRhdGlvbnMg bWF5IG5vdCBuZWVkIGl0IGlmIHRoZXkgb25seSBhcmUgaW50ZW5kZWQgZm9yIGRlcGxveW1lbnQg aW4ganVyaXNkaWN0aW9ucyB0aGF0IGRvbid0IHJlcXVpcmUgaXQgQU5EIHRoZSBEQiBkb2Vzbid0 IG5lZWQgaXQgKHdoZXJlIHNlcnZpY2UgbWF5IG5vdCBkZXBlbmRlbnQgb24gc3VjaCBhdXRoZW50 aWNhdGlvbikuCgpCcmlhbgoKDQoNCiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog CVN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQpTZW50 OglNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiAwNDo0NyBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRp bWUNClRvOglQYXVsIExhbWJlcnQNCkNjOgkncGF3c0BpZXRmLm9yZycNClN1YmplY3Q6CVJlOiBb cGF3c10gUEFXUyBzZWN1cml0eQ0KDQoNCg0KT24gMDkvMTAvMjAxMiAwOTozMCBQTSwgUGF1bCBM YW1iZXJ0IHdyb3RlOg0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBSb3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0NCj4+IFNlbnQ6 IE1vbmRheSwgU2VwdGVtYmVyIDEwLCAyMDEyIDE6MTQgUE0NCj4gLi4uDQo+PiBJdCB3b3VsZCBi ZSBlYXN5IHRvIGRpc2NvdmVyIHRoZSBjZXJ0cyBvZiB0aGUgREJBcywgYmVjYXVzZSB0aGVyZSBh cmUNCj4+IGZldyBvZiB0aGVtLCBhbmQgY29udHJvbGxlZCBieSByZWd1bGF0b3JzLiAgRGlzY292 ZXJ5IG9mIHRoZSBzZXJ2ZXIgY2FuDQo+PiBpbmNsdWRlIGRpc2NvdmVyeSBvZiB0aGUgY2VydHMu ICBUaGUgb3RoZXIgd2F5IGlzIGhhcmRlciBmb3INCj4+IG1hbnVmYWN0dXJlcnMgYmVjYXVzZSBv ZiB0aGUgaXNzdWVzIHlvdSBjaXRlLCBidXQgb3ZlcmFsbCwgaXQncyBtdWNoDQo+PiBlYXNpZXIg dGhhbiBzaGFyZWQgc2VjcmV0cy4NCj4gU28sIHdlIG1heSBiZSBpbiBhZ3JlZW1lbnQgOi0pDQo+ IA0KPiBUaGUgREJzIGNhbiBiZSBkaXNjb3ZlcmVkLCBidXQgdGhleSBuZWVkIHNvbWUgY29tbW9u IHRydXN0IHBvaW50DQo+IGluIHRoZSBkZXZpY2VzIHBlciByZWd1bGF0b3J5IGF1dGhvcml0eS4N Cj4gDQo+Pg0KPj4gSXQgaXMgYSByZXF1aXJlbWVudCB0byBhdXRoZW50aWNhdGUgYm90aCBzaWRl cywgc28gd2UgbmVlZCBzb2x1dGlvbnMNCj4+IGZvciBib3RoLg0KPiBMb29raW5nIGF0IHRoZSBz ZWN1cml0eSBzdHVmZiBkb2N1bWVudGVkIGJ5IHRoaXMgZ3JvdXAsIHdlIGhhdmUNCj4gYXMgYSB0 aHJlYXQ6DQo+ICAgICAzLjIuMS4gIEltcGVyc29uYXRpb24gb2YgYSBtYXN0ZXIgZGV2aWNlDQoN CldoZXJlJ3MgdGhhdD8gSSBvbmx5IHNlZSBhICJNQVkiIGluIFsxXSBmb3IgY2xpZW50IGF1dGgN Cih3aGljaCBJIHRoaW5rIGlzIGNvcnJlY3QpLg0KDQpTLg0KDQpbMV0NCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMt MDgjc2VjdGlvbi04DQoNCj4gQSBsaXR0bGUgbGF0ZSBmb3IgbWUgdG8gYXJndWUgdGhpcyByZXF1 aXJlbWVudCwgc28geWVzIHdlDQo+IGhhdmUgY3JlYXRlZCBhIHJlcXVpcmVtZW50IGZvciBtYXN0 ZXIgZGV2aWNlIGF1dGhlbnRpY2F0aW9uLg0KPiBJIGRvbid0IHNlZSB3aHkgYSBSb2d1ZSBkZXZp Y2UgZXZlbiBjYXJlcyBhYm91dCB0aGUgREIuICBUaGUNCj4gZGV2aWNlcyBhcmUgImNlcnRpZmll ZCIgYXMgY29tcGxpYW50IHRvIHRoZSByZWd1bGF0b3J5IHJ1bGVzLg0KPiBFeHRyYSBjcnlwdG9n cmFwaHkgd2lsbCBub3QgcHJldmVudCBSb2d1ZSBkZXZpY2VzIGZyb20gc2ltcGx5DQo+IHRyYW5z bWl0dGluZyBpbiB3aGF0ZXZlciBjaGFubmVsIHRoZXkgd2FudC4gIA0KPiANCj4gR2l2ZW4gdGhp cyBjbGllbnQgYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQgLSBJIHRvdGFsbHkgYWdyZWUNCj4g dGhhdCBjbGllbnQgcHVibGljIGtleXMgYXJlIGEgbGl0dGxlIG1vcmUgd29yaywgYnV0IGFsd2F5 cyANCj4gYmV0dGVyIHRoYW4gZGlzdHJpYnV0aW5nIHNlY3JldCBrZXlzLg0KPiANCj4gUGF1bA0K PiANCj4+DQo+PiBCcmlhbg0KPj4NCj4+DQo+Pg0KPj4gIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+PiBGcm9tOiAJUGF1bCBMYW1iZXJ0IFttYWlsdG86cGF1bEBtYXJ2ZWxsLmNvbV0NCj4+ IFNlbnQ6CU1vbmRheSwgU2VwdGVtYmVyIDEwLCAyMDEyIDA0OjA0IFBNIEVhc3Rlcm4gU3RhbmRh cmQgVGltZQ0KPj4gVG86CVJvc2VuLCBCcmlhbjsgJ1BldGVyIE1jQ2Fubic7ICdQZXRlciBTdGFu Zm9ydGgnOyAnU3RlcGhlbg0KPj4gRmFycmVsbCc7ICdHYWJvci5CYWprb0Bub2tpYS5jb20nDQo+ PiBDYzoJJ3Bhd3NAaWV0Zi5vcmcnDQo+PiBTdWJqZWN0OglSRTogW3Bhd3NdIFBBV1Mgc2VjdXJp dHkNCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBSb3Nlbiwg QnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0NCj4+IC4uLg0KPj4+IFRoZSBl YXNpZXN0IHdheSB0byBkbyB0aGlzIGlzIHRvIGhhdmUgdGhlIG1hbnVmYWN0dXJlciBwdXQgYSBj ZXJ0IGluDQo+Pj4gdGhlIGRldmljZSB0aGF0IGl0IHNpZ25zLiAgVGhlbiB0aGUgb25seSB0aGlu ZyB0aGUgZGF0YWJhc2UgbmVlZHMgaXMNCj4+PiB0aGUgcHVibGljIGtleSBvZiB0aGUgbWFudWZh Y3R1cmVyLA0KPj4gWW91IGNhbm5vdCBwcmV2ZW50IHNwb29maW5nIG9mIGEgREIgd2l0aG91dCBo YXZpbmcgYSByb290IG9mIHNvbWUgc29ydA0KPj4gdGhhdCAiY2VydGlmaWVzIiByZWFsIGRiIHBy b3ZpZGVycy4gIFRoaXMgaXMgYSBzbWFsbCBudW1iZXIgb2YNCj4+IGNlcnRpZmljYXRlcyBpbnN0 YWxsZWQgaW4gdGhlIHNlcnZlcnMuDQo+Pg0KPj4gSGF2aW5nIGEgcGVyLWRldmljZSBjZXJ0IHNp Z25lZCBieSBhIG1hbnVmYWN0dXJlciBhbmQgaW5zdGFsbGVkIGluIHRoZQ0KPj4gZmFjdG9yeSBp cyBoYXJkZXIuICBJdCdzIG1vcmUgY2VydGlmaWNhdGVzIGFuZCBjb21wbGljYXRlcyB0aGUNCj4+ IG1hbnVmYWN0dXJpbmcgcHJvY2Vzcy4gIFRoZSBhdXRoZW50aWNhdGlvbiB0byBhIG1hbnVmYWN0 dXJlciBpcyBub3QNCj4+IG5lY2Vzc2FyaWx5IHVzZWZ1bC4gVGhlIGF1dGhlbnRpY2F0aW9uIG9m IHRoZSBtYW51ZmFjdHVyZXJzIEZDQyBJRCBhbmQNCj4+IGRldmljZSBJZCBtaWdodCBiZSBvZiBp bnRlcmVzdCwgYnV0IHRoZSByZWd1bGF0aW9ucyBkbyBub3QgbWFuZGF0ZQ0KPj4gKEFGQUlLKSB0 aGlzIGNvbXBsZXhpdHkgb2YgYXNzaWdubWVudCBvZiBhIGZldyBiaXRzIG9mIHBlciBkZXZpY2UN Cj4+IHJlZ3VsYXRvcnkgaW5mb3JtYXRpb24uDQo+Pg0KPj4+IFdoeSBkbyB3ZSB3YW50IHRvIG1h a2UgdGhpcyBoYXJkZXI/DQo+PiBUaGVyZSBhcmUgdHdvIHJlcXVpcmVtZW50czoNCj4+ICAtIGF1 dGhlbnRpY2F0aW9uIG9mIG11bHRpcGxlIERCIHByb3ZpZGVycyB3aXRoaW4gYSByZWd1bGF0b3J5 IGRvbWFpbg0KPj4gIC0gInNlY3VyZSIgdHJhbnNtaXNzaW9uIG9mIFJlZ3VsYXRvcnkgSUQgYW5k IERldmljZSBpZGVudGlmaWNhdGlvbg0KPj4gICAgIHRvIERCDQo+PiBQcm9wb3NhbCBiZWxvdyB3 YXMgcHJpbWFyaWx5IGZvY3VzZWQgb24gdGhlIGZpcnN0IHJlcXVpcmVtZW50IGFib3ZlLg0KPj4g WW91ciBwcm9wb3NhbCBmb3IgZGV2aWNlIGNlcnRzIGlzIGZvciB0aGUgc2Vjb25kLg0KPj4gQm90 aCBtaWdodCBiZSByZXF1aXJlZCAuLi4gZGV2aWNlIGNlcnRzIGhhdmUgb3RoZXIgb3B0aW9ucyBh bHNvIHRoYW4NCj4+IG1hbnVmYWN0dXJlciBvcmllbnRlZCBjZXJ0cyBhbmQgaXMgYSBsb25nZXIg ZGlzY3Vzc2lvbi4NCj4+DQo+PiBQYXVsDQo+Pg0KPj4+IEJlY2F1c2Ugc29tZSBtYW51ZmFjdHVy ZXJzIHRoaW5rIGl0cyB0b28gbXVjaCB3b3JrIHRvIGRvIHRoYXQ/DQo+Pj4NCj4+PiBCcmlhbg0K Pj4+DQo+Pj4NCj4+Pg0KPj4+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206 IAlQYXVsIExhbWJlcnQgW21haWx0bzpwYXVsQG1hcnZlbGwuY29tXQ0KPj4+IFNlbnQ6CU1vbmRh eSwgU2VwdGVtYmVyIDEwLCAyMDEyIDAzOjE1IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KPj4+ IFRvOglQZXRlciBNY0Nhbm47IFBldGVyIFN0YW5mb3J0aDsgU3RlcGhlbiBGYXJyZWxsOw0KPj4+ IEdhYm9yLkJhamtvQG5va2lhLmNvbQ0KPj4+IENjOglwYXdzQGlldGYub3JnDQo+Pj4gU3ViamVj dDoJUmU6IFtwYXdzXSBQQVdTIHNlY3VyaXR5DQo+Pj4NCj4+Pg0KPj4+PiBUaGlzIHJlc3RyaWN0 aW9uIG1heSBob2xkIHRvZGF5IGZvciB0aGUgRkNDLCBidXQgSSBoYXZlIGEgaGFyZCB0aW1lDQo+ Pj4+IGJlbGlldmluZyB0aGF0IGEgcHJlLWV4aXN0aW5nIG1hbnVmYWN0dXJlci1kYXRhYmFzZSBy ZWxhdGlvbnNoaXANCj4+Pj4gd2lsbCBiZSBtYW5kYXRvcnkgaW4gZXZlcnkgcmVndWxhdG9yeSBk b21haW4gZm9yIHRoZSBmb3JzZWVhYmxlDQo+Pj4+IGZ1dHVyZS4gIEkgdGhpbmsgd2Ugc2hvdWxk IGRlc2lnbiB0byBtaW5pbWl6ZSB0aGUgZnJpY3Rpb24gaW4NCj4+Pj4gY2hhbmdpbmcgZGF0YWJh c2UgcHJvdmlkZXJzLg0KPj4+DQo+Pj4gVGhlIGxlYXN0IGZyaWN0aW9uIHdvdWxkIGJlIHRvIGhh cmR3aXJlIGRldmljZXMgd2l0aCBhIFBLICJyb290IiBmb3INCj4+PiBlYWNoIHJlZ3VsYXRvcnkg ZG9tYWluIHRoYXQgdGhlIGRldmljZSBzdXBwb3J0cy4NCj4+Pg0KPj4+IFZhbGlkIERCcyB3b3Vs ZCBoYXZlIGNyZWRlbnRpYWxzIHNpZ25lZCBieSB0aGUga2V5IGhvbGRlciBvZiByb290cw0KPj4g Zm9yDQo+Pj4gZWFjaCByZWd1bGF0b3J5IGRvbWFpbg0KPj4+DQo+Pj4gUGF1bA0KPj4+DQo+Pj4N Cj4+Pj4gLVBldGUNCj4+Pj4NCj4+Pj4gUGV0ZXIgU3RhbmZvcnRoIHdyb3RlOg0KPj4+Pj4gSSBj b21wbGV0ZWx5IGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQgYmVsb3cuIElmIHdlIGFyZSBnb29k IGFueQ0KPj4+PiByYWRpbw0KPj4+Pj4gd2lsbCBoYXZlIHRoZSAiVGVjaG5pY2FsIiBjYXBhYmls aXR5IHRvIHdvcmsgd2l0aCBhbnkgZGF0YWJhc2UuDQo+Pj4+PiBCVVQsIGFuZCB0aGlzIGlzIGEg YmlnIEJVVCwgdGhlIHJlZ3VsYXRpb24gbWF5IG5vdCBhbGxvdyBpdCAtIFRoZQ0KPj4+Pj4gRkND IGRvZXMgbm90IHRvZGF5LiBBbmQgYXMgYSBEQkEgSSBvbmx5IHdhbnQgdG8gd29yayB3aXRoIGRl dmljZXMNCj4+Pj4+IHdoZXJlIEkgaGF2ZSBhIHByZWRlZmluZWQgcmVsYXRpb25zaGlwLiBOb3Qg bGVhc3Qgb2Ygd2hpY2gsDQo+Pj4+PiBiZWNhdXNlIGFzIEkgYW0gYXV0aG9yaXplZCBieSBhIFJl Z3VsYXRvciBJIHdhbnQgdG8gbWFrZSBzdXJlIEkNCj4+IGFtDQo+Pj4+PiBkb2luZyBldmVyeXRo aW5nIEkgY2FuIHRvIGF2b2lkIHRoZWlyIHdyYXRoLg0KPj4+Pj4gVGhpcyBoYXMgY29tZSB1cCBi ZWZvcmUuIFBBV1MgaXMgZGVmaW5pbmcgYW4gQVBJL1Byb3RvY29sLCBub3QNCj4+IHRoZQ0KPj4+ Pj4gcmVndWxhdGlvbiBub3IgdGhlIGJ1c2luZXNzIGNhc2VzIGF0IHRoaXMgdGltZS4gU28gSSBz dGlsbCBzYXkNCj4+Pj4+IHRoYXQNCj4+Pj4gd2UNCj4+Pj4+IGNhbiBjb21wbHkgd2l0aCB5b3Vy IHN0YXRlbWVudCB3aXRob3V0IGNvbnNpZGVyaW5nIGEgIlVzZXIiLg0KPj4+Pj4NCj4+Pj4+IE9u IE1vblNlcC8xMC8xMiBNb24gU2VwIDEwLCAyOjE4IFBNLCAiUGV0ZXIgTWNDYW5uIg0KPj4+Pj4g PFBldGVyLk1jQ2FubkBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj4gVGhpcyBpcyBh IGtleSBxdWVzdGlvbiB3ZSBuZWVkIHRvIGFuc3dlci4NCj4+Pj4+Pg0KPj4+Pj4+IEkgdGhvdWdo dCB3ZSB3ZXJlIGRlZmluaW5nIGEgcHJvdG9jb2wgdGhhdCB3b3VsZCBhbGxvdyBhIHJhZGlvDQo+ Pj4gZnJvbQ0KPj4+Pj4+IGFueSBtYW51ZmFjdHVyZXIgdG8gaW50ZXJvcGVyYXRlIHdpdGggYSBk YXRhYmFzZSBvZiBhbnkgZGF0YWJhc2UNCj4+Pj4gdmVuZG9yLg0KPj4+Pj4+DQo+Pj4+Pj4gLVBl dGUNCj4+Pj4+Pg0KPj4+Pj4+IFBldGVyIFN0YW5mb3J0aCB3cm90ZToNCj4+Pj4+Pj4gUGV0ZSwg SSBhbSBub3Qgc3VyZSBJIGJlbGlldmUgaW4gYSB1c2UgY2FzZSB3aGVyZSAidXNlcnMiIG1vdmUN Cj4+Pj4+Pj4gZnJvbSBvbmUgREIgdG8gYW5vdGhlci4gVGhlIHJlbGF0aW9uc2hpcCBpcyBiZXR3 ZWVuIHRoZSByYWRpbw0KPj4+Pj4+PiB2ZW5kb3IgYW5kIHRoZSBEQkEuIFRoZSByYWRpbyB2ZW5k b3IgbWF5IGhhdmUgbXVsdGlwbGUNCj4+Pj4+Pj4gcmVsYXRpb25zaGlwcyBhbmQgYWxsb3cgYW4g ZW5kIHVzZXIgIHRvIGNob29zZSBvbmUsIGJ1dCBpdCB3aWxsDQo+Pj4gYmUNCj4+Pj4+Pj4gZnJv bSB0aGUgcHJlZGVmaW5lZA0KPj4+PiBsaXN0Lg0KPj4+Pj4+PiBBcyBhIERCQSBJICBkb24ndCB0 aGluayBJIHdvdWxkIHdhbnQsIGFuZCBpbiB0aGUgVVNBIHdlIGFyZSBub3QNCj4+Pj4+Pj4gcGVy bWl0dGVkLCB0byBlc3RhYmxpc2ggYSByZWxhdGlvbnNoaXAgd2l0aCBhIHVzZXIgd2l0aG91dCBh DQo+Pj4+Pj4+IHByZWV4aXN0aW5nIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSByYWRpbyB2ZW5kb3Iu IFNvIHNlY3VyaXR5DQo+Pj4gc2hvdWxkDQo+Pj4+Pj4+IGJlIHByaW1hcmlseSBhIHJhZGlvIHZl bmRvci1EQkEgaXNzdWUuIFdlYXJpbmcgbXkgREJBIGhhdCBJDQo+Pj4+Pj4+IGRvbid0IHRoaW5r IEkgd291bGQgd2FudCB0byBzZXJ2aWNlIGEgcmFkaW8gdGhhdCBJIGRvIG5vdCBoYXZlDQo+PiBh DQo+Pj4+Pj4+IHByZWV4aXN0aW5nIHJlbGF0aW9uc2hpcCB3aXRoIGl0J3MgbWFudWZhY3R1cmVy LiAgSSBhbSBub3Qgc3VyZQ0KPj4+PiB0aGF0DQo+Pj4+Pj4+IHVzZXIgcmVsYXRpb25zaGlwcyBh cmUgZXZlbiB3aXRoaW4gdGhlIHNjb3BlIG9mIHdoYXQgUEFXUw0KPj4gc2hvdWxkDQo+Pj4+Pj4+ IGJlDQo+Pj4+IGRlZmluaW5nLiBQZXRlciBTLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiBNb25TZXAv MTAvMTIgTW9uIFNlcCAxMCwgMTo1OCBQTSwgIlBldGVyIE1jQ2FubiINCj4+Pj4+Pj4gPFBldGVy Lk1jQ2FubkBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4+IFBlcnNvbmFsbHks IEkgdGhpbmsgdGhhdCBtYW51YWxseSBwcm92aXNpb25lZCBzeW1tZXRyaWMga2V5cw0KPj4+IHdp bGwNCj4+Pj4+Pj4+IHNldmVyZWx5IGxpbWl0IHRoZSBhYmlsaXR5IGZvciB1c2VycyB0byBmbGV4 aWJseSBtb3ZlIGZyb20gb25lDQo+Pj4+Pj4+PiBkYXRhYmFzZSBwcm92aWRlciB0byBhbm90aGVy LiAgSXQgd2lsbCByZXF1aXJlIHNvbWUgc2VjdXJlDQo+Pj4+Pj4+PiBvdXQtb2YtYmFuZCBjaGFu bmVsIG9uIHdoaWNoIHRvIHRyYW5zbWl0IHRoZSBzZWNyZXQga2V5IGZyb20NCj4+Pj4+Pj4+IG9u ZSBwYXJ0eSB0byB0aGUgb3RoZXIsIGFuZCBhIG1lY2hhbmlzbSBmb3IgdGhlIHVzZXIgdG8gcHVz aA0KPj4+Pj4+Pj4gdGhlDQo+Pj4+IHNlY3JldA0KPj4+Pj4+Pj4ga2V5IGRvd24gaW50byB0aGUg bWFzdGVyIGRldmljZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQcm92aXNpb25pbmcgb2YgY2VydGlm aWNhdGVzIGRvZXMgbm90IHJlcXVpcmUgdGhlIHNlY3JldA0KPj4+IGNoYW5uZWwsDQo+Pj4+Pj4+ PiBvbmx5IG9uZSB0aGF0IGlzIGludGVncml0eSBwcm90ZWN0ZWQuICBJIHRoaW5rIHRoaXMgaXMg bXVjaA0KPj4+Pj4+Pj4gZWFzaWVyIHRvIGFjaGlldmUgaW4gcHJhY3RpY2UuDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gLVBldGUNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBTdGVwaGVuIEZhcnJlbGwgd3JvdGU6 DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IE9uIDA5LzA3LzIwMTIgMTA6MDEgUE0s IEdhYm9yLkJhamtvQG5va2lhLmNvbSB3cm90ZTo+IEF0IHRoZQ0KPj4+Pj4+Pj4+IFZhbmNvdXZl ciBGMkYgd2UgaGFkIGV4dGVuc2l2ZSBkaXNjdXNzaW9ucyBvbiB0aGUgc2VjdXJpdHkNCj4+PiBt b2RlbA0KPj4+Pj4+Pj4+IGZvciBQQVdTLiBEcmFmdC1kYXMgcHJvcG9zZXMgdG8gdXNlIHNoYXJl ZCBzZWNyZXRzIHByZS0NCj4+Pj4gcHJvdmlzaW9uZWQNCj4+Pj4+Pj4+PiBpbiB0aGUgbWFzdGVy IGRldmljZXMgZm9yIGF1dGhlbnRpY2F0aW9uLCB3aGlsZSBkcmFmdC1sZWkNCj4+Pj4gcHJvcG9z ZXMNCj4+Pj4+Pj4+PiB0byBtYW5kYXRlIGNsaWVudCBjZXJ0aWZpY2F0ZXMgaW50byBtYXN0ZXIg ZGV2aWNlcy4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVGhlcmUgc2VlbWVkIHRvIGJlIGFuIHVu ZGVyc3RhbmRpbmcgdGhhdCB0aGUgY3JlZGVudGlhbA0KPj4gdHlwZXMNCj4+Pj4+Pj4+Pj4gaW4N Cj4+Pj4+Pj4gdXNlDQo+Pj4+Pj4+Pj4gZm9yIGF1dGhlbnRpY2F0aW9uIGFyZSBhIG1hdHRlciBv ZiBhIGJ1c2luZXNzIG1vZGVsIGNob3NlbiBieQ0KPj4+Pj4+Pj4+IHRoZSBwcm92aWRlciB3aGlj aCBkZXBsb3lzIHdoaXRlIHNwYWNlIGRldmljZXMsIHJhdGhlciB0aGFuIGENCj4+Pj4gcHJvdG9j b2wNCj4+Pj4+Pj4+PiBkZWNpc2lvbi4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQnJpYW4gbWVu dGlvbmVkIHRoYXQgdGhlIGllc2cgbWF5IG5vdCBhbGxvdyBhIGRvY3VtZW50IHRvIGJlDQo+Pj4+ Pj4+Pj4gcHVibGlzaGVkIHdoaWNoIHNwZWNpZmllcyBob3cgc2hhcmVkIHNlY3JldHMgYXJlIHVz ZWQsIGJ1dA0KPj4+Pj4+Pj4+IGRvZXMgbm90IGhhdmUgYSBwcm92aXNpb25pbmcgbWVjaGFuaXNt IGZvciB0aGUgc2hhcmVkIHNlY3JldHMNCj4+PiBkZWZpbmVkLg0KPj4+Pj4+Pj4+IEluIG15IG9w aW5pb24sIGEgbWVjaGFuaXNtIGZvciBkaXN0cmlidXRpbmcgc2hhcmVkIHNlY3JldHMNCj4+Pj4+ Pj4+PiBkb2VzIG5vdCBuZWNlc3NhcmlseSBoYXZlIHRvIGJlIGRlZmluZWQsIGFzIGEgc2hhcmVk IHNlY3JldA0KPj4+Pj4+Pj4+IGNhbiBiZSBlc3RhYmxpc2hlZCB1c2luZyBjdXJyZW50IHByYWN0 aWNlcyB0byBzZXQgdXAgc2hhcmVkDQo+Pj4+Pj4+Pj4gc2VjcmV0cyB3aXRoIGZpbmFuY2lhbCBp bnN0aXR1dGlvbnMgKHVzaW5nIHRoZSBicm93c2VyKS4NCj4+Pj4+Pj4+Pj4gVGh1cywgbXkgc3Vn Z2VzdGlvbiB3b3VsZCBiZSB0byBkZXNjcmliZSBpbiB0aGUgZG9jdW1lbnQgaG93DQo+Pj4+Pj4+ Pj4+IGEgc2hhcmVkDQo+Pj4+Pj4+Pj4gc2VjcmV0IGFuZCBob3cgYSBjbGllbnQgY2VydGlmaWNh dGUgaXMgdXNlZCB0byBhdXRoZW50aWNhdGUgYQ0KPj4+Pj4+Pj4+IG1hc3RlciBkZXZpY2UuIFRo ZW4sIGlmIHdlIHJ1biBpbnRvIGlzc3VlcyB3aXRoIGllc2csIGluDQo+PiB3b3JzdA0KPj4+Pj4+ Pj4+IGNhc2Ugd2UgY291bGQgcmVtb3ZlIHRoZSBzaGFyZWQgc2VjcmV0IHBhcnQgYW5kIGtlZXAg dGhlDQo+PiBvdGhlcg0KPj4+PiBvbmUuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEknZCBsaWtl IHRvIGdldCBhZGRpdGlvbmFsIHZpZXdzIG9uIHRoaXMgdG9waWMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiBJIGNhbiBoZWxwIGEgbGl0dGxlIGhlcmUgKGRlcGVuZGluZyBvbiB5b3VyIGRlZmluaXRp b24gb2YNCj4+Pj4+Pj4+PiBoZWxwOi0pDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBCQ1AgMTA3IFsx XSBpcyB0aGUgb25lIHRvIGxvb2sgYXQgd2hlbiBjb25zaWRlcmluZyBob3cgdG8NCj4+Pj4gYXBw cm9hY2gNCj4+Pj4+Pj4+PiBhdXRvbWF0ZWQga2V5IG1hbmFnZW1lbnQgcmVxdWlyZW1lbnRzLiBU aGF0IGhhcyBhbiBJTU8gdmVyeQ0KPj4+IGdvb2QNCj4+Pj4+Pj4+PiBhYnN0cmFjdDoNCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+ICAgIFRoZSBxdWVzdGlvbiBvZnRlbiBhcmlzZXMgb2Ygd2hldGhlciBh IGdpdmVuIHNlY3VyaXR5DQo+PiBzeXN0ZW0NCj4+Pj4+Pj4+PiAgICByZXF1aXJlcyBzb21lIGZv cm0gb2YgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50LCBvciB3aGV0aGVyDQo+Pj4+IG1hbnVhbA0K Pj4+Pj4+Pj4+ICAgIGtleWluZyBpcyBzdWZmaWNpZW50LiAgVGhpcyBtZW1vIHByb3ZpZGVzIGd1 aWRlbGluZXMgZm9yDQo+Pj4+IG1ha2luZw0KPj4+Pj4+Pj4+ICAgIHN1Y2ggZGVjaXNpb25zLiBX aGVuIHN5bW1ldHJpYyBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMNCj4+IGFyZQ0KPj4+PiB1c2Vk DQo+Pj4+Pj4+Pj4gICAgaW4gYSBwcm90b2NvbCwgdGhlIHByZXN1bXB0aW9uIGlzIHRoYXQgYXV0 b21hdGVkIGtleQ0KPj4+PiBtYW5hZ2VtZW50DQo+Pj4+Pj4+Pj4gICAgaXMgZ2VuZXJhbGx5IGJ1 dCBub3QgYWx3YXlzIG5lZWRlZC4gIElmIG1hbnVhbCBrZXlpbmcgaXMNCj4+Pj4+Pj4+PiBwcm9w b3NlZCwNCj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+ICAgIGJ1cmRlbiBvZiBwcm92aW5nIHRoYXQgYXV0 b21hdGVkIGtleSBtYW5hZ2VtZW50IGlzIG5vdA0KPj4+PiByZXF1aXJlZA0KPj4+Pj4+Pj4+ICAg IGZhbGxzIHRvIHRoZQ0KPj4+Pj4+PiBwcm9wb3Nlci4NCj4+Pj4+Pj4+PiBGb3IgdGhvc2UgdGhh dCBtaWdodCBiZSBsZXNzIGZhbWlsaWFyIHdpdGggSUVURiBwcm9jZXNzZXMsDQo+PiB0aGUNCj4+ Pj4+Pj4+PiBmYWN0IHRoYXQgdGhhdCdzIGEgQkNQIG1lYW5zIHRoYXQgaXRzIGVudGlyZWx5IHZh bGlkIGZvciBhbg0KPj4gQUQNCj4+Pj4+Pj4+PiB0byBzdHJlbnVvdXNseSBwdXNoIGJhY2sgYWdh aW5zdCBhIFdHIHRoYXQgd2FudHMgdG8gaWdub3JlDQo+Pj4+Pj4+Pj4gd2hhdCBpdA0KPj4+PiBz YXlzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+IFMuDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBQUzogSSd2ZSBub3QgcmVhZCB0aGUgZHJhZnRzLCBhbmQgY291bGRuJ3Qg bWFrZSB0aGUgc2Vzc2lvbg0KPj4gaW4NCj4+Pj4+Pj4+PiBWYW5jb3V2ZXIsIHNvIHRoaXMgbWln aHQgYmUgZW50aXJlbHkgb2ZmIHRvcGljLCBidXQgaW4gdGhlDQo+Pj4+Pj4+Pj4gY2FzZQ0KPj4+ PiBvZg0KPj4+Pj4+Pj4+IFBBV1MgSSdkIGFsc28gYXJndWUgdGhhdCB0aGUgcmVndWxhdG9ycycg YXBwYXJlbnQgZGVzaXJlIHRvDQo+Pj4+Pj4+Pj4gZm9yY2UgZGV2aWNlcyB0byBhdXRoZW50aWNh dGUgaXMgbm90IG5lY2Vzc2FyaWx5IHRoZSByaWdodA0KPj4gb25lDQo+Pj4+Pj4+Pj4gZm9yIHRo ZSBJRVRGIHRvIGZvcmNlIHVwb24gYWxsIHVzZXJzIG9mIHRoZSBQQVdTIHByb3RvY29sLiBTbw0K Pj4+Pj4+Pj4+IHRoZXJlIGNvdWxkIGZvciBleGFtcGxlIGJlIGEgbW9kZSBvZiBvcGVyYXRpb24g d2hlcmUgdGhlIERCDQo+Pj4+Pj4+Pj4gc2lnbnMgc3R1ZmYgYnV0IGRvZXNuJ3QgY2FyZSB3aG8n cyBhc2tpbmcgYW5kIHRoYXQnZCBiZSBhIGZhcg0KPj4+Pj4+Pj4+IGZhciBlYXNpZXIgc2NlbmFy aW8gaW4gdGVybXMgb2YgYXV0b21hdGVkIGtleSBtYW5hZ2VtZW50Lg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4gWzFdIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2JjcDEwNw0KPj4+Pj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHBhd3MgbWFpbGlu Zw0KPj4+Pj4+Pj4+IGxpc3QgcGF3c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+ PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+Pj4+IHBhd3NA aWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdz DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+IHBhd3NAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From stephen.farrell@cs.tcd.ie Mon Sep 10 14:12:54 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76011E80E5 for ; Mon, 10 Sep 2012 14:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.668 X-Spam-Level: X-Spam-Status: No, score=-102.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfSHS5sDxVgR for ; Mon, 10 Sep 2012 14:12:53 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D841421F8505 for ; Mon, 10 Sep 2012 14:12:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4B584171474; Mon, 10 Sep 2012 22:12:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347311571; bh=pvlK/IqJaKMBrJ PdP/n8WmrY9Mywt+GJ/8+/zg/6jEQ=; b=XU7FJXboXRQR3z9jSxQuI0k8sr13xi ikDVQK+tEvX7bxzw3z8knAPZu59+weQclkIlNyG3q6wTl6QcfPGL8U4HvtDGTTum naZUa+61Ju/PKlcR5eX4Kt+aQQIdytsabFJ4ofyS1husMzMlCfNMYgKg29jXwWUc 6URzak0RQp/WgssOpklIA4bBC5nmfH29drjPVrt9PcK43zNdMttDg25G6GRn61ZH yAHoEQao0CNHYHuSASJu7rGbu5Ms3559OVNHMYSr0IpFNUypliTOnb+fJB34eAlD mdcV6F2XWXGz37Z5ulSLD/Jpcma0TeDVsvhz1764RmDTztMdH3u7n2eg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ETaPqg5BrsAk; Mon, 10 Sep 2012 22:12:51 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.29.198]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D7C15171473; Mon, 10 Sep 2012 22:12:50 +0100 (IST) Message-ID: <504E57D2.20107@cs.tcd.ie> Date: Mon, 10 Sep 2012 22:12:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Rosen, Brian" References: <55A5A9A87506CB4BA580BF9D531957DA690227D8@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227D8@STNTEXCH01.cis.neustar.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 21:12:54 -0000 On 09/10/2012 09:55 PM, Rosen, Brian wrote: > I think the may is that not all domains need it. So the protocol has to define how to do it, but implementations may not need it if they only are intended for deployment in jurisdictions that don't require it AND the DB doesn't need it (where service may not dependent on such authentication). That was my understanding all right. S > Brian > > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, September 10, 2012 04:47 PM Eastern Standard Time > To: Paul Lambert > Cc: 'paws@ietf.org' > Subject: Re: [paws] PAWS security > > > > On 09/10/2012 09:30 PM, Paul Lambert wrote: >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Monday, September 10, 2012 1:14 PM >> ... >>> It would be easy to discover the certs of the DBAs, because there are >>> few of them, and controlled by regulators. Discovery of the server can >>> include discovery of the certs. The other way is harder for >>> manufacturers because of the issues you cite, but overall, it's much >>> easier than shared secrets. >> So, we may be in agreement :-) >> >> The DBs can be discovered, but they need some common trust point >> in the devices per regulatory authority. >> >>> >>> It is a requirement to authenticate both sides, so we need solutions >>> for both. >> Looking at the security stuff documented by this group, we have >> as a threat: >> 3.2.1. Impersonation of a master device > > Where's that? I only see a "MAY" in [1] for client auth > (which I think is correct). > > S. > > [1] > http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-08#section-8 > >> A little late for me to argue this requirement, so yes we >> have created a requirement for master device authentication. >> I don't see why a Rogue device even cares about the DB. The >> devices are "certified" as compliant to the regulatory rules. >> Extra cryptography will not prevent Rogue devices from simply >> transmitting in whatever channel they want. >> >> Given this client authentication requirement - I totally agree >> that client public keys are a little more work, but always >> better than distributing secret keys. >> >> Paul >> >>> >>> Brian >>> >>> >>> >>> -----Original Message----- >>> From: Paul Lambert [mailto:paul@marvell.com] >>> Sent: Monday, September 10, 2012 04:04 PM Eastern Standard Time >>> To: Rosen, Brian; 'Peter McCann'; 'Peter Stanforth'; 'Stephen >>> Farrell'; 'Gabor.Bajko@nokia.com' >>> Cc: 'paws@ietf.org' >>> Subject: RE: [paws] PAWS security >>> >>>> -----Original Message----- >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> ... >>>> The easiest way to do this is to have the manufacturer put a cert in >>>> the device that it signs. Then the only thing the database needs is >>>> the public key of the manufacturer, >>> You cannot prevent spoofing of a DB without having a root of some sort >>> that "certifies" real db providers. This is a small number of >>> certificates installed in the servers. >>> >>> Having a per-device cert signed by a manufacturer and installed in the >>> factory is harder. It's more certificates and complicates the >>> manufacturing process. The authentication to a manufacturer is not >>> necessarily useful. The authentication of the manufacturers FCC ID and >>> device Id might be of interest, but the regulations do not mandate >>> (AFAIK) this complexity of assignment of a few bits of per device >>> regulatory information. >>> >>>> Why do we want to make this harder? >>> There are two requirements: >>> - authentication of multiple DB providers within a regulatory domain >>> - "secure" transmission of Regulatory ID and Device identification >>> to DB >>> Proposal below was primarily focused on the first requirement above. >>> Your proposal for device certs is for the second. >>> Both might be required ... device certs have other options also than >>> manufacturer oriented certs and is a longer discussion. >>> >>> Paul >>> >>>> Because some manufacturers think its too much work to do that? >>>> >>>> Brian >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Paul Lambert [mailto:paul@marvell.com] >>>> Sent: Monday, September 10, 2012 03:15 PM Eastern Standard Time >>>> To: Peter McCann; Peter Stanforth; Stephen Farrell; >>>> Gabor.Bajko@nokia.com >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] PAWS security >>>> >>>> >>>>> This restriction may hold today for the FCC, but I have a hard time >>>>> believing that a pre-existing manufacturer-database relationship >>>>> will be mandatory in every regulatory domain for the forseeable >>>>> future. I think we should design to minimize the friction in >>>>> changing database providers. >>>> >>>> The least friction would be to hardwire devices with a PK "root" for >>>> each regulatory domain that the device supports. >>>> >>>> Valid DBs would have credentials signed by the key holder of roots >>> for >>>> each regulatory domain >>>> >>>> Paul >>>> >>>> >>>>> -Pete >>>>> >>>>> Peter Stanforth wrote: >>>>>> I completely agree with your statement below. If we are good any >>>>> radio >>>>>> will have the "Technical" capability to work with any database. >>>>>> BUT, and this is a big BUT, the regulation may not allow it - The >>>>>> FCC does not today. And as a DBA I only want to work with devices >>>>>> where I have a predefined relationship. Not least of which, >>>>>> because as I am authorized by a Regulator I want to make sure I >>> am >>>>>> doing everything I can to avoid their wrath. >>>>>> This has come up before. PAWS is defining an API/Protocol, not >>> the >>>>>> regulation nor the business cases at this time. So I still say >>>>>> that >>>>> we >>>>>> can comply with your statement without considering a "User". >>>>>> >>>>>> On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" >>>>>> wrote: >>>>>> >>>>>>> This is a key question we need to answer. >>>>>>> >>>>>>> I thought we were defining a protocol that would allow a radio >>>> from >>>>>>> any manufacturer to interoperate with a database of any database >>>>> vendor. >>>>>>> >>>>>>> -Pete >>>>>>> >>>>>>> Peter Stanforth wrote: >>>>>>>> Pete, I am not sure I believe in a use case where "users" move >>>>>>>> from one DB to another. The relationship is between the radio >>>>>>>> vendor and the DBA. The radio vendor may have multiple >>>>>>>> relationships and allow an end user to choose one, but it will >>>> be >>>>>>>> from the predefined >>>>> list. >>>>>>>> As a DBA I don't think I would want, and in the USA we are not >>>>>>>> permitted, to establish a relationship with a user without a >>>>>>>> preexisting relationship with the radio vendor. So security >>>> should >>>>>>>> be primarily a radio vendor-DBA issue. Wearing my DBA hat I >>>>>>>> don't think I would want to service a radio that I do not have >>> a >>>>>>>> preexisting relationship with it's manufacturer. I am not sure >>>>> that >>>>>>>> user relationships are even within the scope of what PAWS >>> should >>>>>>>> be >>>>> defining. Peter S. >>>>>>>> >>>>>>>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Personally, I think that manually provisioned symmetric keys >>>> will >>>>>>>>> severely limit the ability for users to flexibly move from one >>>>>>>>> database provider to another. It will require some secure >>>>>>>>> out-of-band channel on which to transmit the secret key from >>>>>>>>> one party to the other, and a mechanism for the user to push >>>>>>>>> the >>>>> secret >>>>>>>>> key down into the master device. >>>>>>>>> >>>>>>>>> Provisioning of certificates does not require the secret >>>> channel, >>>>>>>>> only one that is integrity protected. I think this is much >>>>>>>>> easier to achieve in practice. >>>>>>>>> >>>>>>>>> -Pete >>>>>>>>> >>>>>>>>> Stephen Farrell wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the >>>>>>>>>> Vancouver F2F we had extensive discussions on the security >>>> model >>>>>>>>>> for PAWS. Draft-das proposes to use shared secrets pre- >>>>> provisioned >>>>>>>>>> in the master devices for authentication, while draft-lei >>>>> proposes >>>>>>>>>> to mandate client certificates into master devices. >>>>>>>>>>> >>>>>>>>>>> There seemed to be an understanding that the credential >>> types >>>>>>>>>>> in >>>>>>>> use >>>>>>>>>> for authentication are a matter of a business model chosen by >>>>>>>>>> the provider which deploys white space devices, rather than a >>>>> protocol >>>>>>>>>> decision. >>>>>>>>>>> >>>>>>>>>>> Brian mentioned that the iesg may not allow a document to be >>>>>>>>>> published which specifies how shared secrets are used, but >>>>>>>>>> does not have a provisioning mechanism for the shared secrets >>>> defined. >>>>>>>>>> In my opinion, a mechanism for distributing shared secrets >>>>>>>>>> does not necessarily have to be defined, as a shared secret >>>>>>>>>> can be established using current practices to set up shared >>>>>>>>>> secrets with financial institutions (using the browser). >>>>>>>>>>> Thus, my suggestion would be to describe in the document how >>>>>>>>>>> a shared >>>>>>>>>> secret and how a client certificate is used to authenticate a >>>>>>>>>> master device. Then, if we run into issues with iesg, in >>> worst >>>>>>>>>> case we could remove the shared secret part and keep the >>> other >>>>> one. >>>>>>>>>>> >>>>>>>>>>> I'd like to get additional views on this topic. >>>>>>>>>> >>>>>>>>>> I can help a little here (depending on your definition of >>>>>>>>>> help:-) >>>>>>>>>> >>>>>>>>>> BCP 107 [1] is the one to look at when considering how to >>>>> approach >>>>>>>>>> automated key management requirements. That has an IMO very >>>> good >>>>>>>>>> abstract: >>>>>>>>>> >>>>>>>>>> The question often arises of whether a given security >>> system >>>>>>>>>> requires some form of automated key management, or whether >>>>> manual >>>>>>>>>> keying is sufficient. This memo provides guidelines for >>>>> making >>>>>>>>>> such decisions. When symmetric cryptographic mechanisms >>> are >>>>> used >>>>>>>>>> in a protocol, the presumption is that automated key >>>>> management >>>>>>>>>> is generally but not always needed. If manual keying is >>>>>>>>>> proposed, >>>>>> the >>>>>>>>>> burden of proving that automated key management is not >>>>> required >>>>>>>>>> falls to the >>>>>>>> proposer. >>>>>>>>>> For those that might be less familiar with IETF processes, >>> the >>>>>>>>>> fact that that's a BCP means that its entirely valid for an >>> AD >>>>>>>>>> to strenuously push back against a WG that wants to ignore >>>>>>>>>> what it >>>>> says. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> S. >>>>>>>>>> >>>>>>>>>> PS: I've not read the drafts, and couldn't make the session >>> in >>>>>>>>>> Vancouver, so this might be entirely off topic, but in the >>>>>>>>>> case >>>>> of >>>>>>>>>> PAWS I'd also argue that the regulators' apparent desire to >>>>>>>>>> force devices to authenticate is not necessarily the right >>> one >>>>>>>>>> for the IETF to force upon all users of the PAWS protocol. So >>>>>>>>>> there could for example be a mode of operation where the DB >>>>>>>>>> signs stuff but doesn't care who's asking and that'd be a far >>>>>>>>>> far easier scenario in terms of automated key management. >>>>>>>>>> >>>>>>>>>> [1] http://tools.ietf.org/html/bcp107 >>>>>>>>>> _______________________________________________ paws mailing >>>>>>>>>> list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> paws mailing list >>>>>>>>> paws@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From Gabor.Bajko@nokia.com Thu Sep 13 16:40:25 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6321F853C for ; Thu, 13 Sep 2012 16:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlVmif7jmTO0 for ; Thu, 13 Sep 2012 16:40:24 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 70ECA21F853E for ; Thu, 13 Sep 2012 16:40:24 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8DNe9FZ001692; Fri, 14 Sep 2012 02:40:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Sep 2012 02:40:08 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0309.003; Fri, 14 Sep 2012 01:40:07 +0200 From: To: , Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhAALc8RHA= Date: Thu, 13 Sep 2012 23:40:07 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2012 23:40:08.0873 (UTC) FILETIME=[1C2DB190:01CD9209] X-Nokia-AV: Clean Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 23:40:25 -0000 X-List-Received-Date: Thu, 13 Sep 2012 23:40:25 -0000 VGhlcmUgd2FzIG5vdCBtdWNoIGZlZWRiYWNrIG9uIHRoZSBsaXN0IGFib3V0IHRoZSBvYmplY3Rp b25zIHRvIHRoZSBkaWZmZXJlbnQgZW5jb2RpbmdzLg0KDQpXZSBzZWVtIHRvIGFncmVlIHRoYXQ6 DQp4bWwgbWF5IG5vdCBiZSB0aGUgcmlnaHQgY2hvaWNlIGJlY2F1c2UgdGhlIGN1cnJlbnQgdHJl bmQgZm9yIEFQSXMgaW4gdGhlIGJyb3dzZXJzIGlzIHRvd2FyZHMganNvbjsgYW5kDQppZiB3ZSBj aG9vc2UgIGpzb24sIGFzIHNvbWUgZGF0YSBzdHJ1Y3R1cmVzIFBBV1MgbWF5IHJldXNlIGFyZSAg ZW5jb2RlZCBpbiB4bWwsIGEganNvbiBlbmNvZGluZyBmb3IgdGhvc2Ugd291bGQgbmVlZCB0byBi ZSBkZWZpbmVkICh3aGljaCBpcyBub3QgaW1wb3NzaWJsZSwgYnV0IHJlcXVpcmVzIHNvbWUgZXh0 cmEgd29yaykNCg0KVGhlIGxhdHRlciBvZiB0aGUgdHdvIG9iamVjdGlvbnMgd2lsbCBub3QgYmUg dmFsaWQgd2hlbiB3ZSdsbCBzZW5kIHRoZSBkb2N1bWVudCB0byBpZXNnLCBhcyBhbGwgdGhlIGVu Y29kaW5ncyB3aWxsIGhhdmUgdG8gYmUgaW4gcGxhY2UgYXQgdGhhdCB0aW1lLg0KU28gd2UgYXJl IGxlZnQgd2l0aCBwcmFjdGljYWxseSBvbmUgcXVlc3Rpb246IGRvIHdlIHdhbnQgdG8gZm9sbG93 IHRoZSBjdXJyZW50IGluZHVzdHJ5IHRyZW5kIGFuZCB1c2UganNvbiwgb3IgZG8gd2Ugd2FudCB0 byBzdGljayB3aXRoIHhtbC4NCg0KQSBzaWduaWZpY2FudCBudW1iZXIgb2YgcGVvcGxlIHByZWZl ciB0byBzcGVjaWZ5IGJvdGggZW5jb2RpbmdzLCBidXQgdGhhdCBtYXkgbm90IGJlIGFncmVlYWJs ZSB3aXRoIHRoZSBpZXNnLg0KDQpUaGlzIGlzIHdoZXJlIHdlIHN0YW5kIG5vdywgZGVhZGxvY2tl ZCBvbiB0aGlzIG5vdCBjcml0aWNhbCBpc3N1ZS4NCg0KQW55IHN1Z2dlc3Rpb24gb24gaG93IHRv IG1vdmUgZm9yd2FyZCB3b3VsZCBiZSBhcHByZWNpYXRlZC4NCg0KLSBHYWJvcg0KDQoNCkZyb206 IGV4dCBaaHVsZWkgW21haWx0bzpsZWkuemh1QGh1YXdlaS5jb21dIA0KU2VudDogTW9uZGF5LCBT ZXB0ZW1iZXIgMTAsIDIwMTIgMTI6NTkgQU0NClRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1Np bGljb25WYWxsZXkpOyBwYXdzQGlldGYub3JnDQpDYzogWmh1bGVpDQpTdWJqZWN0OiBSZTogSlNP TiB2cyBYTUwNCg0KSGksDQoNCkFjdHVhbGx5LCBubyBzbyBtdWNoIGNvbW1lbnRzIG9uIHRoaXMg Y2hvb3NpbmcuIEkganVzdCBkbyBub3QgdGhpbmsgeG1sIGlzIGEgcHJvYmxlbSB0byBlbWJlZGRl ZCBkZXZpY2VzLCBpbiBmYWN0IHhtbCBpcyB3ZWxsIHN1cHBvcnRlZCBieSBkaWZmZXJlbnQgc29y dCBvZiBkZXZpY2VzIGluIG15IHZpZXcuIFRoZSBpc3N1ZSBtYXkgYmUgc29tZSBwb3dlciBhbmQg YmFuZHdpZHRoIGNvbnN0cmFpbmVkIGRldmljZXMgKGUuZy4gc29tZSBzbWFydCBvYmplY3RzKSB0 byBzdXBwb3J0IHR4dCBiYXNlZCBpbmZvcm1hdGlvbi4gTGV04oCZcyBpZ25vcmUgdGhpcyBjYXNl IHNpbmNlIHdlIGFyZSBub3QgdG8gZGVmaW5lIGJpbmFyeSBlbmNvZGluZyBhdCB0aGUgbW9tZW50 LiANCg0KQmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KDQrlj5Hku7bkuro6IHBhd3MtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEdhYm9yLkJhamtv QG5va2lhLmNvbQ0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0OeaciDjml6UgNDo0MQ0K5pS25Lu25Lq6 OiBwYXdzQGlldGYub3JnDQrkuLvpopg6IFtwYXdzXSBKU09OIHZzIFhNTA0KDQpUaGUgY2hhaXJz IGRpc2N1c3NlZCB3aXRoIHRoZSBBRCwgYW5kIHdlIGNhbWUgdXAgd2l0aCB0aGUgZm9sbG93aW5n IGFjdGlvbiBwbGFuIHRvIGRyaXZlIHRoaXMgd2cgdG8gYSBjb25zZW5zdXMgb24gdGhlIGpzb24g dnMgeG1sIGVuY29kaW5nOg0Kd2XigJlsbCBjb2xsZWN0IGFuIG9iamVjdGlvbnMgbGlzdCBmb3Ig anNvbiBhbmQgb25lIGZvciB4bWwsIGxpc3Rpbmcgd2hhdCBpcyBzZWVuIHdyb25nL3Byb2JsZW1h dGljIHdpdGggdGhhdCBlbmNvZGluZy4gVGhlIGNoYWlycyBhbmQgdGhlIHdnIHdpbGwgZ28gdGhy b3VnaCB0aGF0IGxpc3QgYW5kIHNlZSBpZiB0aGUgb2JqZWN0aW9ucyBhcmUgdmFsaWQsIHRoZW4g ZGVjaWRlIHdoaWNoIGVuY29kaW5nIGhhcyBtb3JlIHN1cHBvcnQgYW5kIGNob29zZSB0aGF0IG9u ZS4gSWYgd2UgZW5kIHVwIHdpdGggZ29vZCBvYmplY3Rpb25zIGxpc3QgZm9yIGJvdGgsIHdlIG1h eSBjaG9vc2UgdG8gc3VwcG9ydCBib3RoIGVuY29kaW5ncywgYXMgdGhhdCBsaXN0IHdpbGwganVz dGlmeSB0aGUgZGVjaXNpb24gb25jZSB0aGUgZG9jdW1lbnQgYWR2YW5jZXMgdG8gdGhlIGllc2cu DQoNCkkgd2VudCB0aHJvdWdoIHRoZSBlbWFpbHMgYW5kIEkgZm91bmQgc28gZmFyIHRoZSBmb2xs b3dpbmcgdmFsaWQgb2JqZWN0aW9uczoNCg0KeG1sOiANCnRvbyB2ZXJib3NlLCBtYXkgYmUgYSBw cm9ibGVtIHRvIGJlIHN1cHBvcnRlZCBpbiBlbWJlZGRlZCBkZXZpY2VzDQpjdXJyZW50IHRyZW5k IGZvciBBUElzIGluIHRoZSBicm93c2VycyBpcyB0b3dhcmRzIGpzb24NCg0KDQoNCmpzb246DQpz b21lIGRhdGEgc3RydWN0dXJlcyBhcmXCoCBlbmNvZGVkIGluIHhtbCwgYSBqc29uIGVuY29kaW5n IGZvciB0aG9zZSB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQgKHdoaWNoIGlzIG5vdCBpbXBvc3Np YmxlLCBidXQgcmVxdWlyZXMgc29tZSBleHRyYSB3b3JrKQ0KDQoNCklmIHlvdSBoYXZlIGFkZGl0 aW9uYWwgb2JqZWN0aW9ucywgc2VuZCB0aGVtIHRvIHRoZSBsaXN0IGFzYXAuDQoNCi0gR2Fib3IN Cg== From Gabor.Bajko@nokia.com Thu Sep 13 17:01:19 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA27121F867C for ; Thu, 13 Sep 2012 17:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWdse-fOPRo5 for ; Thu, 13 Sep 2012 17:01:18 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 877BC21F8672 for ; Thu, 13 Sep 2012 17:01:18 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8E017aS017558; Fri, 14 Sep 2012 03:01:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Sep 2012 03:01:07 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.02.0309.003; Fri, 14 Sep 2012 02:00:55 +0200 From: To: , , , , Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaBXVfdMUhbQ7OY0lXuCEkQJ5eD4IlwgAB6rQD//4r34IAAfUcA//+LN1CAAAMcAIAABciBgAUBBiA= Date: Fri, 14 Sep 2012 00:00:54 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602029E09@008-AM1MPN1-006.mgdnok.nokia.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227D5@STNTEXCH01.cis.neustar.com> In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA690227D5@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2012 00:01:07.0565 (UTC) FILETIME=[0A6AD9D0:01CD920C] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 00:01:19 -0000 V2UgaW4gSUVURiBjYW5ub3QgcmVxdWlyZSBhIGNsaWVudCBjZXJ0IHRvIGJlIGluc3RhbGxlZCBp biB0aGUgZGV2aWNlLiBSZWd1bGF0b3JzIG1heSByZXF1aXJlIGl0LCBhbmQgaWYgdGhleSBkb24n dCwgdGhlIGZvbGtzIHdobyBkZXBsb3kgaXQgbWF5IGRvIHNvLg0KV2hhdCB3ZSBjYW4gZG8gaW4g SUVURiBpcyB0byBkZWNpZGUgdG8gb25seSBzcGVjaWZ5IGhvdyBhIGRldmljZSB3aXRoIGEgY2xp ZW50IGNlcnQgaXMgYXV0aGVudGljYXRlZCwgYW5kIG5vdCBzcGVjaWZ5IGhvdyBhIHBhd3MgbWFz dGVyIGRldmljZSBpcyBhdXRoZW50aWNhdGVkIHdpdGggYSBzaGFyZWQgc2VjcmV0LiBJcyB0aGF0 IHdoYXQgd2Ugd2FudD8NCiANCkhhdmluZyBhIGNsaWVudCBjZXJ0IGluIHRoZSBkZXZpY2Ugd291 bGQgY2VydGFpbmx5IG5vdCBjb250cmFkaWN0IHdpdGggdGhlIGN1cnJlbnQgRkNDIHJlcXVpcmVt ZW50IHRvIGhhdmUgYSBwcmlvciByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgbWFzdGVyIGFuZCB0 aGUgZGIuDQoNClRoZSBkcmF3YmFjayBJIGNhbiBzZWUgd2l0aCBub3Qgc3BlY2lmeWluZyB0aGUg c2hhcmVkIHNlY3JldCBjYXNlIGlzIHRoYXQgdGhlIGxhY2sgb2Ygc3BlY2lmeWluZyB0aGUgdXNl IG9mIHNoYXJlZCBzZWNyZXRzIHdpbGwgbm90IHByZXZlbnQgZm9sa3MgdG8gZGVwbG95IGl0IHVz aW5nIHNoYXJlZCBzZWNyZXRzOyB3aGljaCBtYXkgbGVhZCB0byBkZXBsb3ltZW50cyB3aXRoIG5v dCBzdGFuZGFyZCB2YXJpYXRpb25zLg0KDQotIEdhYm9yDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBleHQgUm9zZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rh ci5iaXpdIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgMTI6MTggUE0NClRvOiAn UGF1bCBMYW1iZXJ0JzsgJ1BldGVyIE1jQ2Fubic7ICdQZXRlciBTdGFuZm9ydGgnOyAnU3RlcGhl biBGYXJyZWxsJzsgQmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KQ0KQ2M6ICdw YXdzQGlldGYub3JnJw0KU3ViamVjdDogUkU6IFtwYXdzXSBQQVdTIHNlY3VyaXR5DQoNClRoZSBl YXNpZXN0IHdheSB0byBkbyB0aGlzIGlzIHRvIGhhdmUgdGhlIG1hbnVmYWN0dXJlciBwdXQgYSBj ZXJ0IGluIHRoZSBkZXZpY2UgdGhhdCBpdCBzaWducy4gIFRoZW4gdGhlIG9ubHkgdGhpbmcgdGhl IGRhdGFiYXNlIG5lZWRzIGlzIHRoZSBwdWJsaWMga2V5IG9mIHRoZSBtYW51ZmFjdHVyZXIsDQoN CldoeSBkbyB3ZSB3YW50IHRvIG1ha2UgdGhpcyBoYXJkZXI/DQoNCkJlY2F1c2Ugc29tZSBtYW51 ZmFjdHVyZXJzIHRoaW5rIGl0cyB0b28gbXVjaCB3b3JrIHRvIGRvIHRoYXQ/DQoNCkJyaWFuDQoN Cg0KDQogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlQYXVsIExhbWJlcnQgW21h aWx0bzpwYXVsQG1hcnZlbGwuY29tXQ0KU2VudDoJTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIg MDM6MTUgUE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzoJUGV0ZXIgTWNDYW5uOyBQZXRlciBT dGFuZm9ydGg7IFN0ZXBoZW4gRmFycmVsbDsgR2Fib3IuQmFqa29Abm9raWEuY29tDQpDYzoJcGF3 c0BpZXRmLm9yZw0KU3ViamVjdDoJUmU6IFtwYXdzXSBQQVdTIHNlY3VyaXR5DQoNCiANCj4gVGhp cyByZXN0cmljdGlvbiBtYXkgaG9sZCB0b2RheSBmb3IgdGhlIEZDQywgYnV0IEkgaGF2ZSBhIGhh cmQgdGltZSANCj4gYmVsaWV2aW5nIHRoYXQgYSBwcmUtZXhpc3RpbmcgbWFudWZhY3R1cmVyLWRh dGFiYXNlIHJlbGF0aW9uc2hpcCB3aWxsIA0KPiBiZSBtYW5kYXRvcnkgaW4gZXZlcnkgcmVndWxh dG9yeSBkb21haW4gZm9yIHRoZSBmb3JzZWVhYmxlIGZ1dHVyZS4gIEkgDQo+IHRoaW5rIHdlIHNo b3VsZCBkZXNpZ24gdG8gbWluaW1pemUgdGhlIGZyaWN0aW9uIGluIGNoYW5naW5nIGRhdGFiYXNl IA0KPiBwcm92aWRlcnMuDQoNClRoZSBsZWFzdCBmcmljdGlvbiB3b3VsZCBiZSB0byBoYXJkd2ly ZSBkZXZpY2VzIHdpdGggYSBQSyAicm9vdCIgZm9yIGVhY2ggcmVndWxhdG9yeSBkb21haW4gdGhh dCB0aGUgZGV2aWNlIHN1cHBvcnRzLg0KDQpWYWxpZCBEQnMgd291bGQgaGF2ZSBjcmVkZW50aWFs cyBzaWduZWQgYnkgdGhlIGtleSBob2xkZXIgb2Ygcm9vdHMgZm9yIGVhY2ggcmVndWxhdG9yeSBk b21haW4NCg0KUGF1bA0KDQoNCj4gLVBldGUNCj4gDQo+IFBldGVyIFN0YW5mb3J0aCB3cm90ZToN Cj4gPiBJIGNvbXBsZXRlbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCBiZWxvdy4gSWYgd2Ug YXJlIGdvb2QgYW55DQo+IHJhZGlvDQo+ID4gd2lsbCBoYXZlIHRoZSAiVGVjaG5pY2FsIiBjYXBh YmlsaXR5IHRvIHdvcmsgd2l0aCBhbnkgZGF0YWJhc2UuDQo+ID4gQlVULCBhbmQgdGhpcyBpcyBh IGJpZyBCVVQsIHRoZSByZWd1bGF0aW9uIG1heSBub3QgYWxsb3cgaXQgLSBUaGUgDQo+ID4gRkND IGRvZXMgbm90IHRvZGF5LiBBbmQgYXMgYSBEQkEgSSBvbmx5IHdhbnQgdG8gd29yayB3aXRoIGRl dmljZXMgDQo+ID4gd2hlcmUgSSBoYXZlIGEgcHJlZGVmaW5lZCByZWxhdGlvbnNoaXAuIE5vdCBs ZWFzdCBvZiB3aGljaCwgYmVjYXVzZSANCj4gPiBhcyBJIGFtIGF1dGhvcml6ZWQgYnkgYSBSZWd1 bGF0b3IgSSB3YW50IHRvIG1ha2Ugc3VyZSBJIGFtIGRvaW5nIA0KPiA+IGV2ZXJ5dGhpbmcgSSBj YW4gdG8gYXZvaWQgdGhlaXIgd3JhdGguDQo+ID4gVGhpcyBoYXMgY29tZSB1cCBiZWZvcmUuIFBB V1MgaXMgZGVmaW5pbmcgYW4gQVBJL1Byb3RvY29sLCBub3QgdGhlIA0KPiA+IHJlZ3VsYXRpb24g bm9yIHRoZSBidXNpbmVzcyBjYXNlcyBhdCB0aGlzIHRpbWUuIFNvIEkgc3RpbGwgc2F5IHRoYXQN Cj4gd2UNCj4gPiBjYW4gY29tcGx5IHdpdGggeW91ciBzdGF0ZW1lbnQgd2l0aG91dCBjb25zaWRl cmluZyBhICJVc2VyIi4NCj4gPg0KPiA+IE9uIE1vblNlcC8xMC8xMiBNb24gU2VwIDEwLCAyOjE4 IFBNLCAiUGV0ZXIgTWNDYW5uIg0KPiA+IDxQZXRlci5NY0Nhbm5AaHVhd2VpLmNvbT4gd3JvdGU6 DQo+ID4NCj4gPj4gVGhpcyBpcyBhIGtleSBxdWVzdGlvbiB3ZSBuZWVkIHRvIGFuc3dlci4NCj4g Pj4NCj4gPj4gSSB0aG91Z2h0IHdlIHdlcmUgZGVmaW5pbmcgYSBwcm90b2NvbCB0aGF0IHdvdWxk IGFsbG93IGEgcmFkaW8gZnJvbSANCj4gPj4gYW55IG1hbnVmYWN0dXJlciB0byBpbnRlcm9wZXJh dGUgd2l0aCBhIGRhdGFiYXNlIG9mIGFueSBkYXRhYmFzZQ0KPiB2ZW5kb3IuDQo+ID4+DQo+ID4+ IC1QZXRlDQo+ID4+DQo+ID4+IFBldGVyIFN0YW5mb3J0aCB3cm90ZToNCj4gPj4+IFBldGUsIEkg YW0gbm90IHN1cmUgSSBiZWxpZXZlIGluIGEgdXNlIGNhc2Ugd2hlcmUgInVzZXJzIiBtb3ZlIA0K PiA+Pj4gZnJvbSBvbmUgREIgdG8gYW5vdGhlci4gVGhlIHJlbGF0aW9uc2hpcCBpcyBiZXR3ZWVu IHRoZSByYWRpbyANCj4gPj4+IHZlbmRvciBhbmQgdGhlIERCQS4gVGhlIHJhZGlvIHZlbmRvciBt YXkgaGF2ZSBtdWx0aXBsZSANCj4gPj4+IHJlbGF0aW9uc2hpcHMgYW5kIGFsbG93IGFuIGVuZCB1 c2VyICB0byBjaG9vc2Ugb25lLCBidXQgaXQgd2lsbCBiZSANCj4gPj4+IGZyb20gdGhlIHByZWRl ZmluZWQNCj4gbGlzdC4NCj4gPj4+IEFzIGEgREJBIEkgIGRvbid0IHRoaW5rIEkgd291bGQgd2Fu dCwgYW5kIGluIHRoZSBVU0Egd2UgYXJlIG5vdCANCj4gPj4+IHBlcm1pdHRlZCwgdG8gZXN0YWJs aXNoIGEgcmVsYXRpb25zaGlwIHdpdGggYSB1c2VyIHdpdGhvdXQgYSANCj4gPj4+IHByZWV4aXN0 aW5nIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSByYWRpbyB2ZW5kb3IuIFNvIHNlY3VyaXR5IHNob3Vs ZCANCj4gPj4+IGJlIHByaW1hcmlseSBhIHJhZGlvIHZlbmRvci1EQkEgaXNzdWUuIFdlYXJpbmcg bXkgREJBIGhhdCBJIGRvbid0IA0KPiA+Pj4gdGhpbmsgSSB3b3VsZCB3YW50IHRvIHNlcnZpY2Ug YSByYWRpbyB0aGF0IEkgZG8gbm90IGhhdmUgYSANCj4gPj4+IHByZWV4aXN0aW5nIHJlbGF0aW9u c2hpcCB3aXRoIGl0J3MgbWFudWZhY3R1cmVyLiAgSSBhbSBub3Qgc3VyZQ0KPiB0aGF0DQo+ID4+ PiB1c2VyIHJlbGF0aW9uc2hpcHMgYXJlIGV2ZW4gd2l0aGluIHRoZSBzY29wZSBvZiB3aGF0IFBB V1Mgc2hvdWxkIA0KPiA+Pj4gYmUNCj4gZGVmaW5pbmcuIFBldGVyIFMuDQo+ID4+Pg0KPiA+Pj4g T24gTW9uU2VwLzEwLzEyIE1vbiBTZXAgMTAsIDE6NTggUE0sICJQZXRlciBNY0Nhbm4iDQo+ID4+ PiA8UGV0ZXIuTWNDYW5uQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+PiBQZXJzb25h bGx5LCBJIHRoaW5rIHRoYXQgbWFudWFsbHkgcHJvdmlzaW9uZWQgc3ltbWV0cmljIGtleXMgd2ls bCANCj4gPj4+PiBzZXZlcmVseSBsaW1pdCB0aGUgYWJpbGl0eSBmb3IgdXNlcnMgdG8gZmxleGli bHkgbW92ZSBmcm9tIG9uZSANCj4gPj4+PiBkYXRhYmFzZSBwcm92aWRlciB0byBhbm90aGVyLiAg SXQgd2lsbCByZXF1aXJlIHNvbWUgc2VjdXJlIA0KPiA+Pj4+IG91dC1vZi1iYW5kIGNoYW5uZWwg b24gd2hpY2ggdG8gdHJhbnNtaXQgdGhlIHNlY3JldCBrZXkgZnJvbSBvbmUgDQo+ID4+Pj4gcGFy dHkgdG8gdGhlIG90aGVyLCBhbmQgYSBtZWNoYW5pc20gZm9yIHRoZSB1c2VyIHRvIHB1c2ggdGhl DQo+IHNlY3JldA0KPiA+Pj4+IGtleSBkb3duIGludG8gdGhlIG1hc3RlciBkZXZpY2UuDQo+ID4+ Pj4NCj4gPj4+PiBQcm92aXNpb25pbmcgb2YgY2VydGlmaWNhdGVzIGRvZXMgbm90IHJlcXVpcmUg dGhlIHNlY3JldCBjaGFubmVsLCANCj4gPj4+PiBvbmx5IG9uZSB0aGF0IGlzIGludGVncml0eSBw cm90ZWN0ZWQuICBJIHRoaW5rIHRoaXMgaXMgbXVjaCANCj4gPj4+PiBlYXNpZXIgdG8gYWNoaWV2 ZSBpbiBwcmFjdGljZS4NCj4gPj4+Pg0KPiA+Pj4+IC1QZXRlDQo+ID4+Pj4NCj4gPj4+PiBTdGVw aGVuIEZhcnJlbGwgd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IE9uIDA5LzA3LzIw MTIgMTA6MDEgUE0sIEdhYm9yLkJhamtvQG5va2lhLmNvbSB3cm90ZTo+IEF0IHRoZSANCj4gPj4+ Pj4gVmFuY291dmVyIEYyRiB3ZSBoYWQgZXh0ZW5zaXZlIGRpc2N1c3Npb25zIG9uIHRoZSBzZWN1 cml0eSBtb2RlbCANCj4gPj4+Pj4gZm9yIFBBV1MuIERyYWZ0LWRhcyBwcm9wb3NlcyB0byB1c2Ug c2hhcmVkIHNlY3JldHMgcHJlLQ0KPiBwcm92aXNpb25lZA0KPiA+Pj4+PiBpbiB0aGUgbWFzdGVy IGRldmljZXMgZm9yIGF1dGhlbnRpY2F0aW9uLCB3aGlsZSBkcmFmdC1sZWkNCj4gcHJvcG9zZXMN Cj4gPj4+Pj4gdG8gbWFuZGF0ZSBjbGllbnQgY2VydGlmaWNhdGVzIGludG8gbWFzdGVyIGRldmlj ZXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlcmUgc2VlbWVkIHRvIGJlIGFuIHVuZGVyc3RhbmRp bmcgdGhhdCB0aGUgY3JlZGVudGlhbCB0eXBlcyANCj4gPj4+Pj4+IGluDQo+ID4+PiB1c2UNCj4g Pj4+Pj4gZm9yIGF1dGhlbnRpY2F0aW9uIGFyZSBhIG1hdHRlciBvZiBhIGJ1c2luZXNzIG1vZGVs IGNob3NlbiBieSANCj4gPj4+Pj4gdGhlIHByb3ZpZGVyIHdoaWNoIGRlcGxveXMgd2hpdGUgc3Bh Y2UgZGV2aWNlcywgcmF0aGVyIHRoYW4gYQ0KPiBwcm90b2NvbA0KPiA+Pj4+PiBkZWNpc2lvbi4N Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBCcmlhbiBtZW50aW9uZWQgdGhhdCB0aGUgaWVzZyBtYXkgbm90 IGFsbG93IGEgZG9jdW1lbnQgdG8gYmUNCj4gPj4+Pj4gcHVibGlzaGVkIHdoaWNoIHNwZWNpZmll cyBob3cgc2hhcmVkIHNlY3JldHMgYXJlIHVzZWQsIGJ1dCBkb2VzIA0KPiA+Pj4+PiBub3QgaGF2 ZSBhIHByb3Zpc2lvbmluZyBtZWNoYW5pc20gZm9yIHRoZSBzaGFyZWQgc2VjcmV0cyBkZWZpbmVk Lg0KPiA+Pj4+PiBJbiBteSBvcGluaW9uLCBhIG1lY2hhbmlzbSBmb3IgZGlzdHJpYnV0aW5nIHNo YXJlZCBzZWNyZXRzIGRvZXMgDQo+ID4+Pj4+IG5vdCBuZWNlc3NhcmlseSBoYXZlIHRvIGJlIGRl ZmluZWQsIGFzIGEgc2hhcmVkIHNlY3JldCBjYW4gYmUgDQo+ID4+Pj4+IGVzdGFibGlzaGVkIHVz aW5nIGN1cnJlbnQgcHJhY3RpY2VzIHRvIHNldCB1cCBzaGFyZWQgc2VjcmV0cyANCj4gPj4+Pj4g d2l0aCBmaW5hbmNpYWwgaW5zdGl0dXRpb25zICh1c2luZyB0aGUgYnJvd3NlcikuDQo+ID4+Pj4+ PiBUaHVzLCBteSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIGRlc2NyaWJlIGluIHRoZSBkb2N1bWVu dCBob3cgYSANCj4gPj4+Pj4+IHNoYXJlZA0KPiA+Pj4+PiBzZWNyZXQgYW5kIGhvdyBhIGNsaWVu dCBjZXJ0aWZpY2F0ZSBpcyB1c2VkIHRvIGF1dGhlbnRpY2F0ZSBhIA0KPiA+Pj4+PiBtYXN0ZXIg ZGV2aWNlLiBUaGVuLCBpZiB3ZSBydW4gaW50byBpc3N1ZXMgd2l0aCBpZXNnLCBpbiB3b3JzdCAN Cj4gPj4+Pj4gY2FzZSB3ZSBjb3VsZCByZW1vdmUgdGhlIHNoYXJlZCBzZWNyZXQgcGFydCBhbmQg a2VlcCB0aGUgb3RoZXINCj4gb25lLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEknZCBsaWtlIHRvIGdl dCBhZGRpdGlvbmFsIHZpZXdzIG9uIHRoaXMgdG9waWMuDQo+ID4+Pj4+DQo+ID4+Pj4+IEkgY2Fu IGhlbHAgYSBsaXR0bGUgaGVyZSAoZGVwZW5kaW5nIG9uIHlvdXIgZGVmaW5pdGlvbiBvZiANCj4g Pj4+Pj4gaGVscDotKQ0KPiA+Pj4+Pg0KPiA+Pj4+PiBCQ1AgMTA3IFsxXSBpcyB0aGUgb25lIHRv IGxvb2sgYXQgd2hlbiBjb25zaWRlcmluZyBob3cgdG8NCj4gYXBwcm9hY2gNCj4gPj4+Pj4gYXV0 b21hdGVkIGtleSBtYW5hZ2VtZW50IHJlcXVpcmVtZW50cy4gVGhhdCBoYXMgYW4gSU1PIHZlcnkg Z29vZA0KPiA+Pj4+PiBhYnN0cmFjdDoNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgVGhlIHF1ZXN0aW9u IG9mdGVuIGFyaXNlcyBvZiB3aGV0aGVyIGEgZ2l2ZW4gc2VjdXJpdHkgc3lzdGVtDQo+ID4+Pj4+ ICAgIHJlcXVpcmVzIHNvbWUgZm9ybSBvZiBhdXRvbWF0ZWQga2V5IG1hbmFnZW1lbnQsIG9yIHdo ZXRoZXINCj4gbWFudWFsDQo+ID4+Pj4+ICAgIGtleWluZyBpcyBzdWZmaWNpZW50LiAgVGhpcyBt ZW1vIHByb3ZpZGVzIGd1aWRlbGluZXMgZm9yDQo+IG1ha2luZw0KPiA+Pj4+PiAgICBzdWNoIGRl Y2lzaW9ucy4gV2hlbiBzeW1tZXRyaWMgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc21zIGFyZQ0KPiB1 c2VkDQo+ID4+Pj4+ICAgIGluIGEgcHJvdG9jb2wsIHRoZSBwcmVzdW1wdGlvbiBpcyB0aGF0IGF1 dG9tYXRlZCBrZXkNCj4gbWFuYWdlbWVudA0KPiA+Pj4+PiAgICBpcyBnZW5lcmFsbHkgYnV0IG5v dCBhbHdheXMgbmVlZGVkLiAgSWYgbWFudWFsIGtleWluZyBpcyANCj4gPj4+Pj4gcHJvcG9zZWQs DQo+ID4gdGhlDQo+ID4+Pj4+ICAgIGJ1cmRlbiBvZiBwcm92aW5nIHRoYXQgYXV0b21hdGVkIGtl eSBtYW5hZ2VtZW50IGlzIG5vdA0KPiByZXF1aXJlZA0KPiA+Pj4+PiAgICBmYWxscyB0byB0aGUN Cj4gPj4+IHByb3Bvc2VyLg0KPiA+Pj4+PiBGb3IgdGhvc2UgdGhhdCBtaWdodCBiZSBsZXNzIGZh bWlsaWFyIHdpdGggSUVURiBwcm9jZXNzZXMsIHRoZSANCj4gPj4+Pj4gZmFjdCB0aGF0IHRoYXQn cyBhIEJDUCBtZWFucyB0aGF0IGl0cyBlbnRpcmVseSB2YWxpZCBmb3IgYW4gQUQgDQo+ID4+Pj4+ IHRvIHN0cmVudW91c2x5IHB1c2ggYmFjayBhZ2FpbnN0IGEgV0cgdGhhdCB3YW50cyB0byBpZ25v cmUgd2hhdCANCj4gPj4+Pj4gaXQNCj4gc2F5cy4NCj4gPj4+Pj4NCj4gPj4+Pj4gQ2hlZXJzLA0K PiA+Pj4+PiBTLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBQUzogSSd2ZSBub3QgcmVhZCB0aGUgZHJhZnRz LCBhbmQgY291bGRuJ3QgbWFrZSB0aGUgc2Vzc2lvbiBpbiANCj4gPj4+Pj4gVmFuY291dmVyLCBz byB0aGlzIG1pZ2h0IGJlIGVudGlyZWx5IG9mZiB0b3BpYywgYnV0IGluIHRoZSBjYXNlDQo+IG9m DQo+ID4+Pj4+IFBBV1MgSSdkIGFsc28gYXJndWUgdGhhdCB0aGUgcmVndWxhdG9ycycgYXBwYXJl bnQgZGVzaXJlIHRvIA0KPiA+Pj4+PiBmb3JjZSBkZXZpY2VzIHRvIGF1dGhlbnRpY2F0ZSBpcyBu b3QgbmVjZXNzYXJpbHkgdGhlIHJpZ2h0IG9uZSANCj4gPj4+Pj4gZm9yIHRoZSBJRVRGIHRvIGZv cmNlIHVwb24gYWxsIHVzZXJzIG9mIHRoZSBQQVdTIHByb3RvY29sLiBTbyANCj4gPj4+Pj4gdGhl cmUgY291bGQgZm9yIGV4YW1wbGUgYmUgYSBtb2RlIG9mIG9wZXJhdGlvbiB3aGVyZSB0aGUgREIg DQo+ID4+Pj4+IHNpZ25zIHN0dWZmIGJ1dCBkb2Vzbid0IGNhcmUgd2hvJ3MgYXNraW5nIGFuZCB0 aGF0J2QgYmUgYSBmYXIgDQo+ID4+Pj4+IGZhciBlYXNpZXIgc2NlbmFyaW8gaW4gdGVybXMgb2Yg YXV0b21hdGVkIGtleSBtYW5hZ2VtZW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBbMV0gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvYmNwMTA3IA0KPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBwYXdzIG1haWxpbmcgDQo+ID4+Pj4+IGxpc3QgcGF3 c0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4g Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+ID4+Pj4gcGF3 c0BpZXRmLm9yZw0KPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwYXdzIG1haWxpbmcgbGlzdA0KPiBwYXdz QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFp bGluZyBsaXN0DQpwYXdzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Bhd3MNCg== From brian.rosen@neustar.biz Thu Sep 13 17:07:22 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9574521F869E for ; Thu, 13 Sep 2012 17:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQyPT7yiCC2O for ; Thu, 13 Sep 2012 17:07:21 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4E00B21F867C for ; Thu, 13 Sep 2012 17:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1347581159; x=1662925944; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=/g88/grHjwcHV06lUkVF3 bn0VRo124TDJWB0NXljaU0=; b=HxW8sg+m/hih08IV29KZjgncmiG9Wq+vDoBWY O6qn2wR5DlbwLIXXTyAUwf8U8Gw4MwXX0ZXE04u9mwrd90bsg== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.9245199; Thu, 13 Sep 2012 20:05:57 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 13 Sep 2012 20:07:04 -0400 From: "Rosen, Brian" To: "Gabor.Bajko@nokia.com" Date: Thu, 13 Sep 2012 20:07:03 -0400 Thread-Topic: [paws] PAWS security Thread-Index: Ac2SDN76RmcLDZ7CSeiNBvLzQoacKQ== Message-ID: <769679CF-1359-4B77-B82C-FC3DF3290135@neustar.biz> References: <55A5A9A87506CB4BA580BF9D531957DA690227D5@STNTEXCH01.cis.neustar.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602029E09@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47602029E09@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Sn/VpWNUrhY10Md6MPIZWQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "Peter.McCann@huawei.com" Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 00:07:22 -0000 We can say that the security model for paws is PKI when authentication of t= he device is needed, with a provisioned cert signed by an entity the DB tru= sts. Whether it's preloaded by a manufacturer or provisioned by some other= mechanism doesn't need to be specified. This is my preference. I would prefer not to have any mention of shared secrets. There are no protocol police. If deployments decide to use shared secrets,= we can't stop them. Brian On Sep 13, 2012, at 8:00 PM, Gabor.Bajko@nokia.com wrote: > We in IETF cannot require a client cert to be installed in the device. Re= gulators may require it, and if they don't, the folks who deploy it may do = so. > What we can do in IETF is to decide to only specify how a device with a c= lient cert is authenticated, and not specify how a paws master device is au= thenticated with a shared secret. Is that what we want? >=20 > Having a client cert in the device would certainly not contradict with th= e current FCC requirement to have a prior relationship between the master a= nd the db. >=20 > The drawback I can see with not specifying the shared secret case is that= the lack of specifying the use of shared secrets will not prevent folks to= deploy it using shared secrets; which may lead to deployments with not sta= ndard variations. >=20 > - Gabor >=20 > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Monday, September 10, 2012 12:18 PM > To: 'Paul Lambert'; 'Peter McCann'; 'Peter Stanforth'; 'Stephen Farrell';= Bajko Gabor (Nokia-CIC/SiliconValley) > Cc: 'paws@ietf.org' > Subject: RE: [paws] PAWS security >=20 > The easiest way to do this is to have the manufacturer put a cert in the = device that it signs. Then the only thing the database needs is the public= key of the manufacturer, >=20 > Why do we want to make this harder? >=20 > Because some manufacturers think its too much work to do that? >=20 > Brian >=20 >=20 >=20 > -----Original Message----- > From: Paul Lambert [mailto:paul@marvell.com] > Sent: Monday, September 10, 2012 03:15 PM Eastern Standard Time > To: Peter McCann; Peter Stanforth; Stephen Farrell; Gabor.Bajko@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] PAWS security >=20 >=20 >> This restriction may hold today for the FCC, but I have a hard time=20 >> believing that a pre-existing manufacturer-database relationship will=20 >> be mandatory in every regulatory domain for the forseeable future. I=20 >> think we should design to minimize the friction in changing database=20 >> providers. >=20 > The least friction would be to hardwire devices with a PK "root" for each= regulatory domain that the device supports. >=20 > Valid DBs would have credentials signed by the key holder of roots for ea= ch regulatory domain >=20 > Paul >=20 >=20 >> -Pete >>=20 >> Peter Stanforth wrote: >>> I completely agree with your statement below. If we are good any >> radio >>> will have the "Technical" capability to work with any database. >>> BUT, and this is a big BUT, the regulation may not allow it - The=20 >>> FCC does not today. And as a DBA I only want to work with devices=20 >>> where I have a predefined relationship. Not least of which, because=20 >>> as I am authorized by a Regulator I want to make sure I am doing=20 >>> everything I can to avoid their wrath. >>> This has come up before. PAWS is defining an API/Protocol, not the=20 >>> regulation nor the business cases at this time. So I still say that >> we >>> can comply with your statement without considering a "User". >>>=20 >>> On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" >>> wrote: >>>=20 >>>> This is a key question we need to answer. >>>>=20 >>>> I thought we were defining a protocol that would allow a radio from=20 >>>> any manufacturer to interoperate with a database of any database >> vendor. >>>>=20 >>>> -Pete >>>>=20 >>>> Peter Stanforth wrote: >>>>> Pete, I am not sure I believe in a use case where "users" move=20 >>>>> from one DB to another. The relationship is between the radio=20 >>>>> vendor and the DBA. The radio vendor may have multiple=20 >>>>> relationships and allow an end user to choose one, but it will be=20 >>>>> from the predefined >> list. >>>>> As a DBA I don't think I would want, and in the USA we are not=20 >>>>> permitted, to establish a relationship with a user without a=20 >>>>> preexisting relationship with the radio vendor. So security should=20 >>>>> be primarily a radio vendor-DBA issue. Wearing my DBA hat I don't=20 >>>>> think I would want to service a radio that I do not have a=20 >>>>> preexisting relationship with it's manufacturer. I am not sure >> that >>>>> user relationships are even within the scope of what PAWS should=20 >>>>> be >> defining. Peter S. >>>>>=20 >>>>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" >>>>> wrote: >>>>>=20 >>>>>> Personally, I think that manually provisioned symmetric keys will=20 >>>>>> severely limit the ability for users to flexibly move from one=20 >>>>>> database provider to another. It will require some secure=20 >>>>>> out-of-band channel on which to transmit the secret key from one=20 >>>>>> party to the other, and a mechanism for the user to push the >> secret >>>>>> key down into the master device. >>>>>>=20 >>>>>> Provisioning of certificates does not require the secret channel,=20 >>>>>> only one that is integrity protected. I think this is much=20 >>>>>> easier to achieve in practice. >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>> Stephen Farrell wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the=20 >>>>>>> Vancouver F2F we had extensive discussions on the security model=20 >>>>>>> for PAWS. Draft-das proposes to use shared secrets pre- >> provisioned >>>>>>> in the master devices for authentication, while draft-lei >> proposes >>>>>>> to mandate client certificates into master devices. >>>>>>>>=20 >>>>>>>> There seemed to be an understanding that the credential types=20 >>>>>>>> in >>>>> use >>>>>>> for authentication are a matter of a business model chosen by=20 >>>>>>> the provider which deploys white space devices, rather than a >> protocol >>>>>>> decision. >>>>>>>>=20 >>>>>>>> Brian mentioned that the iesg may not allow a document to be >>>>>>> published which specifies how shared secrets are used, but does=20 >>>>>>> not have a provisioning mechanism for the shared secrets defined. >>>>>>> In my opinion, a mechanism for distributing shared secrets does=20 >>>>>>> not necessarily have to be defined, as a shared secret can be=20 >>>>>>> established using current practices to set up shared secrets=20 >>>>>>> with financial institutions (using the browser). >>>>>>>> Thus, my suggestion would be to describe in the document how a=20 >>>>>>>> shared >>>>>>> secret and how a client certificate is used to authenticate a=20 >>>>>>> master device. Then, if we run into issues with iesg, in worst=20 >>>>>>> case we could remove the shared secret part and keep the other >> one. >>>>>>>>=20 >>>>>>>> I'd like to get additional views on this topic. >>>>>>>=20 >>>>>>> I can help a little here (depending on your definition of=20 >>>>>>> help:-) >>>>>>>=20 >>>>>>> BCP 107 [1] is the one to look at when considering how to >> approach >>>>>>> automated key management requirements. That has an IMO very good >>>>>>> abstract: >>>>>>>=20 >>>>>>> The question often arises of whether a given security system >>>>>>> requires some form of automated key management, or whether >> manual >>>>>>> keying is sufficient. This memo provides guidelines for >> making >>>>>>> such decisions. When symmetric cryptographic mechanisms are >> used >>>>>>> in a protocol, the presumption is that automated key >> management >>>>>>> is generally but not always needed. If manual keying is=20 >>>>>>> proposed, >>> the >>>>>>> burden of proving that automated key management is not >> required >>>>>>> falls to the >>>>> proposer. >>>>>>> For those that might be less familiar with IETF processes, the=20 >>>>>>> fact that that's a BCP means that its entirely valid for an AD=20 >>>>>>> to strenuously push back against a WG that wants to ignore what=20 >>>>>>> it >> says. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> S. >>>>>>>=20 >>>>>>> PS: I've not read the drafts, and couldn't make the session in=20 >>>>>>> Vancouver, so this might be entirely off topic, but in the case >> of >>>>>>> PAWS I'd also argue that the regulators' apparent desire to=20 >>>>>>> force devices to authenticate is not necessarily the right one=20 >>>>>>> for the IETF to force upon all users of the PAWS protocol. So=20 >>>>>>> there could for example be a mode of operation where the DB=20 >>>>>>> signs stuff but doesn't care who's asking and that'd be a far=20 >>>>>>> far easier scenario in terms of automated key management. >>>>>>>=20 >>>>>>> [1] http://tools.ietf.org/html/bcp107=20 >>>>>>> _______________________________________________ paws mailing=20 >>>>>>> list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From lei.zhu@huawei.com Thu Sep 13 21:18:01 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B244321F863C for ; Thu, 13 Sep 2012 21:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=2.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsqxX8rm+ErG for ; Thu, 13 Sep 2012 21:18:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D78521F8629 for ; Thu, 13 Sep 2012 21:18:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJQ70372; Fri, 14 Sep 2012 04:17:57 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 05:16:55 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 05:17:03 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 14 Sep 2012 12:17:00 +0800 From: Zhulei To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhAALc8RHAACYgH0A== Date: Fri, 14 Sep 2012 04:16:59 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.64.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 04:18:01 -0000 SGksDQoNCkkgcmVhbGx5IHdlbnQgdGhyb3VnaCBlLW1haWwgZGlzY3Vzc2lvbnMgb24gdGhpcy4g TXkgcHJvcG9zYWwgaXMgdG8gdXNlIGpzb24gYXMgZGF0YSBtb2RlbCBvZiBwYXdzIHByb3RvY29s IGlzc3VlZCBieSBwYXdzLCBpbiBjYXNlIHRoYXQgd2cgYWRkcmVzc2VzIHRoZSB0cmVuZCBvZiBB UElzIG9mIGJyb3dzZXIgdmVuZGVycyBhbmQga2VlcCBzb21lIGRpc2NvdmVyeSBtZWNoYW5pc21z IG9wZW4gZm9yIGFueSBleHRyYSB3b3Jrcy4gQXQgdGhlIHNhbWUgdGltZSwgd2UgaGF2ZSBzb21l IHByb2JsZW1zIHRvIHNhdGlzZnkgdGhlIG5lZWRzIHRvIHJldXNlIHdzIHNjaGVtYSBlbmNvZGVk IGJ5IHRyYWRpdGlvbmFsIGRldmljZXMsIHdoaWNoIHdpbGwgaXNzdWUgYSBzZXBhcmF0ZSB3ZyBk b2N1bWVudCBmb3IgeG1sIGVuY29kaW5nIHN0YW5kYXJkIGZvciB4bWwgc3VwcG9ydGluZyBpbmR1 c3RyaWVzLg0KDQpUaGUgcmVhc29ucyBkb2luZyB0aGlzIGFyZSBub3QgdGVjaG5pY2FsIGlzc3Vl cywganVzdCB3ZSBoYXZlIGJyb2FkIHJlcXVpcmVtZW50cyB0byByZXVzZSBUU1dTIGdlbmVyYWxs eSBmb3IgY29tbXVuaWNhdGlvbiBwdXJwb3NlcywgaW5jbHVkaW5nIHNtYXJ0IG9iamVjdHMsIGFk IGhvYyB1c2UsIGJyb3dzZXIgQVBJLCB3aWZpIGJyb2FkYmFuZCwgY2VsbHVsYXIgZXRjLiANCg0K QmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bk uro6IEdhYm9yLkJhamtvQG5va2lhLmNvbSBbbWFpbHRvOkdhYm9yLkJhamtvQG5va2lhLmNvbV0g DQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTTml6UgNzo0MA0K5pS25Lu25Lq6OiBaaHVsZWk7 IHBhd3NAaWV0Zi5vcmcNCuS4u+mimDogUkU6IEpTT04gdnMgWE1MDQoNClRoZXJlIHdhcyBub3Qg bXVjaCBmZWVkYmFjayBvbiB0aGUgbGlzdCBhYm91dCB0aGUgb2JqZWN0aW9ucyB0byB0aGUgZGlm ZmVyZW50IGVuY29kaW5ncy4NCg0KV2Ugc2VlbSB0byBhZ3JlZSB0aGF0Og0KeG1sIG1heSBub3Qg YmUgdGhlIHJpZ2h0IGNob2ljZSBiZWNhdXNlIHRoZSBjdXJyZW50IHRyZW5kIGZvciBBUElzIGlu IHRoZSBicm93c2VycyBpcyB0b3dhcmRzIGpzb247IGFuZA0KaWYgd2UgY2hvb3NlICBqc29uLCBh cyBzb21lIGRhdGEgc3RydWN0dXJlcyBQQVdTIG1heSByZXVzZSBhcmUgIGVuY29kZWQgaW4geG1s LCBhIGpzb24gZW5jb2RpbmcgZm9yIHRob3NlIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZCAod2hp Y2ggaXMgbm90IGltcG9zc2libGUsIGJ1dCByZXF1aXJlcyBzb21lIGV4dHJhIHdvcmspDQoNClRo ZSBsYXR0ZXIgb2YgdGhlIHR3byBvYmplY3Rpb25zIHdpbGwgbm90IGJlIHZhbGlkIHdoZW4gd2Un bGwgc2VuZCB0aGUgZG9jdW1lbnQgdG8gaWVzZywgYXMgYWxsIHRoZSBlbmNvZGluZ3Mgd2lsbCBo YXZlIHRvIGJlIGluIHBsYWNlIGF0IHRoYXQgdGltZS4NClNvIHdlIGFyZSBsZWZ0IHdpdGggcHJh Y3RpY2FsbHkgb25lIHF1ZXN0aW9uOiBkbyB3ZSB3YW50IHRvIGZvbGxvdyB0aGUgY3VycmVudCBp bmR1c3RyeSB0cmVuZCBhbmQgdXNlIGpzb24sIG9yIGRvIHdlIHdhbnQgdG8gc3RpY2sgd2l0aCB4 bWwuDQoNCkEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIHBlb3BsZSBwcmVmZXIgdG8gc3BlY2lmeSBi b3RoIGVuY29kaW5ncywgYnV0IHRoYXQgbWF5IG5vdCBiZSBhZ3JlZWFibGUgd2l0aCB0aGUgaWVz Zy4NCg0KVGhpcyBpcyB3aGVyZSB3ZSBzdGFuZCBub3csIGRlYWRsb2NrZWQgb24gdGhpcyBub3Qg Y3JpdGljYWwgaXNzdWUuDQoNCkFueSBzdWdnZXN0aW9uIG9uIGhvdyB0byBtb3ZlIGZvcndhcmQg d291bGQgYmUgYXBwcmVjaWF0ZWQuDQoNCi0gR2Fib3INCg0KDQpGcm9tOiBleHQgWmh1bGVpIFtt YWlsdG86bGVpLnpodUBodWF3ZWkuY29tXSANClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDEwLCAy MDEyIDEyOjU5IEFNDQpUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KTsg cGF3c0BpZXRmLm9yZw0KQ2M6IFpodWxlaQ0KU3ViamVjdDogUmU6IEpTT04gdnMgWE1MDQoNCkhp LA0KDQpBY3R1YWxseSwgbm8gc28gbXVjaCBjb21tZW50cyBvbiB0aGlzIGNob29zaW5nLiBJIGp1 c3QgZG8gbm90IHRoaW5rIHhtbCBpcyBhIHByb2JsZW0gdG8gZW1iZWRkZWQgZGV2aWNlcywgaW4g ZmFjdCB4bWwgaXMgd2VsbCBzdXBwb3J0ZWQgYnkgZGlmZmVyZW50IHNvcnQgb2YgZGV2aWNlcyBp biBteSB2aWV3LiBUaGUgaXNzdWUgbWF5IGJlIHNvbWUgcG93ZXIgYW5kIGJhbmR3aWR0aCBjb25z dHJhaW5lZCBkZXZpY2VzIChlLmcuIHNvbWUgc21hcnQgb2JqZWN0cykgdG8gc3VwcG9ydCB0eHQg YmFzZWQgaW5mb3JtYXRpb24uIExldOKAmXMgaWdub3JlIHRoaXMgY2FzZSBzaW5jZSB3ZSBhcmUg bm90IHRvIGRlZmluZSBiaW5hcnkgZW5jb2RpbmcgYXQgdGhlIG1vbWVudC4gDQoNCkJlc3QgcmVn YXJkcywNClpodSBMZWkNCg0K5Y+R5Lu25Lq6OiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBHYWJvci5CYWprb0Bub2tpYS5jb20NCuWP kemAgeaXtumXtDogMjAxMuW5tDnmnIg45pelIDQ6NDENCuaUtuS7tuS6ujogcGF3c0BpZXRmLm9y Zw0K5Li76aKYOiBbcGF3c10gSlNPTiB2cyBYTUwNCg0KVGhlIGNoYWlycyBkaXNjdXNzZWQgd2l0 aCB0aGUgQUQsIGFuZCB3ZSBjYW1lIHVwIHdpdGggdGhlIGZvbGxvd2luZyBhY3Rpb24gcGxhbiB0 byBkcml2ZSB0aGlzIHdnIHRvIGEgY29uc2Vuc3VzIG9uIHRoZSBqc29uIHZzIHhtbCBlbmNvZGlu ZzoNCndl4oCZbGwgY29sbGVjdCBhbiBvYmplY3Rpb25zIGxpc3QgZm9yIGpzb24gYW5kIG9uZSBm b3IgeG1sLCBsaXN0aW5nIHdoYXQgaXMgc2VlbiB3cm9uZy9wcm9ibGVtYXRpYyB3aXRoIHRoYXQg ZW5jb2RpbmcuIFRoZSBjaGFpcnMgYW5kIHRoZSB3ZyB3aWxsIGdvIHRocm91Z2ggdGhhdCBsaXN0 IGFuZCBzZWUgaWYgdGhlIG9iamVjdGlvbnMgYXJlIHZhbGlkLCB0aGVuIGRlY2lkZSB3aGljaCBl bmNvZGluZyBoYXMgbW9yZSBzdXBwb3J0IGFuZCBjaG9vc2UgdGhhdCBvbmUuIElmIHdlIGVuZCB1 cCB3aXRoIGdvb2Qgb2JqZWN0aW9ucyBsaXN0IGZvciBib3RoLCB3ZSBtYXkgY2hvb3NlIHRvIHN1 cHBvcnQgYm90aCBlbmNvZGluZ3MsIGFzIHRoYXQgbGlzdCB3aWxsIGp1c3RpZnkgdGhlIGRlY2lz aW9uIG9uY2UgdGhlIGRvY3VtZW50IGFkdmFuY2VzIHRvIHRoZSBpZXNnLg0KDQpJIHdlbnQgdGhy b3VnaCB0aGUgZW1haWxzIGFuZCBJIGZvdW5kIHNvIGZhciB0aGUgZm9sbG93aW5nIHZhbGlkIG9i amVjdGlvbnM6DQoNCnhtbDogDQp0b28gdmVyYm9zZSwgbWF5IGJlIGEgcHJvYmxlbSB0byBiZSBz dXBwb3J0ZWQgaW4gZW1iZWRkZWQgZGV2aWNlcw0KY3VycmVudCB0cmVuZCBmb3IgQVBJcyBpbiB0 aGUgYnJvd3NlcnMgaXMgdG93YXJkcyBqc29uDQoNCg0KDQpqc29uOg0Kc29tZSBkYXRhIHN0cnVj dHVyZXMgYXJlwqAgZW5jb2RlZCBpbiB4bWwsIGEganNvbiBlbmNvZGluZyBmb3IgdGhvc2Ugd291 bGQgbmVlZCB0byBiZSBkZWZpbmVkICh3aGljaCBpcyBub3QgaW1wb3NzaWJsZSwgYnV0IHJlcXVp cmVzIHNvbWUgZXh0cmEgd29yaykNCg0KDQpJZiB5b3UgaGF2ZSBhZGRpdGlvbmFsIG9iamVjdGlv bnMsIHNlbmQgdGhlbSB0byB0aGUgbGlzdCBhc2FwLg0KDQotIEdhYm9yDQo= From paul@marvell.com Fri Sep 14 12:34:19 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F5221F853D for ; Fri, 14 Sep 2012 12:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlq7GtNtFyDk for ; Fri, 14 Sep 2012 12:34:19 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id C54C421F8532 for ; Fri, 14 Sep 2012 12:34:18 -0700 (PDT) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUFOGtu1LDAdH8MeVEfqWavnFMXSiNDYb@postini.com; Fri, 14 Sep 2012 12:34:18 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 14 Sep 2012 12:34:13 -0700 From: Paul Lambert To: Zhulei , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Date: Fri, 14 Sep 2012 12:34:11 -0700 Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhAALc8RHAACYgH0AAgzYbQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E4682475@SC-VEXCH2.marvell.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 19:34:19 -0000 DQpJIGRvIG5vdCBzZWUgd2h5IHdlIGFyZSBkZXNpZ25pbmcgZm9yICJicm93c2VyIHZlbmRvcnMi IHdoZW4gd2UgYXJlIGRldmVsb3BpbmcgcHJvdG9jb2xzIGZvciByYWRpb3MuICANCg0KQXMgSSd2 ZSBzYWlkIGJlZm9yZSAuLi4gcmVhbCBwcm90b2NvbHMgdXNlIFRMVnMgDQoNCkl0IGlzIHBvc3Np YmxlIHRvIG1hcCBKU09OIHN0cnVjdXR1cmVzIHRvIFRMVnMgZm9yIGVmZmljaWVuY3kgaWYgYW55 b25lIGlzIGludGVyZXN0ZWQgLi4uDQoNClBhdWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBaaHVsZWkNCj4gU2VudDogVGh1cnNkYXksIFNlcHRl bWJlciAxMywgMjAxMiA5OjE3IFBNDQo+IFRvOiBHYWJvci5CYWprb0Bub2tpYS5jb207IHBhd3NA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtwYXdzXSBKU09OIHZzIFhNTA0KPiANCj4gSGksDQo+ IA0KPiBJIHJlYWxseSB3ZW50IHRocm91Z2ggZS1tYWlsIGRpc2N1c3Npb25zIG9uIHRoaXMuIE15 IHByb3Bvc2FsIGlzIHRvIHVzZQ0KPiBqc29uIGFzIGRhdGEgbW9kZWwgb2YgcGF3cyBwcm90b2Nv bCBpc3N1ZWQgYnkgcGF3cywgaW4gY2FzZSB0aGF0IHdnDQo+IGFkZHJlc3NlcyB0aGUgdHJlbmQg b2YgQVBJcyBvZiBicm93c2VyIHZlbmRlcnMgYW5kIGtlZXAgc29tZSBkaXNjb3ZlcnkNCj4gbWVj aGFuaXNtcyBvcGVuIGZvciBhbnkgZXh0cmEgd29ya3MuIEF0IHRoZSBzYW1lIHRpbWUsIHdlIGhh dmUgc29tZQ0KPiBwcm9ibGVtcyB0byBzYXRpc2Z5IHRoZSBuZWVkcyB0byByZXVzZSB3cyBzY2hl bWEgZW5jb2RlZCBieSB0cmFkaXRpb25hbA0KPiBkZXZpY2VzLCB3aGljaCB3aWxsIGlzc3VlIGEg c2VwYXJhdGUgd2cgZG9jdW1lbnQgZm9yIHhtbCBlbmNvZGluZw0KPiBzdGFuZGFyZCBmb3IgeG1s IHN1cHBvcnRpbmcgaW5kdXN0cmllcy4NCj4gDQo+IFRoZSByZWFzb25zIGRvaW5nIHRoaXMgYXJl IG5vdCB0ZWNobmljYWwgaXNzdWVzLCBqdXN0IHdlIGhhdmUgYnJvYWQNCj4gcmVxdWlyZW1lbnRz IHRvIHJldXNlIFRTV1MgZ2VuZXJhbGx5IGZvciBjb21tdW5pY2F0aW9uIHB1cnBvc2VzLA0KPiBp bmNsdWRpbmcgc21hcnQgb2JqZWN0cywgYWQgaG9jIHVzZSwgYnJvd3NlciBBUEksIHdpZmkgYnJv YWRiYW5kLA0KPiBjZWxsdWxhciBldGMuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFpodSBMZWkN Cj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBHYWJvci5CYWprb0Bu b2tpYS5jb20gW21haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb21dDQo+IOWPkemAgeaXtumXtDog MjAxMuW5tDnmnIgxNOaXpSA3OjQwDQo+IOaUtuS7tuS6ujogWmh1bGVpOyBwYXdzQGlldGYub3Jn DQo+IOS4u+mimDogUkU6IEpTT04gdnMgWE1MDQo+IA0KPiBUaGVyZSB3YXMgbm90IG11Y2ggZmVl ZGJhY2sgb24gdGhlIGxpc3QgYWJvdXQgdGhlIG9iamVjdGlvbnMgdG8gdGhlDQo+IGRpZmZlcmVu dCBlbmNvZGluZ3MuDQo+IA0KPiBXZSBzZWVtIHRvIGFncmVlIHRoYXQ6DQo+IHhtbCBtYXkgbm90 IGJlIHRoZSByaWdodCBjaG9pY2UgYmVjYXVzZSB0aGUgY3VycmVudCB0cmVuZCBmb3IgQVBJcyBp bg0KPiB0aGUgYnJvd3NlcnMgaXMgdG93YXJkcyBqc29uOyBhbmQgaWYgd2UgY2hvb3NlICBqc29u LCBhcyBzb21lIGRhdGENCj4gc3RydWN0dXJlcyBQQVdTIG1heSByZXVzZSBhcmUgIGVuY29kZWQg aW4geG1sLCBhIGpzb24gZW5jb2RpbmcgZm9yDQo+IHRob3NlIHdvdWxkIG5lZWQgdG8gYmUgZGVm aW5lZCAod2hpY2ggaXMgbm90IGltcG9zc2libGUsIGJ1dCByZXF1aXJlcw0KPiBzb21lIGV4dHJh IHdvcmspDQo+IA0KPiBUaGUgbGF0dGVyIG9mIHRoZSB0d28gb2JqZWN0aW9ucyB3aWxsIG5vdCBi ZSB2YWxpZCB3aGVuIHdlJ2xsIHNlbmQgdGhlDQo+IGRvY3VtZW50IHRvIGllc2csIGFzIGFsbCB0 aGUgZW5jb2RpbmdzIHdpbGwgaGF2ZSB0byBiZSBpbiBwbGFjZSBhdCB0aGF0DQo+IHRpbWUuDQo+ IFNvIHdlIGFyZSBsZWZ0IHdpdGggcHJhY3RpY2FsbHkgb25lIHF1ZXN0aW9uOiBkbyB3ZSB3YW50 IHRvIGZvbGxvdyB0aGUNCj4gY3VycmVudCBpbmR1c3RyeSB0cmVuZCBhbmQgdXNlIGpzb24sIG9y IGRvIHdlIHdhbnQgdG8gc3RpY2sgd2l0aCB4bWwuDQo+IA0KPiBBIHNpZ25pZmljYW50IG51bWJl ciBvZiBwZW9wbGUgcHJlZmVyIHRvIHNwZWNpZnkgYm90aCBlbmNvZGluZ3MsIGJ1dA0KPiB0aGF0 IG1heSBub3QgYmUgYWdyZWVhYmxlIHdpdGggdGhlIGllc2cuDQo+IA0KPiBUaGlzIGlzIHdoZXJl IHdlIHN0YW5kIG5vdywgZGVhZGxvY2tlZCBvbiB0aGlzIG5vdCBjcml0aWNhbCBpc3N1ZS4NCj4g DQo+IEFueSBzdWdnZXN0aW9uIG9uIGhvdyB0byBtb3ZlIGZvcndhcmQgd291bGQgYmUgYXBwcmVj aWF0ZWQuDQo+IA0KPiAtIEdhYm9yDQo+IA0KPiANCj4gRnJvbTogZXh0IFpodWxlaSBbbWFpbHRv OmxlaS56aHVAaHVhd2VpLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIg MTI6NTkgQU0NCj4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSk7IHBh d3NAaWV0Zi5vcmcNCj4gQ2M6IFpodWxlaQ0KPiBTdWJqZWN0OiBSZTogSlNPTiB2cyBYTUwNCj4g DQo+IEhpLA0KPiANCj4gQWN0dWFsbHksIG5vIHNvIG11Y2ggY29tbWVudHMgb24gdGhpcyBjaG9v c2luZy4gSSBqdXN0IGRvIG5vdCB0aGluayB4bWwNCj4gaXMgYSBwcm9ibGVtIHRvIGVtYmVkZGVk IGRldmljZXMsIGluIGZhY3QgeG1sIGlzIHdlbGwgc3VwcG9ydGVkIGJ5DQo+IGRpZmZlcmVudCBz b3J0IG9mIGRldmljZXMgaW4gbXkgdmlldy4gVGhlIGlzc3VlIG1heSBiZSBzb21lIHBvd2VyIGFu ZA0KPiBiYW5kd2lkdGggY29uc3RyYWluZWQgZGV2aWNlcyAoZS5nLiBzb21lIHNtYXJ0IG9iamVj dHMpIHRvIHN1cHBvcnQgdHh0DQo+IGJhc2VkIGluZm9ybWF0aW9uLiBMZXTigJlzIGlnbm9yZSB0 aGlzIGNhc2Ugc2luY2Ugd2UgYXJlIG5vdCB0byBkZWZpbmUNCj4gYmluYXJ5IGVuY29kaW5nIGF0 IHRoZSBtb21lbnQuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFpodSBMZWkNCj4gDQo+IOWPkeS7 tuS6ujogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3Jn XSDku6PooagNCj4gR2Fib3IuQmFqa29Abm9raWEuY29tDQo+IOWPkemAgeaXtumXtDogMjAxMuW5 tDnmnIg45pelIDQ6NDENCj4g5pS25Lu25Lq6OiBwYXdzQGlldGYub3JnDQo+IOS4u+mimDogW3Bh d3NdIEpTT04gdnMgWE1MDQo+IA0KPiBUaGUgY2hhaXJzIGRpc2N1c3NlZCB3aXRoIHRoZSBBRCwg YW5kIHdlIGNhbWUgdXAgd2l0aCB0aGUgZm9sbG93aW5nDQo+IGFjdGlvbiBwbGFuIHRvIGRyaXZl IHRoaXMgd2cgdG8gYSBjb25zZW5zdXMgb24gdGhlIGpzb24gdnMgeG1sDQo+IGVuY29kaW5nOg0K PiB3ZeKAmWxsIGNvbGxlY3QgYW4gb2JqZWN0aW9ucyBsaXN0IGZvciBqc29uIGFuZCBvbmUgZm9y IHhtbCwgbGlzdGluZyB3aGF0DQo+IGlzIHNlZW4gd3JvbmcvcHJvYmxlbWF0aWMgd2l0aCB0aGF0 IGVuY29kaW5nLiBUaGUgY2hhaXJzIGFuZCB0aGUgd2cNCj4gd2lsbCBnbyB0aHJvdWdoIHRoYXQg bGlzdCBhbmQgc2VlIGlmIHRoZSBvYmplY3Rpb25zIGFyZSB2YWxpZCwgdGhlbg0KPiBkZWNpZGUg d2hpY2ggZW5jb2RpbmcgaGFzIG1vcmUgc3VwcG9ydCBhbmQgY2hvb3NlIHRoYXQgb25lLiBJZiB3 ZSBlbmQNCj4gdXAgd2l0aCBnb29kIG9iamVjdGlvbnMgbGlzdCBmb3IgYm90aCwgd2UgbWF5IGNo b29zZSB0byBzdXBwb3J0IGJvdGgNCj4gZW5jb2RpbmdzLCBhcyB0aGF0IGxpc3Qgd2lsbCBqdXN0 aWZ5IHRoZSBkZWNpc2lvbiBvbmNlIHRoZSBkb2N1bWVudA0KPiBhZHZhbmNlcyB0byB0aGUgaWVz Zy4NCj4gDQo+IEkgd2VudCB0aHJvdWdoIHRoZSBlbWFpbHMgYW5kIEkgZm91bmQgc28gZmFyIHRo ZSBmb2xsb3dpbmcgdmFsaWQNCj4gb2JqZWN0aW9uczoNCj4gDQo+IHhtbDoNCj4gdG9vIHZlcmJv c2UsIG1heSBiZSBhIHByb2JsZW0gdG8gYmUgc3VwcG9ydGVkIGluIGVtYmVkZGVkIGRldmljZXMN Cj4gY3VycmVudCB0cmVuZCBmb3IgQVBJcyBpbiB0aGUgYnJvd3NlcnMgaXMgdG93YXJkcyBqc29u DQo+IA0KPiANCj4gDQo+IGpzb246DQo+IHNvbWUgZGF0YSBzdHJ1Y3R1cmVzIGFyZcKgIGVuY29k ZWQgaW4geG1sLCBhIGpzb24gZW5jb2RpbmcgZm9yIHRob3NlDQo+IHdvdWxkIG5lZWQgdG8gYmUg ZGVmaW5lZCAod2hpY2ggaXMgbm90IGltcG9zc2libGUsIGJ1dCByZXF1aXJlcyBzb21lDQo+IGV4 dHJhIHdvcmspDQo+IA0KPiANCj4gSWYgeW91IGhhdmUgYWRkaXRpb25hbCBvYmplY3Rpb25zLCBz ZW5kIHRoZW0gdG8gdGhlIGxpc3QgYXNhcC4NCj4gDQo+IC0gR2Fib3INCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QN Cj4gcGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3MNCg== From ben@blindcreek.com Fri Sep 14 16:22:26 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517EE21F849C for ; Fri, 14 Sep 2012 16:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gVs-YF7TEp5 for ; Fri, 14 Sep 2012 16:22:25 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 5F20121F8476 for ; Fri, 14 Sep 2012 16:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=z+dB5/WRCYTLrgWtEiB01blwWACI2jjY3ECLqmK0EF8=; b=Kl/VgjP+iiX8Pd8ItmP2rTmtB1z9PevDk1oqcG5Op4xKyl3dOIxhhHONeboJXXNx9fZBQxZ66oWQwRpytNPAHwyuAOA1od65hYYB08THi1OLEQvf+jvOUuKqf/53YXNK; Received: from [12.31.178.2] (port=63298 helo=[172.17.119.135]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1TCfDK-0007IM-Gz for paws@ietf.org; Fri, 14 Sep 2012 18:22:22 -0500 Message-ID: <5053BC48.6040308@blindcreek.com> Date: Fri, 14 Sep 2012 16:22:48 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E4682475@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E4682475@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 23:22:26 -0000 On 9/14/2012 12:34 PM, Paul Lambert wrote: > I do not see why we are designing for "browser vendors" when we are developing protocols for radios. > As I've said before ... real protocols use TLVs > > It is possible to map JSON strucutures to TLVs for efficiency if anyone is interested ... Yes I'm interested. Ultimately for many TVWS devices in my world, the information provided by PAWS (be it XML or JSON) will be mapped to a compact binary representation that will look a lot like TLVs. -Ben > Paul > >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Zhulei >> Sent: Thursday, September 13, 2012 9:17 PM >> To: Gabor.Bajko@nokia.com; paws@ietf.org >> Subject: Re: [paws] JSON vs XML >> >> Hi, >> >> I really went through e-mail discussions on this. My proposal is to use >> json as data model of paws protocol issued by paws, in case that wg >> addresses the trend of APIs of browser venders and keep some discovery >> mechanisms open for any extra works. At the same time, we have some >> problems to satisfy the needs to reuse ws schema encoded by traditional >> devices, which will issue a separate wg document for xml encoding >> standard for xml supporting industries. >> >> The reasons doing this are not technical issues, just we have broad >> requirements to reuse TSWS generally for communication purposes, >> including smart objects, ad hoc use, browser API, wifi broadband, >> cellular etc. >> >> Best regards, >> Zhu Lei >> >> -----邮件原件----- >> 发件人: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] >> 发é€ć—¶é—´: 2012ĺą´9ćś14ć—Ą 7:40 >> 收件人: Zhulei; paws@ietf.org >> 主é˘: RE: JSON vs XML >> >> There was not much feedback on the list about the objections to the >> different encodings. >> >> We seem to agree that: >> xml may not be the right choice because the current trend for APIs in >> the browsers is towards json; and if we choose json, as some data >> structures PAWS may reuse are encoded in xml, a json encoding for >> those would need to be defined (which is not impossible, but requires >> some extra work) >> >> The latter of the two objections will not be valid when we'll send the >> document to iesg, as all the encodings will have to be in place at that >> time. >> So we are left with practically one question: do we want to follow the >> current industry trend and use json, or do we want to stick with xml. >> >> A significant number of people prefer to specify both encodings, but >> that may not be agreeable with the iesg. >> >> This is where we stand now, deadlocked on this not critical issue. >> >> Any suggestion on how to move forward would be appreciated. >> >> - Gabor >> >> >> From: ext Zhulei [mailto:lei.zhu@huawei.com] >> Sent: Monday, September 10, 2012 12:59 AM >> To: Bajko Gabor (Nokia-CIC/SiliconValley); paws@ietf.org >> Cc: Zhulei >> Subject: Re: JSON vs XML >> >> Hi, >> >> Actually, no so much comments on this choosing. I just do not think xml >> is a problem to embedded devices, in fact xml is well supported by >> different sort of devices in my view. The issue may be some power and >> bandwidth constrained devices (e.g. some smart objects) to support txt >> based information. Let’s ignore this case since we are not to define >> binary encoding at the moment. >> >> Best regards, >> Zhu Lei >> >> 发件人: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] 代表 >> Gabor.Bajko@nokia.com >> 发é€ć—¶é—´: 2012ĺą´9ćś8ć—Ą 4:41 >> 收件人: paws@ietf.org >> 主é˘: [paws] JSON vs XML >> >> The chairs discussed with the AD, and we came up with the following >> action plan to drive this wg to a consensus on the json vs xml >> encoding: >> we’ll collect an objections list for json and one for xml, listing what >> is seen wrong/problematic with that encoding. The chairs and the wg >> will go through that list and see if the objections are valid, then >> decide which encoding has more support and choose that one. If we end >> up with good objections list for both, we may choose to support both >> encodings, as that list will justify the decision once the document >> advances to the iesg. >> >> I went through the emails and I found so far the following valid >> objections: >> >> xml: >> too verbose, may be a problem to be supported in embedded devices >> current trend for APIs in the browsers is towards json >> >> >> >> json: >> some data structures are encoded in xml, a json encoding for those >> would need to be defined (which is not impossible, but requires some >> extra work) >> >> >> If you have additional objections, send them to the list asap. >> >> - Gabor >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Wed Sep 19 10:01:50 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32C121F8499 for ; Wed, 19 Sep 2012 10:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN5rAEImH2MQ for ; Wed, 19 Sep 2012 10:01:49 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5F64021F8648 for ; Wed, 19 Sep 2012 10:01:49 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JH1k6e009571 for ; Wed, 19 Sep 2012 20:01:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 20:01:46 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0309.003; Wed, 19 Sep 2012 19:01:45 +0200 From: To: Thread-Topic: [paws] PAWS security Thread-Index: AQHNjUaBXVfdMUhbQ7OY0lXuCEkQJ5eD4IlwgAB6rQD//4r34IAAfUcA//+LN1CAAAMcAIAABciBgAUBBiD//+UTgAEiv2Qw Date: Wed, 19 Sep 2012 17:01:44 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020321B6@008-AM1MPN1-006.mgdnok.nokia.com> References: <55A5A9A87506CB4BA580BF9D531957DA690227D5@STNTEXCH01.cis.neustar.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602029E09@008-AM1MPN1-006.mgdnok.nokia.com> <769679CF-1359-4B77-B82C-FC3DF3290135@neustar.biz> In-Reply-To: <769679CF-1359-4B77-B82C-FC3DF3290135@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.79.137.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Sep 2012 17:01:46.0512 (UTC) FILETIME=[73BD5900:01CD9688] X-Nokia-AV: Clean Subject: Re: [paws] PAWS security X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:01:50 -0000 I can sense an agreement on this topic, that we are going to only describe = the case when the master device has a cert issued by a trusted CA.=20 I would summarize the objections against describing using shared secrets as= we would also have to either define an automated key management mechanism = for those keys or explain why it is reasonable not to have such a mechanis= m. We likely would not be able to come up with an explanation (as required = by BCP107) in a way that will stand up to scrutiny of IESG. Therefore, I am inclined to instruct the editor to incorporate client cert = part into the merged document. - Gabor -----Original Message----- From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Thursday, September 13, 2012 5:07 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paul@marvell.com; Peter.McCann@huawei.com; peter@spectrumbridge.com; st= ephen.farrell@cs.tcd.ie; paws@ietf.org Subject: Re: [paws] PAWS security We can say that the security model for paws is PKI when authentication of t= he device is needed, with a provisioned cert signed by an entity the DB tru= sts. Whether it's preloaded by a manufacturer or provisioned by some other= mechanism doesn't need to be specified. This is my preference. I would prefer not to have any mention of shared secrets. There are no protocol police. If deployments decide to use shared secrets,= we can't stop them. Brian On Sep 13, 2012, at 8:00 PM, Gabor.Bajko@nokia.com wrote: > We in IETF cannot require a client cert to be installed in the device. Re= gulators may require it, and if they don't, the folks who deploy it may do = so. > What we can do in IETF is to decide to only specify how a device with a c= lient cert is authenticated, and not specify how a paws master device is au= thenticated with a shared secret. Is that what we want? >=20 > Having a client cert in the device would certainly not contradict with th= e current FCC requirement to have a prior relationship between the master a= nd the db. >=20 > The drawback I can see with not specifying the shared secret case is that= the lack of specifying the use of shared secrets will not prevent folks to= deploy it using shared secrets; which may lead to deployments with not sta= ndard variations. >=20 > - Gabor >=20 > -----Original Message----- > From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, September 10, 2012 12:18 PM > To: 'Paul Lambert'; 'Peter McCann'; 'Peter Stanforth'; 'Stephen=20 > Farrell'; Bajko Gabor (Nokia-CIC/SiliconValley) > Cc: 'paws@ietf.org' > Subject: RE: [paws] PAWS security >=20 > The easiest way to do this is to have the manufacturer put a cert in=20 > the device that it signs. Then the only thing the database needs is=20 > the public key of the manufacturer, >=20 > Why do we want to make this harder? >=20 > Because some manufacturers think its too much work to do that? >=20 > Brian >=20 >=20 >=20 > -----Original Message----- > From: Paul Lambert [mailto:paul@marvell.com] > Sent: Monday, September 10, 2012 03:15 PM Eastern Standard Time > To: Peter McCann; Peter Stanforth; Stephen Farrell; Gabor.Bajko@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] PAWS security >=20 >=20 >> This restriction may hold today for the FCC, but I have a hard time=20 >> believing that a pre-existing manufacturer-database relationship will=20 >> be mandatory in every regulatory domain for the forseeable future. I=20 >> think we should design to minimize the friction in changing database=20 >> providers. >=20 > The least friction would be to hardwire devices with a PK "root" for each= regulatory domain that the device supports. >=20 > Valid DBs would have credentials signed by the key holder of roots for=20 > each regulatory domain >=20 > Paul >=20 >=20 >> -Pete >>=20 >> Peter Stanforth wrote: >>> I completely agree with your statement below. If we are good any >> radio >>> will have the "Technical" capability to work with any database. >>> BUT, and this is a big BUT, the regulation may not allow it - The=20 >>> FCC does not today. And as a DBA I only want to work with devices=20 >>> where I have a predefined relationship. Not least of which, because=20 >>> as I am authorized by a Regulator I want to make sure I am doing=20 >>> everything I can to avoid their wrath. >>> This has come up before. PAWS is defining an API/Protocol, not the=20 >>> regulation nor the business cases at this time. So I still say that >> we >>> can comply with your statement without considering a "User". >>>=20 >>> On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" >>> wrote: >>>=20 >>>> This is a key question we need to answer. >>>>=20 >>>> I thought we were defining a protocol that would allow a radio from=20 >>>> any manufacturer to interoperate with a database of any database >> vendor. >>>>=20 >>>> -Pete >>>>=20 >>>> Peter Stanforth wrote: >>>>> Pete, I am not sure I believe in a use case where "users" move=20 >>>>> from one DB to another. The relationship is between the radio=20 >>>>> vendor and the DBA. The radio vendor may have multiple=20 >>>>> relationships and allow an end user to choose one, but it will be=20 >>>>> from the predefined >> list. >>>>> As a DBA I don't think I would want, and in the USA we are not=20 >>>>> permitted, to establish a relationship with a user without a=20 >>>>> preexisting relationship with the radio vendor. So security should=20 >>>>> be primarily a radio vendor-DBA issue. Wearing my DBA hat I don't=20 >>>>> think I would want to service a radio that I do not have a=20 >>>>> preexisting relationship with it's manufacturer. I am not sure >> that >>>>> user relationships are even within the scope of what PAWS should=20 >>>>> be >> defining. Peter S. >>>>>=20 >>>>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" >>>>> wrote: >>>>>=20 >>>>>> Personally, I think that manually provisioned symmetric keys will=20 >>>>>> severely limit the ability for users to flexibly move from one=20 >>>>>> database provider to another. It will require some secure=20 >>>>>> out-of-band channel on which to transmit the secret key from one=20 >>>>>> party to the other, and a mechanism for the user to push the >> secret >>>>>> key down into the master device. >>>>>>=20 >>>>>> Provisioning of certificates does not require the secret channel,=20 >>>>>> only one that is integrity protected. I think this is much=20 >>>>>> easier to achieve in practice. >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>> Stephen Farrell wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 09/07/2012 10:01 PM, Gabor.Bajko@nokia.com wrote:> At the=20 >>>>>>> Vancouver F2F we had extensive discussions on the security model=20 >>>>>>> for PAWS. Draft-das proposes to use shared secrets pre- >> provisioned >>>>>>> in the master devices for authentication, while draft-lei >> proposes >>>>>>> to mandate client certificates into master devices. >>>>>>>>=20 >>>>>>>> There seemed to be an understanding that the credential types=20 >>>>>>>> in >>>>> use >>>>>>> for authentication are a matter of a business model chosen by=20 >>>>>>> the provider which deploys white space devices, rather than a >> protocol >>>>>>> decision. >>>>>>>>=20 >>>>>>>> Brian mentioned that the iesg may not allow a document to be >>>>>>> published which specifies how shared secrets are used, but does=20 >>>>>>> not have a provisioning mechanism for the shared secrets defined. >>>>>>> In my opinion, a mechanism for distributing shared secrets does=20 >>>>>>> not necessarily have to be defined, as a shared secret can be=20 >>>>>>> established using current practices to set up shared secrets=20 >>>>>>> with financial institutions (using the browser). >>>>>>>> Thus, my suggestion would be to describe in the document how a=20 >>>>>>>> shared >>>>>>> secret and how a client certificate is used to authenticate a=20 >>>>>>> master device. Then, if we run into issues with iesg, in worst=20 >>>>>>> case we could remove the shared secret part and keep the other >> one. >>>>>>>>=20 >>>>>>>> I'd like to get additional views on this topic. >>>>>>>=20 >>>>>>> I can help a little here (depending on your definition of >>>>>>> help:-) >>>>>>>=20 >>>>>>> BCP 107 [1] is the one to look at when considering how to >> approach >>>>>>> automated key management requirements. That has an IMO very good >>>>>>> abstract: >>>>>>>=20 >>>>>>> The question often arises of whether a given security system >>>>>>> requires some form of automated key management, or whether >> manual >>>>>>> keying is sufficient. This memo provides guidelines for >> making >>>>>>> such decisions. When symmetric cryptographic mechanisms are >> used >>>>>>> in a protocol, the presumption is that automated key >> management >>>>>>> is generally but not always needed. If manual keying is=20 >>>>>>> proposed, >>> the >>>>>>> burden of proving that automated key management is not >> required >>>>>>> falls to the >>>>> proposer. >>>>>>> For those that might be less familiar with IETF processes, the=20 >>>>>>> fact that that's a BCP means that its entirely valid for an AD=20 >>>>>>> to strenuously push back against a WG that wants to ignore what=20 >>>>>>> it >> says. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> S. >>>>>>>=20 >>>>>>> PS: I've not read the drafts, and couldn't make the session in=20 >>>>>>> Vancouver, so this might be entirely off topic, but in the case >> of >>>>>>> PAWS I'd also argue that the regulators' apparent desire to=20 >>>>>>> force devices to authenticate is not necessarily the right one=20 >>>>>>> for the IETF to force upon all users of the PAWS protocol. So=20 >>>>>>> there could for example be a mode of operation where the DB=20 >>>>>>> signs stuff but doesn't care who's asking and that'd be a far=20 >>>>>>> far easier scenario in terms of automated key management. >>>>>>>=20 >>>>>>> [1] http://tools.ietf.org/html/bcp107=20 >>>>>>> _______________________________________________ paws mailing=20 >>>>>>> list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Wed Sep 19 10:09:33 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EE421F867E for ; Wed, 19 Sep 2012 10:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbCEWXI-2Ldy for ; Wed, 19 Sep 2012 10:09:33 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5A121F867C for ; Wed, 19 Sep 2012 10:09:32 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JH9Fqd004162; Wed, 19 Sep 2012 20:09:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 20:09:24 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0309.003; Wed, 19 Sep 2012 19:09:23 +0200 From: To: , Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhAALc8RHAACYgH0AEXCfvg Date: Wed, 19 Sep 2012 17:09:23 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> In-Reply-To: <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.79.137.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Sep 2012 17:09:24.0534 (UTC) FILETIME=[84BDF560:01CD9689] X-Nokia-AV: Clean Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:09:34 -0000 SSBjYW4gc2Vuc2UgYW4gYWdyZWVtZW50IHRoYXQgd2UgY2FuIGdvIGFoZWFkIGFuZCB1c2UganNv biBlbmNvZGluZyAob25seSkuDQoNCkkgd291bGQgdGhlbiBnbyBhaGVhZCBhbmQgaW5zdHJ1Y3Qg dGhlIGVkaXRvciB0byBlbmNvZGUgdGhlIGRhdGEgbW9kZWwgd2l0aCBqc29uIGluIHRoZSBtZXJn ZWQgZHJhZnQuDQoNCi0gR2Fib3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGV4dCBaaHVsZWkgW21haWx0bzpsZWkuemh1QGh1YXdlaS5jb21dIA0KU2VudDogVGh1cnNkYXks IFNlcHRlbWJlciAxMywgMjAxMiA5OjE3IFBNDQpUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9T aWxpY29uVmFsbGV5KTsgcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEpTT04gdnMgWE1MDQoN CkhpLA0KDQpJIHJlYWxseSB3ZW50IHRocm91Z2ggZS1tYWlsIGRpc2N1c3Npb25zIG9uIHRoaXMu IE15IHByb3Bvc2FsIGlzIHRvIHVzZSBqc29uIGFzIGRhdGEgbW9kZWwgb2YgcGF3cyBwcm90b2Nv bCBpc3N1ZWQgYnkgcGF3cywgaW4gY2FzZSB0aGF0IHdnIGFkZHJlc3NlcyB0aGUgdHJlbmQgb2Yg QVBJcyBvZiBicm93c2VyIHZlbmRlcnMgYW5kIGtlZXAgc29tZSBkaXNjb3ZlcnkgbWVjaGFuaXNt cyBvcGVuIGZvciBhbnkgZXh0cmEgd29ya3MuIEF0IHRoZSBzYW1lIHRpbWUsIHdlIGhhdmUgc29t ZSBwcm9ibGVtcyB0byBzYXRpc2Z5IHRoZSBuZWVkcyB0byByZXVzZSB3cyBzY2hlbWEgZW5jb2Rl ZCBieSB0cmFkaXRpb25hbCBkZXZpY2VzLCB3aGljaCB3aWxsIGlzc3VlIGEgc2VwYXJhdGUgd2cg ZG9jdW1lbnQgZm9yIHhtbCBlbmNvZGluZyBzdGFuZGFyZCBmb3IgeG1sIHN1cHBvcnRpbmcgaW5k dXN0cmllcy4NCg0KVGhlIHJlYXNvbnMgZG9pbmcgdGhpcyBhcmUgbm90IHRlY2huaWNhbCBpc3N1 ZXMsIGp1c3Qgd2UgaGF2ZSBicm9hZCByZXF1aXJlbWVudHMgdG8gcmV1c2UgVFNXUyBnZW5lcmFs bHkgZm9yIGNvbW11bmljYXRpb24gcHVycG9zZXMsIGluY2x1ZGluZyBzbWFydCBvYmplY3RzLCBh ZCBob2MgdXNlLCBicm93c2VyIEFQSSwgd2lmaSBicm9hZGJhbmQsIGNlbGx1bGFyIGV0Yy4gDQoN CkJlc3QgcmVnYXJkcywNClpodSBMZWkNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu2 5Lq6OiBHYWJvci5CYWprb0Bub2tpYS5jb20gW21haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb21d DQrlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTTml6UgNzo0MA0K5pS25Lu25Lq6OiBaaHVsZWk7 IHBhd3NAaWV0Zi5vcmcNCuS4u+mimDogUkU6IEpTT04gdnMgWE1MDQoNClRoZXJlIHdhcyBub3Qg bXVjaCBmZWVkYmFjayBvbiB0aGUgbGlzdCBhYm91dCB0aGUgb2JqZWN0aW9ucyB0byB0aGUgZGlm ZmVyZW50IGVuY29kaW5ncy4NCg0KV2Ugc2VlbSB0byBhZ3JlZSB0aGF0Og0KeG1sIG1heSBub3Qg YmUgdGhlIHJpZ2h0IGNob2ljZSBiZWNhdXNlIHRoZSBjdXJyZW50IHRyZW5kIGZvciBBUElzIGlu IHRoZSBicm93c2VycyBpcyB0b3dhcmRzIGpzb247IGFuZCBpZiB3ZSBjaG9vc2UgIGpzb24sIGFz IHNvbWUgZGF0YSBzdHJ1Y3R1cmVzIFBBV1MgbWF5IHJldXNlIGFyZSAgZW5jb2RlZCBpbiB4bWws IGEganNvbiBlbmNvZGluZyBmb3IgdGhvc2Ugd291bGQgbmVlZCB0byBiZSBkZWZpbmVkICh3aGlj aCBpcyBub3QgaW1wb3NzaWJsZSwgYnV0IHJlcXVpcmVzIHNvbWUgZXh0cmEgd29yaykNCg0KVGhl IGxhdHRlciBvZiB0aGUgdHdvIG9iamVjdGlvbnMgd2lsbCBub3QgYmUgdmFsaWQgd2hlbiB3ZSds bCBzZW5kIHRoZSBkb2N1bWVudCB0byBpZXNnLCBhcyBhbGwgdGhlIGVuY29kaW5ncyB3aWxsIGhh dmUgdG8gYmUgaW4gcGxhY2UgYXQgdGhhdCB0aW1lLg0KU28gd2UgYXJlIGxlZnQgd2l0aCBwcmFj dGljYWxseSBvbmUgcXVlc3Rpb246IGRvIHdlIHdhbnQgdG8gZm9sbG93IHRoZSBjdXJyZW50IGlu ZHVzdHJ5IHRyZW5kIGFuZCB1c2UganNvbiwgb3IgZG8gd2Ugd2FudCB0byBzdGljayB3aXRoIHht bC4NCg0KQSBzaWduaWZpY2FudCBudW1iZXIgb2YgcGVvcGxlIHByZWZlciB0byBzcGVjaWZ5IGJv dGggZW5jb2RpbmdzLCBidXQgdGhhdCBtYXkgbm90IGJlIGFncmVlYWJsZSB3aXRoIHRoZSBpZXNn Lg0KDQpUaGlzIGlzIHdoZXJlIHdlIHN0YW5kIG5vdywgZGVhZGxvY2tlZCBvbiB0aGlzIG5vdCBj cml0aWNhbCBpc3N1ZS4NCg0KQW55IHN1Z2dlc3Rpb24gb24gaG93IHRvIG1vdmUgZm9yd2FyZCB3 b3VsZCBiZSBhcHByZWNpYXRlZC4NCg0KLSBHYWJvcg0KDQoNCkZyb206IGV4dCBaaHVsZWkgW21h aWx0bzpsZWkuemh1QGh1YXdlaS5jb21dDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAx MiAxMjo1OSBBTQ0KVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSk7IHBh d3NAaWV0Zi5vcmcNCkNjOiBaaHVsZWkNClN1YmplY3Q6IFJlOiBKU09OIHZzIFhNTA0KDQpIaSwN Cg0KQWN0dWFsbHksIG5vIHNvIG11Y2ggY29tbWVudHMgb24gdGhpcyBjaG9vc2luZy4gSSBqdXN0 IGRvIG5vdCB0aGluayB4bWwgaXMgYSBwcm9ibGVtIHRvIGVtYmVkZGVkIGRldmljZXMsIGluIGZh Y3QgeG1sIGlzIHdlbGwgc3VwcG9ydGVkIGJ5IGRpZmZlcmVudCBzb3J0IG9mIGRldmljZXMgaW4g bXkgdmlldy4gVGhlIGlzc3VlIG1heSBiZSBzb21lIHBvd2VyIGFuZCBiYW5kd2lkdGggY29uc3Ry YWluZWQgZGV2aWNlcyAoZS5nLiBzb21lIHNtYXJ0IG9iamVjdHMpIHRvIHN1cHBvcnQgdHh0IGJh c2VkIGluZm9ybWF0aW9uLiBMZXTigJlzIGlnbm9yZSB0aGlzIGNhc2Ugc2luY2Ugd2UgYXJlIG5v dCB0byBkZWZpbmUgYmluYXJ5IGVuY29kaW5nIGF0IHRoZSBtb21lbnQuIA0KDQpCZXN0IHJlZ2Fy ZHMsDQpaaHUgTGVpDQoNCuWPkeS7tuS6ujogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggR2Fib3IuQmFqa29Abm9raWEuY29tDQrlj5Hp gIHml7bpl7Q6IDIwMTLlubQ55pyIOOaXpSA0OjQxDQrmlLbku7bkuro6IHBhd3NAaWV0Zi5vcmcN CuS4u+mimDogW3Bhd3NdIEpTT04gdnMgWE1MDQoNClRoZSBjaGFpcnMgZGlzY3Vzc2VkIHdpdGgg dGhlIEFELCBhbmQgd2UgY2FtZSB1cCB3aXRoIHRoZSBmb2xsb3dpbmcgYWN0aW9uIHBsYW4gdG8g ZHJpdmUgdGhpcyB3ZyB0byBhIGNvbnNlbnN1cyBvbiB0aGUganNvbiB2cyB4bWwgZW5jb2Rpbmc6 DQp3ZeKAmWxsIGNvbGxlY3QgYW4gb2JqZWN0aW9ucyBsaXN0IGZvciBqc29uIGFuZCBvbmUgZm9y IHhtbCwgbGlzdGluZyB3aGF0IGlzIHNlZW4gd3JvbmcvcHJvYmxlbWF0aWMgd2l0aCB0aGF0IGVu Y29kaW5nLiBUaGUgY2hhaXJzIGFuZCB0aGUgd2cgd2lsbCBnbyB0aHJvdWdoIHRoYXQgbGlzdCBh bmQgc2VlIGlmIHRoZSBvYmplY3Rpb25zIGFyZSB2YWxpZCwgdGhlbiBkZWNpZGUgd2hpY2ggZW5j b2RpbmcgaGFzIG1vcmUgc3VwcG9ydCBhbmQgY2hvb3NlIHRoYXQgb25lLiBJZiB3ZSBlbmQgdXAg d2l0aCBnb29kIG9iamVjdGlvbnMgbGlzdCBmb3IgYm90aCwgd2UgbWF5IGNob29zZSB0byBzdXBw b3J0IGJvdGggZW5jb2RpbmdzLCBhcyB0aGF0IGxpc3Qgd2lsbCBqdXN0aWZ5IHRoZSBkZWNpc2lv biBvbmNlIHRoZSBkb2N1bWVudCBhZHZhbmNlcyB0byB0aGUgaWVzZy4NCg0KSSB3ZW50IHRocm91 Z2ggdGhlIGVtYWlscyBhbmQgSSBmb3VuZCBzbyBmYXIgdGhlIGZvbGxvd2luZyB2YWxpZCBvYmpl Y3Rpb25zOg0KDQp4bWw6IA0KdG9vIHZlcmJvc2UsIG1heSBiZSBhIHByb2JsZW0gdG8gYmUgc3Vw cG9ydGVkIGluIGVtYmVkZGVkIGRldmljZXMgY3VycmVudCB0cmVuZCBmb3IgQVBJcyBpbiB0aGUg YnJvd3NlcnMgaXMgdG93YXJkcyBqc29uDQoNCg0KDQpqc29uOg0Kc29tZSBkYXRhIHN0cnVjdHVy ZXMgYXJlwqAgZW5jb2RlZCBpbiB4bWwsIGEganNvbiBlbmNvZGluZyBmb3IgdGhvc2Ugd291bGQg bmVlZCB0byBiZSBkZWZpbmVkICh3aGljaCBpcyBub3QgaW1wb3NzaWJsZSwgYnV0IHJlcXVpcmVz IHNvbWUgZXh0cmEgd29yaykNCg0KDQpJZiB5b3UgaGF2ZSBhZGRpdGlvbmFsIG9iamVjdGlvbnMs IHNlbmQgdGhlbSB0byB0aGUgbGlzdCBhc2FwLg0KDQotIEdhYm9yDQo= From Peter.McCann@huawei.com Wed Sep 19 10:20:47 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D9621F8688 for ; Wed, 19 Sep 2012 10:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-ttPxcNIWYw for ; Wed, 19 Sep 2012 10:20:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 131BD21F8678 for ; Wed, 19 Sep 2012 10:20:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKV21039; Wed, 19 Sep 2012 17:20:44 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Sep 2012 18:18:09 +0100 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Sep 2012 18:18:39 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.151]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 19 Sep 2012 10:18:32 -0700 From: Peter McCann To: "Gabor.Bajko@nokia.com" , Zhulei , "paws@ietf.org" Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhAALc8RHAACYgH0AEXCfvgAAB8ZfA= Date: Wed, 19 Sep 2012 17:18:31 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E2C010@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:20:47 -0000 U2hvdWxkIHdlIHNwbGl0IG9mZiB0aGUgSlNPTiBlbmNvZGluZ3Mgb2YgZ2VvZ3JhcGhpYyBsb2Nh dGlvbnMgYW5kIGNvbnRhY3QNCmluZm9ybWF0aW9uIGludG8gc2VwYXJhdGUgZG9jdW1lbnRzLCBz byB0aGV5IGNhbiBiZSByZS11c2VkIGJ5IG90aGVycz8NCg0KU2hvdWxkIHdlIHVyZ2UgRUNSSVQg KG9yIHNvbWUgb3RoZXIgd29ya2luZyBncm91cCkgdG8gcmUtc3BlY2lmeSBMb1NUDQppbiBKU09O IGVuY29kaW5nPyAgT3Igc2hvdWxkIHdlIGRvIHRoZSBlcXVpdmFsZW50IHdvcmsgaGVyZSBpbiBQ QVdTPw0KDQotUGV0ZQ0KDQpHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+IEkgY2FuIHNl bnNlIGFuIGFncmVlbWVudCB0aGF0IHdlIGNhbiBnbyBhaGVhZCBhbmQgdXNlIGpzb24gZW5jb2Rp bmcNCj4gKG9ubHkpLg0KPiANCj4gSSB3b3VsZCB0aGVuIGdvIGFoZWFkIGFuZCBpbnN0cnVjdCB0 aGUgZWRpdG9yIHRvIGVuY29kZSB0aGUgZGF0YSBtb2RlbA0KPiB3aXRoIGpzb24gaW4gdGhlIG1l cmdlZCBkcmFmdC4NCj4gDQo+IC0gR2Fib3INCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGV4dCBaaHVsZWkgW21haWx0bzpsZWkuemh1QGh1YXdlaS5jb21dDQo+IFNl bnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTIgOToxNyBQTQ0KPiBUbzogQmFqa28gR2Fi b3IgKE5va2lhLUNJQy9TaWxpY29uVmFsbGV5KTsgcGF3c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogSlNPTiB2cyBYTUwNCj4gDQo+IEhpLA0KPiANCj4gSSByZWFsbHkgd2VudCB0aHJvdWdoIGUt bWFpbCBkaXNjdXNzaW9ucyBvbiB0aGlzLiBNeSBwcm9wb3NhbCBpcyB0bw0KPiB1c2UganNvbiBh cyBkYXRhIG1vZGVsIG9mIHBhd3MgcHJvdG9jb2wgaXNzdWVkIGJ5IHBhd3MsIGluIGNhc2UgdGhh dA0KPiB3ZyBhZGRyZXNzZXMgdGhlIHRyZW5kIG9mIEFQSXMgb2YgYnJvd3NlciB2ZW5kZXJzIGFu ZCBrZWVwIHNvbWUNCj4gZGlzY292ZXJ5IG1lY2hhbmlzbXMgb3BlbiBmb3IgYW55IGV4dHJhIHdv cmtzLiBBdCB0aGUgc2FtZSB0aW1lLCB3ZQ0KPiBoYXZlIHNvbWUgcHJvYmxlbXMgdG8gc2F0aXNm eSB0aGUgbmVlZHMgdG8gcmV1c2Ugd3Mgc2NoZW1hIGVuY29kZWQgYnkNCj4gdHJhZGl0aW9uYWwg ZGV2aWNlcywgd2hpY2ggd2lsbCBpc3N1ZSBhIHNlcGFyYXRlIHdnIGRvY3VtZW50IGZvciB4bWwN Cj4gZW5jb2Rpbmcgc3RhbmRhcmQgZm9yIHhtbCBzdXBwb3J0aW5nIGluZHVzdHJpZXMuDQo+IA0K PiBUaGUgcmVhc29ucyBkb2luZyB0aGlzIGFyZSBub3QgdGVjaG5pY2FsIGlzc3VlcywganVzdCB3 ZSBoYXZlIGJyb2FkDQo+IHJlcXVpcmVtZW50cyB0byByZXVzZSBUU1dTIGdlbmVyYWxseSBmb3Ig Y29tbXVuaWNhdGlvbiBwdXJwb3NlcywNCj4gaW5jbHVkaW5nIHNtYXJ0IG9iamVjdHMsIGFkIGhv YyB1c2UsIGJyb3dzZXIgQVBJLCB3aWZpIGJyb2FkYmFuZCwNCj4gY2VsbHVsYXIgZXRjLg0KPiAN Cj4gQmVzdCByZWdhcmRzLA0KPiBaaHUgTGVpDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0t DQo+IOWPkeS7tuS6ujogR2Fib3IuQmFqa29Abm9raWEuY29tIFttYWlsdG86R2Fib3IuQmFqa29A bm9raWEuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTTml6UgNzo0MA0KPiDmlLbk u7bkuro6IFpodWxlaTsgcGF3c0BpZXRmLm9yZw0KPiDkuLvpopg6IFJFOiBKU09OIHZzIFhNTA0K PiANCj4gVGhlcmUgd2FzIG5vdCBtdWNoIGZlZWRiYWNrIG9uIHRoZSBsaXN0IGFib3V0IHRoZSBv YmplY3Rpb25zIHRvIHRoZQ0KPiBkaWZmZXJlbnQgZW5jb2RpbmdzLg0KPiANCj4gV2Ugc2VlbSB0 byBhZ3JlZSB0aGF0Og0KPiB4bWwgbWF5IG5vdCBiZSB0aGUgcmlnaHQgY2hvaWNlIGJlY2F1c2Ug dGhlIGN1cnJlbnQgdHJlbmQgZm9yIEFQSXMgaW4NCj4gdGhlIGJyb3dzZXJzIGlzIHRvd2FyZHMg anNvbjsgYW5kIGlmIHdlIGNob29zZSAganNvbiwgYXMgc29tZSBkYXRhDQo+IHN0cnVjdHVyZXMg UEFXUyBtYXkgcmV1c2UgYXJlICBlbmNvZGVkIGluIHhtbCwgYSBqc29uIGVuY29kaW5nIGZvcg0K PiB0aG9zZSB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQgKHdoaWNoIGlzIG5vdCBpbXBvc3NpYmxl LCBidXQgcmVxdWlyZXMNCj4gc29tZSBleHRyYSB3b3JrKQ0KPiANCj4gVGhlIGxhdHRlciBvZiB0 aGUgdHdvIG9iamVjdGlvbnMgd2lsbCBub3QgYmUgdmFsaWQgd2hlbiB3ZSdsbCBzZW5kIHRoZQ0K PiBkb2N1bWVudCB0byBpZXNnLCBhcyBhbGwgdGhlIGVuY29kaW5ncyB3aWxsIGhhdmUgdG8gYmUg aW4gcGxhY2UgYXQNCj4gdGhhdCB0aW1lLg0KPiBTbyB3ZSBhcmUgbGVmdCB3aXRoIHByYWN0aWNh bGx5IG9uZSBxdWVzdGlvbjogZG8gd2Ugd2FudCB0byBmb2xsb3cgdGhlDQo+IGN1cnJlbnQgaW5k dXN0cnkgdHJlbmQgYW5kIHVzZSBqc29uLCBvciBkbyB3ZSB3YW50IHRvIHN0aWNrIHdpdGggeG1s Lg0KPiANCj4gQSBzaWduaWZpY2FudCBudW1iZXIgb2YgcGVvcGxlIHByZWZlciB0byBzcGVjaWZ5 IGJvdGggZW5jb2RpbmdzLCBidXQNCj4gdGhhdCBtYXkgbm90IGJlIGFncmVlYWJsZSB3aXRoIHRo ZSBpZXNnLg0KPiANCj4gVGhpcyBpcyB3aGVyZSB3ZSBzdGFuZCBub3csIGRlYWRsb2NrZWQgb24g dGhpcyBub3QgY3JpdGljYWwgaXNzdWUuDQo+IA0KPiBBbnkgc3VnZ2VzdGlvbiBvbiBob3cgdG8g bW92ZSBmb3J3YXJkIHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0KPiANCj4gLSBHYWJvcg0KPiANCj4g DQo+IEZyb206IGV4dCBaaHVsZWkgW21haWx0bzpsZWkuemh1QGh1YXdlaS5jb21dDQo+IFNlbnQ6 IE1vbmRheSwgU2VwdGVtYmVyIDEwLCAyMDEyIDEyOjU5IEFNDQo+IFRvOiBCYWprbyBHYWJvciAo Tm9raWEtQ0lDL1NpbGljb25WYWxsZXkpOyBwYXdzQGlldGYub3JnDQo+IENjOiBaaHVsZWkNCj4g U3ViamVjdDogUmU6IEpTT04gdnMgWE1MDQo+IA0KPiBIaSwNCj4gDQo+IEFjdHVhbGx5LCBubyBz byBtdWNoIGNvbW1lbnRzIG9uIHRoaXMgY2hvb3NpbmcuIEkganVzdCBkbyBub3QgdGhpbmsNCj4g eG1sIGlzIGEgcHJvYmxlbSB0byBlbWJlZGRlZCBkZXZpY2VzLCBpbiBmYWN0IHhtbCBpcyB3ZWxs IHN1cHBvcnRlZCBieQ0KPiBkaWZmZXJlbnQgc29ydCBvZiBkZXZpY2VzIGluIG15IHZpZXcuIFRo ZSBpc3N1ZSBtYXkgYmUgc29tZSBwb3dlciBhbmQNCj4gYmFuZHdpZHRoIGNvbnN0cmFpbmVkIGRl dmljZXMgKGUuZy4gc29tZSBzbWFydCBvYmplY3RzKSB0byBzdXBwb3J0IHR4dA0KPiBiYXNlZCBp bmZvcm1hdGlvbi4gTGV04oCZcyBpZ25vcmUgdGhpcyBjYXNlIHNpbmNlIHdlIGFyZSBub3QgdG8g ZGVmaW5lDQo+IGJpbmFyeSBlbmNvZGluZyBhdCB0aGUgbW9tZW50Lg0KPiANCj4gQmVzdCByZWdh cmRzLA0KPiBaaHUgTGVpDQo+IA0KPiDlj5Hku7bkuro6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQo+IEdhYm9yLkJhamtvQG5va2lh LmNvbSDlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIOOaXpSA0OjQxIOaUtuS7tuS6ujogcGF3c0Bp ZXRmLm9yZyDkuLvpopg6IFtwYXdzXQ0KPiBKU09OIHZzIFhNTA0KPiANCj4gVGhlIGNoYWlycyBk aXNjdXNzZWQgd2l0aCB0aGUgQUQsIGFuZCB3ZSBjYW1lIHVwIHdpdGggdGhlIGZvbGxvd2luZw0K PiBhY3Rpb24gcGxhbiB0byBkcml2ZSB0aGlzIHdnIHRvIGEgY29uc2Vuc3VzIG9uIHRoZSBqc29u IHZzIHhtbCBlbmNvZGluZzoNCj4gd2XigJlsbCBjb2xsZWN0IGFuIG9iamVjdGlvbnMgbGlzdCBm b3IganNvbiBhbmQgb25lIGZvciB4bWwsIGxpc3Rpbmcgd2hhdA0KPiBpcyBzZWVuIHdyb25nL3By b2JsZW1hdGljIHdpdGggdGhhdCBlbmNvZGluZy4gVGhlIGNoYWlycyBhbmQgdGhlIHdnIHdpbGwN Cj4gZ28gdGhyb3VnaCB0aGF0IGxpc3QgYW5kIHNlZSBpZiB0aGUgb2JqZWN0aW9ucyBhcmUgdmFs aWQsIHRoZW4gZGVjaWRlDQo+IHdoaWNoIGVuY29kaW5nIGhhcyBtb3JlIHN1cHBvcnQgYW5kIGNo b29zZSB0aGF0IG9uZS4gSWYgd2UgZW5kIHVwIHdpdGgNCj4gZ29vZCBvYmplY3Rpb25zIGxpc3Qg Zm9yIGJvdGgsIHdlIG1heSBjaG9vc2UgdG8gc3VwcG9ydCBib3RoIGVuY29kaW5ncywNCj4gYXMg dGhhdCBsaXN0IHdpbGwganVzdGlmeSB0aGUgZGVjaXNpb24gb25jZSB0aGUgZG9jdW1lbnQgYWR2 YW5jZXMgdG8gdGhlDQo+IGllc2cuDQo+IA0KPiBJIHdlbnQgdGhyb3VnaCB0aGUgZW1haWxzIGFu ZCBJIGZvdW5kIHNvIGZhciB0aGUgZm9sbG93aW5nIHZhbGlkDQo+IG9iamVjdGlvbnM6DQo+IA0K PiB4bWw6DQo+IHRvbyB2ZXJib3NlLCBtYXkgYmUgYSBwcm9ibGVtIHRvIGJlIHN1cHBvcnRlZCBp biBlbWJlZGRlZCBkZXZpY2VzDQo+IGN1cnJlbnQgdHJlbmQgZm9yIEFQSXMgaW4gdGhlIGJyb3dz ZXJzIGlzIHRvd2FyZHMganNvbg0KPiANCj4gDQo+IA0KPiBqc29uOg0KPiBzb21lIGRhdGEgc3Ry dWN0dXJlcyBhcmXCoCBlbmNvZGVkIGluIHhtbCwgYSBqc29uIGVuY29kaW5nIGZvciB0aG9zZQ0K PiB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQgKHdoaWNoIGlzIG5vdCBpbXBvc3NpYmxlLCBidXQg cmVxdWlyZXMgc29tZQ0KPiBleHRyYSB3b3JrKQ0KPiANCj4gDQo+IElmIHlvdSBoYXZlIGFkZGl0 aW9uYWwgb2JqZWN0aW9ucywgc2VuZCB0aGVtIHRvIHRoZSBsaXN0IGFzYXAuDQo+IA0KPiAtIEdh Ym9yDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHBhd3MgbWFpbGluZyBsaXN0DQo+IHBhd3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQo= From Gabor.Bajko@nokia.com Wed Sep 19 13:19:03 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173921E8064 for ; Wed, 19 Sep 2012 13:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+pSy6qJKWJL for ; Wed, 19 Sep 2012 13:19:03 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E0D1721F84CE for ; Wed, 19 Sep 2012 13:19:02 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8JKItAw004711 for ; Wed, 19 Sep 2012 23:18:58 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Sep 2012 23:18:57 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0309.003; Wed, 19 Sep 2012 22:18:56 +0200 From: To: Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhAALc8RHAACYgH0AEXCfvgAAB8ZfAABeN+kA== Date: Wed, 19 Sep 2012 20:18:56 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020322A9@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E2C010@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2C010@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.79.137.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Sep 2012 20:18:57.0696 (UTC) FILETIME=[FFACC200:01CD96A3] X-Nokia-AV: Clean Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 20:19:04 -0000 SW5saW5lOg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IFBldGVyIE1j Q2FubiBbbWFpbHRvOlBldGVyLk1jQ2FubkBodWF3ZWkuY29tXSANClNlbnQ6IFdlZG5lc2RheSwg U2VwdGVtYmVyIDE5LCAyMDEyIDEwOjE5IEFNDQpUbzogQmFqa28gR2Fib3IgKE5va2lhLUNJQy9T aWxpY29uVmFsbGV5KTsgWmh1bGVpOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogSlNPTiB2 cyBYTUwNCg0KU2hvdWxkIHdlIHNwbGl0IG9mZiB0aGUgSlNPTiBlbmNvZGluZ3Mgb2YgZ2VvZ3Jh cGhpYyBsb2NhdGlvbnMgYW5kIGNvbnRhY3QgaW5mb3JtYXRpb24gaW50byBzZXBhcmF0ZSBkb2N1 bWVudHMsIHNvIHRoZXkgY2FuIGJlIHJlLXVzZWQgYnkgb3RoZXJzPw0KPEdhYm9yPiBZZXMsIEkg dGhpbmsgdGhhdCB3b3VsZCBtYWtlIGEgbG90IG9mIHNlbnNlLiBXZSBuZWVkIHRvIGlkZW50aWZ5 IHRoZSBkYXRhIHN0cnVjdHVyZXMgd2Ugd2FudCB0byByZS11c2UgaW4gcGF3cywgYW5kIGl0IGlz IG5vdCBvbmx5IHRoZSBsb2NhdGlvbiBvbmVzLCBidXQgcG9zc2libHkgb3RoZXIgc3R1ZmYgbGlr ZSB2Q2FyZCwgaUNhbCwgZXRjLiBJJ2xsIHRyeSB0byBwdXQgdG9nZXRoZXIgYSBwb3RlbnRpYWwg bGlzdCBvZiBkYXRhIHN0cnVjdHVyZXMgcGF3cyBtYXkgd2FudCB0byByZXVzZSwgaW4gdGhlIG5l eHQgY291cGxlIG9mIGRheXMuIFdlIHdpbGwgdGhlbiBqdXN0IG5lZWQgc29tZSB2b2x1bnRlZXJz IHdobyBjb3VsZCB3cml0ZSB1cCB0aGUganNvbiBlbmNvZGluZyBvZiB0aG9zZSBkYXRhIHN0cnVj dHVyZXMuDQoNClNob3VsZCB3ZSB1cmdlIEVDUklUIChvciBzb21lIG90aGVyIHdvcmtpbmcgZ3Jv dXApIHRvIHJlLXNwZWNpZnkgTG9TVCBpbiBKU09OIGVuY29kaW5nPyAgT3Igc2hvdWxkIHdlIGRv IHRoZSBlcXVpdmFsZW50IHdvcmsgaGVyZSBpbiBQQVdTPw0KPEdhYm9yPiBXZSBkbyBub3QgaGF2 ZSBhIGZvcm1hbCBkZWNpc2lvbiBpbiB0aGlzIFdHIG9uIGhvdyB0byBkbyBEQiBkaXNjb3Zlcnkg eWV0LCB3aGV0aGVyIHdlIHVzZSBMb1NUIG9yIHNnIGVsc2UuIExldCdzIGhhdmUgc29tZSBtb3Jl IGRpc2N1c3Npb24gb24gREIgZGlzY292ZXJ5IGZpcnN0LCBhbmQgb25jZSB3ZSBrbm93IGhvdyB0 byBkbyBkaXNjb3ZlcnksIHdlIGNhbiBjb21lIGJhY2sgdG8gdGhpcyBxdWVzdGlvbi4NCg0KLSBH YWJvcg0KDQotUGV0ZQ0KDQpHYWJvci5CYWprb0Bub2tpYS5jb20gd3JvdGU6DQo+IEkgY2FuIHNl bnNlIGFuIGFncmVlbWVudCB0aGF0IHdlIGNhbiBnbyBhaGVhZCBhbmQgdXNlIGpzb24gZW5jb2Rp bmcgDQo+IChvbmx5KS4NCj4gDQo+IEkgd291bGQgdGhlbiBnbyBhaGVhZCBhbmQgaW5zdHJ1Y3Qg dGhlIGVkaXRvciB0byBlbmNvZGUgdGhlIGRhdGEgbW9kZWwgDQo+IHdpdGgganNvbiBpbiB0aGUg bWVyZ2VkIGRyYWZ0Lg0KPiANCj4gLSBHYWJvcg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogZXh0IFpodWxlaSBbbWFpbHRvOmxlaS56aHVAaHVhd2VpLmNvbV0NCj4g U2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxMywgMjAxMiA5OjE3IFBNDQo+IFRvOiBCYWprbyBH YWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpOyBwYXdzQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBKU09OIHZzIFhNTA0KPiANCj4gSGksDQo+IA0KPiBJIHJlYWxseSB3ZW50IHRocm91Z2gg ZS1tYWlsIGRpc2N1c3Npb25zIG9uIHRoaXMuIE15IHByb3Bvc2FsIGlzIHRvIA0KPiB1c2UganNv biBhcyBkYXRhIG1vZGVsIG9mIHBhd3MgcHJvdG9jb2wgaXNzdWVkIGJ5IHBhd3MsIGluIGNhc2Ug dGhhdCANCj4gd2cgYWRkcmVzc2VzIHRoZSB0cmVuZCBvZiBBUElzIG9mIGJyb3dzZXIgdmVuZGVy cyBhbmQga2VlcCBzb21lIA0KPiBkaXNjb3ZlcnkgbWVjaGFuaXNtcyBvcGVuIGZvciBhbnkgZXh0 cmEgd29ya3MuIEF0IHRoZSBzYW1lIHRpbWUsIHdlIA0KPiBoYXZlIHNvbWUgcHJvYmxlbXMgdG8g c2F0aXNmeSB0aGUgbmVlZHMgdG8gcmV1c2Ugd3Mgc2NoZW1hIGVuY29kZWQgYnkgDQo+IHRyYWRp dGlvbmFsIGRldmljZXMsIHdoaWNoIHdpbGwgaXNzdWUgYSBzZXBhcmF0ZSB3ZyBkb2N1bWVudCBm b3IgeG1sIA0KPiBlbmNvZGluZyBzdGFuZGFyZCBmb3IgeG1sIHN1cHBvcnRpbmcgaW5kdXN0cmll cy4NCj4gDQo+IFRoZSByZWFzb25zIGRvaW5nIHRoaXMgYXJlIG5vdCB0ZWNobmljYWwgaXNzdWVz LCBqdXN0IHdlIGhhdmUgYnJvYWQgDQo+IHJlcXVpcmVtZW50cyB0byByZXVzZSBUU1dTIGdlbmVy YWxseSBmb3IgY29tbXVuaWNhdGlvbiBwdXJwb3NlcywgDQo+IGluY2x1ZGluZyBzbWFydCBvYmpl Y3RzLCBhZCBob2MgdXNlLCBicm93c2VyIEFQSSwgd2lmaSBicm9hZGJhbmQsIA0KPiBjZWxsdWxh ciBldGMuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFpodSBMZWkNCj4gDQo+IC0tLS0t6YKu5Lu2 5Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBHYWJvci5CYWprb0Bub2tpYS5jb20gW21haWx0bzpH YWJvci5CYWprb0Bub2tpYS5jb21dDQo+IOWPkemAgeaXtumXtDogMjAxMuW5tDnmnIgxNOaXpSA3 OjQwDQo+IOaUtuS7tuS6ujogWmh1bGVpOyBwYXdzQGlldGYub3JnDQo+IOS4u+mimDogUkU6IEpT T04gdnMgWE1MDQo+IA0KPiBUaGVyZSB3YXMgbm90IG11Y2ggZmVlZGJhY2sgb24gdGhlIGxpc3Qg YWJvdXQgdGhlIG9iamVjdGlvbnMgdG8gdGhlIA0KPiBkaWZmZXJlbnQgZW5jb2RpbmdzLg0KPiAN Cj4gV2Ugc2VlbSB0byBhZ3JlZSB0aGF0Og0KPiB4bWwgbWF5IG5vdCBiZSB0aGUgcmlnaHQgY2hv aWNlIGJlY2F1c2UgdGhlIGN1cnJlbnQgdHJlbmQgZm9yIEFQSXMgaW4gDQo+IHRoZSBicm93c2Vy cyBpcyB0b3dhcmRzIGpzb247IGFuZCBpZiB3ZSBjaG9vc2UgIGpzb24sIGFzIHNvbWUgZGF0YSAN Cj4gc3RydWN0dXJlcyBQQVdTIG1heSByZXVzZSBhcmUgIGVuY29kZWQgaW4geG1sLCBhIGpzb24g ZW5jb2RpbmcgZm9yIA0KPiB0aG9zZSB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQgKHdoaWNoIGlz IG5vdCBpbXBvc3NpYmxlLCBidXQgcmVxdWlyZXMgDQo+IHNvbWUgZXh0cmEgd29yaykNCj4gDQo+ IFRoZSBsYXR0ZXIgb2YgdGhlIHR3byBvYmplY3Rpb25zIHdpbGwgbm90IGJlIHZhbGlkIHdoZW4g d2UnbGwgc2VuZCB0aGUgDQo+IGRvY3VtZW50IHRvIGllc2csIGFzIGFsbCB0aGUgZW5jb2Rpbmdz IHdpbGwgaGF2ZSB0byBiZSBpbiBwbGFjZSBhdCANCj4gdGhhdCB0aW1lLg0KPiBTbyB3ZSBhcmUg bGVmdCB3aXRoIHByYWN0aWNhbGx5IG9uZSBxdWVzdGlvbjogZG8gd2Ugd2FudCB0byBmb2xsb3cg dGhlIA0KPiBjdXJyZW50IGluZHVzdHJ5IHRyZW5kIGFuZCB1c2UganNvbiwgb3IgZG8gd2Ugd2Fu dCB0byBzdGljayB3aXRoIHhtbC4NCj4gDQo+IEEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIHBlb3Bs ZSBwcmVmZXIgdG8gc3BlY2lmeSBib3RoIGVuY29kaW5ncywgYnV0IA0KPiB0aGF0IG1heSBub3Qg YmUgYWdyZWVhYmxlIHdpdGggdGhlIGllc2cuDQo+IA0KPiBUaGlzIGlzIHdoZXJlIHdlIHN0YW5k IG5vdywgZGVhZGxvY2tlZCBvbiB0aGlzIG5vdCBjcml0aWNhbCBpc3N1ZS4NCj4gDQo+IEFueSBz dWdnZXN0aW9uIG9uIGhvdyB0byBtb3ZlIGZvcndhcmQgd291bGQgYmUgYXBwcmVjaWF0ZWQuDQo+ IA0KPiAtIEdhYm9yDQo+IA0KPiANCj4gRnJvbTogZXh0IFpodWxlaSBbbWFpbHRvOmxlaS56aHVA aHVhd2VpLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgMTI6NTkgQU0N Cj4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSk7IHBhd3NAaWV0Zi5v cmcNCj4gQ2M6IFpodWxlaQ0KPiBTdWJqZWN0OiBSZTogSlNPTiB2cyBYTUwNCj4gDQo+IEhpLA0K PiANCj4gQWN0dWFsbHksIG5vIHNvIG11Y2ggY29tbWVudHMgb24gdGhpcyBjaG9vc2luZy4gSSBq dXN0IGRvIG5vdCB0aGluayANCj4geG1sIGlzIGEgcHJvYmxlbSB0byBlbWJlZGRlZCBkZXZpY2Vz LCBpbiBmYWN0IHhtbCBpcyB3ZWxsIHN1cHBvcnRlZCBieSANCj4gZGlmZmVyZW50IHNvcnQgb2Yg ZGV2aWNlcyBpbiBteSB2aWV3LiBUaGUgaXNzdWUgbWF5IGJlIHNvbWUgcG93ZXIgYW5kIA0KPiBi YW5kd2lkdGggY29uc3RyYWluZWQgZGV2aWNlcyAoZS5nLiBzb21lIHNtYXJ0IG9iamVjdHMpIHRv IHN1cHBvcnQgdHh0IA0KPiBiYXNlZCBpbmZvcm1hdGlvbi4gTGV04oCZcyBpZ25vcmUgdGhpcyBj YXNlIHNpbmNlIHdlIGFyZSBub3QgdG8gZGVmaW5lIA0KPiBiaW5hcnkgZW5jb2RpbmcgYXQgdGhl IG1vbWVudC4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWmh1IExlaQ0KPiANCj4g5Y+R5Lu25Lq6 OiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIOS7 o+ihqA0KPiBHYWJvci5CYWprb0Bub2tpYS5jb20g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0OeaciDjm l6UgNDo0MSDmlLbku7bkuro6IHBhd3NAaWV0Zi5vcmcg5Li76aKYOiANCj4gW3Bhd3NdIEpTT04g dnMgWE1MDQo+IA0KPiBUaGUgY2hhaXJzIGRpc2N1c3NlZCB3aXRoIHRoZSBBRCwgYW5kIHdlIGNh bWUgdXAgd2l0aCB0aGUgZm9sbG93aW5nIA0KPiBhY3Rpb24gcGxhbiB0byBkcml2ZSB0aGlzIHdn IHRvIGEgY29uc2Vuc3VzIG9uIHRoZSBqc29uIHZzIHhtbCBlbmNvZGluZzoNCj4gd2XigJlsbCBj b2xsZWN0IGFuIG9iamVjdGlvbnMgbGlzdCBmb3IganNvbiBhbmQgb25lIGZvciB4bWwsIGxpc3Rp bmcgDQo+IHdoYXQgaXMgc2VlbiB3cm9uZy9wcm9ibGVtYXRpYyB3aXRoIHRoYXQgZW5jb2Rpbmcu IFRoZSBjaGFpcnMgYW5kIHRoZSANCj4gd2cgd2lsbCBnbyB0aHJvdWdoIHRoYXQgbGlzdCBhbmQg c2VlIGlmIHRoZSBvYmplY3Rpb25zIGFyZSB2YWxpZCwgdGhlbiANCj4gZGVjaWRlIHdoaWNoIGVu Y29kaW5nIGhhcyBtb3JlIHN1cHBvcnQgYW5kIGNob29zZSB0aGF0IG9uZS4gSWYgd2UgZW5kIA0K PiB1cCB3aXRoIGdvb2Qgb2JqZWN0aW9ucyBsaXN0IGZvciBib3RoLCB3ZSBtYXkgY2hvb3NlIHRv IHN1cHBvcnQgYm90aCANCj4gZW5jb2RpbmdzLCBhcyB0aGF0IGxpc3Qgd2lsbCBqdXN0aWZ5IHRo ZSBkZWNpc2lvbiBvbmNlIHRoZSBkb2N1bWVudCANCj4gYWR2YW5jZXMgdG8gdGhlIGllc2cuDQo+ IA0KPiBJIHdlbnQgdGhyb3VnaCB0aGUgZW1haWxzIGFuZCBJIGZvdW5kIHNvIGZhciB0aGUgZm9s bG93aW5nIHZhbGlkDQo+IG9iamVjdGlvbnM6DQo+IA0KPiB4bWw6DQo+IHRvbyB2ZXJib3NlLCBt YXkgYmUgYSBwcm9ibGVtIHRvIGJlIHN1cHBvcnRlZCBpbiBlbWJlZGRlZCBkZXZpY2VzIA0KPiBj dXJyZW50IHRyZW5kIGZvciBBUElzIGluIHRoZSBicm93c2VycyBpcyB0b3dhcmRzIGpzb24NCj4g DQo+IA0KPiANCj4ganNvbjoNCj4gc29tZSBkYXRhIHN0cnVjdHVyZXMgYXJlwqAgZW5jb2RlZCBp biB4bWwsIGEganNvbiBlbmNvZGluZyBmb3IgdGhvc2UgDQo+IHdvdWxkIG5lZWQgdG8gYmUgZGVm aW5lZCAod2hpY2ggaXMgbm90IGltcG9zc2libGUsIGJ1dCByZXF1aXJlcyBzb21lIA0KPiBleHRy YSB3b3JrKQ0KPiANCj4gDQo+IElmIHlvdSBoYXZlIGFkZGl0aW9uYWwgb2JqZWN0aW9ucywgc2Vu ZCB0aGVtIHRvIHRoZSBsaXN0IGFzYXAuDQo+IA0KPiAtIEdhYm9yDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHBhd3MgbWFpbGluZyBsaXN0DQo+ IHBhd3NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzDQoNCg0KDQo= From jstine@mitre.org Wed Sep 19 15:06:37 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B383A21F84FC for ; Wed, 19 Sep 2012 15:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RK1jaieBvSg for ; Wed, 19 Sep 2012 15:06:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2829721F84FA for ; Wed, 19 Sep 2012 15:06:31 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 88FCA21B0789; Wed, 19 Sep 2012 18:06:30 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7BF5B21B020E; Wed, 19 Sep 2012 18:06:30 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.133]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.001; Wed, 19 Sep 2012 18:06:30 -0400 From: "Stine, John A." To: "Gabor.Bajko@nokia.com" , "lei.zhu@huawei.com" , "paws@ietf.org" Thread-Topic: JSON vs XML Thread-Index: Ac2NNWSzyo+3mF+6Qd2aPJvU3eQx4wB8+XhAALc8RHAACYgH0AEXCfvgAADV4FA= Date: Wed, 19 Sep 2012 22:06:29 +0000 Message-ID: <2782C93FD2244441893673F3F9128192066AF33A@IMCMBX01.MITRE.ORG> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 22:06:37 -0000 SSBkbyBub3Qga25vdyBpZiBJIGFncmVlIHdpdGggdGhpcyBvciBub3QuICBUaGlzIGFwcGVhcnMg dG8gYmUgYW4gYXJlYSB3aGVyZSBtYW55IG9mIHVzLCBpbmNsdWRpbmcgbXlzZWxmLCBhcmUgbm90 IHRoZSBleHBlcnRzLiAgIA0KDQpJIGFza2VkIHNvbWVvbmUgd2hvIGlzIHdoYXQgdGhlIHByb3Mg YW5kIGNvbnMgYXJlIHdpdGggdXNpbmcgSlNPTiB2ZXJzdXMgWE1MLiAgVGhlc2UgYXJlIGhpcyB0 aG91Z2h0cw0KDQoiSWYgYWxsIHlvdSBhcmUgZ29pbmcgdG8gZG8gaXMgaGF2ZSBhIGJyb3dzZXIg dGhhdCBydW5zIEphdmFTY3JpcHQgdGhlbiBKU09OIGlzIGZpbmUuDQoNCkJ1dCBpZiB5b3Ugd2Fu dCB0byBleGNoYW5nZSBkYXRhIGJldHdlZW4gd2ViIHNlcnZpY2VzLCB0cmFuc2Zvcm0gdGhlIGRh dGEsIG9yIHF1ZXJ5IHRoZSBkYXRhLCB0aGVuIFhNTCBpcyB0aGUgd2F5IHRvIGdvLiBYTUwgaXMg MTQgeWVhcnMgb2xkIChpZiB5b3UgY29uc2lkZXIgdGhhdCBYTUwgaGFzIGl0cyBhbmNlc3RyeSBp biBTR01MLCB0aGVuIHlvdSBjb3VsZCBhcmd1ZSB0aGF0IFhNTCBpcyAzNyB5ZWFycyBvbGQpLiBK U09OIGlzIGF0IGJlc3QgMTAgeWVhcnMgb2xkLiBUaGVyZSBhcmUgbm8gdmFsaWRhdGlvbiB0b29s cyBmb3IgSlNPTiwgbm8gdHJhbnNmb3JtYXRpb24gdG9vbHMgKHVubGVzcyB5b3Ugd2FudCB0byB3 cml0ZSBKYXZhU2NyaXB0IGNvZGUpLCBubyBxdWVyeSB0b29scy4NCg0KUmVnYXJkaW5nIGVtYmVk ZGVkIHN5c3RlbXM6IEkgYW0gdG9sZCB0aGF0IG1hbnkgb2YgdGhlIGNlbGxwaG9uZSB2ZW5kb3Jz IGFyZSB1c2luZyBYTUwuIFRvIGFkZHJlc3MgdGhlIHZlcmJvc2VuZXNzIG9mIFhNTCwgdGhleSB1 c2UgdGhlIHN0YW5kYXJkIGJpbmFyeSBYTUwgZm9ybWF0IGNhbGxlZCBFZmZpY2llbnQgWE1MIElu dGVyY2hhbmdlIChFWEkpLiINCg0KSXQgd291bGQgYXBwZWFyIHRvIG1lIHRoYXQgd2l0aCBKU09O IHlvdSBhcmUgZm9yY2luZyB0aGUgdXNlIG9mIEphdmFTY3JpcHQgYW5kIHRvIGRvIGEgd2hvbGUg bG90IG1vcmUgY29kaW5nIGJ1dCB3aXRoIFhNTCB5b3Ugd291bGQgYmUgbXVjaCBtb3JlIGZsZXhp YmxlIGFuZCBoYXZlIG1hbnkgbW9yZSB0b29scyB0byBzdXBwb3J0IHlvdS4NCg0KSm9obg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2Fib3IuQmFqa29Abm9r aWEuY29tDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxOSwgMjAxMiAxOjA5IFBNDQpUbzog bGVpLnpodUBodWF3ZWkuY29tOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bhd3NdIEpT T04gdnMgWE1MDQoNCkkgY2FuIHNlbnNlIGFuIGFncmVlbWVudCB0aGF0IHdlIGNhbiBnbyBhaGVh ZCBhbmQgdXNlIGpzb24gZW5jb2RpbmcgKG9ubHkpLg0KDQpJIHdvdWxkIHRoZW4gZ28gYWhlYWQg YW5kIGluc3RydWN0IHRoZSBlZGl0b3IgdG8gZW5jb2RlIHRoZSBkYXRhIG1vZGVsIHdpdGgganNv biBpbiB0aGUgbWVyZ2VkIGRyYWZ0Lg0KDQotIEdhYm9yDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBleHQgWmh1bGVpIFttYWlsdG86bGVpLnpodUBodWF3ZWkuY29tXSANClNl bnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTIgOToxNyBQTQ0KVG86IEJhamtvIEdhYm9y IChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSk7IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBK U09OIHZzIFhNTA0KDQpIaSwNCg0KSSByZWFsbHkgd2VudCB0aHJvdWdoIGUtbWFpbCBkaXNjdXNz aW9ucyBvbiB0aGlzLiBNeSBwcm9wb3NhbCBpcyB0byB1c2UganNvbiBhcyBkYXRhIG1vZGVsIG9m IHBhd3MgcHJvdG9jb2wgaXNzdWVkIGJ5IHBhd3MsIGluIGNhc2UgdGhhdCB3ZyBhZGRyZXNzZXMg dGhlIHRyZW5kIG9mIEFQSXMgb2YgYnJvd3NlciB2ZW5kZXJzIGFuZCBrZWVwIHNvbWUgZGlzY292 ZXJ5IG1lY2hhbmlzbXMgb3BlbiBmb3IgYW55IGV4dHJhIHdvcmtzLiBBdCB0aGUgc2FtZSB0aW1l LCB3ZSBoYXZlIHNvbWUgcHJvYmxlbXMgdG8gc2F0aXNmeSB0aGUgbmVlZHMgdG8gcmV1c2Ugd3Mg c2NoZW1hIGVuY29kZWQgYnkgdHJhZGl0aW9uYWwgZGV2aWNlcywgd2hpY2ggd2lsbCBpc3N1ZSBh IHNlcGFyYXRlIHdnIGRvY3VtZW50IGZvciB4bWwgZW5jb2Rpbmcgc3RhbmRhcmQgZm9yIHhtbCBz dXBwb3J0aW5nIGluZHVzdHJpZXMuDQoNClRoZSByZWFzb25zIGRvaW5nIHRoaXMgYXJlIG5vdCB0 ZWNobmljYWwgaXNzdWVzLCBqdXN0IHdlIGhhdmUgYnJvYWQgcmVxdWlyZW1lbnRzIHRvIHJldXNl IFRTV1MgZ2VuZXJhbGx5IGZvciBjb21tdW5pY2F0aW9uIHB1cnBvc2VzLCBpbmNsdWRpbmcgc21h cnQgb2JqZWN0cywgYWQgaG9jIHVzZSwgYnJvd3NlciBBUEksIHdpZmkgYnJvYWRiYW5kLCBjZWxs dWxhciBldGMuIA0KDQpCZXN0IHJlZ2FyZHMsDQpaaHUgTGVpDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogR2Fib3IuQmFqa29Abm9raWEuY29tIFttYWlsdG86R2Fib3IuQmFq a29Abm9raWEuY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0OeaciDE05pelIDc6NDANCuaUtuS7 tuS6ujogWmh1bGVpOyBwYXdzQGlldGYub3JnDQrkuLvpopg6IFJFOiBKU09OIHZzIFhNTA0KDQpU aGVyZSB3YXMgbm90IG11Y2ggZmVlZGJhY2sgb24gdGhlIGxpc3QgYWJvdXQgdGhlIG9iamVjdGlv bnMgdG8gdGhlIGRpZmZlcmVudCBlbmNvZGluZ3MuDQoNCldlIHNlZW0gdG8gYWdyZWUgdGhhdDoN CnhtbCBtYXkgbm90IGJlIHRoZSByaWdodCBjaG9pY2UgYmVjYXVzZSB0aGUgY3VycmVudCB0cmVu ZCBmb3IgQVBJcyBpbiB0aGUgYnJvd3NlcnMgaXMgdG93YXJkcyBqc29uOyBhbmQgaWYgd2UgY2hv b3NlICBqc29uLCBhcyBzb21lIGRhdGEgc3RydWN0dXJlcyBQQVdTIG1heSByZXVzZSBhcmUgIGVu Y29kZWQgaW4geG1sLCBhIGpzb24gZW5jb2RpbmcgZm9yIHRob3NlIHdvdWxkIG5lZWQgdG8gYmUg ZGVmaW5lZCAod2hpY2ggaXMgbm90IGltcG9zc2libGUsIGJ1dCByZXF1aXJlcyBzb21lIGV4dHJh IHdvcmspDQoNClRoZSBsYXR0ZXIgb2YgdGhlIHR3byBvYmplY3Rpb25zIHdpbGwgbm90IGJlIHZh bGlkIHdoZW4gd2UnbGwgc2VuZCB0aGUgZG9jdW1lbnQgdG8gaWVzZywgYXMgYWxsIHRoZSBlbmNv ZGluZ3Mgd2lsbCBoYXZlIHRvIGJlIGluIHBsYWNlIGF0IHRoYXQgdGltZS4NClNvIHdlIGFyZSBs ZWZ0IHdpdGggcHJhY3RpY2FsbHkgb25lIHF1ZXN0aW9uOiBkbyB3ZSB3YW50IHRvIGZvbGxvdyB0 aGUgY3VycmVudCBpbmR1c3RyeSB0cmVuZCBhbmQgdXNlIGpzb24sIG9yIGRvIHdlIHdhbnQgdG8g c3RpY2sgd2l0aCB4bWwuDQoNCkEgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIHBlb3BsZSBwcmVmZXIg dG8gc3BlY2lmeSBib3RoIGVuY29kaW5ncywgYnV0IHRoYXQgbWF5IG5vdCBiZSBhZ3JlZWFibGUg d2l0aCB0aGUgaWVzZy4NCg0KVGhpcyBpcyB3aGVyZSB3ZSBzdGFuZCBub3csIGRlYWRsb2NrZWQg b24gdGhpcyBub3QgY3JpdGljYWwgaXNzdWUuDQoNCkFueSBzdWdnZXN0aW9uIG9uIGhvdyB0byBt b3ZlIGZvcndhcmQgd291bGQgYmUgYXBwcmVjaWF0ZWQuDQoNCi0gR2Fib3INCg0KDQpGcm9tOiBl eHQgWmh1bGVpIFttYWlsdG86bGVpLnpodUBodWF3ZWkuY29tXQ0KU2VudDogTW9uZGF5LCBTZXB0 ZW1iZXIgMTAsIDIwMTIgMTI6NTkgQU0NClRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGlj b25WYWxsZXkpOyBwYXdzQGlldGYub3JnDQpDYzogWmh1bGVpDQpTdWJqZWN0OiBSZTogSlNPTiB2 cyBYTUwNCg0KSGksDQoNCkFjdHVhbGx5LCBubyBzbyBtdWNoIGNvbW1lbnRzIG9uIHRoaXMgY2hv b3NpbmcuIEkganVzdCBkbyBub3QgdGhpbmsgeG1sIGlzIGEgcHJvYmxlbSB0byBlbWJlZGRlZCBk ZXZpY2VzLCBpbiBmYWN0IHhtbCBpcyB3ZWxsIHN1cHBvcnRlZCBieSBkaWZmZXJlbnQgc29ydCBv ZiBkZXZpY2VzIGluIG15IHZpZXcuIFRoZSBpc3N1ZSBtYXkgYmUgc29tZSBwb3dlciBhbmQgYmFu ZHdpZHRoIGNvbnN0cmFpbmVkIGRldmljZXMgKGUuZy4gc29tZSBzbWFydCBvYmplY3RzKSB0byBz dXBwb3J0IHR4dCBiYXNlZCBpbmZvcm1hdGlvbi4gTGV04oCZcyBpZ25vcmUgdGhpcyBjYXNlIHNp bmNlIHdlIGFyZSBub3QgdG8gZGVmaW5lIGJpbmFyeSBlbmNvZGluZyBhdCB0aGUgbW9tZW50LiAN Cg0KQmVzdCByZWdhcmRzLA0KWmh1IExlaQ0KDQrlj5Hku7bkuro6IHBhd3MtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEdhYm9yLkJhamtvQG5v a2lhLmNvbQ0K5Y+R6YCB5pe26Ze0OiAyMDEy5bm0OeaciDjml6UgNDo0MQ0K5pS25Lu25Lq6OiBw YXdzQGlldGYub3JnDQrkuLvpopg6IFtwYXdzXSBKU09OIHZzIFhNTA0KDQpUaGUgY2hhaXJzIGRp c2N1c3NlZCB3aXRoIHRoZSBBRCwgYW5kIHdlIGNhbWUgdXAgd2l0aCB0aGUgZm9sbG93aW5nIGFj dGlvbiBwbGFuIHRvIGRyaXZlIHRoaXMgd2cgdG8gYSBjb25zZW5zdXMgb24gdGhlIGpzb24gdnMg eG1sIGVuY29kaW5nOg0Kd2XigJlsbCBjb2xsZWN0IGFuIG9iamVjdGlvbnMgbGlzdCBmb3IganNv biBhbmQgb25lIGZvciB4bWwsIGxpc3Rpbmcgd2hhdCBpcyBzZWVuIHdyb25nL3Byb2JsZW1hdGlj IHdpdGggdGhhdCBlbmNvZGluZy4gVGhlIGNoYWlycyBhbmQgdGhlIHdnIHdpbGwgZ28gdGhyb3Vn aCB0aGF0IGxpc3QgYW5kIHNlZSBpZiB0aGUgb2JqZWN0aW9ucyBhcmUgdmFsaWQsIHRoZW4gZGVj aWRlIHdoaWNoIGVuY29kaW5nIGhhcyBtb3JlIHN1cHBvcnQgYW5kIGNob29zZSB0aGF0IG9uZS4g SWYgd2UgZW5kIHVwIHdpdGggZ29vZCBvYmplY3Rpb25zIGxpc3QgZm9yIGJvdGgsIHdlIG1heSBj aG9vc2UgdG8gc3VwcG9ydCBib3RoIGVuY29kaW5ncywgYXMgdGhhdCBsaXN0IHdpbGwganVzdGlm eSB0aGUgZGVjaXNpb24gb25jZSB0aGUgZG9jdW1lbnQgYWR2YW5jZXMgdG8gdGhlIGllc2cuDQoN Ckkgd2VudCB0aHJvdWdoIHRoZSBlbWFpbHMgYW5kIEkgZm91bmQgc28gZmFyIHRoZSBmb2xsb3dp bmcgdmFsaWQgb2JqZWN0aW9uczoNCg0KeG1sOiANCnRvbyB2ZXJib3NlLCBtYXkgYmUgYSBwcm9i bGVtIHRvIGJlIHN1cHBvcnRlZCBpbiBlbWJlZGRlZCBkZXZpY2VzIGN1cnJlbnQgdHJlbmQgZm9y IEFQSXMgaW4gdGhlIGJyb3dzZXJzIGlzIHRvd2FyZHMganNvbg0KDQoNCg0KanNvbjoNCnNvbWUg ZGF0YSBzdHJ1Y3R1cmVzIGFyZcKgIGVuY29kZWQgaW4geG1sLCBhIGpzb24gZW5jb2RpbmcgZm9y IHRob3NlIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZCAod2hpY2ggaXMgbm90IGltcG9zc2libGUs IGJ1dCByZXF1aXJlcyBzb21lIGV4dHJhIHdvcmspDQoNCg0KSWYgeW91IGhhdmUgYWRkaXRpb25h bCBvYmplY3Rpb25zLCBzZW5kIHRoZW0gdG8gdGhlIGxpc3QgYXNhcC4NCg0KLSBHYWJvcg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGlu ZyBsaXN0DQpwYXdzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bhd3MNCg== From vchen@google.com Wed Sep 19 18:30:42 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F8121F853D for ; Wed, 19 Sep 2012 18:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYCnF6pb2Izt for ; Wed, 19 Sep 2012 18:30:41 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 527AF21F853A for ; Wed, 19 Sep 2012 18:30:41 -0700 (PDT) Received: by qcac10 with SMTP id c10so1518553qca.31 for ; Wed, 19 Sep 2012 18:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=N2LaHi+DVECCZEHA6FzCCoOIoSvQDM8ovHQpGzyPqkw=; b=QLYykUtmUeNS9Y4LjNgzp6RJ/kVcIGF6nSisQWODpHXA9xphl/Sp8j4v+Kqs0s+8G4 7P3TRAOgfNWE4feki0GwHBpXk7s5VgkNrINAF7l6yvRhudver50OjRa0fOH48ENS1o5F t7TNryDirT5bt/ts86Kf+3w5mWgX0hLOeYwaiTP7xxwpCDOrQOkI5moyilYYigb7id9d /lQBsmSUP0ll2qwVZYIsG75dRHKcUBkDmE+aKPOKWOvlWvHOkoDH4WQV95Ak+f7L9i05 NQ/1sm2+FxotQmYdizvhpA7Ccpc6F/UeVnGmORBZn3YzewwUVVUJ0UsXJ/MEAFn17q+F SQog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=N2LaHi+DVECCZEHA6FzCCoOIoSvQDM8ovHQpGzyPqkw=; b=mkjRN9ucGDVuDBHKEELKS2JQzhMH17cM4sPjt86aBEp5D/q2WKJ2HOUU8SL7jS1al9 lOte0iHMNvRNQClBI3bnIBZKc74+4RA6LHUAm0nogYc8JQ76MMxF3/ZXZk0cmzGsX984 2j8DkIaD9umKFzjxUoNQj+aYduKKsaWCjNgtUXKqpX385HMAyH3c7L2DnOaN8l6NGFAU wc/jstt09gZdXl3VEF0C86rDzDq6HWB+GBaC7UJSG+dMYUMZZI1i8gOT0Vf96QQ11sxj +EJi0BYwRvzrwKb2/22uFixqGiM1lXqkVZlyjKQEeu4JpgfQWrnLHvRlmdvavuiCCyaw VYVw== Received: by 10.229.102.155 with SMTP id g27mr208517qco.109.1348104640043; Wed, 19 Sep 2012 18:30:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.102.155 with SMTP id g27mr208505qco.109.1348104639820; Wed, 19 Sep 2012 18:30:39 -0700 (PDT) Received: by 10.229.64.149 with HTTP; Wed, 19 Sep 2012 18:30:39 -0700 (PDT) In-Reply-To: <2782C93FD2244441893673F3F9128192066AF33A@IMCMBX01.MITRE.ORG> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> <2782C93FD2244441893673F3F9128192066AF33A@IMCMBX01.MITRE.ORG> Date: Wed, 19 Sep 2012 18:30:39 -0700 Message-ID: From: Vincent Chen To: "Stine, John A." Content-Type: multipart/alternative; boundary=0023544706d82d325504ca181275 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkhoYO3es//h/Z81toPn1zxEIRYXjvRbzAq/ltxgOvYV9Rg2+1bc4hAwjEWswlbIGwgeTTeSLQOs1eXuOkWNtnYt6fDxO2L6qbTNFHqycF/fzGIPnenNIPqii2m7KE1mm+ZLIDfUKtl7Xb8tauRdYe3tXDg9oajhRTGHgdUypZbaZ+4NHaxKCBnA14xcyLPqi0aK+9C Cc: "paws@ietf.org" Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 01:30:42 -0000 --0023544706d82d325504ca181275 Content-Type: text/plain; charset=ISO-8859-1 Hi, As clarification: - JSON does not require JavaScript or a Browser. It is a text-based representation of data that is language independent, yet well-matched to all major languages. - Simple-to-use libraries exist for all major languages/platforms. No complex transformation tools needed. JSON is not good at representing documents; XML is great for that. We're interested in representing "data", not "documents". -vince On Wed, Sep 19, 2012 at 3:06 PM, Stine, John A. wrote: > I do not know if I agree with this or not. This appears to be an area > where many of us, including myself, are not the experts. > > I asked someone who is what the pros and cons are with using JSON versus > XML. These are his thoughts > > "If all you are going to do is have a browser that runs JavaScript then > JSON is fine. > > But if you want to exchange data between web services, transform the data, > or query the data, then XML is the way to go. XML is 14 years old (if you > consider that XML has its ancestry in SGML, then you could argue that XML > is 37 years old). JSON is at best 10 years old. There are no validation > tools for JSON, no transformation tools (unless you want to write > JavaScript code), no query tools. > > Regarding embedded systems: I am told that many of the cellphone vendors > are using XML. To address the verboseness of XML, they use the standard > binary XML format called Efficient XML Interchange (EXI)." > > It would appear to me that with JSON you are forcing the use of JavaScript > and to do a whole lot more coding but with XML you would be much more > flexible and have many more tools to support you. > > John > > --0023544706d82d325504ca181275 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

As clarification:
=A0- JSON does not requi= re JavaScript or a Browser.=A0=A0It is a text-based representation of data = that is language independent, yet well-matched to all major languages.
=A0- Simple-to-use libraries exist for all major languages/platforms.=A0No = complex transformation tools needed.

JSON is not g= ood at representing documents; XML is great for that. We're interested = in representing "data", not "documents".

-vince


On = Wed, Sep 19, 2012 at 3:06 PM, Stine, John A. <jstine@mitre.org> wrote:
I do not know if I agree with this or not. = =A0This appears to be an area where many of us, including myself, are not t= he experts.

I asked someone who is what the pros and cons are with using JSON versus XM= L. =A0These are his thoughts

"If all you are going to do is have a browser that runs JavaScript the= n JSON is fine.

But if you want to exchange data between web services, transform the data, = or query the data, then XML is the way to go. XML is 14 years old (if you c= onsider that XML has its ancestry in SGML, then you could argue that XML is= 37 years old). JSON is at best 10 years old. There are no validation tools= for JSON, no transformation tools (unless you want to write JavaScript cod= e), no query tools.

Regarding embedded systems: I am told that many of the cellphone vendors ar= e using XML. To address the verboseness of XML, they use the standard binar= y XML format called Efficient XML Interchange (EXI)."

It would appear to me that with JSON you are forcing the use of JavaScript = and to do a whole lot more coding but with XML you would be much more flexi= ble and have many more tools to support you.

John

--0023544706d82d325504ca181275-- From peter@spectrumbridge.com Thu Sep 20 11:19:12 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1421F8806 for ; Thu, 20 Sep 2012 11:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUV8XRZQiMPY for ; Thu, 20 Sep 2012 11:19:11 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA8E21F86F5 for ; Thu, 20 Sep 2012 11:19:10 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 20 Sep 2012 14:19:10 -0400 From: Peter Stanforth To: Vincent Chen Date: Thu, 20 Sep 2012 14:18:59 -0400 Thread-Topic: [paws] JSON vs XML Thread-Index: Ac2XXG2CskDzDFDbR3CFA/Gob1rUdw== Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> <2782C93FD2244441893673F3F9128192066AF33A@IMCMBX01.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A0BBAB0242A34F8A817D7756BDB70D29spectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 18:19:12 -0000 --_000_A0BBAB0242A34F8A817D7756BDB70D29spectrumbridgecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIEkgdGhvdWdodCBhICJkb2N1bWVudCIgd2FzICJkYXRhIi4gU2VyaW91c2x5IHRob3VnaCB0 aGUgcXVlc3Rpb24gZm9yIHRoZSBkZXZpY2UgZ3V5cyBpcy4gRG8gdGhleSB1c2UgdGhlIHNhbWUg cGxhdGZvcm1zIGFzIHRoZSBJVCBndXlzLiBJbiBteSBleHBlcmllbmNlIHdlIG5ldmVyIGhhdmUs IGJ1dCB0aGVuIEkgd2FzIGdlbmVyYWxseSB3cml0aW5nIHJhZGlvIHNvZnR3YXJlIGluIG1hY2hp bmUgY29kZSAtIHNob3dpbmcgbXkgYWdlDQoNClBldGVyIFN0YW5mb3J0aA0KDQpPbiBTZXAgMTks IDIwMTIsIGF0IDk6MzAgUE0sICJWaW5jZW50IENoZW4iIDx2Y2hlbkBnb29nbGUuY29tPG1haWx0 bzp2Y2hlbkBnb29nbGUuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpBcyBjbGFyaWZpY2F0aW9uOg0K IC0gSlNPTiBkb2VzIG5vdCByZXF1aXJlIEphdmFTY3JpcHQgb3IgYSBCcm93c2VyLiAgSXQgaXMg YSB0ZXh0LWJhc2VkIHJlcHJlc2VudGF0aW9uIG9mIGRhdGEgdGhhdCBpcyBsYW5ndWFnZSBpbmRl cGVuZGVudCwgeWV0IHdlbGwtbWF0Y2hlZCB0byBhbGwgbWFqb3IgbGFuZ3VhZ2VzLg0KIC0gU2lt cGxlLXRvLXVzZSBsaWJyYXJpZXMgZXhpc3QgZm9yIGFsbCBtYWpvciBsYW5ndWFnZXMvcGxhdGZv cm1zLiBObyBjb21wbGV4IHRyYW5zZm9ybWF0aW9uIHRvb2xzIG5lZWRlZC4NCg0KSlNPTiBpcyBu b3QgZ29vZCBhdCByZXByZXNlbnRpbmcgZG9jdW1lbnRzOyBYTUwgaXMgZ3JlYXQgZm9yIHRoYXQu IFdlJ3JlIGludGVyZXN0ZWQgaW4gcmVwcmVzZW50aW5nICJkYXRhIiwgbm90ICJkb2N1bWVudHMi Lg0KDQotdmluY2UNCg0KDQpPbiBXZWQsIFNlcCAxOSwgMjAxMiBhdCAzOjA2IFBNLCBTdGluZSwg Sm9obiBBLiA8anN0aW5lQG1pdHJlLm9yZzxtYWlsdG86anN0aW5lQG1pdHJlLm9yZz4+IHdyb3Rl Og0KSSBkbyBub3Qga25vdyBpZiBJIGFncmVlIHdpdGggdGhpcyBvciBub3QuICBUaGlzIGFwcGVh cnMgdG8gYmUgYW4gYXJlYSB3aGVyZSBtYW55IG9mIHVzLCBpbmNsdWRpbmcgbXlzZWxmLCBhcmUg bm90IHRoZSBleHBlcnRzLg0KDQpJIGFza2VkIHNvbWVvbmUgd2hvIGlzIHdoYXQgdGhlIHByb3Mg YW5kIGNvbnMgYXJlIHdpdGggdXNpbmcgSlNPTiB2ZXJzdXMgWE1MLiAgVGhlc2UgYXJlIGhpcyB0 aG91Z2h0cw0KDQoiSWYgYWxsIHlvdSBhcmUgZ29pbmcgdG8gZG8gaXMgaGF2ZSBhIGJyb3dzZXIg dGhhdCBydW5zIEphdmFTY3JpcHQgdGhlbiBKU09OIGlzIGZpbmUuDQoNCkJ1dCBpZiB5b3Ugd2Fu dCB0byBleGNoYW5nZSBkYXRhIGJldHdlZW4gd2ViIHNlcnZpY2VzLCB0cmFuc2Zvcm0gdGhlIGRh dGEsIG9yIHF1ZXJ5IHRoZSBkYXRhLCB0aGVuIFhNTCBpcyB0aGUgd2F5IHRvIGdvLiBYTUwgaXMg MTQgeWVhcnMgb2xkIChpZiB5b3UgY29uc2lkZXIgdGhhdCBYTUwgaGFzIGl0cyBhbmNlc3RyeSBp biBTR01MLCB0aGVuIHlvdSBjb3VsZCBhcmd1ZSB0aGF0IFhNTCBpcyAzNyB5ZWFycyBvbGQpLiBK U09OIGlzIGF0IGJlc3QgMTAgeWVhcnMgb2xkLiBUaGVyZSBhcmUgbm8gdmFsaWRhdGlvbiB0b29s cyBmb3IgSlNPTiwgbm8gdHJhbnNmb3JtYXRpb24gdG9vbHMgKHVubGVzcyB5b3Ugd2FudCB0byB3 cml0ZSBKYXZhU2NyaXB0IGNvZGUpLCBubyBxdWVyeSB0b29scy4NCg0KUmVnYXJkaW5nIGVtYmVk ZGVkIHN5c3RlbXM6IEkgYW0gdG9sZCB0aGF0IG1hbnkgb2YgdGhlIGNlbGxwaG9uZSB2ZW5kb3Jz IGFyZSB1c2luZyBYTUwuIFRvIGFkZHJlc3MgdGhlIHZlcmJvc2VuZXNzIG9mIFhNTCwgdGhleSB1 c2UgdGhlIHN0YW5kYXJkIGJpbmFyeSBYTUwgZm9ybWF0IGNhbGxlZCBFZmZpY2llbnQgWE1MIElu dGVyY2hhbmdlIChFWEkpLiINCg0KSXQgd291bGQgYXBwZWFyIHRvIG1lIHRoYXQgd2l0aCBKU09O IHlvdSBhcmUgZm9yY2luZyB0aGUgdXNlIG9mIEphdmFTY3JpcHQgYW5kIHRvIGRvIGEgd2hvbGUg bG90IG1vcmUgY29kaW5nIGJ1dCB3aXRoIFhNTCB5b3Ugd291bGQgYmUgbXVjaCBtb3JlIGZsZXhp YmxlIGFuZCBoYXZlIG1hbnkgbW9yZSB0b29scyB0byBzdXBwb3J0IHlvdS4NCg0KSm9obg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWls aW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== --_000_A0BBAB0242A34F8A817D7756BDB70D29spectrumbridgecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+QW5kIEkgdGhv dWdodCBhICJkb2N1bWVudCIgd2FzICJkYXRhIi4gU2VyaW91c2x5IHRob3VnaCB0aGUgcXVlc3Rp b24gZm9yIHRoZSBkZXZpY2UgZ3V5cyBpcy4gRG8gdGhleSB1c2UgdGhlIHNhbWUgcGxhdGZvcm1z IGFzIHRoZSBJVCBndXlzLiBJbiBteSBleHBlcmllbmNlIHdlIG5ldmVyIGhhdmUsIGJ1dCB0aGVu IEkgd2FzIGdlbmVyYWxseSB3cml0aW5nIHJhZGlvIHNvZnR3YXJlIGluIG1hY2hpbmUgY29kZSAt IHNob3dpbmcgbXkgYWdlPGJyPjxicj5QZXRlciBTdGFuZm9ydGg8L2Rpdj48ZGl2Pjxicj5PbiBT ZXAgMTksIDIwMTIsIGF0IDk6MzAgUE0sICJWaW5jZW50IENoZW4iICZsdDs8YSBocmVmPSJtYWls dG86dmNoZW5AZ29vZ2xlLmNvbSI+dmNoZW5AZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48 YnI+PC9kaXY+PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PkhpLDxkaXY+ PGJyPjwvZGl2PjxkaXY+QXMgY2xhcmlmaWNhdGlvbjo8L2Rpdj48ZGl2PiZuYnNwOy0gSlNPTiBk b2VzIG5vdCByZXF1aXJlIEphdmFTY3JpcHQgb3IgYSBCcm93c2VyLiZuYnNwOyZuYnNwO0l0IGlz IGEgdGV4dC1iYXNlZCByZXByZXNlbnRhdGlvbiBvZiBkYXRhIHRoYXQgaXMgbGFuZ3VhZ2UgaW5k ZXBlbmRlbnQsIHlldCB3ZWxsLW1hdGNoZWQgdG8gYWxsIG1ham9yIGxhbmd1YWdlcy48L2Rpdj48 ZGl2Pg0KJm5ic3A7LSBTaW1wbGUtdG8tdXNlIGxpYnJhcmllcyBleGlzdCBmb3IgYWxsIG1ham9y IGxhbmd1YWdlcy9wbGF0Zm9ybXMuJm5ic3A7Tm8gY29tcGxleCB0cmFuc2Zvcm1hdGlvbiB0b29s cyBuZWVkZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5KU09OIGlzIG5vdCBnb29kIGF0IHJl cHJlc2VudGluZyBkb2N1bWVudHM7IFhNTCBpcyBncmVhdCBmb3IgdGhhdC4gV2UncmUgaW50ZXJl c3RlZCBpbiByZXByZXNlbnRpbmcgImRhdGEiLCBub3QgImRvY3VtZW50cyIuPC9kaXY+DQo8ZGl2 Pjxicj48L2Rpdj48ZGl2Pi12aW5jZTwvZGl2PjxkaXY+PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gV2VkLCBTZXAgMTksIDIwMTIgYXQgMzowNiBQTSwgU3RpbmUsIEpvaG4gQS4g PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86anN0aW5lQG1pdHJlLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmpzdGluZUBtaXRyZS5vcmc8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+SSBkbyBub3Qga25v dyBpZiBJIGFncmVlIHdpdGggdGhpcyBvciBub3QuICZuYnNwO1RoaXMgYXBwZWFycyB0byBiZSBh biBhcmVhIHdoZXJlIG1hbnkgb2YgdXMsIGluY2x1ZGluZyBteXNlbGYsIGFyZSBub3QgdGhlIGV4 cGVydHMuPGJyPg0KDQo8YnI+DQpJIGFza2VkIHNvbWVvbmUgd2hvIGlzIHdoYXQgdGhlIHByb3Mg YW5kIGNvbnMgYXJlIHdpdGggdXNpbmcgSlNPTiB2ZXJzdXMgWE1MLiAmbmJzcDtUaGVzZSBhcmUg aGlzIHRob3VnaHRzPGJyPg0KPGJyPg0KIklmIGFsbCB5b3UgYXJlIGdvaW5nIHRvIGRvIGlzIGhh dmUgYSBicm93c2VyIHRoYXQgcnVucyBKYXZhU2NyaXB0IHRoZW4gSlNPTiBpcyBmaW5lLjxicj4N Cjxicj4NCkJ1dCBpZiB5b3Ugd2FudCB0byBleGNoYW5nZSBkYXRhIGJldHdlZW4gd2ViIHNlcnZp Y2VzLCB0cmFuc2Zvcm0gdGhlIGRhdGEsIG9yIHF1ZXJ5IHRoZSBkYXRhLCB0aGVuIFhNTCBpcyB0 aGUgd2F5IHRvIGdvLiBYTUwgaXMgMTQgeWVhcnMgb2xkIChpZiB5b3UgY29uc2lkZXIgdGhhdCBY TUwgaGFzIGl0cyBhbmNlc3RyeSBpbiBTR01MLCB0aGVuIHlvdSBjb3VsZCBhcmd1ZSB0aGF0IFhN TCBpcyAzNyB5ZWFycyBvbGQpLiBKU09OIGlzIGF0IGJlc3QgMTAgeWVhcnMgb2xkLiBUaGVyZSBh cmUgbm8gdmFsaWRhdGlvbiB0b29scyBmb3IgSlNPTiwgbm8gdHJhbnNmb3JtYXRpb24gdG9vbHMg KHVubGVzcyB5b3Ugd2FudCB0byB3cml0ZSBKYXZhU2NyaXB0IGNvZGUpLCBubyBxdWVyeSB0b29s cy48YnI+DQoNCjxicj4NClJlZ2FyZGluZyBlbWJlZGRlZCBzeXN0ZW1zOiBJIGFtIHRvbGQgdGhh dCBtYW55IG9mIHRoZSBjZWxscGhvbmUgdmVuZG9ycyBhcmUgdXNpbmcgWE1MLiBUbyBhZGRyZXNz IHRoZSB2ZXJib3NlbmVzcyBvZiBYTUwsIHRoZXkgdXNlIHRoZSBzdGFuZGFyZCBiaW5hcnkgWE1M IGZvcm1hdCBjYWxsZWQgRWZmaWNpZW50IFhNTCBJbnRlcmNoYW5nZSAoRVhJKS4iPGJyPg0KPGJy Pg0KSXQgd291bGQgYXBwZWFyIHRvIG1lIHRoYXQgd2l0aCBKU09OIHlvdSBhcmUgZm9yY2luZyB0 aGUgdXNlIG9mIEphdmFTY3JpcHQgYW5kIHRvIGRvIGEgd2hvbGUgbG90IG1vcmUgY29kaW5nIGJ1 dCB3aXRoIFhNTCB5b3Ugd291bGQgYmUgbXVjaCBtb3JlIGZsZXhpYmxlIGFuZCBoYXZlIG1hbnkg bW9yZSB0b29scyB0byBzdXBwb3J0IHlvdS48YnI+DQo8c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9u dCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KSm9objxicj4NCjwvZm9udD48L3NwYW4+PGRpdiBjbGFz cz0iaW0gSE9FblpiIj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+ cGF3cyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpwYXdzQGll dGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+ PC9ib2R5PjwvaHRtbD4= --_000_A0BBAB0242A34F8A817D7756BDB70D29spectrumbridgecom_-- From brian.rosen@neustar.biz Fri Sep 21 06:01:03 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63BC21F878A for ; Fri, 21 Sep 2012 06:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.387 X-Spam-Level: X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XT2nQIpt5O3L for ; Fri, 21 Sep 2012 06:01:03 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 900E921F878B for ; Fri, 21 Sep 2012 06:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1348232381; x=1663591825; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=QfW/4RtlbXGwPu+Wcobhz KXcdrR8K73AmTFoqgEinyk=; b=Br9JQ6PZKa7RDIs0xaPxvtQwShWu309bMDjHr GUTFDFj+KpCrodHYPjirFQrr0pKeztJK0hKs/6lUue2kSRI6g== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.9579350; Fri, 21 Sep 2012 08:59:40 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 21 Sep 2012 09:00:43 -0400 From: "Rosen, Brian" To: Peter McCann Date: Fri, 21 Sep 2012 09:00:42 -0400 Thread-Topic: [paws] JSON vs XML Thread-Index: Ac2X+RuGvor1zsvgS5iQt9/eztsz9A== Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E4760200DD1A@008-AM1MPN1-007.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE62524991A23@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602028DD8@008-AM1MPN1-006.mgdnok.nokia.com> <470F27D1263A1B4EB73491ED995DE625249923F0@szxeml504-mbs.china.huawei.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020321D5@008-AM1MPN1-006.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716E2C010@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716E2C010@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: YH3btQw+OVuknraxXw26cQ== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] JSON vs XML X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:01:03 -0000 Rmlyc3Qgd2UgaGF2ZSB0byBkZWNpZGUgd2Ugd2FudCB0byB1c2UgTG9TVC4gIEkgZmF2b3IgdGhh dCwgb2YgY291cnNlLiAgVGhlbiBjaGFpcnMgY2FuIGRpc2N1c3Mgd2l0aCBlY3JpdCBjaGFpcnMg b24gdGhlIGJlc3Qgd2F5IHRvIHByb2NlZWQuDQoNCkJyaWFuDQoNCk9uIFNlcCAxOSwgMjAxMiwg YXQgMToxOCBQTSwgUGV0ZXIgTWNDYW5uIDxQZXRlci5NY0Nhbm5AaHVhd2VpLmNvbT4gd3JvdGU6 DQoNCj4gU2hvdWxkIHdlIHNwbGl0IG9mZiB0aGUgSlNPTiBlbmNvZGluZ3Mgb2YgZ2VvZ3JhcGhp YyBsb2NhdGlvbnMgYW5kIGNvbnRhY3QNCj4gaW5mb3JtYXRpb24gaW50byBzZXBhcmF0ZSBkb2N1 bWVudHMsIHNvIHRoZXkgY2FuIGJlIHJlLXVzZWQgYnkgb3RoZXJzPw0KPiANCj4gU2hvdWxkIHdl IHVyZ2UgRUNSSVQgKG9yIHNvbWUgb3RoZXIgd29ya2luZyBncm91cCkgdG8gcmUtc3BlY2lmeSBM b1NUDQo+IGluIEpTT04gZW5jb2Rpbmc/ICBPciBzaG91bGQgd2UgZG8gdGhlIGVxdWl2YWxlbnQg d29yayBoZXJlIGluIFBBV1M/DQo+IA0KPiAtUGV0ZQ0KPiANCj4gR2Fib3IuQmFqa29Abm9raWEu Y29tIHdyb3RlOg0KPj4gSSBjYW4gc2Vuc2UgYW4gYWdyZWVtZW50IHRoYXQgd2UgY2FuIGdvIGFo ZWFkIGFuZCB1c2UganNvbiBlbmNvZGluZw0KPj4gKG9ubHkpLg0KPj4gDQo+PiBJIHdvdWxkIHRo ZW4gZ28gYWhlYWQgYW5kIGluc3RydWN0IHRoZSBlZGl0b3IgdG8gZW5jb2RlIHRoZSBkYXRhIG1v ZGVsDQo+PiB3aXRoIGpzb24gaW4gdGhlIG1lcmdlZCBkcmFmdC4NCj4+IA0KPj4gLSBHYWJvcg0K Pj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogZXh0IFpodWxlaSBb bWFpbHRvOmxlaS56aHVAaHVhd2VpLmNvbV0NCj4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIg MTMsIDIwMTIgOToxNyBQTQ0KPj4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZh bGxleSk7IHBhd3NAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBKU09OIHZzIFhNTA0KPj4gDQo+ PiBIaSwNCj4+IA0KPj4gSSByZWFsbHkgd2VudCB0aHJvdWdoIGUtbWFpbCBkaXNjdXNzaW9ucyBv biB0aGlzLiBNeSBwcm9wb3NhbCBpcyB0bw0KPj4gdXNlIGpzb24gYXMgZGF0YSBtb2RlbCBvZiBw YXdzIHByb3RvY29sIGlzc3VlZCBieSBwYXdzLCBpbiBjYXNlIHRoYXQNCj4+IHdnIGFkZHJlc3Nl cyB0aGUgdHJlbmQgb2YgQVBJcyBvZiBicm93c2VyIHZlbmRlcnMgYW5kIGtlZXAgc29tZQ0KPj4g ZGlzY292ZXJ5IG1lY2hhbmlzbXMgb3BlbiBmb3IgYW55IGV4dHJhIHdvcmtzLiBBdCB0aGUgc2Ft ZSB0aW1lLCB3ZQ0KPj4gaGF2ZSBzb21lIHByb2JsZW1zIHRvIHNhdGlzZnkgdGhlIG5lZWRzIHRv IHJldXNlIHdzIHNjaGVtYSBlbmNvZGVkIGJ5DQo+PiB0cmFkaXRpb25hbCBkZXZpY2VzLCB3aGlj aCB3aWxsIGlzc3VlIGEgc2VwYXJhdGUgd2cgZG9jdW1lbnQgZm9yIHhtbA0KPj4gZW5jb2Rpbmcg c3RhbmRhcmQgZm9yIHhtbCBzdXBwb3J0aW5nIGluZHVzdHJpZXMuDQo+PiANCj4+IFRoZSByZWFz b25zIGRvaW5nIHRoaXMgYXJlIG5vdCB0ZWNobmljYWwgaXNzdWVzLCBqdXN0IHdlIGhhdmUgYnJv YWQNCj4+IHJlcXVpcmVtZW50cyB0byByZXVzZSBUU1dTIGdlbmVyYWxseSBmb3IgY29tbXVuaWNh dGlvbiBwdXJwb3NlcywNCj4+IGluY2x1ZGluZyBzbWFydCBvYmplY3RzLCBhZCBob2MgdXNlLCBi cm93c2VyIEFQSSwgd2lmaSBicm9hZGJhbmQsDQo+PiBjZWxsdWxhciBldGMuDQo+PiANCj4+IEJl c3QgcmVnYXJkcywNCj4+IFpodSBMZWkNCj4+IA0KPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K Pj4g5Y+R5Lu25Lq6OiBHYWJvci5CYWprb0Bub2tpYS5jb20gW21haWx0bzpHYWJvci5CYWprb0Bu b2tpYS5jb21dDQo+PiDlj5HpgIHml7bpl7Q6IDIwMTLlubQ55pyIMTTml6UgNzo0MA0KPj4g5pS2 5Lu25Lq6OiBaaHVsZWk7IHBhd3NAaWV0Zi5vcmcNCj4+IOS4u+mimDogUkU6IEpTT04gdnMgWE1M DQo+PiANCj4+IFRoZXJlIHdhcyBub3QgbXVjaCBmZWVkYmFjayBvbiB0aGUgbGlzdCBhYm91dCB0 aGUgb2JqZWN0aW9ucyB0byB0aGUNCj4+IGRpZmZlcmVudCBlbmNvZGluZ3MuDQo+PiANCj4+IFdl IHNlZW0gdG8gYWdyZWUgdGhhdDoNCj4+IHhtbCBtYXkgbm90IGJlIHRoZSByaWdodCBjaG9pY2Ug YmVjYXVzZSB0aGUgY3VycmVudCB0cmVuZCBmb3IgQVBJcyBpbg0KPj4gdGhlIGJyb3dzZXJzIGlz IHRvd2FyZHMganNvbjsgYW5kIGlmIHdlIGNob29zZSAganNvbiwgYXMgc29tZSBkYXRhDQo+PiBz dHJ1Y3R1cmVzIFBBV1MgbWF5IHJldXNlIGFyZSAgZW5jb2RlZCBpbiB4bWwsIGEganNvbiBlbmNv ZGluZyBmb3INCj4+IHRob3NlIHdvdWxkIG5lZWQgdG8gYmUgZGVmaW5lZCAod2hpY2ggaXMgbm90 IGltcG9zc2libGUsIGJ1dCByZXF1aXJlcw0KPj4gc29tZSBleHRyYSB3b3JrKQ0KPj4gDQo+PiBU aGUgbGF0dGVyIG9mIHRoZSB0d28gb2JqZWN0aW9ucyB3aWxsIG5vdCBiZSB2YWxpZCB3aGVuIHdl J2xsIHNlbmQgdGhlDQo+PiBkb2N1bWVudCB0byBpZXNnLCBhcyBhbGwgdGhlIGVuY29kaW5ncyB3 aWxsIGhhdmUgdG8gYmUgaW4gcGxhY2UgYXQNCj4+IHRoYXQgdGltZS4NCj4+IFNvIHdlIGFyZSBs ZWZ0IHdpdGggcHJhY3RpY2FsbHkgb25lIHF1ZXN0aW9uOiBkbyB3ZSB3YW50IHRvIGZvbGxvdyB0 aGUNCj4+IGN1cnJlbnQgaW5kdXN0cnkgdHJlbmQgYW5kIHVzZSBqc29uLCBvciBkbyB3ZSB3YW50 IHRvIHN0aWNrIHdpdGggeG1sLg0KPj4gDQo+PiBBIHNpZ25pZmljYW50IG51bWJlciBvZiBwZW9w bGUgcHJlZmVyIHRvIHNwZWNpZnkgYm90aCBlbmNvZGluZ3MsIGJ1dA0KPj4gdGhhdCBtYXkgbm90 IGJlIGFncmVlYWJsZSB3aXRoIHRoZSBpZXNnLg0KPj4gDQo+PiBUaGlzIGlzIHdoZXJlIHdlIHN0 YW5kIG5vdywgZGVhZGxvY2tlZCBvbiB0aGlzIG5vdCBjcml0aWNhbCBpc3N1ZS4NCj4+IA0KPj4g QW55IHN1Z2dlc3Rpb24gb24gaG93IHRvIG1vdmUgZm9yd2FyZCB3b3VsZCBiZSBhcHByZWNpYXRl ZC4NCj4+IA0KPj4gLSBHYWJvcg0KPj4gDQo+PiANCj4+IEZyb206IGV4dCBaaHVsZWkgW21haWx0 bzpsZWkuemh1QGh1YXdlaS5jb21dDQo+PiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAx MiAxMjo1OSBBTQ0KPj4gVG86IEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSk7 IHBhd3NAaWV0Zi5vcmcNCj4+IENjOiBaaHVsZWkNCj4+IFN1YmplY3Q6IFJlOiBKU09OIHZzIFhN TA0KPj4gDQo+PiBIaSwNCj4+IA0KPj4gQWN0dWFsbHksIG5vIHNvIG11Y2ggY29tbWVudHMgb24g dGhpcyBjaG9vc2luZy4gSSBqdXN0IGRvIG5vdCB0aGluaw0KPj4geG1sIGlzIGEgcHJvYmxlbSB0 byBlbWJlZGRlZCBkZXZpY2VzLCBpbiBmYWN0IHhtbCBpcyB3ZWxsIHN1cHBvcnRlZCBieQ0KPj4g ZGlmZmVyZW50IHNvcnQgb2YgZGV2aWNlcyBpbiBteSB2aWV3LiBUaGUgaXNzdWUgbWF5IGJlIHNv bWUgcG93ZXIgYW5kDQo+PiBiYW5kd2lkdGggY29uc3RyYWluZWQgZGV2aWNlcyAoZS5nLiBzb21l IHNtYXJ0IG9iamVjdHMpIHRvIHN1cHBvcnQgdHh0DQo+PiBiYXNlZCBpbmZvcm1hdGlvbi4gTGV0 4oCZcyBpZ25vcmUgdGhpcyBjYXNlIHNpbmNlIHdlIGFyZSBub3QgdG8gZGVmaW5lDQo+PiBiaW5h cnkgZW5jb2RpbmcgYXQgdGhlIG1vbWVudC4NCj4+IA0KPj4gQmVzdCByZWdhcmRzLA0KPj4gWmh1 IExlaQ0KPj4gDQo+PiDlj5Hku7bkuro6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBh d3MtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQo+PiBHYWJvci5CYWprb0Bub2tpYS5jb20g5Y+R 6YCB5pe26Ze0OiAyMDEy5bm0OeaciDjml6UgNDo0MSDmlLbku7bkuro6IHBhd3NAaWV0Zi5vcmcg 5Li76aKYOiBbcGF3c10NCj4+IEpTT04gdnMgWE1MDQo+PiANCj4+IFRoZSBjaGFpcnMgZGlzY3Vz c2VkIHdpdGggdGhlIEFELCBhbmQgd2UgY2FtZSB1cCB3aXRoIHRoZSBmb2xsb3dpbmcNCj4+IGFj dGlvbiBwbGFuIHRvIGRyaXZlIHRoaXMgd2cgdG8gYSBjb25zZW5zdXMgb24gdGhlIGpzb24gdnMg eG1sIGVuY29kaW5nOg0KPj4gd2XigJlsbCBjb2xsZWN0IGFuIG9iamVjdGlvbnMgbGlzdCBmb3Ig anNvbiBhbmQgb25lIGZvciB4bWwsIGxpc3Rpbmcgd2hhdA0KPj4gaXMgc2VlbiB3cm9uZy9wcm9i bGVtYXRpYyB3aXRoIHRoYXQgZW5jb2RpbmcuIFRoZSBjaGFpcnMgYW5kIHRoZSB3ZyB3aWxsDQo+ PiBnbyB0aHJvdWdoIHRoYXQgbGlzdCBhbmQgc2VlIGlmIHRoZSBvYmplY3Rpb25zIGFyZSB2YWxp ZCwgdGhlbiBkZWNpZGUNCj4+IHdoaWNoIGVuY29kaW5nIGhhcyBtb3JlIHN1cHBvcnQgYW5kIGNo b29zZSB0aGF0IG9uZS4gSWYgd2UgZW5kIHVwIHdpdGgNCj4+IGdvb2Qgb2JqZWN0aW9ucyBsaXN0 IGZvciBib3RoLCB3ZSBtYXkgY2hvb3NlIHRvIHN1cHBvcnQgYm90aCBlbmNvZGluZ3MsDQo+PiBh cyB0aGF0IGxpc3Qgd2lsbCBqdXN0aWZ5IHRoZSBkZWNpc2lvbiBvbmNlIHRoZSBkb2N1bWVudCBh ZHZhbmNlcyB0byB0aGUNCj4+IGllc2cuDQo+PiANCj4+IEkgd2VudCB0aHJvdWdoIHRoZSBlbWFp bHMgYW5kIEkgZm91bmQgc28gZmFyIHRoZSBmb2xsb3dpbmcgdmFsaWQNCj4+IG9iamVjdGlvbnM6 DQo+PiANCj4+IHhtbDoNCj4+IHRvbyB2ZXJib3NlLCBtYXkgYmUgYSBwcm9ibGVtIHRvIGJlIHN1 cHBvcnRlZCBpbiBlbWJlZGRlZCBkZXZpY2VzDQo+PiBjdXJyZW50IHRyZW5kIGZvciBBUElzIGlu IHRoZSBicm93c2VycyBpcyB0b3dhcmRzIGpzb24NCj4+IA0KPj4gDQo+PiANCj4+IGpzb246DQo+ PiBzb21lIGRhdGEgc3RydWN0dXJlcyBhcmUgIGVuY29kZWQgaW4geG1sLCBhIGpzb24gZW5jb2Rp bmcgZm9yIHRob3NlDQo+PiB3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQgKHdoaWNoIGlzIG5vdCBp bXBvc3NpYmxlLCBidXQgcmVxdWlyZXMgc29tZQ0KPj4gZXh0cmEgd29yaykNCj4+IA0KPj4gDQo+ PiBJZiB5b3UgaGF2ZSBhZGRpdGlvbmFsIG9iamVjdGlvbnMsIHNlbmQgdGhlbSB0byB0aGUgbGlz dCBhc2FwLg0KPj4gDQo+PiAtIEdhYm9yDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+IHBhd3NAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPiANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBwYXdzIG1haWxpbmcgbGlzdA0KPiBwYXdzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQo= From Gabor.Bajko@nokia.com Tue Sep 25 10:42:00 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2CE21F8685 for ; Tue, 25 Sep 2012 10:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTbHQI4MbBgt for ; Tue, 25 Sep 2012 10:41:59 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 040C121F8647 for ; Tue, 25 Sep 2012 10:41:58 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8PHfs1P032109 for ; Tue, 25 Sep 2012 20:41:54 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Sep 2012 20:41:54 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0309.003; Tue, 25 Sep 2012 19:41:53 +0200 From: To: Thread-Topic: JSON encoding Thread-Index: Ac2bQo0v9GArVN/qQa2hBIgDop7xTw== Date: Tue, 25 Sep 2012 17:41:52 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760203557B008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Sep 2012 17:41:54.0475 (UTC) FILETIME=[0D79D7B0:01CD9B45] X-Nokia-AV: Clean Subject: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 17:42:00 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760203557B008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I scanned through the data which has to be carried by PAWS, and it looks to= me that there are two RFCs which we may consider re-using: RFC5491 defines= the xml encoding for geo-location, I did not find a JSON encoding for it. = The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the x= ml representation of vCard, but again, I have not found a JSON encoding for= vCard. vCard seems to be able to handle contact information, schedule, etc= , but there are obviously other data fields, like antenna parameters, which= need to be defined in PAWS. First, I'd like to get some opinions on whether the reuse of the data struc= tures defined in the above two RFCs is generally considered a good idea or = not. If we want to reuse them, we'll need to define a JSON encoding for tho= se. The alternative is to define the whole data structure with JSON encodin= g in PAWS. I'd like to hear opinions on which way is more feasible. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760203557B008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I scanned through the data which has to be carried b= y PAWS, and it looks to me that there are two RFCs which we may consider re= -using: RFC5491 defines the xml encoding for geo-location, I did not find a= JSON encoding for it. The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the xml representa= tion of vCard, but again, I have not found a JSON encoding for vCard. vCard= seems to be able to handle contact information, schedule, etc, but there a= re obviously other data fields, like antenna parameters, which need to be defined in PAWS.

 

First, I’d like to get some opinions on whethe= r the reuse of the data structures defined in the above two RFCs is general= ly considered a good idea or not. If we want to reuse them, we’ll nee= d to define a JSON encoding for those. The alternative is to define the whole data structure with JSON encoding in PAWS.

 

I’d like to hear opinions on which way is more= feasible.

 

-     &= nbsp;    Gabor

 

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760203557B008AM1MPN1006mg_-- From brian.rosen@neustar.biz Tue Sep 25 10:59:26 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C282821F8813 for ; Tue, 25 Sep 2012 10:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xqHbwIwB8DS for ; Tue, 25 Sep 2012 10:59:26 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B623121F85FC for ; Tue, 25 Sep 2012 10:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1348596077; x=1663955601; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=C8nPsL7SRK8OzGa+/Lq9GVvz8cDkIPODTSZU578p1ug=; b=lX7Dmm9mnU1FVMZ47SJ0sAUg/cYPC4LadttZPFv2Y63wdsXucn5dflSKIc2g/P UulgMAI/XWKPyTy+Bmn/v8vg== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.14220624; Tue, 25 Sep 2012 14:01:16 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 25 Sep 2012 13:59:21 -0400 From: "Rosen, Brian" To: "Gabor.Bajko@nokia.com" Date: Tue, 25 Sep 2012 13:59:21 -0400 Thread-Topic: [paws] JSON encoding Thread-Index: Ac2bR31BcsnymwhTSOiDw7RHULUXTg== Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Igu7kfvGL3i7T6t8H32XMA== Content-Type: multipart/alternative; boundary="_000_D83A4EEF8CC84943A7FB2A816411A3EEneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 17:59:26 -0000 --_000_D83A4EEF8CC84943A7FB2A816411A3EEneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Use 5194, which is based on OGC's GML in preference to 6350. Among other t= hings, you may need the ability to encode uncertainty of location. You could consider the Geo URI (RFC5870), but it has the same uncertainty p= roblem. Brian On Sep 25, 2012, at 1:41 PM, Gabor.Bajko@nokia.com wrote: I scanned through the data which has to be carried by PAWS, and it looks to= me that there are two RFCs which we may consider re-using: RFC5491 defines= the xml encoding for geo-location, I did not find a JSON encoding for it. = The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the x= ml representation of vCard, but again, I have not found a JSON encoding for= vCard. vCard seems to be able to handle contact information, schedule, etc= , but there are obviously other data fields, like antenna parameters, which= need to be defined in PAWS. First, I=92d like to get some opinions on whether the reuse of the data str= uctures defined in the above two RFCs is generally considered a good idea o= r not. If we want to reuse them, we=92ll need to define a JSON encoding for= those. The alternative is to define the whole data structure with JSON enc= oding in PAWS. I=92d like to hear opinions on which way is more feasible. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_D83A4EEF8CC84943A7FB2A816411A3EEneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
<as individual>
Use 5194, which is based on OG= C's GML in preference to 6350.  Among other things, you may need the a= bility to encode uncertainty of location.

You coul= d consider the Geo URI (RFC5870), but it has the same uncertainty problem.<= /div>

Brian



=
On Sep 25, 2012, at 1:41 PM, Gabor.Bajko@nokia.com wrote:

I scan= ned through the data which has to be carried by PAWS, and it looks to me th= at there are two RFCs which we may consider re-using: RFC5491 defines the x= ml encoding for geo-location, I did not find a JSON encoding for it. The ot= her one is vCard, RFC6350. There is a so called xCard, RFC6351, the xml rep= resentation of vCard, but again, I have not found a JSON encoding for vCard= . vCard seems to be able to handle contact information, schedule, etc, but = there are obviously other data fields, like antenna parameters, which need = to be defined in PAWS.
 <= /div>
First, I=92d like to get some opinions on whether th= e reuse of the data structures defined in the above two RFCs is generally c= onsidered a good idea or not. If we want to reuse them, we=92ll need to def= ine a JSON encoding for those. The alternative is to define the whole data = structure with JSON encoding in PAWS.
 
I=92d like to hear opinions on which = way is more feasible.
 
-   &= nbsp;     &n= bsp;Gabor
 = ;
 
_______________= ________________________________
paws mailing list
paws@i= etf.org
https://www.ietf.org/mailm= an/listinfo/paws

= --_000_D83A4EEF8CC84943A7FB2A816411A3EEneustarbiz_-- From vchen@google.com Tue Sep 25 11:03:11 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812F221F846F for ; Tue, 25 Sep 2012 11:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy0Eops9aGal for ; Tue, 25 Sep 2012 11:03:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5259F21F845A for ; Tue, 25 Sep 2012 11:03:10 -0700 (PDT) Received: by qabj40 with SMTP id j40so334855qab.10 for ; Tue, 25 Sep 2012 11:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=E442tn+nEoQYTuPZmVoAxS1VhFP3tnYwtCWOIxNSd6w=; b=Ra45h6sHQEB/AGzyVELwtLISJxYD8QraKJANh5cuQwdWoQi9UoXDoMIj2+bQfiucPV n3DPhFE4CB0OsB4pL7/yQEoezsKHZDeAxfuK+BusUBxpoMcjVW3f/0jVNlLiz+Odw1fa 8LFB5NQMGuZjaa66nlqqO+21DjIL/5achAiAWTiD3kipR4FqcwRYNstJt4VvmB0Zf8Kk KyBemerpmK5OJ6mNVq4eCPMNn8clzJkF6tWvYk9O5qmXaDVVSLMHHtBPrZQLzu0d7KGF KlrgtoLC3fgPJpOxtp7lvm7H00XIKBdtGE40tVFd/1vM8ByWmCCo+i9QclfRYOZHRTpK lBSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=E442tn+nEoQYTuPZmVoAxS1VhFP3tnYwtCWOIxNSd6w=; b=G6OHm/Ycxvyprd+Q5VGxgcLXRGEpi8NPNfHbXgdBLAKLT27OgZoxIHO6ukFt2DwGMI hg7rYWhBbwEeW9UX+D4NXPWgGxLSOC3Zfzr0frE3zcxXlq4+hFfjQFiSCNnSRiymXKe2 zK4MHq1yXsfXwAhuNwJtHQi8sW/xpw9YDwBNlwaOSAD3qhBUgNK+7rJJFDokGKHERfzn 8IIYCXXPSFsZkHTQtE/c+1N2X4ThhASOAmJ71DPolwFrwkTpuU9PV41GqeXFCjbN+BNF 2KLZ29jA6wjvtMBaQemvh9ySBwwn3lO98twigshBkm4MhxnPJ613gM8U+lKqKoIs4g0T fVIQ== Received: by 10.229.135.143 with SMTP id n15mr11626178qct.77.1348596189764; Tue, 25 Sep 2012 11:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.143 with SMTP id n15mr11626161qct.77.1348596189449; Tue, 25 Sep 2012 11:03:09 -0700 (PDT) Received: by 10.229.64.149 with HTTP; Tue, 25 Sep 2012 11:03:09 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> Date: Tue, 25 Sep 2012 11:03:09 -0700 Message-ID: From: Vincent Chen To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary=00248c768f2ad14f6404ca8a841c X-System-Of-Record: true X-Gm-Message-State: ALoCoQkhUuckSgwyK4NmJOCSycXKXD02MBu1ulWdlnYgKg74VZVDT+KdozkLexhIhzHRK7jZYWCJagYz/SEXSj+H3lr6oXDRmEhZ36bcUBHT0spjqblcPciutpSErfuLrkwfqI2nXqyUXyZpeMrGyejg4pkygGfgHqWWnndVB9a2A2xk+DVo8Emn5uWo93NS3L/axwVD74GF Cc: paws@ietf.org Subject: Re: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 18:03:11 -0000 --00248c768f2ad14f6404ca8a841c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI. http://json-schema.org/ Version 4 of the IETF draft is active. - This link references JSON schemas for Geographic Coordinate and Card. I have mixed feelings about re-using when the referenced schema is complex and contains many fields that might not make sense for PAWS. We would end up documenting which portions of those schemas are required, optional, etc. I think that's a case-by-case decision. On Tue, Sep 25, 2012 at 10:41 AM, wrote: > I scanned through the data which has to be carried by PAWS, and it looks > to me that there are two RFCs which we may consider re-using: RFC5491 > defines the xml encoding for geo-location, I did not find a JSON encoding > for it. The other one is vCard, RFC6350. There is a so called xCard, > RFC6351, the xml representation of vCard, but again, I have not found a > JSON encoding for vCard. vCard seems to be able to handle contact > information, schedule, etc, but there are obviously other data fields, li= ke > antenna parameters, which need to be defined in PAWS.**** > > ** ** > > First, I=92d like to get some opinions on whether the reuse of the data > structures defined in the above two RFCs is generally considered a good > idea or not. If we want to reuse them, we=92ll need to define a JSON enco= ding > for those. The alternative is to define the whole data structure with JSO= N > encoding in PAWS.**** > > ** ** > > I=92d like to hear opinions on which way is more feasible.**** > > ** ** > > **- **Gabor**** > > ** ** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --00248c768f2ad14f6404ca8a841c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable FYI.=A0http://json-schema.org/=A0Ve= rsion 4 of the IETF draft is active.
=A0- This link references JSON sch= emas for Geographic Coordinate and Card.

I have= mixed feelings about re-using when the referenced schema is complex and co= ntains many fields that might not make sense for PAWS. We would end up docu= menting which portions of those schemas are required, optional, etc.
I think that's a case-by-case decision.

On Tue, Sep 25, 2012 at 10:41 AM, &l= t;Gabor.Bajko@no= kia.com> wrote:

I scanned through the data which has to be carried b= y PAWS, and it looks to me that there are two RFCs which we may consider re= -using: RFC5491 defines the xml encoding for geo-location, I did not find a= JSON encoding for it. The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the xml representa= tion of vCard, but again, I have not found a JSON encoding for vCard. vCard= seems to be able to handle contact information, schedule, etc, but there a= re obviously other data fields, like antenna parameters, which need to be defined in PAWS.

=A0

First, I=92d like to get some opinions on whether th= e reuse of the data structures defined in the above two RFCs is generally c= onsidered a good idea or not. If we want to reuse them, we=92ll need to def= ine a JSON encoding for those. The alternative is to define the whole data structure with JSON encoding in PAWS.

=A0

I=92d like to hear opinions on which way is more fea= sible.<= /span>

=A0

-=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

=A0


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
--00248c768f2ad14f6404ca8a841c-- From brian.rosen@neustar.biz Tue Sep 25 11:09:25 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4636C21F8834 for ; Tue, 25 Sep 2012 11:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCcz3FgLVZCi for ; Tue, 25 Sep 2012 11:09:24 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9A921F85C0 for ; Tue, 25 Sep 2012 11:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1348596350; x=1663949890; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=hDdcJ2RuXWUDLNlD68UtzpvitMo9HwGg0N8ADPZXGS0=; b=H7bt3t+n0mJI05NvU/V+3cg1xe9ya1KoRolommucT2hLkmKrhQ172jXWRo6iQL S10gwg5nt1debk5pDFqmLVHw== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.11530326; Tue, 25 Sep 2012 14:05:48 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 25 Sep 2012 14:09:20 -0400 From: "Rosen, Brian" To: Vincent Chen Date: Tue, 25 Sep 2012 14:09:18 -0400 Thread-Topic: [paws] JSON encoding Thread-Index: Ac2bSOI96mLA53cZS9GgBFebh1r3sg== Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /4p+LqEIO8AxFV7Fo86cUA== Content-Type: multipart/alternative; boundary="_000_CE693BDB33314C0EA5B66FB728EBED3Bneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 18:09:25 -0000 --_000_CE693BDB33314C0EA5B66FB728EBED3Bneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Same problem, no way to represent uncertainty (or confidence, but we could = specify confidence at 95%). Brian On Sep 25, 2012, at 2:03 PM, Vincent Chen > wrote: FYI. http://json-schema.org/ Version 4 of the IETF draft is active. - This link references JSON schemas for Geographic Coordinate and Card. I have mixed feelings about re-using when the referenced schema is complex = and contains many fields that might not make sense for PAWS. We would end u= p documenting which portions of those schemas are required, optional, etc. I think that's a case-by-case decision. On Tue, Sep 25, 2012 at 10:41 AM, > wrote: I scanned through the data which has to be carried by PAWS, and it looks to= me that there are two RFCs which we may consider re-using: RFC5491 defines= the xml encoding for geo-location, I did not find a JSON encoding for it. = The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the x= ml representation of vCard, but again, I have not found a JSON encoding for= vCard. vCard seems to be able to handle contact information, schedule, etc= , but there are obviously other data fields, like antenna parameters, which= need to be defined in PAWS. First, I=92d like to get some opinions on whether the reuse of the data str= uctures defined in the above two RFCs is generally considered a good idea o= r not. If we want to reuse them, we=92ll need to define a JSON encoding for= those. The alternative is to define the whole data structure with JSON enc= oding in PAWS. I=92d like to hear opinions on which way is more feasible. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CE693BDB33314C0EA5B66FB728EBED3Bneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Same problem, no way = to represent uncertainty (or confidence, but we could specify confidence at= 95%).

Brian

On Sep 25, 201= 2, at 2:03 PM, Vincent Chen <vchen@g= oogle.com> wrote:

FYI. http://j= son-schema.org/ Version 4 of the IETF draft is active.
 -= This link references JSON schemas for Geographic Coordinate and Card.
<= div>

I have mixed feelings about re-using when the refer= enced schema is complex and contains many fields that might not make sense = for PAWS. We would end up documenting which portions of those schemas are r= equired, optional, etc.
I think that's a case-by-case decision.

On Tue, Sep 25, 2012 at 10:41 AM, <Gabor.Bajko@nokia.com> wrote:

I scanned through the data which has to be carr= ied by PAWS, and it looks to me that there are two RFCs which we may consid= er re-using: RFC5491 defines the xml encoding for geo-location, I did not f= ind a JSON encoding for it. The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the xml representa= tion of vCard, but again, I have not found a JSON encoding for vCard. vCard= seems to be able to handle contact information, schedule, etc, but there a= re obviously other data fields, like antenna parameters, which need to be defined in PAWS.

 

Fir= st, I=92d like to get some opinions on whether the reuse of the data struct= ures defined in the above two RFCs is generally considered a good idea or n= ot. If we want to reuse them, we=92ll need to define a JSON encoding for th= ose. The alternative is to define the whole data structure with JSON encoding in PAWS.

 

I=92d like to hear opinions on which way is more feasible.

 = ;

-          Gabor

&= nbsp;

 


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws




--
-vince
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mai= lman/listinfo/paws

= --_000_CE693BDB33314C0EA5B66FB728EBED3Bneustarbiz_-- From ben@blindcreek.com Tue Sep 25 11:49:34 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B87E21F8828 for ; Tue, 25 Sep 2012 11:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcRgxZX0BvD4 for ; Tue, 25 Sep 2012 11:49:33 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4821F8827 for ; Tue, 25 Sep 2012 11:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=CBxXg0MUD+xkZMApMjC7CWN75ZM38KirCOZq+B11K5Q=; b=R2LX/yPdz7m/DIA9RDXFzXU/+9IGvJdVa15RsoD3Tgpb8yUf1ZsgXuySYXWkGahewmiPo1fe3u73bZpvMsfZOS/fKz3LH7Zx6HPdcdbguJGCAx/beeN6D0efGtaxv6jN; Received: from [64.74.213.174] (port=62502 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1TGaCI-0007cD-HA for paws@ietf.org; Tue, 25 Sep 2012 13:49:31 -0500 Message-ID: <5061FCBC.4090209@blindcreek.com> Date: Tue, 25 Sep 2012 11:49:32 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 18:49:34 -0000 The ability to include uncertainty seems like it may be important.  I can imagine as protection criteria evolve, we may see criteria based on relative proximity to protected devices, and position uncertainty is important for figuring that out. We also see it specified in the exchange of information between dependent devices and the internet connected device (802); Proposed standards in 802.11 and 802.15 under development use an encoding based on RFC6225, which includes uncertainty, and it could be quite handy if it is obvious how to map from this form to whatever PAWS transports.

So yes, use one that supports that. It'd be even better if it can be elided when not needed to save bits on the air.

-Ben


<as individual>
Use 5194, which is based on OGC's GML in preference to 6350.  Among other things, you may need the ability to encode uncertainty of location.

You could consider the Geo URI (RFC5870), but it has the same uncertainty problem.

Brian



On Sep 25, 2012, at 1:41 PM, Gabor.Bajko@nokia.com wrote:

I scanned through the data which has to be carried by PAWS, and it looks to me that there are two RFCs which we may consider re-using: RFC5491 defines the xml encoding for geo-location, I did not find a JSON encoding for it. The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the xml representation of vCard, but again, I have not found a JSON encoding for vCard. vCard seems to be able to handle contact information, schedule, etc, but there are obviously other data fields, like antenna parameters, which need to be defined in PAWS.
 
First, I’d like to get some opinions on whether the reuse of the data structures defined in the above two RFCs is generally considered a good idea or not. If we want to reuse them, we’ll need to define a JSON encoding for those. The alternative is to define the whole data structure with JSON encoding in PAWS.
 
I’d like to hear opinions on which way is more feasible.
 
-          Gabor
 
 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws


_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

From ben@blindcreek.com Tue Sep 25 12:00:29 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCB621F8882 for ; Tue, 25 Sep 2012 12:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr4If63Orj8p for ; Tue, 25 Sep 2012 12:00:28 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E71F0D1C for ; Tue, 25 Sep 2012 12:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Q51sQIe2bExLBSl0V3S/w+pA/xO+GrYpaH1IB2ul6jk=; b=CH7rScUbak3wVbgV9+28GPWxsaV86q9VVjITxFNrGy0WZu5tqdBAlMpEZpV4aDmSYRSiAx6BXXVvlenQpVuyhfoDRYWGoi/deI9UTiUxhztatJKmjQdM055q+FYBo0nV; Received: from [64.74.213.174] (port=60507 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1TGaMi-0000xB-F9 for paws@ietf.org; Tue, 25 Sep 2012 14:00:16 -0500 Message-ID: <5061FF40.4020308@blindcreek.com> Date: Tue, 25 Sep 2012 12:00:16 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:00:29 -0000 The 'geo' representation does not include all the information that typically is carried around with Lat/Lon. We will need altitude and most likely the datum ID, uncertainty as mentioned before.
Did I look at the wrong thing?

Ben
FYI. http://json-schema.org/ Version 4 of the IETF draft is active.
 - This link references JSON schemas for Geographic Coordinate and Card.

I have mixed feelings about re-using when the referenced schema is complex and contains many fields that might not make sense for PAWS. We would end up documenting which portions of those schemas are required, optional, etc.
I think that's a case-by-case decision.

On Tue, Sep 25, 2012 at 10:41 AM, <Gabor.Bajko@nokia.com> wrote:

I scanned through the data which has to be carried by PAWS, and it looks to me that there are two RFCs which we may consider re-using: RFC5491 defines the xml encoding for geo-location, I did not find a JSON encoding for it. The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the xml representation of vCard, but again, I have not found a JSON encoding for vCard. vCard seems to be able to handle contact information, schedule, etc, but there are obviously other data fields, like antenna parameters, which need to be defined in PAWS.

 

First, I’d like to get some opinions on whether the reuse of the data structures defined in the above two RFCs is generally considered a good idea or not. If we want to reuse them, we’ll need to define a JSON encoding for those. The alternative is to define the whole data structure with JSON encoding in PAWS.

 

I’d like to hear opinions on which way is more feasible.

 

-          Gabor

 

 


_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws




--
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

From Gabor.Bajko@nokia.com Tue Sep 25 13:31:51 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3674821F87CA for ; Tue, 25 Sep 2012 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZOKJi5YzHDX for ; Tue, 25 Sep 2012 13:31:49 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA41F0CB7 for ; Tue, 25 Sep 2012 13:31:48 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8PKViUK021271; Tue, 25 Sep 2012 23:31:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Sep 2012 23:31:44 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0309.003; Tue, 25 Sep 2012 22:31:43 +0200 From: To: Thread-Topic: [paws] JSON encoding Thread-Index: Ac2bQo0v9GArVN/qQa2hBIgDop7xT///6FmA//+2cjA= Date: Tue, 25 Sep 2012 20:31:42 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602035658@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47602035658008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Sep 2012 20:31:44.0914 (UTC) FILETIME=[C7736F20:01CD9B5C] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 20:31:51 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602035658008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 5194 is an unrelated RFC, did you mean 5491 instead? That is what I also pr= oposed for geolocation. That has all the things Ben is looking for, including uncertainty, altitud= e, the datum ID (I guess) is part of the GML 3.1.1 I was not proposing to use 6350 for geolocation, but instead for the contac= t and schedule information. - gabor From: ext Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Tuesday, September 25, 2012 10:59 AM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] JSON encoding Use 5194, which is based on OGC's GML in preference to 6350. Among other t= hings, you may need the ability to encode uncertainty of location. You could consider the Geo URI (RFC5870), but it has the same uncertainty p= roblem. Brian On Sep 25, 2012, at 1:41 PM, Gabor.Bajko@nokia.com wrote: I scanned through the data which has to be carried by PAWS, and it looks to= me that there are two RFCs which we may consider re-using: RFC5491 defines= the xml encoding for geo-location, I did not find a JSON encoding for it. = The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the x= ml representation of vCard, but again, I have not found a JSON encoding for= vCard. vCard seems to be able to handle contact information, schedule, etc= , but there are obviously other data fields, like antenna parameters, which= need to be defined in PAWS. First, I'd like to get some opinions on whether the reuse of the data struc= tures defined in the above two RFCs is generally considered a good idea or = not. If we want to reuse them, we'll need to define a JSON encoding for tho= se. The alternative is to define the whole data structure with JSON encodin= g in PAWS. I'd like to hear opinions on which way is more feasible. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602035658008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

5194 is an unrelated RFC,= did you mean 5491 instead? That is what I also proposed for geolocation.

That has all the things B= en is looking  for, including uncertainty, altitude, the datum ID (I g= uess) is part of the GML 3.1.1

 <= /p>

I was not proposing to us= e 6350 for geolocation, but instead for the contact and schedule informatio= n.

 <= /p>

- =          gabor<= /span>

 <= /p>

 <= /p>

From: ext Rose= n, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Tuesday, September 25, 2012 10:59 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: paws@ietf.org
Subject: Re: [paws] JSON encoding

 

<as individual>

Use 5194, which is based on OGC's GML in preference = to 6350.  Among other things, you may need the ability to encode uncer= tainty of location.

 

You could consider the Geo URI (RFC5870), but it has= the same uncertainty problem.

 

Brian

 

 

 

On Sep 25, 2012, at 1:41 PM, Gabor.Bajko@nokia.com wrote:



I scanned through the data which has to= be carried by PAWS, and it looks to me that there are two RFCs which we ma= y consider re-using: RFC5491 defines the xml encoding for geo-location, I did not find a JSON encoding for it. The other one is vCar= d, RFC6350. There is a so called xCard, RFC6351, the xml representation of = vCard, but again, I have not found a JSON encoding for vCard. vCard seems t= o be able to handle contact information, schedule, etc, but there are obviously other data fields, like antenna par= ameters, which need to be defined in PAWS.

 

First, I’d like to get some opini= ons on whether the reuse of the data structures defined in the above two RF= Cs is generally considered a good idea or not. If we want to reuse them, we’ll need to define a JSON encoding for those. The alternativ= e is to define the whole data structure with JSON encoding in PAWS.

 

I’d like to hear opinions on whic= h way is more feasible.

 

-       &nb= sp;  Gabor

 

 

_____________________________________= __________
paws mailing list
paws@ietf.org=
https://www.ietf.org/mailman/listinfo/paws

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47602035658008AM1MPN1006mg_-- From teco@inf-net.nl Tue Sep 25 14:06:29 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFD321F8688 for ; Tue, 25 Sep 2012 14:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhqk7GwcJhqW for ; Tue, 25 Sep 2012 14:06:26 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A96FF21F8685 for ; Tue, 25 Sep 2012 14:06:25 -0700 (PDT) Received: by eekd4 with SMTP id d4so1400752eek.31 for ; Tue, 25 Sep 2012 14:06:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Ah0NYruYeVhu5qscVozQzJv3bVSO5VIsYRGrgHRqfo4=; b=A4OtwzBvOGbejdtAuxeJmvci0p/uhdPWgwb+U4NRYJCvQHDGedWWEfJaUscWujxyIE I3U9FyAPqoAUBLiypmGZj7gR2MFzBsXBee0TV0VEIfRlC8X3rpGLsq7wUJ1G1QOt6AKH BghAnPYmhpcSSvjg8a/Mu60X9EiOmBqC30sUCch1mPlhRQDz9YUBFuBqB7OvWWj+cy7/ xp/TpZV2ybEmq/z0Jpp0CuGZOoxMeS2uhVJC3HG5oGzNpRcKQLook8JKEcdmY75fVHpe fG8V1PFVomevNEbDekQtYXlRfuiQkXErdjdlnqPeVMGxoebnSHIQbDMFnKy9LDlZT2bK GBUA== Received: by 10.14.180.68 with SMTP id i44mr22527410eem.20.1348607184811; Tue, 25 Sep 2012 14:06:24 -0700 (PDT) Received: from [10.175.173.28] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id i41sm3976705eem.7.2012.09.25.14.06.24 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 14:06:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6D6F06C1-18CF-4B25-B44D-BDC709DF65DF" From: Teco Boot In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> Date: Tue, 25 Sep 2012 23:06:22 +0200 Message-Id: <9FC9B259-33D1-4D02-B16E-3F0C888469BC@inf-net.nl> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnlDpkD7fuT6uGQARRwRUy6ygn+0cSFwYkYq1xkMEVhF7pXgDtP250hihXTrEnGMyPNGKTE Cc: paws@ietf.org Subject: Re: [paws] JSON encoding X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 21:06:29 -0000 --Apple-Mail=_6D6F06C1-18CF-4B25-B44D-BDC709DF65DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Op 25 sep. 2012, om 19:41 heeft = het volgende geschreven: > I scanned through the data which has to be carried by PAWS, and it = looks to me that there are two RFCs which we may consider re-using: = RFC5491 defines the xml encoding for geo-location, I did not find a JSON = encoding for it. The other one is vCard, RFC6350. There is a so called = xCard, RFC6351, the xml representation of vCard, but again, I have not = found a JSON encoding for vCard. vCard seems to be able to handle = contact information, schedule, etc, but there are obviously other data = fields, like antenna parameters, which need to be defined in PAWS. > =20 > First, I=92d like to get some opinions on whether the reuse of the = data structures defined in the above two RFCs is generally considered a = good idea or not. If we want to reuse them, we=92ll need to define a = JSON encoding for those. The alternative is to define the whole data = structure with JSON encoding in PAWS. I prefer to use current encoding as much as possible, with as a goal a = clean and straightforward data structure. With compact messages in mind. Teco > =20 > I=92d like to hear opinions on which way is more feasible. > =20 > - Gabor > =20 > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_6D6F06C1-18CF-4B25-B44D-BDC709DF65DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Op 25 sep. 2012, om 19:41 heeft = <Gabor.Bajko@nokia.com>= <Gabor.Bajko@nokia.com> het = volgende geschreven:

I scanned through the data = which has to be carried by PAWS, and it looks to me that there are two = RFCs which we may consider re-using: RFC5491 defines the xml encoding = for geo-location, I did not find a JSON encoding for it. The other one = is vCard, RFC6350. There is a so called xCard, RFC6351, the xml = representation of vCard, but again, I have not found a JSON encoding for = vCard. vCard seems to be able to handle contact information, schedule, = etc, but there are obviously other data fields, like antenna parameters, = which need to be defined in PAWS.
 
First, I=92d like to get some = opinions on whether the reuse of the data structures defined in the = above two RFCs is generally considered a good idea or not. If we want to = reuse them, we=92ll need to define a JSON encoding for those. The = alternative is to define the whole data structure with JSON encoding in = PAWS.

I prefer = to use current encoding as much as possible, with as a goal a clean and = straightforward data structure. With compact messages in = mind.

Teco

 
I=92d like to hear opinions on = which way is more feasible.
- Gabor
 
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 00:53:07 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020357BB008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Those are simplistic, not suitable for our purpose. - gabor From: ext Vincent Chen [mailto:vchen@google.com] Sent: Tuesday, September 25, 2012 11:03 AM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] JSON encoding FYI. http://json-schema.org/ Version 4 of the IETF draft is active. - This link references JSON schemas for Geographic Coordinate and Card. I have mixed feelings about re-using when the referenced schema is complex = and contains many fields that might not make sense for PAWS. We would end u= p documenting which portions of those schemas are required, optional, etc. I think that's a case-by-case decision. On Tue, Sep 25, 2012 at 10:41 AM, > wrote: I scanned through the data which has to be carried by PAWS, and it looks to= me that there are two RFCs which we may consider re-using: RFC5491 defines= the xml encoding for geo-location, I did not find a JSON encoding for it. = The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the x= ml representation of vCard, but again, I have not found a JSON encoding for= vCard. vCard seems to be able to handle contact information, schedule, etc= , but there are obviously other data fields, like antenna parameters, which= need to be defined in PAWS. First, I'd like to get some opinions on whether the reuse of the data struc= tures defined in the above two RFCs is generally considered a good idea or = not. If we want to reuse them, we'll need to define a JSON encoding for tho= se. The alternative is to define the whole data structure with JSON encodin= g in PAWS. I'd like to hear opinions on which way is more feasible. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020357BB008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Those are simplistic, not= suitable for our purpose. - gabor

 <= /p>

From: ext Vinc= ent Chen [mailto:vchen@google.com]
Sent: Tuesday, September 25, 2012 11:03 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: paws@ietf.org
Subject: Re: [paws] JSON encoding

 

FYI. http:/= /json-schema.org/ Version 4 of the IETF draft is active.

 - This link references JSON schemas for Geogra= phic Coordinate and Card.

 

I have mixed feelings about re-using when the refere= nced schema is complex and contains many fields that might not make sense f= or PAWS. We would end up documenting which portions of those schemas are re= quired, optional, etc.

I think that's a case-by-case decision.

 

On Tue, Sep 25, 2012 at 10:41 AM, <Gabor.Bajko@nokia.com> = wrote:

I scanned through the data which has to be carried by PAWS, and it= looks to me that there are two RFCs which we may consider re-using: RFC549= 1 defines the xml encoding for geo-location, I did not find a JSON encoding for it. The other one is vCard, RFC6350. Th= ere is a so called xCard, RFC6351, the xml representation of vCard, but aga= in, I have not found a JSON encoding for vCard. vCard seems to be able to h= andle contact information, schedule, etc, but there are obviously other data fields, like antenna parameters, w= hich need to be defined in PAWS.

 

First, I’d like to get some opinions on whether the reuse of= the data structures defined in the above two RFCs is generally considered = a good idea or not. If we want to reuse them, we’ll need to define a JSON encoding for those. The alternative is t= o define the whole data structure with JSON encoding in PAWS.

 

I’d like to hear opinions on which way is more feasible.

 

-          Gabor

 

 


_______________________________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws



 

--
-vince

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476020357BB008AM1MPN1006mg_--