From vchen@google.com Wed Oct 3 20:21: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 9FB161F0C86 for ; Wed, 3 Oct 2012 20:21:07 -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=[AWL=-0.000, 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 UWqtY6oizedn for ; Wed, 3 Oct 2012 20:21:07 -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 2F17B1F0C80 for ; Wed, 3 Oct 2012 20:21:02 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so127236qab.10 for ; Wed, 03 Oct 2012 20:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=Z4lvCYh00cuGEeyaeY8sI/5eJI2eQ+G8O4EzNpzDUqg=; b=U13xyts4qoWYdEtJGNyDF/xB9dyKDHP5zn4Jhie/M0/KWkymgs/4eoTPmD7cPMdImf Al9yq1R2fEcw5+AO+dcMky3Kw5qChtfJXsq5jAUIDaH81oMXkp19j+zuDGhWHmuFRLSS 6N3teylaILlwSOamYetfHKYKOWIMvNkdSHIEHv3CgK8rj4prVTdkY/7YU7u48lprfGDs P+HXbNbz6JA4eLaiPsC5vHGHtFsblTyLS4cV09VS7jmWFR0iIgpjL6T0w4inrZwF1+2P FyMI6meF1bOhg+D9gT02kQv3tOIEMQ9qICg97ovs/8fMtuEsuF8074HkQkVDHZyAKwsP bc9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=Z4lvCYh00cuGEeyaeY8sI/5eJI2eQ+G8O4EzNpzDUqg=; b=htD8PO4kPmay9+v7A3L/5pShZd3fsWLIiQI3hS30NHGBQYwtu066M+AfUaGs8ZU7xH M1nv6xVeYHCJ0suMRaY1ediHsRr0VpyTvO4hVnNn50We7haaVJyLWrnlUF+3wv9jbttU wiZF8/Oebx8nuQn4Nqzg8McwOwaDXdEudisLEnyzFMSIbydwOMAkZ+RGNNYoVSE6GSb/ 3PejHX4bOqvSZLRgA9y/E7A6V1I4DoEPslu6bYltOLmKXnAlOpfhcvs7ZyHLqmV2xURQ 7BOgGEqpFmriRWYAFI2eHQa+jiDtBrQAQMyYKUwKalLivL4GtiET83PNAGW2HyBY6Pin 0NRg== MIME-Version: 1.0 Received: by 10.224.180.7 with SMTP id bs7mr10577747qab.37.1349320862304; Wed, 03 Oct 2012 20:21:02 -0700 (PDT) Received: by 10.229.234.9 with HTTP; Wed, 3 Oct 2012 20:21:02 -0700 (PDT) Date: Wed, 3 Oct 2012 20:21:02 -0700 Message-ID: From: Vincent Chen To: paws@ietf.org Content-Type: multipart/alternative; boundary=20cf302efcd6af87a604cb333e6d X-System-Of-Record: true X-Gm-Message-State: ALoCoQlfyatMzC2gf1XcRp5h939Ym8e9SbolK+vsFnF6bdQ9J1xSdhnGQOw890oeeEDgtAWpdnAI5wXElyePo6i7jHKOATt1b5QpNQUx00SNdUrae8rg5dncJZ/WfM3TlFPFD09ItSxkaVekWVZiwJPSYVmTRd8Sc/JDyPqoOJVOXm90s75ou7nsUpGfxJa9Cv3tLi3rJtvF Subject: [paws] New draft for PAWS protocol 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, 04 Oct 2012 03:21:07 -0000 --20cf302efcd6af87a604cb333e6d Content-Type: text/plain; charset=ISO-8859-1 Hi All, We have submitted a draft for the PAWS protocol specification that represents a merge of the non-controversial portions of the two documents presented at the Vancouver F2F. You can find it at: http://tools.ietf.org/html/draft-vchen-paws-protocol-00 Summary of changes: - Be more explicit about required vs optional vs "depends on regulatory domain" - Describe the "Data Models" in a more hierarchical fashion and making it more clear where extension points are located to address regulatory differences - General replacement of "channel" with "frequency" or "spectrum", when appropriate. This version does not include message encoding or specific error codes. -- -vince Vincent Chen Google, Inc. --20cf302efcd6af87a604cb333e6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

We have submitted a draft for the PAWS protocol = specification that represents a merge of the non-controversial portions
of the two documents presented at the Vancouver F2F. You can find it= at:

http://tools.ietf.org/html/draft-vchen-paws-protocol-00

Summary of changes:
=A0-=A0Be more explici= t about required vs optional vs "depends on regulatory domain" =A0- Describe the "Data Models" in a more hierarchical fashion=A0= and making it more clear
=A0 =A0where extension points=A0are loca= ted to address regulatory differences
=A0- General replacement of= "channel" with "frequency" or "spectrum", wh= en
=A0 =A0appropriate.

This version does not inc= lude message encoding or specific error codes.

--
-= vince
Vincent Chen
Google, Inc.
--20cf302efcd6af87a604cb333e6d-- From Gabor.Bajko@nokia.com Wed Oct 3 21:35:48 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 5C2D41F0C8C for ; Wed, 3 Oct 2012 21:35:48 -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 JLQ1RgmXwRcd for ; Wed, 3 Oct 2012 21:35:46 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 52F8721F853B for ; Wed, 3 Oct 2012 21:35:45 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q944Zfoq026971; Thu, 4 Oct 2012 07:35:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Oct 2012 07:35:41 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.144]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0309.003; Thu, 4 Oct 2012 06:35:40 +0200 From: To: , Thread-Topic: New draft for PAWS protocol Thread-Index: AQHNod9L4ggZtTERm0OKj9fadgGKBpeojpnQ Date: Thu, 4 Oct 2012 04:35:39 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A@008-AM1MPN1-006.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.118.234] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2012 04:35:41.0590 (UTC) FILETIME=[B5F69360:01CDA1E9] X-Nokia-AV: Clean Subject: Re: [paws] New draft for PAWS protocol 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, 04 Oct 2012 04:35:48 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, thanks Vince. As a next step, I'd like to ask the WG to review it and send to the list an= y major problem identified with the text in this draft. Then, I'd like to ask the WG to adopt it as a wg document. - Gabor From: ext Vincent Chen [mailto:vchen@google.com] Sent: Wednesday, October 03, 2012 8:21 PM To: paws@ietf.org Cc: Bajko Gabor (Nokia-CIC/SiliconValley) Subject: New draft for PAWS protocol Hi All, We have submitted a draft for the PAWS protocol specification that represen= ts a merge of the non-controversial portions of the two documents presented at the Vancouver F2F. You can find it at: http://tools.ietf.org/html/draft-vchen-paws-protocol-00 Summary of changes: - Be more explicit about required vs optional vs "depends on regulatory do= main" - Describe the "Data Models" in a more hierarchical fashion and making it = more clear where extension points are located to address regulatory differences - General replacement of "channel" with "frequency" or "spectrum", when appropriate. This version does not include message encoding or specific error codes. -- -vince Vincent Chen Google, Inc. --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, thanks Vince.

As a next step, I’d= like to ask the WG to review it and send to the list any major problem ide= ntified with the text in this draft.

Then, I’d like to a= sk the WG to adopt it as a wg document.

- =          Gabor<= /span>

 <= /p>

 <= /p>

From: ext Vinc= ent Chen [mailto:vchen@google.com]
Sent: Wednesday, October 03, 2012 8:21 PM
To: paws@ietf.org
Cc: Bajko Gabor (Nokia-CIC/SiliconValley)
Subject: New draft for PAWS protocol

 

Hi All,

 

We have submitted a draft for the PAWS protocol spec= ification that represents a merge of the non-controversial portions

of the two documents presented at the Vancouver F2F.= You can find it at:

 

 

Summary of changes:

 - Be more explicit about required vs opti= onal vs "depends on regulatory domain"

 - Describe the "Data Models" in a mo= re hierarchical fashion and making it more clear

   where extension points are located= to address regulatory differences

 - General replacement of "channel" w= ith "frequency" or "spectrum", when

   appropriate.

 

This version does not include message encoding or sp= ecific error codes.

 

--
-vince

Vincent Chen

Google, Inc.

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Thu Oct 4 14:11:05 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 9328921F860F for ; Thu, 4 Oct 2012 14:11:05 -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 Ac-qDIMQB8Xx for ; Thu, 4 Oct 2012 14:11:03 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E4F7021F85C7 for ; Thu, 4 Oct 2012 14:11:00 -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 q94LAuiG019212 for ; Fri, 5 Oct 2012 00:10:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Oct 2012 00:10:56 +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; Thu, 4 Oct 2012 23:10:55 +0200 From: To: Thread-Topic: [paws] JSON encoding Thread-Index: Ac2bQo0v9GArVN/qQa2hBIgDop7xT///6FmA//+2cjD/8TsrkA== Date: Thu, 4 Oct 2012 21:10:54 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760204EDF9@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602035658@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47602035658@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_1ECAFF543A2FED4EA2BEB6CACE08E4760204EDF9008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Oct 2012 21:10:56.0754 (UTC) FILETIME=[BEF97D20:01CDA274] X-Nokia-AV: Clean 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: Thu, 04 Oct 2012 21:11:05 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760204EDF9008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to repost my request for volunteers to define a json encoding for = RFC5491 (geolocation) and RFC6350 (vCard). These could/should be separate documents, referenced by the data structure = to be defined in the main solution document. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, September 25, 2012 1:32 PM To: Brian.Rosen@neustar.biz Cc: paws@ietf.org Subject: Re: [paws] JSON encoding 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_1ECAFF543A2FED4EA2BEB6CACE08E4760204EDF9008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to repost = my request for volunteers to define a json encoding for RFC5491 (geolocatio= n) and RFC6350 (vCard).

These could/should be sep= arate documents, referenced by the data structure to be defined in the main= solution document.

 <= /p>

- =          Gabor<= /span>

 <= /p>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, September 25, 2012 1:32 PM
To: Brian.Rosen@neustar.biz
Cc: paws@ietf.org
Subject: Re: [paws] JSON encoding

 

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@neu= star.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_1ECAFF543A2FED4EA2BEB6CACE08E4760204EDF9008AM1MPN1006mg_-- From vchen@google.com Fri Oct 5 09:10: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 9549621F876F for ; Fri, 5 Oct 2012 09:10:01 -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 UH+Zfap8DBib for ; Fri, 5 Oct 2012 09:10:00 -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 8E92121F875A for ; Fri, 5 Oct 2012 09:10:00 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so393336qab.10 for ; Fri, 05 Oct 2012 09:10:00 -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=QKu/MovsTbiiC7QqldwxfDfsCiaW9sbA0C7V5z6jD2Q=; b=MJB5yoBwkCqUVLZcKg4P1hcOQCb41fr5t4u2GsZtUdTxcI9RjauwE5XAmzqKtXaJxA SyritZE01LtqUtu6UQV1CyqpVdqTQMOEJPK5+Qe7OKAoPWfpkCF24CRCqmk8HUwmRifD u6YLCNFbcZtjTzrEyg4o25xpiWz/DMMjQLeNP2WL5FjzIDXFplrPbofKLh6/D32wVNJV UZYWFFdZ9mc7iWPvJid/qPxpfWSBDhb7ccoYDNqtEy73nQBN5ZtZskZM0toqGvEzTkEy w3MHpXAv9ZZ2fiHyPK3QNw3PqLc/E72yvohHBwpN+EbBsJmY9WVs8LNrAttQdivQGfp6 TBTg== 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=QKu/MovsTbiiC7QqldwxfDfsCiaW9sbA0C7V5z6jD2Q=; b=jUNAAVMrtgMQv2Vj96g/oL80h7mv24wzPi01nZweyw90I3n2EiPAIsRpo4w8RlD/fX h3YzhHGn8s8oXSVmsehBwss/i1Xq0EHiZeOZEuKG9o/BohYiG70KkhygBGCCW7BDXnqZ VcR9SeM+NZ4LQo0TrTF6Hi81zkhIywgNy2xnAizANAkIotUFWBhRcFEe7PSfumdoVZPc r/7gzYi+ByJApY4Fc3EttxyFMIMI1YnZ6nohvJcUbuk+VazIGnhmpzAunqYHDlZjG4nw nvTbf4IKpC8O2RTelUoQ4qH7mJdC+rfxsFMb5NrUfUK691aRZUGMyaFC+GvIBQF9g5XW taHg== MIME-Version: 1.0 Received: by 10.224.180.7 with SMTP id bs7mr17954532qab.37.1349453399785; Fri, 05 Oct 2012 09:09:59 -0700 (PDT) Received: by 10.229.234.9 with HTTP; Fri, 5 Oct 2012 09:09:59 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760204EDF9@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760203557B@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602035658@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760204EDF9@008-AM1MPN1-006.mgdnok.nokia.com> Date: Fri, 5 Oct 2012 09:09:59 -0700 Message-ID: From: Vincent Chen To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary=20cf302efcd689000f04cb521a8e X-System-Of-Record: true X-Gm-Message-State: ALoCoQmadhKAbc1jx6p/zGyTNRiamKzGvesTEtCbJ/1z3R0mRN8qi2ghott9uArMsi6owPvvIs340heoDG43ATdfG69QI8xN9Obms872p6HsPBj5nH6qYfSCfYhjP14f65IolW531bIrtnZ1Us5tU8byKjOx3YDt5sloJW9IBRzcDXw74Nhqo4OfvuTNmcNFvfwyFaKxfYWI 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: Fri, 05 Oct 2012 16:10:01 -0000 --20cf302efcd689000f04cb521a8e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Did RFC5870 also come up before as a possible model? It seems simpler and captures (longitude, latitude, altitude, uncertainty). It seems to fit our needs. I think it may have been rejected before for not having uncertainty, but it actually does. As for vCard, I think we can go for a straight-forward encoding to JSON, but it appears to be much more complex than what we would need for PAWS (maybe). It contains things like Photo, Birthday, Anniversary, etc. Should we select a subset? On Thu, Oct 4, 2012 at 2:10 PM, wrote: > I=92d like to repost my request for volunteers to define a json encoding > for RFC5491 (geolocation) and RFC6350 (vCard).**** > > These could/should be separate documents, referenced by the data structur= e > to be defined in the main solution document.**** > > ** ** > > **- **Gabor**** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Bajko Gabor (Nokia-CIC/SiliconValley) > *Sent:* Tuesday, September 25, 2012 1:32 PM > *To:* Brian.Rosen@neustar.biz > > *Cc:* paws@ietf.org > *Subject:* Re: [paws] JSON encoding**** > > ** ** > > 5194 is an unrelated RFC, did you mean 5491 instead? That is what I also > proposed for geolocation.**** > > That has all the things Ben is looking for, including uncertainty, > altitude, 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 > contact 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 > 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, 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**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --20cf302efcd689000f04cb521a8e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Did RFC5870 also come up before as a possible model?

It seems = simpler and captures (longitude, latitude, altitude, uncertainty). It seems= to fit our needs.

I think it may have been reject= ed before for not having uncertainty, but it actually does.

As for vCard, I think we can go for a straight-forward = encoding to JSON, but it appears to be much more complex than what we would= need for PAWS (maybe).
It contains things like Photo, Birthday, = Anniversary, etc. Should we select a subset?



On Thu, Oct 4, 2012 = at 2:10 PM, <Gabor.Bajko@nokia.com> wrote:

I=92d like to repost my r= equest for volunteers to define a json encoding for RFC5491 (geolocation) a= nd RFC6350 (vCard).

These could/should be sep= arate documents, referenced by the data structure to be defined in the main= solution document.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor<= /span>

=A0<= /p>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, September 25, 2012 1:32 PM
To: Bri= an.Rosen@neustar.biz


Cc: paws@ietf.org=
Subject: Re: [paws] JSON encoding

=A0

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 =A0for, including uncertainty, altitude, the datum ID (I gues= s) is part of the GML 3.1.1

=A0<= /p>

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

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor<= /span>

=A0<= /p>

=A0<= /p>

From: ext Rose= n, Brian [mail= to: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

=A0

<as individual>

Use 5194, which is based on OGC's GML in prefere= nce to 6350. =A0Among other things, you may need the ability to encode unce= rtainty of location.

=A0

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

=A0

Brian

=A0

=A0

=A0

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

=A0

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.

=A0

First, I=92d like to get some opinions = on whether the reuse of the data structures defined in the above two RFCs i= s 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.

=A0

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

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Gabor

=A0

=A0

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

=A0


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




--
-vince
--20cf302efcd689000f04cb521a8e-- From vchen@google.com Wed Oct 10 21:54: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 4DA7E21F8620 for ; Wed, 10 Oct 2012 21:54:00 -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 uEoDJWcdS7sf for ; Wed, 10 Oct 2012 21:53:59 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE5021F861E for ; Wed, 10 Oct 2012 21:53:59 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g10so388555ghb.31 for ; Wed, 10 Oct 2012 21:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=7hfGPZRQnQpcupv51xE67Ye9WpniUxnN1S1akLGDFBg=; b=emzNnsvhahQeY2ZCUrQYpuemee6/vBggLuL81tzts09QwY0MVMUfbo+MXTCdl04+Hm 2xgJEcSRf0nOWj9S8Dp+d3UOqZ/zRV4Vid0T+tQwXNtN2qcHA9dBrF2h38asKVOJgMGh Dvg7jH4nyweiDsakDIFQe7d+6wpgK+zPO970wPzzi40vsNp7ZqO2yFie+zqURYs4+9NF 0/10eSQwN4Eo+/N0gRvi62kIGkBh/retyb5/3y7TZtxLDjT0nnexTcFalxXQ81C53jim j/cRY7fly0Urp3FOKs5R7FQRzow8EBjGJTGVx52aLaysfDgYFZMjni5dH5atuW8idslY oqyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=7hfGPZRQnQpcupv51xE67Ye9WpniUxnN1S1akLGDFBg=; b=jJuVFpTnR4TBy4K75M+AdZ4KM7QvL8JBJamnnWQrDGL9w1kkxX59utSyHUtB+EQMWq NgSZL4t/Zzddd7c6giLtb8GyDMiVapxMIJ5JKpMReXdyxUtb6wROBZsIcS6cfyNetj02 LTUyTUX6KHm81o1IUpu31vw7kEsRekCynKEMpMLZB+swlxamKYtxNe/S2MH5XZcoTBGf LAfviXmPZk0YqF7gsy2BD/1vMGxEDZHzifhMo49bWtDurn1FBH5H5f4xEzDqVJaiJ2yF R2lgU4nA+hV45yzuqdamRVFDZwLwjScBzRm/tDN1gaf/Z+73jfDbv+C70bVYwOwXI5Px avgg== MIME-Version: 1.0 Received: by 10.236.112.179 with SMTP id y39mr24879652yhg.67.1349931238819; Wed, 10 Oct 2012 21:53:58 -0700 (PDT) Received: by 10.101.75.19 with HTTP; Wed, 10 Oct 2012 21:53:58 -0700 (PDT) Date: Wed, 10 Oct 2012 21:53:58 -0700 Message-ID: From: Vincent Chen To: paws@ietf.org Content-Type: multipart/alternative; boundary=20cf3011e1f3f6066204cbc15b99 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmEpadF9UcHGRl2RxZKIMYqa7hG4GfbG5HU67ngGTZ9NdMNc+X3JP6Mtqc+iCPjAcqrrssM8WYTf/vgJIoNApDmMNePtB3bsIpLYIkWzFuzwoRvD0N3ras8FX0ftfDFzP1/Gs4kBGGrgNoMdV15p+5jDr0Z6lfTR6ACbA7tuVDlnwRIkGTBKJ3NjxHTJyIuzXCp4duc Subject: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 04:54:00 -0000 --20cf3011e1f3f6066204cbc15b99 Content-Type: text/plain; charset=ISO-8859-1 All, The various versions of the proposed drafts of the PAWS protocol tended to distinguish between "device location" and "antenna height". I think we should combine them into a single 3-D location of the radiation center of (the antenna of) the device. Does that sound right? The proposed draft-vchen-paws-protocol-00 defines the following parameters for location and height: latitude longitude locationUncertainty locationConfidence height heightType heightUncertainty This is very close to the fields defined by RFC 6225, which has the parameters: latitude latitudeUncertainty longitude longitudeUncertainty altitude altitudeUncertainty altitudeType Should PAWS reference RFC 6225 and list the following differences? - The "altitudeType" should be "above means sea level" (WGS84) or "above ground", instead of the ones defined in the RFC. - Add confidence values along each axis. If this acceptable, then we can think about defining JSON encoding of RFC 6225 for use by PAWS. Thanks. -- -vince --20cf3011e1f3f6066204cbc15b99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

The various versions of the proposed drafts of the = PAWS protocol tended to distinguish between "device location" and= "antenna height".

I think we should com= bine them into a single 3-D location of the radiation center of (the antenn= a of) the device.

Does that sound right?

The pro= posed draft-vchen-paws-protocol-00 defines the following parameters for loc= ation and height:

=A0 latitude
=A0 longi= tude
=A0 locationUncertainty
=A0 locationConfidence
=A0 height
=A0 heightType
=A0 heightUncerta= inty

This is very close to the fields =A0defined= =A0by RFC 6225, which has the parameters:

=A0latitude
=A0latitudeUncertainty
= =A0longitude
=A0longitudeUncertainty
=A0altitude
<= div>=A0altitudeUncertainty
=A0altitudeType

Should PAWS reference RFC 6225 and list the following differences?

=A0- The "altitudeType" should be "above= means sea level" (WGS84) or "above ground", instead of the = ones defined in the RFC.

=A0- Add confidence value= s along each axis.

If this acceptable, then we can think about defining JS= ON encoding of RFC 6225 for use by PAWS.

Thanks.

--
-vince
--20cf3011e1f3f6066204cbc15b99-- From brian.rosen@neustar.biz Thu Oct 11 03:08: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 7C89321F85AE for ; Thu, 11 Oct 2012 03:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 4MAmAsRo9z1v for ; Thu, 11 Oct 2012 03:08:00 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1D98821F85AC for ; Thu, 11 Oct 2012 03:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1349950024; x=1665287802; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Rn0YX4b3oqZXFuwF/bZ8k WGXs96exe+Ee00Y51GajKc=; b=dZUPs0k49v1pMMIiTG4y5Ds/C2R8Jf+k2Poki ii9ATPHLf+5QBXp6FvhBpEKhCNaE0lpJlslcZVktPy6jsH9jg== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.10535465; Thu, 11 Oct 2012 06:07:03 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 11 Oct 2012 06:07:56 -0400 From: "Rosen, Brian" To: Vincent Chen Date: Thu, 11 Oct 2012 06:07:57 -0400 Thread-Topic: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? Thread-Index: Ac2nmEizSin3krvET6KYv6hlsrx8GA== Message-ID: <4FA54726-4020-4AC6-9C83-9BB2CEE85CF3@neustar.biz> References: 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: 18WWyrnRb23Wv+jVrm0D8w== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 10:08:01 -0000 We need both I think, because of the way the regulations are written. I do= n't think there is a simple way to convert that would be acceptable. In th= eory, if we knew the terrain height at the location accurately enough, we c= ould calculate what we need, but that is an onerous requirement I think. Brian =20 On Oct 11, 2012, at 12:53 AM, Vincent Chen wrote: > All, >=20 > The various versions of the proposed drafts of the PAWS protocol tended t= o distinguish between "device location" and "antenna height". >=20 > I think we should combine them into a single 3-D location of the radiatio= n center of (the antenna of) the device. >=20 > Does that sound right? >=20 > The proposed draft-vchen-paws-protocol-00 defines the following parameter= s for location and height: >=20 > latitude > longitude > locationUncertainty > locationConfidence >=20 > height > heightType > heightUncertainty >=20 > This is very close to the fields defined by RFC 6225, which has the para= meters: >=20 > latitude > latitudeUncertainty > longitude > longitudeUncertainty > altitude > altitudeUncertainty > altitudeType >=20 > Should PAWS reference RFC 6225 and list the following differences? >=20 > - The "altitudeType" should be "above means sea level" (WGS84) or "above= ground", instead of the ones defined in the RFC. >=20 > - Add confidence values along each axis. >=20 > If this acceptable, then we can think about defining JSON encoding of RFC= 6225 for use by PAWS. >=20 > Thanks. >=20 > --=20 > -vince > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Thu Oct 11 05:40: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 703AB21F875E for ; Thu, 11 Oct 2012 05:40: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=[AWL=0.000, 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 IVN7rkVHe2Ea for ; Thu, 11 Oct 2012 05:40:20 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id BA55E21F86F0 for ; Thu, 11 Oct 2012 05:40:19 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 11 Oct 2012 08:40:18 -0400 From: Peter Stanforth To: "Rosen, Brian" , Vincent Chen Date: Thu, 11 Oct 2012 08:40:15 -0400 Thread-Topic: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? Thread-Index: Ac2nrZGdIMDJHzTpT4+lf2XcTul3wA== Message-ID: In-Reply-To: <4FA54726-4020-4AC6-9C83-9BB2CEE85CF3@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 12:40:20 -0000 Agreed. We need to be able to resolve AGL, HAAT, location and maybe other criteria based on the regulators methods. I am not sure a single 3D location will be acceptable. On ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, Brian" wrote: >We need both I think, because of the way the regulations are written. I >don't think there is a simple way to convert that would be acceptable. >In theory, if we knew the terrain height at the location accurately >enough, we could calculate what we need, but that is an onerous >requirement I think. > >Brian >=20 >On Oct 11, 2012, at 12:53 AM, Vincent Chen wrote: > >> All, >>=20 >> The various versions of the proposed drafts of the PAWS protocol tended >>to distinguish between "device location" and "antenna height". >>=20 >> I think we should combine them into a single 3-D location of the >>radiation center of (the antenna of) the device. >>=20 >> Does that sound right? >>=20 >> The proposed draft-vchen-paws-protocol-00 defines the following >>parameters for location and height: >>=20 >> latitude >> longitude >> locationUncertainty >> locationConfidence >>=20 >> height >> heightType >> heightUncertainty >>=20 >> This is very close to the fields defined by RFC 6225, which has the >>parameters: >>=20 >> latitude >> latitudeUncertainty >> longitude >> longitudeUncertainty >> altitude >> altitudeUncertainty >> altitudeType >>=20 >> Should PAWS reference RFC 6225 and list the following differences? >>=20 >> - The "altitudeType" should be "above means sea level" (WGS84) or >>"above ground", instead of the ones defined in the RFC. >>=20 >> - Add confidence values along each axis. >>=20 >> If this acceptable, then we can think about defining JSON encoding of >>RFC 6225 for use by PAWS. >>=20 >> Thanks. >>=20 >> --=20 >> -vince >> _______________________________________________ >> 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 Thu Oct 11 10:19: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 C8EE021F867C for ; Thu, 11 Oct 2012 10:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.793 X-Spam-Level: X-Spam-Status: No, score=-0.793 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 dtxsyOj0moKd for ; Thu, 11 Oct 2012 10:19:44 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id F18CC21F8674 for ; Thu, 11 Oct 2012 10:19:43 -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=/lW2alAe+5KggRPyJgdUQ3/sbmQNm4e7P8//ILRLCCs=; b=nduSs+BWLza2d4FItS53FRUvnRdD23842ZFLif2FjSeDTxO+sXhgoPtxRtkNk++9ZTo/5nsuVfS5TJ7PSFL/Q60dJ/M0D84qowCBlzbtq+iBGJorXLdU7p5akG2WpM0V; Received: from [64.74.213.174] (port=51621 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TMMQ8-0006kL-8J for paws@ietf.org; Thu, 11 Oct 2012 12:19:40 -0500 Message-ID: <5076FFB7.4030701@blindcreek.com> Date: Thu, 11 Oct 2012 10:19:51 -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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 17:19:44 -0000 I would not suggest specifying a method to resolve HAAT, as there are many methods which may be used and I would not bet on every regulatory region agreeing on a single method. For each Height (altitude) provide a way to indicate what it is as suggested bellow and a way to identify the reference model or regional method (like regulator ID?). At the moment, FCC specifies the location is of the device, while OfCom specifies the location is of the antenna. The later makes more sense to a radio guy worried about interference footprint. The first seems to assume the device and antenna are close enough to each other (within the allowed uncertainty which is currently +-50m). OfCom and FCC currently specify WGS84. This may change in the future if the as the WGS model has been and will be updated from time to time. OfCom gives specific requirements for how accuracy is specified (and a 95% confidence level). Where antenna height is required by OfCom it is specified as above ground level. FCC has specified HAAT and has already revised at least once how HAAT is to be determined (and I expect it to change again). OfCom identifies other antenna characteristics that may be communicated between a device and the database as well including directionality and orientation, polarisation (I am quoting OfCom here), and if the antenna location is indoor or outdoor. Hope this helps Ben On 10/11/2012 5:40 AM, Peter Stanforth wrote: > Agreed. > We need to be able to resolve AGL, HAAT, location and maybe other criteria > based on the regulators methods. I am not sure a single 3D location will > be acceptable. > > On ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, Brian" > wrote: > >> We need both I think, because of the way the regulations are written. I >> don't think there is a simple way to convert that would be acceptable. >> In theory, if we knew the terrain height at the location accurately >> enough, we could calculate what we need, but that is an onerous >> requirement I think. >> >> Brian >> >> On Oct 11, 2012, at 12:53 AM, Vincent Chen wrote: >> >>> All, >>> >>> The various versions of the proposed drafts of the PAWS protocol tended >>> to distinguish between "device location" and "antenna height". >>> >>> I think we should combine them into a single 3-D location of the >>> radiation center of (the antenna of) the device. >>> >>> Does that sound right? >>> >>> The proposed draft-vchen-paws-protocol-00 defines the following >>> parameters for location and height: >>> >>> latitude >>> longitude >>> locationUncertainty >>> locationConfidence >>> >>> height >>> heightType >>> heightUncertainty >>> >>> This is very close to the fields defined by RFC 6225, which has the >>> parameters: >>> >>> latitude >>> latitudeUncertainty >>> longitude >>> longitudeUncertainty >>> altitude >>> altitudeUncertainty >>> altitudeType >>> >>> Should PAWS reference RFC 6225 and list the following differences? >>> >>> - The "altitudeType" should be "above means sea level" (WGS84) or >>> "above ground", instead of the ones defined in the RFC. >>> >>> - Add confidence values along each axis. >>> >>> If this acceptable, then we can think about defining JSON encoding of >>> RFC 6225 for use by PAWS. >>> >>> Thanks. >>> >>> -- >>> -vince >>> _______________________________________________ >>> 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 nbravin@earthlink.net Thu Oct 11 10:36:28 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 D878621F8685 for ; Thu, 11 Oct 2012 10:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 HJMARVzRAutP for ; Thu, 11 Oct 2012 10:36:28 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id EB70021F85C2 for ; Thu, 11 Oct 2012 10:36:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NcRcjenqCVAAJiwo3wG5uos+/5Aj93VLjcEKsF2nX/uf/AISeuNwJLL98MRSrwty; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TMMgC-0001OM-TV; Thu, 11 Oct 2012 13:36:17 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: <5076FFB7.4030701@blindcreek.com> Date: Thu, 11 Oct 2012 10:36:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5076FFB7.4030701@blindcreek.com> To: "Benjamin A. Rolfe" X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8624046dd271ee319c033f126978ffb35f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 17:36:29 -0000 Also, there are different possible use cases that would need HAAT etc, = and some where it could be above sea level if WS devices are used aboard = a ship or boat or attached to a flotation device of some sort for monitoring in the future. Or = infrastructure monitoring on a bridge lets say, that would be above sea = level I assume.=20 OF course this would be applicable to local regulations allowed.=20 So having the ability to comply with all, in the original protocol and = may be something to be discussed by the WG.=20 Just a thought, I am not married to it.=20 Sincerely, Nancy On Oct 11, 2012, at 10:19 AM, Benjamin A. Rolfe wrote: > I would not suggest specifying a method to resolve HAAT, as there are = many methods which may be used and I would not bet on every regulatory = region agreeing on a single method. For each Height (altitude) provide a = way to indicate what it is as suggested bellow and a way to identify the = reference model or regional method (like regulator ID?). >=20 > At the moment, FCC specifies the location is of the device, while = OfCom specifies the location is of the antenna. The later makes more = sense to a radio guy worried about interference footprint. The first = seems to assume the device and antenna are close enough to each other = (within the allowed uncertainty which is currently +-50m). OfCom and = FCC currently specify WGS84. This may change in the future if the as the = WGS model has been and will be updated from time to time. OfCom gives = specific requirements for how accuracy is specified (and a 95% = confidence level). Where antenna height is required by OfCom it is = specified as above ground level. FCC has specified HAAT and has already = revised at least once how HAAT is to be determined (and I expect it to = change again). >=20 > OfCom identifies other antenna characteristics that may be = communicated between a device and the database as well including = directionality and orientation, polarisation (I am quoting OfCom here), = and if the antenna location is indoor or outdoor. >=20 > Hope this helps >=20 > Ben >=20 > On 10/11/2012 5:40 AM, Peter Stanforth wrote: >> Agreed. >> We need to be able to resolve AGL, HAAT, location and maybe other = criteria >> based on the regulators methods. I am not sure a single 3D location = will >> be acceptable. >>=20 >> On ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, Brian" >> wrote: >>=20 >>> We need both I think, because of the way the regulations are = written. I >>> don't think there is a simple way to convert that would be = acceptable. >>> In theory, if we knew the terrain height at the location accurately >>> enough, we could calculate what we need, but that is an onerous >>> requirement I think. >>>=20 >>> Brian >>>=20 >>> On Oct 11, 2012, at 12:53 AM, Vincent Chen wrote: >>>=20 >>>> All, >>>>=20 >>>> The various versions of the proposed drafts of the PAWS protocol = tended >>>> to distinguish between "device location" and "antenna height". >>>>=20 >>>> I think we should combine them into a single 3-D location of the >>>> radiation center of (the antenna of) the device. >>>>=20 >>>> Does that sound right? >>>>=20 >>>> The proposed draft-vchen-paws-protocol-00 defines the following >>>> parameters for location and height: >>>>=20 >>>> latitude >>>> longitude >>>> locationUncertainty >>>> locationConfidence >>>>=20 >>>> height >>>> heightType >>>> heightUncertainty >>>>=20 >>>> This is very close to the fields defined by RFC 6225, which has = the >>>> parameters: >>>>=20 >>>> latitude >>>> latitudeUncertainty >>>> longitude >>>> longitudeUncertainty >>>> altitude >>>> altitudeUncertainty >>>> altitudeType >>>>=20 >>>> Should PAWS reference RFC 6225 and list the following differences? >>>>=20 >>>> - The "altitudeType" should be "above means sea level" (WGS84) or >>>> "above ground", instead of the ones defined in the RFC. >>>>=20 >>>> - Add confidence values along each axis. >>>>=20 >>>> If this acceptable, then we can think about defining JSON encoding = of >>>> RFC 6225 for use by PAWS. >>>>=20 >>>> Thanks. >>>>=20 >>>> --=20 >>>> -vince >>>> _______________________________________________ >>>> 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 >>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Thu Oct 11 13:37: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 9BB5021F8672 for ; Thu, 11 Oct 2012 13:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 aZAYhGIXS2Iu for ; Thu, 11 Oct 2012 13:37:41 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 013DB21F866C for ; Thu, 11 Oct 2012 13:37:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=O5FlVgXCJViodVooQvQUAwXQgrcs4YZ9FlXFoJ01SwNsnsfPnamZ/BaW/OgygnVC; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TMPVj-0003Y4-UU; Thu, 11 Oct 2012 16:37:40 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4C7497BA-9EDC-479E-AA13-79EE9A3A11D4" From: Nancy Bravin In-Reply-To: <50772A5E.50303@blindcreek.com> Date: Thu, 11 Oct 2012 13:37:37 -0700 Message-Id: References: <5076FFB7.4030701@blindcreek.com> <50772A5E.50303@blindcreek.com> To: "Benjamin A. Rolfe" X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86e15fe28906bd3ca12eaf0a5ff8b3c566350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 20:37:42 -0000 --Apple-Mail=_4C7497BA-9EDC-479E-AA13-79EE9A3A11D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A bridge above water? I think would be measured "above sea level as = there is no terrain unless it is underwater.=20 The point being that sea level for a variety of applications should be a = separate category than over terrain, or above ground level.=20 Being below sea level is another issue=85.but can be handled with sea = level minus etc=85 Also different countries will, according to its topology will have = different regulations, so being prepared is wise, including the x mile = of ocean that is not international waters. Cruise ships coming into port for instance=85will the staterooms using = WS devices be above or below sea level,=20 or will everything be WS and Slave devices if such is a use case that = could apply?=20 A DB provider could serve WS devises in such a manner. IMHO Sincerely, N On Oct 11, 2012, at 1:21 PM, Benjamin A. Rolfe wrote: > I find few circumstances where a bridge being below sea level would be = a desireable thing (perhaps in the Salton Sea of southern California?). = In general if the antenna is below sea level on the bridge we hope the = monitoring system has already sent it's alerts! Now the idea of = whitespace device on submersibles, though, is really interesting :-). >=20 > The question really is about how we specify altitude (antenna guys = call it "height", while navigators call it "altitude"). The terms Above = Ground Level (AGL) and Height Above Average Terrain are actually quite = different things. Each must be expressed in units like feet or meters = relative to some reference. Mean Sea Level is a commonly used reference = that defines an ellipsoid approximating the level of the oceans, but of = the actual level of oceans around the world varies over time and = location. MSL is just the well defined reference point. It happens to = be the reference used by GPS and most other navigation systems used on = earth. Two common ways to measure altitude (height) are with barometric = pressure (baro-altitude) and GPS, both typically give a value relative = to MSL. >=20 > HAAT is technically very different than AGL. AGL is defined as the = elevation above a specific point on the surface of the earth. HAAT is = an averaged elevation over an area. Computing altitude AGL is simple = subtraction if you have a geo database that contains the elevation of a = particular lat/lon. If you have for example your measured GPS altitude, = and the elevation of the point on the surface at teh same lat/lon, you = subtract one for the other and viola, height above the ground. Or, for = a fixed system, put in the height of the tower or mast you put the = antenna on top of (assuming the bottom of the tower is attached to the = ground firmly enough the tower remains orthogonal to the ground - a very = useful feature of towers ;-). >=20 > HAAT requires you define a specific area and integrate the elevation = values of a number of points within that area. This means (pun intended) = you have to define an integration method, interval and pattern for = selecting the points to integrate, and so on. The FCC has done this, at = least twice, as the latest MO changed the HAAT definition used. So = it'd be a bad idea to > capture a particular method for computing HAAT in the standard and I = don't see why we would, we just need the protocol to support carrying = the information around. >=20 > Of course in your shipboard example when out to sea I'd expect AGL and = HAAT to resolve to the same value, the average terrain being wet and = flat. The same would be true in Florida too I suppose. >=20 > =46rom a radio point of view, HAAT can be more useful in predicting = radio propagation. FCC picked it for that reason I suspect. We can deal = with the complexity. OfCom has picked to use AGL for device antenna = height in their requirements. A protocol that doesn't support HAAT = can't support databases certified by the FCC, and if you can't support = AGL you can't support databases certified by OfCom. I don't think it = takes much, as I suggested, if we know the regulatory region we can know = what form of altitude we need to give or get. >=20 > Hope that helps....yes I have spent a lot of my life thinking about my = position on the earth :-). >=20 > B >=20 >=20 >> Also, there are different possible use cases that would need HAAT = etc, and some where it could be above sea level if WS devices are used = aboard a ship or boat or attached to >> a flotation device of some sort for monitoring in the future. Or = infrastructure monitoring on a bridge lets say, that would be above sea = level I assume. >>=20 >> OF course this would be applicable to local regulations allowed. >> So having the ability to comply with all, in the original protocol = and may be something to be discussed by the WG. >> Just a thought, I am not married to it. >>=20 >> Sincerely, Nancy >>=20 >> On Oct 11, 2012, at 10:19 AM, Benjamin A. Rolfe wrote: >>=20 >>> I would not suggest specifying a method to resolve HAAT, as there = are many methods which may be used and I would not bet on every = regulatory region agreeing on a single method. For each Height = (altitude) provide a way to indicate what it is as suggested bellow and = a way to identify the reference model or regional method (like regulator = ID?). >>>=20 >>> At the moment, FCC specifies the location is of the device, while = OfCom specifies the location is of the antenna. The later makes more = sense to a radio guy worried about interference footprint. The first = seems to assume the device and antenna are close enough to each other = (within the allowed uncertainty which is currently +-50m). OfCom and = FCC currently specify WGS84. This may change in the future if the as the = WGS model has been and will be updated from time to time. OfCom gives = specific requirements for how accuracy is specified (and a 95% = confidence level). Where antenna height is required by OfCom it is = specified as above ground level. FCC has specified HAAT and has already = revised at least once how HAAT is to be determined (and I expect it to = change again). >>>=20 >>> OfCom identifies other antenna characteristics that may be = communicated between a device and the database as well including = directionality and orientation, polarisation (I am quoting OfCom here), = and if the antenna location is indoor or outdoor. >>>=20 >>> Hope this helps >>>=20 >>> Ben >>>=20 >>> On 10/11/2012 5:40 AM, Peter Stanforth wrote: >>>> Agreed. >>>> We need to be able to resolve AGL, HAAT, location and maybe other = criteria >>>> based on the regulators methods. I am not sure a single 3D location = will >>>> be acceptable. >>>>=20 >>>> On ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, Brian" >>>> wrote: >>>>=20 >>>>> We need both I think, because of the way the regulations are = written. I >>>>> don't think there is a simple way to convert that would be = acceptable. >>>>> In theory, if we knew the terrain height at the location = accurately >>>>> enough, we could calculate what we need, but that is an onerous >>>>> requirement I think. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 11, 2012, at 12:53 AM, Vincent Chen = wrote: >>>>>=20 >>>>>> All, >>>>>>=20 >>>>>> The various versions of the proposed drafts of the PAWS protocol = tended >>>>>> to distinguish between "device location" and "antenna height". >>>>>>=20 >>>>>> I think we should combine them into a single 3-D location of the >>>>>> radiation center of (the antenna of) the device. >>>>>>=20 >>>>>> Does that sound right? >>>>>>=20 >>>>>> The proposed draft-vchen-paws-protocol-00 defines the following >>>>>> parameters for location and height: >>>>>>=20 >>>>>> latitude >>>>>> longitude >>>>>> locationUncertainty >>>>>> locationConfidence >>>>>>=20 >>>>>> height >>>>>> heightType >>>>>> heightUncertainty >>>>>>=20 >>>>>> This is very close to the fields defined by RFC 6225, which has = the >>>>>> parameters: >>>>>>=20 >>>>>> latitude >>>>>> latitudeUncertainty >>>>>> longitude >>>>>> longitudeUncertainty >>>>>> altitude >>>>>> altitudeUncertainty >>>>>> altitudeType >>>>>>=20 >>>>>> Should PAWS reference RFC 6225 and list the following = differences? >>>>>>=20 >>>>>> - The "altitudeType" should be "above means sea level" (WGS84) = or >>>>>> "above ground", instead of the ones defined in the RFC. >>>>>>=20 >>>>>> - Add confidence values along each axis. >>>>>>=20 >>>>>> If this acceptable, then we can think about defining JSON = encoding of >>>>>> RFC 6225 for use by PAWS. >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> --=20 >>>>>> -vince >>>>>> _______________________________________________ >>>>>> 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 >>>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 --Apple-Mail=_4C7497BA-9EDC-479E-AA13-79EE9A3A11D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 A = bridge above water? I think would be measured "above sea level as there = is no terrain unless it is underwater. 

The point = being that sea level for a variety of applications should be a separate = category than over terrain, or above ground level. 
Being = below sea level is another issue=85.but can be handled with sea level = minus etc=85
Also different countries will, according to its = topology will have different regulations, so being prepared is wise, = including the x mile of ocean that
is not international = waters.

 Cruise ships coming into port for = instance=85will the staterooms using WS devices be above or below sea = level, 
or will everything be WS and Slave devices if = such is a use case that could apply? 
A DB provider could = serve WS devises in such a manner. IMHO
Sincerely, = N


On Oct 11, 2012, at 1:21 PM, Benjamin A. Rolfe = wrote:

I find few circumstances where a bridge being below = sea level would be a desireable thing (perhaps in the Salton Sea of = southern California?).  In general if the antenna is below sea = level on the bridge we hope the monitoring system has already sent it's = alerts!  Now the idea of whitespace device on submersibles, though, = is really interesting :-).

The question really is about how we = specify altitude (antenna guys call it "height", while navigators call = it "altitude").  The terms Above Ground Level (AGL)  and = Height Above Average Terrain are actually quite different things. =  Each must be expressed in units like feet or meters relative to = some reference.  Mean Sea Level is a commonly used reference that = defines an ellipsoid approximating the level of the oceans, but of the = actual level of oceans around the world varies over time and location. =   MSL is just the well defined reference point.  It = happens to be the reference used by GPS and most other navigation = systems used on earth.  Two common ways to measure altitude = (height) are with barometric pressure (baro-altitude) and GPS, both = typically give a value relative to MSL.

HAAT is technically very = different than AGL.  AGL is defined as the elevation above a = specific point on the surface of the earth.  HAAT is an averaged = elevation  over an area.  Computing altitude AGL is simple = subtraction if you have a geo database that contains the elevation of a = particular lat/lon. If you have for example your measured GPS altitude, = and the elevation of the point on the surface at teh same lat/lon, you = subtract one for the other and viola, height above the ground.  Or, = for a fixed system, put in the height of the tower or mast you put the = antenna on top of (assuming the bottom of the tower is attached to the = ground firmly enough the tower remains orthogonal to the ground - a very = useful feature of towers ;-).

HAAT requires you define a specific = area and integrate the elevation values of a number of points within = that area. This means (pun intended) you have to define an integration = method, interval and pattern for selecting the points to integrate, and = so on.  The FCC has done this, at least twice, as the latest MO = changed the HAAT definition used.   So it'd be a bad idea = to
capture a particular method for computing HAAT in the standard and = I don't see why we would, we just need the protocol to support carrying = the information around.

Of course in your shipboard example when = out to sea I'd expect AGL and HAAT to resolve to the same value, the = average terrain being wet and flat. The same would be true in Florida = too I suppose.

=46rom a radio point of view, HAAT can be more = useful in predicting radio propagation.  FCC picked it for that = reason I suspect. We can deal with the complexity.  OfCom has = picked to use AGL for device antenna height in their requirements. =  A protocol that doesn't support HAAT can't support databases = certified by the FCC, and if you can't support AGL you can't support = databases certified by OfCom. I don't think it takes much, as I = suggested, if we know the regulatory region we can know what form of = altitude we need to give or get.

Hope that helps....yes I have = spent a lot of my life thinking about my position on the earth = :-).

B


Also, there are = different possible use cases that would need HAAT etc, and some where it = could be above sea level if WS devices are used aboard a ship or boat or = attached to
a flotation device = of some sort for monitoring in the future. Or infrastructure monitoring = on a bridge lets say, that would be above sea level I = assume.

OF course this = would be applicable to local regulations = allowed.
So having the ability = to comply with all, in the original protocol and may be something to be = discussed by the WG.
Just a = thought, I am not married to it.

Sincerely, = Nancy

On Oct 11, = 2012, at 10:19 AM, Benjamin A. Rolfe wrote:

I would not suggest specifying a method to resolve HAAT, = as there are many methods which may be used and I would not bet on every = regulatory region agreeing on a single method. For each Height = (altitude) provide a way to indicate what it is as suggested bellow and = a way to identify the reference model or regional method (like regulator = ID?).

At the moment, FCC specifies the = location is of the device, while OfCom specifies the location is of the = antenna.   The later makes more sense  to a radio guy = worried about interference footprint.  The first seems to assume = the device and antenna are close enough to each other (within the = allowed uncertainty which is currently +-50m).  OfCom and FCC = currently specify WGS84. This may change in the future if the as the WGS = model has been and will be updated from time to time.  OfCom gives = specific requirements for how accuracy is specified (and a 95% = confidence level).  Where antenna height is required by OfCom it is = specified as above ground level. FCC has specified HAAT and has already = revised at least once how HAAT is to be determined (and I expect it to = change again).

OfCom identifies other antenna = characteristics that may be communicated between a device and the = database as well including directionality and orientation, polarisation = (I am quoting OfCom here), and if the antenna location is indoor or = outdoor.

Hope this = helps

Ben

On 10/11/2012 5:40 AM, Peter = Stanforth wrote:
Agreed.
We = need to be able to resolve AGL, HAAT, location and maybe other = criteria
based = on the regulators methods. I am not sure a single 3D location = will
be = acceptable.

On = ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, = Brian"
<Brian.Rosen@neustar.biz> =   wrote:

We need both I think, because of = the way the regulations are written. =  I
don't think there is a simple = way to convert that would be = acceptable.
In theory, if we knew the = terrain height at the location = accurately
enough, we could calculate what = we need, but that is an = onerous
requirement I = think.

Brian

On Oct 11, 2012, at 12:53 AM, = Vincent Chen<vchen@google.com> =   wrote:
=

All,
=

The = various versions of the proposed drafts of the PAWS protocol = tended
to = distinguish between "device location" and "antenna = height".

I = think we should combine them into a single 3-D location of = the
radiation center of (the antenna of) the = device.

Does = that sound = right?

The = proposed draft-vchen-paws-protocol-00 defines the = following
parameters for location and = height:

=   latitude
=   longitude
=   locationUncertainty
=
=   locationConfidence
<= /blockquote>

=   height
=
=   heightType
=   heightUncertainty

This = is very close to the fields  defined by RFC 6225, which has = the
parameters:

=  latitude
=  latitudeUncertainty
=  longitude
=  longitudeUncertainty
=  altitude
=  altitudeUncertainty
=  altitudeType
=

Should = PAWS reference RFC 6225 and list the following = differences?

=  - The "altitudeType" should be "above means sea level" (WGS84) = or
"above = ground", instead of the ones defined in the = RFC.
<= blockquote type=3D"cite">

=  - Add confidence values along each = axis.
=

If = this acceptable, then we can think about defining JSON encoding = of
RFC = 6225 for use by = PAWS.
=

Thanks.

-- =
-vince
_______________________________________________
paws = mailing = list
<= blockquote type=3D"cite">
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

_______________________________________________
paws = mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws



= --Apple-Mail=_4C7497BA-9EDC-479E-AA13-79EE9A3A11D4-- From nbravin@earthlink.net Thu Oct 11 13:44: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 585D421F853E for ; Thu, 11 Oct 2012 13:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FRT_BELOW2=2.154] 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 wnw4GUYaq5eV for ; Thu, 11 Oct 2012 13:44:35 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBFC21F856C for ; Thu, 11 Oct 2012 13:44:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sGaRhCtRAfD3jkVqYVMHJhuYBWqigUIuD09Iuydr8QIXnBEzI0AbOAqfJ7M1suzh; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TMPc7-0000og-NF; Thu, 11 Oct 2012 16:44:15 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Nancy Bravin In-Reply-To: <50772AAC.7020804@blindcreek.com> Date: Thu, 11 Oct 2012 13:44:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80CA8537-FBCE-4360-8B4D-8E8F53201526@earthlink.net> References: <5076FFB7.4030701@blindcreek.com> <50772AAC.7020804@blindcreek.com> To: "Benjamin A. Rolfe" X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86ae1f4e0337408128758bbc27b8999489350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 20:44:36 -0000 Thanks Ben, in any case, as I said I am not married to this idea, just a = thought of possibilities.=20 N On Oct 11, 2012, at 1:23 PM, Benjamin A. Rolfe wrote: > P.S. here's a cool tool from the FCC > http://transition.fcc.gov/mb/audio/bickel/haat_calculator.html >=20 >> Also, there are different possible use cases that would need HAAT = etc, and some where it could be above sea level if WS devices are used = aboard a ship or boat or attached to >> a flotation device of some sort for monitoring in the future. Or = infrastructure monitoring on a bridge lets say, that would be above sea = level I assume. >>=20 >> OF course this would be applicable to local regulations allowed. >> So having the ability to comply with all, in the original protocol = and may be something to be discussed by the WG. >> Just a thought, I am not married to it. >>=20 >> Sincerely, Nancy >>=20 >> On Oct 11, 2012, at 10:19 AM, Benjamin A. Rolfe wrote: >>=20 >>> I would not suggest specifying a method to resolve HAAT, as there = are many methods which may be used and I would not bet on every = regulatory region agreeing on a single method. For each Height = (altitude) provide a way to indicate what it is as suggested bellow and = a way to identify the reference model or regional method (like regulator = ID?). >>>=20 >>> At the moment, FCC specifies the location is of the device, while = OfCom specifies the location is of the antenna. The later makes more = sense to a radio guy worried about interference footprint. The first = seems to assume the device and antenna are close enough to each other = (within the allowed uncertainty which is currently +-50m). OfCom and = FCC currently specify WGS84. This may change in the future if the as the = WGS model has been and will be updated from time to time. OfCom gives = specific requirements for how accuracy is specified (and a 95% = confidence level). Where antenna height is required by OfCom it is = specified as above ground level. FCC has specified HAAT and has already = revised at least once how HAAT is to be determined (and I expect it to = change again). >>>=20 >>> OfCom identifies other antenna characteristics that may be = communicated between a device and the database as well including = directionality and orientation, polarisation (I am quoting OfCom here), = and if the antenna location is indoor or outdoor. >>>=20 >>> Hope this helps >>>=20 >>> Ben >>>=20 >>> On 10/11/2012 5:40 AM, Peter Stanforth wrote: >>>> Agreed. >>>> We need to be able to resolve AGL, HAAT, location and maybe other = criteria >>>> based on the regulators methods. I am not sure a single 3D location = will >>>> be acceptable. >>>>=20 >>>> On ThuOct/11/12 Thu Oct 11, 6:07 AM, "Rosen, Brian" >>>> wrote: >>>>=20 >>>>> We need both I think, because of the way the regulations are = written. I >>>>> don't think there is a simple way to convert that would be = acceptable. >>>>> In theory, if we knew the terrain height at the location = accurately >>>>> enough, we could calculate what we need, but that is an onerous >>>>> requirement I think. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 11, 2012, at 12:53 AM, Vincent Chen = wrote: >>>>>=20 >>>>>> All, >>>>>>=20 >>>>>> The various versions of the proposed drafts of the PAWS protocol = tended >>>>>> to distinguish between "device location" and "antenna height". >>>>>>=20 >>>>>> I think we should combine them into a single 3-D location of the >>>>>> radiation center of (the antenna of) the device. >>>>>>=20 >>>>>> Does that sound right? >>>>>>=20 >>>>>> The proposed draft-vchen-paws-protocol-00 defines the following >>>>>> parameters for location and height: >>>>>>=20 >>>>>> latitude >>>>>> longitude >>>>>> locationUncertainty >>>>>> locationConfidence >>>>>>=20 >>>>>> height >>>>>> heightType >>>>>> heightUncertainty >>>>>>=20 >>>>>> This is very close to the fields defined by RFC 6225, which has = the >>>>>> parameters: >>>>>>=20 >>>>>> latitude >>>>>> latitudeUncertainty >>>>>> longitude >>>>>> longitudeUncertainty >>>>>> altitude >>>>>> altitudeUncertainty >>>>>> altitudeType >>>>>>=20 >>>>>> Should PAWS reference RFC 6225 and list the following = differences? >>>>>>=20 >>>>>> - The "altitudeType" should be "above means sea level" (WGS84) = or >>>>>> "above ground", instead of the ones defined in the RFC. >>>>>>=20 >>>>>> - Add confidence values along each axis. >>>>>>=20 >>>>>> If this acceptable, then we can think about defining JSON = encoding of >>>>>> RFC 6225 for use by PAWS. >>>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> --=20 >>>>>> -vince >>>>>> _______________________________________________ >>>>>> 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 >>>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 From vchen@google.com Thu Oct 11 14:24:32 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 D9B5B1F0C3E for ; Thu, 11 Oct 2012 14:24:32 -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=[AWL=-0.000, 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 wAVKJ3vR9RVn for ; Thu, 11 Oct 2012 14:24:32 -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 1053B1F041F for ; Thu, 11 Oct 2012 14:24:31 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2017821qcg.31 for ; Thu, 11 Oct 2012 14:24:31 -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=R80gNzBtIeZZ4u8bdxzSdTo+bR5GOLAGAaFs2XG5H1A=; b=SUt8tZjpd7s/BMczfAdgrfRTutpIQmkveKpkKVRtlVlwaGUQIItRkKIc1OHoEw0QWe zIZIuQIpvjRGNhnG5JdbIB3iznwAgkO3YyJ9XdzPO26jxhEr/gWg1TNVLE6w54sK7Avm /Dhz5f4jMbHzS5ytTeO60gYkIiF3RoZOHHsKEXYNwTmAImjfBBhcfkVuJHqCB3ZVzCbW 77t3mPQ+4COaFY1qrUAwhEToeeIZQ77xYqAdv+0cglvGVxIgrMySusYskrTQr7StrXYi a71jB4qnBKOxzdYydPVf/Otg9Zlu3bPhnXldW/1kl4omS4jALMh6xqniOkawCgoP4uIf n74g== 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=R80gNzBtIeZZ4u8bdxzSdTo+bR5GOLAGAaFs2XG5H1A=; b=MLJ0knJwchjD4ddlxqbGfkIWnXfLyeAFQ2ARIZDEG4OtNl4RF/usJkuIXXnUtTqmMa hkjQSOFZd6SMbnVNadQ5JnN9nvYCCPJpJcqrSX4i+/fCOYSkCqPOPuZ1xDwH2jR3SfJG 7++rfkBf62TJ+Rke8yjf9gXSqeQoNpEWbeLAzJf7ThTByWbFbr27htfZNswkOhDgu9Bd Xzva1/3V0mpiiiuJQG93yhtTSHFEYtu4LIHUBvf+0/x8MoxC6B1tW4IcQOlohEpgQMzt fo1xAjsPm9IMS8tbsFNA4idMagjx4a41S95nzo8umRocixWYi6uuJEkonhHmFHYhhoMe Mc9g== MIME-Version: 1.0 Received: by 10.224.203.193 with SMTP id fj1mr4125440qab.13.1349990671475; Thu, 11 Oct 2012 14:24:31 -0700 (PDT) Received: by 10.229.234.9 with HTTP; Thu, 11 Oct 2012 14:24:31 -0700 (PDT) In-Reply-To: References: <5076FFB7.4030701@blindcreek.com> Date: Thu, 11 Oct 2012 14:24:31 -0700 Message-ID: From: Vincent Chen To: Nancy Bravin Content-Type: multipart/alternative; boundary=20cf300512326c628c04cbcf32c2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnXXsBaPpVsf2IKCUyPJGN6VUcr5YCgMTYzxXT+p6ZrOG6vhDzfhhE4Ks3ZNCXfHUmzWgO40SDebH2ZIYBv+2febySJHVUfEKlrmgCpcQOB5nYQEzn0qFzX60LdfXPt4cplUwHGO48FpmHveB74NB9MFmIxUVTgLhVL3PyfTwNBbDWpIYUObisQqYLBHSaMi5N4Ifdc Cc: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 21:24:33 -0000 --20cf300512326c628c04cbcf32c2 Content-Type: text/plain; charset=ISO-8859-1 Thanks All, So what I hear is that trying to re-use a standard that describes location as (latitude, longitude, altitude) is probably not a good idea. To focus specifically on the discussion of height: - Whether protection should be computed using a device's HAAT is a regulatory rule. As such, the Database should be responsible to applying the right rules (including how to compute HAAT). We should not be burdening a device with those. For the PAWS protocol, we should define height in a way that is easy for the device to determine by itself (or by an installer), independent of regulatory specifics. There appears to me two options we should support: 1. Height above (relative to) mean sea level, as can be reported by a GPS, or 2. Height above ground (or sea in case of a bridge) that can be determined by direct measurement or engineering drawings For the first, we could specify WGS84. If WGS were to change in the future, how much difference would we expect? Probably won't actually make a difference in protection or available spectrum computations... In the case of a bridge or ship, I claim one of the above will do. How to compute available channels is a regulatory rule whose enforcement belongs in the Database. It should not impact the PAWS protocol. I would hope that one of the goals of a standard is: - Establish reasonably flexible parameter set without going "overboard" (pun intended). I think we should present a model around which regulators could align, rather than encourage each to come up with completely new rules. Thoughts? -vince --20cf300512326c628c04cbcf32c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks All,

So what I hear is that trying to re-use a st= andard that describes location as (latitude, longitude, altitude) is probab= ly not a good idea.

To focus specifically on the d= iscussion of height:

=A0- Whether protection should be computed using a devi= ce's HAAT is a regulatory rule. As such, the Database should be respons= ible to applying the right rules (including how to compute HAAT). We should= not be burdening a device with those.

For the PAWS protocol, we should define height in a way= that is easy for the device to determine by itself (or by an installer), i= ndependent of regulatory specifics. There appears to me two options we shou= ld support:
=A0 =A01. Height above (relative to) mean sea level, as can be re= ported by a GPS, or
=A0 =A02. Height above ground (or sea in case= of a bridge) that can be determined by direct measurement or engineering d= rawings

For the first, we could specify WGS84. If WGS wer= e to change in the future, how much difference would we expect? Probably wo= n't actually make a difference in protection or available spectrum comp= utations...

In the case of a bridge or ship, I claim one of the abo= ve will do. How to compute available channels is a regulatory rule whose en= forcement belongs in the Database.
It should not impact the PAWS = protocol.

I would hope that one of the goals of a standard is:
=A0- Establish reasonably flexible parameter set without going "= overboard" (pun intended). I think we should present a model around wh= ich regulators could align, rather than encourage each to come up with comp= letely new rules.

Thoughts?

-vince --20cf300512326c628c04cbcf32c2-- From nbravin@earthlink.net Thu Oct 11 16:17:39 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 68E3121F84FE for ; Thu, 11 Oct 2012 16:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.994, 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 Lvpy2NX2yRIr for ; Thu, 11 Oct 2012 16:17:38 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA8121F84F6 for ; Thu, 11 Oct 2012 16:17:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=LgD/56OhA3xuYgKgEPfDerEVe+yrKgszx/B65e9UV3dC6nP/Kq4vEBAvnsWbWkyV; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TMS0X-0006VJ-Vr; Thu, 11 Oct 2012 19:17:38 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E14ED4CE-F5F0-400D-92F3-A596F7B06846" From: Nancy Bravin In-Reply-To: Date: Thu, 11 Oct 2012 16:17:36 -0700 Message-Id: <7235207B-F0E1-4EF7-AFB3-6A6FB06BE6B9@earthlink.net> References: <5076FFB7.4030701@blindcreek.com> To: Vincent Chen X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86ee24994cb88d8b8817efb2aee4060857350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 23:17:39 -0000 --Apple-Mail=_E14ED4CE-F5F0-400D-92F3-A596F7B06846 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Well said, I agree=85thanks Nancy Nancy Bravin nbravin@earthlink.net nancybravin@me.com On Oct 11, 2012, at 2:24 PM, Vincent Chen wrote: > Thanks All, >=20 > So what I hear is that trying to re-use a standard that describes = location as (latitude, longitude, altitude) is probably not a good idea. >=20 > To focus specifically on the discussion of height: >=20 > - Whether protection should be computed using a device's HAAT is a = regulatory rule. As such, the Database should be responsible to applying = the right rules (including how to compute HAAT). We should not be = burdening a device with those. >=20 > For the PAWS protocol, we should define height in a way that is easy = for the device to determine by itself (or by an installer), independent = of regulatory specifics. There appears to me two options we should = support: > 1. Height above (relative to) mean sea level, as can be reported by = a GPS, or > 2. Height above ground (or sea in case of a bridge) that can be = determined by direct measurement or engineering drawings >=20 > For the first, we could specify WGS84. If WGS were to change in the = future, how much difference would we expect? Probably won't actually = make a difference in protection or available spectrum computations... >=20 > In the case of a bridge or ship, I claim one of the above will do. How = to compute available channels is a regulatory rule whose enforcement = belongs in the Database. > It should not impact the PAWS protocol. >=20 > I would hope that one of the goals of a standard is: > - Establish reasonably flexible parameter set without going = "overboard" (pun intended). I think we should present a model around = which regulators could align, rather than encourage each to come up with = completely new rules. >=20 > Thoughts? >=20 > -vince --Apple-Mail=_E14ED4CE-F5F0-400D-92F3-A596F7B06846 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Well = said, I agree=85thanks Nancy

Nancy = Bravin

nbravin@earthlink.net
nancybr= avin@me.com

On Oct 11, 2012, at 2:24 PM, Vincent Chen wrote:

Thanks = All,

So what I hear is that trying to re-use a = standard that describes location as (latitude, longitude, altitude) is = probably not a good idea.

To focus specifically = on the discussion of height:

 - Whether protection should be computed using = a device's HAAT is a regulatory rule. As such, the Database should be = responsible to applying the right rules (including how to compute HAAT). = We should not be burdening a device with those.

For the PAWS protocol, we should define height in a = way that is easy for the device to determine by itself (or by an = installer), independent of regulatory specifics. There appears to me two = options we should support:
   1. Height above (relative to) mean sea level, as = can be reported by a GPS, or
   2. Height above = ground (or sea in case of a bridge) that can be determined by direct = measurement or engineering drawings

For the first, we could specify WGS84. If WGS = were to change in the future, how much difference would we expect? = Probably won't actually make a difference in protection or available = spectrum computations...

In the case of a bridge or ship, I claim one of the = above will do. How to compute available channels is a regulatory rule = whose enforcement belongs in the Database.
It should not = impact the PAWS protocol.

I would hope that one of the goals of a standard = is:
 - Establish reasonably flexible parameter set without = going "overboard" (pun intended). I think we should present a model = around which regulators could align, rather than encourage each to come = up with completely new rules.
=

Thoughts?

-vince<= /div>

= --Apple-Mail=_E14ED4CE-F5F0-400D-92F3-A596F7B06846-- From jmalyar@telcordia.com Thu Oct 11 16:47: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 7C1C31F0423 for ; Thu, 11 Oct 2012 16:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 YT0BGzK1EpBt for ; Thu, 11 Oct 2012 16:47:24 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietfa.amsl.com (Postfix) with ESMTP id A6BCB1F0417 for ; Thu, 11 Oct 2012 16:47:24 -0700 (PDT) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q9BNlLWo012653; Thu, 11 Oct 2012 19:47:21 -0400 (EDT) X-AuditID: 80602530-b7f726d000000e4c-0a-50775a893f9b Received: from rrc-dte-exhb3.dte.telcordia.com (rrc-dte-exhb3.cc.telcordia.com [128.96.105.72]) by pya-dte-bms01.telcordia.com (Symantec Messaging Gateway) with SMTP id DF.C5.03660.98A57705; Thu, 11 Oct 2012 19:47:21 -0400 (EDT) Received: from RRC-DTE-EXMB4.dte.telcordia.com ([fe80::8ad:5ccb:8fe0:2314]) by rrc-dte-exhb3.dte.telcordia.com ([2002:8060:6948::8060:6948]) with mapi id 14.01.0379.000; Thu, 11 Oct 2012 19:47:21 -0400 From: "Malyar, John P" To: "'vchen@google.com'" , "'nbravin@earthlink.net'" Thread-Topic: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? Thread-Index: AQHNqArBptAn4zKByUy1rulYudrByw== Date: Thu, 11 Oct 2012 23:47:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2002:8060:9608::8060:9608] Content-Type: multipart/alternative; boundary="_000_E7916FF82420BB40A104D4CAAB11C7880F4E78rrcdteexmb4dtetel_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsXSkJDpodsZVR5gsOaWlsWHDxPYLQ70zGW2 mPB7G6sDs8eqLxOYPRZsKvVYsuQnUwBzFJdNSmpOZllqkb5dAlfGiam97AUn7Cvmrd3H2MD4 xLaLkZNDQsBEouHseiYIW0ziwr31bCC2kMAzRolNa1K7GLmA7LOMEoeOf2AFSbAJ6Enc+tfJ DmKLCCRIPF71FqyZWUBVYs/tNjBbWCBaYs75x6wQNTESVx6dZexi5ACy9SSWr+YHCbMAlV/8 +hGsnFcgRGLV9s1g5ZwCgRKP3t1iBrEZge75fmoN1HhxiVtP5kPdKSCxZM95ZghbVOLl43+s ELauxPb+TWwQ9fkSj2/vYoaYLyhxcuYTlgmMIrOQjJqFpGwWkrJZQJcyC2hKrN+lD1GiKDGl +yE7hK0h0TpnLjuy+AJG9lWM0gWVibopJam6SbnFBoZ6Jak5yflFKZmJesn5uZsYwRGnarCD cfcv9UOMAhyMSjy8MwPtAoRYE8uKK3MPMUpwMCuJ8H5aCRTiTUmsrEotyo8vKs1JLT7EKM3B oiTOu0Xf30dIID2xJDU7NbUgtQgmy8TBKdXA2DDhlbktz+H6mU1XBNsOFQfrVpju2BhWvzjQ 7MXcC+s6vO7e3xfYIcXYs0p47Rqr2Tk8vXYnuz1VZ9qqRPvohn7cJczjbbnS9OH2FVL+KoXt hwM2BLc+/v22t32P9Z8ZFV+52o5sSTrk3/urS/6Cu6rfyUdBR08t44j92X2eY0JrkeaiZDlm JZbijERDLeai4kQArTvU+bQCAAA= Cc: "'paws@ietf.org'" Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 11 Oct 2012 23:47:25 -0000 --_000_E7916FF82420BB40A104D4CAAB11C7880F4E78rrcdteexmb4dtetel_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmluY2UNCg0KSSBhZ3JlZSB0aGF0IHRoZSBEZXZpY2Ugc2hvdWxkIG5vdCBzcGVjaWZ5IEhBQVQg YnV0IHdlIGRvIG5lZWQgYSBwYXJhbWV0ZXIgZnJvbSB0aGUgRGV2aWNlIHRvIHBhc3MgaW5mb3Jt YXRpb24gYWJvdmUgYW5kIGJleW9uZCBMYXQgYW5kIExvbiBmb3IgZXhhbXBsZSBIQUdMLiBUaGUg c3BlY2lmaWMgdmFsdWUgaW4gdGhpcyB0cmlwbGUgd2lsbCBiZSBkZWZpbmVkIGJ5IHRoZSBSZWd1 bGF0b3J5IEF1dGhvcml0eS4gV2UgY2FuIHNpbXBsZSBjYWxsIGl0IEhlaWdodCBhbmQgaWRlbnRp ZnkgdGhhdCB0aGUgcmVxdWlyZWQvZXhwZWN0ZWQgdmFsdWUgd2lsbCBiZSBkZXRlcm1pbmVkIGJ5 IHRoZSBSQS4gTm90IHN1cmUgSSB3b3VsZCBzYXkgaXQgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIFJB LiBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgdmFsdWUgc2hvdWxkIGJlIHByZXNlbnQgaW4g dGhlIFJlZ2lzdHJhdGlvbiBidXQgbm90IG5lY2Vzc2FyeSBpbiB0aGUgR2V0IENoYW5uZWxzLg0K DQpKb2huDQoNCkZyb206IFZpbmNlbnQgQ2hlbiBbbWFpbHRvOnZjaGVuQGdvb2dsZS5jb21dDQpT ZW50OiBUaHVyc2RheSwgT2N0b2JlciAxMSwgMjAxMiAwNToyNCBQTQ0KVG86IE5hbmN5IEJyYXZp biA8bmJyYXZpbkBlYXJ0aGxpbmsubmV0Pg0KQ2M6IHBhd3NAaWV0Zi5vcmcgPHBhd3NAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFBBV1MgUHJvdG9jb2w6IFNob3VsZCAiRGV2aWNlIGxv Y2F0aW9uIiByZWFsbHkgYmUgIkFudGVubmEgbG9jYXRpb24iPw0KDQpUaGFua3MgQWxsLA0KDQpT byB3aGF0IEkgaGVhciBpcyB0aGF0IHRyeWluZyB0byByZS11c2UgYSBzdGFuZGFyZCB0aGF0IGRl c2NyaWJlcyBsb2NhdGlvbiBhcyAobGF0aXR1ZGUsIGxvbmdpdHVkZSwgYWx0aXR1ZGUpIGlzIHBy b2JhYmx5IG5vdCBhIGdvb2QgaWRlYS4NCg0KVG8gZm9jdXMgc3BlY2lmaWNhbGx5IG9uIHRoZSBk aXNjdXNzaW9uIG9mIGhlaWdodDoNCg0KIC0gV2hldGhlciBwcm90ZWN0aW9uIHNob3VsZCBiZSBj b21wdXRlZCB1c2luZyBhIGRldmljZSdzIEhBQVQgaXMgYSByZWd1bGF0b3J5IHJ1bGUuIEFzIHN1 Y2gsIHRoZSBEYXRhYmFzZSBzaG91bGQgYmUgcmVzcG9uc2libGUgdG8gYXBwbHlpbmcgdGhlIHJp Z2h0IHJ1bGVzIChpbmNsdWRpbmcgaG93IHRvIGNvbXB1dGUgSEFBVCkuIFdlIHNob3VsZCBub3Qg YmUgYnVyZGVuaW5nIGEgZGV2aWNlIHdpdGggdGhvc2UuDQoNCkZvciB0aGUgUEFXUyBwcm90b2Nv bCwgd2Ugc2hvdWxkIGRlZmluZSBoZWlnaHQgaW4gYSB3YXkgdGhhdCBpcyBlYXN5IGZvciB0aGUg ZGV2aWNlIHRvIGRldGVybWluZSBieSBpdHNlbGYgKG9yIGJ5IGFuIGluc3RhbGxlciksIGluZGVw ZW5kZW50IG9mIHJlZ3VsYXRvcnkgc3BlY2lmaWNzLiBUaGVyZSBhcHBlYXJzIHRvIG1lIHR3byBv cHRpb25zIHdlIHNob3VsZCBzdXBwb3J0Og0KICAgMS4gSGVpZ2h0IGFib3ZlIChyZWxhdGl2ZSB0 bykgbWVhbiBzZWEgbGV2ZWwsIGFzIGNhbiBiZSByZXBvcnRlZCBieSBhIEdQUywgb3INCiAgIDIu IEhlaWdodCBhYm92ZSBncm91bmQgKG9yIHNlYSBpbiBjYXNlIG9mIGEgYnJpZGdlKSB0aGF0IGNh biBiZSBkZXRlcm1pbmVkIGJ5IGRpcmVjdCBtZWFzdXJlbWVudCBvciBlbmdpbmVlcmluZyBkcmF3 aW5ncw0KDQpGb3IgdGhlIGZpcnN0LCB3ZSBjb3VsZCBzcGVjaWZ5IFdHUzg0LiBJZiBXR1Mgd2Vy ZSB0byBjaGFuZ2UgaW4gdGhlIGZ1dHVyZSwgaG93IG11Y2ggZGlmZmVyZW5jZSB3b3VsZCB3ZSBl eHBlY3Q/IFByb2JhYmx5IHdvbid0IGFjdHVhbGx5IG1ha2UgYSBkaWZmZXJlbmNlIGluIHByb3Rl Y3Rpb24gb3IgYXZhaWxhYmxlIHNwZWN0cnVtIGNvbXB1dGF0aW9ucy4uLg0KDQpJbiB0aGUgY2Fz ZSBvZiBhIGJyaWRnZSBvciBzaGlwLCBJIGNsYWltIG9uZSBvZiB0aGUgYWJvdmUgd2lsbCBkby4g SG93IHRvIGNvbXB1dGUgYXZhaWxhYmxlIGNoYW5uZWxzIGlzIGEgcmVndWxhdG9yeSBydWxlIHdo b3NlIGVuZm9yY2VtZW50IGJlbG9uZ3MgaW4gdGhlIERhdGFiYXNlLg0KSXQgc2hvdWxkIG5vdCBp bXBhY3QgdGhlIFBBV1MgcHJvdG9jb2wuDQoNCkkgd291bGQgaG9wZSB0aGF0IG9uZSBvZiB0aGUg Z29hbHMgb2YgYSBzdGFuZGFyZCBpczoNCiAtIEVzdGFibGlzaCByZWFzb25hYmx5IGZsZXhpYmxl IHBhcmFtZXRlciBzZXQgd2l0aG91dCBnb2luZyAib3ZlcmJvYXJkIiAocHVuIGludGVuZGVkKS4g SSB0aGluayB3ZSBzaG91bGQgcHJlc2VudCBhIG1vZGVsIGFyb3VuZCB3aGljaCByZWd1bGF0b3Jz IGNvdWxkIGFsaWduLCByYXRoZXIgdGhhbiBlbmNvdXJhZ2UgZWFjaCB0byBjb21lIHVwIHdpdGgg Y29tcGxldGVseSBuZXcgcnVsZXMuDQoNClRob3VnaHRzPw0KDQotdmluY2UNCg== --_000_E7916FF82420BB40A104D4CAAB11C7880F4E78rrcdteexmb4dtetel_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlZpbmNlPGJyPg0KPGJyPg0KSSBhZ3JlZSB0 aGF0IHRoZSBEZXZpY2Ugc2hvdWxkIG5vdCBzcGVjaWZ5IEhBQVQgYnV0IHdlIGRvIG5lZWQgYSBw YXJhbWV0ZXIgZnJvbSB0aGUgRGV2aWNlIHRvIHBhc3MgaW5mb3JtYXRpb24gYWJvdmUgYW5kIGJl eW9uZCBMYXQgYW5kIExvbiBmb3IgZXhhbXBsZSBIQUdMLiBUaGUgc3BlY2lmaWMgdmFsdWUgaW4g dGhpcyB0cmlwbGUgd2lsbCBiZSBkZWZpbmVkIGJ5IHRoZSBSZWd1bGF0b3J5IEF1dGhvcml0eS4g V2UgY2FuIHNpbXBsZSBjYWxsIGl0DQogSGVpZ2h0IGFuZCBpZGVudGlmeSB0aGF0IHRoZSByZXF1 aXJlZC9leHBlY3RlZCB2YWx1ZSB3aWxsIGJlIGRldGVybWluZWQgYnkgdGhlIFJBLiBOb3Qgc3Vy ZSBJIHdvdWxkIHNheSBpdCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgUkEuIEl0IHNob3VsZCBiZSBu b3RlZCB0aGF0IHRoZSB2YWx1ZSBzaG91bGQgYmUgcHJlc2VudCBpbiB0aGUgUmVnaXN0cmF0aW9u IGJ1dCBub3QgbmVjZXNzYXJ5IGluIHRoZSBHZXQgQ2hhbm5lbHMuDQo8YnI+DQo8YnI+DQpKb2hu IDwvZm9udD48YnI+DQombmJzcDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9u dCBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGI+RnJvbTwvYj46IFZpbmNlbnQgQ2hlbiBbbWFpbHRv OnZjaGVuQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogVGh1cnNkYXksIE9jdG9iZXIg MTEsIDIwMTIgMDU6MjQgUE08YnI+DQo8Yj5UbzwvYj46IE5hbmN5IEJyYXZpbiAmbHQ7bmJyYXZp bkBlYXJ0aGxpbmsubmV0Jmd0OyA8YnI+DQo8Yj5DYzwvYj46IHBhd3NAaWV0Zi5vcmcgJmx0O3Bh d3NAaWV0Zi5vcmcmZ3Q7IDxicj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW3Bhd3NdIFBBV1MgUHJv dG9jb2w6IFNob3VsZCAmcXVvdDtEZXZpY2UgbG9jYXRpb24mcXVvdDsgcmVhbGx5IGJlICZxdW90 O0FudGVubmEgbG9jYXRpb24mcXVvdDs/DQo8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0KPC9kaXY+ DQpUaGFua3MgQWxsLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U28gd2hhdCBJIGhlYXIgaXMg dGhhdCB0cnlpbmcgdG8gcmUtdXNlIGEgc3RhbmRhcmQgdGhhdCBkZXNjcmliZXMgbG9jYXRpb24g YXMgKGxhdGl0dWRlLCBsb25naXR1ZGUsIGFsdGl0dWRlKSBpcyBwcm9iYWJseSBub3QgYSBnb29k IGlkZWEuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UbyBmb2N1cyBzcGVjaWZpY2Fs bHkgb24gdGhlIGRpc2N1c3Npb24gb2YgaGVpZ2h0OjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+Jm5ic3A7LSBXaGV0aGVyIHByb3RlY3Rpb24gc2hvdWxkIGJlIGNvbXB1dGVkIHVzaW5n IGEgZGV2aWNlJ3MgSEFBVCBpcyBhIHJlZ3VsYXRvcnkgcnVsZS4gQXMgc3VjaCwgdGhlIERhdGFi YXNlIHNob3VsZCBiZSByZXNwb25zaWJsZSB0byBhcHBseWluZyB0aGUgcmlnaHQgcnVsZXMgKGlu Y2x1ZGluZyBob3cgdG8gY29tcHV0ZSBIQUFUKS4gV2Ugc2hvdWxkIG5vdCBiZSBidXJkZW5pbmcg YSBkZXZpY2Ugd2l0aCB0aG9zZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZvciB0 aGUgUEFXUyBwcm90b2NvbCwgd2Ugc2hvdWxkIGRlZmluZSBoZWlnaHQgaW4gYSB3YXkgdGhhdCBp cyBlYXN5IGZvciB0aGUgZGV2aWNlIHRvIGRldGVybWluZSBieSBpdHNlbGYgKG9yIGJ5IGFuIGlu c3RhbGxlciksIGluZGVwZW5kZW50IG9mIHJlZ3VsYXRvcnkgc3BlY2lmaWNzLiBUaGVyZSBhcHBl YXJzIHRvIG1lIHR3byBvcHRpb25zIHdlIHNob3VsZCBzdXBwb3J0OjwvZGl2Pg0KPGRpdj4NCjxk aXY+Jm5ic3A7ICZuYnNwOzEuIEhlaWdodCBhYm92ZSAocmVsYXRpdmUgdG8pIG1lYW4gc2VhIGxl dmVsLCBhcyBjYW4gYmUgcmVwb3J0ZWQgYnkgYSBHUFMsIG9yPC9kaXY+DQo8ZGl2PiZuYnNwOyAm bmJzcDsyLiBIZWlnaHQgYWJvdmUgZ3JvdW5kIChvciBzZWEgaW4gY2FzZSBvZiBhIGJyaWRnZSkg dGhhdCBjYW4gYmUgZGV0ZXJtaW5lZCBieSBkaXJlY3QgbWVhc3VyZW1lbnQgb3IgZW5naW5lZXJp bmcgZHJhd2luZ3M8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Rm9yIHRo ZSBmaXJzdCwgd2UgY291bGQgc3BlY2lmeSBXR1M4NC4gSWYgV0dTIHdlcmUgdG8gY2hhbmdlIGlu IHRoZSBmdXR1cmUsIGhvdyBtdWNoIGRpZmZlcmVuY2Ugd291bGQgd2UgZXhwZWN0PyBQcm9iYWJs eSB3b24ndCBhY3R1YWxseSBtYWtlIGEgZGlmZmVyZW5jZSBpbiBwcm90ZWN0aW9uIG9yIGF2YWls YWJsZSBzcGVjdHJ1bSBjb21wdXRhdGlvbnMuLi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkluIHRoZSBjYXNlIG9mIGEgYnJpZGdlIG9yIHNoaXAsIEkgY2xhaW0gb25lIG9mIHRoZSBh Ym92ZSB3aWxsIGRvLiBIb3cgdG8gY29tcHV0ZSBhdmFpbGFibGUgY2hhbm5lbHMgaXMgYSByZWd1 bGF0b3J5IHJ1bGUgd2hvc2UgZW5mb3JjZW1lbnQgYmVsb25ncyBpbiB0aGUgRGF0YWJhc2UuPC9k aXY+DQo8ZGl2Pkl0IHNob3VsZCBub3QgaW1wYWN0IHRoZSBQQVdTIHByb3RvY29sLjxicj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd291bGQgaG9wZSB0aGF0IG9uZSBvZiB0aGUgZ29hbHMg b2YgYSBzdGFuZGFyZCBpczo8YnI+DQo8ZGl2PiZuYnNwOy0gRXN0YWJsaXNoIHJlYXNvbmFibHkg ZmxleGlibGUgcGFyYW1ldGVyIHNldCB3aXRob3V0IGdvaW5nICZxdW90O292ZXJib2FyZCZxdW90 OyAocHVuIGludGVuZGVkKS4gSSB0aGluayB3ZSBzaG91bGQgcHJlc2VudCBhIG1vZGVsIGFyb3Vu ZCB3aGljaCByZWd1bGF0b3JzIGNvdWxkIGFsaWduLCByYXRoZXIgdGhhbiBlbmNvdXJhZ2UgZWFj aCB0byBjb21lIHVwIHdpdGggY29tcGxldGVseSBuZXcgcnVsZXMuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+VGhvdWdodHM/PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4tdmluY2U8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E7916FF82420BB40A104D4CAAB11C7880F4E78rrcdteexmb4dtetel_-- From ben@blindcreek.com Fri Oct 12 08:08: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 1FEA221F84F0 for ; Fri, 12 Oct 2012 08:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.275 X-Spam-Level: X-Spam-Status: No, score=0.275 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_50=0.001, 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 7wU4nLjDMiFt for ; Fri, 12 Oct 2012 08:08:14 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA3921F86B5 for ; Fri, 12 Oct 2012 08:08:14 -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=w+9jyoE7N9KyNMdg+MrdkqjQ2ABp7ZkJZtzWNViaNeY=; b=tM8tKtjxlhUIyHGwfxVd+mU9R2muR0sOmeAKK65dMtpeaEYoG3vscvOX+yzMBhl33T2y6PggCnpTRrDA4US5dYAxGbIFqUV8wsMWPmOTXQuzZj1+NpOXvYeHro/sXTKe; Received: from [64.74.213.174] (port=58975 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TMgqR-0008Ku-As for paws@ietf.org; Fri, 12 Oct 2012 10:08:12 -0500 Message-ID: <50783263.6060601@blindcreek.com> Date: Fri, 12 Oct 2012 08:08:19 -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: <5076FFB7.4030701@blindcreek.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 12 Oct 2012 15:08:15 -0000 On 10/11/2012 2:24 PM, Vincent Chen wrote:
Thanks All,

So what I hear is that trying to re-use a standard that describes location as (latitude, longitude, altitude) is probably not a good idea.
I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a good starting point for what you need to do to represent location.

Note that in both FCC and OfCom the number captured in the database is relative to the surface (HAAT or AGL) and not relative to the reference datum (i.e. MSL or MLLW), so the height value they're looking for is going to be relative to whatever datum they use to define terrain/ground elevation.  I'd suggest we add a field called "height" rather than use "altitude", so as to not confuse this from altitude as provided by a GPS receiver or barometric pressure measurement (height above the reference datum, usually just called MSL).  Use "altitude" to mean what most people think it means and "height" to mean what FCC, OfCom and other regulators want it to mean, which of course is slightly different depending on which regulation you are reading.  Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation and interference potential, I care about the antenna height relative to the stuff around it and not much about absolute altitude.

As for what "height" means, that will be defined by the regulations.  It may be different for every set of WS rules and it might even vary by region in a single regulatory domain. And it will evolve over time.

Your correct that the difference between the various datums isn't as big as the uncertainty allowed by current regs, but I'm not sure that matters as I don't see why the protocol would USE the value. It may be relevant to an application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know the regulatory domain you know what reference datum they use, as well as what how they calculate height, so maybe just knowing the regulatory region ID may be enough.

I also pointed out you likely need to carry additional information about the antenna as well, such what I listed from the OfCom requirements.  Sorry that is really a diversion for this thread, but as we talk about antennas it came to mind.


Hope that helps.
Ben



To focus specifically on the discussion of height:

 - Whether protection should be computed using a device's HAAT is a regulatory rule. As such, the Database should be responsible to applying the right rules (including how to compute HAAT). We should not be burdening a device with those.

For the PAWS protocol, we should define height in a way that is easy for the device to determine by itself (or by an installer), independent of regulatory specifics. There appears to me two options we should support:
   1. Height above (relative to) mean sea level, as can be reported by a GPS, or
   2. Height above ground (or sea in case of a bridge) that can be determined by direct measurement or engineering drawings

For the first, we could specify WGS84. If WGS were to change in the future, how much difference would we expect? Probably won't actually make a difference in protection or available spectrum computations...

In the case of a bridge or ship, I claim one of the above will do. How to compute available channels is a regulatory rule whose enforcement belongs in the Database.
It should not impact the PAWS protocol.

I would hope that one of the goals of a standard is:
 - Establish reasonably flexible parameter set without going "overboard" (pun intended). I think we should present a model around which regulators could align, rather than encourage each to come up with completely new rules.

Thoughts?

-vince

From vchen@google.com Fri Oct 12 09:59:28 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 6361F21F8752 for ; Fri, 12 Oct 2012 09:59:28 -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 GYmYWK03lccu for ; Fri, 12 Oct 2012 09:59:27 -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 0EB3D21F8749 for ; Fri, 12 Oct 2012 09:59:26 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2795054qcg.31 for ; Fri, 12 Oct 2012 09:59:25 -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=qZAbjvzPSSTV+McQ8vG6rvDtixUZuRjm0WOj8xplUJs=; b=RWcfzLyN1/zKW3jWScwoehCBGcO/8/0sCZIUChqB1fnQp8UgmGXHmaPGb0C4WVYe6x k3gkGnveTKXq3zjMlg7XMhxf/WJxQ3pip8yIH3h7LYm2ev+LNknHWMeiOGt8gAvN4U3J 26eYSwqRiplVS5IMLEb4CKUaKn+h8fqVTmt6x2pZNJIfKFSlh6xbMr3AcecZnTvb/D79 GIEQMiAAW1caaiNLVEeKk6Yr7/oX1jnnRQY4BkazpmqwLot25NuoV+uUuQPu50JdsHxl FnuCH7FQydgjQOT+5ivmw7QXTvleYbaX0AMFQz6DlS7iSxCJnVSGcyf3/hLlxYDg4hMM gINA== 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=qZAbjvzPSSTV+McQ8vG6rvDtixUZuRjm0WOj8xplUJs=; b=k32Hy27K5wm/eX1kdOYaaDFvNZO9cpNTYFsriwWc7Ro0UDid85jfifhcT9GoEmJrbO ByQTpwNgoai/6monMkAPB2Ix/Q3zdEK9S02yVeWbyyncBet/YrtEjH0Sjkp8Za8aEpP2 KA//g8HVprDLVUPZkYtw8jk/G6ofncy0EaG4a5tNhUrpuWWgnIUuvyNJZH5fwKs3qF+D dQTJ07JLvnjja7M7XqsxRLbgwGQhbt7jH8t8lCIpQsA9eHc80r8uHIPIZc6EgECESaNJ bQVmxFtpG1Bn9kUPuWem1vd8Q9r1en316e7diSXTNKGk7FcvwYbfkabpkhIV4wBeQsIy gsUg== MIME-Version: 1.0 Received: by 10.49.72.1 with SMTP id z1mr3327553qeu.2.1350061165428; Fri, 12 Oct 2012 09:59:25 -0700 (PDT) Received: by 10.229.234.9 with HTTP; Fri, 12 Oct 2012 09:59:25 -0700 (PDT) In-Reply-To: <50783263.6060601@blindcreek.com> References: <5076FFB7.4030701@blindcreek.com> <50783263.6060601@blindcreek.com> Date: Fri, 12 Oct 2012 09:59:25 -0700 Message-ID: From: Vincent Chen To: "Benjamin A. Rolfe" Content-Type: multipart/alternative; boundary=047d7b6da0c430bde404cbdf9c69 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk6k6Uvt+Vyt0qTWtbGtJu4eeFVKRIJPyDTnM9/zajV1dpGDnmWogGgpprtUnDdeyDrVjG8WS05RxPGBKu5SghaX1lMuplQu+HtgAX6kZRD8byO/O0ncJVxoIEwS2orHG+esl4zESqXQ0k68sQ07jjPzRCFpOBna9C7/bdlsdNiMg34W0LiFoovhKremIVY8bLMNo0T Cc: "paws@ietf.org" Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 12 Oct 2012 16:59:28 -0000 --047d7b6da0c430bde404cbdf9c69 Content-Type: text/plain; charset=ISO-8859-1 IMHO we should define a protocol that makes it easy to build devices that operation in as many regulatory domains as possible. In order to do that, we should minimize regulatory-domain logic in the devices. On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe wrote: > ** > On 10/11/2012 2:24 PM, Vincent Chen wrote: > > Thanks All, > > So what I hear is that trying to re-use a standard that describes > location as (latitude, longitude, altitude) is probably not a good idea. > > I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a > good starting point for what you need to do to represent location. > > Note that in both FCC and OfCom the number captured in the database is > relative to the surface (HAAT or AGL) and not relative to the reference > datum (i.e. MSL or MLLW), so the height value they're looking for is going > to be relative to whatever datum they use to define terrain/ground > elevation. I'd suggest we add a field called "height" rather than use > "altitude", so as to not confuse this from altitude as provided by a GPS > receiver or barometric pressure measurement (height above the reference > datum, usually just called MSL). Use "altitude" to mean what most people > think it means and "height" to mean what FCC, OfCom and other regulators > want it to mean, which of course is slightly different depending on which > regulation you are reading. Then we don't get tangled up in confusing (1) > and (2) below. As a radio guy noodling RF propagation and interference > potential, I care about the antenna height relative to the stuff around it > and not much about absolute altitude. > That's a good suggestion on using RFC 6225 plus a height specification. Setting aside FCC and Ofcom specifics for the moment.... While I agree that, from RF perspective, antenna height above surface is the relevant number. For PAWS protocol, though, I'd like to have a device be able to report location as automatically as possible (think portable) and as regulatory-independent as possible. That means the protocol should allow a height value that can be reported from a technology such as GPS, which is typically above sea level. (We're still allowing height above surface to be configured by fixed-device installers) It should be the Database's responsibility to convert those measurements to values that are relevant for RF in order to compute protection and available spectrum. That is, the Database should have terrain info, not the device. > > As for what "height" means, that will be defined by the regulations. It > may be different for every set of WS rules and it might even vary by region > in a single regulatory domain. And it will evolve over time. > > Your correct that the difference between the various datums isn't as big > as the uncertainty allowed by current regs, but I'm not sure that matters > as I don't see why the protocol would USE the value. It may be relevant to > an application process such as a provisioning system, so maybe we need to > transport the value. Or not, as if you know the regulatory domain you know > what reference datum they use, as well as what how they calculate height, > so maybe just knowing the regulatory region ID may be enough. > As I mentioned, we should minimize regulatory-specific logic in the device. That is, I don't think we should build knowledge of per-domain reference datum into a device. I'm hoping we can let the protocol drive the rules a bit. Simplify the logic in the device: - The Device reports height as "Above Surface" OR altitude "Above Sea Level". - Let each Database do any conversions it wants (including which one it trusts when both are specified). Any region-to-region differences should be in the DB, not in the device. If we can agree that this is a good idea (big if?), do we need to be precise about which datum is used for "Above Sea Level"? or can we leave it at that (Note that Ofcom does not specify datum for height). Complication from actual rules: - FCC asks for height above ground (surface) - Ofcom asks for height above sea level (but height is optional) Will we be able to have a Device report only one and still satisfy the intent of the rules? While we might be forced to build FCC- and Ofcom-specific logic into a device, hopefully we can influence future rules and harmonization efforts to be more flexible. (my 2 cents) > I also pointed out you likely need to carry *additional *information > about the antenna as well, such what I listed from the OfCom requirements. > Sorry that is really a diversion for this thread, but as we talk about > antennas it came to mind. > This is already accounted for in draft-vchen-paws-protocol-00. I wanted to focus only on the location-related fields in this thread. > > Hope that helps. > Ben > > > > > To focus specifically on the discussion of height: > > - Whether protection should be computed using a device's HAAT is a > regulatory rule. As such, the Database should be responsible to applying > the right rules (including how to compute HAAT). We should not be burdening > a device with those. > > For the PAWS protocol, we should define height in a way that is easy for > the device to determine by itself (or by an installer), independent of > regulatory specifics. There appears to me two options we should support: > 1. Height above (relative to) mean sea level, as can be reported by a > GPS, or > 2. Height above ground (or sea in case of a bridge) that can be > determined by direct measurement or engineering drawings > > For the first, we could specify WGS84. If WGS were to change in the > future, how much difference would we expect? Probably won't actually make a > difference in protection or available spectrum computations... > > In the case of a bridge or ship, I claim one of the above will do. How > to compute available channels is a regulatory rule whose enforcement > belongs in the Database. > It should not impact the PAWS protocol. > > I would hope that one of the goals of a standard is: > - Establish reasonably flexible parameter set without going "overboard" > (pun intended). I think we should present a model around which regulators > could align, rather than encourage each to come up with completely new > rules. > > Thoughts? > > -vince > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --047d7b6da0c430bde404cbdf9c69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

IMHO we should define a protoc= ol that makes it easy to build devices that operation in as many regulatory= domains as possible.
In order to do that, we should minimize reg= ulatory-domain logic in the devices.


On Fri, Oct 12, 2012 at 8:08 = AM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
=20 =20 =20
On 10/11/2012 2:24 PM, Vincent Chen wrote:
Thanks All,

So what I hear is that trying to re-use a standard that describes location as (latitude, longitude, altitude) is probably not a good idea.
I disagree. I think it's a good idea to reuse what applies; RFC 622= 5 is a good starting point for what you need to do to represent location.

Note that in both FCC and OfCom the number captured in the database is relative to the surface (HAAT or AGL) and not relative to the reference datum (i.e. MSL or MLLW), so the height value they're looking for is going to be relative to whatever datum they use to define terrain/ground elevation.=A0 I'd suggest we add a field call= ed "height" rather than use "altitude", so as to not c= onfuse this from altitude as provided by a GPS receiver or barometric pressure measurement (height above the reference datum, usually just called MSL).=A0 Use "altitude" to mean what most people think it mea= ns and "height" to mean what FCC, OfCom and other regulators want it= to mean, which of course is slightly different depending on which regulation you are reading.=A0 Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation and interference potential, I care about the antenna height relative to the stuff around it and not much about absolute altitude.
<= /blockquote>

That's a good suggestion on using RFC 6= 225 plus a height specification.=A0

Setting a= side FCC and Ofcom specifics for the moment....

While I agree that, from RF perspective, antenna = height above surface is the relevant number. For PAWS protocol, though, I&#= 39;d like to have a device be able to report location as automatically as p= ossible (think portable) and as regulatory-independent as possible.

That means the protocol should allow a height value tha= t can be reported from a technology such as GPS, which is typically above s= ea level.
(We're still allowing height above surface to be co= nfigured by fixed-device installers)

It should be the Database's responsibility to conve= rt those measurements to values that are relevant for RF in order to comput= e protection and available spectrum. That is, the Database should have terr= ain info, not the device.

=A0

As for what "height" means, that will be defined by the regulations.=A0 It may be different for every set of WS rules and it might even vary by region in a single regulatory domain. And it will evolve over time.
=

Your correct that the difference between the various datums isn't a= s big as the uncertainty allowed by current regs, but I'm not sure that matters as I don't see why the protocol would USE the value. I= t may be relevant to an application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know the regulatory domain you know what reference datum they use, as well as what how they calculate height, so maybe just knowing the regulatory region ID may be enough.

As I mentioned, we should minimize regulatory-specific logic in the= device. That is, I don't think we should build knowledge of per-domain= reference datum into a device.

I'm hoping we can let the protocol drive the rules = a bit. Simplify the logic in the device:
=A0- The Device reports = height as "Above Surface" OR altitude "Above Sea Level"= .
=A0- Let each Database do any conversions it wants (including which on= e it trusts when both are specified). Any region-to-region differences shou= ld be in the DB, not in the device.

If we can agre= e that this is a good idea (big if?), do we need to be precise about which = datum is used for "Above Sea Level"? or can we leave it at that (= Note that Ofcom does not specify datum for height).

Complication from actual rules:
=A0- FCC= asks for height above ground (surface)
=A0- Ofcom asks for heigh= t above sea level (but height is optional)

W= ill we be able to have a Device report only one and still satisfy the inten= t of the rules?

While we might be forced to build FCC- and Ofcom-specif= ic logic into a device, hopefully we can influence future rules and harmoni= zation efforts to be more flexible.

(my 2 cents)


I also pointed out you likely need to carry additional informati= on about the antenna as well, such what I listed from the OfCom requirements.=A0 Sorry that is really a diversion for this thread, but as we talk about antennas it came to mind.
<= br>
This is already accounted for in draft-vchen-paws-protocol-00. I wanted to focus only on the loca= tion-related fields in this thread.



Hope that helps.
Ben




To focus specifically on the discussion of height:

=A0- Whether protection should be computed using a device's HAAT is a regulatory rule. As such, the Database should be responsible to applying the right rules (including how to compute HAAT). We should not be burdening a device with those.

For the PAWS protocol, we should define height in a way that is easy for the device to determine by itself (or by an installer), independent of regulatory specifics. There appears to me two options we should support:
=A0 =A01. Height above (relative to) mean sea level, as can be reported by a GPS, or
=A0 =A02. Height above ground (or sea in case of a bridge) tha= t can be determined by direct measurement or engineering drawings

For the first, we could specify WGS84. If WGS were to change in the future, how much difference would we expect? Probably won't actually make a difference in protection or available spectrum computations...

In the case of a bridge or ship, I claim one of the above will do. How to compute available channels is a regulatory rule whose enforcement belongs in the Database.
It should not impact the PAWS protocol.

I would hope that one of the goals of a standard is:
=A0- Establish reasonably flexible parameter set without going "overboard" (pun intended). I think we should p= resent a model around which regulators could align, rather than encourage each to come up with completely new rules.

Thoughts?

-vince


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




--
-vince --047d7b6da0c430bde404cbdf9c69-- From vchen@google.com Fri Oct 12 10:38: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 C7E4C21F875E for ; Fri, 12 Oct 2012 10:38:47 -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 x+Zwz7yaCnMi for ; Fri, 12 Oct 2012 10:38:46 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 459D621F86C1 for ; Fri, 12 Oct 2012 10:38:46 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so33578qao.10 for ; Fri, 12 Oct 2012 10:38:45 -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=CK17tFrbocMiOvbNrYtCjSUMtj0ib3+IECSD5wfJ/1c=; b=QpBwiGGbO/J5MO89x1Rw/5YiZza2vxE//38GBI97Io+eU75Vnara9uXcZQnohjb48g SrYvZiGSTxEt0UHuRmf5vKSNgspvAi1VsiPXyPmgXB5fo/kfgjntE0wwk92/xp+bPk7N ZnFMdPPDnQN2VQ2+5oEiNfqwXyWsLaPdPzzENV7yHhJ5vIb7+RNxJIArLuj0XSTKIsOW IObWDz0jfYOhomdL/pZ+9rOUrzGNKyV4t61snAAeGtU5LxckZ7Gr7RWsISNe3BS136aw SIIk+t7onzzE3Z/g1LDz3iZfyMhn5AdarybVYCT+OKA5qhHlyObV1+TSsJH7lIpYjwuN 94Jg== 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=CK17tFrbocMiOvbNrYtCjSUMtj0ib3+IECSD5wfJ/1c=; b=QP1TcMwI1yWkp0O7Z65wqbSrF0+u6MjJpKnVO0t0ibkAWhlSKRvFGTBmG1RcjVRFQs XZ2w9kJ+aSYQpsOleZjhetqOaVMPriBdLV7iwoUalqvKniy676wXXbQRS9pmhGqmlbRM GA8O6Frjc8JH56QpR9U3ip+2ZsXSCFjLXOZfUMff2bXgXQjtCfRvtgJKYDkuuP7qT+jX 5PzVk6J2g5uBzJzIUrLmoXuAUPYiAs8PKoybXfnCi34s+3HhJRNTLwLH4PmP9XxBBGx6 BkVeucfFwAsy1R8FtpZSCiknzhlSyjOQZwNjBPtoRZPzJsYd07Y215lj8VqCqWWnQknp ciYA== MIME-Version: 1.0 Received: by 10.224.203.193 with SMTP id fj1mr8547903qab.13.1350063525623; Fri, 12 Oct 2012 10:38:45 -0700 (PDT) Received: by 10.229.234.9 with HTTP; Fri, 12 Oct 2012 10:38:45 -0700 (PDT) In-Reply-To: References: <5076FFB7.4030701@blindcreek.com> <50783263.6060601@blindcreek.com> Date: Fri, 12 Oct 2012 10:38:45 -0700 Message-ID: From: Vincent Chen To: "Benjamin A. Rolfe" Content-Type: multipart/alternative; boundary=20cf30051232de76b904cbe0285b X-System-Of-Record: true X-Gm-Message-State: ALoCoQkXD/bWaGLgIfIqRxpiEQwUJ6DK/qfvAcv6mOwBQy2GCX+bLMO8thrGg5Qm6N9JivWfy6N4IJrdfvhhQmw5YoY4DomKd6B10aSIUQnNwJlM24kcPPteZe8DR+S9/dPfKXspMuL09LuZXb91jS/pIAyaXtK5oBnDvlTWgTAQrxRyBW9Yq5EdLqS8kszWfWK26BOqXCWm Cc: "paws@ietf.org" Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 12 Oct 2012 17:38:47 -0000 --20cf30051232de76b904cbe0285b Content-Type: text/plain; charset=ISO-8859-1 Correction: FCC rules only state that the Database must "store" the fixed-device's "height above ground". It does not mandate that the Device must send "height above ground" over the wire. Thus, the protocol can still allow "Above Sea Level" from the device and let the database compute and store "height above ground". On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen wrote: > > IMHO we should define a protocol that makes it easy to build devices that > operation in as many regulatory domains as possible. > In order to do that, we should minimize regulatory-domain logic in the > devices. > > > On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe wrote: > >> ** >> On 10/11/2012 2:24 PM, Vincent Chen wrote: >> >> Thanks All, >> >> So what I hear is that trying to re-use a standard that describes >> location as (latitude, longitude, altitude) is probably not a good idea. >> >> I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a >> good starting point for what you need to do to represent location. >> >> Note that in both FCC and OfCom the number captured in the database is >> relative to the surface (HAAT or AGL) and not relative to the reference >> datum (i.e. MSL or MLLW), so the height value they're looking for is going >> to be relative to whatever datum they use to define terrain/ground >> elevation. I'd suggest we add a field called "height" rather than use >> "altitude", so as to not confuse this from altitude as provided by a GPS >> receiver or barometric pressure measurement (height above the reference >> datum, usually just called MSL). Use "altitude" to mean what most people >> think it means and "height" to mean what FCC, OfCom and other regulators >> want it to mean, which of course is slightly different depending on which >> regulation you are reading. Then we don't get tangled up in confusing (1) >> and (2) below. As a radio guy noodling RF propagation and interference >> potential, I care about the antenna height relative to the stuff around it >> and not much about absolute altitude. >> > > That's a good suggestion on using RFC 6225 plus a height specification. > > Setting aside FCC and Ofcom specifics for the moment.... > > While I agree that, from RF perspective, antenna height above surface is > the relevant number. For PAWS protocol, though, I'd like to have a device > be able to report location as automatically as possible (think portable) > and as regulatory-independent as possible. > > That means the protocol should allow a height value that can be reported > from a technology such as GPS, which is typically above sea level. > (We're still allowing height above surface to be configured by > fixed-device installers) > > It should be the Database's responsibility to convert those measurements > to values that are relevant for RF in order to compute protection and > available spectrum. That is, the Database should have terrain info, not the > device. > > > >> >> As for what "height" means, that will be defined by the regulations. It >> may be different for every set of WS rules and it might even vary by region >> in a single regulatory domain. And it will evolve over time. >> > >> Your correct that the difference between the various datums isn't as big >> as the uncertainty allowed by current regs, but I'm not sure that matters >> as I don't see why the protocol would USE the value. It may be relevant to >> an application process such as a provisioning system, so maybe we need to >> transport the value. Or not, as if you know the regulatory domain you know >> what reference datum they use, as well as what how they calculate height, >> so maybe just knowing the regulatory region ID may be enough. >> > > As I mentioned, we should minimize regulatory-specific logic in the > device. That is, I don't think we should build knowledge of per-domain > reference datum into a device. > > I'm hoping we can let the protocol drive the rules a bit. Simplify the > logic in the device: > - The Device reports height as "Above Surface" OR altitude "Above Sea > Level". > - Let each Database do any conversions it wants (including which one it > trusts when both are specified). Any region-to-region differences should be > in the DB, not in the device. > > If we can agree that this is a good idea (big if?), do we need to be > precise about which datum is used for "Above Sea Level"? or can we leave it > at that (Note that Ofcom does not specify datum for height). > > Complication from actual rules: > - FCC asks for height above ground (surface) > - Ofcom asks for height above sea level (but height is optional) > > Will we be able to have a Device report only one and still satisfy the > intent of the rules? > > While we might be forced to build FCC- and Ofcom-specific logic into a > device, hopefully we can influence future rules and harmonization efforts > to be more flexible. > > (my 2 cents) > > >> I also pointed out you likely need to carry *additional *information >> about the antenna as well, such what I listed from the OfCom requirements. >> Sorry that is really a diversion for this thread, but as we talk about >> antennas it came to mind. >> > > This is already accounted for in draft-vchen-paws-protocol-00. I wanted > to focus only on the location-related fields in this thread. > > >> >> Hope that helps. >> Ben >> >> >> >> >> To focus specifically on the discussion of height: >> >> - Whether protection should be computed using a device's HAAT is a >> regulatory rule. As such, the Database should be responsible to applying >> the right rules (including how to compute HAAT). We should not be burdening >> a device with those. >> >> For the PAWS protocol, we should define height in a way that is easy >> for the device to determine by itself (or by an installer), independent of >> regulatory specifics. There appears to me two options we should support: >> 1. Height above (relative to) mean sea level, as can be reported by >> a GPS, or >> 2. Height above ground (or sea in case of a bridge) that can be >> determined by direct measurement or engineering drawings >> >> For the first, we could specify WGS84. If WGS were to change in the >> future, how much difference would we expect? Probably won't actually make a >> difference in protection or available spectrum computations... >> >> In the case of a bridge or ship, I claim one of the above will do. How >> to compute available channels is a regulatory rule whose enforcement >> belongs in the Database. >> It should not impact the PAWS protocol. >> >> I would hope that one of the goals of a standard is: >> - Establish reasonably flexible parameter set without going "overboard" >> (pun intended). I think we should present a model around which regulators >> could align, rather than encourage each to come up with completely new >> rules. >> >> Thoughts? >> >> -vince >> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > -- -vince --20cf30051232de76b904cbe0285b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correction: FCC rules only state that the Database must "store" t= he fixed-device's "height above ground".
It does not mand= ate that the Device must send "height above ground" over the wire= .

Thus, the protocol can still allow "Above Sea Leve= l" from the device and let the database compute and store "height= above ground".


On Fri, O= ct 12, 2012 at 9:59 AM, Vincent Chen <vchen@google.com> wrote= :

IMHO we should define a protocol th= at makes it easy to build devices that operation in as many regulatory doma= ins as possible.
In order to do that, we should minimize regulatory-domain logic in the= devices.


On Fri, Oct= 12, 2012 at 8:08 AM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
=20 =20 =20
On 10/11/2012 2:24 PM, Vincent Chen wrote:
Thanks All,

So what I hear is that trying to re-use a standard that describes location as (latitude, longitude, altitude) is probably not a good idea.
I disagree. I think it's a good idea to reuse what applies; RFC 622= 5 is a good starting point for what you need to do to represent location.

Note that in both FCC and OfCom the number captured in the database is relative to the surface (HAAT or AGL) and not relative to the reference datum (i.e. MSL or MLLW), so the height value they're looking for is going to be relative to whatever datum they use to define terrain/ground elevation.=A0 I'd suggest we add a field call= ed "height" rather than use "altitude", so as to not c= onfuse this from altitude as provided by a GPS receiver or barometric pressure measurement (height above the reference datum, usually just called MSL).=A0 Use "altitude" to mean what most people think it mea= ns and "height" to mean what FCC, OfCom and other regulators want it= to mean, which of course is slightly different depending on which regulation you are reading.=A0 Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation and interference potential, I care about the antenna height relative to the stuff around it and not much about absolute altitude.
<= /blockquote>

That's a good suggestion on using= RFC 6225 plus a height specification.=A0

Setting aside FCC and Ofcom specifics for the moment....

While I agree that, from RF perspective, antenna = height above surface is the relevant number. For PAWS protocol, though, I&#= 39;d like to have a device be able to report location as automatically as p= ossible (think portable) and as regulatory-independent as possible.

That means the protocol should allow a height value tha= t can be reported from a technology such as GPS, which is typically above s= ea level.
(We're still allowing height above surface to be co= nfigured by fixed-device installers)

It should be the Database's responsibility to conve= rt those measurements to values that are relevant for RF in order to comput= e protection and available spectrum. That is, the Database should have terr= ain info, not the device.

=A0

As for what "height" means, that will be defined by the regulations.=A0 It may be different for every set of WS rules and it might even vary by region in a single regulatory domain. And it will evolve over time.
=

Your correct that the difference between the various datums isn't a= s big as the uncertainty allowed by current regs, but I'm not sure that matters as I don't see why the protocol would USE the value. I= t may be relevant to an application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know the regulatory domain you know what reference datum they use, as well as what how they calculate height, so maybe just knowing the regulatory region ID may be enough.

As I mentioned, we should minimize regulatory-specific logic = in the device. That is, I don't think we should build knowledge of per-= domain reference datum into a device.

I'm hoping we can let the protocol drive the rules = a bit. Simplify the logic in the device:
=A0- The Device reports = height as "Above Surface" OR altitude "Above Sea Level"= .
=A0- Let each Database do any conversions it wants (including which on= e it trusts when both are specified). Any region-to-region differences shou= ld be in the DB, not in the device.

If we can agre= e that this is a good idea (big if?), do we need to be precise about which = datum is used for "Above Sea Level"? or can we leave it at that (= Note that Ofcom does not specify datum for height).

Complication from actual rules:
=A0- FCC= asks for height above ground (surface)
=A0- Ofcom asks for heigh= t above sea level (but height is optional)

Will we be able to have a Device report only one and still satisfy the inte= nt of the rules?

While we might be forced to build FCC- and Ofcom-specif= ic logic into a device, hopefully we can influence future rules and harmoni= zation efforts to be more flexible.

(my 2 cents)


I also pointed out you likely need to carry additional informati= on about the antenna as well, such what I listed from the OfCom requirements.=A0 Sorry that is really a diversion for this thread, but as we talk about antennas it came to mind.
<= br>
This is already accounted for in draft-vchen-paws-= protocol-00. I wanted to focus only on the location-related fields in this = thread.



Hope that helps.
Ben




To focus specifically on the discussion of height:

=A0- Whether protection should be computed using a device's HAAT is a regulatory rule. As such, the Database should be responsible to applying the right rules (including how to compute HAAT). We should not be burdening a device with those.

For the PAWS protocol, we should define height in a way that is easy for the device to determine by itself (or by an installer), independent of regulatory specifics. There appears to me two options we should support:
=A0 =A01. Height above (relative to) mean sea level, as can be reported by a GPS, or
=A0 =A02. Height above ground (or sea in case of a bridge) tha= t can be determined by direct measurement or engineering drawings

For the first, we could specify WGS84. If WGS were to change in the future, how much difference would we expect? Probably won't actually make a difference in protection or available spectrum computations...

In the case of a bridge or ship, I claim one of the above will do. How to compute available channels is a regulatory rule whose enforcement belongs in the Database.
It should not impact the PAWS protocol.

I would hope that one of the goals of a standard is:
=A0- Establish reasonably flexible parameter set without going "overboard" (pun intended). I think we should p= resent a model around which regulators could align, rather than encourage each to come up with completely new rules.

Thoughts?

-vince


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




--
-vince



-- -vince
--20cf30051232de76b904cbe0285b-- From ben@blindcreek.com Fri Oct 12 13:42:55 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 DBB9421F87D5 for ; Fri, 12 Oct 2012 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=0.412, 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 roytV23NiQFL for ; Fri, 12 Oct 2012 13:42:54 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85921F87B8 for ; Fri, 12 Oct 2012 13:42:54 -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=LzUp+RZReeTWF+Nh0pCWlFEbUkZQvz7MBy1PhdVkaVs=; b=TqQSnb49+oIA2UpZyAQGZcwkCEKz1+V175ePHi0NV2ZuICMXR8pcbqJiHE9Opoypy37KMqHtuCOP89vhLVoJmIO09gc8D5YJpgj3tRNaaS/lLBj9NAl4Nk9LSWNPMFbd; Received: from [64.74.213.174] (port=61342 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TMm4J-0004mt-9L for paws@ietf.org; Fri, 12 Oct 2012 15:42:51 -0500 Message-ID: <507880D5.5010501@blindcreek.com> Date: Fri, 12 Oct 2012 13:43:01 -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: <5076FFB7.4030701@blindcreek.com> <50783263.6060601@blindcreek.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 12 Oct 2012 20:42:56 -0000 FCC Part 15.713 does say that the registration information must be in the database and doesn't say how it gets there. This is "registration" and must be completed before the device may operate. This is where I got the notion that it would be part of the device registration protocol. If that is outside the scope of PAWS then I'm sorry to have missed that.

As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 states conditions when both antenna height above ground and HAAT requirements must be used to determine if the device be provided channel availability data. Again may not need to be sent over the wire. But in the case of some 802 systems, we expect a local device will be a source of channel availability data (a fixed device serving a mode II device for example) and so this information will need to be acquired somehow.

I definitely prefer Vincents approach, where the TVWS device provides to the DB server 3D location and let the DB server do the work of accessing geographic data and calculating the rest. This may work in the US. 

OfCom seems specifically to state that the antenna height above ground will need to be communicated between the DB and the WS device, in 3.9 through 3.13 it gives conditions where antenna height both "may" and "must" be communicated a between the database and the master device. Again leads me to the notion that the protocol provide for the exchange.

Maybe we should separate device location from antenna parameters?  

-Ben
Correction: FCC rules only state that the Database must "store" the fixed-device's "height above ground".
It does not mandate that the Device must send "height above ground" over the wire.

Thus, the protocol can still allow "Above Sea Level" from the device and let the database compute and store "height above ground".


On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen <vchen@google.com> wrote:

IMHO we should define a protocol that makes it easy to build devices that operation in as many regulatory domains as possible.
In order to do that, we should minimize regulatory-domain logic in the devices.


On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
On 10/11/2012 2:24 PM, Vincent Chen wrote:
Thanks All,

So what I hear is that trying to re-use a standard that describes location as (latitude, longitude, altitude) is probably not a good idea.
I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a good starting point for what you need to do to represent location.

Note that in both FCC and OfCom the number captured in the database is relative to the surface (HAAT or AGL) and not relative to the reference datum (i.e. MSL or MLLW), so the height value they're looking for is going to be relative to whatever datum they use to define terrain/ground elevation.  I'd suggest we add a field called "height" rather than use "altitude", so as to not confuse this from altitude as provided by a GPS receiver or barometric pressure measurement (height above the reference datum, usually just called MSL).  Use "altitude" to mean what most people think it means and "height" to mean what FCC, OfCom and other regulators want it to mean, which of course is slightly different depending on which regulation you are reading.  Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation and interference potential, I care about the antenna height relative to the stuff around it and not much about absolute altitude.

That's a good suggestion on using RFC 6225 plus a height specification. 

Setting aside FCC and Ofcom specifics for the moment....

While I agree that, from RF perspective, antenna height above surface is the relevant number. For PAWS protocol, though, I'd like to have a device be able to report location as automatically as possible (think portable) and as regulatory-independent as possible.

That means the protocol should allow a height value that can be reported from a technology such as GPS, which is typically above sea level.
(We're still allowing height above surface to be configured by fixed-device installers)

It should be the Database's responsibility to convert those measurements to values that are relevant for RF in order to compute protection and available spectrum. That is, the Database should have terrain info, not the device.

 

As for what "height" means, that will be defined by the regulations.  It may be different for every set of WS rules and it might even vary by region in a single regulatory domain. And it will evolve over time.

Your correct that the difference between the various datums isn't as big as the uncertainty allowed by current regs, but I'm not sure that matters as I don't see why the protocol would USE the value. It may be relevant to an application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know the regulatory domain you know what reference datum they use, as well as what how they calculate height, so maybe just knowing the regulatory region ID may be enough.

As I mentioned, we should minimize regulatory-specific logic in the device. That is, I don't think we should build knowledge of per-domain reference datum into a device.

I'm hoping we can let the protocol drive the rules a bit. Simplify the logic in the device:
 - The Device reports height as "Above Surface" OR altitude "Above Sea Level".
 - Let each Database do any conversions it wants (including which one it trusts when both are specified). Any region-to-region differences should be in the DB, not in the device.

If we can agree that this is a good idea (big if?), do we need to be precise about which datum is used for "Above Sea Level"? or can we leave it at that (Note that Ofcom does not specify datum for height).

Complication from actual rules:
 - FCC asks for height above ground (surface)
 - Ofcom asks for height above sea level (but height is optional)

Will we be able to have a Device report only one and still satisfy the intent of the rules?

While we might be forced to build FCC- and Ofcom-specific logic into a device, hopefully we can influence future rules and harmonization efforts to be more flexible.

(my 2 cents)


I also pointed out you likely need to carry additional information about the antenna as well, such what I listed from the OfCom requirements.  Sorry that is really a diversion for this thread, but as we talk about antennas it came to mind.

This is already accounted for in draft-vchen-paws-protocol-00. I wanted to focus only on the location-related fields in this thread.



Hope that helps.
Ben




To focus specifically on the discussion of height:

 - Whether protection should be computed using a device's HAAT is a regulatory rule. As such, the Database should be responsible to applying the right rules (including how to compute HAAT). We should not be burdening a device with those.

For the PAWS protocol, we should define height in a way that is easy for the device to determine by itself (or by an installer), independent of regulatory specifics. There appears to me two options we should support:
   1. Height above (relative to) mean sea level, as can be reported by a GPS, or
   2. Height above ground (or sea in case of a bridge) that can be determined by direct measurement or engineering drawings

For the first, we could specify WGS84. If WGS were to change in the future, how much difference would we expect? Probably won't actually make a difference in protection or available spectrum computations...

In the case of a bridge or ship, I claim one of the above will do. How to compute available channels is a regulatory rule whose enforcement belongs in the Database.
It should not impact the PAWS protocol.

I would hope that one of the goals of a standard is:
 - Establish reasonably flexible parameter set without going "overboard" (pun intended). I think we should present a model around which regulators could align, rather than encourage each to come up with completely new rules.

Thoughts?

-vince


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




--
-vince



--
-vince

From peter@spectrumbridge.com Sun Oct 14 14:18:23 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 1A1F121F84F3 for ; Sun, 14 Oct 2012 14:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 j9HIUgLlKyUj for ; Sun, 14 Oct 2012 14:18:21 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3D83021F84EF for ; Sun, 14 Oct 2012 14:18:20 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sun, 14 Oct 2012 17:18:19 -0400 From: Peter Stanforth To: "Benjamin A. Rolfe" , "paws@ietf.org" Date: Sun, 14 Oct 2012 17:18:06 -0400 Thread-Topic: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? Thread-Index: Ac2qUW7omLZOL/ecTdmeJN3zf+TlXw== Message-ID: In-Reply-To: <507880D5.5010501@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CCA0A2632EAEBpeterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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: Sun, 14 Oct 2012 21:18:23 -0000 --_000_CCA0A2632EAEBpeterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Assuming the DB has access to terrain data, likely if it is doing any kind = of propagation calculation (required by FCC). Then the DB will be able to d= etermine the HAAT and other topographic data from the Lat/Long provided by = the device. The only thing the DB does not know is the height (above ground= at that location) of the antenna, which both FCC and Ofcom require. This i= s the "Height" the DB needs. Remember that Regulators are restricting the device to about 1W ERP so it d= oes not make much sense to have the device very far away from the antenna. = So the location of the device is a reasonable approximation for the locati= on of the antenna. In the FCC world personal/portable devices will be requi= red to have a permanently attached antenna. Fixed devices are being certifi= ed with "remote" antenna but the certification includes specific antenna th= at are permitted so even here there is not much room for error. Peter S. From: "Benjamin A. Rolfe" > Date: Friday, October ,12, 2012 Fri Oct 12, 4:43 PM To: "paws@ietf.org" > Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Ante= nna location"? FCC Part 15.713 does say that the registration information must be in the d= atabase and doesn't say how it gets there. This is "registration" and must = be completed before the device may operate. This is where I got the notion = that it would be part of the device registration protocol. If that is outsi= de the scope of PAWS then I'm sorry to have missed that. As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 st= ates conditions when both antenna height above ground and HAAT requirements= must be used to determine if the device be provided channel availability d= ata. Again may not need to be sent over the wire. But in the case of some 8= 02 systems, we expect a local device will be a source of channel availabili= ty data (a fixed device serving a mode II device for example) and so this i= nformation will need to be acquired somehow. I definitely prefer Vincents approach, where the TVWS device provides to th= e DB server 3D location and let the DB server do the work of accessing geog= raphic data and calculating the rest. This may work in the US. OfCom seems specifically to state that the antenna height above ground will= need to be communicated between the DB and the WS device, in 3.9 through 3= .13 it gives conditions where antenna height both "may" and "must" be commu= nicated a between the database and the master device. Again leads me to the= notion that the protocol provide for the exchange. Maybe we should separate device location from antenna parameters? -Ben Correction: FCC rules only state that the Database must "store" the fixed-d= evice's "height above ground". It does not mandate that the Device must send "height above ground" over th= e wire. Thus, the protocol can still allow "Above Sea Level" from the device and le= t the database compute and store "height above ground". On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen > wrote: IMHO we should define a protocol that makes it easy to build devices that o= peration in as many regulatory domains as possible. In order to do that, we should minimize regulatory-domain logic in the devi= ces. On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe > wrote: On 10/11/2012 2:24 PM, Vincent Chen wrote: Thanks All, So what I hear is that trying to re-use a standard that describes location = as (latitude, longitude, altitude) is probably not a good idea. I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a g= ood starting point for what you need to do to represent location. Note that in both FCC and OfCom the number captured in the database is rela= tive to the surface (HAAT or AGL) and not relative to the reference datum (= i.e. MSL or MLLW), so the height value they're looking for is going to be r= elative to whatever datum they use to define terrain/ground elevation. I'd= suggest we add a field called "height" rather than use "altitude", so as t= o not confuse this from altitude as provided by a GPS receiver or barometri= c pressure measurement (height above the reference datum, usually just call= ed MSL). Use "altitude" to mean what most people think it means and "heigh= t" to mean what FCC, OfCom and other regulators want it to mean, which of c= ourse is slightly different depending on which regulation you are reading. = Then we don't get tangled up in confusing (1) and (2) below. As a radio gu= y noodling RF propagation and interference potential, I care about the ante= nna height relative to the stuff around it and not much about absolute alti= tude. That's a good suggestion on using RFC 6225 plus a height specification. Setting aside FCC and Ofcom specifics for the moment.... While I agree that, from RF perspective, antenna height above surface is th= e relevant number. For PAWS protocol, though, I'd like to have a device be = able to report location as automatically as possible (think portable) and a= s regulatory-independent as possible. That means the protocol should allow a height value that can be reported fr= om a technology such as GPS, which is typically above sea level. (We're still allowing height above surface to be configured by fixed-device= installers) It should be the Database's responsibility to convert those measurements to= values that are relevant for RF in order to compute protection and availab= le spectrum. That is, the Database should have terrain info, not the device= . As for what "height" means, that will be defined by the regulations. It ma= y be different for every set of WS rules and it might even vary by region i= n a single regulatory domain. And it will evolve over time. Your correct that the difference between the various datums isn't as big as= the uncertainty allowed by current regs, but I'm not sure that matters as = I don't see why the protocol would USE the value. It may be relevant to an = application process such as a provisioning system, so maybe we need to tran= sport the value. Or not, as if you know the regulatory domain you know what= reference datum they use, as well as what how they calculate height, so ma= ybe just knowing the regulatory region ID may be enough. As I mentioned, we should minimize regulatory-specific logic in the device.= That is, I don't think we should build knowledge of per-domain reference d= atum into a device. I'm hoping we can let the protocol drive the rules a bit. Simplify the logi= c in the device: - The Device reports height as "Above Surface" OR altitude "Above Sea Leve= l". - Let each Database do any conversions it wants (including which one it tr= usts when both are specified). Any region-to-region differences should be i= n the DB, not in the device. If we can agree that this is a good idea (big if?), do we need to be precis= e about which datum is used for "Above Sea Level"? or can we leave it at th= at (Note that Ofcom does not specify datum for height). Complication from actual rules: - FCC asks for height above ground (surface) - Ofcom asks for height above sea level (but height is optional) Will we be able to have a Device report only one and still satisfy the inte= nt of the rules? While we might be forced to build FCC- and Ofcom-specific logic into a devi= ce, hopefully we can influence future rules and harmonization efforts to be= more flexible. (my 2 cents) I also pointed out you likely need to carry additional information about th= e antenna as well, such what I listed from the OfCom requirements. Sorry t= hat is really a diversion for this thread, but as we talk about antennas it= came to mind. This is already accounted for in draft-vchen-paws-protocol-00. I wanted to = focus only on the location-related fields in this thread. Hope that helps. Ben To focus specifically on the discussion of height: - Whether protection should be computed using a device's HAAT is a regulat= ory rule. As such, the Database should be responsible to applying the right= rules (including how to compute HAAT). We should not be burdening a device= with those. For the PAWS protocol, we should define height in a way that is easy for th= e device to determine by itself (or by an installer), independent of regula= tory specifics. There appears to me two options we should support: 1. Height above (relative to) mean sea level, as can be reported by a GP= S, or 2. Height above ground (or sea in case of a bridge) that can be determin= ed by direct measurement or engineering drawings For the first, we could specify WGS84. If WGS were to change in the future,= how much difference would we expect? Probably won't actually make a differ= ence in protection or available spectrum computations... In the case of a bridge or ship, I claim one of the above will do. How to c= ompute available channels is a regulatory rule whose enforcement belongs in= the Database. It should not impact the PAWS protocol. I would hope that one of the goals of a standard is: - Establish reasonably flexible parameter set without going "overboard" (p= un intended). I think we should present a model around which regulators cou= ld align, rather than encourage each to come up with completely new rules. Thoughts? -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince --_000_CCA0A2632EAEBpeterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Assuming the DB has acce= ss to terrain data, likely if it is doing any kind of propagation calculati= on (required by FCC). Then the DB will be able to determine the HAAT and ot= her topographic data from the Lat/Long provided by the device. The only thi= ng the DB does not know is the height (above ground at that location) of th= e antenna, which both FCC and Ofcom require. This is the "Height" the DB ne= eds. 
Remember that Regulators are restricting the device to= about 1W ERP so it does not make much sense to have the device very far aw= ay from the antenna.  So the location of the device is a reasonable ap= proximation for the location of the antenna. In the FCC world personal/port= able devices will be required to have a permanently attached antenna. Fixed= devices are being certified with "remote" antenna but the certification in= cludes specific antenna that are permitted so even here there is not much r= oom for error.
Peter S.


<= br>
From: "Benjamin A. R= olfe" <ben@blindcreek.com><= br>Date: Friday, October ,12, 2012= Fri Oct 12, 4:43 PM
To: "paws@ietf.org" <paws@ietf.org>
Subject:= Re: [paws] PAWS Protocol: Should "Device location" really be "Ante= nna location"?

FCC Part 15.713 does say that the registration information must be in the d= atabase and doesn't say how it gets there. This is "registration" and must = be completed before the device may operate. This is where I got the notion = that it would be part of the device registration protocol. If that is outside the scope of PAWS then I'm sorry= to have missed that.

As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 st= ates conditions when both antenna height above ground and HAAT requirements= must be used to determine if the device be provided channel availability d= ata. Again may not need to be sent over the wire. But in the case of some 802 systems, we expect a local devi= ce will be a source of channel availability data (a fixed device serving a = mode II device for example) and so this information will need to be acquire= d somehow.

I definitely prefer Vincents approach, where the TVWS device provides to th= e DB server 3D location and let the DB server do the work of accessing geog= raphic data and calculating the rest. This may work in the US. 

OfCom seems specifically to state that the antenna height above ground will= need to be communicated between the DB and the WS device, in 3.9 through 3= .13 it gives conditions where antenna height both "may" and "must" be commu= nicated a between the database and the master device. Again leads me to the notion that the protocol provide = for the exchange.

Maybe we should separate device location from antenna parameters? &nbs= p;

-Ben
Correction: FCC rules only state that the Database must "store" the fixed-d= evice's "height above ground".
It does not mandate that the Device must send "height above ground" ov= er the wire.

Thus, the protocol can still allow "A= bove Sea Level" from the device and let the database compute and store "hei= ght above ground".


On Fri, Oct= 12, 2012 at 9:59 AM, Vincent Chen <vchen@google.com> wrote:

IMHO we should define a protocol that makes it easy to build devices that o= peration in as many regulatory domains as possible.
In order to d= o that, we should minimize regulatory-domain logic in the devices.


On Fri, Oct 12= , 2012 at 8:08 AM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
On 10/11/2012 2:24 PM, Vincent Chen wrote:
Thanks All,

So what I hear is that trying to re-use a standard that= describes location as (latitude, longitude, altitude) is probably not a go= od idea.
I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a g= ood starting point for what you need to do to represent location.

Note that in both FCC and OfCom the number captured in the database is rela= tive to the surface (HAAT or AGL) and not relative to the reference datum (= i.e. MSL or MLLW), so the height value they're looking for is going to be r= elative to whatever datum they use to define terrain/ground elevation.  I'd suggest we add a field calle= d "height" rather than use "altitude", so as to not confuse this from altit= ude as provided by a GPS receiver or barometric pressure measurement (heigh= t above the reference datum, usually just called MSL).  Use "altitude" to mean what most people think it m= eans and "height" to mean what FCC, OfCom and other regulators want it to m= ean, which of course is slightly different depending on which regulation yo= u are reading.  Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation = and interference potential, I care about the antenna height relative to the= stuff around it and not much about absolute altitude.

That's a good suggestion on using RFC 6225 plus= a height specification. 

Setting aside = FCC and Ofcom specifics for the moment....

W= hile I agree that, from RF perspective, antenna height above surface is the= relevant number. For PAWS protocol, though, I'd like to have a device be a= ble to report location as automatically as possible (think portable) and as= regulatory-independent as possible.

That means the protocol should allow a = height value that can be reported from a technology such as GPS, which is t= ypically above sea level.
(We're still allowing height above surf= ace to be configured by fixed-device installers)

I= t should be the Database's responsibility to convert those measurements to = values that are relevant for RF in order to compute protection and availabl= e spectrum. That is, the Database should have terrain info, not the device.=

 

As for what "height" means, that will be defined by the regulations.  = It may be different for every set of WS rules and it might even vary by reg= ion in a single regulatory domain. And it will evolve over time.
<= /blockquote>

Your correct that the difference between the various datums isn't as big as= the uncertainty allowed by current regs, but I'm not sure that matters as = I don't see why the protocol would USE the value. It may be relevant to an = application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know th= e regulatory domain you know what reference datum they use, as well as what= how they calculate height, so maybe just knowing the regulatory region ID = may be enough.

As I mentioned, we should = minimize regulatory-specific logic in the device. That is, I don't think we= should build knowledge of per-domain reference datum into a device.
<= div>
I'm hoping we can let the protocol drive the rules a bit= . Simplify the logic in the device:
 - The Device reports he= ight as "Above Surface" OR altitude "Above Sea Level".
 - Le= t each Database do any conversions it wants (including which one it trusts = when both are specified). Any region-to-region differences should be in the= DB, not in the device.

If we can agree that this = is a good idea (big if?), do we need to be precise about which datum is use= d for "Above Sea Level"? or can we leave it at that (Note that Ofcom does n= ot specify datum for height).

Complication from ac= tual rules:
 - FCC asks for height above ground (surfac= e)
 - Ofcom asks for height above sea level (but height is o= ptional)

Will we be able to have a Device re= port only one and still satisfy the intent of the rules?

While we might be forced to build FCC- and Ofcom-specific logic into= a device, hopefully we can influence future rules and harmonization effort= s to be more flexible.

(my 2 cents)


I also pointed out you likely need to carry additional information a= bout the antenna as well, such what I listed from the OfCom requirements.&n= bsp; Sorry that is really a diversion for this thread, but as we talk about= antennas it came to mind.

= This is already accounted for in draft-vchen-paws-protocol-0= 0. I wanted to focus only on the location-related fields in this thread.



Hope that helps.
Ben




To focu= s specifically on the discussion of height:

 = - Whether protection should be computed using a device's HAAT is a regulato= ry rule. As such, the Database should be responsible to applying the right = rules (including how to compute HAAT). We should not be burdening a device = with those.

For the PAWS protocol, we should defin= e height in a way that is easy for the device to determine by itself (or by= an installer), independent of regulatory specifics. There appears to me tw= o options we should support:
   1. Height above (r= elative to) mean sea level, as can be reported by a GPS, or
 = ;  2. Height above ground (or sea in case of a bridge) that can be det= ermined by direct measurement or engineering drawings

<= /div>
For the first, we could specify WGS84. If WGS were to change in t= he future, how much difference would we expect? Probably won't actually mak= e a difference in protection or available spectrum computations...

In the case of a bridge or ship, I claim one of the above = will do. How to compute available channels is a regulatory rule whose enfor= cement belongs in the Database.
It should not impact the PAWS pro= tocol.

I would hope that one of the goals of a stand= ard is:
 - Establish reasonably flexible parameter set without= going "overboard" (pun intended). I think we should present a model around= which regulators could align, rather than encourage each to come up with c= ompletely new rules.

Thoughts?

-vince


=
_______________________________________________
paws mailing list
paws@ietf.org
https://w= ww.ietf.org/mailman/listinfo/paws




--
-vince



<= /div> --
-vince

--_000_CCA0A2632EAEBpeterspectrumbridgecom_-- From jmalyar@telcordia.com Sun Oct 14 15:08:14 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 BCE4221F84FC for ; Sun, 14 Oct 2012 15:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 IdoPW5YqIHuU for ; Sun, 14 Oct 2012 15:08:13 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietfa.amsl.com (Postfix) with ESMTP id E16BA21F84F8 for ; Sun, 14 Oct 2012 15:08:12 -0700 (PDT) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q9EM855i006544; Sun, 14 Oct 2012 18:08:05 -0400 (EDT) X-AuditID: 80602530-b7f726d000000e4c-2b-507b37c460e4 Received: from rrc-dte-exhb3.dte.telcordia.com (rrc-dte-exhb3.cc.telcordia.com [128.96.105.72]) by pya-dte-bms01.telcordia.com (Symantec Messaging Gateway) with SMTP id 62.04.03660.4C73B705; Sun, 14 Oct 2012 18:08:05 -0400 (EDT) Received: from RRC-DTE-EXMB4.dte.telcordia.com ([fe80::8ad:5ccb:8fe0:2314]) by rrc-dte-exhb3.dte.telcordia.com ([2002:8060:6948::8060:6948]) with mapi id 14.01.0379.000; Sun, 14 Oct 2012 18:08:04 -0400 From: "Malyar, John P" To: "Benjamin A. Rolfe" , "paws@ietf.org" Thread-Topic: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? Thread-Index: AQHNqLosmNKczHa2SUiJTCOLWi7VUJe5WqwV Date: Sun, 14 Oct 2012 22:08:03 +0000 Message-ID: References: <5076FFB7.4030701@blindcreek.com> <50783263.6060601@blindcreek.com> , <507880D5.5010501@blindcreek.com> In-Reply-To: <507880D5.5010501@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.96.150.200] Content-Type: multipart/alternative; boundary="_000_E7916FF82420BB40A104D4CAAB11C7880F5CE9rrcdteexmb4dtetel_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsXSkJDpoXvUvDrA4Ns/TouJFzcxWRzomcvs wOSx8vd2Fo8lS34yBTBFcdmkpOZklqUW6dslcGXc+fyAuWDaEcaKVS8CGxgPLmTsYuTkkBAw kbg7aSk7hC0mceHeerYuRi4OIYFnjBKdPW9YIJyzjBJbvs8Bq2IT0JO49a8TzBYR8JXoXLwH qIODQ1ggWuLXY2EQU0QgRuJsqw5EhZHE0nsb2UBsFgFVibMf7oHZvAIhEsvWLoLatZpZ4v70 TmaQBCfQ+HO3T4Idxwh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQtpLE1Y7T bBD1+RJ3L85nhVgmKHFy5hOWCYwis5CMmoWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4d YkEWX8DIvopRuqAyUTelJFU3KbfYwFCvJDUnOb8oJTNRLzk/dxMjOMpUDXYw7v6lfohRgINR iYd3ZqBdgBBrYllxZe4hRgkOZiUR3k8rgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5t+j7+wgJ pCeWpGanphakFsFkmTg4pRoYZzxLuyM+tSvasfzFV5ezSxPrG3ayOfBt9zBu5FfnS43udBPv Mk7WuMzZa81ZZeMQ2n5J//oDbw9h1b8bas7ONdwsx1l6wHNBvUN8Qn1rr4t6a9tpJha36D1T X3ad+edytu2sguWZ9w7tLw0vfc1RZZIK3Oxw+NRvZ9c3ZUb+N19OdLm06rgSS3FGoqEWc1Fx IgA3PcIKrgIAAA== Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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: Sun, 14 Oct 2012 22:08:15 -0000 --_000_E7916FF82420BB40A104D4CAAB11C7880F5CE9rrcdteexmb4dtetel_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ben, I think I agree but not sure if there is something subtle in your comments = that I am missing. I agree that the device should be able to communicate it= s lat/lon/height. As was mentioned for some device types (e.g. Fixed WSD) t= he height parameter is required by some Regulatory Authorities (e.g. US FCC= requires HAGL). I shared previously that the height parameter should be a = generalized value not sure "altitude" has a specific implied definition. Th= e value of HAAT should be the responsibility of the Database based on the R= egulatory Authority Policy. In the original draft submitted that was used f= or this merged document the method for registration was separate from the r= equest for available channels to allow for a clean separation of required f= unctionality (e.g in the US only Fixed WSD must register once or if they ar= e moved, Mode IIs do not register). Also more FYI in the US the FCC request= ed that the database provide the Fixed WSD registration capability over the= wire when Telcordia was certified (although it was not explicitly state). Best regards, John ________________________________ From: paws-bounces@ietf.org [paws-bounces@ietf.org] on behalf of Benjamin A= . Rolfe [ben@blindcreek.com] Sent: Friday, October 12, 2012 4:43 PM To: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Ante= nna location"? FCC Part 15.713 does say that the registration information must be in the d= atabase and doesn't say how it gets there. This is "registration" and must = be completed before the device may operate. This is where I got the notion = that it would be part of the device registration protocol. If that is outsi= de the scope of PAWS then I'm sorry to have missed that. As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 st= ates conditions when both antenna height above ground and HAAT requirements= must be used to determine if the device be provided channel availability d= ata. Again may not need to be sent over the wire. But in the case of some 8= 02 systems, we expect a local device will be a source of channel availabili= ty data (a fixed device serving a mode II device for example) and so this i= nformation will need to be acquired somehow. I definitely prefer Vincents approach, where the TVWS device provides to th= e DB server 3D location and let the DB server do the work of accessing geog= raphic data and calculating the rest. This may work in the US. OfCom seems specifically to state that the antenna height above ground will= need to be communicated between the DB and the WS device, in 3.9 through 3= .13 it gives conditions where antenna height both "may" and "must" be commu= nicated a between the database and the master device. Again leads me to the= notion that the protocol provide for the exchange. Maybe we should separate device location from antenna parameters? -Ben Correction: FCC rules only state that the Database must "store" the fixed-d= evice's "height above ground". It does not mandate that the Device must send "height above ground" over th= e wire. Thus, the protocol can still allow "Above Sea Level" from the device and le= t the database compute and store "height above ground". On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen > wrote: IMHO we should define a protocol that makes it easy to build devices that o= peration in as many regulatory domains as possible. In order to do that, we should minimize regulatory-domain logic in the devi= ces. On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe > wrote: On 10/11/2012 2:24 PM, Vincent Chen wrote: Thanks All, So what I hear is that trying to re-use a standard that describes location = as (latitude, longitude, altitude) is probably not a good idea. I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a g= ood starting point for what you need to do to represent location. Note that in both FCC and OfCom the number captured in the database is rela= tive to the surface (HAAT or AGL) and not relative to the reference datum (= i.e. MSL or MLLW), so the height value they're looking for is going to be r= elative to whatever datum they use to define terrain/ground elevation. I'd= suggest we add a field called "height" rather than use "altitude", so as t= o not confuse this from altitude as provided by a GPS receiver or barometri= c pressure measurement (height above the reference datum, usually just call= ed MSL). Use "altitude" to mean what most people think it means and "heigh= t" to mean what FCC, OfCom and other regulators want it to mean, which of c= ourse is slightly different depending on which regulation you are reading. = Then we don't get tangled up in confusing (1) and (2) below. As a radio gu= y noodling RF propagation and interference potential, I care about the ante= nna height relative to the stuff around it and not much about absolute alti= tude. That's a good suggestion on using RFC 6225 plus a height specification. Setting aside FCC and Ofcom specifics for the moment.... While I agree that, from RF perspective, antenna height above surface is th= e relevant number. For PAWS protocol, though, I'd like to have a device be = able to report location as automatically as possible (think portable) and a= s regulatory-independent as possible. That means the protocol should allow a height value that can be reported fr= om a technology such as GPS, which is typically above sea level. (We're still allowing height above surface to be configured by fixed-device= installers) It should be the Database's responsibility to convert those measurements to= values that are relevant for RF in order to compute protection and availab= le spectrum. That is, the Database should have terrain info, not the device= . As for what "height" means, that will be defined by the regulations. It ma= y be different for every set of WS rules and it might even vary by region i= n a single regulatory domain. And it will evolve over time. Your correct that the difference between the various datums isn't as big as= the uncertainty allowed by current regs, but I'm not sure that matters as = I don't see why the protocol would USE the value. It may be relevant to an = application process such as a provisioning system, so maybe we need to tran= sport the value. Or not, as if you know the regulatory domain you know what= reference datum they use, as well as what how they calculate height, so ma= ybe just knowing the regulatory region ID may be enough. As I mentioned, we should minimize regulatory-specific logic in the device.= That is, I don't think we should build knowledge of per-domain reference d= atum into a device. I'm hoping we can let the protocol drive the rules a bit. Simplify the logi= c in the device: - The Device reports height as "Above Surface" OR altitude "Above Sea Leve= l". - Let each Database do any conversions it wants (including which one it tr= usts when both are specified). Any region-to-region differences should be i= n the DB, not in the device. If we can agree that this is a good idea (big if?), do we need to be precis= e about which datum is used for "Above Sea Level"? or can we leave it at th= at (Note that Ofcom does not specify datum for height). Complication from actual rules: - FCC asks for height above ground (surface) - Ofcom asks for height above sea level (but height is optional) Will we be able to have a Device report only one and still satisfy the inte= nt of the rules? While we might be forced to build FCC- and Ofcom-specific logic into a devi= ce, hopefully we can influence future rules and harmonization efforts to be= more flexible. (my 2 cents) I also pointed out you likely need to carry additional information about th= e antenna as well, such what I listed from the OfCom requirements. Sorry t= hat is really a diversion for this thread, but as we talk about antennas it= came to mind. This is already accounted for in draft-vchen-paws-protocol-00. I wanted to = focus only on the location-related fields in this thread. Hope that helps. Ben To focus specifically on the discussion of height: - Whether protection should be computed using a device's HAAT is a regulat= ory rule. As such, the Database should be responsible to applying the right= rules (including how to compute HAAT). We should not be burdening a device= with those. For the PAWS protocol, we should define height in a way that is easy for th= e device to determine by itself (or by an installer), independent of regula= tory specifics. There appears to me two options we should support: 1. Height above (relative to) mean sea level, as can be reported by a GP= S, or 2. Height above ground (or sea in case of a bridge) that can be determin= ed by direct measurement or engineering drawings For the first, we could specify WGS84. If WGS were to change in the future,= how much difference would we expect? Probably won't actually make a differ= ence in protection or available spectrum computations... In the case of a bridge or ship, I claim one of the above will do. How to c= ompute available channels is a regulatory rule whose enforcement belongs in= the Database. It should not impact the PAWS protocol. I would hope that one of the goals of a standard is: - Establish reasonably flexible parameter set without going "overboard" (p= un intended). I think we should present a model around which regulators cou= ld align, rather than encourage each to come up with completely new rules. Thoughts? -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince --_000_E7916FF82420BB40A104D4CAAB11C7880F5CE9rrcdteexmb4dtetel_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ben,

 

I think I agree but not sure if there is something subtle in your commen= ts that I am missing. I agree that the device should be able to communicate= its lat/lon/height. As was mention= ed for some device types (e.g. Fixed WSD) the height parameter is required b= y some Regulatory Authorities (e.g. US FCC requires HAGL= ). I shared previously that the height parameter should be a generalized va= lue not sure "altitude" has a specific implied definition. The value of HAAT should be the responsibility of the Database based&= nbsp;on the Regulatory Authority Policy. In the original d= raft submitted that was used for this merged document the = method for registration was separate from the request for available channels to allow for a clean = separation of required functionality (e.g in the US only= Fixed WSD must register once or if they are moved, Mode=  IIs do not register). Also more FYI in the US the FCC requested that the database provide the Fi= xed WSD registration capability over the wire when&= nbsp;Telcordia was certified (although it was not explicitly = state).    

 

Best regards,

 

John        

From: paws-bounces@ietf.org [paws-bounces@= ietf.org] on behalf of Benjamin A. Rolfe [ben@blindcreek.com]
Sent: Friday, October 12, 2012 4:43 PM
To: paws@ietf.org
Subject: Re: [paws] PAWS Protocol: Should "Device location"= ; really be "Antenna location"?

FCC Part 15.713 does say that the registration information must be in = the database and doesn't say how it gets there. This is "registration&= quot; and must be completed before the device may operate. This is where I = got the notion that it would be part of the device registration protocol. If that is outside the scope of PAWS then I'= m sorry to have missed that.

As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 st= ates conditions when both antenna height above ground and HAAT requirements= must be used to determine if the device be provided channel availability d= ata. Again may not need to be sent over the wire. But in the case of some 802 systems, we expect a local devi= ce will be a source of channel availability data (a fixed device serving a = mode II device for example) and so this information will need to be acquire= d somehow.

I definitely prefer Vincents approach, where the TVWS device provides to th= e DB server 3D location and let the DB server do the work of accessing geog= raphic data and calculating the rest. This may work in the US. 

OfCom seems specifically to state that the antenna height above ground will= need to be communicated between the DB and the WS device, in 3.9 through 3= .13 it gives conditions where antenna height both "may" and "= ;must" be communicated a between the database and the master device. Again leads me to the notion that the protocol provide = for the exchange.

Maybe we should separate device location from antenna parameters? &nbs= p;

-Ben
Correction: FCC rules only state that the Databas= e must "store" the fixed-device's "height above ground"= .
It does not mandate that the Device must send "height above groun= d" over the wire.

Thus, the protocol can still allow "Above Sea Level" from th= e device and let the database compute and store "height above ground&q= uot;.


On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen <vchen@google.com<= /a>> wrote:

IMHO we should define a protocol that makes it easy to build devices that o= peration in as many regulatory domains as possible.
In order to do that, we should minimize regulatory-domain logic in the= devices.


On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe <ben@blindcreek.= com> wrote:
On 10/11/2012 2:24 PM, Vincent Chen wrote:
Thanks All,

So what I hear is that trying to re-use a standard that describes loca= tion as (latitude, longitude, altitude) is probably not a good idea.
I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a g= ood starting point for what you need to do to represent location.

Note that in both FCC and OfCom the number captured in the database is rela= tive to the surface (HAAT or AGL) and not relative to the reference datum (= i.e. MSL or MLLW), so the height value they're looking for is going to be r= elative to whatever datum they use to define terrain/ground elevation.  I'd suggest we add a field calle= d "height" rather than use "altitude", so as to not con= fuse this from altitude as provided by a GPS receiver or barometric pressur= e measurement (height above the reference datum, usually just called MSL).  Use "altitude" to mean what most people = think it means and "height" to mean what FCC, OfCom and other reg= ulators want it to mean, which of course is slightly different depending on= which regulation you are reading.  Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation = and interference potential, I care about the antenna height relative to the= stuff around it and not much about absolute altitude.

That's a good suggestion on using RFC 6225 plus a height specification= . 

Setting aside FCC and Ofcom specifics for the moment....

While I agree that, from RF perspective, antenna height above surface = is the relevant number. For PAWS protocol, though, I'd like to have a devic= e be able to report location as automatically as possible (think portable) = and as regulatory-independent as possible.

That means the protocol should allow a height value that can be report= ed from a technology such as GPS, which is typically above sea level.
(We're still allowing height above surface to be configured by fixed-d= evice installers)

It should be the Database's responsibility to convert those measuremen= ts to values that are relevant for RF in order to compute protection and av= ailable spectrum. That is, the Database should have terrain info, not the d= evice.

 

As for what "height" means, that will be defined by the regulatio= ns.  It may be different for every set of WS rules and it might even v= ary by region in a single regulatory domain. And it will evolve over time.<= br>

Your correct that the difference between the various datums isn't as big as= the uncertainty allowed by current regs, but I'm not sure that matters as = I don't see why the protocol would USE the value. It may be relevant to an = application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know th= e regulatory domain you know what reference datum they use, as well as what= how they calculate height, so maybe just knowing the regulatory region ID = may be enough.

As I mentioned, we should minimize regulatory-specific logic in the de= vice. That is, I don't think we should build knowledge of per-domain refere= nce datum into a device.

I'm hoping we can let the protocol drive the rules a bit. Simplify the= logic in the device:
 - The Device reports height as "Above Surface" OR alti= tude "Above Sea Level".
 - Let each Database do any conversions it wants (including which= one it trusts when both are specified). Any region-to-region differences s= hould be in the DB, not in the device.

If we can agree that this is a good idea (big if?), do we need to be p= recise about which datum is used for "Above Sea Level"? or can we= leave it at that (Note that Ofcom does not specify datum for height).

Complication from actual rules:
 - FCC asks for height above ground (surface)
 - Ofcom asks for height above sea level (but height is optional)=

Will we be able to have a Device report only one and still satisfy the= intent of the rules?

While we might be forced to build FCC- and Ofcom-specific logic into a= device, hopefully we can influence future rules and harmonization efforts = to be more flexible.

(my 2 cents)


I also pointed out you likely need to carry additional information a= bout the antenna as well, such what I listed from the OfCom requirements.&n= bsp; Sorry that is really a diversion for this thread, but as we talk about= antennas it came to mind.

This is already accounted for in draft-vchen-paws-protocol-0= 0. I wanted to focus only on the location-related fields in this thread.



Hope that helps.
Ben




To focus specifically on the discussion of height:

 - Whether protection should be computed using a device's HAAT is= a regulatory rule. As such, the Database should be responsible to applying= the right rules (including how to compute HAAT). We should not be burdenin= g a device with those.

For the PAWS protocol, we should define height in a way that is easy f= or the device to determine by itself (or by an installer), independent of r= egulatory specifics. There appears to me two options we should support:
   1. Height above (relative to) mean sea level, as can be r= eported by a GPS, or
   2. Height above ground (or sea in case of a bridge) that = can be determined by direct measurement or engineering drawings

For the first, we could specify WGS84. If WGS were to change in the fu= ture, how much difference would we expect? Probably won't actually make a d= ifference in protection or available spectrum computations...

In the case of a bridge or ship, I claim one of the above will do. How= to compute available channels is a regulatory rule whose enforcement belon= gs in the Database.
It should not impact the PAWS protocol.

I would hope that one of the goals of a standard is:
 - Establish reasonably flexible parameter set without going &quo= t;overboard" (pun intended). I think we should present a model around = which regulators could align, rather than encourage each to come up with co= mpletely new rules.

Thoughts?

-vince


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




--
-vince



--
-vince

--_000_E7916FF82420BB40A104D4CAAB11C7880F5CE9rrcdteexmb4dtetel_-- From Gabor.Bajko@nokia.com Tue Oct 23 14:23: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 597D821F85EB for ; Tue, 23 Oct 2012 14:23: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=[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 NvehgESFnZBD for ; Tue, 23 Oct 2012 14:23:43 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB591F0C91 for ; Tue, 23 Oct 2012 14:23:41 -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 q9NLNJRf011233; Wed, 24 Oct 2012 00:23:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 00:23:20 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.183]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0309.003; Tue, 23 Oct 2012 23:23:19 +0200 From: To: , Thread-Topic: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? Thread-Index: AQHNqLotozKeIXAPuE+hXV7dhu1wZpfHdqyA Date: Tue, 23 Oct 2012 21:23:19 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19@008-AM1MPN1-007.mgdnok.nokia.com> References: <5076FFB7.4030701@blindcreek.com> <50783263.6060601@blindcreek.com> <507880D5.5010501@blindcreek.com> In-Reply-To: <507880D5.5010501@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.115.108] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2012 21:23:20.0554 (UTC) FILETIME=[A0299CA0:01CDB164] X-Nokia-AV: Clean Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 23 Oct 2012 21:23:51 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I also think that separating the device location and antenna parameter= s is a good approach. This is what the requirements document requires too. So, send the device's (lon, lat, alt) location with related uncertainties a= nd datum; and separately, the antenna parameters. The DB can then combine t= hem, if it needs to, to provide the list of available channels. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Benjamin A. Rolfe Sent: Friday, October 12, 2012 1:43 PM To: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Ante= nna location"? FCC Part 15.713 does say that the registration information must be in the d= atabase and doesn't say how it gets there. This is "registration" and must = be completed before the device may operate. This is where I got the notion = that it would be part of the device registration protocol. If that is outsi= de the scope of PAWS then I'm sorry to have missed that. As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 st= ates conditions when both antenna height above ground and HAAT requirements= must be used to determine if the device be provided channel availability d= ata. Again may not need to be sent over the wire. But in the case of some 8= 02 systems, we expect a local device will be a source of channel availabili= ty data (a fixed device serving a mode II device for example) and so this i= nformation will need to be acquired somehow. I definitely prefer Vincents approach, where the TVWS device provides to th= e DB server 3D location and let the DB server do the work of accessing geog= raphic data and calculating the rest. This may work in the US. OfCom seems specifically to state that the antenna height above ground will= need to be communicated between the DB and the WS device, in 3.9 through 3= .13 it gives conditions where antenna height both "may" and "must" be commu= nicated a between the database and the master device. Again leads me to the= notion that the protocol provide for the exchange. Maybe we should separate device location from antenna parameters? -Ben Correction: FCC rules only state that the Database must "store" the fixed-d= evice's "height above ground". It does not mandate that the Device must send "height above ground" over th= e wire. Thus, the protocol can still allow "Above Sea Level" from the device and le= t the database compute and store "height above ground". On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen > wrote: IMHO we should define a protocol that makes it easy to build devices that o= peration in as many regulatory domains as possible. In order to do that, we should minimize regulatory-domain logic in the devi= ces. On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe > wrote: On 10/11/2012 2:24 PM, Vincent Chen wrote: Thanks All, So what I hear is that trying to re-use a standard that describes location = as (latitude, longitude, altitude) is probably not a good idea. I disagree. I think it's a good idea to reuse what applies; RFC 6225 is a g= ood starting point for what you need to do to represent location. Note that in both FCC and OfCom the number captured in the database is rela= tive to the surface (HAAT or AGL) and not relative to the reference datum (= i.e. MSL or MLLW), so the height value they're looking for is going to be r= elative to whatever datum they use to define terrain/ground elevation. I'd= suggest we add a field called "height" rather than use "altitude", so as t= o not confuse this from altitude as provided by a GPS receiver or barometri= c pressure measurement (height above the reference datum, usually just call= ed MSL). Use "altitude" to mean what most people think it means and "heigh= t" to mean what FCC, OfCom and other regulators want it to mean, which of c= ourse is slightly different depending on which regulation you are reading. = Then we don't get tangled up in confusing (1) and (2) below. As a radio gu= y noodling RF propagation and interference potential, I care about the ante= nna height relative to the stuff around it and not much about absolute alti= tude. That's a good suggestion on using RFC 6225 plus a height specification. Setting aside FCC and Ofcom specifics for the moment.... While I agree that, from RF perspective, antenna height above surface is th= e relevant number. For PAWS protocol, though, I'd like to have a device be = able to report location as automatically as possible (think portable) and a= s regulatory-independent as possible. That means the protocol should allow a height value that can be reported fr= om a technology such as GPS, which is typically above sea level. (We're still allowing height above surface to be configured by fixed-device= installers) It should be the Database's responsibility to convert those measurements to= values that are relevant for RF in order to compute protection and availab= le spectrum. That is, the Database should have terrain info, not the device= . As for what "height" means, that will be defined by the regulations. It ma= y be different for every set of WS rules and it might even vary by region i= n a single regulatory domain. And it will evolve over time. Your correct that the difference between the various datums isn't as big as= the uncertainty allowed by current regs, but I'm not sure that matters as = I don't see why the protocol would USE the value. It may be relevant to an = application process such as a provisioning system, so maybe we need to tran= sport the value. Or not, as if you know the regulatory domain you know what= reference datum they use, as well as what how they calculate height, so ma= ybe just knowing the regulatory region ID may be enough. As I mentioned, we should minimize regulatory-specific logic in the device.= That is, I don't think we should build knowledge of per-domain reference d= atum into a device. I'm hoping we can let the protocol drive the rules a bit. Simplify the logi= c in the device: - The Device reports height as "Above Surface" OR altitude "Above Sea Leve= l". - Let each Database do any conversions it wants (including which one it tr= usts when both are specified). Any region-to-region differences should be i= n the DB, not in the device. If we can agree that this is a good idea (big if?), do we need to be precis= e about which datum is used for "Above Sea Level"? or can we leave it at th= at (Note that Ofcom does not specify datum for height). Complication from actual rules: - FCC asks for height above ground (surface) - Ofcom asks for height above sea level (but height is optional) Will we be able to have a Device report only one and still satisfy the inte= nt of the rules? While we might be forced to build FCC- and Ofcom-specific logic into a devi= ce, hopefully we can influence future rules and harmonization efforts to be= more flexible. (my 2 cents) I also pointed out you likely need to carry additional information about th= e antenna as well, such what I listed from the OfCom requirements. Sorry t= hat is really a diversion for this thread, but as we talk about antennas it= came to mind. This is already accounted for in draft-vchen-paws-protocol-00. I wanted to = focus only on the location-related fields in this thread. Hope that helps. Ben To focus specifically on the discussion of height: - Whether protection should be computed using a device's HAAT is a regulat= ory rule. As such, the Database should be responsible to applying the right= rules (including how to compute HAAT). We should not be burdening a device= with those. For the PAWS protocol, we should define height in a way that is easy for th= e device to determine by itself (or by an installer), independent of regula= tory specifics. There appears to me two options we should support: 1. Height above (relative to) mean sea level, as can be reported by a GP= S, or 2. Height above ground (or sea in case of a bridge) that can be determin= ed by direct measurement or engineering drawings For the first, we could specify WGS84. If WGS were to change in the future,= how much difference would we expect? Probably won't actually make a differ= ence in protection or available spectrum computations... In the case of a bridge or ship, I claim one of the above will do. How to c= ompute available channels is a regulatory rule whose enforcement belongs in= the Database. It should not impact the PAWS protocol. I would hope that one of the goals of a standard is: - Establish reasonably flexible parameter set without going "overboard" (p= un intended). I think we should present a model around which regulators cou= ld align, rather than encourage each to come up with completely new rules. Thoughts? -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince -- -vince --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I also think that se= parating the device location and antenna parameters is a good approach. Thi= s is what the requirements document requires too.

So, send the device’= ;s (lon, lat, alt) location with related uncertainties and datum; and separ= ately, the antenna parameters. The DB can then combine them, if it needs to, to provide the list of available channels.<= /p>

 <= /p>

- =          Gabor

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.o= rg] On Behalf Of ext Benjamin A. Rolfe
Sent: Friday, October 12, 2012 1:43 PM
To: paws@ietf.org
Subject: Re: [paws] PAWS Protocol: Should "Device location"= ; really be "Antenna location"?

 

FCC Part 15.713 does say that the registration infor= mation must be in the database and doesn't say how it gets there. This is &= quot;registration" and must be completed before the device may operate= . This is where I got the notion that it would be part of the device registration protocol. If that is outside the scope = of PAWS then I'm sorry to have missed that.

As for HAAT requirements, The FCC Second Memorandum and Order FCC 10-174 st= ates conditions when both antenna height above ground and HAAT requirements= must be used to determine if the device be provided channel availability d= ata. Again may not need to be sent over the wire. But in the case of some 802 systems, we expect a local devi= ce will be a source of channel availability data (a fixed device serving a = mode II device for example) and so this information will need to be acquire= d somehow.

I definitely prefer Vincents approach, where the TVWS device provides to th= e DB server 3D location and let the DB server do the work of accessing geog= raphic data and calculating the rest. This may work in the US. 

OfCom seems specifically to state that the antenna height above ground will= need to be communicated between the DB and the WS device, in 3.9 through 3= .13 it gives conditions where antenna height both "may" and "= ;must" be communicated a between the database and the master device. Again leads me to the notion that the protocol provide = for the exchange.

Maybe we should separate device location from antenna parameters? &nbs= p;

-Ben

Correction: FCC rules only state that the Database m= ust "store" the fixed-device's "height above ground".

It does not mandate that the Device must send "= height above ground" over the wire.

 

Thus, the protocol can still allow "Above Sea L= evel" from the device and let the database compute and store "hei= ght above ground".

 

On Fri, Oct 12, 2012 at 9:59 AM, Vincent Chen <vchen@google.com>= ; wrote:


IMHO we should define a protocol that makes it easy to build devices that o= peration in as many regulatory domains as possible.

In order to do that, we should minimize regulatory-d= omain logic in the devices.

 

 

On Fri, Oct 12, 2012 at 8:08 AM, Benjamin A. Rolfe &= lt;ben@blindcreek.c= om> wrote:

On 10/11/2012 2:24 PM, Vincent Chen wrote:

Thanks All,

 

So what I hear is that trying to re-use a standard t= hat describes location as (latitude, longitude, altitude) is probably not a= good idea.

I disagree. I think it's a good idea to reuse what a= pplies; RFC 6225 is a good starting point for what you need to do to repres= ent location.

Note that in both FCC and OfCom the number captured in the database is rela= tive to the surface (HAAT or AGL) and not relative to the reference datum (= i.e. MSL or MLLW), so the height value they're looking for is going to be r= elative to whatever datum they use to define terrain/ground elevation.  I'd suggest we add a field calle= d "height" rather than use "altitude", so as to not con= fuse this from altitude as provided by a GPS receiver or barometric pressur= e measurement (height above the reference datum, usually just called MSL).  Use "altitude" to mean what most people = think it means and "height" to mean what FCC, OfCom and other reg= ulators want it to mean, which of course is slightly different depending on= which regulation you are reading.  Then we don't get tangled up in confusing (1) and (2) below. As a radio guy noodling RF propagation = and interference potential, I care about the antenna height relative to the= stuff around it and not much about absolute altitude.

 

That's a good suggestion on using RFC 6225 plus a he= ight specification. 

 

Setting aside FCC and Ofcom specifics for the moment= ....

 

While I agree that, from RF perspective, antenna hei= ght above surface is the relevant number. For PAWS protocol, though, I'd li= ke to have a device be able to report location as automatically as possible= (think portable) and as regulatory-independent as possible.

 

That means the protocol should allow a height value = that can be reported from a technology such as GPS, which is typically abov= e sea level.

(We're still allowing height above surface to be con= figured by fixed-device installers)

 

It should be the Database's responsibility to conver= t those measurements to values that are relevant for RF in order to compute= protection and available spectrum. That is, the Database should have terra= in info, not the device.

 

 


As for what "height" means, that will be defined by the regulatio= ns.  It may be different for every set of WS rules and it might even v= ary by region in a single regulatory domain. And it will evolve over time.<= o:p>


Your correct that the difference between the various datums isn't as big as= the uncertainty allowed by current regs, but I'm not sure that matters as = I don't see why the protocol would USE the value. It may be relevant to an = application process such as a provisioning system, so maybe we need to transport the value. Or not, as if you know th= e regulatory domain you know what reference datum they use, as well as what= how they calculate height, so maybe just knowing the regulatory region ID = may be enough.

 

As I mentioned, we should minimize regulatory-specif= ic logic in the device. That is, I don't think we should build knowledge of= per-domain reference datum into a device.

 

I'm hoping we can let the protocol drive the rules a= bit. Simplify the logic in the device:

 - The Device reports height as "Above Sur= face" OR altitude "Above Sea Level".

 - Let each Database do any conversions it want= s (including which one it trusts when both are specified). Any region-to-re= gion differences should be in the DB, not in the device.

 

If we can agree that this is a good idea (big if?), = do we need to be precise about which datum is used for "Above Sea Leve= l"? or can we leave it at that (Note that Ofcom does not specify datum= for height).

 

Complication from actual rules:

 - FCC asks for height above ground (surface)

 - Ofcom asks for height above sea level (but h= eight is optional)

 

Will we be able to have a Device report only one and= still satisfy the intent of the rules?

 

While we might be forced to build FCC- and Ofcom-spe= cific logic into a device, hopefully we can influence future rules and harm= onization efforts to be more flexible.

 

(my 2 cents)

 


I also pointed out you likely need to carry additional information a= bout the antenna as well, such what I listed from the OfCom requirements.&n= bsp; Sorry that is really a diversion for this thread, but as we talk about= antennas it came to mind.

 

This is already accounted for in draft-vchen-paws-protocol-00. I wanted to focus only on the locatio= n-related fields in this thread.

 



Hope that helps.
Ben





 

To focus specifically on the discussion of height:

 

 - Whether protection should be computed using = a device's HAAT is a regulatory rule. As such, the Database should be respo= nsible to applying the right rules (including how to compute HAAT). We shou= ld not be burdening a device with those.

 

For the PAWS protocol, we should define height in a = way that is easy for the device to determine by itself (or by an installer)= , independent of regulatory specifics. There appears to me two options we s= hould support:

   1. Height above (relative to) mean sea = level, as can be reported by a GPS, or

   2. Height above ground (or sea in case = of a bridge) that can be determined by direct measurement or engineering dr= awings

 

For the first, we could specify WGS84. If WGS were t= o change in the future, how much difference would we expect? Probably won't= actually make a difference in protection or available spectrum computation= s...

 

In the case of a bridge or ship, I claim one of the = above will do. How to compute available channels is a regulatory rule whose= enforcement belongs in the Database.

It should not impact the PAWS protocol.

 

I would hope that one of the goals of a standard is:=

 - Establish reasonably flexible parameter set = without going "overboard" (pun intended). I think we should prese= nt a model around which regulators could align, rather than encourage each = to come up with completely new rules.

 

Thoughts?

 

-vince

 

 

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



 

--
-vince



 

--
-vince

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19008AM1MPN1007mg_-- From Gabor.Bajko@nokia.com Tue Oct 23 14:32: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 04ACA11E80DC for ; Tue, 23 Oct 2012 14:32: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=[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 1eL8m5IUQEaV for ; Tue, 23 Oct 2012 14:32:15 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 185F111E8101 for ; Tue, 23 Oct 2012 14:32:14 -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 q9NLWCXs005433 for ; Wed, 24 Oct 2012 00:32:13 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 00:32:12 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.183]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0309.003; Tue, 23 Oct 2012 23:32:11 +0200 From: To: Thread-Topic: F2F session at IETF85 in Atlanta Thread-Index: Ac2PdDKxV3nQ9+C+QhORZsf33FFydQh8YuFA Date: Tue, 23 Oct 2012 21:32:10 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47602012484@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <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.115.108] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2012 21:32:12.0178 (UTC) FILETIME=[DD08FF20:01CDB165] X-Nokia-AV: Clean Subject: Re: [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: Tue, 23 Oct 2012 21:32:16 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you would like a timeslot to present in the upcoming F2F, please send a = request to the chairs. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Monday, September 10, 2012 9:51 AM To: paws@ietf.org Subject: [paws] F2F session at IETF85 in Atlanta Folks, FYI, I just requested a 2.5 hour session for PAWS at the Atlanta meeting. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you would like a ti= meslot to present in the upcoming F2F, please send a request to the chairs.=

Thanks, Gabor

 

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Monday, September 10, 2012 9:51 AM
To: paws@ietf.org
Subject: [paws] F2F session at IETF85 in Atlanta

 

Folks,

 

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

 

-     &= nbsp;    Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E008AM1MPN1007mg_-- From Gabor.Bajko@nokia.com Tue Oct 23 14:38:32 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 F336111E8101 for ; Tue, 23 Oct 2012 14:38:31 -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 iw8oQOTwGaM4 for ; Tue, 23 Oct 2012 14:38:30 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2D39611E80D9 for ; Tue, 23 Oct 2012 14:38:29 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9NLc2Sa009845; Wed, 24 Oct 2012 00:38:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 00:27:54 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.183]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0309.003; Tue, 23 Oct 2012 23:27:47 +0200 From: To: , Thread-Topic: New draft for PAWS protocol Thread-Index: AQHNod9L4ggZtTERm0OKj9fadgGKBpeojpnQgB72+MA= Date: Tue, 23 Oct 2012 21:27:46 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A@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: [10.163.115.108] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Oct 2012 21:27:54.0239 (UTC) FILETIME=[434AA0F0:01CDB165] X-Nokia-AV: Clean Subject: Re: [paws] New draft for PAWS protocol 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, 23 Oct 2012 21:38:32 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There has been no response whatsoever to this mail. I am not sure what that= means; is everyone ok with the draft Vince submitted, or did the wg loose = interest?? I will anyway intend to ask for adoption of it as a wg document in the upco= ming F2F. Therefore, if you have any issues with the draft, please send tho= se to the list prior to the F2F meeting. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Wednesday, October 03, 2012 9:36 PM To: vchen@google.com; paws@ietf.org Subject: Re: [paws] New draft for PAWS protocol Ok, thanks Vince. As a next step, I'd like to ask the WG to review it and send to the list an= y major problem identified with the text in this draft. Then, I'd like to ask the WG to adopt it as a wg document. - Gabor From: ext Vincent Chen [mailto:vchen@google.com] Sent: Wednesday, October 03, 2012 8:21 PM To: paws@ietf.org Cc: Bajko Gabor (Nokia-CIC/SiliconValley) Subject: New draft for PAWS protocol Hi All, We have submitted a draft for the PAWS protocol specification that represen= ts a merge of the non-controversial portions of the two documents presented at the Vancouver F2F. You can find it at: http://tools.ietf.org/html/draft-vchen-paws-protocol-00 Summary of changes: - Be more explicit about required vs optional vs "depends on regulatory do= main" - Describe the "Data Models" in a more hierarchical fashion and making it = more clear where extension points are located to address regulatory differences - General replacement of "channel" with "frequency" or "spectrum", when appropriate. This version does not include message encoding or specific error codes. -- -vince Vincent Chen Google, Inc. --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There has been no respons= e whatsoever to this mail. I am not sure what that means; is everyone ok wi= th the draft Vince submitted, or did the wg loose interest??

I will anyway intend to a= sk for adoption of it as a wg document in the upcoming F2F. Therefore, if y= ou have any issues with the draft, please send those to the list prior to the F2F meeting.

- =          Gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, October 03, 2012 9:36 PM
To: vchen@google.com; paws@ietf.org
Subject: Re: [paws] New draft for PAWS protocol

 

Ok, thanks Vince.

As a next step, I’d= like to ask the WG to review it and send to the list any major problem ide= ntified with the text in this draft.

Then, I’d like to a= sk the WG to adopt it as a wg document.

- =          Gabor<= /span>

 <= /p>

 <= /p>

From: ext Vinc= ent Chen [mailto:vchen@google.com] =
Sent: Wednesday, October 03, 2012 8:21 PM
To: paws@ietf.org
Cc: Bajko Gabor (Nokia-CIC/SiliconValley)
Subject: New draft for PAWS protocol

 

Hi All,

 

We have submitted a draft for the PAWS protocol spec= ification that represents a merge of the non-controversial portions

of the two documents presented at the Vancouver F2F.= You can find it at:

 

 

Summary of changes:

 - Be more explicit about required vs opti= onal vs "depends on regulatory domain"

 - Describe the "Data Models" in a mo= re hierarchical fashion and making it more clear

   where extension points are located= to address regulatory differences

 - General replacement of "channel" w= ith "frequency" or "spectrum", when

   appropriate.

 

This version does not include message encoding or sp= ecific error codes.

 

--
-vince

Vincent Chen

Google, Inc.

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B008AM1MPN1007mg_-- From cuiyang@huawei.com Tue Oct 23 19:00: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 60C2F11E811F for ; Tue, 23 Oct 2012 19:00:49 -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 jQCyUZndGOhR for ; Tue, 23 Oct 2012 19:00:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 47A4B11E80E9 for ; Tue, 23 Oct 2012 19:00:48 -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 ALZ83425; Wed, 24 Oct 2012 02:00:45 +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, 24 Oct 2012 03:00:33 +0100 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 24 Oct 2012 03:00:42 +0100 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.236]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Wed, 24 Oct 2012 10:00:33 +0800 From: Cuiyang To: "paws@ietf.org" Thread-Topic: New Version Notification for draft-wu-paws-secutity-01.txt Thread-Index: AQHNsE3e1JkiTjhbJkGv7Cx35ZQ7cZfHsBMQ Date: Wed, 24 Oct 2012 02:00:32 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE216368716ED@SZXEML508-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [paws] FW: New Version Notification for draft-wu-paws-secutity-01.txt 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, 24 Oct 2012 02:00:49 -0000 UEFXUyBXRywNCg0KVGhlIGZvbGxvd2luZyBpcyBvdXIgdXBkYXRlIHRvIGRyYWZ0LXd1LXBhd3Mt c2VjdXRpdHktMDAsIHdoaWNoIGlzIGZvY3VzZWQgb24gdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50 cyBhbmQgcG9zc2libGUgc29sdXRpb25zLg0KQW5kIHdlIHBsYW4gdG8gaW5jbHVkZSBtb3JlIGRl dGFpbHMgb2YgY2xpZW50IGF1dGggdXNpbmcgY2VydGlmaWNhdGUgYW5kIFBTSywgcmVzcGVjdGl2 ZWx5Lg0KDQpDb21tZW50cyBhcmUgd2VsY29tZSwgdGhhbmtzIGluIGFkdmFuY2UuDQoNClJlZ2Fy ZHMsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0NCiBZYW5nIEN1aSwgIFBoLkQuDQogSHVhd2Vp IFRlY2hub2xvZ2llcw0KIGN1aXlhbmdAaHVhd2VpLmNvbQ0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxMuW5tDEw5pyIMjLml6UgMjA6 MDgNCuaUtuS7tuS6ujogV3V5aXpodWFuZw0K5oqE6YCBOiBDdWl5YW5nDQrkuLvpopg6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0wMS50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0wMS50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWWl6aHVhbmcgV3UgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC13dS1wYXdzLXNlY3V0 aXR5DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3Bh Y2UgRGF0YWJhc2U6U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCkNyZWF0aW9uIGRhdGU6CSAyMDEy LTEwLTIyDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog MTMNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0wMS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dS1wYXdzLXNlY3V0aXR5DQpIdG1saXplZDog ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LXBhd3Mtc2VjdXRpdHkt MDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtd3UtcGF3cy1zZWN1dGl0eS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgYW5h bHlzZXMgY29tbW9uIHNlY3VyaXR5IHRocmVhdHMgb2YgdGhlIFByb3RvY29sIHRvDQogICBBY2Nl c3MgV2hpdGUgU3BhY2UgZGF0YWJhc2UgKFBBV1MpLCBhbmQgZGVzY3JpYmVzIHRoZWlyIHBvdGVu dGlhbA0KICAgaW1wYWN0cyBvbiBtZXNzYWdlIGV4Y2hhbmdlcyBiZXR3ZWVuIG1hc3RlciBkZXZp Y2UgYW5kIHdoaXRlIHNwYWNlDQogICBkYXRhYmFzZSB3aGVuIGltcGxlbWVudGluZyBQQVdTLiAg TWVhbndoaWxlLCB0aGUgY29ycmVzcG9uZGluZw0KICAgY291bnRlcm1lYXN1cmVzIGFyZSBhbHNv IGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSBQQVdTIGlzDQogICB1c2VkIGZvciBy ZXRyaWV2aW5nIHRoZSBhdmFpbGFibGUgd2hpdGUgc3BhY2UgaW5mb3JtYXRpb24gYXQgYSBnaXZl bg0KICAgbG9jYXRpb24gYW5kIHRpbWUgZnJvbSBhIHdoaXRlIHNwYWNlIGRhdGFiYXNlLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From cuiyang@huawei.com Tue Oct 23 20:33:10 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 269E811E8115 for ; Tue, 23 Oct 2012 20:33:10 -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, 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 sx27+uUFuxeq for ; Tue, 23 Oct 2012 20:33:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA5C11E80D3 for ; Tue, 23 Oct 2012 20:33:08 -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 ALZ89250; Wed, 24 Oct 2012 03:33:04 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 24 Oct 2012 04:32:54 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 24 Oct 2012 04:33:02 +0100 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.236]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 24 Oct 2012 11:32:59 +0800 From: Cuiyang To: "Gabor.Bajko@nokia.com" , "vchen@google.com" , "paws@ietf.org" Thread-Topic: New draft for PAWS protocol Thread-Index: AQHNod9L4ggZtTERm0OKj9fadgGKBpeojpnQgB72+MCAAE26MA== Date: Wed, 24 Oct 2012 03:32:58 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163687172C@SZXEML508-MBX.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B@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.48.135] Content-Type: multipart/alternative; boundary="_000_8CC0CB0BCAE52F46882E17828A9AE2163687172CSZXEML508MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] New draft for PAWS protocol 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, 24 Oct 2012 03:33:10 -0000 --_000_8CC0CB0BCAE52F46882E17828A9AE2163687172CSZXEML508MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEdhYm9yIGFuZCBWaW5jZW50LA0KDQpCYXNpY2FsbHksIHRoZSBtZXJnZWQgZHJhZnQgaXMg T2theSBmb3IgbWUuDQpCeSBub3csIG9uZSB0aGluZyB3b3J0aCBwb2ludGluZyBvdXQgaXMgdGhh dCB0aGUgbWFzdGVyIGRldmljZSBhdXRoZW50aWNhdGlvbiwgd2hpY2ggaGFzIGJlZW4gbWVudGlv bmVkIGluIGRyYWZ0LWlldGYtcGF3cy1wcm9ibGVtLXN0bXQtdXNlY2FzZXMtcnFtdHMsIGFzIGEg obBNVVNUobEuDQoNCi0tLXF1b3RlLS0NCg0KLSBTZWMgNi4xDQoNClAuNDogVGhlIHByb3RvY29s IE1VU1QgcHJvdmlkZSB0aGUgYWJpbGl0eSBmb3IgdGhlIGRhdGFiYXNlIHRvIGF1dGhlbnRpY2F0 ZSB0aGUgbWFzdGVyIGRldmljZS4NCg0KTy44OiBUaGUgZGF0YWJhc2UgTVVTVCByZXNwb25kIHRv IGFuIGF2YWlsYWJsZSBjaGFubmVsIGxpc3QgcmVxdWVzdCBmcm9tIGFuIGF1dGhlbnRpY2F0ZWQg YW5kIGF1dGhvcml6ZWQgZGV2aWNlDQoNCi0gU2VjIDggKHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z KQ0KVGhyZWF0IDE6IFVzZXIgbW9kaWZpZXMgYSBkZXZpY2UgdG8gbWFzcXVlcmFkZSBhcyBhbm90 aGVyIHZhbGlkIGNlcnRpZmllZCBkZXZpY2UNClRocmVhdCA1OiBVbmF1dGhvcml6ZWQgdXNlIG9m IGNoYW5uZWxzIGJ5IGFuIHVuY2VydGlmaWVkIGRldmljZQ0KDQotLS1xdW90ZS0tDQpCdXQgaW4g dGhlIG1lcmdlZCBkcmFmdCBTZWMgMTAuNCwgaXQgaXMgc2FpZCB0aGF0IKGwQ29uc2VxdWVudGx5 LCBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgbm90IHJlcXVpcmVkIGZvciB0aGUgUEFXUyBwcm90 b2NvbC6hsQ0KDQpJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHdlIGNsYXJpZnkgdGhpcyBj b250cmFkaWN0aW9uLCBzdWNoIGFzLCByZW1vdmUgdGhlIHVuZGVybHlpbmcgc2VudGVuY2U7IG90 aGVyd2lzZSBwZW9wbGUgbWF5IHdvbmRlciB3aGV0aGVyIHdlIG5lZWQgYSChsE1VU1ShsSBjYXBh YmlsaXR5IGZvciBhIKGwbm90IHJlcXVpcmVkobEgZmVhdHVyZS4NCkFsdGVybmF0aXZlbHksIHdl IGNvdWxkIGNoYW5nZSB0aGUgobBNVVNUobEgdG8gobBNQVmhsSBpbiB0aGUgcnFtdHMgV0cgZG9j dW1lbnQuDQoNCkJUVywgdGhlIHR3byBjb25jZXJucyBmb3IgY2xpZW50IGF1dGggaW4gU2VjIDEw LjQsDQoNCi0gICAgICAgICAgQXV0aG9yaXphdGlvbg0KDQotICAgICAgICAgIENyZWRlbnRpYWwg bGVha2FnZQ0KaGF2ZSBiZWVuIHRha2VuIGNhcmUgb2YgaW4gdGhlIGRyYWZ0IGRyYWZ0LXd1LXBh d3Mtc2VjdXRpdHktMDEuDQoNClJlZ2FyZHMsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0NCllh bmcgQ3VpLCAgUGguRC4NCkh1YXdlaSBUZWNobm9sb2dpZXMNCmN1aXlhbmdAaHVhd2VpLmNvbQ0K DQq3orz+yMs6IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBHYWJvci5CYWprb0Bub2tpYS5jb20NCreiy83KsbzkOiAyMDEyxOoxMNTCMjTI 1SA1OjI4DQrK1bz+yMs6IHZjaGVuQGdvb2dsZS5jb207IHBhd3NAaWV0Zi5vcmcNCtb3zOI6IFJl OiBbcGF3c10gTmV3IGRyYWZ0IGZvciBQQVdTIHByb3RvY29sDQoNClRoZXJlIGhhcyBiZWVuIG5v IHJlc3BvbnNlIHdoYXRzb2V2ZXIgdG8gdGhpcyBtYWlsLiBJIGFtIG5vdCBzdXJlIHdoYXQgdGhh dCBtZWFuczsgaXMgZXZlcnlvbmUgb2sgd2l0aCB0aGUgZHJhZnQgVmluY2Ugc3VibWl0dGVkLCBv ciBkaWQgdGhlIHdnIGxvb3NlIGludGVyZXN0Pz8NCkkgd2lsbCBhbnl3YXkgaW50ZW5kIHRvIGFz ayBmb3IgYWRvcHRpb24gb2YgaXQgYXMgYSB3ZyBkb2N1bWVudCBpbiB0aGUgdXBjb21pbmcgRjJG LiBUaGVyZWZvcmUsIGlmIHlvdSBoYXZlIGFueSBpc3N1ZXMgd2l0aCB0aGUgZHJhZnQsIHBsZWFz ZSBzZW5kIHRob3NlIHRvIHRoZSBsaXN0IHByaW9yIHRvIHRoZSBGMkYgbWVldGluZy4NCg0KLSAg ICAgICAgICBHYWJvcg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1Np bGljb25WYWxsZXkpDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDMsIDIwMTIgOTozNiBQTQ0K VG86IHZjaGVuQGdvb2dsZS5jb207IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF3c10g TmV3IGRyYWZ0IGZvciBQQVdTIHByb3RvY29sDQoNCk9rLCB0aGFua3MgVmluY2UuDQpBcyBhIG5l eHQgc3RlcCwgSaGvZCBsaWtlIHRvIGFzayB0aGUgV0cgdG8gcmV2aWV3IGl0IGFuZCBzZW5kIHRv IHRoZSBsaXN0IGFueSBtYWpvciBwcm9ibGVtIGlkZW50aWZpZWQgd2l0aCB0aGUgdGV4dCBpbiB0 aGlzIGRyYWZ0Lg0KVGhlbiwgSaGvZCBsaWtlIHRvIGFzayB0aGUgV0cgdG8gYWRvcHQgaXQgYXMg YSB3ZyBkb2N1bWVudC4NCg0KLSAgICAgICAgICBHYWJvcg0KDQoNCkZyb206IGV4dCBWaW5jZW50 IENoZW4gW21haWx0bzp2Y2hlbkBnb29nbGUuY29tXTxtYWlsdG86W21haWx0bzp2Y2hlbkBnb29n bGUuY29tXT4NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwMywgMjAxMiA4OjIxIFBNDQpUbzog cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCkNjOiBCYWprbyBHYWJvciAoTm9r aWEtQ0lDL1NpbGljb25WYWxsZXkpDQpTdWJqZWN0OiBOZXcgZHJhZnQgZm9yIFBBV1MgcHJvdG9j b2wNCg0KSGkgQWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IGZvciB0aGUgUEFXUyBw cm90b2NvbCBzcGVjaWZpY2F0aW9uIHRoYXQgcmVwcmVzZW50cyBhIG1lcmdlIG9mIHRoZSBub24t Y29udHJvdmVyc2lhbCBwb3J0aW9ucw0Kb2YgdGhlIHR3byBkb2N1bWVudHMgcHJlc2VudGVkIGF0 IHRoZSBWYW5jb3V2ZXIgRjJGLiBZb3UgY2FuIGZpbmQgaXQgYXQ6DQoNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXZjaGVuLXBhd3MtcHJvdG9jb2wtMDANCg0KU3VtbWFyeSBvZiBj aGFuZ2VzOg0KIC0gQmUgbW9yZSBleHBsaWNpdCBhYm91dCByZXF1aXJlZCB2cyBvcHRpb25hbCB2 cyAiZGVwZW5kcyBvbiByZWd1bGF0b3J5IGRvbWFpbiINCiAtIERlc2NyaWJlIHRoZSAiRGF0YSBN b2RlbHMiIGluIGEgbW9yZSBoaWVyYXJjaGljYWwgZmFzaGlvbiBhbmQgbWFraW5nIGl0IG1vcmUg Y2xlYXINCiAgIHdoZXJlIGV4dGVuc2lvbiBwb2ludHMgYXJlIGxvY2F0ZWQgdG8gYWRkcmVzcyBy ZWd1bGF0b3J5IGRpZmZlcmVuY2VzDQogLSBHZW5lcmFsIHJlcGxhY2VtZW50IG9mICJjaGFubmVs IiB3aXRoICJmcmVxdWVuY3kiIG9yICJzcGVjdHJ1bSIsIHdoZW4NCiAgIGFwcHJvcHJpYXRlLg0K DQpUaGlzIHZlcnNpb24gZG9lcyBub3QgaW5jbHVkZSBtZXNzYWdlIGVuY29kaW5nIG9yIHNwZWNp ZmljIGVycm9yIGNvZGVzLg0KDQotLQ0KLXZpbmNlDQpWaW5jZW50IENoZW4NCkdvb2dsZSwgSW5j Lg0K --_000_8CC0CB0BCAE52F46882E17828A9AE2163687172CSZXEML508MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Gabor = and Vincent,

 = ;

Basically,= the merged draft is Okay for me.

By now, on= e thing worth pointing out is that the master device authentication, which = has been mentioned in draft-ietf-paws-problem-stmt-usecases-rqmts, as a =A1=B0MUST=A1=B1.

---q= uote--

- Sec 6.1

P.4: The protocol MUST = provide the ability for the database to authenticate the master device.

O.8: The database MUST = respond to an available channel list request from an authenticated and auth= orized device

- Sec 8 (security consi= derations)

Threat 1: User modifies a dev= ice to masquerade as another valid certified device

Threat 5: Unauthorized use of= channels by an uncertified device

---q= uote--

But in the merged draft Sec 10.4, it is said that =A1=B0= Consequently, client authentication is not required for the PAWS protocol.=A1=B1

 = ;

I would li= ke to suggest that we clarify this contradiction, such as, remove the under= lying sentence; otherwise people may wonder whether we need a =A1=B0MUST=A1=B1 capability for a =A1=B0not required=A1=B1 feature.=

Alternativ= ely, we could change the =A1=B0MUST=A1=B1 to =A1=B0MAY=A1=B1 in the rqmts W= G document.

 = ;

BTW, the t= wo concerns for client auth in Sec 10.4,

-Au= thorization

-Cr= edential leakage

have been = taken care of in the draft draft-wu-paws-secutity-01.

 = ;

Regards,

Yang<= /o:p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Yang Cui,  Ph.D.<= /o:p>

Huawei Technologies

cuiyang@huawei.com

 = ;

=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=EA10=D4=C224=C8=D5 5:28
=CA=D5=BC=FE=C8=CB: vchen@google.com; paws@ietf.org
=D6=F7=CC=E2: Re: [paws] New draft for PAWS protocol

 

There has = been no response whatsoever to this mail. I am not sure what that means; is= everyone ok with the draft Vince submitted, or did the wg loose interest??

I will any= way intend to ask for adoption of it as a wg document in the upcoming F2F. = Therefore, if you have any issues with the draft, please send those to the list prior to the F2F meeting.

-          Ga= bor

 = ;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, October 03, 2012 9:36 PM
To: vchen@google.com; paws@ietf.org
Subject: Re: [paws] New draft for PAWS protocol

 

Ok, thanks= Vince.

As a next = step, I=A1=AFd like to ask the WG to review it and send to the list any maj= or problem identified with the text in this draft.

Then, I=A1= =AFd like to ask the WG to adopt it as a wg document.

-          Ga= bor

 = ;

 = ;

From: ext Vincent Chen [mailto:vchen@google.com] =
Sent: Wednesday, October 03, 2012 8:21 PM
To: paws@ietf.org
Cc: Bajko Gabor (Nokia-CIC/SiliconValley)
Subject: New draft for PAWS protocol

 

Hi All,

 

We have submitted a draft for t= he PAWS protocol specification that represents a merge of the non-controver= sial portions

of the two documents presented = at the Vancouver F2F. You can find it at:

 

 

Summary of changes:<= /span>

 - Be more explicit a= bout required vs optional vs "depends on regulatory domain"<= /o:p>

 - Describe the "Data= Models" in a more hierarchical fashion and making it more clear<= o:p>

   where extension po= ints are located to address regulatory differences

 - General replacement of = "channel" with "frequency" or "spectrum", whe= n

   appropriate.<= /o:p>

 

This version does not include m= essage encoding or specific error codes.

 

--
-vince

Vincent Chen<= /p>

Google, Inc.<= /p>

--_000_8CC0CB0BCAE52F46882E17828A9AE2163687172CSZXEML508MBXchi_-- From cuiyang@huawei.com Tue Oct 23 21:16: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 D7D5D11E8115 for ; Tue, 23 Oct 2012 21:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[AWL=-1.401, 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 r8rnNg-yGtRy for ; Tue, 23 Oct 2012 21:16:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21CDD11E810B for ; Tue, 23 Oct 2012 21:16:56 -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 ALZ91839; Wed, 24 Oct 2012 04:16:52 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 24 Oct 2012 05:15:26 +0100 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 24 Oct 2012 05:15:34 +0100 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.236]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Wed, 24 Oct 2012 12:15:31 +0800 From: Cuiyang To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" , "br@brianrosen.net" Thread-Topic: F2F session at IETF85 in Atlanta Thread-Index: Ac2PdDKxV3nQ9+C+QhORZsf33FFydQh8YuFAAA4VxHA= Date: Wed, 24 Oct 2012 04:15:30 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE2163687174A@SZXEML508-MBX.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47602012484@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E@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.48.135] Content-Type: multipart/alternative; boundary="_000_8CC0CB0BCAE52F46882E17828A9AE2163687174ASZXEML508MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [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: Wed, 24 Oct 2012 04:16:59 -0000 --_000_8CC0CB0BCAE52F46882E17828A9AE2163687174ASZXEML508MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEdhYm9yIGFuZCBCcmlhbg0KDQpXZSB3b3VsZCBsaWtlIHRvIGFzayBmb3IgYSB0aW1lIHNs b3QgZm9yIGludHJvZHVjaW5nIG91ciBkcmFmdC13dS1wYXdzLXNlY3V0aXR5LTAxLg0KDQpUaGFu a3MsDQpZYW5nDQo9PT09PT09PT09PT09PT09PT0NCllhbmcgQ3VpLCAgUGguRC4NCkh1YXdlaSBU ZWNobm9sb2dpZXMNCmN1aXlhbmdAaHVhd2VpLmNvbQ0KDQoNCj09PT09PT09PT09PT09PT09PQ0K WWFuZyBDdWksICBQaC5ELg0KSHVhd2VpIFRlY2hub2xvZ2llcw0KY3VpeWFuZ0BodWF3ZWkuY29t DQoNCreivP7IyzogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIEdhYm9yLkJhamtvQG5va2lhLmNvbQ0Kt6LLzcqxvOQ6IDIwMTLE6jEw1MIy NMjVIDU6MzINCsrVvP7IyzogcGF3c0BpZXRmLm9yZw0K1vfM4jogUmU6IFtwYXdzXSBGMkYgc2Vz c2lvbiBhdCBJRVRGODUgaW4gQXRsYW50YQ0KDQpJZiB5b3Ugd291bGQgbGlrZSBhIHRpbWVzbG90 IHRvIHByZXNlbnQgaW4gdGhlIHVwY29taW5nIEYyRiwgcGxlYXNlIHNlbmQgYSByZXF1ZXN0IHRv IHRoZSBjaGFpcnMuDQpUaGFua3MsIEdhYm9yDQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJhamtvIEdhYm9y IChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDEwLCAy MDEyIDk6NTEgQU0NClRvOiBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBbcGF3c10gRjJGIHNlc3Np b24gYXQgSUVURjg1IGluIEF0bGFudGENCg0KRm9sa3MsDQoNCkZZSSwgSSBqdXN0IHJlcXVlc3Rl ZCBhIDIuNSBob3VyIHNlc3Npb24gZm9yIFBBV1MgYXQgdGhlIEF0bGFudGEgbWVldGluZy4NCg0K DQotICAgICAgICAgIEdhYm9yDQoNCg== --_000_8CC0CB0BCAE52F46882E17828A9AE2163687174ASZXEML508MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Gabor and Brian

 

We would like to ask for a time slot for introducing our draft-wu= -paws-secutity-01.

 

Thanks,

Yang

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Yang Cui,  Ph.D.

Huawei Technologies

cuiyang@huawei.com

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

Yang Cui,  Ph.D.

Huawei Technologies

cuiyang@huawei.com

 

=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=EA10=D4=C224=C8=D5 5:32
=CA=D5=BC=FE=C8=CB: paws@ietf.org
=D6=F7=CC=E2: Re: [paws] F2F session at IETF85 in Atlanta

 

If you = would like a timeslot to present in the upcoming F2F, please send a request= to the chairs.

Thanks,= Gabor

&n= bsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Monday, September 10, 2012 9:51 AM
To: paws@ietf.org
Subject: [paws] F2F session at IETF85 in Atlanta

 

Folks,

 

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

 

-  = ;        Gabor=

 

--_000_8CC0CB0BCAE52F46882E17828A9AE2163687174ASZXEML508MBXchi_-- From paul@marvell.com Wed Oct 24 14:24:23 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 3D14721F85B2 for ; Wed, 24 Oct 2012 14:24:23 -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 7AIfO5GOv2nc for ; Wed, 24 Oct 2012 14:24:22 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 75FDC21F84FB for ; Wed, 24 Oct 2012 14:24:22 -0700 (PDT) Received: from sc-owa02.marvell.com ([199.233.58.137]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUIhchW3RTaGrVVAZQbBIYCZgOSRuukH0@postini.com; Wed, 24 Oct 2012 14:24:22 PDT Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 24 Oct 2012 14:10:24 -0700 From: Paul Lambert To: Cuiyang , "paws@ietf.org" Date: Wed, 24 Oct 2012 14:10:22 -0700 Thread-Topic: [paws] FW: New Version Notification for draft-wu-paws-secutity-01.txt Thread-Index: AQHNsE3e1JkiTjhbJkGv7Cx35ZQ7cZfHsBMQgAFFuwA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015E4ADCB72@SC-VEXCH2.marvell.com> References: <8CC0CB0BCAE52F46882E17828A9AE216368716ED@SZXEML508-MBX.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE216368716ED@SZXEML508-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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] FW: New Version Notification for draft-wu-paws-secutity-01.txt 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, 24 Oct 2012 21:24:23 -0000 DQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlIG9mIHRoaXMgc3VibWlzc2lvbi4NCg0K VGhlIHJlcXVpcmVtZW50cyBmb3Igc2VjdXJpdHkgYXJlIGFscmVhZHkgYWdyZWVkIHVwb24gYW5k IGRvY3VtZW50ZWQgaW46DQoJZHJhZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1y cW10cy0wOA0KDQpUaGlzIG5ldyBkb2N1bWVudCB2YXJpZXMgZnJvbSB0aGUgcHJpb3IgcmVxdWly ZW1lbnRzIGFuZCBkb2VzIG5vdCBleHBsYWluDQp3aHkgdGhleSBhcmUgYmVpbmcgcmVhcnRpY3Vs YXRlZCBpbiBhIGRpZmZlcmVudCBtYW5uZXIgbGVhdmluZyBvdXQNCnNpZ25pZmljYW50IHJlcXVp cmVtZW50cyBmcm9tIHRoZSBhZ3JlZWQgZG9jdW1lbnQuDQoNClRoZSByZWNvbW1lbmRhdGlvbnMg aW4gdGhlIGRvY3VtZW50IGFyZSB2ZXJ5IHVuY2xlYXIuIEl0IHN1Z2dlc3RzDQp0aGUgdXNlIG9m IGNlcnRpZmljYXRlcywgcHJlLXNoYXJlZCBrZXlzIFRMUyBhbmQgSVBzZWMuICBUaGlzIA0KaXMg YSB2aWFibGUgbGF1bmRyeSBsaXN0IG9mIHNvbHV0aW9ucywgYnV0IGlzIHVuY2xlYXIgaW4gDQpp bnRlbmQgb2Ygd2hhdCBpcyB0aGUgcHJvcG9zZWQgUEFXcyBtZWNoYW5pc20uDQoNClBlcmhhcHMg YSBzaG9ydCBzdW1tYXJ5IHN0YXRlbWVudCBvciBidWxsZXRlZCBsaXN0IHRvIGRlc2NyaWJlDQp0 aGUgYWN0dWFsIHByb3Bvc2FsIHdvdWxkIGhlbHAgbXkgY29uZnVzZWQgc3RhdGUuDQoNClRoYW5r cywNCg0KUGF1bA0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQo+IEN1aXlhbmcNCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAyMywgMjAxMiA3 OjAxIFBNDQo+IFRvOiBwYXdzQGlldGYub3JnDQo+IFN1YmplY3Q6IFtwYXdzXSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13dS1wYXdzLQ0KPiBzZWN1dGl0eS0wMS50eHQN Cj4gDQo+IFBBV1MgV0csDQo+IA0KPiBUaGUgZm9sbG93aW5nIGlzIG91ciB1cGRhdGUgdG8gZHJh ZnQtd3UtcGF3cy1zZWN1dGl0eS0wMCwgd2hpY2ggaXMNCj4gZm9jdXNlZCBvbiB0aGUgc2VjdXJp dHkgcmVxdWlyZW1lbnRzIGFuZCBwb3NzaWJsZSBzb2x1dGlvbnMuDQo+IEFuZCB3ZSBwbGFuIHRv IGluY2x1ZGUgbW9yZSBkZXRhaWxzIG9mIGNsaWVudCBhdXRoIHVzaW5nIGNlcnRpZmljYXRlDQo+ IGFuZCBQU0ssIHJlc3BlY3RpdmVseS4NCj4gDQo+IENvbW1lbnRzIGFyZSB3ZWxjb21lLCB0aGFu a3MgaW4gYWR2YW5jZS4NCj4gDQo+IFJlZ2FyZHMsDQo+IFlhbmcNCj4gPT09PT09PT09PT09PT09 PT09DQo+ICBZYW5nIEN1aSwgIFBoLkQuDQo+ICBIdWF3ZWkgVGVjaG5vbG9naWVzDQo+ICBjdWl5 YW5nQGh1YXdlaS5jb20NCj4gDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7 tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTLlubQxMOaciDIy5pelIDIwOjA4DQo+IOaUtuS7 tuS6ujogV3V5aXpodWFuZw0KPiDmioTpgIE6IEN1aXlhbmcNCj4g5Li76aKYOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXd1LXBhd3Mtc2VjdXRpdHktMDEudHh0DQo+IA0KPiAN Cj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LXBhd3Mtc2VjdXRpdHktMDEudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWWl6aHVhbmcgV3UgYW5kIHBvc3Rl ZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFmdC13dS1w YXdzLXNlY3V0aXR5DQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkgUHJvdG9jb2wgdG8gQWNj ZXNzIFdoaXRlIFNwYWNlIERhdGFiYXNlOlNlY3VyaXR5DQo+IENvbnNpZGVyYXRpb25zDQo+IENy ZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTIyDQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KPiBOdW1iZXIgb2YgcGFnZXM6IDEzDQo+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd3UtcGF3cy0NCj4gc2VjdXRpdHktMDEudHh0 DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC13dS1wYXdzLXNlY3V0aXR5DQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0wMQ0KPiBEaWZmOiAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXd1LXBhd3MtDQo+IHNlY3V0aXR5 LTAxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBhbmFseXNlcyBjb21tb24g c2VjdXJpdHkgdGhyZWF0cyBvZiB0aGUgUHJvdG9jb2wgdG8NCj4gICAgQWNjZXNzIFdoaXRlIFNw YWNlIGRhdGFiYXNlIChQQVdTKSwgYW5kIGRlc2NyaWJlcyB0aGVpciBwb3RlbnRpYWwNCj4gICAg aW1wYWN0cyBvbiBtZXNzYWdlIGV4Y2hhbmdlcyBiZXR3ZWVuIG1hc3RlciBkZXZpY2UgYW5kIHdo aXRlIHNwYWNlDQo+ICAgIGRhdGFiYXNlIHdoZW4gaW1wbGVtZW50aW5nIFBBV1MuICBNZWFud2hp bGUsIHRoZSBjb3JyZXNwb25kaW5nDQo+ICAgIGNvdW50ZXJtZWFzdXJlcyBhcmUgYWxzbyBpbnRy b2R1Y2VkIGluIHRoaXMgZG9jdW1lbnQuICBUaGUgUEFXUyBpcw0KPiAgICB1c2VkIGZvciByZXRy aWV2aW5nIHRoZSBhdmFpbGFibGUgd2hpdGUgc3BhY2UgaW5mb3JtYXRpb24gYXQgYSBnaXZlbg0K PiAgICBsb2NhdGlvbiBhbmQgdGltZSBmcm9tIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UuDQo+IA0K PiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4g cGF3c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCg== From nbravin@earthlink.net Wed Oct 24 16:39:39 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 7A3791F0C4C for ; Wed, 24 Oct 2012 16:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 L3BQWhGLcGcR for ; Wed, 24 Oct 2012 16:39:38 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id A72FA1F0419 for ; Wed, 24 Oct 2012 16:39:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nqwZfrEeFDwLqXB3JlwW/Z6zTFELnrOCDBKobTBALB4MS8s7dN+3iGhI0gxgXuj2; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TRAXQ-0005Z8-2o; Wed, 24 Oct 2012 19:39:04 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_193039D4-FC70-4493-B619-67E2485F85AE" From: Nancy Bravin In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2163687174A@SZXEML508-MBX.china.huawei.com> Date: Wed, 24 Oct 2012 16:39:02 -0700 Message-Id: References: <1ECAFF543A2FED4EA2BEB6CACE08E47602012484@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163687174A@SZXEML508-MBX.china.huawei.com> To: Cuiyang X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86e2fcf2866f0c90551b9a71928b7c7910350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: "paws@ietf.org" , "br@brianrosen.net" Subject: Re: [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: Wed, 24 Oct 2012 23:39:39 -0000 --Apple-Mail=_193039D4-FC70-4493-B619-67E2485F85AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Yang,=20 It seems to me that when advocating issues that have been agreed upon = otherwise before, at this late date, will need a formal proposal before any adoption takes place so the members have time to go through your = presentation and again be able to respond via the reflector.=20 Case in point=A1=ADcertificates/TLS=A1=ADmy recollection is that many = discussed this for a long time and it was not excepted in the proposal.=20= What is the thought process for changing this now and can you elaborate = on why each area of change, needed or already decided against is in your presentation asap so there can be a proper proposal timeframe = with members able to give such ideas its due time and questions on the PAWS reflector starting now, it may be of help to all of us, and = in some cases be a help to the total effort. Thanks,=20 Nancy On Oct 23, 2012, at 9:15 PM, Cuiyang wrote: > Hi, Gabor and Brian > =20 > We would like to ask for a time slot for introducing our = draft-wu-paws-secutity-01. > =20 > Thanks, > Yang > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Yang Cui, Ph.D. > Huawei Technologies > cuiyang@huawei.com > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Yang Cui, Ph.D. > Huawei Technologies > cuiyang@huawei.com > =20 > =B7=A2=BC=FE=C8=CB: paws-bounces@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=EA10=D4=C224=C8=D5 5:32 > =CA=D5=BC=FE=C8=CB: paws@ietf.org > =D6=F7=CC=E2: Re: [paws] F2F session at IETF85 in Atlanta > =20 > If you would like a timeslot to present in the upcoming F2F, please = send a request to the chairs. > Thanks, Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Bajko Gabor (Nokia-CIC/SiliconValley) > Sent: Monday, September 10, 2012 9:51 AM > To: paws@ietf.org > Subject: [paws] F2F session at IETF85 in Atlanta > =20 > Folks, > =20 > FYI, I just requested a 2.5 hour session for PAWS at the Atlanta = meeting. > =20 > - Gabor > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_193039D4-FC70-4493-B619-67E2485F85AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Yang, 

It seems to me = that when advocating issues that have been agreed upon otherwise before, = at this late date, will need a formal proposal before
any = adoption takes place so the members have time to go through your = presentation and again be able to respond via the = reflector. 
Case in point=A1=ADcertificates/TLS=A1=ADmy = recollection is that many discussed this for a long time and it was not = excepted in the proposal. 
What is the thought process = for changing this now and can you elaborate on why each area of change, = needed or already decided against
is in your presentation asap = so there can be a proper proposal timeframe with members able to give = such ideas its due time and questions
on the PAWS reflector = starting now, it may be of help to all of us, and in some cases be a = help to the total = effort.

Thanks, 

Hi, Gabor and = Brian
We would like to = ask for a time slot for introducing our = draft-wu-paws-secutity-01.
 
Thanks,
Yang
Yang Cui,  Ph.D.
Huawei Technologies
=B7=A2=BC=FE=C8=CB: paws-bounces@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=EA10=D4=C224=C8=D5 5:32
=CA=D5=BC=FE= =C8=CB: paws@ietf.org
=D6=F7=CC=E2<= span lang=3D"EN-US">: Re: [paws] F2F session at = IETF85 in Atlanta
 
From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor = (Nokia-CIC/SiliconValley)
Sent: Monday, September 10, 2012 = 9:51 AM
To: paws@ietf.org
Subject: [paws] F2F session at = IETF85 in Atlanta
 
Folks,
 
FYI, I just requested a 2.5 hour = session for PAWS at the Atlanta meeting.
 
- Gabor
 
_________________= ______________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= --Apple-Mail=_193039D4-FC70-4493-B619-67E2485F85AE-- From cuiyang@huawei.com Wed Oct 24 19:53: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 4BB7321F8F47 for ; Wed, 24 Oct 2012 19:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=-1.051, 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 ZL9F8QhDh7FC for ; Wed, 24 Oct 2012 19:53:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B4B0D21F8F46 for ; Wed, 24 Oct 2012 19:53: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 AMA74178; Thu, 25 Oct 2012 02:53: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; Thu, 25 Oct 2012 03:52:58 +0100 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 25 Oct 2012 03:53:08 +0100 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.236]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Thu, 25 Oct 2012 10:53:06 +0800 From: Cuiyang To: Nancy Bravin Thread-Topic: [paws] F2F session at IETF85 in Atlanta Thread-Index: Ac2PdDKxV3nQ9+C+QhORZsf33FFydQh8YuFAAA4VxHAAF+b2AAAT6Hcw Date: Thu, 25 Oct 2012 02:53:05 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21636871A7E@SZXEML508-MBX.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47602012484@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163687174A@SZXEML508-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.135] Content-Type: multipart/alternative; boundary="_000_8CC0CB0BCAE52F46882E17828A9AE21636871A7ESZXEML508MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , "br@brianrosen.net" Subject: Re: [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: Thu, 25 Oct 2012 02:53:57 -0000 --_000_8CC0CB0BCAE52F46882E17828A9AE21636871A7ESZXEML508MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTmFuY3ksDQoNClRoYW5rcyBmb3IgeW91ciBraW5kIHJlbWluZGluZzstKQ0KSSBoYXZlIG5v dGljZWQgdGhhdCBhIGxlbmd0aHkgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCBhbmQgYXQgVmFuY291 dmVyIG9uIHRoZSBzZWN1cml0eSBpc3N1ZXMuDQpXZSBhcmUgbm90IGFpbWVkIHRvIHJld3JpdGUg dGhlIGNvbW1vbiBhZ3JlZW1lbnQgdGhhdCBXRyBoYXMgZ290Lg0KDQpUaGUgcHJldmlvdXMgdmVy c2lvbiBvZiBvdXIgZHJhZnQgaXMgZm9jdXNlZCBvbiB0aGUgYXV0aGVudGljYXRpb24gYW5kIGF1 dGhvcml6YXRpb24gbW9kZWwsIGZvciBleGFtcGxlLCB0aGUgaW50ZXJhY3Rpb24gb2YgbWFzdGVy IGRldmljZSwgZGF0YWJhc2UgYW5kIEZDQy4NCkJ1dCB0aGUgbGF0ZXN0IHZlcnNpb24gc2ltcGxp ZmllcyB0aGUgbW9kZWxzLCB3aGljaCBwcm92aWRlcyBhIHNvbHV0aW9uIHRoYXQgobBIb3cgZGF0 YWJhc2UgY2FuIHZhbGlkYXRlIGEgRkNDIGFwcHJvdmVkIG1hc3RlciBkZXZpY2WhsSwgZXRjLg0K SXQgY291bGQgbmF0dXJhbGx5IHNvbHZlIHRoZSBJRC9kZXZpY2UgcmV2b2NhdGlvbiBwcm9ibGVt Lg0KQWxzbywgc2luY2UgUFNLIGF1dGggaXMgbGVmdCBvdXQgd2l0aCBhIGNvbmNlcm4gdGhhdCBJ RVNHIG1heSByZWZ1c2UgaXQgd2l0aG91dCB0aGUga2V5IHByb3Zpc2lvbiBtZWNoYW5pc20sIHdl IGNvdWxkIHRyeSB0byBwcm92aWRlIFBTSyBhdXRoZW50aWNhdGlvbiB3aXRoIHByb3BlciBrZXkg cHJvdmlzaW9uIG1lY2hhbmlzbS4NCg0KQWxsIGluIGFsbCwgdGhpcyBzdWJtaXNzaW9uIGlzIHRv IGRpc2N1c3MgdGhlIHBvc3NpYmxlIHRocmVhdHMgYW5kIHNvbHV0aW9ucyBub3QgaW5jbHVkZWQg aW4gdGhlIGN1cnJlbnQgV0cgZG9jLg0KDQpUaGFua3MsDQpZYW5nDQo9PT09PT09PT09PT09PT09 PT0NCllhbmcgQ3VpLCAgUGguRC4NCkh1YXdlaSBUZWNobm9sb2dpZXMNCmN1aXlhbmdAaHVhd2Vp LmNvbQ0KDQq3orz+yMs6IE5hbmN5IEJyYXZpbiBbbWFpbHRvOm5icmF2aW5AZWFydGhsaW5rLm5l dF0NCreiy83KsbzkOiAyMDEyxOoxMNTCMjXI1SA3OjM5DQrK1bz+yMs6IEN1aXlhbmcNCrOty806 IEdhYm9yLkJhamtvQG5va2lhLmNvbTsgcGF3c0BpZXRmLm9yZzsgYnJAYnJpYW5yb3Nlbi5uZXQN Ctb3zOI6IFJlOiBbcGF3c10gRjJGIHNlc3Npb24gYXQgSUVURjg1IGluIEF0bGFudGENCg0KSGkg WWFuZywNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB3aGVuIGFkdm9jYXRpbmcgaXNzdWVzIHRoYXQg aGF2ZSBiZWVuIGFncmVlZCB1cG9uIG90aGVyd2lzZSBiZWZvcmUsIGF0IHRoaXMgbGF0ZSBkYXRl LCB3aWxsIG5lZWQgYSBmb3JtYWwgcHJvcG9zYWwgYmVmb3JlDQphbnkgYWRvcHRpb24gdGFrZXMg cGxhY2Ugc28gdGhlIG1lbWJlcnMgaGF2ZSB0aW1lIHRvIGdvIHRocm91Z2ggeW91ciBwcmVzZW50 YXRpb24gYW5kIGFnYWluIGJlIGFibGUgdG8gcmVzcG9uZCB2aWEgdGhlIHJlZmxlY3Rvci4NCkNh c2UgaW4gcG9pbnShrWNlcnRpZmljYXRlcy9UTFOhrW15IHJlY29sbGVjdGlvbiBpcyB0aGF0IG1h bnkgZGlzY3Vzc2VkIHRoaXMgZm9yIGEgbG9uZyB0aW1lIGFuZCBpdCB3YXMgbm90IGV4Y2VwdGVk IGluIHRoZSBwcm9wb3NhbC4NCldoYXQgaXMgdGhlIHRob3VnaHQgcHJvY2VzcyBmb3IgY2hhbmdp bmcgdGhpcyBub3cgYW5kIGNhbiB5b3UgZWxhYm9yYXRlIG9uIHdoeSBlYWNoIGFyZWEgb2YgY2hh bmdlLCBuZWVkZWQgb3IgYWxyZWFkeSBkZWNpZGVkIGFnYWluc3QNCmlzIGluIHlvdXIgcHJlc2Vu dGF0aW9uIGFzYXAgc28gdGhlcmUgY2FuIGJlIGEgcHJvcGVyIHByb3Bvc2FsIHRpbWVmcmFtZSB3 aXRoIG1lbWJlcnMgYWJsZSB0byBnaXZlIHN1Y2ggaWRlYXMgaXRzIGR1ZSB0aW1lIGFuZCBxdWVz dGlvbnMNCm9uIHRoZSBQQVdTIHJlZmxlY3RvciBzdGFydGluZyBub3csIGl0IG1heSBiZSBvZiBo ZWxwIHRvIGFsbCBvZiB1cywgYW5kIGluIHNvbWUgY2FzZXMgYmUgYSBoZWxwIHRvIHRoZSB0b3Rh bCBlZmZvcnQuDQoNClRoYW5rcywNCg0KTmFuY3kNCk9uIE9jdCAyMywgMjAxMiwgYXQgOToxNSBQ TSwgQ3VpeWFuZyB3cm90ZToNCg0KDQpIaSwgR2Fib3IgYW5kIEJyaWFuDQoNCldlIHdvdWxkIGxp a2UgdG8gYXNrIGZvciBhIHRpbWUgc2xvdCBmb3IgaW50cm9kdWNpbmcgb3VyIGRyYWZ0LXd1LXBh d3Mtc2VjdXRpdHktMDEuDQoNClRoYW5rcywNCllhbmcNCj09PT09PT09PT09PT09PT09PQ0KWWFu ZyBDdWksICBQaC5ELg0KSHVhd2VpIFRlY2hub2xvZ2llcw0KY3VpeWFuZ0BodWF3ZWkuY29tPG1h aWx0bzpjdWl5YW5nQGh1YXdlaS5jb20+DQoNCg0KPT09PT09PT09PT09PT09PT09DQpZYW5nIEN1 aSwgIFBoLkQuDQpIdWF3ZWkgVGVjaG5vbG9naWVzDQpjdWl5YW5nQGh1YXdlaS5jb208bWFpbHRv OmN1aXlhbmdAaHVhd2VpLmNvbT4NCg0Kt6K8/sjLOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gR2Fib3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+ DQq3osvNyrG85DogMjAxMsTqMTDUwjI0yNUgNTozMg0KytW8/sjLOiBwYXdzQGlldGYub3JnPG1h aWx0bzpwYXdzQGlldGYub3JnPg0K1vfM4jogUmU6IFtwYXdzXSBGMkYgc2Vzc2lvbiBhdCBJRVRG ODUgaW4gQXRsYW50YQ0KDQpJZiB5b3Ugd291bGQgbGlrZSBhIHRpbWVzbG90IHRvIHByZXNlbnQg aW4gdGhlIHVwY29taW5nIEYyRiwgcGxlYXNlIHNlbmQgYSByZXF1ZXN0IHRvIHRoZSBjaGFpcnMu DQpUaGFua3MsIEdhYm9yDQoNCkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF3 cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEJhamtvIEdhYm9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNClNlbnQ6IE1vbmRh eSwgU2VwdGVtYmVyIDEwLCAyMDEyIDk6NTEgQU0NClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpw YXdzQGlldGYub3JnPg0KU3ViamVjdDogW3Bhd3NdIEYyRiBzZXNzaW9uIGF0IElFVEY4NSBpbiBB dGxhbnRhDQoNCkZvbGtzLA0KDQpGWUksIEkganVzdCByZXF1ZXN0ZWQgYSAyLjUgaG91ciBzZXNz aW9uIGZvciBQQVdTIGF0IHRoZSBBdGxhbnRhIG1lZXRpbmcuDQoNCi0gICAgICAgICAgR2Fib3IN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3Mg bWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg== --_000_8CC0CB0BCAE52F46882E17828A9AE21636871A7ESZXEML508MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Nancy,<= o:p>

 = ;

Thanks for= your kind reminding;-)

I have not= iced that a lengthy discussion on the list and at Vancouver on the security= issues.

We are not= aimed to rewrite the common agreement that WG has got.

 = ;

The previo= us version of our draft is focused on the authentication and authorization = model, for example, the interaction of master device, database and FCC.

But the la= test version simplifies the models, which provides a solution that =A1=B0Ho= w database can validate a FCC approved master device=A1=B1, etc.=

It could n= aturally solve the ID/device revocation problem.

Also, sinc= e PSK auth is left out with a concern that IESG may refuse it without the k= ey provision mechanism, we could try to provide PSK authentication with proper key provision mechanism.

 = ;

All in all= , this submission is to discuss the possible threats and solutions not incl= uded in the current WG doc.

 = ;

Thanks,

Yang<= /o:p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Yang Cui,  Ph.D.<= /o:p>

Huawei Technologies

cuiyang@huawei.com

 = ;

=B7=A2=BC=FE=C8= =CB: Nancy Bravin [mailto:nbravin@earthlink.net]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C225=C8=D5 = 7:39
=CA=D5=BC=FE=C8=CB: Cuiyang
=B3=AD=CB=CD: Gabor.Bajko@nokia.com; paws@ietf.org; br@brianrosen.net
=D6=F7=CC=E2: Re: [paws] F2F session at IETF85 in Atlanta

 

Hi Yang, 

 

It seems to me that when advoca= ting issues that have been agreed upon otherwise before, at this late date,= will need a formal proposal before

any adoption takes place so the= members have time to go through your presentation and again be able to res= pond via the reflector. 

Case in point=A1=ADcertificates= /TLS=A1=ADmy recollection is that many discussed this for a long time and i= t was not excepted in the proposal. 

What is the thought process for= changing this now and can you elaborate on why each area of change, needed= or already decided against

is in your presentation asap so= there can be a proper proposal timeframe with members able to give such id= eas its due time and questions

on the PAWS reflector starting = now, it may be of help to all of us, and in some cases be a help to the tot= al effort.

 

Thanks, =

 

Nancy<= /span>

On Oct 23, 2012, at 9:15 PM, Cu= iyang wrote:



Hi, Gabor = and Brian

 

We would l= ike to ask for a time slot for introducing our draft-wu-paws-secutity-01.

 

Thanks,

Yang

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Yang Cui,  Ph.D.

Huawei Technologies<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif"">

cuiyang@huawei.com

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Yang Cui,  Ph.D.

Huawei Technologies<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif"">

cuiyang@huawei.com

 

=B7=A2=BC=FE=C8= =CB: <= span lang=3D"EN-US" style=3D"font-size:10.0pt">paws-bounces@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=EA10=D4=C224=C8=D5 = 5:32
=CA=D5=BC=FE=C8=CB: paws@ietf.org
=D6=F7=CC=E2: Re: [paws] F2F session at IETF85 in Atlanta

 =

If you wou= ld like a timeslot to present in the upcoming F2F, please send a request to= the chairs.

Thanks, Ga= bor

 

From: paw= s-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Monday, Sept= ember 10, 2012 9:51 AM
To: paws@ietf.org
Subject: [paws] F2= F session at IETF85 in Atlanta

 =

Folks,=

 =

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

 =

-     &= nbsp;    <= /span>Gabor

 =

______________________= _________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

--_000_8CC0CB0BCAE52F46882E17828A9AE21636871A7ESZXEML508MBXchi_-- From cuiyang@huawei.com Wed Oct 24 20:26:17 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 9AB7621E8022 for ; Wed, 24 Oct 2012 20:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.338 X-Spam-Level: X-Spam-Status: No, score=-5.338 tagged_above=-999 required=5 tests=[AWL=1.261, 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 UWc9oZ4zgvRY for ; Wed, 24 Oct 2012 20:26:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B69F11E80A2 for ; Wed, 24 Oct 2012 20:26:16 -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 AKX59581; Thu, 25 Oct 2012 03:26:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 25 Oct 2012 04:24:58 +0100 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 25 Oct 2012 04:25:08 +0100 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.236]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Thu, 25 Oct 2012 11:25:05 +0800 From: Cuiyang To: Paul Lambert , "paws@ietf.org" Thread-Topic: [paws] FW: New Version Notification for draft-wu-paws-secutity-01.txt Thread-Index: AQHNsi3yaCzHoaxNiUe9S4/l4Mz8SJfJU4RA Date: Thu, 25 Oct 2012 03:25:05 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21636871AA9@SZXEML508-MBX.china.huawei.com> References: <8CC0CB0BCAE52F46882E17828A9AE216368716ED@SZXEML508-MBX.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D015E4ADCB72@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E4ADCB72@SC-VEXCH2.marvell.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.48.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] FW: New Version Notification for draft-wu-paws-secutity-01.txt 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, 25 Oct 2012 03:26:17 -0000 SGksIFBhdWwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCj09PT09PT09PT09PT09PT09PQ0KIFlh bmcgQ3VpLCAgUGguRC4NCiBIdWF3ZWkgVGVjaG5vbG9naWVzDQogY3VpeWFuZ0BodWF3ZWkuY29t DQoNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogUGF1bCBMYW1iZXJ0 IFttYWlsdG86cGF1bEBtYXJ2ZWxsLmNvbV0NCj4g5Y+R6YCB5pe26Ze0OiAyMDEy5bm0MTDmnIgy NeaXpSA1OjEwDQo+IOaUtuS7tuS6ujogQ3VpeWFuZzsgcGF3c0BpZXRmLm9yZw0KPiDkuLvpopg6 IFJFOiBbcGF3c10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtd3Ut cGF3cy1zZWN1dGl0eS0wMS50eHQNCj4gDQo+IA0KPiBJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBw dXJwb3NlIG9mIHRoaXMgc3VibWlzc2lvbi4NCj4gDQo+IFRoZSByZXF1aXJlbWVudHMgZm9yIHNl Y3VyaXR5IGFyZSBhbHJlYWR5IGFncmVlZCB1cG9uIGFuZCBkb2N1bWVudGVkIGluOg0KPiAJZHJh ZnQtaWV0Zi1wYXdzLXByb2JsZW0tc3RtdC11c2VjYXNlcy1ycW10cy0wOA0KPiANCj4gVGhpcyBu ZXcgZG9jdW1lbnQgdmFyaWVzIGZyb20gdGhlIHByaW9yIHJlcXVpcmVtZW50cyBhbmQgZG9lcyBu b3QgZXhwbGFpbg0KPiB3aHkgdGhleSBhcmUgYmVpbmcgcmVhcnRpY3VsYXRlZCBpbiBhIGRpZmZl cmVudCBtYW5uZXIgbGVhdmluZyBvdXQNCj4gc2lnbmlmaWNhbnQgcmVxdWlyZW1lbnRzIGZyb20g dGhlIGFncmVlZCBkb2N1bWVudC4NCj4gDQpbQ3VpIFlhbmddIFNlY3VyaXR5IHJlcXVpcmVtZW50 cyBhcmUgZm9sbG93aW5nIHRoZSBnZW5lcmFsIHJlcXVpcmVtZW50cyBpbiB0aGUgV0cgZG9jLCBk cmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLTA4LCBmcm9tIGEgaW1w bGVtZW50YXRpb24gcG9pbnQgb2Ygdmlldy4NCkFuZCBlbXBoYXNpemUgb24gc29tZSB0eXBpY2Fs IHNjZW5hcmlvLCBzdWNoIGFzIE1pdE0gYXR0YWNrLCBkaXNjdXNzZWQgYSBsb3Qgb24gdGhlIGxp c3QuDQpJZiB3ZSBtaXNzZWQgc29tZSBpbXBvcnRhbnQgcG9pbnRzLCBwbGVhc2UgbGV0IHVzIGtu b3cuDQoNCj4gVGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0aGUgZG9jdW1lbnQgYXJlIHZlcnkgdW5j bGVhci4gSXQgc3VnZ2VzdHMNCj4gdGhlIHVzZSBvZiBjZXJ0aWZpY2F0ZXMsIHByZS1zaGFyZWQg a2V5cyBUTFMgYW5kIElQc2VjLiAgVGhpcw0KPiBpcyBhIHZpYWJsZSBsYXVuZHJ5IGxpc3Qgb2Yg c29sdXRpb25zLCBidXQgaXMgdW5jbGVhciBpbg0KPiBpbnRlbmQgb2Ygd2hhdCBpcyB0aGUgcHJv cG9zZWQgUEFXcyBtZWNoYW5pc20uDQo+IA0KW0N1aSBZYW5nXSBTb3JyeSBmb3IgdGhhdCENCk91 ciBkcmFmdCBpcyBhaW1lZCB0byBkaXNjdXNzIHRoZSBzZWN1cml0eSBpc3N1ZXMgaW4gaW1wbGVt ZW50YXRpb24sIGFuZCBwcm92aWRlIGFuIGluZm9ybWF0aW9uYWwgbm90ZSBmb3IgdmFyaWV0aWVz IG9mIHNlY3VyaXR5IHNvbHV0aW9ucy4NCklNTywgVExTIChib3RoIGNlcnQgYW5kIFBTSykgY2Fu IHdvcmsgd2VsbCwgYnV0IHRoZSBwcm9ibGVtcyBhcmUga2V5IHByb3Zpc2lvbmluZyBhbmQgY2Vy dCByZXZvY2F0aW9uLCBhdXRob3JpemF0aW9uIG1vZGVsLg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0 aGUgYWJvdmUgbmVlZHMgdG8gYmUgaW52ZXN0aWdhdGVkIGFuZCBwcm92aWRlZCwgZm9yIGRpZmZl cmVudCB1c2UgY2FzZXMgb2YgUEFXUy4NCg0KPiBQZXJoYXBzIGEgc2hvcnQgc3VtbWFyeSBzdGF0 ZW1lbnQgb3IgYnVsbGV0ZWQgbGlzdCB0byBkZXNjcmliZQ0KPiB0aGUgYWN0dWFsIHByb3Bvc2Fs IHdvdWxkIGhlbHAgbXkgY29uZnVzZWQgc3RhdGUuDQo+IA0KW0N1aSBZYW5nXSBXZSB3aWxsIHBy b3ZpZGUgaW4gdGhlIHVwZGF0ZS4NClRoYW5rcyBmb3IgeW91ciBjb21tZW50IQ0KDQo+IFRoYW5r cywNCj4gDQo+IFBhdWwNCj4gDQo+IA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+IEN1aXlhbmcNCj4gPiBTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDIzLCAyMDEyIDc6MDEgUE0NCj4gPiBUbzogcGF3c0BpZXRmLm9yZw0KPiA+ IFN1YmplY3Q6IFtwYXdzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13 dS1wYXdzLQ0KPiA+IHNlY3V0aXR5LTAxLnR4dA0KPiA+DQo+ID4gUEFXUyBXRywNCj4gPg0KPiA+ IFRoZSBmb2xsb3dpbmcgaXMgb3VyIHVwZGF0ZSB0byBkcmFmdC13dS1wYXdzLXNlY3V0aXR5LTAw LCB3aGljaCBpcw0KPiA+IGZvY3VzZWQgb24gdGhlIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBhbmQg cG9zc2libGUgc29sdXRpb25zLg0KPiA+IEFuZCB3ZSBwbGFuIHRvIGluY2x1ZGUgbW9yZSBkZXRh aWxzIG9mIGNsaWVudCBhdXRoIHVzaW5nIGNlcnRpZmljYXRlDQo+ID4gYW5kIFBTSywgcmVzcGVj dGl2ZWx5Lg0KPiA+DQo+ID4gQ29tbWVudHMgYXJlIHdlbGNvbWUsIHRoYW5rcyBpbiBhZHZhbmNl Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBZYW5nDQo+ID4gPT09PT09PT09PT09PT09PT09DQo+ ID4gIFlhbmcgQ3VpLCAgUGguRC4NCj4gPiAgSHVhd2VpIFRlY2hub2xvZ2llcw0KPiA+ICBjdWl5 YW5nQGh1YXdlaS5jb20NCj4gPg0KPiA+DQo+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+ IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXQ0KPiA+IOWPkemAgeaXtumXtDogMjAxMuW5tDEw5pyIMjLml6UgMjA6MDgN Cj4gPiDmlLbku7bkuro6IFd1eWl6aHVhbmcNCj4gPiDmioTpgIE6IEN1aXlhbmcNCj4gPiDkuLvp opg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd3UtcGF3cy1zZWN1dGl0eS0w MS50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXd1LXBhd3Mt c2VjdXRpdHktMDEudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBZ aXpodWFuZyBXdSBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0K PiA+IEZpbGVuYW1lOgkgZHJhZnQtd3UtcGF3cy1zZWN1dGl0eQ0KPiA+IFJldmlzaW9uOgkgMDEN Cj4gPiBUaXRsZToJCSBQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UgRGF0YWJhc2U6U2Vj dXJpdHkNCj4gPiBDb25zaWRlcmF0aW9ucw0KPiA+IENyZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTIy DQo+ID4gV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ID4gTnVtYmVyIG9mIHBhZ2Vz OiAxMw0KPiA+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtd3UtcGF3cy0NCj4gPiBzZWN1dGl0eS0wMS50eHQNCj4gPiBTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtcGF3cy1zZWN1 dGl0eQ0KPiA+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtd3UtcGF3cy1zZWN1dGl0eS0wMQ0KPiA+IERpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtd3UtcGF3cy0NCj4gPiBzZWN1dGl0eS0wMQ0KPiA+ DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgVGhpcyBkb2N1bWVudCBhbmFseXNlcyBjb21tb24gc2Vj dXJpdHkgdGhyZWF0cyBvZiB0aGUgUHJvdG9jb2wgdG8NCj4gPiAgICBBY2Nlc3MgV2hpdGUgU3Bh Y2UgZGF0YWJhc2UgKFBBV1MpLCBhbmQgZGVzY3JpYmVzIHRoZWlyIHBvdGVudGlhbA0KPiA+ICAg IGltcGFjdHMgb24gbWVzc2FnZSBleGNoYW5nZXMgYmV0d2VlbiBtYXN0ZXIgZGV2aWNlIGFuZCB3 aGl0ZSBzcGFjZQ0KPiA+ICAgIGRhdGFiYXNlIHdoZW4gaW1wbGVtZW50aW5nIFBBV1MuICBNZWFu d2hpbGUsIHRoZSBjb3JyZXNwb25kaW5nDQo+ID4gICAgY291bnRlcm1lYXN1cmVzIGFyZSBhbHNv IGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSBQQVdTIGlzDQo+ID4gICAgdXNlZCBm b3IgcmV0cmlldmluZyB0aGUgYXZhaWxhYmxlIHdoaXRlIHNwYWNlIGluZm9ybWF0aW9uIGF0IGEg Z2l2ZW4NCj4gPiAgICBsb2NhdGlvbiBhbmQgdGltZSBmcm9tIGEgd2hpdGUgc3BhY2UgZGF0YWJh c2UuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBw YXdzIG1haWxpbmcgbGlzdA0KPiA+IHBhd3NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== From nbravin@earthlink.net Wed Oct 24 23:12: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 CBBEA21E8039 for ; Wed, 24 Oct 2012 23:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.192 X-Spam-Level: X-Spam-Status: No, score=0.192 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] 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 YxSdfaRXgxWh for ; Wed, 24 Oct 2012 23:12:51 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B29C121E8037 for ; Wed, 24 Oct 2012 23:12:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nnEUXc5F/IjG+x3z+ViQIeRI9s5iUpK/CkcUraABytA3e+f0mzuAJWi6OaBUxTKV; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TRGgI-0003Pc-4h; Thu, 25 Oct 2012 02:12:38 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0F08FBA3-922C-49D4-A120-4F465FAFD49B" From: Nancy Bravin In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE21636871A7E@SZXEML508-MBX.china.huawei.com> Date: Wed, 24 Oct 2012 23:12:35 -0700 Message-Id: <9BF4DFE6-A610-44A8-88D1-3C9DAEE27F20@earthlink.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E47602012484@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163687174A@SZXEML508-MBX.china.huawei.com> <8CC0CB0BCAE52F46882E17828A9AE21636871A7E@SZXEML508-MBX.china.huawei.com> To: Cuiyang X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86c0e34eb6fc245b16140306174231ebf1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: "paws@ietf.org" , "br@brianrosen.net" Subject: Re: [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: Thu, 25 Oct 2012 06:12:52 -0000 --Apple-Mail=_0F08FBA3-922C-49D4-A120-4F465FAFD49B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Yang,=20 Thanks for the explanation, and I do understand the issues with the = approval of the IESG, and of course satisfying regulatory domains.=20 I hope that the members take this time to ask questions so the F2F/on = line participation will be easier as some of the details can start to be discussed now if members choose to ask, or offer alternatives, or = enhancements to your presentation.=20 Anything worth while can always be added at a later time when all of = those things that need to be satisfied with the IESG and on going regulatory changes in the world of PAWS with consensus of the = members.=20 Thanks again, Nancy On Oct 24, 2012, at 7:53 PM, Cuiyang wrote: > Hi Nancy, > =20 > Thanks for your kind reminding;-) > I have noticed that a lengthy discussion on the list and at Vancouver = on the security issues. > We are not aimed to rewrite the common agreement that WG has got. > =20 > The previous version of our draft is focused on the authentication and = authorization model, for example, the interaction of master device, = database and FCC. > But the latest version simplifies the models, which provides a = solution that =A1=B0How database can validate a FCC approved master = device=A1=B1, etc. > It could naturally solve the ID/device revocation problem. > Also, since PSK auth is left out with a concern that IESG may refuse = it without the key provision mechanism, we could try to provide PSK = authentication with proper key provision mechanism. > =20 > All in all, this submission is to discuss the possible threats and = solutions not included in the current WG doc. > =20 > Thanks, > Yang > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Yang Cui, Ph.D. > Huawei Technologies > cuiyang@huawei.com > =20 > =B7=A2=BC=FE=C8=CB: Nancy Bravin [mailto:nbravin@earthlink.net]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C225=C8=D5 7:39 > =CA=D5=BC=FE=C8=CB: Cuiyang > =B3=AD=CB=CD: Gabor.Bajko@nokia.com; paws@ietf.org; br@brianrosen.net > =D6=F7=CC=E2: Re: [paws] F2F session at IETF85 in Atlanta > =20 > Hi Yang,=20 > =20 > It seems to me that when advocating issues that have been agreed upon = otherwise before, at this late date, will need a formal proposal before > any adoption takes place so the members have time to go through your = presentation and again be able to respond via the reflector.=20 > Case in point=A1=ADcertificates/TLS=A1=ADmy recollection is that many = discussed this for a long time and it was not excepted in the proposal.=20= > What is the thought process for changing this now and can you = elaborate on why each area of change, needed or already decided against > is in your presentation asap so there can be a proper proposal = timeframe with members able to give such ideas its due time and = questions > on the PAWS reflector starting now, it may be of help to all of us, = and in some cases be a help to the total effort. > =20 > Thanks,=20 > =20 > Nancy > On Oct 23, 2012, at 9:15 PM, Cuiyang wrote: >=20 >=20 > Hi, Gabor and Brian > =20 > We would like to ask for a time slot for introducing our = draft-wu-paws-secutity-01. > =20 > Thanks, > Yang > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Yang Cui, Ph.D. > Huawei Technologies > cuiyang@huawei.com > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Yang Cui, Ph.D. > Huawei Technologies > cuiyang@huawei.com > =20 > =B7=A2=BC=FE=C8=CB: paws-bounces@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=EA10=D4=C224=C8=D5 5:32 > =CA=D5=BC=FE=C8=CB: paws@ietf.org > =D6=F7=CC=E2: Re: [paws] F2F session at IETF85 in Atlanta > =20 > If you would like a timeslot to present in the upcoming F2F, please = send a request to the chairs. > Thanks, Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Bajko Gabor (Nokia-CIC/SiliconValley) > Sent: Monday, September 10, 2012 9:51 AM > To: paws@ietf.org > Subject: [paws] F2F session at IETF85 in Atlanta > =20 > Folks, > =20 > FYI, I just requested a 2.5 hour session for PAWS at the Atlanta = meeting. > =20 > - Gabor > =20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_0F08FBA3-922C-49D4-A120-4F465FAFD49B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Yang, 

Thanks for the = explanation, and I do understand the issues with the approval of the = IESG, and of course satisfying regulatory domains. 
I = hope that the members take this time to ask questions so the F2F/on line = participation will be easier as some of the details can = start
to be discussed now if members choose to ask, or offer = alternatives, or enhancements to your = presentation. 
Anything worth while can always be added = at a later time when all of those things that need to be satisfied with = the IESG and
on going regulatory changes in the world of PAWS = with consensus of the members. 

Thanks = again, Nancy
Hi = Nancy,
 
Thanks for your kind = reminding;-)
I have noticed that a lengthy discussion on the list = and at Vancouver on the security issues.
We are not aimed to rewrite the = common agreement that WG has got.
The previous version of our draft is focused on the = authentication and authorization model, for example, the interaction of = master device, database and FCC.
But the latest version simplifies = the models, which provides a solution that =A1=B0How database can = validate a FCC approved master device=A1=B1, = etc.
It = could naturally solve the ID/device revocation = problem.
Also, since PSK auth is left out with a concern that = IESG may refuse it without the key provision mechanism, we could try to = provide PSK authentication with proper key provision = mechanism.
 
All in all, this submission is to = discuss the possible threats and solutions not included in the current = WG doc.
 
Yang
Yang = Cui,  Ph.D.
Huawei = Technologies
 
Hi Yang, 
 
It seems to me that when advocating issues that = have been agreed upon otherwise before, at this late date, will need a = formal proposal before
any adoption takes place so the members have time = to go through your presentation and again be able to respond via the = reflector. 
Case in point=A1=ADcertificates/TLS=A1=ADmy = recollection is that many discussed this for a long time and it was not = excepted in the proposal. 
What is the thought process for changing this now = and can you elaborate on why each area of change, needed or already = decided against
is in your presentation asap so there can be a = proper proposal timeframe with members able to give such ideas its due = time and questions
on the PAWS reflector starting now, it may be of = help to all of us, and in some cases be a help to the total = effort.
 
Thanks, 
 
Nancy
On Oct 23, 2012, at 9:15 PM, Cuiyang = wrote:


Hi, Gabor and Brian
 We would like to ask for a time slot for = introducing our draft-wu-paws-secutity-01. Thanks,Yang=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Yang = Cui,  Ph.D.
Huawei = Technologies
  =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Yang = Cui,  Ph.D.
Huawei = Technologies
 
: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] =B4=FA=B1=ED : 2012=C4=EA10=D4=C224=C8=D5 5:32
=CA=D5=BC=FE=C8=CB: paws@ietf.org
=D6=F7=CC=E2: Re: [paws] F2F = session at IETF85 in AtlantaIf you would like a timeslot to present in the = upcoming F2F, please send a request to the chairs.
Thanks, Gabor 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Bajko Gabor = (Nokia-CIC/SiliconValley)
Sent: Monday, September 10, 2012 = 9:51 AM
To: paws@ietf.org
Subject: [paws] F2F session at = IETF85 in AtlantaFYI, I = just requested a 2.5 hour session for PAWS at the Atlanta = meeting.


= --Apple-Mail=_0F08FBA3-922C-49D4-A120-4F465FAFD49B-- From Gabor.Bajko@nokia.com Thu Oct 25 09:43: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 29A4A21F899B for ; Thu, 25 Oct 2012 09:43:15 -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, 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 pMFEtLug-bsW for ; Thu, 25 Oct 2012 09:43:14 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7F21F89A0 for ; Thu, 25 Oct 2012 09:43:12 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9PGh4I8027859; Thu, 25 Oct 2012 19:43:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Oct 2012 19:43:04 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.183]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0309.003; Thu, 25 Oct 2012 18:43:03 +0200 From: To: , , Thread-Topic: New draft for PAWS protocol Thread-Index: AQHNod9L4ggZtTERm0OKj9fadgGKBpeojpnQgB72+MCAAE26MIAChpiw Date: Thu, 25 Oct 2012 16:43:02 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760206F6EA@008-AM1MPN1-007.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E4760204EA8A@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB3B@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163687172C@SZXEML508-MBX.china.huawei.com> In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2163687172C@SZXEML508-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: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206F6EA008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Oct 2012 16:43:04.0290 (UTC) FILETIME=[CDB6DC20:01CDB2CF] X-Nokia-AV: Clean Subject: Re: [paws] New draft for PAWS protocol 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, 25 Oct 2012 16:43:15 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206F6EA008AM1MPN1007mg_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhZ3JlZSwgdGhhdCBzZWN0aW9uIHJlcXVpcmVzIHNvbWUgcmV3b3JkaW5nLiBJIHRoaW5rIHRo ZSBpbnRlbnRpb24gd2FzIHRvIHNheSB0aGF0IG5vdCBhbGwgcmVndWxhdG9yeSBkb21haW5zIHJl cXVpcmUgbWFzdGVyIGRldmljZSBhdXRoZW50aWNhdGlvbjsgYnV0IHdoZXJlIGl0IGlzIHJlcXVp cmVkLCBpdCBpcyBhIG11c3QgdG8gYmUgcGVyZm9ybWVkLg0KSSBiZWxpZXZlIHRoZSBNVVNUIHJl cXVpcmVtZW50IGluIHRoZSByZXFzIGRvYyBpcyB0aGUgcHJvcGVyIGxhbmd1YWdlLCBhcyB0aGUg cHJvdG9jb2wgaGFzIHRvIGhhdmUgdGhhdCBjYXBhYmlsaXR5IChldmVuIGlmIHVzZWQgb25seSBi eSBzb21lLCBhbmQgbm90IGFsbCByZWd1bGF0b3J5IGRvbWFpbnMpLg0KDQpJIGV4cGVjdCB0aGUg ZWRpdG9yIHRvIGNvbWUgdXAgd2l0aCByZXNvbHV0aW9ucyB0byB0aGUgY29tbWVudHMgaXQgcmVj ZWl2ZXMgcHJpb3IgdG8gdGhlIEYyRiwgYXMgd2VsbCBhcyBhbnkgb3BlbiBpc3N1ZXMgaGUgaXMg YXdhcmUgb2YsIGR1cmluZyB0aGUgc3RhdHVzIHVwZGF0ZSBvZiB0aGUgbWVyZ2VkIGRyYWZ0Lg0K DQoNCi0gICAgICAgICAgR2Fib3INCg0KRnJvbTogZXh0IEN1aXlhbmcgW21haWx0bzpjdWl5YW5n QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIzLCAyMDEyIDg6MzMgUE0NClRv OiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpOyB2Y2hlbkBnb29nbGUuY29t OyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogTmV3IGRyYWZ0IGZvciBQQVdTIHByb3RvY29s DQoNCkhpLCBHYWJvciBhbmQgVmluY2VudCwNCg0KQmFzaWNhbGx5LCB0aGUgbWVyZ2VkIGRyYWZ0 IGlzIE9rYXkgZm9yIG1lLg0KQnkgbm93LCBvbmUgdGhpbmcgd29ydGggcG9pbnRpbmcgb3V0IGlz IHRoYXQgdGhlIG1hc3RlciBkZXZpY2UgYXV0aGVudGljYXRpb24sIHdoaWNoIGhhcyBiZWVuIG1l bnRpb25lZCBpbiBkcmFmdC1pZXRmLXBhd3MtcHJvYmxlbS1zdG10LXVzZWNhc2VzLXJxbXRzLCBh cyBhIKGwTVVTVKGxLg0KDQotLS1xdW90ZS0tDQoNCi0gU2VjIDYuMQ0KDQpQLjQ6IFRoZSBwcm90 b2NvbCBNVVNUIHByb3ZpZGUgdGhlIGFiaWxpdHkgZm9yIHRoZSBkYXRhYmFzZSB0byBhdXRoZW50 aWNhdGUgdGhlIG1hc3RlciBkZXZpY2UuDQoNCk8uODogVGhlIGRhdGFiYXNlIE1VU1QgcmVzcG9u ZCB0byBhbiBhdmFpbGFibGUgY2hhbm5lbCBsaXN0IHJlcXVlc3QgZnJvbSBhbiBhdXRoZW50aWNh dGVkIGFuZCBhdXRob3JpemVkIGRldmljZQ0KDQotIFNlYyA4IChzZWN1cml0eSBjb25zaWRlcmF0 aW9ucykNClRocmVhdCAxOiBVc2VyIG1vZGlmaWVzIGEgZGV2aWNlIHRvIG1hc3F1ZXJhZGUgYXMg YW5vdGhlciB2YWxpZCBjZXJ0aWZpZWQgZGV2aWNlDQpUaHJlYXQgNTogVW5hdXRob3JpemVkIHVz ZSBvZiBjaGFubmVscyBieSBhbiB1bmNlcnRpZmllZCBkZXZpY2UNCg0KLS0tcXVvdGUtLQ0KQnV0 IGluIHRoZSBtZXJnZWQgZHJhZnQgU2VjIDEwLjQsIGl0IGlzIHNhaWQgdGhhdCChsENvbnNlcXVl bnRseSwgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCByZXF1aXJlZCBmb3IgdGhlIFBBV1Mg cHJvdG9jb2wuobENCg0KSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB3ZSBjbGFyaWZ5IHRo aXMgY29udHJhZGljdGlvbiwgc3VjaCBhcywgcmVtb3ZlIHRoZSB1bmRlcmx5aW5nIHNlbnRlbmNl OyBvdGhlcndpc2UgcGVvcGxlIG1heSB3b25kZXIgd2hldGhlciB3ZSBuZWVkIGEgobBNVVNUobEg Y2FwYWJpbGl0eSBmb3IgYSChsG5vdCByZXF1aXJlZKGxIGZlYXR1cmUuDQpBbHRlcm5hdGl2ZWx5 LCB3ZSBjb3VsZCBjaGFuZ2UgdGhlIKGwTVVTVKGxIHRvIKGwTUFZobEgaW4gdGhlIHJxbXRzIFdH IGRvY3VtZW50Lg0KDQpCVFcsIHRoZSB0d28gY29uY2VybnMgZm9yIGNsaWVudCBhdXRoIGluIFNl YyAxMC40LA0KDQotICAgICAgICAgIEF1dGhvcml6YXRpb24NCg0KLSAgICAgICAgICBDcmVkZW50 aWFsIGxlYWthZ2UNCmhhdmUgYmVlbiB0YWtlbiBjYXJlIG9mIGluIHRoZSBkcmFmdCBkcmFmdC13 dS1wYXdzLXNlY3V0aXR5LTAxLg0KDQpSZWdhcmRzLA0KWWFuZw0KPT09PT09PT09PT09PT09PT09 DQpZYW5nIEN1aSwgIFBoLkQuDQpIdWF3ZWkgVGVjaG5vbG9naWVzDQpjdWl5YW5nQGh1YXdlaS5j b208bWFpbHRvOmN1aXlhbmdAaHVhd2VpLmNvbT4NCg0Kt6K8/sjLOiBwYXdzLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10+ILT6se0gR2Fi b3IuQmFqa29Abm9raWEuY29tPG1haWx0bzpHYWJvci5CYWprb0Bub2tpYS5jb20+DQq3osvNyrG8 5DogMjAxMsTqMTDUwjI0yNUgNToyOA0KytW8/sjLOiB2Y2hlbkBnb29nbGUuY29tPG1haWx0bzp2 Y2hlbkBnb29nbGUuY29tPjsgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCtb3 zOI6IFJlOiBbcGF3c10gTmV3IGRyYWZ0IGZvciBQQVdTIHByb3RvY29sDQoNClRoZXJlIGhhcyBi ZWVuIG5vIHJlc3BvbnNlIHdoYXRzb2V2ZXIgdG8gdGhpcyBtYWlsLiBJIGFtIG5vdCBzdXJlIHdo YXQgdGhhdCBtZWFuczsgaXMgZXZlcnlvbmUgb2sgd2l0aCB0aGUgZHJhZnQgVmluY2Ugc3VibWl0 dGVkLCBvciBkaWQgdGhlIHdnIGxvb3NlIGludGVyZXN0Pz8NCkkgd2lsbCBhbnl3YXkgaW50ZW5k IHRvIGFzayBmb3IgYWRvcHRpb24gb2YgaXQgYXMgYSB3ZyBkb2N1bWVudCBpbiB0aGUgdXBjb21p bmcgRjJGLiBUaGVyZWZvcmUsIGlmIHlvdSBoYXZlIGFueSBpc3N1ZXMgd2l0aCB0aGUgZHJhZnQs IHBsZWFzZSBzZW5kIHRob3NlIHRvIHRoZSBsaXN0IHByaW9yIHRvIHRoZSBGMkYgbWVldGluZy4N Cg0KLSAgICAgICAgICBHYWJvcg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddPG1h aWx0bzpbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBCYWprbyBH YWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIg MDMsIDIwMTIgOTozNiBQTQ0KVG86IHZjaGVuQGdvb2dsZS5jb208bWFpbHRvOnZjaGVuQGdvb2ds ZS5jb20+OyBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtwYXdzXSBOZXcgZHJhZnQgZm9yIFBBV1MgcHJvdG9jb2wNCg0KT2ssIHRoYW5rcyBWaW5jZS4N CkFzIGEgbmV4dCBzdGVwLCBJoa9kIGxpa2UgdG8gYXNrIHRoZSBXRyB0byByZXZpZXcgaXQgYW5k IHNlbmQgdG8gdGhlIGxpc3QgYW55IG1ham9yIHByb2JsZW0gaWRlbnRpZmllZCB3aXRoIHRoZSB0 ZXh0IGluIHRoaXMgZHJhZnQuDQpUaGVuLCBJoa9kIGxpa2UgdG8gYXNrIHRoZSBXRyB0byBhZG9w dCBpdCBhcyBhIHdnIGRvY3VtZW50Lg0KDQotICAgICAgICAgIEdhYm9yDQoNCg0KRnJvbTogZXh0 IFZpbmNlbnQgQ2hlbiBbbWFpbHRvOnZjaGVuQGdvb2dsZS5jb21dPG1haWx0bzpbbWFpbHRvOnZj aGVuQGdvb2dsZS5jb21dPg0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDAzLCAyMDEyIDg6MjEg UE0NClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KQ2M6IEJhamtvIEdh Ym9yIChOb2tpYS1DSUMvU2lsaWNvblZhbGxleSkNClN1YmplY3Q6IE5ldyBkcmFmdCBmb3IgUEFX UyBwcm90b2NvbA0KDQpIaSBBbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgZHJhZnQgZm9yIHRo ZSBQQVdTIHByb3RvY29sIHNwZWNpZmljYXRpb24gdGhhdCByZXByZXNlbnRzIGEgbWVyZ2Ugb2Yg dGhlIG5vbi1jb250cm92ZXJzaWFsIHBvcnRpb25zDQpvZiB0aGUgdHdvIGRvY3VtZW50cyBwcmVz ZW50ZWQgYXQgdGhlIFZhbmNvdXZlciBGMkYuIFlvdSBjYW4gZmluZCBpdCBhdDoNCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdmNoZW4tcGF3cy1wcm90b2NvbC0wMA0KDQpTdW1t YXJ5IG9mIGNoYW5nZXM6DQogLSBCZSBtb3JlIGV4cGxpY2l0IGFib3V0IHJlcXVpcmVkIHZzIG9w dGlvbmFsIHZzICJkZXBlbmRzIG9uIHJlZ3VsYXRvcnkgZG9tYWluIg0KIC0gRGVzY3JpYmUgdGhl ICJEYXRhIE1vZGVscyIgaW4gYSBtb3JlIGhpZXJhcmNoaWNhbCBmYXNoaW9uIGFuZCBtYWtpbmcg aXQgbW9yZSBjbGVhcg0KICAgd2hlcmUgZXh0ZW5zaW9uIHBvaW50cyBhcmUgbG9jYXRlZCB0byBh ZGRyZXNzIHJlZ3VsYXRvcnkgZGlmZmVyZW5jZXMNCiAtIEdlbmVyYWwgcmVwbGFjZW1lbnQgb2Yg ImNoYW5uZWwiIHdpdGggImZyZXF1ZW5jeSIgb3IgInNwZWN0cnVtIiwgd2hlbg0KICAgYXBwcm9w cmlhdGUuDQoNClRoaXMgdmVyc2lvbiBkb2VzIG5vdCBpbmNsdWRlIG1lc3NhZ2UgZW5jb2Rpbmcg b3Igc3BlY2lmaWMgZXJyb3IgY29kZXMuDQoNCi0tDQotdmluY2UNClZpbmNlbnQgQ2hlbg0KR29v Z2xlLCBJbmMuDQo= --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206F6EA008AM1MPN1007mg_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I agree, that section req= uires some rewording. I think the intention was to say that not all regulat= ory domains require master device authentication; but where it is required, it is a must to be performed.

I believe the MUST requir= ement in the reqs doc is the proper language, as the protocol has to have t= hat capability (even if used only by some, and not all regulatory domains).

 <= /p>

I expect the editor to co= me up with resolutions to the comments it receives prior to the F2F, as wel= l as any open issues he is aware of, during the status update of the merged draft.

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: ext Cuiy= ang [mailto:cuiyang@huawei.com]
Sent: Tuesday, October 23, 2012 8:33 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); vchen@google.com; paws@ie= tf.org
Subject: Re: New draft for PAWS protocol

 

Hi, Gabor and Vincent,

 <= /p>

Basically, the merged dra= ft is Okay for me.

By now, one thing worth p= ointing out is that the master device authentication, which has been mentio= ned in draft-ietf-paws-problem-stmt-usecases-rqmts, as a =A1=B0MUST=A1=B1.

---quote--

- Sec 6.1

P.4: The protocol MUST provide the abi= lity for the database to authenticate the master device.<= /p>

O.8: The database MUST respond to an a= vailable channel list request from an authenticated and authorized device

- Sec 8 (security considerations)=

Threat 1: User modifies a device to masquera= de as another valid certified device

Threat 5: Unauthorized use of channels by an= uncertified device

---quote--

But in the merged draft Sec 10.4, it is said that =A1=B0Consequently, c= lient authentication is not required for the PAWS protocol.=A1=B1

 <= /p>

I would like to suggest t= hat we clarify this contradiction, such as, remove the underlying sentence;= otherwise people may wonder whether we need a =A1=B0MUST=A1=B1 capability for a =A1=B0not required=A1=B1 feature.

Alternatively, we could c= hange the =A1=B0MUST=A1=B1 to =A1=B0MAY=A1=B1 in the rqmts WG document.

 <= /p>

BTW, the two concerns for= client auth in Sec 10.4,

-  &n= bsp;       Authorization

-  &n= bsp;       Credential leakag= e

have been taken care of i= n the draft draft-wu-paws-secutity-01.

 <= /p>

Regards,

Yang

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Yang Cui,  Ph.D.

Huawei Technologies

cuiy= ang@huawei.com

 <= /p>

=B7=A2=BC=FE=C8=CB: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] =B4=FA=B1=ED Gabor.Bajko@nokia.com<= br> =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA10=D4=C224=C8=D5 5:28
=CA=D5=BC=FE=C8=CB: vchen@google.com; paws@ietf.org
=D6=F7=CC=E2: Re: [paws] New draft for P= AWS protocol

 

There has been no respons= e whatsoever to this mail. I am not sure what that means; is everyone ok wi= th the draft Vince submitted, or did the wg loose interest??

I will anyway intend to a= sk for adoption of it as a wg document in the upcoming F2F. Therefore, if y= ou have any issues with the draft, please send those to the list prior to the F2F meeting.

- =          Gabor<= /span>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-C= IC/SiliconValley)
Sent: Wednesday, October 03, 2012 9:36 PM
To: vchen@google.com; paws@ietf.org
Subject: Re: [paws] New draft for PAWS protocol

 

Ok, thanks Vince.

As a next step, I=A1=AFd = like to ask the WG to review it and send to the list any major problem iden= tified with the text in this draft.

Then, I=A1=AFd like to as= k the WG to adopt it as a wg document.

- =          Gabor<= /span>

 <= /p>

 <= /p>

From: ext Vinc= ent Chen [mailto:vchen@google.com] =
Sent: Wednesday, October 03, 2012 8:21 PM
To: paws@ietf.org
Cc: Bajko Gabor (Nokia-CIC/SiliconValley)
Subject: New draft for PAWS protocol

 

Hi All,

 

We have submitted a draft for the PAWS protocol spec= ification that represents a merge of the non-controversial portions

of the two documents presented at the Vancouver F2F.= You can find it at:

 

 

Summary of changes:

 - Be more explicit about required vs opti= onal vs "depends on regulatory domain"

 - Describe the "Data Models" in a mo= re hierarchical fashion and making it more clear

   where extension points are located= to address regulatory differences

 - General replacement of "channel" w= ith "frequency" or "spectrum", when

   appropriate.

 

This version does not include message encoding or sp= ecific error codes.

 

--
-vince

Vincent Chen

Google, Inc.

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760206F6EA008AM1MPN1007mg_-- From vchen@google.com Thu Oct 25 11:05:39 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 2108121F8940 for ; Thu, 25 Oct 2012 11:05:39 -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 j3CWWtNqd670 for ; Thu, 25 Oct 2012 11:05:34 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8838921F8727 for ; Thu, 25 Oct 2012 11:05:32 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so3672489qao.10 for ; Thu, 25 Oct 2012 11:05:24 -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 :content-type:x-system-of-record; bh=Z/0wHpdrFd50DMYLptKofuOIX/GIDezDRABhNMycGk4=; b=j+RwnUbENgL74GgJ7aTZqZljCbE5zZoE7/uE1mDTXmF5fckjqtikTRJib1KcKEddue e4n3FGqnNWVXqFmSSWN/oPYcp3Uu6I/145KinLpo2UOn97EFCzd3tVPTHfPfmrAOU/vf aXcP30ShMASKmhbdN7TssEeKqmeh7Mhw48SjwjNPCyK+9u04ffO1o++ZU01+Ljt7lPuL 4OSn7MeeWAWvVhwz7+wtL1kOxZ/NZFHQkBF2eCDfw5bTSUJLqpKojULK3jeq8I5Tte4o tBhBe74R1j+P/f2YaOxGuyAy/sk0poZlRYFyPpOqbQAxK0+qrxDn6KbDq6YD9bTZ0BwR 4PYA== 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 :content-type:x-system-of-record:x-gm-message-state; bh=Z/0wHpdrFd50DMYLptKofuOIX/GIDezDRABhNMycGk4=; b=OYuzHJJmcnTua0KsTJ+i2/Pox4vU6CqZVxZtKg6ZGImJgjhJjvVPsrRoXTfQNvgCla zZcdRCTTqD2vlOpWlGWQkumYkA+HrTzVUxzy/hRoA+zm74TjWEQa5H7EVFB+caCJk72w U5C1zWj1inMnNy9/AxlKrEJH/33WwfMOY2BLyGeH+hPWwNrzzsd2Ark1UnPrphRbvXN0 z3QblvNnJJispTJzaahpHQDW7P02mVb9OVpmIezMfuo3TUoLOL/oz3U5gtrcFmSAypXt IjTEl5ibqFRmbRwrotdwK8yQwLhMG9Zi71B0cpQYRWyjeqnSlMYekyuZbIGkZhMynsRX n68Q== MIME-Version: 1.0 Received: by 10.49.63.104 with SMTP id f8mr11581265qes.29.1351188323922; Thu, 25 Oct 2012 11:05:23 -0700 (PDT) Received: by 10.229.133.135 with HTTP; Thu, 25 Oct 2012 11:05:23 -0700 (PDT) In-Reply-To: <8CC0CB0BCAE52F46882E17828A9AE2163687174A@SZXEML508-MBX.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47602012484@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB4E@008-AM1MPN1-007.mgdnok.nokia.com> <8CC0CB0BCAE52F46882E17828A9AE2163687174A@SZXEML508-MBX.china.huawei.com> Date: Thu, 25 Oct 2012 11:05:23 -0700 Message-ID: From: Vincent Chen To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" , "br@brianrosen.net" Content-Type: multipart/alternative; boundary=047d7bdc1a3a12731b04cce60cec X-System-Of-Record: true X-Gm-Message-State: ALoCoQkLfRYNIL/PLKr+qDyVIhSiRSlcY96/73Vtk2IFM0gnrxMJss2HVNsnDvy3LO0Bp8tk5aIQePtS5klqDXwwwBM431cwhw8yCIeB65DBqtVviwWTCfEyPrjr+oEukCZkj7NUwwYFGAnJ6S1OPzxfqF6pNZk8Ra9bJl63GEFTugbL1MBO+378A2HDiYWp+rc1PgvdSCPN Subject: Re: [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: Thu, 25 Oct 2012 18:05:39 -0000 --047d7bdc1a3a12731b04cce60cec Content-Type: text/plain; charset=ISO-8859-1 Hi Gabor and Brian, We would like a time slot to discuss draft-vchen-paws-protocol-00. Thanks. -vince --047d7bdc1a3a12731b04cce60cec Content-Type: text/html; charset=ISO-8859-1 Hi Gabor and Brian,

We would like a time slot to discuss draft-vchen-paws-protocol-00.

Thanks.

-vince
--047d7bdc1a3a12731b04cce60cec-- From vchen@google.com Sun Oct 28 12:25:41 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 6707C21F84F5 for ; Sun, 28 Oct 2012 12:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.376 X-Spam-Level: X-Spam-Status: No, score=-100.376 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Al1bt+GM6Y5n for ; Sun, 28 Oct 2012 12:25:40 -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 899F321F8581 for ; Sun, 28 Oct 2012 12:25:40 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so1236027qca.31 for ; Sun, 28 Oct 2012 12:25: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=JndJW5b/RvLuJ86IAaRGgxwiBZgD6qc2Y+hnw2PCqLw=; b=F5QE7h8U2XHyjcvr4bDGhD27YCYVLnDXqBZphKaP/df7jcXfU++Dz36L1S5sSmizUi vtr2tOHyiQM8YUcUW2WIvDay/YmzGADAt+tUWrmZCyRjDBb0fu+x9LZlsgvn0CcJ3Etj 3ZybO53w7VwoPefc9KZNql7rhb2G3Ljv3Wobh9xGRIuGKop2wOLRnW9uEyD21Jk+KvWH uDINw4v4decezIJs8hdMDxNWVHxrdAdhAz8dPYmzVOo5RGfTXN9bQ3p7DcorhHjWqOtU +JMV2DZHwmxda5qlgD9cT4anT8yg5u5s/ZpNY6OAzpZZn6VBUwfoWozXZEqKlhSfQDgm 4xLQ== 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=JndJW5b/RvLuJ86IAaRGgxwiBZgD6qc2Y+hnw2PCqLw=; b=lgABCNgor+4u/7nYHec9T1AEl/WLw5/FamyN58AclmUkZOCYX6La25Mtccr3NokNiG LDO5qxe/kguiFWJ7NqabjlGXMiBKDhTPVWj6797cRc2B2JHWduHJhUO760qXK+249nVy bCJfcizpkYN44iNyFaNgAhFkDeRdGf8O/i5RwV/Tk3ZPxmchRZW90XhYv8xOEj3irk2k EDfUdEN2ApVmJ1kIQBbjbWdKf8KoTthNz9UuVYRk14PhkzBBthTsPgNS2WWULcClSTqg ASPy8PNKDN6rUyPgIOZrx36KGQlE5NyjcOCJ9Ybr4xxFB/6Jkr9dfyN6iXsGtO/ArnSq LY+A== MIME-Version: 1.0 Received: by 10.224.200.196 with SMTP id ex4mr16420172qab.46.1351452339907; Sun, 28 Oct 2012 12:25:39 -0700 (PDT) Received: by 10.229.133.135 with HTTP; Sun, 28 Oct 2012 12:25:39 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19@008-AM1MPN1-007.mgdnok.nokia.com> References: <5076FFB7.4030701@blindcreek.com> <50783263.6060601@blindcreek.com> <507880D5.5010501@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19@008-AM1MPN1-007.mgdnok.nokia.com> Date: Sun, 28 Oct 2012 12:25:39 -0700 Message-ID: From: Vincent Chen To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary=20cf3005dd26a6ab7804cd238426 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm2tOdFm1ztEAdfUcCbrqeiYovKJpWR1Dhg2ucH+z/3xDQvQWQCn+GJL/DKV9aMo01UtOzjgj/m434xViRDR7PhlybGWEhiB+KoWhhS7yQDhNG0JXyVQeub8KZHK7m5WKuaouIgjk6KjuWVfHQR/ZDCVUo5ntkngW1bMgDS0NWsRoQ/Bl80+9jpcg3Io1e74WPkGXYf Cc: paws@ietf.org Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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: Sun, 28 Oct 2012 19:25:41 -0000 --20cf3005dd26a6ab7804cd238426 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, I'd like to address this at the F2F as an open issue, though I think we are mostly in agreement. The only point of discussion seems to be how to represent the (lat, lon, height) in the protocol messages. 1. In the interest of avoiding ambiguity in the "generic" Device-to-Database protocol, it still seems more precise for the device to report (only) the location of its antenna's radiation center: (lat, lon, height) with associated uncertainties, etc, and where height is optional for some types of devices. That's the only relevant location when determining available spectrum. It seems that that's the intent of the FCC rules, even though the text does say "device location". 2. We probably should allow automated GPS-reporting of the location of the antenna's radiation center. Since GPS cannot report height above ground, the protocol should allow the height to be entered as: - Height relative to ground/surface (manually entered by installer) - Height relative to mean sea level (reported by GPS) A regulatory domain could restrict to be only one of these. -vince On Tue, Oct 23, 2012 at 2:23 PM, wrote: > Yes, I also think that separating the device location and antenna > parameters is a good approach. This is what the requirements document > requires too.**** > > So, send the device=92s (lon, lat, alt) location with related uncertainti= es > and datum; and separately, the antenna parameters. The DB can then combin= e > them, if it needs to, to provide the list of available channels.**** > > ** ** > > **- **Gabor **** > > ** ** > > > --20cf3005dd26a6ab7804cd238426 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All,

I'd like to address this at the F2F as an open = issue, though I think we are mostly in agreement.
The only point = of discussion seems to be how to represent the (lat, lon, height) in the pr= otocol messages.

1. In the interest of avoiding ambiguity in the "g= eneric" Device-to-Database protocol, it still seems
=A0 =A0 = more precise for the device to report (only) the location of its antenna= 9;s radiation center:

=A0 =A0 (lat, lon, height)

=A0= =A0with associated uncertainties, etc, and where height is optional for so= me types of devices.

=A0 That's the only relev= ant location when determining available spectrum. It seems that that's<= /div>
=A0 the intent of the FCC rules, even though the text does say "d= evice location".

2. We probably should allow = automated GPS-reporting of the location of the antenna's radiation=A0
=A0 =A0center. Since GPS cannot report height above ground, the protoc= ol should allow the height to be
=A0 =A0entered as:
=A0 =A0- Height relative to ground/surface (manually entered by= installer)
=A0 =A0- Height relative to mean sea level (reported by GPS)

=A0 =A0A regulatory domain could restrict to be only one of= these.

-vince

O= n Tue, Oct 23, 2012 at 2:23 PM, <Gabor.Bajko@nokia.com>= wrote:

Yes, I also think that se= parating the device location and antenna parameters is a good approach. Thi= s is what the requirements document requires too.

So, send the device=92s (= lon, lat, alt) location with related uncertainties and datum; and separatel= y, the antenna parameters. The DB can then combine them, if it needs to, to provide the list of available channels.

=A0<= /p>

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

=A0<= /p>


--20cf3005dd26a6ab7804cd238426-- From presnick@qti.qualcomm.com Sun Oct 28 23:38:02 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 D307621F85D5 for ; Sun, 28 Oct 2012 23:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.772 X-Spam-Level: X-Spam-Status: No, score=-99.772 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227, 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 2i-qONSH5QsD for ; Sun, 28 Oct 2012 23:38:01 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 139FE21F85C8 for ; Sun, 28 Oct 2012 23:38:01 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6879"; a="2631218" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 28 Oct 2012 23:15:34 -0700 X-IronPort-AV: E=Sophos;i="4.80,669,1344236400"; d="scan'208";a="916308" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Oct 2012 23:38:00 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sun, 28 Oct 2012 23:37:56 -0700 Message-ID: <508E2443.8010701@qti.qualcomm.com> Date: Mon, 29 Oct 2012 01:37:55 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Subject: [paws] AD Review of draft-ietf-paws-problem-stmt-usecases-rqmts 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, 29 Oct 2012 06:38:03 -0000 Folks, Off the top, I want to sincerely apologize for the lateness of this review. A bunch of day-job things followed by an ill-timed vacation conspired to make this very late. Overall, I want to say that while I have some issues with this document, they are almost all of the form that there is *too much* information in the document. Section 4 is 19 pages of the document, and for the life of me I can't connect up the use cases in section 4 with the requirements in section 6. I am inclined to seriously trim down the use cases so that it is clear what use case corresponds to what requirement. There is also quite a bit of material in sections 1 through 3 that are about whitespace itself and the regulatory environment. As I've said before in face-to-face meetings and on this list, this protocol, while it is being used for access to a whitespace database, has scant little to do with whitespace. You don't even need to know much about anything about radio to implement this protocol; it's a database access protocol with a set of fields returned that happen to have information about whitespace usage. So please (to quote Douglas Adams), "Don't panic!" Take the below comments as simply an attempt to remove extra unnecessary information; as I said, for the most part, that is my main complaint. But I do think we want to take a shot at clearing this up before Last Call, let alone before IESG Evaluation. Other ADs will not be so kind! :-) pr ------ Specifics: 1.1. Introduction to white space Academia and Industry have studied multiple cognitive radio mechanisms for use in such a scenario. "Cognitive Radio" is undefined. Spectrum useable for data communications, especially wireless Internet communications, is scarce. ... I think everything up to the last two sentences of this paragraph is unnecessary and doesn't add to the document Any entity that is assigned spectrum that is not densely used may be asked to give it up in one way or another for more intensive use. Providing a mechanism by which additional users share the spectrum with the assigned user is attractive in many bands in many countries. That's fine Television transmission until now has primarily been analog. ... This paragraph and the figure are completely unneeded. The fundamental issue is how to determine for a specific location and specific time if any of the spectrum is available for additional use. ... I'm not sure whether the above is necessary or not. I don't see what it adds. 1.2.1. In Scope This document applies only to communications required for basic service in TV white spaces. That sentence is just wrong. First, it's worded as if this document is about *communications* in TV white spaces. It's obviously not about that at all; it applies to *database access for discovery of whitespace allocations*. But even there, it's also not at all clear that this document applies only to TV white spaces. This protocol is applicable to any shared spectrum, whether it is coming from TV white space or otherwise. What I think you mean to say is, "This document lays out the requirements for accessing a database of information about available spectrum, with a specific eye to the use case of TV white spaces. Requirements outside of that use case are not accounted for." We don't want to say that this document *can't* be used for other such databases; it just isn't taking those requirements into account. 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains, but is not limited to, You say, "not limited to". What other kinds of things might be in there? current information as required by by the regulatory policies... The phrase "as required by regulatory policies" is unneeded. The information in the database might be required by regulators, or it might not. Regulatory policies have nothing to do with the requirements of the protocol. Device Class Identifies classes of devices defined by Regional Regulators, ... Again, "defined by Regional Regulators" should be removed. including fixed, mobile, portable, etc... May also indicate if the device is indoor or outdoor. Slave Device A device which uses the spectrum made available by a master device, and cannot query the database directly. Do you mean "cannot" or "does not"? In other words, if a device has direct Internet access and is able to communicate with the database, is it by definition a master device? 3. Prior Work I didn't find section 3 at all useful. Could someone explain what this adds to the document? An understanding of this did not help me in section 6, which is what I would expect. 4. Use cases and protocol services There are many potential use cases that could be considered for the TV white space spectrum. ... So my basic issue with this section (and this paragraph) is that many of the use cases are architecturally identical for purposes of the requirements. I think a good deal of compression could be done in this section. 4.1.1. White space database discovery ... The master device will need to discover a trusted database in the relevant regulatory domain, using the following steps: "Regulatory domain" is unnecessary. 1. The master device is connected to the Internet by any means... That's fine. ...other than using the white space radio. A local regulator may identify exception cases where a master may initialize over white space (e.g. the FCC allows a master to initialize over the TV white space in certain conditions). The rest of this is out of band and not relevant to the protocol. Optionally the radio device is pre-programmed with the Internet address of at least one trusted database. The device can establish contact with a trusted database using one of the pre-programmed Internet addresses and establish a white space network (as described in one of the following use cases). OK. Optionally the initial query will be made to a listing approved by the national regulator for the domain of operation (e.g. a website either hosted by or under control of the national regulator) which maintains a list of WS databases and their Internet addresses. The query results in the list of databases and their Internet addresses being sent to the master, which then evaluates the response to determine if a trusted database can be identified where the master device is able to register and receive service from the database. The above seems identical to the previous paragraph. Can't this paragraph be removed? 4.1.2. Device registration with trusted Database Registration may be preliminary to creating a radio network using white space; in some regulatory domains, for some device types, it is a prerequisite to the use cases below. The radio network is created by a master device. Before the master device can transmit in white space spectrum, it must contact a trusted database where the device can learn if any channels are available for it to use. The above is confusing to me. What does it mean to create the radio network before transmitting? And again, why is this relevant to the protocol? \|/ ---------- | |Database| | .---. /--------- |-|---------| ( ) / \|/ | Master | / \ | / | |========( Internet ) | / |-----------| \ / +-|----+ (AirIF) ( ) |Master| / (----) | | / +------+ Figure 2: Example illustration of registration requirement in white space use-case Master appears twice is this diagram. Are there two masters in this model? I don't understand what this means. A simplified operational scenario showing registration consists of the following steps: 1. The master device must register with its most current and up-to- date information. Typically the master device will register prior to operating in white space for the first time after power up, after changing location by a predetermined distance, and after regular time intervals. Is the above simply an authentication step? 2. The master device shall provide to the database during registration all information required according to local regulatory requirements. This information may include, but is not limited to, the Device ID, serial number assigned by the manufacturer the device's location, device antenna height above ground, name of the individual or business that owns the device, name of a contact person responsible for the device's operation address for the contact person, email address for the contact person and phone number of the contact person. Is the above to be specified by the protocol, or is this simply a blob of information that has only local meaning? For instance, will the database announce the information it needs for registration, or will the device simply have to know this out of band? I don't see anything in section 6 regarding this. 3. The database shall respond to the registration request with an acknowledgement code to indicate the success or failure of the registration request. Additional information may be provided according to local regulator requirements. Are there semantics to the acknowldgement code beyond "Registered" and "Not registered"? If so, is the IETF defining those? 4.2. Use cases 4.2.1. Hotspot: urban Internet connectivity service First let me say that I can find no difference architecturally between this use case and wide-area/rural deployment in 4.2.2. Indeed, the diagrams are almost identical. So I see no need to separate this out into two sections; they should at least be combined. That said: In this use case Internet connectivity service is provided in a "hotspot" to local users. Typical deployment scenarios include urban areas where Internet connectivity is provided to local businesses and residents, and campus environments where Internet connectivity is provided to local buildings and relatively small outdoor areas. The above seems unimportant. Whether it's a hotspot, or provider to campus or local buildings, or wide-area/rural is not important to the architecture. They key an Internet access point that wants to talk to devices over whitespace spectrum discovering which spectrum to use by querying the database. This deployment scenario is typically characterized by multiple masters ... If this is typical, why is only one master shown in the figure. You'd think that would be important to the diagram. However, I suspect it isn't important to the architecture and that this discussion about multiple masters can be removed. (APs or hotspots) in close proximity, with low antenna height, cells with relatively small radius (a few kilometers or less), and limited numbers of available radio channels. Many of the masters/APs are assumed to be individually deployed and operated, i.e. there is no coordination between many of the masters/APs. The masters/APs in this scenario use a TDD radio technology. Each master/AP has a connection to the Internet and may provide Internet connectivity to other master and slave devices. TDD is undefined. AP is undefined. And again, I see nothing in the above important to the architecture being discussed. Figure 3: Slaves are labeled as "device". That's confusing. 1. ...A local regulator may identify exception cases where a master may initialize over white space (e.g. the FCC allows a master to initialize over TV white space in certain conditions). This sounds like a different deployment scenario, not the same one. 3. The master/AP registers with the trusted database according to regulatory domain requirements (see Section 4.1.2). Regulatory domain requirement are irrelevent. You can strike that part. 4. ...The complete set of parameters to be provided from the master to the database is specified by the local regulator. No, it's provided by database policy. Local regulators may specify their particular database policy, but that's outside of the protocol. 5. If the master/AP has met all regulatory domain requirements (e.g. been previously authenticated, etc)... Is there anything beyond authentication here? Importantly, neither the master nor the database can understand the semantics of "regulatory domain requirements"can they? That's all out of band. 6. Once the master/AP has met all regulatory domain requirements (e.g. authenticated the WS channel list response message from the database, etc)... Same as above. ...the AP selects one or more available WS channels from the list. Prior to initiating transmission, if required by local regulation... It's not "local regulation", it's protocol that would require the answer, right? 7-13. Except for relaying information about the slaves to the database and how frequencies/channels are determined, isn't everything thing else in 7-13 what a normal device/AP interaction would look like? This can all be reduced to one or two points it seems to me. 4.2.2. Wide-Area or Rural Internet broadband access As I said above, this appears architecturally identical to 4.2.1. A typical deployment scenario is a wide area or rural area, where Internet broadband access is provided to local businesses and residents from a master (i.e., BS) connected to the Internet. BS is undefined. Probably best to define it. :-) 4.2.3. Offloading: moving traffic to a white space network This example is obfuscated by the mention of "3G" and "YouTube". First of all, there is nothing about 3G that is unique to this scenario; the desire to use white space instead of any kind of more costly internet connection (metered wire service, metered wireless service, metered satellite service) is what's relevant. Second, using a widget or an online service is also irrelevant; the key is that a high-bandwidth or other costly service is to be used. (The mention of "YouTube" is, I think, especially inappropriate.) This entire section could use some rewriting. 4.2.4. White space serving as backhaul In this use case Internet connectivity service is provided to users over a more common wireless standard such as Wi-Fi with white space entities providing backhaul connectivity to the Internet. In a typical deployment scenario an end user has a device with a radio such as Wi-Fi. An Internet service provider or a small business owner wants to provide Wi-Fi Internet connectivity service to their customers. The location where Internet connectivity service via Wi-Fi is to be provided is within the coverage area of a white space master (e.g. Hotspot or Wide-Area/Rural network). The service provider installs a white space slave device and connects it to the Wi-Fi access point(s). Wi-Fi access points with an integrated white space slave component may also be used. This deployment scenario is typically characterized by a WS master/AP/BS providing local coverage. The master/AP has a connection to the Internet and provides Internet connectivity to slave devices that are within its coverage area. The WS slave device is 'bridged' to a Wi-Fi network thereby enabling Internet connectivity service to Wi-Fi devices. The WS Master/AP/BS which has some form of Internet connectivity (wired or wireless) queries the database and obtains available channel information. It then provides service using those channels to slave devices which are within its coverage area. Figure 6 shows an example deployment of this scenario. \|/ white \|/ \|/ Wi-Fi \|/ | space | | | | | | |-|----| |--------| |-|---------| |-|------|-| | Wi-Fi| | | | Master | | Slave | | Dev | |Internet|------| (AP/BS) | | Bridge | |------| | | | | | to Wi-Fi | |--------| |-----------| |----------| \|/ | |-|----| | Wi-Fi| | Dev | |------| Figure 6: WS for backhaul The description of this deployment scenario is not well written, and the figure does nothing to help. Aren't the Wi-fi devices supposed to be connected to the slave, and then the slave talks to the master? This needs some help. 4.2.5. Rapid deployed network for emergency scenario ... This approach does in no way imply such organizations for disaster relief must compete on spectrum allocation with other white spaces users, but they can. ... That sentence seems unnecessary. 4.2.6. Mobility How does this use case differ architecturally from 4.2.1? Why isn't this case just a subcase of 4.2.1, like 4.2.2? 4.2.7. Indoor Networking Isn't this just the same as 4.2.1 without geolocation? Again, seems like it could be combined and shortened. 5. Problem Statement In Figure 11, note that there could be multiple databases serving white space devices. The databases are country specific since the regulations and available spectrum may vary. Location specific, not country specific, right? It may be that multiple countries share a database, or it may be that a single country has multiple databases for sub-locales, right? The architecture doesn't depend on "country". 5.1. Global applicability The use of TV white space spectrum is currently approved by the FCC in the United States. However regulatory bodies in other countries are also considering similar use of available spectrum. ... Again, the mention of the regulatory bodies here is unnecessary as it doesn't impact this protocol. 4. Address regulatory requirements - Each country is likely to have regulations that are unique to that country. The messaging interface needs to be flexible to accommodate the specific needs of a regulatory body in the country where the white space device is operating and connecting to the relevant database. I would rewrite this to say: "4. Flexible and extensible data structures - Different databases are likely to have different requirements for the kinds of data required for registration as well as the kinds of data returned with available white space. For instance, different regulatory bodies might require different information to be passed between the database and the device accessing it." Again, don't make the regulatory body part of the problem statement; the need to accommodate different data is the requirement. 5.4. Data model definition ... Use of XML for specifying a data model is an attractive option. The intent is to evaluate the best option that meets the need for use between white space devices and databases. The mention of XML here is premature. Give it as one example (perhaps including JSON as another) if you think you need such an example. 6. Requirements 6.1. Normative Requirements D. Data Model Requirements: D.1: The Data Model MUST support specifying the location of the WSD, the uncertainty in meters, the height & its uncertainty, and confidence in percentage of the location determination. ... "Location" in the above is ambiguous. You mean the "geographic location", right? ...The Data Model MUST support both North American Datum of 1983 and WGS84. Neither of these has a reference. Also, if NAD is really a requirement, shouldn't there be others listed? D.2: The Data Model MUST support specifying the regulatory domain and its corresponding data requirements. That is poorly written. I don't understand what needs to go in a protocol from the above. Don't you just mean that the Data Model MUST be extensible? D.3: The Data Model MUST support specifying an ID of the transmitter device. This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain. The Data Model MUST support a device class. The Data Model MUST support specifying information about the type of RAT of the transmitter device. What sort of data is an ID? You probably need to mention that. Also "RAT" is undefined. P. Protocol Requirements: P.1: The protocol MUST provide a mechanism to enable WSD discovery. In some environments, a listing of the approved white space databases is maintained by the national regulator. The protocol MUST support discovery of a database using a listing approved by a national regulator. The "national regulator" portion of the requirement is not the requirement. What is it about the list a national regulator provides that is different, protocol-wise, from any other list from which the WSD is discovered? P.3: The protocol MUST support determination of regulatory domain governing its current location. I don't know what that requirement means. P.8: The protocol MUST support the master device registering with the database. What is "registering" independent of authentication/authorization? P.10: The protocol MUST support a channel query request from the master device to the database. The channel query request message MUST include parameters as required by local regulatory requirement. These parameters MAY include any of the parameters and attributes required to be supported in the Data Model Requirements. Strike the second sentence. Unnecessary. 6.2. Non-normative requirements I don't understand what a non-normative requirement is. Are these just pre-requisites? Please explain. I'm guessing that the 2119 language in this section is misused, but let me understand what the section is meant to say first. O.4: The master device MUST implement at least one connection method to access the database. The master device MAY contact a database directly for service (e.g. as defined by FCC) or the master device MAY contact a listing server first followed by contact to a database (e.g. as defined by Ofcom). References needed for FCC and Ofcom if you insist on noting them. (I don't think they're necessary.) O.5: The master device MUST obtain an indication about the regulatory domain governing operation at its current location, i.e. the master device MUST know if it operates under regulations from FCC, Ofcom, etc... That would be completely out of band, correct? -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From peter@spectrumbridge.com Mon Oct 29 05:53:10 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 ADB1621F85FA for ; Mon, 29 Oct 2012 05:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227] 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 9VRnj4mUEaCv for ; Mon, 29 Oct 2012 05:53:09 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id A038821F84FC for ; Mon, 29 Oct 2012 05:53:08 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 29 Oct 2012 08:53:07 -0400 From: Peter Stanforth To: Pete Resnick , "paws@ietf.org" Date: Mon, 29 Oct 2012 08:53:01 -0400 Thread-Topic: [paws] AD Review of draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac211FctJiNsIbi9QPmS0MrShaO84g== Message-ID: In-Reply-To: <508E2443.8010701@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] AD Review of draft-ietf-paws-problem-stmt-usecases-rqmts 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, 29 Oct 2012 12:53:10 -0000 Pete, I don't think we can ignore the "Regulator". You may not need to know what a radio does or how it works but the database is logically tied to a Regulator. In all the cases we are aware of the Database will either be operated by the Regulator or by an entity (or entities) authorized by a Regulator. Spectrum use is tightly regulated - the regulator makes the rules. There are many examples of things that are included in this protocol that you could argue would not normally be required for a protocol. They are only there because Regulators require them. You raise a lot of questions on the requirements and these should probably be resolved before we expend much more effort on the protocol specifications. Peter S. On MonOct/29/12 Mon Oct 29, 2:37 AM, "Pete Resnick" wrote: >Folks, > >Off the top, I want to sincerely apologize for the lateness of this >review. A bunch of day-job things followed by an ill-timed vacation >conspired to make this very late. > >Overall, I want to say that while I have some issues with this document, >they are almost all of the form that there is *too much* information in >the document. Section 4 is 19 pages of the document, and for the life of >me I can't connect up the use cases in section 4 with the requirements >in section 6. I am inclined to seriously trim down the use cases so that >it is clear what use case corresponds to what requirement. There is also >quite a bit of material in sections 1 through 3 that are about >whitespace itself and the regulatory environment. As I've said before in >face-to-face meetings and on this list, this protocol, while it is being >used for access to a whitespace database, has scant little to do with >whitespace. You don't even need to know much about anything about radio >to implement this protocol; it's a database access protocol with a set >of fields returned that happen to have information about whitespace >usage. So please (to quote Douglas Adams), "Don't panic!" Take the below >comments as simply an attempt to remove extra unnecessary information; >as I said, for the most part, that is my main complaint. But I do think >we want to take a shot at clearing this up before Last Call, let alone >before IESG Evaluation. Other ADs will not be so kind! :-) > >pr > >------ > >Specifics: > >1.1. Introduction to white space > > Academia and Industry have studied > multiple cognitive radio mechanisms for use in such a scenario. > >"Cognitive Radio" is undefined. > > Spectrum useable for data communications, especially wireless > Internet communications, is scarce. ... > >I think everything up to the last two sentences of this paragraph is >unnecessary and doesn't add to the document > > Any entity that is assigned > spectrum that is not densely used may be asked to give it up in one > way or another for more intensive use. Providing a mechanism by > which additional users share the spectrum with the assigned user is > attractive in many bands in many countries. > >That's fine > > Television transmission until now has primarily been analog. ... > >This paragraph and the figure are completely unneeded. > > The fundamental issue is how to determine for a specific location and > specific time if any of the spectrum is available for additional use. > ... > >I'm not sure whether the above is necessary or not. I don't see what it >adds. > >1.2.1. In Scope > > This document applies only to communications required for basic > service in TV white spaces. > >That sentence is just wrong. First, it's worded as if this document is >about *communications* in TV white spaces. It's obviously not about that >at all; it applies to *database access for discovery of whitespace >allocations*. But even there, it's also not at all clear that this >document applies only to TV white spaces. This protocol is applicable to >any shared spectrum, whether it is coming from TV white space or >otherwise. What I think you mean to say is, "This document lays out the >requirements for accessing a database of information about available >spectrum, with a specific eye to the use case of TV white spaces. >Requirements outside of that use case are not accounted for." We don't >want to say that this document *can't* be used for other such databases; >it just isn't taking those requirements into account. > >2.2. Terminology > > Database > > In the context of white space and cognitive radio technologies, > the database is an entity which contains, but is not limited to, > >You say, "not limited to". What other kinds of things might be in there? > > current information as required by by the regulatory policies... > >The phrase "as required by regulatory policies" is unneeded. The >information in the database might be required by regulators, or it might >not. Regulatory policies have nothing to do with the requirements of the >protocol. > > Device Class > > Identifies classes of devices defined by Regional Regulators, > ... > >Again, "defined by Regional Regulators" should be removed. > > including fixed, mobile, portable, etc... May also indicate if > the device is indoor or outdoor. > > Slave Device > > A device which uses the spectrum made available by a master > device, and cannot query the database directly. > >Do you mean "cannot" or "does not"? In other words, if a device has >direct Internet access and is able to communicate with the database, is >it by definition a master device? > >3. Prior Work > >I didn't find section 3 at all useful. Could someone explain what this >adds to the document? An understanding of this did not help me in >section 6, which is what I would expect. > >4. Use cases and protocol services > > There are many potential use cases that could be considered for the > TV white space spectrum. ... > >So my basic issue with this section (and this paragraph) is that many of >the use cases are architecturally identical for purposes of the >requirements. I think a good deal of compression could be done in this >section. > >4.1.1. White space database discovery > > ... The master device will need to discover a > trusted database in the relevant regulatory domain, using the > following steps: > >"Regulatory domain" is unnecessary. > > 1. The master device is connected to the Internet by any means... > >That's fine. > > ...other > than using the white space radio. A local regulator may identify > exception cases where a master may initialize over white space > (e.g. the FCC allows a master to initialize over the TV white > space in certain conditions). > >The rest of this is out of band and not relevant to the protocol. > > Optionally the radio device is pre-programmed with the Internet > address of at least one trusted database. The device can establish > contact with a trusted database using one of the pre-programmed > Internet addresses and establish a white space network (as described > in one of the following use cases). > >OK. > > Optionally the initial query will be made to a listing approved by > the national regulator for the domain of operation (e.g. a website > either hosted by or under control of the national regulator) which > maintains a list of WS databases and their Internet addresses. The > query results in the list of databases and their Internet addresses > being sent to the master, which then evaluates the response to > determine if a trusted database can be identified where the master > device is able to register and receive service from the database. > >The above seems identical to the previous paragraph. Can't this >paragraph be removed? > >4.1.2. Device registration with trusted Database > > Registration may be preliminary to creating a radio network using > white space; in some regulatory domains, for some device types, it is > a prerequisite to the use cases below. The radio network is created > by a master device. Before the master device can transmit in white > space spectrum, it must contact a trusted database where the device > can learn if any channels are available for it to use. > >The above is confusing to me. What does it mean to create the radio >network before transmitting? And again, why is this relevant to the >protocol? > > > \|/ ---------- > | |Database| > | .---. /--------- > |-|---------| ( ) / > \|/ | Master | / \ > | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Inter= net ) > | / |-----------| \ / > +-|----+ (AirIF) ( ) > |Master| / (----) > | | / > +------+ > > Figure 2: Example illustration of registration requirement in white > space use-case > > >Master appears twice is this diagram. Are there two masters in this >model? I don't understand what this means. > > A simplified operational scenario showing registration consists of > the following steps: > > 1. The master device must register with its most current and up-to- > date information. Typically the master device will register > prior to operating in white space for the first time after power > up, after changing location by a predetermined distance, and > after regular time intervals. > >Is the above simply an authentication step? > > 2. The master device shall provide to the database during > registration all information required according to local > regulatory requirements. This information may include, but is > not limited to, the Device ID, serial number assigned by the > manufacturer the device's location, device antenna height above > ground, name of the individual or business that owns the device, > name of a contact person responsible for the device's operation > address for the contact person, email address for the contact > person and phone number of the contact person. > >Is the above to be specified by the protocol, or is this simply a blob >of information that has only local meaning? For instance, will the >database announce the information it needs for registration, or will the >device simply have to know this out of band? I don't see anything in >section 6 regarding this. > > 3. The database shall respond to the registration request with an > acknowledgement code to indicate the success or failure of the > registration request. Additional information may be provided > according to local regulator requirements. > >Are there semantics to the acknowldgement code beyond "Registered" and >"Not registered"? If so, is the IETF defining those? > >4.2. Use cases > >4.2.1. Hotspot: urban Internet connectivity service > >First let me say that I can find no difference architecturally between >this use case and wide-area/rural deployment in 4.2.2. Indeed, the >diagrams are almost identical. So I see no need to separate this out >into two sections; they should at least be combined. That said: > > In this use case Internet connectivity service is provided in a > "hotspot" to local users. Typical deployment scenarios include urban > areas where Internet connectivity is provided to local businesses and > residents, and campus environments where Internet connectivity is > provided to local buildings and relatively small outdoor areas. > >The above seems unimportant. Whether it's a hotspot, or provider to >campus or local buildings, or wide-area/rural is not important to the >architecture. They key an Internet access point that wants to talk to >devices over whitespace spectrum discovering which spectrum to use by >querying the database. > > This > deployment scenario is typically characterized by multiple masters > ... > >If this is typical, why is only one master shown in the figure. You'd >think that would be important to the diagram. However, I suspect it >isn't important to the architecture and that this discussion about >multiple masters can be removed. > > (APs or hotspots) in close proximity, with low antenna height, cells > with relatively small radius (a few kilometers or less), and limited > numbers of available radio channels. Many of the masters/APs are > assumed to be individually deployed and operated, i.e. there is no > coordination between many of the masters/APs. The masters/APs in > this scenario use a TDD radio technology. Each master/AP has a > connection to the Internet and may provide Internet connectivity to > other master and slave devices. > >TDD is undefined. AP is undefined. And again, I see nothing in the above >important to the architecture being discussed. > > Figure 3: > >Slaves are labeled as "device". That's confusing. > > 1. ...A local > regulator may identify exception cases where a master may > initialize over white space (e.g. the FCC allows a master to > initialize over TV white space in certain conditions). > >This sounds like a different deployment scenario, not the same one. > > 3. The master/AP registers with the trusted database according to > regulatory domain requirements (see Section 4.1.2). > >Regulatory domain requirement are irrelevent. You can strike that part. > > 4. ...The complete set of parameters to be provided > from the master to the database is specified by the local > regulator. > >No, it's provided by database policy. Local regulators may specify their >particular database policy, but that's outside of the protocol. > > 5. If the master/AP has met all regulatory domain requirements > (e.g. been previously authenticated, etc)... > >Is there anything beyond authentication here? Importantly, neither the >master nor the database can understand the semantics of "regulatory >domain requirements"can they? That's all out of band. > > 6. Once the master/AP has met all regulatory domain requirements > (e.g. authenticated the WS channel list response message from > the database, etc)... > >Same as above. > > ...the AP selects one or more available WS > channels from the list. Prior to initiating transmission, if > required by local regulation... > >It's not "local regulation", it's protocol that would require the >answer, right? > > 7-13. > >Except for relaying information about the slaves to the database and how >frequencies/channels are determined, isn't everything thing else in 7-13 >what a normal device/AP interaction would look like? This can all be >reduced to one or two points it seems to me. > >4.2.2. Wide-Area or Rural Internet broadband access > >As I said above, this appears architecturally identical to 4.2.1. > > A typical deployment scenario is a wide area or rural area, where > Internet broadband access is provided to local businesses and > residents from a master (i.e., BS) connected to the Internet. > >BS is undefined. Probably best to define it. :-) > >4.2.3. Offloading: moving traffic to a white space network > >This example is obfuscated by the mention of "3G" and "YouTube". First >of all, there is nothing about 3G that is unique to this scenario; the >desire to use white space instead of any kind of more costly internet >connection (metered wire service, metered wireless service, metered >satellite service) is what's relevant. Second, using a widget or an >online service is also irrelevant; the key is that a high-bandwidth or >other costly service is to be used. (The mention of "YouTube" is, I >think, especially inappropriate.) This entire section could use some >rewriting. > >4.2.4. White space serving as backhaul > > In this use case Internet connectivity service is provided to users > over a more common wireless standard such as Wi-Fi with white space > entities providing backhaul connectivity to the Internet. In a > typical deployment scenario an end user has a device with a radio > such as Wi-Fi. An Internet service provider or a small business > owner wants to provide Wi-Fi Internet connectivity service to their > customers. The location where Internet connectivity service via > Wi-Fi is to be provided is within the coverage area of a white space > master (e.g. Hotspot or Wide-Area/Rural network). The service > provider installs a white space slave device and connects it to the > Wi-Fi access point(s). Wi-Fi access points with an integrated white > space slave component may also be used. This deployment scenario is > typically characterized by a WS master/AP/BS providing local > coverage. The master/AP has a connection to the Internet and > provides Internet connectivity to slave devices that are within its > coverage area. The WS slave device is 'bridged' to a Wi-Fi network > thereby enabling Internet connectivity service to Wi-Fi devices. The > WS Master/AP/BS which has some form of Internet connectivity (wired > or wireless) queries the database and obtains available channel > information. It then provides service using those channels to slave > devices which are within its coverage area. > > Figure 6 shows an example deployment of this scenario. > > > \|/ white \|/ \|/ Wi-Fi \|/ > | space | | | > | | | |-|----| > |--------| |-|---------| |-|------|-| | Wi-Fi| > | | | Master | | Slave | | Dev | > |Internet|------| (AP/BS) | | Bridge | |------| > | | | | | to Wi-Fi | > |--------| |-----------| |----------| \|/ > | > |-|----| > | Wi-Fi| > | Dev | > |------| > > Figure 6: WS for backhaul > >The description of this deployment scenario is not well written, and the >figure does nothing to help. Aren't the Wi-fi devices supposed to be >connected to the slave, and then the slave talks to the master? This >needs some help. > >4.2.5. Rapid deployed network for emergency scenario > > ... This > approach does in no way imply such organizations for disaster relief > must compete on spectrum allocation with other white spaces users, > but they can. ... > >That sentence seems unnecessary. > >4.2.6. Mobility > >How does this use case differ architecturally from 4.2.1? Why isn't this >case just a subcase of 4.2.1, like 4.2.2? > > >4.2.7. Indoor Networking > >Isn't this just the same as 4.2.1 without geolocation? Again, seems like >it could be combined and shortened. > >5. Problem Statement > > In Figure 11, note that there could be multiple databases serving > white space devices. The databases are country specific since the > regulations and available spectrum may vary. > >Location specific, not country specific, right? It may be that multiple >countries share a database, or it may be that a single country has >multiple databases for sub-locales, right? The architecture doesn't >depend on "country". > >5.1. Global applicability > > The use of TV white space spectrum is currently approved by the FCC > in the United States. However regulatory bodies in other countries > are also considering similar use of available spectrum. ... > >Again, the mention of the regulatory bodies here is unnecessary as it >doesn't impact this protocol. > > 4. Address regulatory requirements - Each country is likely to have > regulations that are unique to that country. The messaging > interface needs to be flexible to accommodate the specific needs > of a regulatory body in the country where the white space device > is operating and connecting to the relevant database. > >I would rewrite this to say: "4. Flexible and extensible data structures >- Different databases are likely to have different requirements for the >kinds of data required for registration as well as the kinds of data >returned with available white space. For instance, different regulatory >bodies might require different information to be passed between the >database and the device accessing it." Again, don't make the regulatory >body part of the problem statement; the need to accommodate different >data is the requirement. > >5.4. Data model definition > > ... > Use of XML for specifying a data model is an attractive option. The > intent is to evaluate the best option that meets the need for use > between white space devices and databases. > >The mention of XML here is premature. Give it as one example (perhaps >including JSON as another) if you think you need such an example. > > >6. Requirements > >6.1. Normative Requirements > > D. Data Model Requirements: > > D.1: The Data Model MUST support specifying the location of the > WSD, the uncertainty in meters, the height & its > uncertainty, and confidence in percentage of the location > determination. ... > >"Location" in the above is ambiguous. You mean the "geographic >location", right? > > ...The Data Model MUST support both North > American Datum of 1983 and WGS84. > >Neither of these has a reference. Also, if NAD is really a requirement, >shouldn't there be others listed? > > D.2: The Data Model MUST support specifying the regulatory domain > and its corresponding data requirements. > >That is poorly written. I don't understand what needs to go in a >protocol from the above. Don't you just mean that the Data Model MUST be >extensible? > > D.3: The Data Model MUST support specifying an ID of the > transmitter device. This ID would contain the ID of the > transmitter device that has been certified by a regulatory > body for its regulatory domain. The Data Model MUST support > a device class. The Data Model MUST support specifying > information about the type of RAT of the transmitter device. > >What sort of data is an ID? You probably need to mention that. Also >"RAT" is undefined. > > P. Protocol Requirements: > > P.1: The protocol MUST provide a mechanism to enable WSD > discovery. In some environments, a listing of the approved > white space databases is maintained by the national > regulator. The protocol MUST support discovery of a > database using a listing approved by a national regulator. > >The "national regulator" portion of the requirement is not the >requirement. What is it about the list a national regulator provides >that is different, protocol-wise, from any other list from which the WSD >is discovered? > > P.3: The protocol MUST support determination of regulatory > domain governing its current location. > >I don't know what that requirement means. > > P.8: The protocol MUST support the master device registering > with the database. > >What is "registering" independent of authentication/authorization? > > P.10: The protocol MUST support a channel query request from the > master device to the database. The channel query request > message MUST include parameters as required by local > regulatory requirement. These parameters MAY include any > of the parameters and attributes required to be supported > in the Data Model Requirements. > >Strike the second sentence. Unnecessary. > >6.2. Non-normative requirements > >I don't understand what a non-normative requirement is. Are these just >pre-requisites? Please explain. > >I'm guessing that the 2119 language in this section is misused, but let >me understand what the section is meant to say first. > > O.4: The master device MUST implement at least one connection > method to access the database. The master device MAY contact > a database directly for service (e.g. as defined by FCC) or > the master device MAY contact a listing server first followed > by contact to a database (e.g. as defined by Ofcom). > >References needed for FCC and Ofcom if you insist on noting them. (I >don't think they're necessary.) > > O.5: The master device MUST obtain an indication about the > regulatory domain governing operation at its current location, > i.e. the master device MUST know if it operates under > regulations from FCC, Ofcom, etc... > >That would be completely out of band, correct? > > >-- >Pete Resnick >Qualcomm Technologies, Inc. - +1 (858)651-4478 > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Oct 29 07:30:39 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 75BD421F8557 for ; Mon, 29 Oct 2012 07:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] 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 QfkjpP5ibFlt for ; Mon, 29 Oct 2012 07:30:38 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5832521F8526 for ; Mon, 29 Oct 2012 07:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1351520843; x=1666878715; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=YxzdyyCX422aae0XkdRF1z/zxaIpGggdPoh4aUa4CWY=; b=Zcm0MrK0j4TVmw0JvyCBMFWd0XaDXPkhUgKwhQscDVzLSFLBILBzMu3G9JYAQM KlOl6pEAJRO3XAc23R0wr/jg== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.12705184; Mon, 29 Oct 2012 10:27:21 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 29 Oct 2012 10:30:32 -0400 From: "Rosen, Brian" To: Vincent Chen Date: Mon, 29 Oct 2012 10:30:31 -0400 Thread-Topic: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? Thread-Index: Ac214fNwN7FM7wylRs6rLxnOJg6ETw== Message-ID: <4D19E2D7-F659-4EC0-BB31-7FD65CE51C57@neustar.biz> References: <5076FFB7.4030701@blindcreek.com> <50783263.6060601@blindcreek.com> <507880D5.5010501@blindcreek.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760206EB19@008-AM1MPN1-007.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: s9lcZlrhAkgoFw52W/HsQg== Content-Type: multipart/alternative; boundary="_000_4D19E2D7F6594EC0BB317FD65CE51C57neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] PAWS Protocol: Should "Device location" really be "Antenna location"? 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, 29 Oct 2012 14:30:39 -0000 --_000_4D19E2D7F6594EC0BB317FD65CE51C57neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think several participants have asked that the "device location" to be ex= pressed as lat/lon, with optional height, and the antenna to be specified a= s height above ground. I think that is the most practical way to obtain th= e data, and is what the current regulations require. I think it is a mista= ke to try to specify radiation center as the input variable because it conf= lates what you know. The device itself or an installer can measure the loc= ation of the device. GPS is not accurate with respect to height in most ca= ses, but it would be forward looking to allow device location to include he= ight. What we do now is use a terrain database to determine height of the = device. The antenna height is a measured quantity. It's often fixed, or t= he installer knows it. It's the height, not the radiation center, that is = measured. Brian On Oct 28, 2012, at 3:25 PM, Vincent Chen > wrote: All, I'd like to address this at the F2F as an open issue, though I think we are= mostly in agreement. The only point of discussion seems to be how to represent the (lat, lon, he= ight) in the protocol messages. 1. In the interest of avoiding ambiguity in the "generic" Device-to-Databas= e protocol, it still seems more precise for the device to report (only) the location of its antenn= a's radiation center: (lat, lon, height) with associated uncertainties, etc, and where height is optional for som= e types of devices. That's the only relevant location when determining available spectrum. It= seems that that's the intent of the FCC rules, even though the text does say "device locati= on". 2. We probably should allow automated GPS-reporting of the location of the = antenna's radiation center. Since GPS cannot report height above ground, the protocol should= allow the height to be entered as: - Height relative to ground/surface (manually entered by installer) - Height relative to mean sea level (reported by GPS) A regulatory domain could restrict to be only one of these. -vince On Tue, Oct 23, 2012 at 2:23 PM, > wrote: Yes, I also think that separating the device location and antenna parameter= s is a good approach. This is what the requirements document requires too. So, send the device=92s (lon, lat, alt) location with related uncertainties= and datum; and separately, the antenna parameters. The DB can then combine= them, if it needs to, to provide the list of available channels. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_4D19E2D7F6594EC0BB317FD65CE51C57neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think several parti= cipants have asked that the "device location" to be expressed as lat/lon, w= ith optional height, and the antenna to be specified as height above ground= .  I think that is the most practical way to obtain the data, and is w= hat the current regulations require.  I think it is a mistake to try t= o specify radiation center as the input variable because it conflates what = you know.  The device itself or an installer can measure the location = of the device.  GPS is not accurate with respect to height in most cas= es, but it would be forward looking to allow device location to include hei= ght.  What we do now is use a terrain database to determine height of = the device.  The antenna height is a measured quantity.  It's oft= en fixed, or the installer knows it.  It's the height, not the radiati= on center, that is measured.  

Brian


On Oct 28, 2012, at 3:25 PM, Vincent Chen <vchen@google.com> wrote:

All,

I'd like to address this at the F2F as an open issue, though I think= we are mostly in agreement.
The only point of discussion seems t= o be how to represent the (lat, lon, height) in the protocol messages.

1. In the interest of avoiding ambiguity in the "generi= c" Device-to-Database protocol, it still seems
    more= precise for the device to report (only) the location of its antenna's radi= ation center:

    (lat, lon, height)

   with associated uncertainties, etc, and where height is opt= ional for some types of devices.

  That's the= only relevant location when determining available spectrum. It seems that = that's
  the intent of the FCC rules, even though the text does say "dev= ice location".

2. We probably should allow automat= ed GPS-reporting of the location of the antenna's radiation 
   center. Since GPS cannot report height above ground, the = protocol should allow the height to be
   entered as:

   - Height relative to ground/surface (m= anually entered by installer)

= --_000_4D19E2D7F6594EC0BB317FD65CE51C57neustarbiz_-- From presnick@qti.qualcomm.com Mon Oct 29 11:20:31 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 E9D5A21F86CD for ; Mon, 29 Oct 2012 11:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.142 X-Spam-Level: X-Spam-Status: No, score=-100.142 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, SARE_SUB_OBFU_Q1=0.227, 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 ysG+dpdGQjY8 for ; Mon, 29 Oct 2012 11:20:31 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9821F86C3 for ; Mon, 29 Oct 2012 11:20:30 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6880"; a="2795078" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 29 Oct 2012 11:06:29 -0700 X-IronPort-AV: E=Sophos;i="4.80,673,1344236400"; d="scan'208";a="356324512" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Oct 2012 11:20:29 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 29 Oct 2012 11:20:29 -0700 Message-ID: <508EC8EA.6010602@qti.qualcomm.com> Date: Mon, 29 Oct 2012 13:20:26 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Peter Stanforth References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "paws@ietf.org" Subject: Re: [paws] AD Review of draft-ietf-paws-problem-stmt-usecases-rqmts 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, 29 Oct 2012 18:20:32 -0000 On 10/29/12 7:53 AM, Peter Stanforth wrote: > I don't think we can ignore the "Regulator". You may not need to know what > a radio does or how it works but the database is logically tied to a > Regulator. > In all the cases we are aware of the Database will either be operated by > the Regulator or by an entity (or entities) authorized by a Regulator. > Spectrum use is tightly regulated - the regulator makes the rules. There > are many examples of things that are included in this protocol that you > could argue would not normally be required for a protocol. They are only > there because Regulators require them. I think you've missed the point. It is certainly clear that we need to take into account requirements that come from regulators. But it is the requirements that are important, not where they come from. For example, in other IETF protocols, we may have requirements from industry that certain things are NETCONF manageable. That might not normally be required for a protocol, but because they are required by a particular industry, they are requirements for our protocol design. That doesn't mean that we say, "MUST follow all requirements of the widget industry". We say, "MUST be NETCONF manageable." The industry is irrelevant to the document; it's the requirement that matters. Concentrating on the regulator also obfuscates real requirements. Regulatory language is almost never in appropriate engineering terms. People must figure out what the engineering requirement is from the regulatory language. Conversely, if a regulatory statement seems to indicate something that is contrary to the correct engineering outcome, we have to figure out how to do the engineering with the requirement or get the requirement fixed. Knowing it comes from a regulator doesn't help us. There is nothing special, from a protocol engineering perspective, that the requirements come from a regulator. Having references to the regulator is either inappropriate or is hiding missing information that we need to have in the document. Of the items that I specifically pointed out in the document, I can find nothing that mentioning the regulator adds to the text. If you can point one out that makes a difference, please do. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From Gabor.Bajko@nokia.com Wed Oct 31 16:20: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 C130C21F889C for ; Wed, 31 Oct 2012 16:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] 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 muZ+bQuGTdQ6 for ; Wed, 31 Oct 2012 16:20:15 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 24A7F21F889B for ; Wed, 31 Oct 2012 16:20:14 -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 q9VNK84f019476 for ; Thu, 1 Nov 2012 01:20:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Nov 2012 01:20:08 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.183]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0309.003; Thu, 1 Nov 2012 00:20:07 +0100 From: To: Thread-Topic: agenda uploaded Thread-Index: Ac23viR+72PYyu8ARv6AW2uDaP3obA== Date: Wed, 31 Oct 2012 23:20:06 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602073D7A@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.117.228] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D7A008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2012 23:20:08.0029 (UTC) FILETIME=[443F70D0:01CDB7BE] X-Nokia-AV: Clean Subject: [paws] agenda uploaded 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, 31 Oct 2012 23:20:15 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D7A008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/85/agenda/agenda-85-paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D7A008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/85/agenda/agenda-85-paws

 

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D7A008AM1MPN1007mg_-- From Gabor.Bajko@nokia.com Wed Oct 31 16:23: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 6421D21F8490 for ; Wed, 31 Oct 2012 16:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.744 X-Spam-Level: X-Spam-Status: No, score=-4.744 tagged_above=-999 required=5 tests=[AWL=1.854, 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 wcZFEFDckinX for ; Wed, 31 Oct 2012 16:23:00 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 826AB21F8465 for ; Wed, 31 Oct 2012 16:23:00 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9VNMwDN021658 for ; Thu, 1 Nov 2012 01:22:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Nov 2012 01:22:58 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.183]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0309.003; Thu, 1 Nov 2012 00:22:57 +0100 From: To: Thread-Topic: remote participation Thread-Index: Ac23vmTmshqODAEESiWt76RoQI/1OA== Date: Wed, 31 Oct 2012 23:22:57 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602073D92@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.117.228] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D92008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Oct 2012 23:22:58.0441 (UTC) FILETIME=[A9D23F90:01CDB7BE] X-Nokia-AV: Clean Subject: [paws] remote participation 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, 31 Oct 2012 23:23:01 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D92008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, For those of you who can't make it to Atlanta, there will be remote partici= pation possibility. As usual, we'll use Meetecho for video and screen shari= ng, and skype for audio. I'll send out the link and other info the day before the meeting. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D92008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

For those of you who can’t make it to Atlanta,= there will be remote participation possibility. As usual, we’ll use = Meetecho for video and screen sharing, and skype for audio.

 

I’ll send out the link and other info the day = before the meeting.

 

-     &= nbsp;    Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47602073D92008AM1MPN1007mg_--