From nobody Mon Apr 7 09:54:22 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5E01A047A for ; Mon, 7 Apr 2014 09:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSjpTz_iMWdi for ; Mon, 7 Apr 2014 09:54:16 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2431F1A07BF for ; Mon, 7 Apr 2014 09:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1396889646; x=1428425646; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=XSo6fGgTpoFzlL3ZXAEQC1HoyS7+BgzV2536wvrJbY8=; b=Jk+SsxJBvppWyG1qYPiNduluhHB8Kos+m438VD9oToK4EbItzD5Mr4wb 2hYSc3jni0ojrGmedPrPvfRQcicJIIqinFut8Zl6dXTnT4XwjrsKqFkMV g2T/Czxrw8sEPlVKVbe4/y4rtVQyQV6v7HB4Rh0/Sfe2ysp0xOG2ydJDk U=; X-IronPort-AV: E=McAfee;i="5400,1158,7401"; a="27152413" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 07 Apr 2014 09:54:06 -0700 X-IronPort-AV: E=Sophos;i="4.97,811,1389772800"; d="scan'208";a="29080117" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Apr 2014 09:54:06 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Apr 2014 09:54:05 -0700 Message-ID: <5342D82B.2080001@qti.qualcomm.com> Date: Mon, 7 Apr 2014 11:54:03 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/3261fRZy6mRKcbapBALo5imFZNQ Subject: [paws] AD Evaluation of draft-ietf-paws-protocol-11 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 07 Apr 2014 16:54:21 -0000 Greetings, At long last, I completed my AD Evaluation of the protocol document to prepare for IETF Last Call. Below are a *large* number of comments. As I said with the requirements document: Don't panic. Many of these are editorial, are about some overuses of MUST/SHOULD/etc., or are clarifications to make sure the protocol requirements are separate from the regulatory requirements. The truly substantive issues are: - Section 4.1 on database discovery. - Section 9 on IANA registration policies. I don't think either will be a big deal to solve, but they will take some thought. Coincidentally, we just today received a (very late) disclosure of IPR regarding database discovery . Given my comments on 4.1, my general suggestion is that we think about making the entire discussion of database discovery clearly non-normative for this document, simply saying "The device needs to get a URI of the database, and whether that is done through pre-configuration, a Listing Server, or some Database Discovery mechanism, it is all outside of the scope of this document", and then move all discussion of this to whatever discovery document the WG wants to attempt. (I will separately chat with the chairs regarding the lateness of the disclosure and see what, if anything, there is to be done about that, and how the WG discussion of the disclosure itself should proceed.) So, below is the list. I presume Vincent will go through all of the editorial or clarifying ones and tick them off. If anyone else notices something that you think would be a substantive change that needs discussion (beyond 4.1 and 9), please do make a special note of them so the group can address it. pr --- Global changes: Change "regulatory rules" to "Ruleset". Change "regulatory specifics" to "Ruleset specifics". Change "regulatory-specific" to "Ruleset-specific". Change "depends on regulatory domain" to "optional" in the tables. The description is sufficient to explain the dependency on regulatory domains. That said, throughout the descriptions of parameters, there are lots of places that say something like, "Some regulatory domains may require it." You could say something like that in a note at the top of the section and not have to repeat it. For any optional parameter, some regulatory domain might require it, even where you don't say that, so putting it on only some of the optional parameters is wrong, and putting it all of them seems silly. In the tables where it lists "*other" parameters, you could add "optional". 2.2: NEW Regulatory Domain: A location where certain rules apply to the use of white space spectrum, including the operation of databases and devices involved in its use. A regulatory domain is normally defined by a unit of government for a particular country, but the PAWS protocol is agnostic as to how a regulatory domain is constructed. OLD Ruleset: A set of rules that governs operations of white space devices and Spectrum Databases within a regulatory domain. The same set of rules may be used by more than one regulatory domain. NEW Ruleset: An IANA-registered set of rules that governs operations of white space devices and Spectrum Databases. A regulatory authority can define and register its own rulesets, or can use rulesets that have been previously registered by others. 3.1: For a Master Device that supports multiple rulesets and operates with multiple databases in multiple regulatory domains Strike "in multiple regulatory domains". 4: o Device Registration (Section 4.3) MAY be used by the Master Device and MAY be implemented by the Database as a separate component or as part of the Available Spectrum Query (Section 4.4) component. The second "MAY" is confusing. I think you instead mean, "and MAY be implemented by the Database, either as a separate component or as part of the Available Spectrum Query (Section 4.4) component." o Device Validation (Section 4.5) MAY be used by the Master Device. Shouldn't you add "and the Database"? For each of the notification and validation bullets: Some regulatory domains mandate notifications, which would mandate their use by the Master Device and mandate their implementation by the Database. I'd strike these from the bullets and put them in a note after the definitions: Note: Some regulatory domains mandate the use notifications and validation. In such cases, obviously their implementation and use would be necessary. I would add a last paragraph, something like: The parameter tables in this section and Section 5 are for reference and contain the name of each parameter, the data type of each parameter, and whether the existence of the parameter is required for the protocol transaction in question. The data types are either defined in Section 5 or are part of the base data types specified in The JavaScript Object Notation (JSON) Data Interchange Format [RFC7159]. See Section 5 and Section 6 for more detail on data types and encodings. 4.1: The first paragraph and three bullets seem completely unnecessary and I think they should be removed. Then, rewrite the "Preconfiguration" as follows: Preconfiguration The Master Device can be provisioned statically with the URI of one or more Databases. For example, in a particular regulatory domain there may be a number of certified databases that any device operating in that domain is permitted to connect to, and those URIs can be provisioned in the device. Alternatively, a Master Device can be provisioned statically with the URI of a Database Listing Server, from which it can retrieve URIs of available Databases. (However, see comments on 4.1.1.) There should probably be a non-normative reference to the bootstrapping draft in this section. Last sentence: Change "regulators" to "regulatory domains". 4.1.1: I'm a little concerned about the discussion of Listing Servers, especially the last sentence of this section. Are we saying that we are not defining the Listing Server protocol at all? That is, as a device, I might be handed a URI for a Listing Server, but this document gives me no protocol with which to communicate with the Listing Server? The protocol is completely out-of-band? That's not interoperable, and if left this way, I think the discussion of Listing Servers might have to be completely removed from the document. If we are going to discuss Listing Servers, there's still work to be done on this section. I think the first paragraph needs a total rewrite. There's no need to talk about the mandates of regulators here. Here's my suggestion: The use of a Database Listing Server allows the Device to determine the URIs of available databases. When a Listing Server is used, the Device can save the database list and SHOULD contact the Database Listing Server periodically to update its list. The time between such updates MUST be no longer than one week, although the update interval can be shorter (for example, when required by the applicable regulatory domain). Strike the last sentence of the second paragraph. The last sentence needs to be replaced with the way to get information out of the Listing Server. 4.2: Strike "regulatory-dependent". 4.4: In item 4: OLD It MUST return an error with appropriate error code (Table 1), if validation fails. NEW If validation fails, the Database returns an appropriate error code (Table 1). Also, I suggest changing the name of the "REQUIRED" error code to "MISSING" or "MISSING_PARAM" to avoid confusing it with the 2119 terminology. In item 5: OLD the Database MUST indicate so in the response message. NEW the Database will indicate so in the response message. In item 6: What happens if there is a request for spectrum-usage in the available-spectrum response but the Master Device never sends the spectrum-usage notification? Does the database send back an unsolicited error? Is this a *protocol level* violation, or just a regulatory one? If it's just regulatory, change "MUST send" to "will send" or "sends". 4.4.1: deviceDesc and location - In the table, change "optional" to "see description". There are times where it is *protocol* required. requestType is of type "string", but there are no particular limits (either length or characters) on what can be in it. You can define it here or in section 5 if you like, but some indication of what can go in there seems important. Change "regulatory specifics" to "Ruleset specifics". 4.4.2: "SHOULD be sorted in increasing time": Why? If there's a good reason, what are the exceptions when you might not do it? Change "This SHOULD be used by the Device" to "This can be used by the Device". "...is REQUIRED and MUST include at least one entry" seems redundant. I think you can strike "is REQUIRED and". 4.4.3: OLD The Database MUST interpret each location in the batch request as if it were an independent request and MUST return results consistent with multiple individual AVAIL_SPECTRUM_REQ (Section 4.4.1) requests. The request message for NEW The Database interprets each location in the batch request as if it were an independent request and returns results consistent with multiple individual AVAIL_SPECTRUM_REQ (Section 4.4.1) requests, but returns these results in a batched response (Section 4.4.4). The request message for deviceDesc: Change to "optional" to "see description". 4.4.4: geoSpectrumSpecs: I think this is "optional". See below. Change "This SHOULD be used by the Device" to "This can be used by the Device". Change "The Device MUST NOT make any assumptions on the order of the entries in the list and..." to "The order of the entries in the list is not significant and the Device..." 4.4.5: OLD The spectrum-use notification message MUST contain the geo-location of the Device. Some regulatory domains may mandate additional parameters. NEW The spectrum-use notification message indicates the spectrum anticipated to be used by the device. (The discussion of what's required is below and needn't be mentioned here. In any event, the geo-location is not always required -- i.e., for a Slave Device -- so the sentence is wrong.) In spectra, it says "SHOULD match". This doesn't sound like an interoperability requirement to me; if it's a SHOULD, the Database still has to deal with a different resolution than the one from the AVAIL_SPECTRUM_RESP. If this is needed for interoperability, you should change it to a MUST. If not, I'd drop this. 4.5: Typo: Change "and entry" to "an entry". 5.1: For "point" and "region" in the table, change "optional" to "see description". Change "the orientation MUST be interpreted as 0" to "the default value is 0". Change "its value MUST be interpreted as 95" to "the default value is 95". 5.2: Change "regulatory-specific ID" to "manufacturer's ID". This section mentions 3 parameters that "MUST NOT exceed 64 characters". If these were limited to US-ASCII, that would also mean 64 octets, but 64 characters is not necessarily 64 octets. Some definition is probably needed for what can specifically go in each one. You could even put in the ABNF for each. For example: serialNumber = 1*64name-char name-char = ALPHA / DIGIT / "_" Obviously you can limit them as you see fit. If you want internationalization, I would obviously limit it to UTF-8. OLD This SHOULD represent the name of the device manufacturer, SHOULD be consistent across all devices from the same manufacturer, and SHOULD be distinct from that of other manufacturers. NEW This represents the name of the device manufacturer, and therefore ought to be consistent across all devices from the same manufacturer and distinct from that of other manufacturers. 5.3: If AGL is default, then why is heightType REQUIRED if height is provided? 5.4: Change "Each FrequencyRange element MUST contain" to "Each FrequencyRange element contains". Why is it SHOULD NOT instead of MUST NOT return frequencies outside of the range? 5.6: Are you sure you want to limit authority to 2-letter country codes in the protocol with a MUST? I could imagine in the future authority being a different political entity (e.g., maybe there will be an EU authority some day). Instead of MUST, would "will normally" make sense here? A reference to 8.2 for rulesetID would be helpful here. For "maxLocationChange" and "maxPollingSecs" in the table, change "optional" to "see description". 5.8: You need to define length and content limits for name and uri if applicable. 5.9: "SHOULD be sorted in increasing time": Why? If there's a good reason, what are the exceptions when you might not do it? Change "MUST be interpreted by the Device as" to "are". "When specified, it SHOULD correspond to the frequency ranges governed by the ruleset." I don't know what that means. Please explain. Change "which the Device MUST treat as the same as a false value" to "in which case the default value is false". For the following: If this parameter is present and its value is true, the Device MUST send a SPECTRUM_USE_NOTIFY (Section 4.4.5) message to the Database Again, what happens if there is a request for spectrum-usage in the available-spectrum response but the Master Device never sends the spectrum-usage notification? Does the database send back an unsolicited error? Is this a *protocol level* violation, or just a regulatory one? If it's just regulatory, change "MUST send" to "will send" or "sends". 5.11: "such that the Device MUST satisfy all the conditions" seems wrong. Don't you just mean, "such that the spectrum satisfies all of the conditions"? Change "MUST cover" to "covers". Why is it "SHOULD be ordered in non-decreasing frequency value" instead of MUST? Change "is REQUIRED to define" to "defines". Change "is REQUIRED to specify" to "specifies". 5.15: Change "is REQUIRED to identify" to "identifies". 5.16: You define the length in terms of characters for "reason", but don't indicate what contents it might have. If this can contain UTF-8, you'll want to say that, and say what the octet limit is instead of the character count. 5.17: Change "optional" to "see description" for data. "message" is another string that requires further definition. In "data", mention that any required additional data is described in Table 1. As mentioned above, probably best to change the name of the "REQUIRED" error code. A mention of the IANA registry in this section would be useful. 5.17.1: Change "MAY include" to "contains". 5.17.2: Change "MUST include" to "contains". 5.17.3: As mentioned above, probably best to change the name of the "REQUIRED" error code. Instead of "SHOULD be expressed using dotted notation", don't you just mean "is expressed using dotted notation"? 6: Was a review of all of the schema descriptions and examples done by a JSON expert? 6.8.13: Change "regulatory-domain ruleset" to "ruleset". Why "SHOULD be sorted"? (See 5.9) 8.1: Change param-name to: param-name = 1*64name-char 8.2: OLD The form of a Ruleset ID value SHOULD be guided by the following: o The value SHOULD describe the set of rules that allow a device to operate within one or more regulatory domains. For example, it MAY include the name of a regulatory body or a certification process o The value SHOULD include version information, such as a year and/or version number o The value MUST NOT exceed 64 characters NEW When defining a Ruleset ID: o It can be useful for the identifier to be descriptive of the set of rules that allow a device to operate within one or more regulatory domains. For example, it might include the name of a regulatory body or a certification process o The identifier SHOULD include some sort of version information, such as a year and/or version number. o The identifier MUST NOT exceed 64 characters 8.3: Change "MUST be registered" (x2) to "are registered". Change "SHOULD be" to "is". Change "it MAY use" to "it can use". 9.1, 9.2, and 9.3: are registered through the Specification Required [RFC5226] process, after a two-week review period on the paws-iana-review@ietf.org mailing list, on the advice of one or more Designated Experts. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests must be sent to the paws-iana-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for parameter: example"). Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. IANA must only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. First of all, I think this is the wrong way to set up the process. Submitting to the list will leave an unclosed loop. Instead, submissions of registrations should go to IANA. That will either happen by way of Last Call, if the specification is an RFC, or by direct submission if it's a different kind of specification. Then let IANA contact the Designated Expert(s) to do their review. This document can specify that the DEs can/will post the request to a list for wider community review, but that should be part of the instructions to the DEs in this document. After the DEs approve, they send the message to IANA (who can poke them if they're late), and IANA notifies the registrant and does the registration. So the order should be: Registrant->IANA->DE(s)->list->DE(s)->IANA->Registrant Set up this way, IANA will be tracking the progress of the registration from beginning to end. Second, I think this needs specific instruction to the DEs on what basis they should accept or reject registration requests. Can they only do it based on completeness of the application? Can they reject if the registration is somehow duplicative with an existing registration? For early allocation requests, should the DEs be reviewing the draft specification for completeness? Each section should provide an explanation of criteria that the DEs should be using to evaluate registration requests. Finally, for ease of reading, I'd ask that you swap sections 9.1 and 9.2. Describing FCC parameters before defining the FCC ruleset ID seemed weird. 9.2.2: I think the second column of the table should be subdivided: For each parameter, it should specify the parameter name, its type, and whether it is required or optional. I'm not sure the description of DeviceOwner is clear enough that IANA will know how to put that into the table. 11: I'm a bit concerned about everyone but Vincent being listed in the Author's section rather than the Contributor's section. The Author's section includes the folks that must sign off on the document during RFC Editor AUTH48. I'd rather not require 5 people to have to do that. The Contributor's section indicates that each person was an instrumental contributor of text to the document, so I think that's a reasonable place to put those folks. 13.1: I think X.520 can be Informative instead of Normative. 13.2: I think JSON-RPC is going to have to be Normative. RFC 2818 is definitely normative. Appendix A: You should note that the RFC Editor should remove this section before publication. -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Apr 24 17:41:41 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B407E1A044A; Thu, 24 Apr 2014 17:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6SNbA4CgBo7; Thu, 24 Apr 2014 17:41:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 504311A044F; Thu, 24 Apr 2014 17:41:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140425004136.20484.45101.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 17:41:36 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/TRyI8Hl55IvA7wXMStuNtFmFF7w Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-12.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 00:41:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol to Access WS database Working Group of the IETF. Title : Protocol to Access White-Space (PAWS) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-12.txt Pages : 113 Date : 2014-04-24 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/