From stpeter@stpeter.im Tue May 3 05:36:39 2011 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 81E37E07C5; Tue, 3 May 2011 05:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHBluWfrJPIB; Tue, 3 May 2011 05:36:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4288FE06D8; Tue, 3 May 2011 05:36:38 -0700 (PDT) Received: from squire.local (unknown [144.254.202.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E0BE940126; Tue, 3 May 2011 06:36:36 -0600 (MDT) Message-ID: <4DBFF6D2.3040705@stpeter.im> Date: Tue, 03 May 2011 14:36:34 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: paws@ietf.org References: <20110419165634.CD24CE07CF@ietfc.amsl.com> In-Reply-To: <20110419165634.CD24CE07CF@ietfc.amsl.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070006070308060703080203" Cc: iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 12:36:39 -0000 This is a cryptographically signed message in MIME format. --------------ms070006070308060703080203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, at the IESG retreat just now we discussed the PAWS charter. The basic feedback is as follows: - it seems appropriate to do this work at the IETF - the Applications Area seems like the right area within the IETF - it would be best to prefer re-use of existing IETF protocols - we need to clean up the charter text here and there I've provided specific text suggestions below. Discussion is welcome. On 4/19/11 6:56 PM, IESG Secretary wrote: > A new IETF working group has been proposed. The IESG has not made any > determination as yet. The following draft charter was submitted, and is= > provided for informational purposes only. Please send your comments to = the > IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. = =20 > =20 >=20 > Protocol to Access White Space database (paws) > ------------------------------------------------ > Current Status: Proposed Working Group > Last updated: 2011-04-14 >=20 > Chairs: > TBD >=20 > Area Directors: > TBD >=20 > Area Advisor: > TBD >=20 > Mailing lists: > Address: paws@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/paws > Archive: http://www.ietf.org/mail-archive/web/paws/ >=20 > Description of Working Group: >=20 > Governments around the world continue to search for new pieces of radio= > spectrum which can be used by the expanding wireless communications > industry to provide more services in the usable spectrum. The concept > of allowing secondary transmissions (licensed or unlicensed) in > frequencies allocated to a primary user is a technique to "unlock" > existing spectrum for new use. An obvious requirement is that these > secondary transmissions do not interfere with the primary use of the > spectrum. Often, in a given physical location, the primary user(s) may > not be using the entire band allocated to them. The available spectrum > for a secondary use would then depend on the location of the secondary > user. The primary user may have a schedule when it uses the spectrum, > which may be available for secondary use outside that schedule. The > fundamental issue is how to determine for a specific location and > specific time, if any of the primary spectrum is available for secondar= y > use. One simple mechanism is to use a geospatial database that records > protected contours for primary users, and require the secondary users t= o > check the database prior to selecting what part of the spectrum they > use. Such databases could be available on the Internet for query by > users. >=20 > In a typical implementation of geolocation and database to access TV > white space, a radio is configured with, or has the capability to > determine its location in latitude and longitude. At power-on, before > the device can transmit or use any of the spectrum set aside for > secondary use, the device must identify the relevant database to query,= > contact the database, provide its geolocation and receive in return a > list of unoccupied or "white space" spectrum (for example, in a TV > White space implementation, the list of available channels at that > location). The device can then select one of the channels from the list= > and begin to transmit and receive on the selected channel. The device > must query the database subsequently on a periodic basis for a list of > unoccupied channels based on certain conditions, e.g. a fixed amount of= > time has passed or the device has changed location beyond a specified > threshold. >=20 > The databases are expected to be reachable via the Internet and the > devices querying these databases are expected to have some form of > Internet connectivity, directly or indirectly. The databases may be > country specific since the available spectrum and regulations may vary,= > but the fundamental operation of the protocol should be country > independent, thus extensibility of data structures will be required. Th= e > solution will not be tied to any specific spectrum, country, or > phy/mac/air interface but may incorporate relevant aspects of these as > needed for proper operation. >=20 > The proposed working group will : Remove "proposed". Add: - define the requirements for querying a white space database > - standardize a protocol for querying the database, which includes a > location sensitive database discovery mechanism and security for the > protocol, and application services. > - Standardize the data structure to be carried by the query > protocol. >=20 > The protocol must protect both the channel enablement process and the > privacy of users. Robust security mechanisms are required to prevent: > device identity spoofing, modification of device requests, modification= > of channel enablement information, impersonation of registered database= > services and unauthorized disclosure of a users location. >=20 > Existing IETF location data structures and privacy mechanisms may be > considered for use. The WG will also investigate the need for other > mechanisms and related protocols to the White Space DB. Change to: The working group will prefer to use existing IETF technologies and privacy mechanisms where possible. Some IESG members were concerned about the open-ended nature of this statement: The WG will also investigate the need for other mechanisms and related protocols to the White Space DB. Is that really needed? Can it simply be removed? > The Working Group will set up and maintain appropriate contact and > liaison with other relevant standards bodies and groups, including IEEE= > 802.11af and IEEE 802.22 to begin with. The working group may also > consider input from regulatory entities that are involved in the > specification of the rules for secondary use of spectrum in specific > bands. >=20 > Goals and Milestones >=20 > Sep 2011 Submit 'Requirements and Framework' to the IESG for > publication as Informational Change "Requirements and Framework" to "Requirements for Querying a White Space Database". > Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to > the IESG for publication as Proposed Standard >=20 > Apr 2012 Submit 'Data Model for Whitespace query protocol' to the > IESG for publication as Proposed Standard Change "Model" to "Structure". (Also change "Whitespace" to "White Space"?) Other IESG members might have additional comments. I might even have further comments after the IESG meeting is finished. :) Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070006070308060703080203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUw MzEyMzYzNFowIwYJKoZIhvcNAQkEMRYEFG8rj5owqHwYisZXMK62+CDrGZypMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBD4flOnYvC+qpmzWGJMVltzzKzXFFiqahXwVokJovc7xxt6iymIke9TjKV gO61xqLa9cdYjJjANv+1xNGo/kH0HmERUfILC73NDwL4drijvAg9xWfa+P2W49XEBeVhazPV k7R0gir/Vu2biSp3dkwQRa+sZlqfxdV6mzcGfc1wcVMdBtymKjP5ZgUF6mj9/biKxoavjFWX dq0FnPYEsHM/9Kd209dvtsEdAmUhXjRuLdSP9tUFNV6Qo4yNn8S+tXNej6Y5KNE+H3Aj3dms ptkQDPIUY0/F1IiAxUBMkX9N3PKDMs2rGFVA0FobsF6yQj/U4+rMopbLyhFaxqQihk5wAAAA AAAA --------------ms070006070308060703080203-- From stephen.farrell@cs.tcd.ie Tue May 3 05:55:03 2011 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 75619E081A; Tue, 3 May 2011 05:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 IGKw8rjJYSDM; Tue, 3 May 2011 05:55:02 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A89FFE0808; Tue, 3 May 2011 05:55:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DF4CE171C19; Tue, 3 May 2011 13:54:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1304427299; bh=FVLzZSyjmQizRe yAAVibd2YozT4h8VDjbm73bndRRIM=; b=rsP/l7pewaMNUdHN2CfZeZQOt4lyav TrEeMqoAms9riOzPx7YQAfQGCtEWMzdcguDpLFxHaqZbOXaNn1QsLnFWd89bBAM/ IxNALEIjVk775AUrL73CqquP8jjle0XDtJjgEQI5kfoRYyV00LrB6uIBMsZ7KDab Ma4yH4ZekQXZuh3YxNEAh4om/Ug5KLUpAJY2OPyKbdgnZwQ9OwI8fdsTsgicLnmZ FjTBFlKy+R+84uADeo8hzPKDumRtgjimUI0JgBSdif5koItWM25jPTgQ8RIWMt8A /heaiCFBoO0bMonzdTTmKYlbIM6ENn+NzHuFcptNdDAr9nYdb4N9/Ipg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id UHeWBGeWgEjb; Tue, 3 May 2011 13:54:59 +0100 (IST) Received: from [144.254.113.64] (dhcp-guest-ams5-144-254-113-64.cisco.com [144.254.113.64]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 172D2171C1A; Tue, 3 May 2011 13:54:58 +0100 (IST) Message-ID: <4DBFFB20.1080003@cs.tcd.ie> Date: Tue, 03 May 2011 13:54:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Peter Saint-Andre References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> In-Reply-To: <4DBFF6D2.3040705@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 12:55:03 -0000 I made a comment on the security bit that lead to a thread with some suggested changes. [1] I think incorporating that language would be good. Its a bit scattered over a couple of messages, but I think I was ok with all the variants. I've tried to reconstitute this below start from Brian's suggested change. OLD: The protocol must protect both the channel enablement process and the privacy of users. Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services and unauthorized disclosure of a users location. NEW: The protocol must protect both the channel enablement process and the privacy of users, and prevent unauthorized disclosure of a user's location. In some circumstances robust security mechanisms will be required to be used to prevent device identity spoofing, modification of device requests, modification of channel enablement information and impersonation of registered database services. Such security requirements may be in the scope of regulations which can vary between countries. The WG MUST consider these security aspects in the design of the protocol with sufficient flexibility to meet the needs of differing regulations/deployments. S. [1] http://www.ietf.org/mail-archive/web/paws/current/msg00159.html On 03/05/11 13:36, Peter Saint-Andre wrote: > Folks, at the IESG retreat just now we discussed the PAWS charter. The > basic feedback is as follows: > > - it seems appropriate to do this work at the IETF > > - the Applications Area seems like the right area within the IETF > > - it would be best to prefer re-use of existing IETF protocols > > - we need to clean up the charter text here and there > > I've provided specific text suggestions below. Discussion is welcome. > > On 4/19/11 6:56 PM, IESG Secretary wrote: >> A new IETF working group has been proposed. The IESG has not made any >> determination as yet. The following draft charter was submitted, and is >> provided for informational purposes only. Please send your comments to the >> IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. >> >> >> Protocol to Access White Space database (paws) >> ------------------------------------------------ >> Current Status: Proposed Working Group >> Last updated: 2011-04-14 >> >> Chairs: >> TBD >> >> Area Directors: >> TBD >> >> Area Advisor: >> TBD >> >> Mailing lists: >> Address: paws@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >> Archive: http://www.ietf.org/mail-archive/web/paws/ >> >> Description of Working Group: >> >> Governments around the world continue to search for new pieces of radio >> spectrum which can be used by the expanding wireless communications >> industry to provide more services in the usable spectrum. The concept >> of allowing secondary transmissions (licensed or unlicensed) in >> frequencies allocated to a primary user is a technique to "unlock" >> existing spectrum for new use. An obvious requirement is that these >> secondary transmissions do not interfere with the primary use of the >> spectrum. Often, in a given physical location, the primary user(s) may >> not be using the entire band allocated to them. The available spectrum >> for a secondary use would then depend on the location of the secondary >> user. The primary user may have a schedule when it uses the spectrum, >> which may be available for secondary use outside that schedule. The >> fundamental issue is how to determine for a specific location and >> specific time, if any of the primary spectrum is available for secondary >> use. One simple mechanism is to use a geospatial database that records >> protected contours for primary users, and require the secondary users to >> check the database prior to selecting what part of the spectrum they >> use. Such databases could be available on the Internet for query by >> users. >> >> In a typical implementation of geolocation and database to access TV >> white space, a radio is configured with, or has the capability to >> determine its location in latitude and longitude. At power-on, before >> the device can transmit or use any of the spectrum set aside for >> secondary use, the device must identify the relevant database to query, >> contact the database, provide its geolocation and receive in return a >> list of unoccupied or "white space" spectrum (for example, in a TV >> White space implementation, the list of available channels at that >> location). The device can then select one of the channels from the list >> and begin to transmit and receive on the selected channel. The device >> must query the database subsequently on a periodic basis for a list of >> unoccupied channels based on certain conditions, e.g. a fixed amount of >> time has passed or the device has changed location beyond a specified >> threshold. >> >> The databases are expected to be reachable via the Internet and the >> devices querying these databases are expected to have some form of >> Internet connectivity, directly or indirectly. The databases may be >> country specific since the available spectrum and regulations may vary, >> but the fundamental operation of the protocol should be country >> independent, thus extensibility of data structures will be required. The >> solution will not be tied to any specific spectrum, country, or >> phy/mac/air interface but may incorporate relevant aspects of these as >> needed for proper operation. >> >> The proposed working group will : > > Remove "proposed". > > Add: > > - define the requirements for querying a white space database > >> - standardize a protocol for querying the database, which includes a >> location sensitive database discovery mechanism and security for the >> protocol, and application services. >> - Standardize the data structure to be carried by the query >> protocol. >> >> The protocol must protect both the channel enablement process and the >> privacy of users. Robust security mechanisms are required to prevent: >> device identity spoofing, modification of device requests, modification >> of channel enablement information, impersonation of registered database >> services and unauthorized disclosure of a users location. >> >> Existing IETF location data structures and privacy mechanisms may be >> considered for use. The WG will also investigate the need for other >> mechanisms and related protocols to the White Space DB. > > Change to: > > The working group will prefer to use existing IETF technologies > and privacy mechanisms where possible. > > Some IESG members were concerned about the open-ended nature of this > statement: > > The WG will also investigate the need for other mechanisms and > related protocols to the White Space DB. > > Is that really needed? Can it simply be removed? > >> The Working Group will set up and maintain appropriate contact and >> liaison with other relevant standards bodies and groups, including IEEE >> 802.11af and IEEE 802.22 to begin with. The working group may also >> consider input from regulatory entities that are involved in the >> specification of the rules for secondary use of spectrum in specific >> bands. >> >> Goals and Milestones >> >> Sep 2011 Submit 'Requirements and Framework' to the IESG for >> publication as Informational > > Change "Requirements and Framework" to "Requirements for Querying a > White Space Database". > >> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >> the IESG for publication as Proposed Standard >> >> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >> IESG for publication as Proposed Standard > > Change "Model" to "Structure". > > (Also change "Whitespace" to "White Space"?) > > Other IESG members might have additional comments. I might even have > further comments after the IESG meeting is finished. :) > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > From brian.rosen@neustar.biz Tue May 3 06:04:36 2011 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 7B607E0824; Tue, 3 May 2011 06:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 gqqDKuE7ieO4; Tue, 3 May 2011 06:04:35 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1D824E0807; Tue, 3 May 2011 06:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1304427870; x=1619765809; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=zK6D71eF66yUvo/Z6I9Of kATKUTPyzirrYTRb/hhypM=; b=R9z/1eoYQ6LNiN2kOoZiQQs1320neI6+kAkqf IJY5m5DfV109uW/wqzxHWEHs2rlAor6xjnSy1CJX2OSaukejQ== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.36952117; Tue, 03 May 2011 09:04:28 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 3 May 2011 09:04:28 -0400 From: "Rosen, Brian" To: Peter Saint-Andre Date: Tue, 3 May 2011 09:04:26 -0400 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwJkqI2uB8L3vhLTNeTumYfkBUTuA== Message-ID: References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> In-Reply-To: <4DBFF6D2.3040705@stpeter.im> 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: D3gp4oyJZ9uBe7CiwQL0zw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 13:04:36 -0000 I have two comments: I don't recall ever having been requested to "prefer to use existing IETF t= echnologies" before. Is there something special about this effort that war= rants this language? Usually, we just consider them. I suspect we actuall= y do "prefer" in many cases, but this request stands out in my mind and I'm= trying to understand why this is needed. Also, some push back on "Requirements and Framework" to "Requirements". Th= is implies the IESG sees no need for a framework document. We thought it m= ight be helpful, but didn't warrant a separate document, so we suggested co= mbining framework and requirements into one document. In the discussions we have had, there are other needs to build a whitespace= ecosystem. Here in the U.S. for example, we need automated ways to provis= ion the database of protected entities that allows sharing of data among co= mpeting database providers. That is the origin of the "other mechanisms an= d protocols" part. We can recharter to get those in AFTER the database dis= covery and query mechanisms are worked out, so I don't have a problem with = deleting that language from the charter now. Brian On May 3, 2011, at 8:36 AM, Peter Saint-Andre wrote: > Folks, at the IESG retreat just now we discussed the PAWS charter. The > basic feedback is as follows: >=20 > - it seems appropriate to do this work at the IETF >=20 > - the Applications Area seems like the right area within the IETF >=20 > - it would be best to prefer re-use of existing IETF protocols >=20 > - we need to clean up the charter text here and there >=20 > I've provided specific text suggestions below. Discussion is welcome. >=20 > On 4/19/11 6:56 PM, IESG Secretary wrote: >> A new IETF working group has been proposed. The IESG has not made any >> determination as yet. The following draft charter was submitted, and is >> provided for informational purposes only. Please send your comments to t= he >> IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. = =20 >>=20 >>=20 >> Protocol to Access White Space database (paws) >> ------------------------------------------------ >> Current Status: Proposed Working Group >> Last updated: 2011-04-14 >>=20 >> Chairs: >> TBD >>=20 >> Area Directors: >> TBD >>=20 >> Area Advisor: >> TBD >>=20 >> Mailing lists: >> Address: paws@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >> Archive: http://www.ietf.org/mail-archive/web/paws/ >>=20 >> Description of Working Group: >>=20 >> Governments around the world continue to search for new pieces of radio >> spectrum which can be used by the expanding wireless communications >> industry to provide more services in the usable spectrum. The concept >> of allowing secondary transmissions (licensed or unlicensed) in >> frequencies allocated to a primary user is a technique to "unlock" >> existing spectrum for new use. An obvious requirement is that these >> secondary transmissions do not interfere with the primary use of the >> spectrum. Often, in a given physical location, the primary user(s) may >> not be using the entire band allocated to them. The available spectrum >> for a secondary use would then depend on the location of the secondary >> user. The primary user may have a schedule when it uses the spectrum, >> which may be available for secondary use outside that schedule. The >> fundamental issue is how to determine for a specific location and >> specific time, if any of the primary spectrum is available for secondary >> use. One simple mechanism is to use a geospatial database that records >> protected contours for primary users, and require the secondary users to >> check the database prior to selecting what part of the spectrum they >> use. Such databases could be available on the Internet for query by >> users. >>=20 >> In a typical implementation of geolocation and database to access TV >> white space, a radio is configured with, or has the capability to >> determine its location in latitude and longitude. At power-on, before >> the device can transmit or use any of the spectrum set aside for >> secondary use, the device must identify the relevant database to query, >> contact the database, provide its geolocation and receive in return a >> list of unoccupied or "white space" spectrum (for example, in a TV >> White space implementation, the list of available channels at that >> location). The device can then select one of the channels from the list >> and begin to transmit and receive on the selected channel. The device >> must query the database subsequently on a periodic basis for a list of >> unoccupied channels based on certain conditions, e.g. a fixed amount of >> time has passed or the device has changed location beyond a specified >> threshold. >>=20 >> The databases are expected to be reachable via the Internet and the >> devices querying these databases are expected to have some form of >> Internet connectivity, directly or indirectly. The databases may be >> country specific since the available spectrum and regulations may vary, >> but the fundamental operation of the protocol should be country >> independent, thus extensibility of data structures will be required. The >> solution will not be tied to any specific spectrum, country, or >> phy/mac/air interface but may incorporate relevant aspects of these as >> needed for proper operation. >>=20 >> The proposed working group will : >=20 > Remove "proposed". >=20 > Add: >=20 > - define the requirements for querying a white space database >=20 >> - standardize a protocol for querying the database, which includes a >> location sensitive database discovery mechanism and security for the >> protocol, and application services. >> - Standardize the data structure to be carried by the query >> protocol. >>=20 >> The protocol must protect both the channel enablement process and the >> privacy of users. Robust security mechanisms are required to prevent: >> device identity spoofing, modification of device requests, modification >> of channel enablement information, impersonation of registered database >> services and unauthorized disclosure of a users location. >>=20 >> Existing IETF location data structures and privacy mechanisms may be >> considered for use. The WG will also investigate the need for other >> mechanisms and related protocols to the White Space DB. >=20 > Change to: >=20 > The working group will prefer to use existing IETF technologies > and privacy mechanisms where possible. >=20 > Some IESG members were concerned about the open-ended nature of this > statement: >=20 > The WG will also investigate the need for other mechanisms and > related protocols to the White Space DB. >=20 > Is that really needed? Can it simply be removed? >=20 >> The Working Group will set up and maintain appropriate contact and >> liaison with other relevant standards bodies and groups, including IEEE >> 802.11af and IEEE 802.22 to begin with. The working group may also >> consider input from regulatory entities that are involved in the >> specification of the rules for secondary use of spectrum in specific >> bands. >>=20 >> Goals and Milestones >>=20 >> Sep 2011 Submit 'Requirements and Framework' to the IESG for >> publication as Informational >=20 > Change "Requirements and Framework" to "Requirements for Querying a > White Space Database". >=20 >> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >> the IESG for publication as Proposed Standard >>=20 >> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >> IESG for publication as Proposed Standard >=20 > Change "Model" to "Structure". >=20 > (Also change "Whitespace" to "White Space"?) >=20 > Other IESG members might have additional comments. I might even have > further comments after the IESG meeting is finished. :) >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 > From brian.rosen@neustar.biz Tue May 3 06:05:37 2011 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 00E48E0816; Tue, 3 May 2011 06:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Uc5WiRUmxnvk; Tue, 3 May 2011 06:05:36 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 98E29E0810; Tue, 3 May 2011 06:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1304427927; x=1619785617; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=4Kcwpkl7jKAWaJi1qt6ht eXR482zU8e9l0AtpfbSMoY=; b=TP+QjT+PLY/sbaXtMNMQNzQejKIH/t+cPjMyB /40Sawe9WM1ACvq5XZeG/oSeE2KVLIeTcbo5Y6GCtT+ITCMrg== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.38595248; Tue, 03 May 2011 09:05:26 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 3 May 2011 09:05:26 -0400 From: "Rosen, Brian" To: Stephen Farrell Date: Tue, 3 May 2011 09:05:25 -0400 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwJksTx2ndmcKPRTnyDd9ndl47D0w== Message-ID: References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> <4DBFFB20.1080003@cs.tcd.ie> In-Reply-To: <4DBFFB20.1080003@cs.tcd.ie> 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: UTEkrK7zNUYuKae1ail+Jg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 13:05:37 -0000 I am fine with this language change. Brian On May 3, 2011, at 8:54 AM, Stephen Farrell wrote: >=20 > I made a comment on the security bit that lead to a thread with > some suggested changes. [1] >=20 > I think incorporating that language would be good. Its a bit > scattered over a couple of messages, but I think I was ok with > all the variants. I've tried to reconstitute this below > start from Brian's suggested change. >=20 > OLD: >=20 > The protocol must protect both the channel enablement process and the > privacy of users. Robust security mechanisms are required to prevent: > device identity spoofing, modification of device requests, modification > of channel enablement information, impersonation of registered database > services and unauthorized disclosure of a users location. >=20 > NEW: >=20 > The protocol must protect both the channel enablement process and > the privacy of users, and prevent unauthorized disclosure of a > user's location. In some circumstances robust security > mechanisms will be required to be used to prevent device identity > spoofing, modification of device requests, modification of channel > enablement information and impersonation of registered database > services. Such security requirements may be in the scope of > regulations which can vary between countries. The WG MUST > consider these security aspects in the design of the protocol > with sufficient flexibility to meet the needs of differing > regulations/deployments. >=20 > S. >=20 > [1] http://www.ietf.org/mail-archive/web/paws/current/msg00159.html >=20 > On 03/05/11 13:36, Peter Saint-Andre wrote: >> Folks, at the IESG retreat just now we discussed the PAWS charter. The >> basic feedback is as follows: >>=20 >> - it seems appropriate to do this work at the IETF >>=20 >> - the Applications Area seems like the right area within the IETF >>=20 >> - it would be best to prefer re-use of existing IETF protocols >>=20 >> - we need to clean up the charter text here and there >>=20 >> I've provided specific text suggestions below. Discussion is welcome. >>=20 >> On 4/19/11 6:56 PM, IESG Secretary wrote: >>> A new IETF working group has been proposed. The IESG has not made any >>> determination as yet. The following draft charter was submitted, and is >>> provided for informational purposes only. Please send your comments to = the >>> IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. = =20 >>>=20 >>>=20 >>> Protocol to Access White Space database (paws) >>> ------------------------------------------------ >>> Current Status: Proposed Working Group >>> Last updated: 2011-04-14 >>>=20 >>> Chairs: >>> TBD >>>=20 >>> Area Directors: >>> TBD >>>=20 >>> Area Advisor: >>> TBD >>>=20 >>> Mailing lists: >>> Address: paws@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >>> Archive: http://www.ietf.org/mail-archive/web/paws/ >>>=20 >>> Description of Working Group: >>>=20 >>> Governments around the world continue to search for new pieces of radio >>> spectrum which can be used by the expanding wireless communications >>> industry to provide more services in the usable spectrum. The concept >>> of allowing secondary transmissions (licensed or unlicensed) in >>> frequencies allocated to a primary user is a technique to "unlock" >>> existing spectrum for new use. An obvious requirement is that these >>> secondary transmissions do not interfere with the primary use of the >>> spectrum. Often, in a given physical location, the primary user(s) may >>> not be using the entire band allocated to them. The available spectrum >>> for a secondary use would then depend on the location of the secondary >>> user. The primary user may have a schedule when it uses the spectrum, >>> which may be available for secondary use outside that schedule. The >>> fundamental issue is how to determine for a specific location and >>> specific time, if any of the primary spectrum is available for secondar= y >>> use. One simple mechanism is to use a geospatial database that records >>> protected contours for primary users, and require the secondary users t= o >>> check the database prior to selecting what part of the spectrum they >>> use. Such databases could be available on the Internet for query by >>> users. >>>=20 >>> In a typical implementation of geolocation and database to access TV >>> white space, a radio is configured with, or has the capability to >>> determine its location in latitude and longitude. At power-on, before >>> the device can transmit or use any of the spectrum set aside for >>> secondary use, the device must identify the relevant database to query, >>> contact the database, provide its geolocation and receive in return a >>> list of unoccupied or "white space" spectrum (for example, in a TV >>> White space implementation, the list of available channels at that >>> location). The device can then select one of the channels from the list >>> and begin to transmit and receive on the selected channel. The device >>> must query the database subsequently on a periodic basis for a list of >>> unoccupied channels based on certain conditions, e.g. a fixed amount of >>> time has passed or the device has changed location beyond a specified >>> threshold. >>>=20 >>> The databases are expected to be reachable via the Internet and the >>> devices querying these databases are expected to have some form of >>> Internet connectivity, directly or indirectly. The databases may be >>> country specific since the available spectrum and regulations may vary, >>> but the fundamental operation of the protocol should be country >>> independent, thus extensibility of data structures will be required. Th= e >>> solution will not be tied to any specific spectrum, country, or >>> phy/mac/air interface but may incorporate relevant aspects of these as >>> needed for proper operation. >>>=20 >>> The proposed working group will : >>=20 >> Remove "proposed". >>=20 >> Add: >>=20 >> - define the requirements for querying a white space database >>=20 >>> - standardize a protocol for querying the database, which includes a >>> location sensitive database discovery mechanism and security for the >>> protocol, and application services. >>> - Standardize the data structure to be carried by the query >>> protocol. >>>=20 >>> The protocol must protect both the channel enablement process and the >>> privacy of users. Robust security mechanisms are required to prevent: >>> device identity spoofing, modification of device requests, modification >>> of channel enablement information, impersonation of registered database >>> services and unauthorized disclosure of a users location. >>>=20 >>> Existing IETF location data structures and privacy mechanisms may be >>> considered for use. The WG will also investigate the need for other >>> mechanisms and related protocols to the White Space DB. >>=20 >> Change to: >>=20 >> The working group will prefer to use existing IETF technologies >> and privacy mechanisms where possible. >>=20 >> Some IESG members were concerned about the open-ended nature of this >> statement: >>=20 >> The WG will also investigate the need for other mechanisms and >> related protocols to the White Space DB. >>=20 >> Is that really needed? Can it simply be removed? >>=20 >>> The Working Group will set up and maintain appropriate contact and >>> liaison with other relevant standards bodies and groups, including IEEE >>> 802.11af and IEEE 802.22 to begin with. The working group may also >>> consider input from regulatory entities that are involved in the >>> specification of the rules for secondary use of spectrum in specific >>> bands. >>>=20 >>> Goals and Milestones >>>=20 >>> Sep 2011 Submit 'Requirements and Framework' to the IESG for >>> publication as Informational >>=20 >> Change "Requirements and Framework" to "Requirements for Querying a >> White Space Database". >>=20 >>> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >>> the IESG for publication as Proposed Standard >>>=20 >>> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >>> IESG for publication as Proposed Standard >>=20 >> Change "Model" to "Structure". >>=20 >> (Also change "Whitespace" to "White Space"?) >>=20 >> Other IESG members might have additional comments. I might even have >> further comments after the IESG meeting is finished. :) >>=20 >> Peter >>=20 >> -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From stpeter@stpeter.im Tue May 3 06:10:39 2011 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 DA4A0E0818; Tue, 3 May 2011 06:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9WApLSGxtyR; Tue, 3 May 2011 06:10:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.233]) by ietfa.amsl.com (Postfix) with ESMTP id EF32EE081A; Tue, 3 May 2011 06:10:38 -0700 (PDT) Received: from squire.local (unknown [144.254.202.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F23E140126; Tue, 3 May 2011 07:10:37 -0600 (MDT) Message-ID: <4DBFFECC.8050104@stpeter.im> Date: Tue, 03 May 2011 15:10:36 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Rosen, Brian" References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030203070709020400050807" Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 13:10:40 -0000 This is a cryptographically signed message in MIME format. --------------ms030203070709020400050807 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/3/11 3:04 PM, Rosen, Brian wrote: > I have two comments: >=20 > I don't recall ever having been requested to "prefer to use existing > IETF technologies" before. Is there something special about this > effort that warrants this language? Usually, we just consider them. > I suspect we actually do "prefer" in many cases, but this request > stands out in my mind and I'm trying to understand why this is > needed. The concern expressed during the IESG discussion was that the charter as proposed lets the WG define just about any new application protocol (e.g., not even to prefer HTTP as a protocol for transferring data) instead of taking a look at what existing IETF technologies might be reusable. > Also, some push back on "Requirements and Framework" to > "Requirements". This implies the IESG sees no need for a framework > document. We thought it might be helpful, but didn't warrant a > separate document, so we suggested combining framework and > requirements into one document. The rest of the charter text talks about requirements but not the framework. In this context, what exactly are folks thinking about when they refer to a framework? > In the discussions we have had, there are other needs to build a > whitespace ecosystem. Here in the U.S. for example, we need > automated ways to provision the database of protected entities that > allows sharing of data among competing database providers. That is > the origin of the "other mechanisms and protocols" part. We can > recharter to get those in AFTER the database discovery and query > mechanisms are worked out, so I don't have a problem with deleting > that language from the charter now. Either way. In general it's probably good for us to complete the core work first and then look at extensions or additional methods for accessing the database. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms030203070709020400050807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUw MzEzMTAzNlowIwYJKoZIhvcNAQkEMRYEFPLBo7BUzuSQ7MZNtHVoIyjpDdljMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCQWG3PoX6mDxX+yqVzsr+aOxcX84iBKG6J4yM0URteC4Sfhs08re5qYDZC FqsQ09OcZgbIrWvMNUCUz9KjGaud9ALnkVK4zREr8WqCvjARM90qT2JBits2DUQZkB9uiyrv bYxaaJgZ+0aQuFjCT1LHLXBhczm2RyJ6rKGMgMhMiQWmtzr8XzR2TfrCFzaqlGbuEFE4x1UR 0Djfj8mYN49ZZCvpLVZyXQAKll/HdiYC4mI55sW2O+eEa3a9oyenp6nBp+LG7o4UAmjZ+4s6 7Z5EHPZehWK4Z13H8m2QKWTwjKoN6rGdxdKRjhjplirQia/Gg9UfwOmXrsDwONZ1EvL+AAAA AAAA --------------ms030203070709020400050807-- From dromasca@avaya.com Tue May 3 06:14:45 2011 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 D62E0E0818; Tue, 3 May 2011 06:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.166 X-Spam-Level: X-Spam-Status: No, score=-103.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 z7W14KeCVXLk; Tue, 3 May 2011 06:14:45 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 14544E0807; Tue, 3 May 2011 06:14:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAHD/v03GmAcF/2dsb2JhbACYBo4Fd6ssApoxhgIEk0+JfQ X-IronPort-AV: E=Sophos;i="4.64,309,1301889600"; d="scan'208";a="277910346" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 May 2011 09:14:27 -0400 X-IronPort-AV: E=Sophos;i="4.64,309,1301889600"; d="scan'208";a="616033847" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 May 2011 09:14:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 May 2011 15:14:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwJkqI2uB8L3vhLTNeTumYfkBUTuAAAIOlQ References: <20110419165634.CD24CE07CF@ietfc.amsl.com><4DBFF6D2.3040705@stpeter.im> From: "Romascanu, Dan (Dan)" To: "Rosen, Brian" , "Peter Saint-Andre" Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 13:14:46 -0000 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 > Behalf Of Rosen, Brian > Sent: Tuesday, May 03, 2011 4:04 PM > To: Peter Saint-Andre > Cc: paws@ietf.org; iesg@ietf.org > Subject: Re: [paws] WG Review: Protocol to Access White Space=20 > database (paws) >=20 > I have two comments: >=20 > I don't recall ever having been requested to "prefer to use=20 > existing IETF technologies" before. Is there something=20 > special about this effort that warrants this language? =20 > Usually, we just consider them. I suspect we actually do=20 > "prefer" in many cases, but this request stands out in my=20 > mind and I'm trying to understand why this is needed. >=20 Hi,=20 'Prefer' means in this context that if some specific combination of IETF technologies meet the Requirements it should be preferred over inventing a new protocol.=20 Regards, Dan=20 =20 From brian.rosen@neustar.biz Tue May 3 06:46:10 2011 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 B57F2E0680; Tue, 3 May 2011 06:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 xx1VdkkHuBzY; Tue, 3 May 2011 06:46:09 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 86BE1E06C7; Tue, 3 May 2011 06:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1304430367; x=1619765809; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=tNDJ2W0r2tKIsPaERKt/Q UU1WwMYb+N+jjf4Z/jXNQQ=; b=UImfMDGmQSv8W1tf1GWsShdAnR9OHz2wGvwS0 uZ+g8t9vRl3alvG1lABc2CdVDgxoxOPoAvrApypiK2QwADwZA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.36953249; Tue, 03 May 2011 09:46:05 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 3 May 2011 09:46:05 -0400 From: "Rosen, Brian" To: Peter Saint-Andre Date: Tue, 3 May 2011 09:46:03 -0400 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwJmHJoKpAyVy0gTcegIhFfy+mm4w== Message-ID: <4B4F7690-A351-45DE-8DDA-F17D724D307E@neustar.biz> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> <4DBFFECC.8050104@stpeter.im> In-Reply-To: <4DBFFECC.8050104@stpeter.im> 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: buX2Hn/g1babIHlAHiIe3Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 13:46:10 -0000 Inline On May 3, 2011, at 9:10 AM, Peter Saint-Andre wrote: > On 5/3/11 3:04 PM, Rosen, Brian wrote: >> I have two comments: >>=20 >> I don't recall ever having been requested to "prefer to use existing >> IETF technologies" before. Is there something special about this >> effort that warrants this language? Usually, we just consider them. >> I suspect we actually do "prefer" in many cases, but this request >> stands out in my mind and I'm trying to understand why this is >> needed. >=20 > The concern expressed during the IESG discussion was that the charter as > proposed lets the WG define just about any new application protocol > (e.g., not even to prefer HTTP as a protocol for transferring data) > instead of taking a look at what existing IETF technologies might be > reusable. I don't want to make a big deal out of this. I don't think it changes anyt= hing. I point out your concern is true of every protocol effort we start t= hese days. Yet, this language isn't in any charter I've looked at recentl= y. To cite an example, clue's charter says: Reuse of existing protocols and backwards compatibility with SIP-compliant audio/video endpoints are important factors for the working group to consider. "Consider" to "prefer to use" is a change in language AFAIK. Is there some= thing special about paws that warrants this change, or are you going to ask= charters generally to use that phrase? We can make the change, I'm just t= rying to understand if there is anything we've missed. >=20 >> Also, some push back on "Requirements and Framework" to >> "Requirements". This implies the IESG sees no need for a framework >> document. We thought it might be helpful, but didn't warrant a >> separate document, so we suggested combining framework and >> requirements into one document. >=20 > The rest of the charter text talks about requirements but not the > framework. In this context, what exactly are folks thinking about when > they refer to a framework? Whenever we start talking with new people, we have to bring them through th= e deck we present in the BoF, which explains what whitespace is, how it wor= ks, what the regulatory situation is, and what role the database plays. We= need to show some use cases. We were thinking we would put a version of t= hat in the Requirements and Framework document, and then have the protocol = document just refer to it, rather than explain it all again there. >=20 >> In the discussions we have had, there are other needs to build a >> whitespace ecosystem. Here in the U.S. for example, we need >> automated ways to provision the database of protected entities that >> allows sharing of data among competing database providers. That is >> the origin of the "other mechanisms and protocols" part. We can >> recharter to get those in AFTER the database discovery and query >> mechanisms are worked out, so I don't have a problem with deleting >> that language from the charter now. >=20 > Either way. In general it's probably good for us to complete the core > work first and then look at extensions or additional methods for > accessing the database. No problem >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 From stpeter@stpeter.im Tue May 3 06:55:37 2011 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 F1E6CE081A; Tue, 3 May 2011 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASQZ+1RkdEXN; Tue, 3 May 2011 06:55:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4A7E0816; Tue, 3 May 2011 06:55:36 -0700 (PDT) Received: from squire.local (unknown [144.254.202.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EA20140126; Tue, 3 May 2011 07:55:34 -0600 (MDT) Message-ID: <4DC00955.3060601@stpeter.im> Date: Tue, 03 May 2011 15:55:33 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Rosen, Brian" References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> <4DBFFECC.8050104@stpeter.im> <4B4F7690-A351-45DE-8DDA-F17D724D307E@neustar.biz> In-Reply-To: <4B4F7690-A351-45DE-8DDA-F17D724D307E@neustar.biz> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090304000206090306070806" Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 03 May 2011 13:55:37 -0000 This is a cryptographically signed message in MIME format. --------------ms090304000206090306070806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/3/11 3:46 PM, Rosen, Brian wrote: > Inline On May 3, 2011, at 9:10 AM, Peter Saint-Andre wrote: >=20 >> On 5/3/11 3:04 PM, Rosen, Brian wrote: >>> I have two comments: >>>=20 >>> I don't recall ever having been requested to "prefer to use >>> existing IETF technologies" before. Is there something special >>> about this effort that warrants this language? Usually, we just >>> consider them. I suspect we actually do "prefer" in many cases, >>> but this request stands out in my mind and I'm trying to >>> understand why this is needed. >>=20 >> The concern expressed during the IESG discussion was that the >> charter as proposed lets the WG define just about any new >> application protocol (e.g., not even to prefer HTTP as a protocol >> for transferring data) instead of taking a look at what existing >> IETF technologies might be reusable. > I don't want to make a big deal out of this. I don't think it > changes anything. I point out your concern is true of every protocol > effort we start these days. Yet, this language isn't in any charter > I've looked at recently. To cite an example, clue's charter says:=20 > Reuse of existing protocols and backwards compatibility with=20 > SIP-compliant audio/video endpoints are important factors for the=20 > working group to consider. >=20 > "Consider" to "prefer to use" is a change in language AFAIK. Is > there something special about paws that warrants this change, or are > you going to ask charters generally to use that phrase? We can make > the change, I'm just trying to understand if there is anything we've > missed. I don't see a big difference between "consider" and "prefer if possible", but "should consider" is better than "may consider" in my opinion because the latter sounds purely optional. >>> Also, some push back on "Requirements and Framework" to=20 >>> "Requirements". This implies the IESG sees no need for a >>> framework document. We thought it might be helpful, but didn't >>> warrant a separate document, so we suggested combining framework >>> and requirements into one document. >>=20 >> The rest of the charter text talks about requirements but not the=20 >> framework. In this context, what exactly are folks thinking about >> when they refer to a framework? > Whenever we start talking with new people, we have to bring them > through the deck we present in the BoF, which explains what > whitespace is, how it works, what the regulatory situation is, and > what role the database plays. We need to show some use cases. We > were thinking we would put a version of that in the Requirements and > Framework document, and then have the protocol document just refer to > it, rather than explain it all again there. Sounds reasonable to me! By "framework" some folks seem to be thinking of "technology framework" instead of something more like "problem statement and use cases". >>> In the discussions we have had, there are other needs to build a=20 >>> whitespace ecosystem. Here in the U.S. for example, we need=20 >>> automated ways to provision the database of protected entities >>> that allows sharing of data among competing database providers. >>> That is the origin of the "other mechanisms and protocols" part. >>> We can recharter to get those in AFTER the database discovery and >>> query mechanisms are worked out, so I don't have a problem with >>> deleting that language from the charter now. >>=20 >> Either way. In general it's probably good for us to complete the >> core work first and then look at extensions or additional methods >> for accessing the database. > No problem Excellent. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090304000206090306070806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUw MzEzNTUzM1owIwYJKoZIhvcNAQkEMRYEFDrbTjM0LhVyKIZc3rMGJerPXeSIMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBRLPiX44OloYsKfYyroEK7KTm7JFOD9u2vylSVv2DeCtCig5whs5lUy762 gEoQKjNG77xRcSMhKs5n5gsXLTBSd4wTi3741GdHGedvIIIR9yXONel+7OEWHtjH5rDlqn0r YZTAqhqlFUAapFY1dGNCK5kbQ4haN7vvgAG9rvys3oZ0PPulNbkLj9JByCSbh/xeJB7K4v+J m1yRQ6SIhdEmjvS2v5KN8yHm4+Ihalsl6o3qbZy5sRzHak8JVIufD3MH1/deq3j3/50n+/8j hXWUZ9in+Q/DWff0lsGzH6aE1N478b5ODeLWRMpkDK7WTH+iTxvvLtRbNlm4C3QT0m+PAAAA AAAA --------------ms090304000206090306070806-- From Adrian.Farrel@huawei.com Tue May 3 06:55:24 2011 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 EE79AE06AB; Tue, 3 May 2011 06:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 SYm3sqJKU7Yt; Tue, 3 May 2011 06:55:23 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id D18C4E0684; Tue, 3 May 2011 06:55:23 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKM00EV0HCBYF@usaga03-in.huawei.com>; Tue, 03 May 2011 08:55:23 -0500 (CDT) Received: from 950129200 (dhcp-guest-ams5-144-254-113-98.cisco.com [144.254.113.98]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKM003Z8HC9KR@usaga03-in.huawei.com>; Tue, 03 May 2011 08:55:23 -0500 (CDT) Date: Tue, 03 May 2011 14:55:20 +0100 From: Adrian Farrel In-reply-to: <4B4F7690-A351-45DE-8DDA-F17D724D307E@neustar.biz> To: "'Rosen, Brian'" , 'Peter Saint-Andre' Message-id: <03c801cc0999$bfd8bb40$3f8a31c0$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AQHE32dxBff+5/TpeJA6HfhOZ1Ze9wH1fcO3AN3JIsUCXhSexQK3ZtLOlEouFzA= References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> <4DBFFECC.8050104@stpeter.im> <4B4F7690-A351-45DE-8DDA-F17D724D307E@neustar.biz> X-Mailman-Approved-At: Tue, 03 May 2011 06:57:36 -0700 Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 13:55:25 -0000 Hi Brian, > > The concern expressed during the IESG discussion was that the charter as > > proposed lets the WG define just about any new application protocol > > (e.g., not even to prefer HTTP as a protocol for transferring data) > > instead of taking a look at what existing IETF technologies might be > > reusable. > I don't want to make a big deal out of this. I don't think it changes anything. I > point out your concern is true of every protocol effort we start these days. Yet, > this language isn't in any charter I've looked at recently. To cite an example, > clue's charter says: > Reuse of existing protocols and backwards compatibility with > SIP-compliant audio/video endpoints are important factors for the > working group to consider. I think you are right to not make a big issue out of this. Recharters can be quick and painless. They are not to be feared. As a datapoint, one of our most recently chartered WGs is ARMD http://datatracker.ietf.org/wg/armd/charter/ Cheers, Adrian From warren@kumari.net Wed May 4 15:02:04 2011 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 3E966E067E; Wed, 4 May 2011 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iV-a+KGSmyk; Wed, 4 May 2011 15:02:03 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 41ACDE0663; Wed, 4 May 2011 15:02:02 -0700 (PDT) Received: from [172.19.118.237] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 572901B40155; Wed, 4 May 2011 18:02:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4DBFF6D2.3040705@stpeter.im> Date: Wed, 4 May 2011 18:01:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <278C839B-A7E3-4177-9C01-F637E49322D7@kumari.net> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 04 May 2011 22:02:04 -0000 On May 3, 2011, at 8:36 AM, Peter Saint-Andre wrote: > Folks, at the IESG retreat just now we discussed the PAWS charter. The > basic feedback is as follows: >=20 > - it seems appropriate to do this work at the IETF >=20 > - the Applications Area seems like the right area within the IETF >=20 > - it would be best to prefer re-use of existing IETF protocols >=20 > - we need to clean up the charter text here and there >=20 > I've provided specific text suggestions below. Discussion is welcome. >=20 > On 4/19/11 6:56 PM, IESG Secretary wrote: >> A new IETF working group has been proposed. The IESG has not made = any >> determination as yet. The following draft charter was submitted, and = is >> provided for informational purposes only. Please send your comments = to the >> IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. = =20 >>=20 >>=20 >> Protocol to Access White Space database (paws) >> ------------------------------------------------ >> Current Status: Proposed Working Group >> Last updated: 2011-04-14 >>=20 >> Chairs: >> TBD >>=20 >> Area Directors: >> TBD >>=20 >> Area Advisor: >> TBD >>=20 >> Mailing lists: >> Address: paws@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >> Archive: http://www.ietf.org/mail-archive/web/paws/ >>=20 >> Description of Working Group: >>=20 >> Governments around the world continue to search for new pieces of = radio >> spectrum which can be used by the expanding wireless communications >> industry to provide more services in the usable spectrum. The concept >> of allowing secondary transmissions (licensed or unlicensed) in >> frequencies allocated to a primary user is a technique to "unlock" >> existing spectrum for new use. An obvious requirement is that these >> secondary transmissions do not interfere with the primary use of the >> spectrum. Often, in a given physical location, the primary user(s) = may >> not be using the entire band allocated to them. The available = spectrum >> for a secondary use would then depend on the location of the = secondary >> user. The primary user may have a schedule when it uses the spectrum, >> which may be available for secondary use outside that schedule. The >> fundamental issue is how to determine for a specific location and >> specific time, if any of the primary spectrum is available for = secondary >> use. One simple mechanism is to use a geospatial database that = records >> protected contours for primary users, and require the secondary users = to >> check the database prior to selecting what part of the spectrum they >> use. Such databases could be available on the Internet for query by >> users. >>=20 >> In a typical implementation of geolocation and database to access TV >> white space, a radio is configured with, or has the capability to >> determine its location in latitude and longitude. At power-on, before >> the device can transmit or use any of the spectrum set aside for >> secondary use, the device must identify the relevant database to = query, >> contact the database, provide its geolocation and receive in return a >> list of unoccupied or "white space" spectrum (for example, in a TV >> White space implementation, the list of available channels at that >> location). The device can then select one of the channels from the = list >> and begin to transmit and receive on the selected channel. The device >> must query the database subsequently on a periodic basis for a list = of >> unoccupied channels based on certain conditions, e.g. a fixed amount = of >> time has passed or the device has changed location beyond a specified >> threshold. >>=20 >> The databases are expected to be reachable via the Internet and the >> devices querying these databases are expected to have some form of >> Internet connectivity, directly or indirectly. The databases may be >> country specific since the available spectrum and regulations may = vary, >> but the fundamental operation of the protocol should be country >> independent, thus extensibility of data structures will be required. = The >> solution will not be tied to any specific spectrum, country, or >> phy/mac/air interface but may incorporate relevant aspects of these = as >> needed for proper operation. >>=20 >> The proposed working group will : >=20 > Remove "proposed". >=20 > Add: >=20 > - define the requirements for querying a white space database >=20 >> - standardize a protocol for querying the database, which includes a >> location sensitive database discovery mechanism and security for the >> protocol, and application services. >> - Standardize the data structure to be carried by the query >> protocol. >>=20 >> The protocol must protect both the channel enablement process and the >> privacy of users. Robust security mechanisms are required to prevent: >> device identity spoofing, modification of device requests, = modification >> of channel enablement information, impersonation of registered = database >> services and unauthorized disclosure of a users location. My main comment here is on the use of the word "channel" with no real = definition. Yes, I know that much / some of the interest from this is = the TV whitespace, and that is where the "channel" comes from, but I = think that we should actually be discussing frequencies or frequency = ranges. I think that this is an important distinction for the chartering = discussions to help the WG keep all of the users in mind.=20 I have tried to some up with a way to insert something like a definition = for a channel (or a way to s/channel/ frequency range/), but all of my = attempts ruin the text -- this might be a sign that I'm worrying about = nothing... Other than that I like the charter with the changes -- I'm a little = surprised by the explicit "prefer to use existing IETF technologies", = but a: have no strong views and b: figure there might be a good reason = for is... W >>=20 >> Existing IETF location data structures and privacy mechanisms may be >> considered for use. The WG will also investigate the need for other >> mechanisms and related protocols to the White Space DB. >=20 > Change to: >=20 > The working group will prefer to use existing IETF technologies > and privacy mechanisms where possible. >=20 > Some IESG members were concerned about the open-ended nature of this > statement: >=20 > The WG will also investigate the need for other mechanisms and > related protocols to the White Space DB. >=20 > Is that really needed? Can it simply be removed? >=20 >> The Working Group will set up and maintain appropriate contact and >> liaison with other relevant standards bodies and groups, including = IEEE >> 802.11af and IEEE 802.22 to begin with. The working group may also >> consider input from regulatory entities that are involved in the >> specification of the rules for secondary use of spectrum in specific >> bands. >>=20 >> Goals and Milestones >>=20 >> Sep 2011 Submit 'Requirements and Framework' to the IESG for >> publication as Informational >=20 > Change "Requirements and Framework" to "Requirements for Querying a > White Space Database". >=20 >> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >> the IESG for publication as Proposed Standard >>=20 >> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >> IESG for publication as Proposed Standard >=20 > Change "Model" to "Structure". >=20 > (Also change "Whitespace" to "White Space"?) >=20 > Other IESG members might have additional comments. I might even have > further comments after the IESG meeting is finished. :) >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed May 4 17:31:56 2011 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 5E4D3E06C2; Wed, 4 May 2011 17:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 fLFBX7a7JgGe; Wed, 4 May 2011 17:31:55 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C9266E067E; Wed, 4 May 2011 17:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1304555511; x=1619888235; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=HYnz3hDxEF8dCbaSYQ1ZO Ls3yUQJMEIrbj14FfYdl4I=; b=jDLIMWEXvcggQTogRd/STv++cirlVvFeSy/xs Iv4bQAwmehcnc8lkh+EKKhixUbLPVexW/rgHKbBGWCzA0l+hg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.22210128; Wed, 04 May 2011 20:31:50 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 4 May 2011 20:31:50 -0400 From: "Rosen, Brian" To: Warren Kumari Date: Wed, 4 May 2011 20:31:49 -0400 Thread-Topic: [paws] WG Review: Protocol to Access White Space database (paws) Thread-Index: AcwKu9LGe9Q+47iLQZCUPUzG0Bvu6w== Message-ID: References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> <278C839B-A7E3-4177-9C01-F637E49322D7@kumari.net> In-Reply-To: <278C839B-A7E3-4177-9C01-F637E49322D7@kumari.net> 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: oXkjO4gs/yfVEt99AALH+g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 05 May 2011 00:31:56 -0000 How about just "spectrum" instead of "channel"? Brian On May 4, 2011, at 6:01 PM, Warren Kumari wrote: >=20 > On May 3, 2011, at 8:36 AM, Peter Saint-Andre wrote: >=20 >> Folks, at the IESG retreat just now we discussed the PAWS charter. The >> basic feedback is as follows: >>=20 >> - it seems appropriate to do this work at the IETF >>=20 >> - the Applications Area seems like the right area within the IETF >>=20 >> - it would be best to prefer re-use of existing IETF protocols >>=20 >> - we need to clean up the charter text here and there >>=20 >> I've provided specific text suggestions below. Discussion is welcome. >>=20 >> On 4/19/11 6:56 PM, IESG Secretary wrote: >>> A new IETF working group has been proposed. The IESG has not made any >>> determination as yet. The following draft charter was submitted, and is >>> provided for informational purposes only. Please send your comments to = the >>> IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. = =20 >>>=20 >>>=20 >>> Protocol to Access White Space database (paws) >>> ------------------------------------------------ >>> Current Status: Proposed Working Group >>> Last updated: 2011-04-14 >>>=20 >>> Chairs: >>> TBD >>>=20 >>> Area Directors: >>> TBD >>>=20 >>> Area Advisor: >>> TBD >>>=20 >>> Mailing lists: >>> Address: paws@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >>> Archive: http://www.ietf.org/mail-archive/web/paws/ >>>=20 >>> Description of Working Group: >>>=20 >>> Governments around the world continue to search for new pieces of radio >>> spectrum which can be used by the expanding wireless communications >>> industry to provide more services in the usable spectrum. The concept >>> of allowing secondary transmissions (licensed or unlicensed) in >>> frequencies allocated to a primary user is a technique to "unlock" >>> existing spectrum for new use. An obvious requirement is that these >>> secondary transmissions do not interfere with the primary use of the >>> spectrum. Often, in a given physical location, the primary user(s) may >>> not be using the entire band allocated to them. The available spectrum >>> for a secondary use would then depend on the location of the secondary >>> user. The primary user may have a schedule when it uses the spectrum, >>> which may be available for secondary use outside that schedule. The >>> fundamental issue is how to determine for a specific location and >>> specific time, if any of the primary spectrum is available for secondar= y >>> use. One simple mechanism is to use a geospatial database that records >>> protected contours for primary users, and require the secondary users t= o >>> check the database prior to selecting what part of the spectrum they >>> use. Such databases could be available on the Internet for query by >>> users. >>>=20 >>> In a typical implementation of geolocation and database to access TV >>> white space, a radio is configured with, or has the capability to >>> determine its location in latitude and longitude. At power-on, before >>> the device can transmit or use any of the spectrum set aside for >>> secondary use, the device must identify the relevant database to query, >>> contact the database, provide its geolocation and receive in return a >>> list of unoccupied or "white space" spectrum (for example, in a TV >>> White space implementation, the list of available channels at that >>> location). The device can then select one of the channels from the list >>> and begin to transmit and receive on the selected channel. The device >>> must query the database subsequently on a periodic basis for a list of >>> unoccupied channels based on certain conditions, e.g. a fixed amount of >>> time has passed or the device has changed location beyond a specified >>> threshold. >>>=20 >>> The databases are expected to be reachable via the Internet and the >>> devices querying these databases are expected to have some form of >>> Internet connectivity, directly or indirectly. The databases may be >>> country specific since the available spectrum and regulations may vary, >>> but the fundamental operation of the protocol should be country >>> independent, thus extensibility of data structures will be required. Th= e >>> solution will not be tied to any specific spectrum, country, or >>> phy/mac/air interface but may incorporate relevant aspects of these as >>> needed for proper operation. >>>=20 >>> The proposed working group will : >>=20 >> Remove "proposed". >>=20 >> Add: >>=20 >> - define the requirements for querying a white space database >>=20 >>> - standardize a protocol for querying the database, which includes a >>> location sensitive database discovery mechanism and security for the >>> protocol, and application services. >>> - Standardize the data structure to be carried by the query >>> protocol. >>>=20 >>> The protocol must protect both the channel enablement process and the >>> privacy of users. Robust security mechanisms are required to prevent: >>> device identity spoofing, modification of device requests, modification >>> of channel enablement information, impersonation of registered database >>> services and unauthorized disclosure of a users location. >=20 > My main comment here is on the use of the word "channel" with no real def= inition. Yes, I know that much / some of the interest from this is the TV w= hitespace, and that is where the "channel" comes from, but I think that we = should actually be discussing frequencies or frequency ranges. I think that= this is an important distinction for the chartering discussions to help th= e WG keep all of the users in mind.=20 >=20 > I have tried to some up with a way to insert something like a definition = for a channel (or a way to s/channel/ frequency range/), but all of my atte= mpts ruin the text -- this might be a sign that I'm worrying about nothing.= .. >=20 > Other than that I like the charter with the changes -- I'm a little surpr= ised by the explicit "prefer to use existing IETF technologies", but a: hav= e no strong views and b: figure there might be a good reason for is... >=20 > W >>>=20 >>> Existing IETF location data structures and privacy mechanisms may be >>> considered for use. The WG will also investigate the need for other >>> mechanisms and related protocols to the White Space DB. >>=20 >> Change to: >>=20 >> The working group will prefer to use existing IETF technologies >> and privacy mechanisms where possible. >>=20 >> Some IESG members were concerned about the open-ended nature of this >> statement: >>=20 >> The WG will also investigate the need for other mechanisms and >> related protocols to the White Space DB. >>=20 >> Is that really needed? Can it simply be removed? >>=20 >>> The Working Group will set up and maintain appropriate contact and >>> liaison with other relevant standards bodies and groups, including IEEE >>> 802.11af and IEEE 802.22 to begin with. The working group may also >>> consider input from regulatory entities that are involved in the >>> specification of the rules for secondary use of spectrum in specific >>> bands. >>>=20 >>> Goals and Milestones >>>=20 >>> Sep 2011 Submit 'Requirements and Framework' to the IESG for >>> publication as Informational >>=20 >> Change "Requirements and Framework" to "Requirements for Querying a >> White Space Database". >>=20 >>> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >>> the IESG for publication as Proposed Standard >>>=20 >>> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >>> IESG for publication as Proposed Standard >>=20 >> Change "Model" to "Structure". >>=20 >> (Also change "Whitespace" to "White Space"?) >>=20 >> Other IESG members might have additional comments. I might even have >> further comments after the IESG meeting is finished. :) >>=20 >> Peter >>=20 >> -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >> _______________________________________________ >> 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 From caulfield.jesse@gmail.com Wed May 4 17:49:49 2011 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 B08E8E067E; Wed, 4 May 2011 17:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v825QKK2-QML; Wed, 4 May 2011 17:49:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2717E0674; Wed, 4 May 2011 17:49:48 -0700 (PDT) Received: by vxg33 with SMTP id 33so2052716vxg.31 for ; Wed, 04 May 2011 17:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-cr-hashedpuzzle :x-cr-puzzleid; bh=+I+6bqtxdkvEVXnbXiwMYAktL8RhX+yKCJiZvNr3vcY=; b=iW9yv0iGA2/1ODw8A3g4iWOc3xpJZLOVMW6/SJ2r0oMknPvnlOLdsDTVYQ2FHzU9md RHW+cnEnkhyXEBRsrLEipfHXET6cmSSR//UvVmohb8ag3vqquVGdcPHClZ21oz3l65/7 bvNr7TjzMOg2Y94+oqfgZcZGHg0Ube163zLyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-cr-hashedpuzzle:x-cr-puzzleid; b=S/wmCLmZM6Dtj12F/jfU8l8MSef1WPBREL27ZMzZJKfdrXJbrV3rjBvS9nZ4XymYDD 6T8jGJ8QLASHuKJM/diE7b/heQpShtHmx7q1Iwm4h6svOWci+Pk//LOtVQ7KuLu5FveS lX5MKGBsUmZhh+PRDwGz5Pw1husGlSg9ex/lo= Received: by 10.52.96.138 with SMTP id ds10mr442703vdb.11.1304556588149; Wed, 04 May 2011 17:49:48 -0700 (PDT) Received: from JMCLaptop (pool-173-66-247-174.washdc.fios.verizon.net [173.66.247.174]) by mx.google.com with ESMTPS id dh10sm263868vdc.37.2011.05.04.17.49.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 17:49:47 -0700 (PDT) From: "Jesse Caulfield" To: "'Warren Kumari'" , "'Peter Saint-Andre'" References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> <278C839B-A7E3-4177-9C01-F637E49322D7@kumari.net> In-Reply-To: <278C839B-A7E3-4177-9C01-F637E49322D7@kumari.net> Date: Wed, 4 May 2011 20:49:41 -0400 Message-ID: <4dc1f42b.aab3340a.700f.170c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwKpuphEZz/59NuSYCUz5KFiicZhQAE2yQA Content-Language: en-us x-cr-hashedpuzzle: Btnf C5hd GAjw Ikf4 I7Xn Mshm TZHn Tre+ WCLX X9Zm YRjd irNo isau rg1j tM+6 uuT5; 4; aQBlAHMAZwBAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQB3AHMAQABpAGUAdABmAC4AbwByAGcAOwBzAHQAcABlAHQAZQByAEAAcwB0AHAAZQB0AGUAcgAuAGkAbQA7AHcAYQByAHIAZQBuAEAAawB1AG0AYQByAGkALgBuAGUAdAA=; Sosha1_v1; 7; {E907B2C7-26D2-4D70-BA3A-DB4116D63F52}; YwBhAHUAbABmAGkAZQBsAGQALgBqAGUAcwBzAGUAQABnAG0AYQBpAGwALgBjAG8AbQA=; Thu, 05 May 2011 00:49:29 GMT; UgBFADoAIABbAHAAYQB3AHMAXQAgAFcARwAgAFIAZQB2AGkAZQB3ADoAIABQAHIAbwB0AG8AYwBvAGwAIAB0AG8AIABBAGMAYwBlAHMAcwAgAFcAaABpAHQAZQAgAFMAcABhAGMAZQAgAGQAYQB0AGEAYgBhAHMAZQAgACgAcABhAHcAcwApAA== x-cr-puzzleid: {E907B2C7-26D2-4D70-BA3A-DB4116D63F52} Cc: paws@ietf.org, iesg@ietf.org Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 05 May 2011 00:49:49 -0000 > My main comment here is on the use of the word "channel" with no real definition. Yes, I know that much / some of the interest from this is the TV whitespace, and that is where the "channel" comes from, but I think that we should actually be discussing frequencies or frequency ranges. I think that this is an important distinction for the chartering discussions to help the WG keep all of the users in mind. > I have tried to some up with a way to insert something like a definition for a channel (or a way to s/channel/ frequency range/), but all of my attempts ruin the text -- this might be a sign that I'm worrying about nothing... Agreed. I believe a generalized white space protocol must accommodate the following at minimum: * Multiple frequency bands (e.g. UHF, VHF, S-band, etc.) * Variable channel width (e.g. 6 MHz, 8 MHz ...) For this it seems a reasonable solution to specify either start plus stop frequencies or center frequency plus channel width. "Channel" is an opaque term unless explicitly tied to an objective definition. For example US TV channels are defined in 47 CFR 73.603. For internationalization a "channel" number must also reference the regulatory authority under which a system is operating and which precisely defines the channel's technical parameters. -- Jesse Caulfield, Key Bridge From teco@inf-net.nl Wed May 4 23:32:27 2011 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 693C5E06DD; Wed, 4 May 2011 23:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5c1-AawDe3t; Wed, 4 May 2011 23:32:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 936C6E06C0; Wed, 4 May 2011 23:32:24 -0700 (PDT) Received: by wyb29 with SMTP id 29so1557756wyb.31 for ; Wed, 04 May 2011 23:32:23 -0700 (PDT) Received: by 10.216.254.79 with SMTP id g57mr2089694wes.42.1304577143562; Wed, 04 May 2011 23:32:23 -0700 (PDT) Received: from [192.168.2.150] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id t58sm908187weq.16.2011.05.04.23.32.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 23:32:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Thu, 5 May 2011 08:32:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B5F612F-5047-4C8E-AB7D-CCB76A35D1CF@inf-net.nl> References: <20110419165634.CD24CE07CF@ietfc.amsl.com> <4DBFF6D2.3040705@stpeter.im> <278C839B-A7E3-4177-9C01-F637E49322D7@kumari.net> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1084) Cc: "paws@ietf.org" , "iesg@ietf.org" Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) 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, 05 May 2011 06:32:27 -0000 Op 5 mei 2011, om 02:31 heeft Rosen, Brian het volgende geschreven: > How about just "spectrum" instead of "channel"? I prefer channel. We use this term for a (set of) frequency band(s), = used for RF communications. Channels are part of the spectrum. We need to specify used definitions. It is a bit early to discuss this = right now. Teco >=20 > Brian >=20 > On May 4, 2011, at 6:01 PM, Warren Kumari wrote: >=20 >>=20 >> On May 3, 2011, at 8:36 AM, Peter Saint-Andre wrote: >>=20 >>> Folks, at the IESG retreat just now we discussed the PAWS charter. = The >>> basic feedback is as follows: >>>=20 >>> - it seems appropriate to do this work at the IETF >>>=20 >>> - the Applications Area seems like the right area within the IETF >>>=20 >>> - it would be best to prefer re-use of existing IETF protocols >>>=20 >>> - we need to clean up the charter text here and there >>>=20 >>> I've provided specific text suggestions below. Discussion is = welcome. >>>=20 >>> On 4/19/11 6:56 PM, IESG Secretary wrote: >>>> A new IETF working group has been proposed. The IESG has not made = any >>>> determination as yet. The following draft charter was submitted, = and is >>>> provided for informational purposes only. Please send your comments = to the >>>> IESG mailing list (iesg@ietf.org) by Tuesday, April 26, 2011. = =20 >>>>=20 >>>>=20 >>>> Protocol to Access White Space database (paws) >>>> ------------------------------------------------ >>>> Current Status: Proposed Working Group >>>> Last updated: 2011-04-14 >>>>=20 >>>> Chairs: >>>> TBD >>>>=20 >>>> Area Directors: >>>> TBD >>>>=20 >>>> Area Advisor: >>>> TBD >>>>=20 >>>> Mailing lists: >>>> Address: paws@ietf.org >>>> To Subscribe: https://www.ietf.org/mailman/listinfo/paws >>>> Archive: http://www.ietf.org/mail-archive/web/paws/ >>>>=20 >>>> Description of Working Group: >>>>=20 >>>> Governments around the world continue to search for new pieces of = radio >>>> spectrum which can be used by the expanding wireless communications >>>> industry to provide more services in the usable spectrum. The = concept >>>> of allowing secondary transmissions (licensed or unlicensed) in >>>> frequencies allocated to a primary user is a technique to "unlock" >>>> existing spectrum for new use. An obvious requirement is that these >>>> secondary transmissions do not interfere with the primary use of = the >>>> spectrum. Often, in a given physical location, the primary user(s) = may >>>> not be using the entire band allocated to them. The available = spectrum >>>> for a secondary use would then depend on the location of the = secondary >>>> user. The primary user may have a schedule when it uses the = spectrum, >>>> which may be available for secondary use outside that schedule. The >>>> fundamental issue is how to determine for a specific location and >>>> specific time, if any of the primary spectrum is available for = secondary >>>> use. One simple mechanism is to use a geospatial database that = records >>>> protected contours for primary users, and require the secondary = users to >>>> check the database prior to selecting what part of the spectrum = they >>>> use. Such databases could be available on the Internet for query by >>>> users. >>>>=20 >>>> In a typical implementation of geolocation and database to access = TV >>>> white space, a radio is configured with, or has the capability to >>>> determine its location in latitude and longitude. At power-on, = before >>>> the device can transmit or use any of the spectrum set aside for >>>> secondary use, the device must identify the relevant database to = query, >>>> contact the database, provide its geolocation and receive in return = a >>>> list of unoccupied or "white space" spectrum (for example, in a TV >>>> White space implementation, the list of available channels at that >>>> location). The device can then select one of the channels from the = list >>>> and begin to transmit and receive on the selected channel. The = device >>>> must query the database subsequently on a periodic basis for a list = of >>>> unoccupied channels based on certain conditions, e.g. a fixed = amount of >>>> time has passed or the device has changed location beyond a = specified >>>> threshold. >>>>=20 >>>> The databases are expected to be reachable via the Internet and the >>>> devices querying these databases are expected to have some form of >>>> Internet connectivity, directly or indirectly. The databases may be >>>> country specific since the available spectrum and regulations may = vary, >>>> but the fundamental operation of the protocol should be country >>>> independent, thus extensibility of data structures will be = required. The >>>> solution will not be tied to any specific spectrum, country, or >>>> phy/mac/air interface but may incorporate relevant aspects of these = as >>>> needed for proper operation. >>>>=20 >>>> The proposed working group will : >>>=20 >>> Remove "proposed". >>>=20 >>> Add: >>>=20 >>> - define the requirements for querying a white space database >>>=20 >>>> - standardize a protocol for querying the database, which includes = a >>>> location sensitive database discovery mechanism and security for = the >>>> protocol, and application services. >>>> - Standardize the data structure to be carried by the query >>>> protocol. >>>>=20 >>>> The protocol must protect both the channel enablement process and = the >>>> privacy of users. Robust security mechanisms are required to = prevent: >>>> device identity spoofing, modification of device requests, = modification >>>> of channel enablement information, impersonation of registered = database >>>> services and unauthorized disclosure of a users location. >>=20 >> My main comment here is on the use of the word "channel" with no real = definition. Yes, I know that much / some of the interest from this is = the TV whitespace, and that is where the "channel" comes from, but I = think that we should actually be discussing frequencies or frequency = ranges. I think that this is an important distinction for the chartering = discussions to help the WG keep all of the users in mind.=20 >>=20 >> I have tried to some up with a way to insert something like a = definition for a channel (or a way to s/channel/ frequency range/), but = all of my attempts ruin the text -- this might be a sign that I'm = worrying about nothing... >>=20 >> Other than that I like the charter with the changes -- I'm a little = surprised by the explicit "prefer to use existing IETF technologies", = but a: have no strong views and b: figure there might be a good reason = for is... >>=20 >> W >>>>=20 >>>> Existing IETF location data structures and privacy mechanisms may = be >>>> considered for use. The WG will also investigate the need for other >>>> mechanisms and related protocols to the White Space DB. >>>=20 >>> Change to: >>>=20 >>> The working group will prefer to use existing IETF technologies >>> and privacy mechanisms where possible. >>>=20 >>> Some IESG members were concerned about the open-ended nature of this >>> statement: >>>=20 >>> The WG will also investigate the need for other mechanisms and >>> related protocols to the White Space DB. >>>=20 >>> Is that really needed? Can it simply be removed? >>>=20 >>>> The Working Group will set up and maintain appropriate contact and >>>> liaison with other relevant standards bodies and groups, including = IEEE >>>> 802.11af and IEEE 802.22 to begin with. The working group may also >>>> consider input from regulatory entities that are involved in the >>>> specification of the rules for secondary use of spectrum in = specific >>>> bands. >>>>=20 >>>> Goals and Milestones >>>>=20 >>>> Sep 2011 Submit 'Requirements and Framework' to the IESG for >>>> publication as Informational >>>=20 >>> Change "Requirements and Framework" to "Requirements for Querying a >>> White Space Database". >>>=20 >>>> Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to >>>> the IESG for publication as Proposed Standard >>>>=20 >>>> Apr 2012 Submit 'Data Model for Whitespace query protocol' to the >>>> IESG for publication as Proposed Standard >>>=20 >>> Change "Model" to "Structure". >>>=20 >>> (Also change "Whitespace" to "White Space"?) >>>=20 >>> Other IESG members might have additional comments. I might even have >>> further comments after the IESG meeting is finished. :) >>>=20 >>> Peter >>>=20 >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>>=20 >>> _______________________________________________ >>> 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 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed May 11 14:52:56 2011 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 90A1EE08AE for ; Wed, 11 May 2011 14:52:56 -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 g3SM-V5B4vr2 for ; Wed, 11 May 2011 14:52:55 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id C53A3E089C for ; Wed, 11 May 2011 14:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1305150766; x=1620502052; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=35/lIpAKWvQ52kLdvsj7O uegcT5xLHJXoFp2hldlSdo=; b=XFJwdodzXnrufepHdli56jAftVoRtEAetNVsf JBX2MWp1XTwzJeyZlvUqnl6xiN9qqRo4OaJieTZJxQk8+UhnQ== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.38864416; Wed, 11 May 2011 17:52:45 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 11 May 2011 17:52:44 -0400 From: "Rosen, Brian" To: "paws@ietf.org" Date: Wed, 11 May 2011 17:52:41 -0400 Thread-Topic: Updated charter text Thread-Index: AcwQJcG+0cyavHleTcObm3myTXJPwA== Message-ID: <4A1C28E3-CD5E-4389-92BB-03FD064E4311@neustar.biz> 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: sznK2VpyE2MwmK71GJXz1g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Updated charter text 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, 11 May 2011 21:52:56 -0000 I believe we are pretty close to getting approval. I want to confirm that = this is the charter text we want. I left "channel" as is. We need to fina= lize this, so at this point, if you can live with it, say so, and if not, m= ake specific wording proposals. Consider this an (informal, we're not a wo= rk group, and have no chairs) call for consensus. Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-05-11 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: paws@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of unoccupied or "white space" spectrum (for example, in a TV White space implementation, the list of available channels at that location). The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list of unoccupied channels based on certain conditions, e.g. a fixed amount of time has passed or the device has changed location beyond a specified threshold. The databases are expected to be reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases may be country specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be country independent, thus extensibility of data structures will be required. The solution will not be tied to any specific spectrum, country, or phy/mac/air interface but may incorporate relevant aspects of these as needed for proper operation. The working group will : - define the requirements for querying a white space database - standardize a protocol for querying the database, which includes a location sensitive database discovery mechanism and security for the protocol, and application services. - Standardize the data structure to be carried by the query protocol. The protocol must protect both the channel enablement process and the privacy of users, and prevent unauthorized disclosure of a user's location. In some circumstances robust security mechanisms will be required to be used to prevent device identity spoofing, modification of device requests, modification of channel enablement information and impersonation of registered database services. Such security requirements may be in the scope of regulations which can vary between countries. The WG MUST consider these security aspects in the design of the protocol with sufficient flexibility to meet the needs of differing regulations/deployments. The working group will prefer to use existing IETF technologies and privacy mechanisms where possible. The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups, including IEEE 802.11af and IEEE 802.22 to begin with. The working group may also consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific bands. Goals and Milestones Sep 2011 Submit 'Problem Statement and Requirements for Querying a White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to the IESG for publication as Proposed Standard Apr 2012 Submit 'Data Structure for White Space query protocol' to the IESG for publication as Proposed Standard From Basavaraj.Patil@nokia.com Wed May 11 14:55:22 2011 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 C9E16E08AE for ; Wed, 11 May 2011 14:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT7R1NB6cgAR for ; Wed, 11 May 2011 14:55:22 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 099B5E089C for ; Wed, 11 May 2011 14:55:21 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4BLsPIY010288; Thu, 12 May 2011 00:55:21 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 May 2011 00:54:53 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 11 May 2011 23:54:52 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0289.008; Wed, 11 May 2011 23:54:52 +0200 From: To: , Thread-Topic: Updated charter text Thread-Index: AcwQJcG+0cyavHleTcObm3myTXJPwAAAD4+w Date: Wed, 11 May 2011 21:54:51 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719035DDE@008-AM1MPN1-024.mgdnok.nokia.com> References: <4A1C28E3-CD5E-4389-92BB-03FD064E4311@neustar.biz> In-Reply-To: <4A1C28E3-CD5E-4389-92BB-03FD064E4311@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2011 21:54:53.0288 (UTC) FILETIME=[0EF8A680:01CC1026] X-Nokia-AV: Clean Subject: Re: [paws] Updated charter text 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, 11 May 2011 21:55:22 -0000 Looks good.=20 -Raj -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Rosen, Brian Sent: Wednesday, May 11, 2011 4:53 PM To: paws@ietf.org Subject: [paws] Updated charter text I believe we are pretty close to getting approval. I want to confirm that = this is the charter text we want. I left "channel" as is. We need to fina= lize this, so at this point, if you can live with it, say so, and if not, m= ake specific wording proposals. Consider this an (informal, we're not a wo= rk group, and have no chairs) call for consensus. Protocol to Access White Space database (paws) ------------------------------------------------ Current Status: Proposed Working Group Last updated: 2011-05-11 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: paws@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spe= ctrum which can be used by the expanding wireless communications industry t= o provide more services in the usable spectrum. The concept of allowing sec= ondary transmissions (licensed or unlicensed) in frequencies allocated to a= primary user is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these seconda= ry transmissions do not interfere with the primary use of the spectrum. Oft= en, in a given physical location, the primary user(s) may not be using the = entire band allocated to them. The available spectrum for a secondary use w= ould then depend on the location of the secondary user. The primary user ma= y have a schedule when it uses the spectrum, which may be available for sec= ondary use outside that schedule. The fundamental issue is how to determine= for a specific location and specific time, if any of the primary spectrum = is available for secondary use. One simple mechanism is to use a geospatial= database that records protected contours for primary users, and require th= e secondary users to check the database prior to selecting what part of the= spectrum they use. Such databases could be available on the Internet for q= uery by users. In a typical implementation of geolocation and database to access TV white = space, a radio is configured with, or has the capability to determine its l= ocation in latitude and longitude. At power-on, before the device can trans= mit or use any of the spectrum set aside for secondary use, the device must= identify the relevant database to query, contact the database, provide its= geolocation and receive in return a list of unoccupied or "white space" sp= ectrum (for example, in a TV White space implementation, the list of availa= ble channels at that location). The device can then select one of the chann= els from the list and begin to transmit and receive on the selected channel= . The device must query the database subsequently on a periodic basis for a= list of unoccupied channels based on certain conditions, e.g. a fixed amou= nt of time has passed or the device has changed location beyond a specified= threshold. The databases are expected to be reachable via the Internet and the devices= querying these databases are expected to have some form of Internet connec= tivity, directly or indirectly. The databases may be country specific since= the available spectrum and regulations may vary, but the fundamental opera= tion of the protocol should be country independent, thus extensibility of d= ata structures will be required. The solution will not be tied to any speci= fic spectrum, country, or phy/mac/air interface but may incorporate relevan= t aspects of these as needed for proper operation. The working group will : - define the requirements for querying a white space database - standardize a protocol for querying the database, which includes a locati= on sensitive database discovery mechanism and security for the protocol, an= d application services. - Standardize the data structure to be carried by the query protocol. The protocol must protect both the channel enablement process and the privacy of users, and prevent unauthorized disclosure of a user's location. In some circumstances robust security mechanisms will be required to be used to prevent device identity spoofing, modification of device requests, modification of channel enablement information and impersonation of registered database services. Such security requirements may be in the scope of regulations which can vary between countries. The WG MUST consider these security aspects in the design of the protocol with sufficient flexibility to meet the needs of differing regulations/deployments. The working group will prefer to use existing IETF technologies and priva= cy mechanisms where possible. The Working Group will set up and maintain appropriate contact and liaison = with other relevant standards bodies and groups, including IEEE 802.11af an= d IEEE 802.22 to begin with. The working group may also consider input from= regulatory entities that are involved in the specification of the rules fo= r secondary use of spectrum in specific bands. Goals and Milestones Sep 2011 Submit 'Problem Statement and Requirements for Querying a White S= pace Database' to the IESG for publication as Informational Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to the IESG for publication as Proposed Standard Apr 2012 Submit 'Data Structure for White Space query protocol' to the IESG for publication as Proposed Standard _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From caulfield.jesse@gmail.com Wed May 11 19:33:06 2011 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 53E45E0696 for ; Wed, 11 May 2011 19:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqcFz21JDND2 for ; Wed, 11 May 2011 19:33:05 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4F6E0662 for ; Wed, 11 May 2011 19:33:05 -0700 (PDT) Received: by gxk19 with SMTP id 19so484584gxk.31 for ; Wed, 11 May 2011 19:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=k2nYsOAvVt94KvrqiH4G1TXEn9uxnHKOr6Q+IYa0R6E=; b=WSkor9TAlOT0Ethop+rl7sztYIDr2zEJ2QD4mD7eJoa05sUSI0l02PuO64iW+JXSu/ TB8jehQ3QK1/TclfHeI6XKfDJtgmjS6AYZ+7AZfdyqZcoZOzywxGu5OIew0KQ8ya6wIZ nFYERs5eAojudnwovtmok352dgT8XA1N9e2uI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=MDk0PWmgNJDhnwH8UNIU8HAUAxkR28lzD+6gDUDIPrjkl/SQ4/w4CMy2dKJ+BouKx1 QFTRR6F1+HR3KF0W/fqN/kVmhRBke2Db43gD0sulR2gNH4P8mJ6wS5bGmirjjNHwL3rA lIwEWpvLkh1xvBQgV+IQ6vHf+EqJbjQ0k9gT0= Received: by 10.236.193.36 with SMTP id j24mr12039969yhn.31.1305167584943; Wed, 11 May 2011 19:33:04 -0700 (PDT) Received: from JMCLaptop (pool-173-66-247-174.washdc.fios.verizon.net [173.66.247.174]) by mx.google.com with ESMTPS id j9sm474880ann.20.2011.05.11.19.33.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 19:33:03 -0700 (PDT) From: "Jesse Caulfield" To: "'Rosen, Brian'" , References: <4A1C28E3-CD5E-4389-92BB-03FD064E4311@neustar.biz> In-Reply-To: <4A1C28E3-CD5E-4389-92BB-03FD064E4311@neustar.biz> Date: Wed, 11 May 2011 22:32:58 -0400 Message-ID: <4dcb46df.0984650a.49bb.2276@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwQJcG+0cyavHleTcObm3myTXJPwAAJivbg Content-Language: en-us Subject: Re: [paws] Updated charter text 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, 12 May 2011 02:33:06 -0000 Hello Brian, I made some light edits to enhance readability and precision but no changes to the document's substance or spirit - the 2nd paragraph especially seemed to ramble. I hope the contribution is helpful but if my suggestions are too late then what you had before was OK. -- Jesse Edited text below: Description of Working Group: Governments around the world continue to search additional radio spectrum for wireless broadband and other emerging communications services. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to "unlock" existing spectrum for new use. A requirement for secondary transmissions is they must not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit on spectrum that may be available for secondary use, the device must identify the appropriate database to query, contact that database, provide its geolocation and receive a description of unoccupied or available "White Space" spectrum (for example, in a TV Bands implementation, the list of channels is returned). The device may then select one of the channels from the list and begin to transmit the selected channel. The device must periodically query a database for a list of unoccupied channels based on certain conditions, e.g. after a fixed amount of time has passed or if the device has changed location beyond a specified threshold. Databases are expected to be reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases may be country specific since the available spectrum and regulations may vary according to regulation but the protocol's fundamental operation should be country independent, thus extensibility of data structures will be required. The solution will not be tied to any specific spectrum, country, or phy/mac/air interface but may incorporate relevant aspects of these as needed for proper operation. The working group will : - define the requirements for querying a white space database - standardize a protocol for querying the database, which may include a location discovery mechanisms, security and application services. - Standardize the data structure to be carried by the query protocol. The protocol must protect the channel enablement process and user privacy and also prevent unauthorized disclosure of a user's location. In some circumstances robust security mechanisms may be required to prevent device identity spoofing, modification of device requests, modification of channel enablement information and impersonation of registered database services. Security requirements may in regulation regulations which can vary between countries. The WG MUST consider security aspects in the design of the protocol and provide for sufficient flexibility to accommodate differing regulations and country-specific implementations. The working group will prefer to use existing IETF technologies and privacy mechanisms where possible. The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups, including IEEE 802.11af and IEEE 802.22 to begin with. The working group may also consider input from regulatory entities that are involved in the specification of the rules for secondary use of spectrum in specific bands. Goals and Milestones Sep 2011 Submit 'Problem Statement and Requirements for Querying a White Space Database' to the IESG for publication as Informational Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to the IESG for publication as Proposed Standard Apr 2012 Submit 'Data Structure for White Space query protocol' to the IESG for publication as Proposed Standard From ietfdbh@comcast.net Wed May 11 21:15:53 2011 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 85F05E070A for ; Wed, 11 May 2011 21:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mLa3Dp3t38G for ; Wed, 11 May 2011 21:15:52 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by ietfa.amsl.com (Postfix) with ESMTP id C769EE06E3 for ; Wed, 11 May 2011 21:15:52 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta08.emeryville.ca.mail.comcast.net with comcast id iUA31g0010b6N64A8UFr7R; Thu, 12 May 2011 04:15:51 +0000 Received: from davidPC ([67.189.235.106]) by omta03.emeryville.ca.mail.comcast.net with comcast id iUFo1g00K2JQnJT8PUFpoL; Thu, 12 May 2011 04:15:50 +0000 From: "David Harrington" To: "'The IESG'" , Date: Thu, 12 May 2011 00:15:46 -0400 Message-ID: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 thread-index: AcwQW0SO9wVXLnOYRciJsnJqi4JPEQ== Subject: [paws] paws charter 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, 12 May 2011 04:15:53 -0000 Hi, I raised some issues about the charter text, and they do not seem to have been addressed in the latest proposed revision. 1) The work proposed is related to a database of non-IETF technologies (spectrum/channels,etc.). That raises the question of why IETF is the appropriate place to develop this solution. The answer is apparently that interoperability is important, and the IETF has already developed application-layer database protocols and relevant security and transport protocols that have been widely deployed in an interoperable manner. To justify this work as an IETF-appropriate effort, I believe it is important to try to reuse existing IETF protocols BEFORE designing any new IETF protocols for the PAWS-specific purpose. The current charter prominently states the WG will **standardize a protocol ... which includes a location sensitive database discovery mechanism and security for the protocol, and application services." This definitely sounds to me like a plan to develop a NEW protocol, designed for this special purpose rather than reusing existing protocols. As an addendum, the charter later on says " The working group will prefer to use existing IETF technologies and privacy mechanisms where possible." This placement makes reuse of existing standards sound like an afterthought, only included here because the IESG insisted on it. I do not think the charter text as written makes the reuse of existing IETF standards seem preferred over developing a brand new protocol. Some have asked why this charter, but not others, have this requirement. I point you to the proposed charter for CDNI for an example of another charter with similar text: "The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. ... It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter." I also point to the DECADE WG charter: "- An architecture document ... will identify DECADE's relationship with existing IETF protocols. Existing protocols will be used wherever possible and appropriate to support DECADE's requirements." 2) I raised concerns with the following text: "The Working Group will set up and maintain appropriate contact and liaison with other relevant standards bodies and groups, including IEEE 802.11af and IEEE 802.22 to begin with." Liasion relationships are the responsibility of the IAB. They make strategic decisions about which SDOs the IETF should, or should not, establish formal liaison relationships with. As per http://www.iab.org/liaisons/index.html: "It should be noted that the number of formal liaison relationships is somewhat small, as the best way for most organizations to work with the IETF is to do so through IETF working groups. The primary contact regarding the establishment of a new liaison relationship is the IAB." While the IAB may choose to delegate some of the contact work to specific WGs, I believe it is inappropriate to include in a WG's charter the authority to set up and maintain liasion relationships with other SDOs of the WG's choosing. The WG can request that the IAB setup and maintain liaison relationships with other SDOs. I think the charter text would be much better if it simply stated that "The WG will also coordinate with relevant groups outside the IETF such as 802.11af and IEEE 802.22" rather than stating it will "setup and maintain liaisons" with other standards bodies. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From dromasca@avaya.com Thu May 12 02:46:20 2011 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 7557EE06CB; Thu, 12 May 2011 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7Lt3bF+gXdP; Thu, 12 May 2011 02:46:16 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF73E070D; Thu, 12 May 2011 02:46:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwAAJKXy03GmAcF/2dsb2JhbACXPY40d61mAolNkhWDDxqCagSUOook X-IronPort-AV: E=Sophos;i="4.64,357,1301889600"; d="scan'208";a="187972513" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 May 2011 04:20:30 -0400 X-IronPort-AV: E=Sophos;i="4.64,357,1301889600"; d="scan'208";a="620572619" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 May 2011 04:20:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 May 2011 10:20:27 +0200 Message-ID: In-Reply-To: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] paws charter Thread-Index: AcwQW0SO9wVXLnOYRciJsnJqi4JPEQAIVYwg References: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "The IESG" , Subject: Re: [paws] paws charter 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, 12 May 2011 09:46:20 -0000 Hi,=20 I agree with both comments from David.=20 For the first point I suggest the following language:=20 s/The working group will prefer to use existing IETF technologies and privacy mechanisms where possible./The working group will re-use existing IETF protocols, privacy mechanisms and other technologies wherever they meet the requirements./ For the second point I support the wording as suggested by David. Regards, Dan=20 =20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 > Behalf Of David Harrington > Sent: Thursday, May 12, 2011 7:16 AM > To: 'The IESG'; paws@ietf.org > Subject: [paws] paws charter >=20 > Hi, >=20 > I raised some issues about the charter text, and they do not=20 > seem to have been addressed in the latest proposed revision. >=20 > 1) The work proposed is related to a database of non-IETF=20 > technologies (spectrum/channels,etc.). That raises the=20 > question of why IETF is the appropriate place to develop this=20 > solution. The answer is apparently that interoperability is=20 > important, and the IETF has already developed=20 > application-layer database protocols and relevant security=20 > and transport protocols that have been widely deployed in an=20 > interoperable manner. To justify this work as an=20 > IETF-appropriate effort, I believe it is important to try to=20 > reuse existing IETF protocols BEFORE designing any new IETF=20 > protocols for the PAWS-specific purpose. >=20 > The current charter prominently states the WG will=20 > **standardize a protocol ... which includes a location=20 > sensitive database discovery mechanism and security for the=20 > protocol, and application services." > This definitely sounds to me like a plan to develop a NEW=20 > protocol, designed for this special purpose rather than=20 > reusing existing protocols. As an addendum, the charter later=20 > on says " The working group will prefer to use existing IETF=20 > technologies and privacy mechanisms where possible." This=20 > placement makes reuse of existing standards sound like an=20 > afterthought, only included here because the IESG insisted on=20 > it. I do not think the charter text as written makes the=20 > reuse of existing IETF standards seem preferred over=20 > developing a brand new protocol. >=20 > Some have asked why this charter, but not others, have this=20 > requirement. I point you to the proposed charter for CDNI for=20 > an example of another charter with similar text:=20 > "The working group will only define solutions for aspects of=20 > the CDN Interconnection problem space that require direct=20 > communication or interoperation between CDNs. > In particular, the WG will not define: > - New session, transport or network protocols. > - New protocols for delivering content from a CDN to an End=20 > User/User Agent. > - New protocols for ingestion of content or metadata between=20 > a CSP and a CDN. > - New protocols for acquiring content across CDNs. > - Protocols and algorithms for intra-CDN operations. > - Support for Transparent Caching across CDNs. > - New applications consuming CDNI logs. > - Digital Right Management (DRM) mechanisms. >=20 > The CDNI WG will work with other IETF WGs to assess, and=20 > where appropriate, leverage protocols developed by those WGs,=20 > in order to realize the CDNI requirements and CDNI=20 > interfaces. For example, the WG may assess the suitability of=20 > the ALTO protocol as a protocol to enable downstream CDNs to=20 > exchange information which may aid an upstream CDN with=20 > making CDNI request routing decisions. The CDNI WG will also=20 > coordinate with relevant groups outside the IETF such as=20 > UltraViolet. ... It is expected that the CDNI interfaces will=20 > be realized using existing IETF protocols for transport and=20 > message exchange, and using existing object notation=20 > grammars/languages for the definition of CDNI objects and=20 > semantics. In the event that protocol extensions or new=20 > protocols are deemed necessary by the WG, the WG will recharter." >=20 > I also point to the DECADE WG charter: "- An architecture document ... > will identify DECADE's > relationship with existing IETF protocols. Existing protocols=20 > will be used wherever possible and appropriate to support=20 > DECADE's requirements." >=20 > 2) I raised concerns with the following text:=20 > "The Working Group will set up and maintain appropriate=20 > contact and liaison with other relevant standards bodies and=20 > groups, including IEEE 802.11af and IEEE 802.22 to begin with." > Liasion relationships are the responsibility of the IAB. They=20 > make strategic decisions about which SDOs the IETF should, or=20 > should not, establish formal liaison relationships with. As per > http://www.iab.org/liaisons/index.html: > "It should be noted that the number of formal liaison=20 > relationships is somewhat small, as the best way for most=20 > organizations to work with the IETF is to do so through IETF=20 > working groups. The primary contact regarding the=20 > establishment of a new liaison relationship is the IAB." >=20 > While the IAB may choose to delegate some of the contact work=20 > to specific WGs, I believe it is inappropriate to include in=20 > a WG's charter the authority to set up and maintain liasion=20 > relationships with other SDOs of the WG's choosing. The WG=20 > can request that the IAB setup and maintain liaison=20 > relationships with other SDOs. I think the charter text would=20 > be much better if it simply stated that "The WG will also=20 > coordinate with relevant groups outside the IETF such as=20 > 802.11af and IEEE 802.22" rather than stating it will "setup=20 > and maintain liaisons" with other standards bodies. >=20 >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf)=20 > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 From brian.rosen@neustar.biz Thu May 12 06:38:50 2011 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 6A369E06E0; Thu, 12 May 2011 06:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS0B-Lk9Kkin; Thu, 12 May 2011 06:38:45 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 52DF5E06BE; Thu, 12 May 2011 06:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1305207519; x=1620559619; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=fU+qYWZPYFudCBhCbad07 Boz1tpD83oQGyByJcprxq8=; b=Ve2SP8B74HDK/kFa3Tx+1PIDqSP4F7owvaVxR o4+PGa4s4WcFHtYi2aCq7IkNk+c50qCApBAWNjQLy2lRMfMPA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.45007077; Thu, 12 May 2011 09:38:38 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 12 May 2011 09:38:37 -0400 From: "Rosen, Brian" To: Dan Romascanu , David Harrington Date: Thu, 12 May 2011 09:38:34 -0400 Thread-Topic: [paws] paws charter Thread-Index: AcwQqeVdDpuOl08vTMuusBftvdT46g== Message-ID: <542DAE7B-63AB-4E1F-8D90-E1A80F4F6079@neustar.biz> References: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> 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: odTxTS4r9XZmyvVgHG3zRw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , The IESG Subject: Re: [paws] paws charter 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, 12 May 2011 13:38:50 -0000 In my strictly personal opinion, the query protocol will be a simple HTTP/X= ML webservice. The database discovery mechanism may make use of LoST, but that may not wor= k out so well, because there is, so far, only a need to locate to a country= , and not a region within a country, and we have more than one parameter fo= r search, not just location. As a long time ecrit participant, I'm biased = to use LoST if it works for us. We'll clearly reuse IETF security mechanisms. But we don't need to say any of that, because we have to make sure we get a= complete view of requirements before we choose solutions. You seem to need IETF boilerplate. EVERY work group should conside= r and prefer to use existing solutions. and not reinvent wheels. We should= write text that says that and put it in every charter. Clearly, this work= is no different in any way from 99% of work group charters in that regard,= and is nothing at all like CDNI, where some assumptions can be made at the= outset. We have no such assumptions. We'll create the requirements, and = see if we can match them to existing solutions. I strongly suggest the IES= G develop this boilerplate so the next group doesn't have to reinvent it. In the mean time, I am fine with using your language suggestion. I have no problem with David's proposed change in the IEEE liaison language= . The intention was to use the existing process. We just wanted to note w= hich groups we would need to use that process for. Brian On May 12, 2011, at 4:20 AM, Romascanu, Dan (Dan) wrote: >=20 >=20 > Hi,=20 >=20 > I agree with both comments from David.=20 >=20 > For the first point I suggest the following language:=20 >=20 > s/The working group will prefer to use existing IETF technologies and > privacy mechanisms where possible./The working group will re-use > existing IETF protocols, privacy mechanisms and other technologies > wherever they meet the requirements./ >=20 > For the second point I support the wording as suggested by David. >=20 > Regards, >=20 > Dan=20 >=20 >=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >> Behalf Of David Harrington >> Sent: Thursday, May 12, 2011 7:16 AM >> To: 'The IESG'; paws@ietf.org >> Subject: [paws] paws charter >>=20 >> Hi, >>=20 >> I raised some issues about the charter text, and they do not=20 >> seem to have been addressed in the latest proposed revision. >>=20 >> 1) The work proposed is related to a database of non-IETF=20 >> technologies (spectrum/channels,etc.). That raises the=20 >> question of why IETF is the appropriate place to develop this=20 >> solution. The answer is apparently that interoperability is=20 >> important, and the IETF has already developed=20 >> application-layer database protocols and relevant security=20 >> and transport protocols that have been widely deployed in an=20 >> interoperable manner. To justify this work as an=20 >> IETF-appropriate effort, I believe it is important to try to=20 >> reuse existing IETF protocols BEFORE designing any new IETF=20 >> protocols for the PAWS-specific purpose. >>=20 >> The current charter prominently states the WG will=20 >> **standardize a protocol ... which includes a location=20 >> sensitive database discovery mechanism and security for the=20 >> protocol, and application services." >> This definitely sounds to me like a plan to develop a NEW=20 >> protocol, designed for this special purpose rather than=20 >> reusing existing protocols. As an addendum, the charter later=20 >> on says " The working group will prefer to use existing IETF=20 >> technologies and privacy mechanisms where possible." This=20 >> placement makes reuse of existing standards sound like an=20 >> afterthought, only included here because the IESG insisted on=20 >> it. I do not think the charter text as written makes the=20 >> reuse of existing IETF standards seem preferred over=20 >> developing a brand new protocol. >>=20 >> Some have asked why this charter, but not others, have this=20 >> requirement. I point you to the proposed charter for CDNI for=20 >> an example of another charter with similar text:=20 >> "The working group will only define solutions for aspects of=20 >> the CDN Interconnection problem space that require direct=20 >> communication or interoperation between CDNs. >> In particular, the WG will not define: >> - New session, transport or network protocols. >> - New protocols for delivering content from a CDN to an End=20 >> User/User Agent. >> - New protocols for ingestion of content or metadata between=20 >> a CSP and a CDN. >> - New protocols for acquiring content across CDNs. >> - Protocols and algorithms for intra-CDN operations. >> - Support for Transparent Caching across CDNs. >> - New applications consuming CDNI logs. >> - Digital Right Management (DRM) mechanisms. >>=20 >> The CDNI WG will work with other IETF WGs to assess, and=20 >> where appropriate, leverage protocols developed by those WGs,=20 >> in order to realize the CDNI requirements and CDNI=20 >> interfaces. For example, the WG may assess the suitability of=20 >> the ALTO protocol as a protocol to enable downstream CDNs to=20 >> exchange information which may aid an upstream CDN with=20 >> making CDNI request routing decisions. The CDNI WG will also=20 >> coordinate with relevant groups outside the IETF such as=20 >> UltraViolet. ... It is expected that the CDNI interfaces will=20 >> be realized using existing IETF protocols for transport and=20 >> message exchange, and using existing object notation=20 >> grammars/languages for the definition of CDNI objects and=20 >> semantics. In the event that protocol extensions or new=20 >> protocols are deemed necessary by the WG, the WG will recharter." >>=20 >> I also point to the DECADE WG charter: "- An architecture document ... >> will identify DECADE's >> relationship with existing IETF protocols. Existing protocols=20 >> will be used wherever possible and appropriate to support=20 >> DECADE's requirements." >>=20 >> 2) I raised concerns with the following text:=20 >> "The Working Group will set up and maintain appropriate=20 >> contact and liaison with other relevant standards bodies and=20 >> groups, including IEEE 802.11af and IEEE 802.22 to begin with." >> Liasion relationships are the responsibility of the IAB. They=20 >> make strategic decisions about which SDOs the IETF should, or=20 >> should not, establish formal liaison relationships with. As per >> http://www.iab.org/liaisons/index.html: >> "It should be noted that the number of formal liaison=20 >> relationships is somewhat small, as the best way for most=20 >> organizations to work with the IETF is to do so through IETF=20 >> working groups. The primary contact regarding the=20 >> establishment of a new liaison relationship is the IAB." >>=20 >> While the IAB may choose to delegate some of the contact work=20 >> to specific WGs, I believe it is inappropriate to include in=20 >> a WG's charter the authority to set up and maintain liasion=20 >> relationships with other SDOs of the WG's choosing. The WG=20 >> can request that the IAB setup and maintain liaison=20 >> relationships with other SDOs. I think the charter text would=20 >> be much better if it simply stated that "The WG will also=20 >> coordinate with relevant groups outside the IETF such as=20 >> 802.11af and IEEE 802.22" rather than stating it will "setup=20 >> and maintain liaisons" with other standards bodies. >>=20 >>=20 >> David Harrington >> Director, IETF Transport Area >> ietfdbh@comcast.net (preferred for ietf)=20 >> dbharrington@huaweisymantec.com >> +1 603 828 1401 (cell) >>=20 >> _______________________________________________ >> 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 From hannes.tschofenig@gmx.net Thu May 12 06:48:29 2011 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 E07F6E07B3 for ; Thu, 12 May 2011 06:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3PM3rY27bR6 for ; Thu, 12 May 2011 06:48:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B5FA9E0688 for ; Thu, 12 May 2011 06:48:24 -0700 (PDT) Received: (qmail invoked by alias); 12 May 2011 13:48:23 -0000 Received: from h87.s239.verisign.com (EHLO [10.131.32.72]) [216.168.239.87] by mail.gmx.net (mp038) with SMTP; 12 May 2011 15:48:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+AEMQsctCAyP1eGiTmuZWeVtfPS6/dySdVH47u9D bW3KAApSVxC3XF Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <542DAE7B-63AB-4E1F-8D90-E1A80F4F6079@neustar.biz> Date: Thu, 12 May 2011 16:48:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8D35AEAA-A3C0-490B-8BCF-762F21B4EE93@gmx.net> References: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> <542DAE7B-63AB-4E1F-8D90-E1A80F4F6079@neustar.biz> To: Brian Rosen , Dan Romascanu X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: paws@ietf.org, Hannes Tschofenig , David Harrington , The IESG Subject: Re: [paws] paws charter 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, 12 May 2011 13:48:30 -0000 Brian, Dan,=20 I wonder whether we have already started designing the protocol during = the charter process.=20 I don't think that's the best way to spend our time.=20 I am also not overly concerned that an IETF working group would not = re-use IETF protocols. In general we like our protocols and reuse them. = It is fine to say that we care about privacy, security, etc. aren't we = doing that anyway regardless whether the charter text says that.=20 I would only add something if some readers unfamiliar with the IETF work = (and overall process) find the page and need to be aware of an important = aspect of this work.=20 Ciao Hannes On May 12, 2011, at 4:38 PM, Rosen, Brian wrote: > In my strictly personal opinion, the query protocol will be a simple = HTTP/XML webservice. >=20 > The database discovery mechanism may make use of LoST, but that may = not work out so well, because there is, so far, only a need to locate to = a country, and not a region within a country, and we have more than one = parameter for search, not just location. As a long time ecrit = participant, I'm biased to use LoST if it works for us. >=20 > We'll clearly reuse IETF security mechanisms. >=20 > But we don't need to say any of that, because we have to make sure we = get a complete view of requirements before we choose solutions. >=20 > You seem to need IETF boilerplate. EVERY work group should = consider and prefer to use existing solutions. and not reinvent wheels. = We should write text that says that and put it in every charter. = Clearly, this work is no different in any way from 99% of work group = charters in that regard, and is nothing at all like CDNI, where some = assumptions can be made at the outset. We have no such assumptions. = We'll create the requirements, and see if we can match them to existing = solutions. I strongly suggest the IESG develop this boilerplate so the = next group doesn't have to reinvent it. >=20 > In the mean time, I am fine with using your language suggestion. >=20 > I have no problem with David's proposed change in the IEEE liaison = language. The intention was to use the existing process. We just = wanted to note which groups we would need to use that process for. >=20 > Brian >=20 > On May 12, 2011, at 4:20 AM, Romascanu, Dan (Dan) wrote: >=20 >>=20 >>=20 >> Hi,=20 >>=20 >> I agree with both comments from David.=20 >>=20 >> For the first point I suggest the following language:=20 >>=20 >> s/The working group will prefer to use existing IETF technologies and >> privacy mechanisms where possible./The working group will re-use >> existing IETF protocols, privacy mechanisms and other technologies >> wherever they meet the requirements./ >>=20 >> For the second point I support the wording as suggested by David. >>=20 >> Regards, >>=20 >> Dan=20 >>=20 >>=20 >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On=20 >>> Behalf Of David Harrington >>> Sent: Thursday, May 12, 2011 7:16 AM >>> To: 'The IESG'; paws@ietf.org >>> Subject: [paws] paws charter >>>=20 >>> Hi, >>>=20 >>> I raised some issues about the charter text, and they do not=20 >>> seem to have been addressed in the latest proposed revision. >>>=20 >>> 1) The work proposed is related to a database of non-IETF=20 >>> technologies (spectrum/channels,etc.). That raises the=20 >>> question of why IETF is the appropriate place to develop this=20 >>> solution. The answer is apparently that interoperability is=20 >>> important, and the IETF has already developed=20 >>> application-layer database protocols and relevant security=20 >>> and transport protocols that have been widely deployed in an=20 >>> interoperable manner. To justify this work as an=20 >>> IETF-appropriate effort, I believe it is important to try to=20 >>> reuse existing IETF protocols BEFORE designing any new IETF=20 >>> protocols for the PAWS-specific purpose. >>>=20 >>> The current charter prominently states the WG will=20 >>> **standardize a protocol ... which includes a location=20 >>> sensitive database discovery mechanism and security for the=20 >>> protocol, and application services." >>> This definitely sounds to me like a plan to develop a NEW=20 >>> protocol, designed for this special purpose rather than=20 >>> reusing existing protocols. As an addendum, the charter later=20 >>> on says " The working group will prefer to use existing IETF=20 >>> technologies and privacy mechanisms where possible." This=20 >>> placement makes reuse of existing standards sound like an=20 >>> afterthought, only included here because the IESG insisted on=20 >>> it. I do not think the charter text as written makes the=20 >>> reuse of existing IETF standards seem preferred over=20 >>> developing a brand new protocol. >>>=20 >>> Some have asked why this charter, but not others, have this=20 >>> requirement. I point you to the proposed charter for CDNI for=20 >>> an example of another charter with similar text:=20 >>> "The working group will only define solutions for aspects of=20 >>> the CDN Interconnection problem space that require direct=20 >>> communication or interoperation between CDNs. >>> In particular, the WG will not define: >>> - New session, transport or network protocols. >>> - New protocols for delivering content from a CDN to an End=20 >>> User/User Agent. >>> - New protocols for ingestion of content or metadata between=20 >>> a CSP and a CDN. >>> - New protocols for acquiring content across CDNs. >>> - Protocols and algorithms for intra-CDN operations. >>> - Support for Transparent Caching across CDNs. >>> - New applications consuming CDNI logs. >>> - Digital Right Management (DRM) mechanisms. >>>=20 >>> The CDNI WG will work with other IETF WGs to assess, and=20 >>> where appropriate, leverage protocols developed by those WGs,=20 >>> in order to realize the CDNI requirements and CDNI=20 >>> interfaces. For example, the WG may assess the suitability of=20 >>> the ALTO protocol as a protocol to enable downstream CDNs to=20 >>> exchange information which may aid an upstream CDN with=20 >>> making CDNI request routing decisions. The CDNI WG will also=20 >>> coordinate with relevant groups outside the IETF such as=20 >>> UltraViolet. ... It is expected that the CDNI interfaces will=20 >>> be realized using existing IETF protocols for transport and=20 >>> message exchange, and using existing object notation=20 >>> grammars/languages for the definition of CDNI objects and=20 >>> semantics. In the event that protocol extensions or new=20 >>> protocols are deemed necessary by the WG, the WG will recharter." >>>=20 >>> I also point to the DECADE WG charter: "- An architecture document = ... >>> will identify DECADE's >>> relationship with existing IETF protocols. Existing protocols=20 >>> will be used wherever possible and appropriate to support=20 >>> DECADE's requirements." >>>=20 >>> 2) I raised concerns with the following text:=20 >>> "The Working Group will set up and maintain appropriate=20 >>> contact and liaison with other relevant standards bodies and=20 >>> groups, including IEEE 802.11af and IEEE 802.22 to begin with." >>> Liasion relationships are the responsibility of the IAB. They=20 >>> make strategic decisions about which SDOs the IETF should, or=20 >>> should not, establish formal liaison relationships with. As per >>> http://www.iab.org/liaisons/index.html: >>> "It should be noted that the number of formal liaison=20 >>> relationships is somewhat small, as the best way for most=20 >>> organizations to work with the IETF is to do so through IETF=20 >>> working groups. The primary contact regarding the=20 >>> establishment of a new liaison relationship is the IAB." >>>=20 >>> While the IAB may choose to delegate some of the contact work=20 >>> to specific WGs, I believe it is inappropriate to include in=20 >>> a WG's charter the authority to set up and maintain liasion=20 >>> relationships with other SDOs of the WG's choosing. The WG=20 >>> can request that the IAB setup and maintain liaison=20 >>> relationships with other SDOs. I think the charter text would=20 >>> be much better if it simply stated that "The WG will also=20 >>> coordinate with relevant groups outside the IETF such as=20 >>> 802.11af and IEEE 802.22" rather than stating it will "setup=20 >>> and maintain liaisons" with other standards bodies. >>>=20 >>>=20 >>> David Harrington >>> Director, IETF Transport Area >>> ietfdbh@comcast.net (preferred for ietf)=20 >>> dbharrington@huaweisymantec.com >>> +1 603 828 1401 (cell) >>>=20 >>> _______________________________________________ >>> 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 From housley@vigilsec.com Thu May 12 07:16:53 2011 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 83CA6E0682; Thu, 12 May 2011 07:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPUznxVufM6c; Thu, 12 May 2011 07:16:49 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 962A5E0680; Thu, 12 May 2011 07:16:49 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 18E43F24055; Thu, 12 May 2011 10:16:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 0w2WbGmYQoSV; Thu, 12 May 2011 10:16:35 -0400 (EDT) Received: from [10.131.32.81] (h87.s239.verisign.com [216.168.239.87]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 4AA8FF240F8; Thu, 12 May 2011 10:16:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> Date: Thu, 12 May 2011 10:16:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> To: "David Harrington" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 12 May 2011 07:38:06 -0700 Cc: paws@ietf.org, 'The IESG' Subject: Re: [paws] paws charter 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, 12 May 2011 14:16:53 -0000 I suggest that there is a straightforward way to handle this concern. I = suggest: The WG will coordinate with other standards bodies that are expected to = make use of PAWS, including IEEE 802.11af and IEEE 802.22. Where = liaison relationships are in place, the liaison managers will interface = between the groups. Russ On May 12, 2011, at 12:15 AM, David Harrington wrote: > 2) I raised concerns with the following text:=20 > "The Working Group will set up and maintain appropriate contact and > liaison with other relevant standards bodies and groups, including > IEEE > 802.11af and IEEE 802.22 to begin with." > Liasion relationships are the responsibility of the IAB. They make > strategic decisions about which SDOs the IETF should, or should not, > establish formal liaison relationships with. As per > http://www.iab.org/liaisons/index.html: > "It should be noted that the number of formal liaison relationships is > somewhat small, as the best way for most organizations to work with > the IETF is to do so through IETF working groups. The primary contact > regarding the establishment of a new liaison relationship is the IAB." >=20 > While the IAB may choose to delegate some of the contact work to > specific WGs, I believe it is inappropriate to include in a WG's > charter the authority to set up and maintain liasion relationships > with other SDOs of the WG's choosing. The WG can request that the IAB > setup and maintain liaison relationships with other SDOs. I think the > charter text would be much better if it simply stated that "The WG > will also coordinate with relevant groups outside the IETF such as > 802.11af and IEEE 802.22" rather than stating it will "setup and > maintain liaisons" with other standards bodies. From Basavaraj.Patil@nokia.com Mon May 23 12:15:06 2011 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 A796DE07E0; Mon, 23 May 2011 12:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, 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 eWCMywQwlptc; Mon, 23 May 2011 12:15:05 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 715DCE0809; Mon, 23 May 2011 12:15:05 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4NJF1rl029514; Mon, 23 May 2011 22:15:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 May 2011 22:14:36 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 23 May 2011 21:14:36 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Mon, 23 May 2011 21:14:35 +0200 From: To: , , Thread-Topic: [paws] paws charter Thread-Index: AcwQW0SO9wVXLnOYRciJsnJqi4JPEQI57OuA Date: Mon, 23 May 2011 19:14:35 +0000 Message-ID: In-Reply-To: <145DE30A9D4E407A8F018BA21FF6C4C8@davidPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.138] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <38EB50EDB8D1444597454B950BBF4793@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 May 2011 19:14:36.0600 (UTC) FILETIME=[A7EF8380:01CC197D] X-Nokia-AV: Clean Subject: Re: [paws] paws charter 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, 23 May 2011 19:15:06 -0000 David, The issues that you had raised previously were IMO irrelevant for the most part. You did not provide valid reasoning behind your statements or any explanation either to my earlier email requesting for the same. Further comments inline: On 5/11/11 11:15 PM, "ext David Harrington" wrote: >Hi, > >I raised some issues about the charter text, and they do not seem to >have been addressed in the latest proposed revision. > >1) The work proposed is related to a database of non-IETF technologies >(spectrum/channels,etc.). That raises the question of why IETF is the >appropriate place to develop this solution. The answer is apparently >that interoperability is important, and the IETF has already developed >application-layer database protocols and relevant security and >transport protocols that have been widely deployed in an interoperable >manner. To justify this work as an IETF-appropriate effort, I believe >it is important to try to reuse existing IETF protocols BEFORE >designing any new IETF protocols for the PAWS-specific purpose. The question as to why the IETF is the right place to do this work has been discussed at length and at the BoF. There was strong consensus regarding the same. Yet you continue to question this aspect. Reuse of existing protocols has also been mentioned as a possibility. The people involved in the BoF recognize it. Mandating that the PAWS protocol MUST reuse existing IETF protocols before we have had a chance to even get into the design of the protocol seems premature and an immature suggestion. > >The current charter prominently states the WG will **standardize a >protocol ... which includes a location sensitive database discovery >mechanism and security for the protocol, and application services." >This definitely sounds to me like a plan to develop a NEW protocol, >designed for this special purpose rather than reusing existing >protocols. As an addendum, the charter later on says " The working >group will prefer to use existing IETF technologies and privacy >mechanisms where possible." This placement makes reuse of existing >standards sound like an afterthought, only included here because the >IESG insisted on it. I do not think the charter text as written makes >the reuse of existing IETF standards seem preferred over developing a >brand new protocol. And that is by intent and design because we really do not have the visibility whether an existing protocol (IETF) will meet the requirements for PAWS. > >Some have asked why this charter, but not others, have this >requirement. I point you to the proposed charter for CDNI for an >example of another charter with similar text: >"The working group will only define solutions for aspects of the CDN >Interconnection problem space that require direct communication or >interoperation between CDNs. >In particular, the WG will not define: >- New session, transport or network protocols. >- New protocols for delivering content from a CDN to an End User/User >Agent. >- New protocols for ingestion of content or metadata between a CSP and >a CDN. >- New protocols for acquiring content across CDNs. >- Protocols and algorithms for intra-CDN operations. >- Support for Transparent Caching across CDNs. >- New applications consuming CDNI logs. >- Digital Right Management (DRM) mechanisms. > >The CDNI WG will work with other IETF WGs to assess, and where >appropriate, leverage protocols developed by those WGs, in order to >realize the CDNI requirements and CDNI interfaces. For example, the WG >may assess the suitability of the ALTO protocol as a protocol to >enable downstream CDNs to exchange information which may aid an >upstream CDN with making CDNI request routing decisions. The CDNI WG >will also coordinate with relevant groups outside the IETF such as >UltraViolet. ... It is expected that the CDNI interfaces will be >realized using existing IETF protocols for transport and message >exchange, and using existing object notation grammars/languages for >the definition of CDNI objects and semantics. In the event that >protocol extensions or new protocols are deemed necessary by the WG, >the WG will recharter." > >I also point to the DECADE WG charter: "- An architecture document ... >will identify DECADE's >relationship with existing IETF protocols. Existing protocols will be >used wherever possible and appropriate to support DECADE's >requirements." > >2) I raised concerns with the following text: >"The Working Group will set up and maintain appropriate contact and >liaison with other relevant standards bodies and groups, including >IEEE >802.11af and IEEE 802.22 to begin with." >Liasion relationships are the responsibility of the IAB. They make >strategic decisions about which SDOs the IETF should, or should not, >establish formal liaison relationships with. As per >http://www.iab.org/liaisons/index.html: >"It should be noted that the number of formal liaison relationships is >somewhat small, as the best way for most organizations to work with >the IETF is to do so through IETF working groups. The primary contact >regarding the establishment of a new liaison relationship is the IAB." Right. We understand the process for establishing liaisons. So I don=B9t know what is your issue here as far as liaisons are concerned. The question about liaisons was also discussed at the BoF. While IEEE 802 was noted as one SDO with which we should establish a liaison, it was also mentioned that liaisons could be established with other bodies as well in the future that are relevant w.r.t the WS technology. The IESG IMO appears to have an opinion that overrides the community consensus in this case and acting in an authoritarian way that does not suit the ethos/taos of the IETF. -Raj > >While the IAB may choose to delegate some of the contact work to >specific WGs, I believe it is inappropriate to include in a WG's >charter the authority to set up and maintain liasion relationships >with other SDOs of the WG's choosing. The WG can request that the IAB >setup and maintain liaison relationships with other SDOs. I think the >charter text would be much better if it simply stated that "The WG >will also coordinate with relevant groups outside the IETF such as >802.11af and IEEE 802.22" rather than stating it will "setup and >maintain liaisons" with other standards bodies. > > >David Harrington >Director, IETF Transport Area >ietfdbh@comcast.net (preferred for ietf) >dbharrington@huaweisymantec.com >+1 603 828 1401 (cell) > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws