From nobody Thu Jul 3 10:28:15 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 13ABA1B2B4F; Thu, 3 Jul 2014 10:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 rpIEMCbTcRYQ; Thu, 3 Jul 2014 10:28:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D321A0021; Thu, 3 Jul 2014 10:28:04 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s63HS36D009530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 3 Jul 2014 12:28:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53B592A2.2080202@nostrum.com> Date: Thu, 03 Jul 2014 12:28:02 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: General Area Review Team , paws@ietf.org, "ietf@ietf.org" , draft-ietf-paws-protocol@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Uh5R4Fbru22AkIgeqZyavY5vdeY Subject: [paws] Gen-art LC review: draft-ietf-paws-protocol-12 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: Thu, 03 Jul 2014 17:28:07 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-paws-protocol-12 Reviewer: Robert Sparks Review Date: 3 July, 2014 IETF LC End Date: 7 July, 2014 IESG Telechat date: 10 July, 2014 Summary: This document is not ready for publication as a Proposed Standard. I apologize in advance if I've missed where one of the questions below is already answered. There's a lot to take in here. Major Issues - The document says it "describes" the use of HTTP/TLS as the transport for the protocol. Was it the intent to allow others? If not, the language should be firmed up. - The document still says "TBD Define message format" in the section on Listing Servers. I understand from reading the list that what the document is going to say about Listing Servers is going to change (to not include how you talk to them?). This change needs to be finished before the document can be reviewed for completeness. - It's not clear when a server should use the HTTP level redirection discussed in section 7 vs the databaseChange mechanism in the protocol's responses. There should be some discussion about what the Device should do when the databaseChange mechanism results in a redirect loop. - The document needs to be clear where the primitive types (like string, float, and integer) in the UML-ish diagrams in section 4 are defined. I'm guessing from context that you're assuming the definitions in RFC4627. If that's true, there are several places that you talk about string where your text should change. RFC4627 says string is UNICODE, and may be encoded many ways (see section 3 of that document). If your intent is to restrict all strings to UTF-8 encoding say that, and adjust the text you currently have that mentions UTF-8. (The various places where you say a string MAY contain UTF-8 do not make sense - if you're assuming the encoding is UTF-8 and trying to reinforce that there may be non-ASCII range UTF-8 here, say that explicitly). There are other related phrases that don't make sense such as where you say things like "The length of the string MUST NOT exceed 64 US-ASCII characters." - The descriptions of messages in section 4 all contain *other:any. None of those are reflected in the concrete schema of section 6. Should they be? - The INIT_RESP description requires one or more RulesetInfo objects. What is a database supposed to do if it has no rulesets to return (possibly because it doesn't have anything overlapping with the list of ruleset IDs listed in the DeviceDescriptor in the INIT_REQ.). Should this have been 0..* (along with the corresponding change to the text), or is there an Error that the database should return when this happens. If the latter, it would be good to call it out in 4.2.2. - Section 4.4 talks about returning OUTSIDE_COVERAGE when the location specified in the request is outside the regulatory domain (could that be domains?) supported by the database. The sections on init and registration (4.2 and 4.3) don't have this discussion. Should they? - A databaseChange (at least as described in 4.4) can provide one or more alternate database URIs, affecting the Device's configuration. When there's more than one, is there any preference to what order the Device should try to use them in? Is there any expectation that they will give the same answers to a given request? If not, do you want to say anything about discouraging devices from asking all the databases it knows about to find an answer it likes best? - If the requirements to act as if there is no available whitespace when you can't reach a Listing Server remain in the document, the security considerations should call out that any attack that would prevent reaching a Listing Server would result in all devices relying on that Listing Server ceasing their use of any whitespace. - Please check the description of 'timeRange' in section 5.9 (SpectrumSpec). I think you meant to say "in which there is _NO_ available spectrum". - The definition of SpectrumProfile (section 5.12) needs clarification. Is this allowed? "profiles" : [ {"hz": 5.18e8, "dbm": 30.0 }, {"hz": 5.24e8, "dbm": 37.0 } ] If so, what does it mean? Do I do linear interpolation between points (33.5 dbm (~2.25 watts) at 521Mhz)? Similarly, does this specify a ramp up and then back down? (shaped like a ^)? [ {"hz": 5.18e8, "dbm": 30.0 }, {"hz": 5.21e8, "dbm": 33.5 }, {"hz": 5.24e8, "dbm": 30.0 } ] If not, what text disallows it? - You are using the schema language defined in draft-zyp-json-schema to define your message format. That makes it a normative reference. The draft is expired - are there plans to progress it? - Something needs to talk about case-sensitivity of the various protocol elements. JSON-RPC says that member names are case sensitive and is otherwise silent. The string "sensitive" doesn't appear in RFC4627. So, you have an example that says "authority":"us". Is that the same as "authority":"US", and where does the spec answer that question? My read of JSON-RPC says that "authority":"us" and "Authority":"us" are _not_ the same thing, and that the second would not be a recognized property of a RulesetInfo object. Minor Issues - I'm not finding where you define the protocol version. I see "1.0" in the json examples in section 6. Where is it specified? Within a given method, the only extension point I find other than changing the protocol version is the *other concept in messages, which MUST be ignored when either side doesn't understand them. So there should be some discussion about what kind of change would require the protocol version number to change. Suppose you wanted to allow batching requests from several slaves into one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but allowing a list of DeviceDescriptors perhaps). Does this require a new protocol version, or is it just a new request type in this version? If you think it's a new request-type, should there be a request and response type and/or method registry? And yes, I see how you could do this with JSON-RPC batch, but if that's where you'd send this idea, why didn't you do AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figure out what "The initialization message also represents extension points for database implementations or rulesets that require the explicit handshake." is trying to say. Can you rephrase that more simply?) - It's not clear what it means to "support" a ruleset. I infer that this means that the device has code that implements what's required by the name. Can you state that explicitly? Does a Master device have to have this code? Could it simply be a box that only serves to answer requests from Slave devices? If so, why does it care what the rulesets actually are. If a slave can ask and a database can answer, should a master just shovel the bits, or is there a requirement that the master device be configured to handle a ruleset before a slave can ask about it? - In the last paragraph of section 4.1 (before 4.1.1 starts), "If the Device is already operating" assumes that the device could only be operating if it had previously contacted some database. The problem is that the device was able to reach a database at one point and now it can't reach any. It would read more clearly if you said that explicitly. - Please point somewhere for a definition of the terms 'uncertainty' and 'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV working group has gone through many iterations of disagreement about what these terms mean and how they should be used. For a taste, skim some of . If you don't point to a hard definition, your implementation community will have to go through the same arguments. - Should the security considerations section talk about the risk of collisions in serialNumber (since it is the only required element in DeviceDescriptor, and isn't a particularly secret thing)? Is there any harm at the database if two devices innocently end up sending the same serial number (without providing any of the optional information that would otherwise disambiguate the devices)? Can a device learn anything useful about another device by spoofing it? Is it possible that in some regulatory realm, some devices would get more access than others, encouraging devices to ask about what their competition gets to do? Can harm be done by a device sending SPECTRUM_USE_NOTIFY messages claiming to be some other serial number (and perhaps manufacturer) maliciously? I think this needs more discussion than what RFC6953 contains. - The use of the "id" parameter from JSON-RPC deserves more discussion. The JSON-RPC spec allows it to be string, numeric (without a fractional part), NULL or missing. You've chosen to require it (since you're not using json-rpc notifications), and not allowing numeric values (why?). Are you making any other assumptions about what it should contain? I think you're assuming a level of uniqueness that would let you use the Batch mechanism in section 6 of JSON-RPC (otherwise, the HTTP request/response context is enough to associate the request and response and the id might as well be constant). - Section 7 says a server can reject a GET with a 404 - wouldn't that have consequences for a later POST? Why wouldn't it use a 405? - The draft calls for the creation of a special list for review requests for the IANA assignments. This may be ok (mailing lists are easy to set up), but is there not an existing list that would serve the purpose just as well? Nits - RFC 2616 has been obsoleted - the references should be updated. - It would help to have an example of a ruleset in the definition in the Terminology section and perhaps for that definition to more strongly convey that it is a name in a namespace, and what that rule means is elsewhere. (Right now the definition says that the ruleset is the actual set of rules, not a name, and it made reading the protocol overview much harder than it needed to be). At the very least, pointing to the examples in section 9 early would help. - Is the document loosely borrowing UML, or are the diagrams used in section 4 of a format formally defined in some other RFC? A pointer to a definition of the format, or a brief description noting it's based on UML along with where the base types are defined would be useful. - "One approach to manage spectrum sharing" is awkward. Would "One approach to managing spectrum sharing" or "One approach to the management of spectrum sharing" work? - There are several instances of "The Device needs to use the information to update its list". Consider clarifying 'needs to'. Should this have been MUST? - "The vertices MUST be defined in a counter-clockwise direction" assumes you are looking at them from above - please be explicit. - Section 9.1.2's first paragraph should say "FCC and ETSI" the same way 9.2.2 does. You could generalize that to "any particular set of authorities". From nobody Thu Jul 3 20:38:23 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 F33F01B29A7 for ; Thu, 3 Jul 2014 20:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 1Qb94x7hPnnj for ; Thu, 3 Jul 2014 20:38:18 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8571B2B41 for ; Thu, 3 Jul 2014 20:38:17 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jx11so1134900veb.19 for ; Thu, 03 Jul 2014 20:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NOePnTOkJeE9tDS9ntf/Q2HAMIDyNlupnaPWXReq2Wc=; b=gCPoMRFOy4LUWBytTWgnV+q12fBTo2u1bHquZwpXaIHnAU2p7gXzF45yEH+r1LMXdV EQFREKyc4awRlvwY8UcEBUV/gJaG+w1ATdH7rK1IQjqxeyAfhuugyCRh1W0rNSesHW+z 0rM2xyht3oYGOWuYjufXWyOErNxqsZLIJq2IdIhgVaCLE81VgU6oxNQZqEZcqYqCMcuc Ypwf2jTm44JbUdvjimcB8xneWELFdLks2LbTOUlT7DC1GoDbmkSOlHM+UX/jfNXCl3/T JvdQf5BP9vYRaWIjVjVD5dkuQctnLQRIcYngdk7FMBg1dyZ2D20+1WYUaRVWUIz/cN2u xfiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NOePnTOkJeE9tDS9ntf/Q2HAMIDyNlupnaPWXReq2Wc=; b=QfJNiR4Jn8ycTqrSDRNuud2EA2usd7JPd/wvwk59F9xa84W1ftQBFzIQ0i46sVwG5+ 1DMdQMN6NidWP9ugL9W4oz7v9SXKNPDrN4L8XjhnKHmn2QEbbyOM6mTpKQvPw3irRMTy +KZ4rkT/3Nk75Gd4mciFz6vMw0he7032glEsAlORZ/bh1w4VZ3E9fBwP4GG676J0jFC2 TzxSTfg/hCuqR/EIXsA0PpHgNBl0vzo6BsHcavyc76c7AZ4m900avB1J48GPzVd7BAdS AFFn5fGndxrasjIMwSpgl/XdVEsFn+3ArQVdLMakzLLNT3s22SFd/Gwu2ozdgTMCnBql LgnQ== X-Gm-Message-State: ALoCoQlJPi493HIx6kIeRuyTAJ7p3otLzwamvZYP7Ds4mT5U9R4rdyHg/U09ZKTF4xcYPHmhfQeY MIME-Version: 1.0 X-Received: by 10.221.25.210 with SMTP id rj18mr7376742vcb.5.1404445096910; Thu, 03 Jul 2014 20:38:16 -0700 (PDT) Received: by 10.52.180.163 with HTTP; Thu, 3 Jul 2014 20:38:16 -0700 (PDT) In-Reply-To: <53A73852.4060002@qti.qualcomm.com> References: <20140425004136.20484.45101.idtracker@ietfa.amsl.com> <53A73852.4060002@qti.qualcomm.com> Date: Thu, 3 Jul 2014 20:38:16 -0700 Message-ID: From: Vincent Chen To: Pete Resnick Content-Type: multipart/alternative; boundary=001a113643181bbf5e04fd55db4d Archived-At: http://mailarchive.ietf.org/arch/msg/paws/xZckueofCweQbAcEUG0NHqpwIJw Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-12.txt 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: Fri, 04 Jul 2014 03:38:21 -0000 --001a113643181bbf5e04fd55db4d Content-Type: text/plain; charset=UTF-8 Pete, Thanks for the suggestions. They seem reasonable except for some of the comments for the IANA Sections 9.1.x.x and 9.2.x.x. These registries are for extending the protocol, so should contain protocol-style language. Please see in-line comments below. Thanks. -vince On Sun, Jun 22, 2014 at 1:10 PM, Pete Resnick wrote: > I've sat on this document for far too long. I've sent in the request for > the Last Call, but there are still some outstanding issues. I think these > can be handled during Last Call: > > 3.1 > > NOTE: Regulatory rules contain many device-only requirements that > govern device behavior, independent of any database rules. These > requirements may be complex and involve device behavior that are not > easily parameterized. The ruleset-id parameter provides a mechanism > for the Database to inform the Master Device of the applicable > ruleset without having to express device-side behavior within the > protocol. The ruleset identifier is a string value that contains the > name of the regulatory body that established the rules and version > information, such as "FccTvBandWhiteSpace-2010". > > No change got made to this paragraph between -11 and -12, even though it > still refers to "regulatory rules". Might I suggest: > > NOTE: Some regulatory domains specify sets of requirements for device > behavior that may be complex and not easily parameterized. The > ruleset-id parameter provides a mechanism for the Database to inform > the Master Device of an applicable ruleset, and for devices with > out-of-band knowledge of the particular regulatory domain > requirements to satisfy those requirements, without having to specify > the device-side behavior within the protocol. Ruleset identifiers > will normally contain the name of the regulatory body that > established the rules and version information, such as > "FccTvBandWhiteSpace-2010". > *Done* > > 5.2: Are the formats of serialNumber, manufacturerId, modelId defined > anywhere? Are they UTF-8? If I'm writing an implementation, how do I know > what these are? > *Done. Specified UTF-8.* > 5.8 "It MAY contain UTF-8". That's not interoperable. It either "MUST > contain UTF-8" or be completely opaque and therefore strike commentary on > the format. > *Done. MUST be UTF-8* > > 5.16/5.17 "MAY be in any language and contain UTF-8 characters". First, > separate out "MAY be in any language" from the format. But as for the > format, again, that's not interoperable. In this case, I think "MUST be > UTF-8" is the only real choice. > *Done* > > 8.1: > > s/they MUST be registered/they are registered > s/64 characters/64 octets > > The octets/characters thing doesn't make a difference here, but > consistency is always a fine thing. > *Done* > > 8.3: s/MAY be defined/can be defined > *Done* > > 9: > > Insert at the top: "[RFC Editor/IANA: Please replace "[[ this document ]]" > with the RFC number of this document as indicated below, and remove this > note prior to publication.]" > *Done* > > s/responsible IESG area director should/the IESG shall > > That's automatic, but you can say it as above. > *Done* > > s/30 days/2 weeks > > Let's make it a normal Last Call length. I think that will make the > logistics work a bit better. > *Done* > > Also, add on to the end of that paragraph: "Specific criteria that the > Designated Expert should use in assessing registrations are given below in > the description of each registry." > *Done* > > > 9.1: s/regulatory rules/regulatory domain > *Done* > > 9.1.1: > > OLD > Ruleset name: The name of the ruleset. It is a string value that > contains the name of the regulatory body that established the > rules and version information. The length of the string MUST NOT > exceed 64 US-ASCII characters. > NEW > Ruleset identifier: The name of the ruleset. See [[ this document ]], > Section 8.1 for the format requirements of this identifier. > > s/New parameters MUST be/New parameters are > *Done* > > 9.1.2: > > OLD > as of this writing, it is the only regulatory > domain that has finalized rules. There is no intent to restrict the > protocol to FCC rules. > NEW > as of this writing, they are the only regulatory > domains that have finalized rules. There is no intent to restrict the > protocol to FCC or ETSI rules. > *Done* > > 9.1.2.1/9.1.2.2: s/REQUIRED/required and s/OPTIONAL/optional > *These sections describe protocol extensions needed for each ruleset, so the REQUIRED and OPTIONAL are protocol requirements, I believe. * * E.g., if the ruleset is "FccTvBandWhiteSpace-2010", then "fccId" is REQUIRED....at the protocol level.* > 9.1.1.1: In the DeviceOwner definition, I suggest changing "MUST contain" > to "is mandated to contain" (3 times), to make it clear that this is a > regulatory requirement, not a protocol requirement. > *Done* > > 9.1.2.2: > > s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5.2 > s/MUST respond/is mandated to respond > s/MUST set this/is mandated to set this > *Done* > > 9.2.2.1: > > ...MUST NOT exceed 32 US-ASCII characters... > > If that's a protocol requirement, it belongs in section 5.2. It doesn't > belong here. > *Since this is a new parameter for extending the protocol, I believe it is a protocol requirement. There would be no place to put this in section 5.2, since the parameter does not exist in the base protocol.* > > 9.2.2.5 > > The string value MUST NOT exceed 64 octets in length. > > Is that an ETSI requirement? Then rewrite as "The ETSI standard specifies > that the string value be a maximum of 64 octets in length." Otherwise, > strike the sentence. *Again. This is a new parameter, so I believe it is a protocol requirement. The ETSI standard actually does not contain any language to limit the number of characters. This was determined by consulting w/ Cesar Gutierrez of Ofcom.* > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --001a113643181bbf5e04fd55db4d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pete,

Thanks for the suggestions. They = seem reasonable except for some of the comments for the IANA Sections 9.1.x= .x and 9.2.x.x. These registries are for extending the protocol, so should = contain protocol-style language. Please see in-line comments below.

Thanks.

-vince


On Sun, Jun 22, 2014 at= 1:10 PM, Pete Resnick <presnick@qti.qualcomm.com> w= rote:
I've sat on this document for far too long. I've s= ent in the request for the Last Call, but there are still some outstanding = issues. I think these can be handled during Last Call:

3.1

=C2=A0 =C2=A0NOTE: Regulatory rules contain many device-only requirements t= hat
=C2=A0 =C2=A0govern device behavior, independent of any database rules. =C2= =A0These
=C2=A0 =C2=A0requirements may be complex and involve device behavior that a= re not
=C2=A0 =C2=A0easily parameterized. =C2=A0The ruleset-id parameter provides = a mechanism
=C2=A0 =C2=A0for the Database to inform the Master Device of the applicable=
=C2=A0 =C2=A0ruleset without having to express device-side behavior within = the
=C2=A0 =C2=A0protocol. =C2=A0The ruleset identifier is a string value that = contains the
=C2=A0 =C2=A0name of the regulatory body that established the rules and ver= sion
=C2=A0 =C2=A0information, such as "FccTvBandWhiteSpace-2010".

No change got made to this paragraph between -11 and -12, even though it st= ill refers to "regulatory rules". Might I suggest:

=C2=A0 =C2=A0NOTE: Some regulatory domains specify sets of requirements for= device
=C2=A0 =C2=A0behavior that may be complex and not easily parameterized. The=
=C2=A0 =C2=A0ruleset-id parameter provides a mechanism for the Database to = inform
=C2=A0 =C2=A0the Master Device of an applicable ruleset, and for devices wi= th
=C2=A0 =C2=A0out-of-band knowledge of the particular regulatory domain
=C2=A0 =C2=A0requirements to satisfy those requirements, without having to = specify
=C2=A0 =C2=A0the device-side behavior within the protocol. Ruleset identifi= ers
=C2=A0 =C2=A0will normally contain the name of the regulatory body that
=C2=A0 =C2=A0established the rules and version information, such as
=C2=A0 =C2=A0"FccTvBandWhiteSpace-2010".
Done
=C2=A0

5.2: Are the formats of serialNumber, manufacturerId, modelId defined anywh= ere? Are they UTF-8? If I'm writing an implementation, how do I know wh= at these are?

Done. Specified UTF-8.


5.8 "It MAY contain UTF-8". That's not interoperable. It eith= er "MUST contain UTF-8" or be completely opaque and therefore str= ike commentary on the format.

Done. MUST be UTF-8
=C2=A0

5.16/5.17 "MAY be in any language and contain UTF-8 characters". = First, separate out "MAY be in any language" from the format. But= as for the format, again, that's not interoperable. In this case, I th= ink "MUST be UTF-8" is the only real choice.

Done=
=C2=A0

8.1:

=C2=A0 =C2=A0s/they MUST be registered/they are registered
=C2=A0 =C2=A0s/64 characters/64 octets

The octets/characters thing doesn't make a difference here, but consist= ency is always a fine thing.

Done
=C2=A0

8.3: s/MAY be defined/can be defined

Done
=C2=A0

9:

Insert at the top: "[RFC Editor/IANA: Please replace "[[ this doc= ument ]]" with the RFC number of this document as indicated below, and= remove this note prior to publication.]"

Done
=C2=A0

=C2=A0 =C2=A0s/responsible IESG area director should/the IESG shall

That's automatic, but you can say it as above.
Done=C2=A0

=C2=A0 =C2=A0s/30 days/2 weeks

Let's make it a normal Last Call length. I think that will make the log= istics work a bit better.

Done=C2=A0

Also, add on to the end of that paragraph: "Specific criteria that the= Designated Expert should use in assessing registrations are given below in= the description of each registry."

Done=C2=A0


9.1: s/regulatory rules/regulatory domain

Done=C2=A0

9.1.1:

OLD
=C2=A0 =C2=A0Ruleset name: =C2=A0The name of the ruleset. =C2=A0It is a str= ing value that
=C2=A0 =C2=A0 =C2=A0 contains the name of the regulatory body that establis= hed the
=C2=A0 =C2=A0 =C2=A0 rules and version information. =C2=A0The length of the= string MUST NOT
=C2=A0 =C2=A0 =C2=A0 exceed 64 US-ASCII characters.
NEW
=C2=A0 =C2=A0 Ruleset identifier: The name of the ruleset. See [[ this docu= ment ]],
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 8.1 for the format requirements of this = identifier.

s/New parameters MUST be/New parameters are

=
Done=C2=A0

9.1.2:

OLD
=C2=A0 =C2=A0as of this writing, it is the only regulatory
=C2=A0 =C2=A0domain that has finalized rules. =C2=A0There is no intent to r= estrict the
=C2=A0 =C2=A0protocol to FCC rules.
NEW
=C2=A0 =C2=A0as of this writing, they are the only regulatory
=C2=A0 =C2=A0domains that have finalized rules. =C2=A0There is no intent to= restrict the
=C2=A0 =C2=A0protocol to FCC or ETSI rules.

=
Done
=C2=A0

9.1.2.1/9.1.2.2: s= /REQUIRED/required and s/OPTIONAL/optional

<= div>=C2=A0These sections describe protocol exten= sions needed for each ruleset, so the REQUIRED and OPTIONAL are protocol re= quirements, I believe.=C2=A0
=C2=A0E.g., if the ruleset is "FccTvBa= ndWhiteSpace-2010", then "fccId" is REQUIRED....at the proto= col level.


9.1.1.1: In the DeviceOwne= r definition, I suggest changing "MUST contain" to "is manda= ted to contain" (3 times), to make it clear that this is a regulatory = requirement, not a protocol requirement.

Done=
=C2=A0

9.1.2.2:

=C2=A0 =C2=A0s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5= .2
=C2=A0 =C2=A0s/MUST respond/is mandated to respond
=C2=A0 =C2=A0s/MUST set this/is mandated to set this
<= br>
Done=C2=A0

9.2.2.1:

=C2=A0 =C2=A0...MUST NOT exceed 32 US-ASCII characters...

If that's a protocol requirement, it belongs in section 5.2. It doesn&#= 39;t belong here.

Since this is a new parameter for extending the protocol, I believe i= t is a protocol requirement. There would be no place to put this in section= 5.2, since the parameter does not exist in the base protocol.

=C2=A0

9.2.2.5

=C2=A0 =C2=A0The string value MUST NOT exceed 64 octets in length.

Is that an ETSI requirement? Then rewrite as "The ETSI standard specif= ies that the string value be a maximum of 64 octets in length." Otherw= ise, strike the sentence.

=C2=A0Again. This is a new parameter, so I believe it is a protoc= ol requirement. The ETSI standard actually does not contain any language to= limit the number of characters. This was determined by consulting w/ Cesar= =C2=A0Gutierrez of Ofcom.



--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478



--001a113643181bbf5e04fd55db4d-- From nobody Thu Jul 3 20:42:18 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 DF7FE1B2B9A for ; Thu, 3 Jul 2014 20:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 rrUr2Ni9OS_c for ; Thu, 3 Jul 2014 20:42:10 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A421A8BB7 for ; Thu, 3 Jul 2014 20:42:10 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id jw12so1139749veb.11 for ; Thu, 03 Jul 2014 20:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=exr9SGHXzX0q0FcQY+25/TAXoILwB0wcJuUsLu1tJJc=; b=ZUZmGUe1nEP72C3pTqRtsEfpclV8UExAgwqP4020lsQtUobd6Pp+1Ebu6WXoAG3u4w O2kaqC2Vo721v59gGnd7F0AsA7ZVXOWce8LrTNOUQEKVq6q761PrrHeSoubGOQPl62ML fQHhs3S/QGU2Y8YlpNDyNctMEUuhPtncqXe28/w3W7GN6GNh9nY1W4MfU+dHqw4fvkVX P5221D4DrRpVwuY9owuepSpK4lWD5nO7pWOoJw/N4G+YW8ysL81ntLJOZxcQJgy5yhFT JJUDV1LbnD/VmpzJ3nECGkFDVpWdr6Jk0+s8pLH/dU39rOAzeyuG1pAzyE/8sS0osJiV 1pcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=exr9SGHXzX0q0FcQY+25/TAXoILwB0wcJuUsLu1tJJc=; b=l0tp2ET0ybw46O02iRepcE68iGrEWzIjqtT6Tosw/f3mERhHGPmwRpp6x7mV6wYs3o NALmMMgQYnlqxFOt3f0oqwjPSOYPFpAl6SNaYvXm4kVGgbrGp+2pd/T1xiDew7Ua2l7/ wb8btfxVFpXYY3p7/hy5bN96ejl49nJiofUKd6WSdeFi0YJwksscQgX5bdhuR2v3uM6z +pCvCqW5GX3plBBHIkYM+K+gyZ+x4s8FzzX+vMIaDNK8PXoXdSbiGzcDJbj1sp0DTTCY UrCwXM5elMeCUAjXkIcLgGrb036DFOtZoPtizRcsE4eazJXhC9jPpBE2HytZ+R+/VFxe ZpBA== X-Gm-Message-State: ALoCoQkW4Uoki7tfKzY8E/TpHoGhNwKmg5vC2jXmzTp+Ns2az1LLUKSZDVUr2Yt1as/KhfGocRW7 MIME-Version: 1.0 X-Received: by 10.220.250.203 with SMTP id mp11mr7347265vcb.2.1404445329415; Thu, 03 Jul 2014 20:42:09 -0700 (PDT) Received: by 10.52.180.163 with HTTP; Thu, 3 Jul 2014 20:42:09 -0700 (PDT) In-Reply-To: References: <20140425004136.20484.45101.idtracker@ietfa.amsl.com> <53A73852.4060002@qti.qualcomm.com> Date: Thu, 3 Jul 2014 20:42:09 -0700 Message-ID: From: Vincent Chen To: Pete Resnick Content-Type: multipart/alternative; boundary=089e013d0502f787ee04fd55e833 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/PRoHCFBemAjLxx4XICqE9mikfk4 Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-12.txt 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: Fri, 04 Jul 2014 03:42:14 -0000 --089e013d0502f787ee04fd55e833 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 3, 2014 at 8:38 PM, Vincent Chen wrote: > Pete, > > Thanks for the suggestions. They seem reasonable except for some of the > comments for the IANA Sections 9.1.x.x and 9.2.x.x. These registries are > for extending the protocol, so should contain protocol-style language. > Please see in-line comments below. > > Thanks. > > -vince > > > On Sun, Jun 22, 2014 at 1:10 PM, Pete Resnick > wrote: > >> I've sat on this document for far too long. I've sent in the request for >> the Last Call, but there are still some outstanding issues. I think these >> can be handled during Last Call: >> >> 3.1 >> >> NOTE: Regulatory rules contain many device-only requirements that >> govern device behavior, independent of any database rules. These >> requirements may be complex and involve device behavior that are not >> easily parameterized. The ruleset-id parameter provides a mechanism >> for the Database to inform the Master Device of the applicable >> ruleset without having to express device-side behavior within the >> protocol. The ruleset identifier is a string value that contains the >> name of the regulatory body that established the rules and version >> information, such as "FccTvBandWhiteSpace-2010". >> >> No change got made to this paragraph between -11 and -12, even though it >> still refers to "regulatory rules". Might I suggest: >> >> NOTE: Some regulatory domains specify sets of requirements for device >> behavior that may be complex and not easily parameterized. The >> ruleset-id parameter provides a mechanism for the Database to inform >> the Master Device of an applicable ruleset, and for devices with >> out-of-band knowledge of the particular regulatory domain >> requirements to satisfy those requirements, without having to specify >> the device-side behavior within the protocol. Ruleset identifiers >> will normally contain the name of the regulatory body that >> established the rules and version information, such as >> "FccTvBandWhiteSpace-2010". >> > > *Done* > > >> >> 5.2: Are the formats of serialNumber, manufacturerId, modelId defined >> anywhere? Are they UTF-8? If I'm writing an implementation, how do I know >> what these are? >> > > *Done. Specified UTF-8.* > > >> 5.8 "It MAY contain UTF-8". That's not interoperable. It either "MUST >> contain UTF-8" or be completely opaque and therefore strike commentary on >> the format. >> > > *Done. MUST be UTF-8* > > >> >> 5.16/5.17 "MAY be in any language and contain UTF-8 characters". First, >> separate out "MAY be in any language" from the format. But as for the >> format, again, that's not interoperable. In this case, I think "MUST be >> UTF-8" is the only real choice. >> > > *Done* > > >> >> 8.1: >> >> s/they MUST be registered/they are registered >> s/64 characters/64 octets >> >> The octets/characters thing doesn't make a difference here, but >> consistency is always a fine thing. >> > > *Done* > > >> >> 8.3: s/MAY be defined/can be defined >> > > *Done* > > >> >> 9: >> >> Insert at the top: "[RFC Editor/IANA: Please replace "[[ this document >> ]]" with the RFC number of this document as indicated below, and remove >> this note prior to publication.]" >> > > *Done* > > >> >> s/responsible IESG area director should/the IESG shall >> >> That's automatic, but you can say it as above. >> > > *Done* > >> >> s/30 days/2 weeks >> >> Let's make it a normal Last Call length. I think that will make the >> logistics work a bit better. >> > > *Done* > >> >> Also, add on to the end of that paragraph: "Specific criteria that the >> Designated Expert should use in assessing registrations are given below in >> the description of each registry." >> > > *Done* > >> >> >> 9.1: s/regulatory rules/regulatory domain >> > > *Done* > >> >> 9.1.1: >> >> OLD >> Ruleset name: The name of the ruleset. It is a string value that >> contains the name of the regulatory body that established the >> rules and version information. The length of the string MUST NOT >> exceed 64 US-ASCII characters. >> NEW >> Ruleset identifier: The name of the ruleset. See [[ this document ]], >> Section 8.1 for the format requirements of this identifier. >> >> s/New parameters MUST be/New parameters are >> > > *Done* > >> >> 9.1.2: >> >> OLD >> as of this writing, it is the only regulatory >> domain that has finalized rules. There is no intent to restrict the >> protocol to FCC rules. >> NEW >> as of this writing, they are the only regulatory >> domains that have finalized rules. There is no intent to restrict the >> protocol to FCC or ETSI rules. >> > > *Done* > > >> >> 9.1.2.1/9.1.2.2: s/REQUIRED/required and s/OPTIONAL/optional >> > > *These sections describe protocol extensions needed for each ruleset, so > the REQUIRED and OPTIONAL are protocol requirements, I believe. * > * E.g., if the ruleset is "FccTvBandWhiteSpace-2010", then "fccId" is > REQUIRED....at the protocol level.* > > >> 9.1.1.1: In the DeviceOwner definition, I suggest changing "MUST >> contain" to "is mandated to contain" (3 times), to make it clear that this >> is a regulatory requirement, not a protocol requirement. >> > > > *Actually, this is also a protocol requirement. The regulatory domain does > not require any specific encoding for the owner information.* > > >> >> 9.1.2.2: >> >> s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5.2 >> s/MUST respond/is mandated to respond >> s/MUST set this/is mandated to set this >> > > *Done* > >> >> 9.2.2.1: >> >> ...MUST NOT exceed 32 US-ASCII characters... >> >> If that's a protocol requirement, it belongs in section 5.2. It doesn't >> belong here. >> > > *Since this is a new parameter for extending the protocol, I believe it is > a protocol requirement. There would be no place to put this in section 5.2, > since the parameter does not exist in the base protocol.* > > > >> >> 9.2.2.5 >> >> The string value MUST NOT exceed 64 octets in length. >> >> Is that an ETSI requirement? Then rewrite as "The ETSI standard specifies >> that the string value be a maximum of 64 octets in length." Otherwise, >> strike the sentence. > > > *Again. This is a new parameter, so I believe it is a protocol > requirement. The ETSI standard actually does not contain any language to > limit the number of characters. This was determined by consulting w/ > Cesar Gutierrez of Ofcom.* > > >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> > > -- -vince --089e013d0502f787ee04fd55e833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 3, 2014 at 8:38 PM, Vincent Chen <= vchen@google.com&= gt; wrote:
Pete,

Thanks for the s= uggestions. They seem reasonable except for some of the comments for the IA= NA Sections 9.1.x.x and 9.2.x.x. These registries are for extending the pro= tocol, so should contain protocol-style language. Please see in-line commen= ts below.

Thanks.

-vince


On Sun,= Jun 22, 2014 at 1:10 PM, Pete Resnick <presnick@qti.qualcomm.com<= /a>> wrote:
I've sat on this document for far too long. I've s= ent in the request for the Last Call, but there are still some outstanding = issues. I think these can be handled during Last Call:

3.1

=C2=A0 =C2=A0NOTE: Regulatory rules contain many device-only requirements t= hat
=C2=A0 =C2=A0govern device behavior, independent of any database rules. =C2= =A0These
=C2=A0 =C2=A0requirements may be complex and involve device behavior that a= re not
=C2=A0 =C2=A0easily parameterized. =C2=A0The ruleset-id parameter provides = a mechanism
=C2=A0 =C2=A0for the Database to inform the Master Device of the applicable=
=C2=A0 =C2=A0ruleset without having to express device-side behavior within = the
=C2=A0 =C2=A0protocol. =C2=A0The ruleset identifier is a string value that = contains the
=C2=A0 =C2=A0name of the regulatory body that established the rules and ver= sion
=C2=A0 =C2=A0information, such as "FccTvBandWhiteSpace-2010".

No change got made to this paragraph between -11 and -12, even though it st= ill refers to "regulatory rules". Might I suggest:

=C2=A0 =C2=A0NOTE: Some regulatory domains specify sets of requirements for= device
=C2=A0 =C2=A0behavior that may be complex and not easily parameterized. The=
=C2=A0 =C2=A0ruleset-id parameter provides a mechanism for the Database to = inform
=C2=A0 =C2=A0the Master Device of an applicable ruleset, and for devices wi= th
=C2=A0 =C2=A0out-of-band knowledge of the particular regulatory domain
=C2=A0 =C2=A0requirements to satisfy those requirements, without having to = specify
=C2=A0 =C2=A0the device-side behavior within the protocol. Ruleset identifi= ers
=C2=A0 =C2=A0will normally contain the name of the regulatory body that
=C2=A0 =C2=A0established the rules and version information, such as
=C2=A0 =C2=A0"FccTvBandWhiteSpace-2010".


5.8 "It MAY contain UTF-8". That's not interoperable. It eith= er "MUST contain UTF-8" or be completely opaque and therefore str= ike commentary on the format.

Done. MUST be UTF-8
=C2=A0

5.16/5.17 "MAY be in any language and contain UTF-8 characters". = First, separate out "MAY be in any language" from the format. But= as for the format, again, that's not interoperable. In this case, I th= ink "MUST be UTF-8" is the only real choice.

Done
=C2=A0

8.1:

=C2=A0 =C2=A0s/they MUST be registered/they are registered
=C2=A0 =C2=A0s/64 characters/64 octets

The octets/characters thing doesn't make a difference here, but consist= ency is always a fine thing.

<= font color=3D"#cc0000">Done
=C2=A0

8.3: s/MAY be defined/can be defined

<= div>Done
= =C2=A0

9:

Insert at the top: "[RFC Editor/IANA: Please replace "[[ this doc= ument ]]" with the RFC number of this document as indicated below, and= remove this note prior to publication.]"

Done
=C2=A0

=C2=A0 =C2=A0s/responsible IESG area director should/the IESG shall

That's automatic, but you can say it as above.
Done=C2=A0

=C2=A0 =C2=A0s/30 days/2 weeks

Let's make it a normal Last Call length. I think that will make the log= istics work a bit better.


Also, add on to the end of that paragraph: "Specific criteria that the= Designated Expert should use in assessing registrations are given below in= the description of each registry."



9.1: s/regulatory rules/regulatory domain

Done=C2=A0

9.1.1:

OLD
=C2=A0 =C2=A0Ruleset name: =C2=A0The name of the ruleset. =C2=A0It is a str= ing value that
=C2=A0 =C2=A0 =C2=A0 contains the name of the regulatory body that establis= hed the
=C2=A0 =C2=A0 =C2=A0 rules and version information. =C2=A0The length of the= string MUST NOT
=C2=A0 =C2=A0 =C2=A0 exceed 64 US-ASCII characters.
NEW
=C2=A0 =C2=A0 Ruleset identifier: The name of the ruleset. See [[ this docu= ment ]],
=C2=A0 =C2=A0 =C2=A0 =C2=A0Section 8.1 for the format requirements of this = identifier.

s/New parameters MUST be/New parameters are

=

9.1.2:

OLD
=C2=A0 =C2=A0as of this writing, it is the only regulatory
=C2=A0 =C2=A0domain that has finalized rules. =C2=A0There is no intent to r= estrict the
=C2=A0 =C2=A0protocol to FCC rules.
NEW
=C2=A0 =C2=A0as of this writing, they are the only regulatory
=C2=A0 =C2=A0domains that have finalized rules. =C2=A0There is no intent to= restrict the
=C2=A0 =C2=A0protocol to FCC or ETSI rules.

=
=C2=A0

9.1.2.1/9.1.2.2: s= /REQUIRED/required and s/OPTIONAL/optional

<= div>=C2=A0These sections describe protocol exten= sions needed for each ruleset, so the REQUIRED and OPTIONAL are protocol re= quirements, I believe.=C2=A0
=C2=A0E.g., if the ruleset is "FccTvBa= ndWhiteSpace-2010", then "fccId" is REQUIRED....at the proto= col level.
=

9.1.1.1: In the DeviceOwne= r definition, I suggest changing "MUST contain" to "is manda= ted to contain" (3 times), to make it clear that this is a regulatory = requirement, not a protocol requirement.

=C2=A0
Actually, this is also a protocol requirement. = The regulatory domain does not require any specific encoding for the owner = information.
=C2=A0

9.1.2.2:

=C2=A0 =C2=A0s/MUST NOT exceed 64 octets/See [[ this document ]], Section 5= .2
=C2=A0 =C2=A0s/MUST respond/is mandated to respond
=C2=A0 =C2=A0s/MUST set this/is mandated to set this
<= br>
Done=C2=A0
<= div class=3D"">

9.2.2.1:

=C2=A0 =C2=A0...MUST NOT exceed 32 US-ASCII characters...

If that's a protocol requirement, it belongs in section 5.2. It doesn&#= 39;t belong here.

Since this is a new parameter for extending the protocol, I bel= ieve it is a protocol requirement. There would be no place to put this in s= ection 5.2, since the parameter does not exist in the base protocol.

=C2=A0

9.2.2.5

=C2=A0 =C2=A0The string value MUST NOT exceed 64 octets in length.

Is that an ETSI requirement? Then rewrite as "The ETSI standard specif= ies that the string value be a maximum of 64 octets in length." Otherw= ise, strike the sentence.

=C2=A0Again. This is a new parameter, so I believe it is a = protocol requirement. The ETSI standard actually does not contain any langu= age to limit the number of characters. This was determined by consulting w/= Cesar=C2=A0Gutierrez of Ofcom.



--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478






--
-vince --089e013d0502f787ee04fd55e833-- From nobody Tue Jul 8 02:33:27 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 2B74F1B27A9 for ; Tue, 8 Jul 2014 02:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 RidsZPBIkIt5 for ; Tue, 8 Jul 2014 02:33:23 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 521431B27CA for ; Tue, 8 Jul 2014 02:33:23 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id ij19so5103660vcb.36 for ; Tue, 08 Jul 2014 02:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BJkXCEWIUbuPasjKtt92w/BHulh7oaEjEWarHbW8WJI=; b=QbKxPPogw2ypyLczpLB0Mq92ymy0hUiK8tlYeOiv1Q6mmp6XLCFwH03AYk6qqsNFXB 4BQORKMceYptLlurcgwadmS9FWXl31XyztNdKVAUMDWCLGcPWINouA8irsnDBL/ltloo OTy45rq/pmHpx7m9Tku0tq00SXaQWdzTyolDNi7HKnReenuB5keDXDwP0qjNy357Vjkd ulXLZnsF8ExkVe6YQk1jJVUXzZ0inphrQqgKUNGPZjhie7ylZ3PzqAptlBtDrNA74mxk U7tfBFzspQrM0djnnI8ULFM2sCIgNF/nlWOyj/q5NuVvCRxWI/bhjd4WXguSJeVyLN0J Cqug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BJkXCEWIUbuPasjKtt92w/BHulh7oaEjEWarHbW8WJI=; b=ln38kdlkA3WIpp5pLrrVBGvXR3m7V22CXvW54UBAuPIsiD0vjtaUo0ufrBuNuEee25 A9CxzOsgPj+2ceoCxXQ7wBO++HxGDadjphAyCb9194rucPBg4YQ+Y22rYUfVk7ZMpQcm 6+n2LVDmqwjVq1chzbd3nS6NI+2WDZMFg36EJcV8NyaqB24YTWbT1QGRj3/fhmcEki/M XQ2mI476jCLKbsABobrmvq/yNRnIzaJpsbrLu/0pu1X0DEtDHWAdTAjs6EVW0qezzgSJ uJSaP5LB9UPcu3Nq2adVNv4RQm8Yj9y2SZz0dc72ibsXbQi+6goBQpeC5R4quY4pA+xq JAIg== X-Gm-Message-State: ALoCoQmU/GzYQ+wEht7CP0sBQP8XU/jv6mBivYfmTHBK6WYTleCZVt3LFP75qWVK+voezm+hSip3 MIME-Version: 1.0 X-Received: by 10.58.134.81 with SMTP id pi17mr8427958veb.14.1404812002313; Tue, 08 Jul 2014 02:33:22 -0700 (PDT) Received: by 10.52.180.163 with HTTP; Tue, 8 Jul 2014 02:33:22 -0700 (PDT) In-Reply-To: <53B592A2.2080202@nostrum.com> References: <53B592A2.2080202@nostrum.com> Date: Tue, 8 Jul 2014 02:33:22 -0700 Message-ID: From: Vincent Chen To: Robert Sparks Content-Type: multipart/alternative; boundary=089e013a28645fe8ac04fdab4818 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/3WdmtG4EwJR9ktlAU0jk750qRqM Cc: "paws@ietf.org" , General Area Review Team , "ietf@ietf.org" , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Gen-art LC review: draft-ietf-paws-protocol-12 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: Tue, 08 Jul 2014 09:33:27 -0000 --089e013a28645fe8ac04fdab4818 Content-Type: text/plain; charset=UTF-8 Robert, Thanks so much for your comments. Just a quick note that I'm working my through them and will post a reply in the next couple of days. -vince On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-paws-protocol-12 > Reviewer: Robert Sparks > Review Date: 3 July, 2014 > IETF LC End Date: 7 July, 2014 > IESG Telechat date: 10 July, 2014 > > Summary: This document is not ready for publication as a Proposed Standard. > > I apologize in advance if I've missed where one of the questions below is > already answered. There's a lot to take in here. > > Major Issues > > - The document says it "describes" the use of HTTP/TLS as the transport > for the protocol. Was it the intent to allow others? If not, the language > should be firmed up. > > - The document still says "TBD Define message format" in the section on > Listing Servers. I understand from reading the list that what the document > is going to say about Listing Servers is going to change (to not include > how you talk to them?). This change needs to be finished before the > document can be reviewed for completeness. > > - It's not clear when a server should use the HTTP level redirection > discussed in section 7 vs the databaseChange mechanism in the protocol's > responses. There should be some discussion about what the Device should do > when the databaseChange mechanism results in a redirect loop. > > - The document needs to be clear where the primitive types (like string, > float, and integer) in the UML-ish diagrams in section 4 are defined. I'm > guessing from context that you're assuming the definitions in RFC4627. If > that's true, there are several places that you talk about string where your > text should change. RFC4627 says string is UNICODE, and may be encoded many > ways (see section 3 of that document). If your intent is to restrict all > strings to UTF-8 encoding say that, and adjust the text you currently have > that mentions UTF-8. (The various places where you say a string MAY contain > UTF-8 do not make sense - if you're assuming the encoding is UTF-8 and > trying to reinforce that there may be non-ASCII range UTF-8 here, say that > explicitly). There are other related phrases that don't make sense such as > where you say things like "The length of the string MUST NOT exceed 64 > US-ASCII characters." > > - The descriptions of messages in section 4 all contain *other:any. None > of those are reflected in the concrete schema of section 6. Should they be? > > - The INIT_RESP description requires one or more RulesetInfo objects. What > is a database supposed to do if it has no rulesets to return (possibly > because it doesn't have anything overlapping with the list of ruleset IDs > listed in the DeviceDescriptor in the INIT_REQ.). Should this have been > 0..* (along with the corresponding change to the text), or is there an > Error that the database should return when this happens. If the latter, it > would be good to call it out in 4.2.2. > > - Section 4.4 talks about returning OUTSIDE_COVERAGE when the location > specified in the request is outside the regulatory domain (could that be > domains?) supported by the database. The sections on init and registration > (4.2 and 4.3) don't have this discussion. Should they? > > - A databaseChange (at least as described in 4.4) can provide one or more > alternate database URIs, affecting the Device's configuration. When there's > more than one, is there any preference to what order the Device should try > to use them in? Is there any expectation that they will give the same > answers to a given request? If not, do you want to say anything about > discouraging devices from asking all the databases it knows about to find > an answer it likes best? > > - If the requirements to act as if there is no available whitespace when > you can't reach a Listing Server remain in the document, the security > considerations should call out that any attack that would prevent reaching > a Listing Server would result in all devices relying on that Listing Server > ceasing their use of any whitespace. > > - Please check the description of 'timeRange' in section 5.9 > (SpectrumSpec). I think you meant to say "in which there is _NO_ available > spectrum". > > - The definition of SpectrumProfile (section 5.12) needs clarification. Is > this allowed? > "profiles" : [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.24e8, "dbm": 37.0 } > ] > If so, what does it mean? Do I do linear interpolation between points > (33.5 dbm (~2.25 watts) at 521Mhz)? > Similarly, does this specify a ramp up and then back down? (shaped like a > ^)? > [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.21e8, "dbm": 33.5 }, > {"hz": 5.24e8, "dbm": 30.0 } > ] > If not, what text disallows it? > > > - You are using the schema language defined in draft-zyp-json-schema to > define your message format. That makes it a normative reference. The draft > is expired - are there plans to progress it? > > - Something needs to talk about case-sensitivity of the various protocol > elements. JSON-RPC says that member names are case sensitive and is > otherwise silent. The string "sensitive" doesn't appear in RFC4627. So, you > have an example that says "authority":"us". Is that the same as > "authority":"US", and where does the spec answer that question? My read of > JSON-RPC says that "authority":"us" and "Authority":"us" are _not_ the same > thing, and that the second would not be a recognized property of a > RulesetInfo object. > > Minor Issues > > - I'm not finding where you define the protocol version. I see "1.0" in > the json examples in section 6. Where is it specified? Within a given > method, the only extension point I find other than changing the protocol > version is the *other concept in messages, which MUST be ignored when > either side doesn't understand them. So there should be some discussion > about what kind of change would require the protocol version number to > change. Suppose you wanted to allow batching requests from several slaves > into one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but > allowing a list of DeviceDescriptors perhaps). Does this require a new > protocol version, or is it just a new request type in this version? If you > think it's a new request-type, should there be a request and response type > and/or method registry? And yes, I see how you could do this with JSON-RPC > batch, but if that's where you'd send this idea, why didn't you do > AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figure out > what "The initialization message also represents extension points for > database implementations or rulesets that require the explicit handshake." > is trying to say. Can you rephrase that more simply?) > > - It's not clear what it means to "support" a ruleset. I infer that this > means that the device has code that implements what's required by the name. > Can you state that explicitly? Does a Master device have to have this code? > Could it simply be a box that only serves to answer requests from Slave > devices? If so, why does it care what the rulesets actually are. If a slave > can ask and a database can answer, should a master just shovel the bits, or > is there a requirement that the master device be configured to handle a > ruleset before a slave can ask about it? > > - In the last paragraph of section 4.1 (before 4.1.1 starts), "If the > Device is already operating" assumes that the device could only be > operating if it had previously contacted some database. The problem is that > the device was able to reach a database at one point and now it can't reach > any. It would read more clearly if you said that explicitly. > > - Please point somewhere for a definition of the terms 'uncertainty' and > 'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV > working group has gone through many iterations of disagreement about what > these terms mean and how they should be used. For a taste, skim some of < > https://mailarchive.ietf.org/arch/search/?email_list=geopriv&q=uncertainty>. > If you don't point to a hard definition, your implementation community will > have to go through the same arguments. > > - Should the security considerations section talk about the risk of > collisions in serialNumber (since it is the only required element in > DeviceDescriptor, and isn't a particularly secret thing)? Is there any harm > at the database if two devices innocently end up sending the same serial > number (without providing any of the optional information that would > otherwise disambiguate the devices)? Can a device learn anything useful > about another device by spoofing it? Is it possible that in some regulatory > realm, some devices would get more access than others, encouraging devices > to ask about what their competition gets to do? Can harm be done by a > device sending SPECTRUM_USE_NOTIFY messages claiming to be some other > serial number (and perhaps manufacturer) maliciously? I think this needs > more discussion than what RFC6953 contains. > > - The use of the "id" parameter from JSON-RPC deserves more discussion. > The JSON-RPC spec allows it to be string, numeric (without a fractional > part), NULL or missing. You've chosen to require it (since you're not using > json-rpc notifications), and not allowing numeric values (why?). Are you > making any other assumptions about what it should contain? I think you're > assuming a level of uniqueness that would let you use the Batch mechanism > in section 6 of JSON-RPC (otherwise, the HTTP request/response context is > enough to associate the request and response and the id might as well be > constant). > > - Section 7 says a server can reject a GET with a 404 - wouldn't that have > consequences for a later POST? Why wouldn't it use a 405? > > - The draft calls for the creation of a special list for review requests > for the IANA assignments. This may be ok (mailing lists are easy to set > up), but is there not an existing list that would serve the purpose just as > well? > > Nits > > - RFC 2616 has been obsoleted - the references should be updated. > > - It would help to have an example of a ruleset in the definition in the > Terminology section and perhaps for that definition to more strongly convey > that it is a name in a namespace, and what that rule means is elsewhere. > (Right now the definition says that the ruleset is the actual set of > rules, not a name, and it made reading the protocol overview much harder > than it needed to be). At the very least, pointing to the examples in > section 9 early would help. > > - Is the document loosely borrowing UML, or are the diagrams used in > section 4 of a format formally defined in some other RFC? A pointer to a > definition of the format, or a brief description noting it's based on UML > along with where the base types are defined would be useful. > > - "One approach to manage spectrum sharing" is awkward. Would "One > approach to managing spectrum sharing" or "One approach to the management > of spectrum sharing" work? > > - There are several instances of "The Device needs to use the information > to update its list". Consider clarifying 'needs to'. Should this have been > MUST? > > - "The vertices MUST be defined in a counter-clockwise direction" assumes > you are looking at them from above - please be explicit. > > - Section 9.1.2's first paragraph should say "FCC and ETSI" the same way > 9.2.2 does. You could generalize that to "any particular set of > authorities". > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --089e013a28645fe8ac04fdab4818 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

Thanks so much for your comment= s. Just a quick note that I'm working my through them and will post a r= eply in the next couple of days.

-vince


On Thu, Jul 3= , 2014 at 10:28 AM, Robert Sparks <rjsparks@nostrum.com> = wrote:
I am the assigned Gen-ART reviewer for this = draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtf= aq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-paws-protocol-12
Reviewer: Robert Sparks
Review Date: 3 July, 2014
IETF LC End Date: 7 July, 2014
IESG Telechat date: 10 July, 2014

Summary: This document is not ready for publication as a Proposed Standard.=

I apologize in advance if I've missed where one of the questions below = is already answered. There's a lot to take in here.

Major Issues

- The document says it "describes" the use of HTTP/TLS as the tra= nsport for the protocol. Was it the intent to allow others? If not, the lan= guage should be firmed up.

- The document still says "TBD Define message format" in the sect= ion on Listing Servers. I understand from reading the list that what the do= cument is going to say about Listing Servers is going to change (to not inc= lude how you talk to them?). This change needs to be finished before the do= cument can be reviewed for completeness.

- It's not clear when a server should use the HTTP level redirection di= scussed in section 7 vs the databaseChange mechanism in the protocol's = responses. There should be some discussion about what the Device should do = when the databaseChange mechanism results in a redirect loop.

- The document needs to be clear where the primitive types (like string, fl= oat, and integer) in the UML-ish diagrams in section 4 are defined. I'm= guessing from context that you're assuming the definitions in RFC4627.= If that's true, there are several places that you talk about string wh= ere your text should change. RFC4627 says string is UNICODE, and may be enc= oded many ways (see section 3 of that document). If your intent is to restr= ict all strings to UTF-8 encoding say that, and adjust the text you current= ly have that mentions UTF-8. (The various places where you say a string MAY= contain UTF-8 do not make sense - if you're assuming the encoding is U= TF-8 and trying to reinforce that there may be non-ASCII range UTF-8 here, = say that explicitly). There are other related phrases that don't make s= ense such as where you say things like "The length of the string MUST = NOT exceed 64 US-ASCII characters."

- The descriptions of messages in section 4 all contain *other:any. None of= those are reflected in the concrete schema of section 6. Should they be?
- The INIT_RESP description requires one or more RulesetInfo objects. What = is a database supposed to do if it has no rulesets to return (possibly beca= use it doesn't have anything overlapping with the list of ruleset IDs l= isted in the DeviceDescriptor in the INIT_REQ.). Should this have been 0..*= (along with the corresponding change to the text), or is there an Error th= at the database should return when this happens. If the latter, it would be= good to call it out in 4.2.2.

- Section 4.4 talks about returning OUTSIDE_COVERAGE when the location spec= ified in the request is outside the regulatory domain (could that be domain= s?) supported by the database. The sections on init and registration (4.2 a= nd 4.3) don't have this discussion. Should they?

- A databaseChange (at least as described in 4.4) can provide one or more a= lternate database URIs, affecting the Device's configuration. When ther= e's more than one, is there any preference to what order the Device sho= uld try to use them in? Is there any expectation that they will give the sa= me answers to a given request? If not, do you want to say anything about di= scouraging devices from asking all the databases it knows about to find an = answer it likes best?

- If the requirements to act as if there is no available whitespace when yo= u can't reach a Listing Server remain in the document, the security con= siderations should call out that any attack that would prevent reaching a L= isting Server would result in all devices relying on that Listing Server ce= asing their use of any whitespace.

- Please check the description of 'timeRange' in section 5.9 (Spect= rumSpec). I think you meant to say "in which there is _NO_ available s= pectrum".

- The definition of SpectrumProfile (section 5.12) needs clarification. Is = this allowed?
=C2=A0 "profiles" : [
=C2=A0 =C2=A0 {"hz": 5.18e8, "dbm": 30.0 },
=C2=A0 =C2=A0 {"hz": 5.24e8, "dbm": 37.0 }
=C2=A0 ]
If so, what does it mean? Do I do linear interpolation between points (33.5= dbm (~2.25 watts) at 521Mhz)?
Similarly, does this specify a ramp up and then back down? (shaped like a ^= )?
=C2=A0 [
=C2=A0 =C2=A0 {"hz": 5.18e8, "dbm": 30.0 },
=C2=A0 =C2=A0 {"hz": 5.21e8, "dbm": 33.5 },
=C2=A0 =C2=A0 {"hz": 5.24e8, "dbm": 30.0 }
=C2=A0 ]
If not, what text disallows it?


- You are using the schema language defined in draft-zyp-json-schema to def= ine your message format. That makes it a normative reference. The draft is = expired - are there plans to progress it?

- Something needs to talk about case-sensitivity of the various protocol el= ements. JSON-RPC says that member names are case sensitive and is otherwise= silent. The string "sensitive" doesn't appear in RFC4627. So= , you have an example that says "authority":"us". Is th= at the same as "authority":"US", and where does the spe= c answer that question? My read of JSON-RPC says that "authority"= :"us" and "Authority":"us" are _not_ the same= thing, and that the second would not be a recognized property of a Ruleset= Info object.

Minor Issues

- I'm not finding where you define the protocol version. I see "1.= 0" in the json examples in section 6. Where is it specified? Within a = given method, the only extension point I find other than changing the proto= col version is the *other concept in messages, which MUST be ignored when e= ither side doesn't understand them. So there should be some discussion = about what kind of change would require the protocol version number to chan= ge. Suppose you wanted to allow batching requests from several slaves into = one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but allowi= ng a list of DeviceDescriptors perhaps). Does this require a new protocol v= ersion, or is it just a new request type in this version? If you think it&#= 39;s a new request-type, should there be a request and response type and/or= method registry? =C2=A0And yes, I see how you could do this with JSON-RPC = batch, but if that's where you'd send this idea, why didn't you= do AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figur= e out what "The initialization message also represents extension point= s for database implementations or rulesets that require the explicit handsh= ake." is trying to say. Can you rephrase that more simply?)

- It's not clear what it means to "support" a ruleset. I infe= r that this means that the device has code that implements what's requi= red by the name. Can you state that explicitly? Does a Master device have t= o have this code? Could it simply be a box that only serves to answer reque= sts from Slave devices? If so, why does it care what the rulesets actually = are. If a slave can ask and a database can answer, should a master just sho= vel the bits, or is there a requirement that the master device be configure= d to handle a ruleset before a slave can ask about it?

- In the last paragraph of section 4.1 (before 4.1.1 starts), "If the = Device is already operating" assumes that the device could only be ope= rating if it had previously contacted some database. The problem is that th= e device was able to reach a database at one point and now it can't rea= ch any. =C2=A0It would read more clearly if you said that explicitly.

- Please point somewhere for a definition of the terms 'uncertainty'= ; and 'confidence' (I suggest draft-ietf-geopriv-uncertainty= ). The GEOPRIV working group has gone through many iterations of disagreeme= nt about what these terms mean and how they should be used. For a taste, sk= im some of <https://mailarchive.ie= tf.org/arch/search/?email_list=3Dgeopriv&q=3Duncertainty<= /a>>. If you don't point to a hard definition, your implementation c= ommunity will have to go through the same arguments.

- Should the security considerations section talk about the risk of collisi= ons in serialNumber (since it is the only required element in DeviceDescrip= tor, and isn't a particularly secret thing)? Is there any harm at the d= atabase if two devices innocently end up sending the same serial number (wi= thout providing any of the optional information that would otherwise disamb= iguate the devices)? Can a device learn anything useful about another devic= e by spoofing it? Is it possible that in some regulatory realm, some device= s would get more access than others, encouraging devices to ask about what = their competition gets to do? Can harm be done by a device sending SPECTRUM= _USE_NOTIFY messages claiming to be some other serial number (and perhaps m= anufacturer) maliciously? I think this needs more discussion than what RFC6= 953 contains.

- The use of the "id" parameter from JSON-RPC deserves more discu= ssion. The JSON-RPC spec allows it to be string, numeric (without a fractio= nal part), NULL or missing. You've chosen to require it (since you'= re not using json-rpc notifications), and not allowing numeric values (why?= ). Are you making any other assumptions about what it should contain? I thi= nk you're assuming a level of uniqueness that would let you use the Bat= ch mechanism in section 6 of JSON-RPC (otherwise, the HTTP request/response= context is enough to associate the request and response and the id might a= s well be constant).

- Section 7 says a server can reject a GET with a 404 - wouldn't that h= ave consequences for a later POST? Why wouldn't it use a 405?

- The draft calls for the creation of a special list for review requests fo= r the IANA assignments. This may be ok (mailing lists are easy to set up), = but is there not an existing list that would serve the purpose just as well= ?

Nits

- RFC 2616 has been obsoleted - the references should be updated.

- It would help to have an example of a ruleset in the definition in the Te= rminology section and perhaps for that definition to more strongly convey t= hat it is a name in a namespace, and what that rule means is elsewhere. =C2= =A0(Right now the definition says that the ruleset is the actual set of rul= es, not a name, and it made reading the protocol overview much harder than = it needed to be). At the very least, pointing to the examples in section 9 = early would help.

- Is the document loosely borrowing UML, or are the diagrams used in sectio= n 4 of a format formally defined in some other RFC? A pointer to a definiti= on of the format, or a brief description noting it's based on UML along= with where the base types are defined would be useful.

- "One approach to manage spectrum sharing" is awkward. Would &qu= ot;One approach to managing spectrum sharing" or "One approach to= the management of spectrum sharing" work?

- There are several instances of "The Device needs to use the informat= ion to update its list". Consider clarifying 'needs to'. Shoul= d this have been MUST?

- "The vertices MUST be defined in a counter-clockwise direction"= assumes you are looking at them from above - please be explicit.

- Section 9.1.2's first paragraph should say "FCC and ETSI" t= he same way 9.2.2 does. You could generalize that to "any particular s= et of authorities".

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



--
-vince
--089e013a28645fe8ac04fdab4818-- From nobody Tue Jul 8 12:36:12 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 9FE641A0305 for ; Tue, 8 Jul 2014 12:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 oOfTpcqqqCHK for ; Tue, 8 Jul 2014 12:36:06 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0821A058E for ; Tue, 8 Jul 2014 12:36:05 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id z60so5670731qgd.30 for ; Tue, 08 Jul 2014 12:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z0oZbw1B2L4+tPFiCx0ihIeVHEupk+KA5V9S8tfxnd8=; b=IEmEVcY3009J7vObK4KkNCHlzLbThN1agNo3zyxQmSQ+LXD4rvTmU3flRfpOAlvqRW OZ4+0giGtlbhsbUS9Ewg79zFnKaEy/6l31BLA0KkC+p85k1+Rw7VsD2zUnEZfqCqsBUl eDiNNmEwWhIPQRsCuaayT5pWhGZSmixPeQD3+XWA1k2mCVdCEwN188jxhq49qM4JwotO TBRTLQceTI9ulUBMelBXtGIUZldhbKWIDkPgn/LK9EGONp2UtnEkYOsJNTGvnZLyoPHn k/9mh/fMp9OaV4LETBcjO5wu1eAkDXciFk2Fp7jEZ4usCRor0nDoVZyERdXAyVI7a7q+ DsWg== MIME-Version: 1.0 X-Received: by 10.224.123.71 with SMTP id o7mr61959299qar.38.1404848165093; Tue, 08 Jul 2014 12:36:05 -0700 (PDT) Received: by 10.140.50.6 with HTTP; Tue, 8 Jul 2014 12:36:05 -0700 (PDT) Date: Tue, 8 Jul 2014 12:36:05 -0700 Message-ID: From: Gabor Bajko To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0da26d836b004fdb3b3d7 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/NR_h8cYNm4CZgwZBGT-iowr5fXw Subject: [paws] Toronto meeting 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: Tue, 08 Jul 2014 19:36:10 -0000 --047d7bf0da26d836b004fdb3b3d7 Content-Type: text/plain; charset=UTF-8 Folks, We have an one hour PAWS session scheduled for Tuesday afternoon of the Toronto meeting. If you would like to present, send a request to the chairs please. Gabor --047d7bf0da26d836b004fdb3b3d7 Content-Type: text/html; charset=UTF-8
Folks,

We have an one hour PAWS session scheduled for Tuesday afternoon of the Toronto meeting.
If you would like to present, send a request to the chairs please.

Gabor
--047d7bf0da26d836b004fdb3b3d7-- From nobody Tue Jul 8 19:22:02 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 A6A281A0299 for ; Tue, 8 Jul 2014 19:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 CwccSOhLUfM3 for ; Tue, 8 Jul 2014 19:21:52 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1A41A0270 for ; Tue, 8 Jul 2014 19:21:52 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id lf12so6288884vcb.18 for ; Tue, 08 Jul 2014 19:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t7wGLZX/Z1OiWip+e9BaemExXOJbdIk+aHYNBGbvpMo=; b=UgFdn/YUdXX7tPPVn9ip3d3or5leQaXMQwT1HKA9sbC4JPrLjv1LznygBZBe2t6kjr 4664sUslfLORr2vpehnxgFOrjNRAQK8VBn7wUzoQqUEzP3FSk1naomIHNBRNW3VWJZgf AzAC15n2q5RbigQwBwhntYerCSXLzu150NYYr10w1zFhlIdhaAWgyTMZW2mzrPt9u9aq dsZQEJTCGLob/hVc0hcwP2ta+s4Fm2wc6b0X2f4vJ9yT9WhB62E1RWDoeluFobJ7WY2o p49Pcd2YWyPALm2kT1TAoxXmxZ8D8HJbeudtRg9/ANhJZ8VCvagAcJKW77TWzfhMeX80 iHUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t7wGLZX/Z1OiWip+e9BaemExXOJbdIk+aHYNBGbvpMo=; b=feW4oNNiWpEOCzO65KQsugtf6g+rDvxjufbjG4ZlCQt5LmuegLnrkb7zfPM0sQ9Xbl YB3SZlLIXRdAfH7MTGjpnbh8tZZvMx8QvtdnZr7wBi0prfqm/pUcRbsxrGehRgttI0Ei KUzy4yFi464/iIax9LK0Fyzpq5AUsAIgluyw9YJGkpkq2W+wZoXDUgTjWkt5LWwtxsbK jpgYERN0feFjOZ5q3to0Daf+X4UxnrIhMQzdRnmbEoY5Oxg1AFQtWHpayMkIyEtAgt1h Zxz8fjbH5afMChjQnlKbT8Uy1oaTMRhj9DgiH9yzS5n2zTu39j7Qbl/4EFPymXWrks70 lodQ== X-Gm-Message-State: ALoCoQmBFqdm976q56JagJBlF3HldNICg/KC6f5Fq8njwdd9U4lL0sWFHPexVNefGPepDD/C2n0n MIME-Version: 1.0 X-Received: by 10.52.34.46 with SMTP id w14mr5656vdi.64.1404872511478; Tue, 08 Jul 2014 19:21:51 -0700 (PDT) Received: by 10.52.180.163 with HTTP; Tue, 8 Jul 2014 19:21:51 -0700 (PDT) In-Reply-To: <53B592A2.2080202@nostrum.com> References: <53B592A2.2080202@nostrum.com> Date: Tue, 8 Jul 2014 19:21:51 -0700 Message-ID: From: Vincent Chen To: Robert Sparks Content-Type: multipart/alternative; boundary=20cf307ca3b8008db604fdb95f3f Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ItMU-qA9DT7AJNkGUr49P7eGwRs Cc: "paws@ietf.org" , General Area Review Team , "ietf@ietf.org" , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Gen-art LC review: draft-ietf-paws-protocol-12 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: Wed, 09 Jul 2014 02:21:57 -0000 --20cf307ca3b8008db604fdb95f3f Content-Type: text/plain; charset=UTF-8 Robert, Thanks again for the review. I have place comments, questions, suggested text inline for each of your comments. Please take a look. -vince On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-paws-protocol-12 > Reviewer: Robert Sparks > Review Date: 3 July, 2014 > IETF LC End Date: 7 July, 2014 > IESG Telechat date: 10 July, 2014 > > Summary: This document is not ready for publication as a Proposed Standard. > > I apologize in advance if I've missed where one of the questions below is > already answered. There's a lot to take in here. > > Major Issues > > - The document says it "describes" the use of HTTP/TLS as the transport > for the protocol. Was it the intent to allow others? If not, the language > should be firmed up. > The protocol messages are meaningful independent of the transport, so we did not want to prohibit others. It that frowned on? > > - The document still says "TBD Define message format" in the section on > Listing Servers. I understand from reading the list that what the document > is going to say about Listing Servers is going to change (to not include > how you talk to them?). This change needs to be finished before the > document can be reviewed for completeness. > Noted. Will ask again on the list. > > - It's not clear when a server should use the HTTP level redirection > discussed in section 7 vs the databaseChange mechanism in the protocol's > responses. There should be some discussion about what the Device should do > when the databaseChange mechanism results in a redirect loop. > Thanks for pointing this out. I propose removing the HTTP-level 301 Moved Permanently mechanism and only have the databaseChange mechanism. Proposed modified text in Section 4.1: A Database MAY indicate that its URI will be changing by including the URI of one or more alternate databases (See DbUpdateSpec (Section 5.7)) in its responses to a Device. Before a Database ceases operation, for example, it MUST include DbUpdateSpec in its responses to notify Devices. A Device will update its preconfigured list of databases to replace (only) its entry for the responding Database with the URIs of the alternate databases; the list of alternate databases does not affect any other entries. Note that the ordering of databases in the list does not imply any preference and does not need to remain the same for every request. The Device SHOULD detect infinite redirection loops; if a suitable database cannot be contacted, the Device MUST treat this as equivalent to a response indicating no available spectrum. > > - The document needs to be clear where the primitive types (like string, > float, and integer) in the UML-ish diagrams in section 4 are defined. I'm > guessing from context that you're assuming the definitions in RFC4627. If > that's true, there are several places that you talk about string where your > text should change. RFC4627 says string is UNICODE, and may be encoded many > ways (see section 3 of that document). If your intent is to restrict all > strings to UTF-8 encoding say that, and adjust the text you currently have > that mentions UTF-8. (The various places where you say a string MAY contain > UTF-8 do not make sense - if you're assuming the encoding is UTF-8 and > trying to reinforce that there may be non-ASCII range UTF-8 here, say that > explicitly). There are other related phrases that don't make sense such as > where you say things like "The length of the string MUST NOT exceed 64 > US-ASCII characters." > OK. Specified UTF-8 and removed meaningless statements. Proposed added text in Section 4: The parameter tables in this section and Protocol Parameters (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 diagrams are loosely based on UML, and the data types are defined either in Protocol Parameters (Section 5) or are one of the following primitive or structured types: string A string, as defined by The JavaScript Object Notation (JSON) Data Interchange Format [RFC7159], restricted to the UTF-8 encoding. int A number, as defined by The JavaScript Object Notation (JSON) Data Interchange Format [RFC7159], without a fractional or exponent part. float A number, as defined by The JavaScript Object Notation (JSON) Data Interchange Format [RFC7159]. boolean A boolean, as defined by The JavaScript Object Notation (JSON) Data Interchange Format [RFC7159]. list A structured type the represents a list of elements, as defined by The JavaScript Object Notation (JSON) Data Interchange Format [RFC7159] array type. For each list parameter, its diagram and description include a reference to the data type its list elements. The diagram notation and description may include additional constraints, such as minimum or maximum number of elements. NOTE: All parameter names are case sensitive. Unless stated otherwise, all string values are case sensitive. > - The descriptions of messages in section 4 all contain *other:any. None > of those are reflected in the concrete schema of section 6. Should they be? > This was intended to be capture by the note in Section 6: NOTE: In general, all messages defined in this section are extensible by adding additional properties to support ruleset-specific and database-specific requirements. In all cases, the Device or Database MUST ignore any parameter it does not understand. > > - The INIT_RESP description requires one or more RulesetInfo objects. What > is a database supposed to do if it has no rulesets to return (possibly > because it doesn't have anything overlapping with the list of ruleset IDs > listed in the DeviceDescriptor in the INIT_REQ.). Should this have been > 0..* (along with the corresponding change to the text), or is there an > Error that the database should return when this happens. If the latter, it > would be good to call it out in 4.2.2. > This was indicated in the prior section for INIT_REQ, but propose adding the following as first paragraph: The initialization response message communicates database parameters to the requesting device. This response is returned only when there is at least one ruleset. Otherwise, the Database returns an error response, as described in INIT_REQ (Section 4.2.1). > > - Section 4.4 talks about returning OUTSIDE_COVERAGE when the location > specified in the request is outside the regulatory domain (could that be > domains?) supported by the database. The sections on init and registration > (4.2 and 4.3) don't have this discussion. Should they? > Yes. Added to those requests. Thanks. > > - A databaseChange (at least as described in 4.4) can provide one or more > alternate database URIs, affecting the Device's configuration. When there's > more than one, is there any preference to what order the Device should try > to use them in? Is there any expectation that they will give the same > answers to a given request? If not, do you want to say anything about > discouraging devices from asking all the databases it knows about to find > an answer it likes best? > In general, there should be no difference in answers, because each Database must also conform to the regulatory rules. There is no significance implied by the list ordering. On the other hand, I don't think we need language discouraging devices from asking multiple databases, since they should have an understanding of the rules as well. See proposed text above that contains: Note that the ordering of databases in the list does not imply any preference and does not need to remain the same for every request. > > - If the requirements to act as if there is no available whitespace when > you can't reach a Listing Server remain in the document, the security > considerations should call out that any attack that would prevent reaching > a Listing Server would result in all devices relying on that Listing Server > ceasing their use of any whitespace. > Thanks. Added. > > - Please check the description of 'timeRange' in section 5.9 > (SpectrumSpec). I think you meant to say "in which there is _NO_ available > spectrum". > Thanks for the catch! > > - The definition of SpectrumProfile (section 5.12) needs clarification. Is > this allowed? > "profiles" : [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.24e8, "dbm": 37.0 } > ] > If so, what does it mean? Do I do linear interpolation between points > (33.5 dbm (~2.25 watts) at 521Mhz)? > Similarly, does this specify a ramp up and then back down? (shaped like a > ^)? > [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.21e8, "dbm": 33.5 }, > {"hz": 5.24e8, "dbm": 30.0 } > ] > If not, what text disallows it? > This is explicitly allowed. We changed the encoding to allow this. Propose modifying the first paragraph of 5.12 to the following: A spectrum profile is characterized by an ordered list of (frequency, power) points that represents the shape of maximum permissible power levels over a range of frequencies as a piecewise linear curve. Also add after the list of constraints: NOTE: This encoding allows presentation of "ramps" where the slope of a line segment may be finite and non-zero. > > - You are using the schema language defined in draft-zyp-json-schema to > define your message format. That makes it a normative reference. The draft > is expired - are there plans to progress it? > Yikes. The intent is not to define a strict, formal schema, but just to have a way of defining the messages in a concise fashion. Do you have a recommendation of what to do here? Are the descriptions self-explanatory enough? or do I have to define the "schema language". > > - Something needs to talk about case-sensitivity of the various protocol > elements. JSON-RPC says that member names are case sensitive and is > otherwise silent. The string "sensitive" doesn't appear in RFC4627. So, you > have an example that says "authority":"us". Is that the same as > "authority":"US", and where does the spec answer that question? My read of > JSON-RPC says that "authority":"us" and "Authority":"us" are _not_ the same > thing, and that the second would not be a recognized property of a > RulesetInfo object. > You're right. See above proposed text defining the primitive types. > > Minor Issues > > - I'm not finding where you define the protocol version. I see "1.0" in > the json examples in section 6. Where is it specified? Within a given > method, the only extension point I find other than changing the protocol > version is the *other concept in messages, which MUST be ignored when > either side doesn't understand them. So there should be some discussion > about what kind of change would require the protocol version number to > change. Suppose you wanted to allow batching requests from several slaves > into one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but > allowing a list of DeviceDescriptors perhaps). Does this require a new > protocol version, or is it just a new request type in this version? If you > think it's a new request-type, should there be a request and response type > and/or method registry? And yes, I see how you could do this with JSON-RPC > batch, but if that's where you'd send this idea, why didn't you do > AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figure out > what "The initialization message also represents extension points for > database implementations or rulesets that require the explicit handshake." > is trying to say. Can you rephrase that more simply?) > Good point. Propose adding a new section: 4.2. PAWS Version PAWS version uses a "." numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the Device or Database to indicate the format of a message and its understanding of PAWS functionality defined by that version. No change is made to the version string for the addition of message components which only add to extensible field values. The number is incremented when the changes made to the protocol add functionalities (methods), but do not change the existing functionalities. The number is incremented when incompatible changes are made to existing functionality. The current PAWS version is "1.0". > > - It's not clear what it means to "support" a ruleset. I infer that this > means that the device has code that implements what's required by the name. > Can you state that explicitly? Does a Master device have to have this code? > Could it simply be a box that only serves to answer requests from Slave > devices? If so, why does it care what the rulesets actually are. If a slave > can ask and a database can answer, should a master just shovel the bits, or > is there a requirement that the master device be configured to handle a > ruleset before a slave can ask about it? > OK. Propose update Terminology section to distinguish between "ruleset" and "ruleset identifier": Ruleset: A ruleset represents a set of rules that governs the operation of white space devices and Spectrum Databases. A regulatory authority can define its own set of rules or adopt an existing ruleset. When a Database or Device is said to "support a ruleset", it means that it contains out-of-band knowledge of the rules and that its hardware and software implementations conform to those rules. Ruleset Identifier: A ruleset can be identified by an IANA- registered identifier (see PAWS Ruleset ID Registry (Section 9.1)). When a Database or Device indicates it supports a ruleset identifier, it means that it conforms to the rules associated with that identifier. A regulatory authority can define and register its own ruleset identifiers, or it can use a previously registered identifier if it adopts an existing ruleset. > > - In the last paragraph of section 4.1 (before 4.1.1 starts), "If the > Device is already operating" assumes that the device could only be > operating if it had previously contacted some database. The problem is that > the device was able to reach a database at one point and now it can't reach > any. It would read more clearly if you said that explicitly. > Proposed change: If the Device had previously contacted a database to get available spectrum, but subsequently fails to contact a suitable database, the spectrum the Device is currently using can be used for as long as the spectrum data is valid; ... > > - Please point somewhere for a definition of the terms 'uncertainty' and > 'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV > working group has gone through many iterations of disagreement about what > these terms mean and how they should be used. For a taste, skim some of < > https://mailarchive.ietf.org/arch/search/?email_list=geopriv&q=uncertainty>. > If you don't point to a hard definition, your implementation community will > have to go through the same arguments. > Done. Although regulatory authorities may prescribe their own definitions. > > - Should the security considerations section talk about the risk of > collisions in serialNumber (since it is the only required element in > DeviceDescriptor, and isn't a particularly secret thing)? Is there any harm > at the database if two devices innocently end up sending the same serial > number (without providing any of the optional information that would > otherwise disambiguate the devices)? Can a device learn anything useful > about another device by spoofing it? Is it possible that in some regulatory > realm, some devices would get more access than others, encouraging devices > to ask about what their competition gets to do? Can harm be done by a > device sending SPECTRUM_USE_NOTIFY messages claiming to be some other > serial number (and perhaps manufacturer) maliciously? I think this needs > more discussion than what RFC6953 contains. > Re: Available spectrum. The available spectrum depends on device type and location, not on serial number. Consequently, there is no advantage to spoofing, and there would be no additional information to be gained on spoofed devices. If, in the future, there is some regulatory realm that would set up rules differently, then I think security considerations would be extended to handle those cases. Re: SPECTRUM_USE_NOTIFY I suppose this depends on the specific regulatory domains (or database implementations) that require it. Currently there is no harm, since notifications do not change the available spectrum answers that the Database returns to devices. So should I add these statements to the Security Considerations section? > > - The use of the "id" parameter from JSON-RPC deserves more discussion. > The JSON-RPC spec allows it to be string, numeric (without a fractional > part), NULL or missing. You've chosen to require it (since you're not using > json-rpc notifications), and not allowing numeric values (why?). Are you > making any other assumptions about what it should contain? I think you're > assuming a level of uniqueness that would let you use the Batch mechanism > in section 6 of JSON-RPC (otherwise, the HTTP request/response context is > enough to associate the request and response and the id might as well be > constant). > Purely as a practical matter, handling a known type is easier than multi-type. It should improve interoperability. Otherwise, its value remains opaque to the Database. What is your recommendation here? > > - Section 7 says a server can reject a GET with a 404 - wouldn't that have > consequences for a later POST? Why wouldn't it use a 405? > Yes, it's supposed to be 405. > > - The draft calls for the creation of a special list for review requests > for the IANA assignments. This may be ok (mailing lists are easy to set > up), but is there not an existing list that would serve the purpose just as > well? > I do not believe there is an existing list, unless it's standard practice to re-use this discussion group (paws@ietf.org). > > Nits > > - RFC 2616 has been obsoleted - the references should be updated. > Updating to RFC 7231 > > - It would help to have an example of a ruleset in the definition in the > Terminology section and perhaps for that definition to more strongly convey > that it is a name in a namespace, and what that rule means is elsewhere. > (Right now the definition says that the ruleset is the actual set of > rules, not a name, and it made reading the protocol overview much harder > than it needed to be). At the very least, pointing to the examples in > section 9 early would help. > See proposed text of Terminology above. > > - Is the document loosely borrowing UML, or are the diagrams used in > section 4 of a format formally defined in some other RFC? A pointer to a > definition of the format, or a brief description noting it's based on UML > along with where the base types are defined would be useful. > See proposed text of primitive types above. Do I need a reference to UML? > > - "One approach to manage spectrum sharing" is awkward. Would "One > approach to managing spectrum sharing" or "One approach to the management > of spectrum sharing" work? > Thanks. Changing to "One approach to managing spectrum sharing" > > - There are several instances of "The Device needs to use the information > to update its list". Consider clarifying 'needs to'. Should this have been > MUST? > These were changed based on comments from our AD (Pete), since they are not a protocol requirement. > - "The vertices MUST be defined in a counter-clockwise direction" assumes > you are looking at them from above - please be explicit. > Thanks. Adding clarification. > > - Section 9.1.2's first paragraph should say "FCC and ETSI" the same way > 9.2.2 does. You could generalize that to "any particular set of > authorities". > Thanks for the suggestion. Changing both to "any particular set of authorities". > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --20cf307ca3b8008db604fdb95f3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

Thanks again for the review. I = have place comments, questions, suggested text inline for each of your comm= ents.
Please take a look.

-vince


On Thu, Jul 3, 2014 at 10:28 AM, Robert= Sparks <rjsparks@nostrum.com> wrote:
I am the assigned Gen-ART reviewer for this draft. For bac= kground on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtf= aq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-paws-protocol-12
Reviewer: Robert Sparks
Review Date: 3 July, 2014
IETF LC End Date: 7 July, 2014
IESG Telechat date: 10 July, 2014

Summary: This document is not ready for publication as a Proposed Standard.=

I apologize in advance if I've missed where one of the questions below = is already answered. There's a lot to take in here.

Major Issues

- The document says it "describes" the use of HTTP/TLS as the tra= nsport for the protocol. Was it the intent to allow others? If not, the lan= guage should be firmed up.

The protocol messages are meaningful independent of the transp= ort, so we did not want to prohibit others. It that frowned on?
=C2=A0

- The document still says "TBD Define message format" in the sect= ion on Listing Servers. I understand from reading the list that what the do= cument is going to say about Listing Servers is going to change (to not inc= lude how you talk to them?). This change needs to be finished before the do= cument can be reviewed for completeness.

Noted. Will ask ag= ain on the list.
=C2=A0

- It's not clear when a server should use the HTTP level redirection di= scussed in section 7 vs the databaseChange mechanism in the protocol's = responses. There should be some discussion about what the Device should do = when the databaseChange mechanism results in a redirect loop.

Thanks for pointin= g this out. I propose removing the HTTP-level 301 Moved Permanently mechani= sm and only have the databaseChange mechanism.

Proposed modified text in Section= 4.1:
=C2=A0 =C2=A0A Database= MAY indicate that its URI will be changing by including
=C2=A0 = =C2=A0the URI of one or more alternate databases (See DbUpdateSpec
=C2=A0 =C2=A0(Section 5.7)) in its responses to a Device. =C2=A0Before= a Database
=C2=A0 =C2=A0ceases operation, for example, it MUST i= nclude DbUpdateSpec in its
=C2=A0 =C2=A0responses to notify Devic= es. =C2=A0A Device will update its preconfigured
=C2=A0 =C2=A0list of databases to replace (only) its entry for the res= ponding
=C2=A0 =C2=A0Database with the URIs of the alternate data= bases; the list of
=C2=A0 =C2=A0alternate databases does not affe= ct any other entries. =C2=A0Note that the
=C2=A0 =C2=A0ordering of databases in the list does not imply any pref= erence and
=C2=A0 =C2=A0does not need to remain the same for ever= y request. =C2=A0The Device
=C2=A0 =C2=A0SHOULD detect infinite r= edirection loops; if a suitable database
=C2=A0 =C2=A0cannot be contacted, the Device MUST treat this as equiva= lent to a
=C2=A0 =C2=A0response indicating no available spectrum.=
=C2=A0=C2=A0
=C2=A0

- The document needs to be clear where the primitive types (like string, fl= oat, and integer) in the UML-ish diagrams in section 4 are defined. I'm= guessing from context that you're assuming the definitions in RFC4627.= If that's true, there are several places that you talk about string wh= ere your text should change. RFC4627 says string is UNICODE, and may be enc= oded many ways (see section 3 of that document). If your intent is to restr= ict all strings to UTF-8 encoding say that, and adjust the text you current= ly have that mentions UTF-8. (The various places where you say a string MAY= contain UTF-8 do not make sense - if you're assuming the encoding is U= TF-8 and trying to reinforce that there may be non-ASCII range UTF-8 here, = say that explicitly). There are other related phrases that don't make s= ense such as where you say things like "The length of the string MUST = NOT exceed 64 US-ASCII characters."

OK. Specified UTF-= 8 and removed meaningless statements.

Proposed added text in Section 4:

=C2=A0 =C2=A0The parameter t= ables in this section and Protocol Parameters
=C2=A0 =C2=A0(Secti= on 5) are for reference and contain the name of each parameter,
= =C2=A0 =C2=A0the data type of each parameter, and whether the existence of = the
=C2=A0 =C2=A0parameter is required for the protocol transaction in que= stion. =C2=A0The
=C2=A0 =C2=A0diagrams are loosely based on UML, = and the data types are defined
=C2=A0 =C2=A0either in Protocol Pa= rameters (Section 5) or are one of the following
=C2=A0 =C2=A0primitive or structured types:

= =C2=A0 =C2=A0string =C2=A0A string, as defined by The JavaScript Object Not= ation (JSON)
=C2=A0 =C2=A0 =C2=A0 Data Interchange Format [RFC715= 9], restricted to the UTF-8
=C2=A0 =C2=A0 =C2=A0 encoding.

=C2=A0 =C2=A0int = =C2=A0A number, as defined by The JavaScript Object Notation (JSON)
=C2=A0 =C2=A0 =C2=A0 Data Interchange Format [RFC7159], without a fracti= onal or
=C2=A0 =C2=A0 =C2=A0 exponent part.

=C2=A0 =C2=A0float =C2=A0A number, as defined by The Ja= vaScript Object Notation (JSON)
=C2=A0 =C2=A0 =C2=A0 Data Interch= ange Format [RFC7159].

=C2=A0 =C2=A0boolean =C2=A0= A boolean, as defined by The JavaScript Object Notation
=C2=A0 =C2=A0 =C2=A0 (JSON) Data Interchange Format [RFC7159].

=C2=A0 =C2=A0list =C2=A0A structured type the represents = a list of elements, as defined
=C2=A0 =C2=A0 =C2=A0 by The JavaSc= ript Object Notation (JSON) Data Interchange Format
=C2=A0 =C2=A0 =C2=A0 [RFC7159] array type. =C2=A0For each list paramet= er, its diagram and
=C2=A0 =C2=A0 =C2=A0 description include a re= ference to the data type its list
=C2=A0 =C2=A0 =C2=A0 elements. = =C2=A0The diagram notation and description may include
=C2=A0 =C2=A0 =C2=A0 additional constraints, such as minimum or maximu= m number of
=C2=A0 =C2=A0 =C2=A0 elements.

=C2=A0 =C2=A0NOTE: All parameter names are case sensitive. =C2=A0Unless = stated
=C2=A0 =C2=A0otherwise, all string values are case sensiti= ve.


- The descriptions of messages in section 4 all contain *other:any. None of= those are reflected in the concrete schema of section 6. Should they be?

This was intende= d to be capture by the note in Section 6:

= =C2=A0 =C2=A0NOTE: In general, all messages defined in this section are ext= ensible
=C2=A0 =C2=A0by adding add= itional properties to support ruleset-specific and
=C2=A0 =C2=A0database-specific requirements. = =C2=A0In all cases, the Device or Database
=C2=A0 =C2=A0MUST ignore any parameter it does not understand.
=C2=A0

- The INIT_RESP description requires one or more RulesetInfo objects. What = is a database supposed to do if it has no rulesets to return (possibly beca= use it doesn't have anything overlapping with the list of ruleset IDs l= isted in the DeviceDescriptor in the INIT_REQ.). Should this have been 0..*= (along with the corresponding change to the text), or is there an Error th= at the database should return when this happens. If the latter, it would be= good to call it out in 4.2.2.

This was indicated= in the prior section for INIT_REQ, but propose adding the following as fir= st paragraph:

=C2=A0 =C2=A0The initialization response messa= ge communicates database parameters
=C2=A0 =C2=A0to the requestin= g device. =C2=A0This response is returned only when there
=C2=A0 = =C2=A0is at least one ruleset. =C2=A0Otherwise, the Database returns an err= or
=C2=A0 =C2=A0response, as described in INIT_REQ (Section 4.2.1).
=

=C2=A0

- Section 4.4 talks about returning OUTSIDE_COVERAGE when the location spec= ified in the request is outside the regulatory domain (could that be domain= s?) supported by the database. The sections on init and registration (4.2 a= nd 4.3) don't have this discussion. Should they?

Yes. Added to thos= e requests. Thanks.
=C2=A0

- A databaseChange (at least as described in 4.4) can provide one or more a= lternate database URIs, affecting the Device's configuration. When ther= e's more than one, is there any preference to what order the Device sho= uld try to use them in? Is there any expectation that they will give the sa= me answers to a given request? If not, do you want to say anything about di= scouraging devices from asking all the databases it knows about to find an = answer it likes best?

In general, there = should be no difference in answers, because each Database must also conform= to the regulatory rules. There is no significance implied by the list orde= ring. On the other hand, I don't think we need language discouraging de= vices from asking multiple databases, since they should have an understandi= ng of the rules as well.

= See proposed text above that contains:

=C2=A0 =C2=A0Note t= hat the
=C2=A0 =C2=A0ordering of databases in the list does not imply any preferenc= e and
=C2=A0 =C2=A0does not need to remain the same for every req= uest.
=C2=A0

- If the requirements to act as if there is no available whitespace when yo= u can't reach a Listing Server remain in the document, the security con= siderations should call out that any attack that would prevent reaching a L= isting Server would result in all devices relying on that Listing Server ce= asing their use of any whitespace.

Thanks. Added.
=C2=A0

- Please check the description of 'timeRange' in section 5.9 (Spect= rumSpec). I think you meant to say "in which there is _NO_ available s= pectrum".

= Thanks for the catch!
=C2=A0

- The definition of SpectrumProfile (section 5.12) needs clarification. Is = this allowed?
=C2=A0 "profiles" : [
=C2=A0 =C2=A0 {"hz": 5.18e8, "dbm": 30.0 },
=C2=A0 =C2=A0 {"hz": 5.24e8, "dbm": 37.0 }
=C2=A0 ]
If so, what does it mean? Do I do linear interpolation between points (33.5= dbm (~2.25 watts) at 521Mhz)?
Similarly, does this specify a ramp up and then back down? (shaped like a ^= )?
=C2=A0 [
=C2=A0 =C2=A0 {"hz": 5.18e8, "dbm": 30.0 },
=C2=A0 =C2=A0 {"hz": 5.21e8, "dbm": 33.5 },
=C2=A0 =C2=A0 {"hz": 5.24e8, "dbm": 30.0 }
=C2=A0 ]
If not, what text disallows it?

This is explicitly allowed. We changed the encoding to all= ow this. Propose modifying the first paragraph of =C2=A05.12 to the followi= ng:

=
=C2=A0 =C2=A0A spectrum profile is characterized by an ordered list of= (frequency,
=C2=A0 =C2=A0power) points that represents the shape= of maximum permissible power
=C2=A0 =C2=A0levels over a range of frequencies as a piecewise linear = curve.

Also add after the list of constraints:

=C2=A0 =C2=A0NOTE: This encoding allows presenta= tion of "ramps" where the slope of
=C2=A0 =C2=A0a line segment may be finite and non-zero.



- You are using the schema language defined in draft-zyp-json-schema to def= ine your message format. That makes it a normative reference. The draft is = expired - are there plans to progress it?

Yikes. The intent is not to define a strict, f= ormal schema, but just to have a way of defining the messages in a concise = fashion.
Do you have a recommendat= ion of what to do here? Are the descriptions self-explanatory enough? or do= I have to define
the "schema language".
<= div>=C2=A0

- Something needs to talk about case-sensitivity of the various protocol el= ements. JSON-RPC says that member names are case sensitive and is otherwise= silent. The string "sensitive" doesn't appear in RFC4627. So= , you have an example that says "authority":"us". Is th= at the same as "authority":"US", and where does the spe= c answer that question? My read of JSON-RPC says that "authority"= :"us" and "Authority":"us" are _not_ the same= thing, and that the second would not be a recognized property of a Ruleset= Info object.

You're right. = See above proposed text defining the primitive types.
=C2= =A0

Minor Issues

- I'm not finding where you define the protocol version. I see "1.= 0" in the json examples in section 6. Where is it specified? Within a = given method, the only extension point I find other than changing the proto= col version is the *other concept in messages, which MUST be ignored when e= ither side doesn't understand them. So there should be some discussion = about what kind of change would require the protocol version number to chan= ge. Suppose you wanted to allow batching requests from several slaves into = one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but allowi= ng a list of DeviceDescriptors perhaps). Does this require a new protocol v= ersion, or is it just a new request type in this version? If you think it&#= 39;s a new request-type, should there be a request and response type and/or= method registry? =C2=A0And yes, I see how you could do this with JSON-RPC = batch, but if that's where you'd send this idea, why didn't you= do AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figur= e out what "The initialization message also represents extension point= s for database implementations or rulesets that require the explicit handsh= ake." is trying to say. Can you rephrase that more simply?)

Good point. Propos= e adding a new section:

4.2. =C2=A0PAWS Version

=C2=A0 =C2=A0PAWS version uses a = "<major>.<minor>" numbering scheme to indicate=
=C2=A0 =C2=A0versions of the protocol. = =C2=A0The protocol versioning policy is intended
=C2=A0 =C2=A0to allow the Device or Database t= o indicate the format of a message
=C2=A0 =C2=A0and its understanding of PAWS functionality defined by that v= ersion.
=C2=A0 =C2=A0No change is made to the version = string for the addition of message
=C2=A0 =C2=A0components which only add to extensible field values. =C2=A0T= he <minor>
=C2=A0 =C2=A0number is incremented when the ch= anges made to the protocol add
=C2= =A0 =C2=A0functionalities (methods), but do not change the existing<= /div>
=C2=A0 =C2=A0functionalities. =C2=A0The &= lt;major> number is incremented when incompatible
=C2=A0 =C2=A0changes are made to existing func= tionality.

<= font color=3D"#0000ff">=C2=A0 =C2=A0The current PAWS version is "1.0&q= uot;.
=C2=A0

- It's not clear what it means to "support" a ruleset. I infe= r that this means that the device has code that implements what's requi= red by the name. Can you state that explicitly? Does a Master device have t= o have this code? Could it simply be a box that only serves to answer reque= sts from Slave devices? If so, why does it care what the rulesets actually = are. If a slave can ask and a database can answer, should a master just sho= vel the bits, or is there a requirement that the master device be configure= d to handle a ruleset before a slave can ask about it?

OK. Propose update= Terminology section to distinguish between "ruleset" and "r= uleset identifier":

=C2=A0 =C2=A0Ruleset: =C2=A0A ruleset represen= ts a set of rules that governs the
=C2=A0 =C2=A0 =C2=A0 operation of white space devices and Spectrum Databas= es. =C2=A0A
=C2=A0 =C2=A0 =C2=A0 r= egulatory authority can define its own set of rules or adopt an
=C2=A0 =C2=A0 =C2=A0 existing ruleset. =C2=A0W= hen a Database or Device is said to "support a
=C2=A0 =C2=A0 =C2=A0 ruleset", it means that it cont= ains out-of-band knowledge of the
=C2=A0 =C2=A0 =C2=A0 rules and that its hardwa= re and software implementations conform
=C2=A0 =C2=A0 =C2=A0 to those rules.

=C2=A0 =C2=A0Ruleset= Identifier: =C2=A0A ruleset can be identified by an IANA-
=C2=A0 =C2=A0 =C2=A0 registered identifier (se= e PAWS Ruleset ID Registry
=C2=A0 = =C2=A0 =C2=A0 (Section 9.1)). =C2=A0When a Database or Device indicates it = supports a
=C2=A0 =C2=A0 =C2=A0 ru= leset identifier, it means that it conforms to the rules
=C2=A0 =C2=A0 =C2=A0 associated with that iden= tifier. =C2=A0A regulatory authority can
=C2=A0 =C2=A0 =C2=A0 define and register its own ruleset identifiers= , or it can use a
=C2=A0 =C2=A0 =C2=A0 previously registered identifi= er if it adopts an existing ruleset.
=C2=A0

- In the last paragraph of section 4.1 (before 4.1.1 starts), "If the = Device is already operating" assumes that the device could only be ope= rating if it had previously contacted some database. The problem is that th= e device was able to reach a database at one point and now it can't rea= ch any. =C2=A0It would read more clearly if you said that explicitly.

Proposed change:

=C2=A0 =C2=A0If the Device had previously contacted a datab= ase to get available
=C2=A0 =C2=A0spectrum, but subsequently fails = to contact a suitable database, the
=C2=A0 =C2=A0spectrum the Device is currently using can be used for as lo= ng as the
=C2=A0 =C2=A0spectrum data is valid; ...
=C2=A0

- Please point somewhere for a definition of the terms 'uncertainty'= ; and 'confidence' (I suggest draft-ietf-geopriv-uncertainty= ). The GEOPRIV working group has gone through many iterations of disagreeme= nt about what these terms mean and how they should be used. For a taste, sk= im some of <https://mailarchive.ie= tf.org/arch/search/?email_list=3Dgeopriv&q=3Duncertainty<= /a>>. If you don't point to a hard definition, your implementation c= ommunity will have to go through the same arguments.


- Should the security considerations section talk about the risk of collisi= ons in serialNumber (since it is the only required element in DeviceDescrip= tor, and isn't a particularly secret thing)? Is there any harm at the d= atabase if two devices innocently end up sending the same serial number (wi= thout providing any of the optional information that would otherwise disamb= iguate the devices)? Can a device learn anything useful about another devic= e by spoofing it? Is it possible that in some regulatory realm, some device= s would get more access than others, encouraging devices to ask about what = their competition gets to do? Can harm be done by a device sending SPECTRUM= _USE_NOTIFY messages claiming to be some other serial number (and perhaps m= anufacturer) maliciously? I think this needs more discussion than what RFC6= 953 contains.


=C2=A0 If, in the future, there is some regulatory = realm that would set up rules differently, then I think security considerat= ions would be extended to handle those cases.

Re: SPECTRUM_USE_NOTIFY
=C2=A0 I suppose this depends on the specific regu= latory domains (or database implementations) that require it. Currently the= re is no harm, since notifications do not change the available spectrum ans= wers that the Database returns to devices.

So should I add these statements to the Security Co= nsiderations section?
=C2=A0

- The use of the "id" parameter from JSON-RPC deserves more discu= ssion. The JSON-RPC spec allows it to be string, numeric (without a fractio= nal part), NULL or missing. You've chosen to require it (since you'= re not using json-rpc notifications), and not allowing numeric values (why?= ). Are you making any other assumptions about what it should contain? I thi= nk you're assuming a level of uniqueness that would let you use the Bat= ch mechanism in section 6 of JSON-RPC (otherwise, the HTTP request/response= context is enough to associate the request and response and the id might a= s well be constant).

Purely as a practi= cal matter, handling a known type is easier than multi-type. It should impr= ove interoperability. Otherwise, its value remains opaque to the Database.<= /font>

= What is your recommendation here?
=C2=A0

- Section 7 says a server can reject a GET with a 404 - wouldn't that h= ave consequences for a later POST? Why wouldn't it use a 405?

Yes, it's supposed t= o be 405.
=C2=A0

- The draft calls for the creation of a special list for review requests fo= r the IANA assignments. This may be ok (mailing lists are easy to set up), = but is there not an existing list that would serve the purpose just as well= ?
=C2=A0

Nits

- RFC 2616 has been obsoleted - the references should be updated.

Updating to RFC 7231
=C2=A0

- It would help to have an example of a ruleset in the definition in the Te= rminology section and perhaps for that definition to more strongly convey t= hat it is a name in a namespace, and what that rule means is elsewhere. =C2= =A0(Right now the definition says that the ruleset is the actual set of rul= es, not a name, and it made reading the protocol overview much harder than = it needed to be). At the very least, pointing to the examples in section 9 = early would help.

See proposed text = of Terminology above.
=C2=A0

- Is the document loosely borrowing UML, or are the diagrams used in sectio= n 4 of a format formally defined in some other RFC? A pointer to a definiti= on of the format, or a brief description noting it's based on UML along= with where the base types are defined would be useful.

See proposed text = of primitive types above. Do I need a reference to UML?
= =C2=A0

- "One approach to manage spectrum sharing" is awkward. Would &qu= ot;One approach to managing spectrum sharing" or "One approach to= the management of spectrum sharing" work?

Thanks. Changing to "One approach t= o managing spectrum sharing"
=C2=A0

- There are several instances of "The Device needs to use the informat= ion to update its list". Consider clarifying 'needs to'. Shoul= d this have been MUST?

These were changed based on comments from our AD (Pete), since they= are not a protocol requirement.


- "The vertices MUST be defined in a counter-clockwise direction"= assumes you are looking at them from above - please be explicit.

Thanks. Adding clarifica= tion.
=C2=A0

- Section 9.1.2's first paragraph should say "FCC and ETSI" t= he same way 9.2.2 does. You could generalize that to "any particular s= et of authorities".

Thanks for the suggestion. Changing both to "any particular = set of authorities".
=C2=A0

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



--
-vince
--20cf307ca3b8008db604fdb95f3f-- From nobody Mon Jul 14 12:31:58 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 0160F1A008D for ; Mon, 14 Jul 2014 12:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 TWA-9z1qhzAB for ; Mon, 14 Jul 2014 12:31:53 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26DF1A007C for ; Mon, 14 Jul 2014 12:31:52 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id el20so650899lab.38 for ; Mon, 14 Jul 2014 12:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=D2ZSBsnOh5a3qHwGLivjhUmUlM1nAjmN3ce4LlvHbjw=; b=NH1Xb0cCgszXApRK8ZTmyqjrxIa0XI2VfquGRmoj5Yppi/xk0jJvUVxX1zP+vDvADc +WbZnkupHel2tRqiXKXr2mONFxxfnEyHZB13BYnMMdkuNIjUm48O4ysMBebW5JCc4A4/ pWp187/9eiUJoy7UyxeQjIOMOIC2+3AJ4VwNQyzQMUM+lggBEbXeC5xDE+TEjJ31BLLV rLmR1togOf8SkjmShkLu5PP2dt0AW6DLWNASBgThRId3mCiW1nJoHl8QYYKBMuraSsiL tl2kW/v+g0su5jfGT6a+JodSN9whPee4ZO3amWw0bY11tBqhZEI4IGmHgAdyefSNe2z0 DqeA== MIME-Version: 1.0 X-Received: by 10.112.171.134 with SMTP id au6mr14606083lbc.21.1405366310898; Mon, 14 Jul 2014 12:31:50 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Mon, 14 Jul 2014 12:31:50 -0700 (PDT) Date: Mon, 14 Jul 2014 15:31:50 -0400 X-Google-Sender-Auth: 0Ltmsa4lJEJjhnwXR4Q7sGxw_G0 Message-ID: From: Barry Leiba To: paws@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/E37aJRSOdq19_9jOYbyKGupUalk Subject: [paws] Review of draft-ietf-paws-protocol-12 (by the other APP AD) 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, 14 Jul 2014 19:31:57 -0000 Hey, PAWS folk. As Pete has put the subject document on the 7 August telechat agenda, though he still has it in "Waiting for AD Go Ahead" state, I decided to review it now, rather than wait. I've found quite a list of issues, from large to small, which I've sorted below into three categories: "DISCUSS" are those that I would put in a DISCUSS ballot during IESG Evaluation. I think they're errors in the document that need to be corrected, or else things that need to be discussed and resolved. The most important in this category, and the only one I think will be difficult to resolve, is how to specify the JSON payload formally. "COMMENT -- substantive" are those that I would put in the non-blocking comments, but that I think are important to deal with, and that I'd hope we'd have a discussion about if the authors think a discussion is necessary. "COMMENT -- minor" are minor editorial issues that I think would be better corrected, but that I'm not going to grump about further. Discussion is always welcome, but should be pretty much unnecessary for these. I hope it's useful to get these comments earlier, rather than later. And, so, here they are, below. I've offered suggested text where I could, and I hope that helps as well. Barry ======================= DISCUSS ======================= -- Section 4 -- o Device Registration (Section 4.3) MAY be used by the Master Device and MAY be implemented by the Database, either as a separate component or as part of the Available Spectrum Query (Section 4.4) component. I don't think the first MAY is correct. If the database requires registration, it is *not* optional for the Master Device to use it. I think this needs some rework. The same is true with "Device Validation". This list also mixes "used", "supported", and "implemented", without making all the issues clear. If something MAY be used, does that mean it's optional to implement? If it MUST be supported, what does that say about its use? And what's the difference between "supported" and "implemented"? I strongly suggest that, if you're going to say that, you make it all clear, as to both implementation/support and use. The note after the list that says that some things are obvious... nah, one of it is obvious. -- Section 4.1 -- A Database MAY indicate that its URI will be changing by including the URI of one or more alternate databases (See DbUpdateSpec (Section 5.7)) in its responses to a Device. Before a Database ceases operation, for example, it MUST include DbUpdateSpec in its responses to notify Devices. I don't understand how the MAY and MUST are consistent with each other. Can you explain or fix it? -- Section 4.1.1 -- 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 Here's another 2119 conflict. It doesn't make sense to have a MUST for the time period if doing it at all is a SHOULD. Please sort this one out as well. -- Section 4.2 A Master Device SHOULD use the initialization procedure to exchange capability information with the Database whenever the Master Device powers up or initiates communication with the Database. But in Section 4 you said "Initialization (Section 4.2) MAY be used by the Master Device," and now you're saying "SHOULD"? You see why I'm on about the 2119 inconsistencies? When a Master Device is configured manually with these parameterized-rule values, it does not need to use the initialization procedure. Dos that mean that when it's not configured with them, it *does* need to? In other words, is this really a "MUST use initialization unless it's pre-configured with the values" thing? -- Section 4.2.1 -- deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is REQUIRED. If the Database does not support the device or any of the rulesets specified in the device descriptor, it MUST return an error with the UNSUPPORTED (Table 1) code in the error response. If the device descriptor does not contain any ruleset IDs, the Database SHOULD return a list of RulesetInfo (Section 5.6) parameters for each ruleset it supports at the specified location. What this says to me is that the Master Device uses an empty list of rulesets to query the list of supported rulesets. So: how does this work if the Database does not return its list of rulesets? Presumably, the Master Device did this because it needs the list, and then it didn't get it. What does it do now? Also, this is worded a bit confusingly. The list is REQUIRED, so it's not true that the Database SHOULD return a list. What you mean to tell us is what the Database SHOULD include in the list. I think it's really awkward to try to say that here in the query, rather than in the next section in the response. Try this: OLD (Section 4.2.1) deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is REQUIRED. If the Database does not support the device or any of the rulesets specified in the device descriptor, it MUST return an error with the UNSUPPORTED (Table 1) code in the error response. If the device descriptor does not contain any ruleset IDs, the Database SHOULD return a list of RulesetInfo (Section 5.6) parameters for each ruleset it supports at the specified location. NEW deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is REQUIRED. If the device descriptor does not contain any ruleset IDs, the Master Device is asking the Database to return a list of RulesetInfo (Section 5.6) parameters for each ruleset it supports at the specified location. END OLD (Section 4.2.2) rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be included in the response. Each RulesetInfo parameter corresponds to a ruleset supported by the Database and is applicable to the location specified in the INIT_REQ (Section 4.2.1) message. If the Device included a list of ruleset IDs in the DeviceDescriptor parameter of its INIT_REQ message, each RulesetInfo parameter in the response MUST match one of the specified ruleset IDs. NEW rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be included in the response. Each RulesetInfo parameter corresponds to a ruleset supported by the Database and is applicable to the location specified in the INIT_REQ (Section 4.2.1) message. If the Device included a list of ruleset IDs in the DeviceDescriptor parameter of its INIT_REQ message, each RulesetInfo parameter in the response MUST match one of the specified ruleset IDs. If the DeviceDescriptor did not contain any ruleset IDs, the Database SHOULD include in the list the RulesetInfo parameters for each ruleset it supports at the specified location. If the Database does not support the device or any of the rulesets specified in the DeviceDescriptor, it MUST instead return an error with the UNSUPPORTED (Table 1) code in the error response. END -- Section 4.3.2 -- If the Database accepts the registration for none of the rulesets it supports, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). I can't follow this sentence at all. Do you mean, "If the Database does not accept the registration for any of the rulesets" ? Or do you mean something else? Can you re-word this, please? -- Section 5.8 -- name: The display name for a database. It MAY contain UTF-8. What about all the other strings whose content format is unspecified? Are they allowed to contain UTF-8? If not, what *do* they contain? I see that the Gen-ART review mentioned this also, and the response will be to specify that all strings are encoded in UTF-8. Good. -- Section 6 -- How is the reference to JSON Schema [I-D.zyp-json-schema] not normative, when the 6.x subsections quite depend upon the understanding of the schema format that it describes? I see that the Gen-ART review mentioned this also, but the response is quite troubling. No, the mechanism you're using is not sufficiently self explanatory. I understand it -- I do -- but I had to figure it out (I decided not to go look at the Zyp draft), and we can't assume that arbitrary implementors will get it right. We need a well defined way to explain how JSON objects are constructed. And, unfortunately, the JSON working group chose *not* to take on a work item for this (which I was pushing for). We have at least three proposals (apart from Zyp, there's Newton (draft-newton-json-content-rules), and there's the mechanism that I proposed, which is used in Section 6.2 of RFC 7071), but nothing that's being taken forward as a standard yet. -- Section 6.6.2 -- The schema is missing the optional databaseChange property. -- Section 6.7.1 -- The schema is missing the optional masterDeviceDesc property. -- Section 6.8.11 -- The schema says that both properties are optional, but Section 5.14 says that they're both required. -- Section 6.8.13 -- The schema says that rulesetInfo is optional, but Section 5.9 says that it's required. -- Section 7 -- The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by HTTP/1.1 [RFC2616]). ... Since the Device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation (note that this represents an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods). The references to RFC2616 need to change to RFC7231, now that 2616 is obsolete. I see that the Gen-ART review mentioned this also, and you plan to change the reference. This should help you get that right: The change to 7231 also means that the note about the second citation can change. 2616 said this about redirecting a POST: --- RFC 2616 --- If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. ---------------- That advice has changed in 7231: --- RFC 7231 --- Automatic redirection needs to done with care for methods not known to be safe, as defined in Section 4.2.1, since the user might not wish to redirect an unsafe request. ---------------- In my view, that means that the parenthesized note in the quote above can be removed from this document. I also suggest using a section number in the citation, as you're citing a big document. So... OLD The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by HTTP/1.1 [RFC2616]). NEW The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by HTTP/1.1 Semantics and Content [RFC7231], Section 6.4). END OLD Since the Device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation (note that this represents an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods). NEW Since the Device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation, even though it is in response to an HTTP POST request. END -- Section 8.2 -- The parameter name SHOULD be lowerCamelCase. Why "SHOULD"? How does it affect interoperability? Wouldn't "Parameter names use lowerCamelCase by convention." work fine? -- Section 9 -- First, and most importantly, the IANA review interpreted your text to say that the registration policies are Expert Review; I interpret your text to say that they're Specification Required. Yet Vince replied to the IANA review without correcting that. Which policy do you intend? If it is Specification Required, you need to clear that up with IANA. Or just deal with my other comments in this section, and that might happen anyway. The text in this section seems to be commonly copied from somewhere. Perhaps you could tell me whence you copied it, so we can make an effort to stop people from doing that. The first paragraph is entirely unnecessary: please just remove it. The second paragraph and the list is fine, and the third is mostly OK, except for the URI. You'll need to ask IANA how they want to receive requests (by email or through a web URI), and specify that in paragraph 3 instead of what's there now. The fourth paragraph really needs to be entirely re-thought: it is not how IANA does expert review in the first place, and we shouldn't be telling IANA how to run their process in the second place. The fourth paragraph should say that all registries use the Specification Required policy [RFC5226], with a Designated Expert appointed by the IESG. It should note that instructions to the DE as to what she should look for and consider in evaluating a request are given below in the descriptions of each registry. It should say that the DE should take advice from the community through the designated mailing list, and that is why the registrant should post to the mailing list before formally requesting the registration from IANA. All the rest of the mechanics are part of IANA's process, and should not be specified here. One question: does it make sense for the review list to be a separate list, or couldn't the WG mailing list be reused for that purpose? ======================= COMMENT -- substantive ======================= General: You appear to sometimes use "parameter" to refer to a structure (such as GeoLocation) and also the fields within the parameter (see Section 5.1, for example). I find this confusing, and suggest that you do not use the same term for both. -- Section 3 -- In step 4, should this not say a word or two about what message it responds with? Might it respond, "To be, or not to be; that is the question?" Or is there an expected sort of response? Step 5 is the first mention of registration. A reference to where that process is explained would be useful here (as this step doesn't seem to fit into the flow). In step 7, this is the first mention of a Slave Device, so referring to "the Slave Device" doesn't make sense. Maybe you want something like, "If a Slave Device has made a request to the Master Device, the Master Device may verify..." ? It's not clear how step 7 relates to steps 6 and 8. In step 10, might it also send an error, refusal, or whatever? Or are those all considered acknowledgment messages? Hm, it seems that steps 5 and 7 are actually explained in the paragraph after the numbered steps. So do they really belong in the numbered steps at all? -- Section 5.1 -- point: If present, it indicates that the GeoLocation represents a point. ... region: If present, it indicates that the GeoLocation represents a region. These make it sound as though these are boolean. It took me a bit to realize that the values of each of these is actually a structure. I think you mean this: NEW point: If present, it specifies the GeoLocation as a point. ... region: If present, it specifies the GeoLocation as a region. END -- Section 8.3 -- Please get rid of the MAY in the first sentence. If an appropriate category does not exist, it can use values in a different range. What is the antecedent for "it"? It looks like it's "an appropriate category", but that's clearly not right. Please fix. ======================= COMMENT -- minor ======================= A small point in the header: "iconectiv (formerly Telcordia Interconnection Solutions)" I think it's fine to put that in the "Authors' Addresses" section, but the header should just say "iconectiv". I realize that takes a little inconvenient massaging of the XML, and probably isn't worth the trouble for the I-D. Might just put that in an RFC Editor note.... General: I like that your citations include the document names, as well as the RFC numbers; thanks! It would be better if you put quotation marks around the document names, to distinguish them from being part of your text. -- Section 1 -- The document describes the use of HTTP/TLS as transport for the protocol. This hits what's rather a peeve of mine: HTTP is not a transport protocol; the transport protocol you're using is TCP. I'd be happier if you said something like this: OLD This specification defines an extensible protocol to obtain available spectrum from a geospatial database by a device with geo-location capability. NEW This specification defines an extensible protocol, built on top of HTTP and TLS, to obtain available spectrum from a geospatial database by a device with geo-location capability. END ...and then eliminate that last sentence. See also comments on Section 4 and Section 7. -- Section 2.2 -- I suggest this: OLD EIRP: Effective isotropically radiated power ETSI: European Telecommunications Standards Institute FCC: Federal Communications Commission NEW ETSI: European Telecommunications Standards Institute FCC: The U.S. Federal Communications Commission END ... and then in Section 9.2.2.7, spell out EIRP, as it's only used in that one place. -- Section 3 -- Little grammar nit: 1. The Master Device obtains (statically or dynamically) the URI for a Database appropriate for its location to send subsequent PAWS messages. Make it "location, to which to send". -- Section 3.1 -- These requirements may be complex and involve device behavior that are not easily parameterized. "Device behaviour" is singular, so "that is not", please. -- Section 4 -- Usage pet peeve: please change "comprise" to "compose", in the one place it's used. HTTPS Binding (Section 7) describes the use of HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and optional device authentication. Please use "transferring", instead of "transporting", to avoid calling HTTP a transport. -- Section 4.1.1 -- TBD Define message format You missed something here. Jus' sayin'. -- Section 4.4.1 -- Rulesets may mandate that it be the Device's current location or allow it to be an anticipated location. This is probably as good a place as any to ask this: is there any validation of the geo-location at all? If not, can such a mandate have any real teeth? What is this *really* saying? -- Section 4.4.5 -- The table says that "location" is required, but the text says it's not always required. The table should say "see description". -- Section 4.5 -- Typically, a Slave Device needs a Master Device to ask the Database on its behalf for available spectrum "Typically"? Isn't that the *definition* of a Slave Device? -- Section 5.5 -- All contact information MUST be expressed using the structure defined by the vCard Format Specification [RFC6350]. I think it's best to include both references here, like this: NEW All contact information MUST be expressed using the structure defined by the vCard Format Specification [RFC6350], encoded in JSON [RFC 7095]. END -- Section 5.7 -- The subsections explain what additional "data" field each error might use, but there are only sections for the ones that use the "data" field. One has to assume that the absence of a subsection means that the "data" field is not used for that error. It would be better to say that in the table. I suggest adding one sentence to each error description in the table except for -104, -105, and -201, as follows: "This error does not use any additional data." -- Section 5.11 -- The third table should be labelled "SpectrumProfilePoint". -- Section 5.12 -- The second table should be labelled "SpectrumProfilePoint". -- Section 5.17.1 -- When the error code is OUTSIDE_COVERAGE, the Database MAY include an ErrorData element within its as the "data" field You're missing the words "Error response" after "within its". -- Section 7 -- This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS [RFC2818] as the transport mechanism for the PAWS protocol. As I've noted earlier, please say "as the transfer mechanism". Also, it's really weird to describe the document in the same words as the document title. I suggest just deleting the document title in this case. This also applies to Section 10.1. -- Section 9.1.2 -- The first paragraph was obviously written before the ETSI info was added. Please adjust it accordingly. (I see that the Gen-ART review mentioned this too, and it will be fixed.) You might add instructions to the DE with respect to handling prefixes. Suppose, for example, I wanted to register something starting with "fcc". Or perhaps with the initials of an organization that hasn't yet registered anything, but reasonably might. -- Section 10.1 -- The doubled "HTTP over TLS" comment applies here. Also, it's not at all clear, when you say "these checks MAY be omitted," exactly what checks you're saying may be omitted. In particular, the validation path of the certificate must end in one of the client's trust anchors, even if that trust anchor is the Database certificate itself. A Master Device should allow for the fact that a Database can change its certificate authorities (CAs) over time. Just a question here: did the WG consider DANE at all? Another question: is it really necessary to cover this stuff here? Isn't it in 2818? -- Section 10.3 -- Using HTTP over TLS, messages protected by appropriate cypher suites are also protected from eavesdropping or otherwise access by unauthorized parties en route. What does "or otherwise access" mean? Apart from the grammar problem: it would be better to say something substantive here, rather than something vague. -- Section 11 -- I wouldn't usually comment on a "Contributors" section, but it seems odd to me to cite abandoned and long-expired drafts as references. It might be better just to include the draft names, without making them references. No? You're not actually suggesting that people read them, just thanking the authors for their contributions. ============================================== From nobody Tue Jul 15 09:10:50 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 E401A1B28C7 for ; Tue, 15 Jul 2014 09:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 7H6AU-D5--Js for ; Tue, 15 Jul 2014 09:10:31 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7831E1B287F for ; Tue, 15 Jul 2014 09:10:31 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hu12so5513469vcb.6 for ; Tue, 15 Jul 2014 09:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S2KRVAom/Tu6RajfmYsR9c8sJGlFcWuyVfnPUStETSk=; b=OvLfOp7/2LnIQCUp5dEkPlg0JAGLXnJoJPzfBGGmfcXkIplg69yHzUGUA+Hf+rmF47 hMol4+KFRnpsT+4p8pUgri6RO9Y1GFEnn5Gsj8wJy3pFl5xMANvw+9MJVGbwII6YWw7T swctm41/hwtT7UIEWCXr9FsgNGJ6wOMZVNZICBjvIiehnvwr+4hUZrO69kccJtYNNEvp TPKSDCea50/gcWaPRZOD3lSK3gO73Fwc0TUYz0FHADMXfuirRBZzSLYRAGMn3P9wCOLp 7AIeemYx0VhqS3mLGFLEJbwOJuwMU72BNKYVtKSnpy7BYRmqvxrK+PM0OFWBEsClNSdT dYZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=S2KRVAom/Tu6RajfmYsR9c8sJGlFcWuyVfnPUStETSk=; b=glIliiwMuJ9t59Ego4LY+ho1MKXJt59+WmpJrSmOLo0zciEpPeCuQVCQ41XQnJnUZp g09u8AeKaIF2xefwoRk7UFu5SVtpRqaCYf5Yn8x/D+UjYDkILn95Y4/tf6quJ78e1yBm QIifK0fOaho12URFUBqgKirjVlDDEuLRpveollV3q4oavAOAnypICBLxBf6VK5UBUaBl CuohattoyWxPMUo15wWht+2taQgEofoDAq3irpyYOxQ2mV7O/dx7U9w1E7vbZH9g4/sa zwd4oZ507KmDmqG/6/B9abFZ8pdoo5NP5PTF1Ls14/RFUULRO0YfW00mJhaeAw8oTZi5 xAzQ== X-Gm-Message-State: ALoCoQnpiTaIladHLfsZB5fClSfdOYVkd6QDR1xmWNbBLb67+dvs4AT4iR0WwiwsXQHLITPJTQVg MIME-Version: 1.0 X-Received: by 10.52.27.80 with SMTP id r16mr1206355vdg.91.1405440630487; Tue, 15 Jul 2014 09:10:30 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Tue, 15 Jul 2014 09:10:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jul 2014 09:10:30 -0700 Message-ID: From: Vincent Chen To: Barry Leiba Content-Type: multipart/alternative; boundary=20cf307cfd0c88a0c904fe3da58d Archived-At: http://mailarchive.ietf.org/arch/msg/paws/KXF0jLJOizBwUt1AGVh8Sop74OY Cc: "paws@ietf.org" Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APP AD) 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: Tue, 15 Jul 2014 16:10:44 -0000 --20cf307cfd0c88a0c904fe3da58d Content-Type: text/plain; charset=UTF-8 Thanks Barry for the detailed comments. It looks like some of your comments overlap two other comment sets in the works, for which I've responded to the list with proposed changes, but are awaiting responses. Should I try to fold all 3 sets of changes into a new 13 draft? or would it be easier for you if I made 2 separate passes? -vince On Mon, Jul 14, 2014 at 12:31 PM, Barry Leiba wrote: > Hey, PAWS folk. > As Pete has put the subject document on the 7 August telechat agenda, > though he still has it in "Waiting for AD Go Ahead" state, I decided > to review it now, rather than wait. I've found quite a list of > issues, from large to small, which I've sorted below into three > categories: > > "DISCUSS" are those that I would put in a DISCUSS ballot during IESG > Evaluation. I think they're errors in the document that need to be > corrected, or else things that need to be discussed and resolved. > > The most important in this category, and the only one I think will be > difficult to resolve, is how to specify the JSON payload formally. > > "COMMENT -- substantive" are those that I would put in the > non-blocking comments, but that I think are important to deal with, > and that I'd hope we'd have a discussion about if the authors think a > discussion is necessary. > > "COMMENT -- minor" are minor editorial issues that I think would be > better corrected, but that I'm not going to grump about further. > Discussion is always welcome, but should be pretty much unnecessary > for these. > > I hope it's useful to get these comments earlier, rather than later. > And, so, here they are, below. I've offered suggested text where I > could, and I hope that helps as well. > > Barry > > ======================= DISCUSS ======================= > > -- Section 4 -- > > o Device Registration (Section 4.3) MAY be used by the Master Device > and MAY be implemented by the Database, either as a separate > component or as part of the Available Spectrum Query (Section 4.4) > component. > > I don't think the first MAY is correct. If the database requires > registration, it is *not* optional for the Master Device to use it. I > think this needs some rework. The same is true with "Device > Validation". > > This list also mixes "used", "supported", and "implemented", without > making all the issues clear. If something MAY be used, does that mean > it's optional to implement? If it MUST be supported, what does that > say about its use? And what's the difference between "supported" and > "implemented"? > > I strongly suggest that, if you're going to say that, you make it all > clear, as to both implementation/support and use. The note after the > list that says that some things are obvious... nah, one of it is > obvious. > > -- Section 4.1 -- > > A Database MAY indicate that its URI will be changing by including > the URI of one or more alternate databases (See DbUpdateSpec > (Section 5.7)) in its responses to a Device. Before a Database > ceases operation, for example, it MUST include DbUpdateSpec in its > responses to notify Devices. > > I don't understand how the MAY and MUST are consistent with each > other. Can you explain or fix it? > > -- Section 4.1.1 -- > > 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 > > Here's another 2119 conflict. It doesn't make sense to have a MUST > for the time period if doing it at all is a SHOULD. Please sort this > one out as well. > > -- Section 4.2 > > A Master Device SHOULD use the initialization procedure to exchange > capability information with the Database whenever the Master Device > powers up or initiates communication with the Database. > > But in Section 4 you said "Initialization (Section 4.2) MAY be used by > the Master Device," and now you're saying "SHOULD"? You see why I'm > on about the 2119 inconsistencies? > > When a Master Device is > configured manually with these parameterized-rule values, it does not > need to use the initialization procedure. > > Dos that mean that when it's not configured with them, it *does* need > to? In other words, is this really a "MUST use initialization unless > it's pre-configured with the values" thing? > > -- Section 4.2.1 -- > > deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is > REQUIRED. If the Database does not support the device or any of > the rulesets specified in the device descriptor, it MUST return an > error with the UNSUPPORTED (Table 1) code in the error response. > If the device descriptor does not contain any ruleset IDs, the > Database SHOULD return a list of RulesetInfo (Section 5.6) > parameters for each ruleset it supports at the specified location. > > What this says to me is that the Master Device uses an empty list of > rulesets to query the list of supported rulesets. So: how does this > work if the Database does not return its list of rulesets? > Presumably, the Master Device did this because it needs the list, and > then it didn't get it. What does it do now? > > Also, this is worded a bit confusingly. The list is REQUIRED, so it's > not true that the Database SHOULD return a list. What you mean to > tell us is what the Database SHOULD include in the list. I think it's > really awkward to try to say that here in the query, rather than in > the next section in the response. > > Try this: > > OLD (Section 4.2.1) > deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is > REQUIRED. If the Database does not support the device or any of > the rulesets specified in the device descriptor, it MUST return an > error with the UNSUPPORTED (Table 1) code in the error response. > If the device descriptor does not contain any ruleset IDs, the > Database SHOULD return a list of RulesetInfo (Section 5.6) > parameters for each ruleset it supports at the specified location. > NEW > deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is > REQUIRED. If the device descriptor does not contain any ruleset > IDs, the Master Device is asking the Database to return a list of > RulesetInfo (Section 5.6) parameters for each ruleset it supports > at the specified location. > END > > OLD (Section 4.2.2) > rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be > included in the response. Each RulesetInfo parameter corresponds > to a ruleset supported by the Database and is applicable to the > location specified in the INIT_REQ (Section 4.2.1) message. If > the Device included a list of ruleset IDs in the DeviceDescriptor > parameter of its INIT_REQ message, each RulesetInfo parameter in > the response MUST match one of the specified ruleset IDs. > NEW > rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be > included in the response. Each RulesetInfo parameter corresponds > to a ruleset supported by the Database and is applicable to the > location specified in the INIT_REQ (Section 4.2.1) message. > > If the Device included a list of ruleset IDs in the DeviceDescriptor > parameter of its INIT_REQ message, each RulesetInfo parameter in > the response MUST match one of the specified ruleset IDs. > > If the DeviceDescriptor did not contain any ruleset IDs, the > Database SHOULD include in the list the RulesetInfo parameters for > each ruleset it supports at the specified location. > > If the Database does not support the device or any of the rulesets > specified in the DeviceDescriptor, it MUST instead return an > error with the UNSUPPORTED (Table 1) code in the error response. > END > > -- Section 4.3.2 -- > > If the Database accepts the > registration for none of the rulesets it supports, the Database MUST > return the NOT_REGISTERED error (See Error Codes (Section 5.17)). > > I can't follow this sentence at all. Do you mean, "If the Database > does not accept the registration for any of the rulesets" ? Or do you > mean something else? Can you re-word this, please? > > -- Section 5.8 -- > > name: The display name for a database. It MAY contain UTF-8. > > What about all the other strings whose content format is unspecified? > Are they allowed to contain UTF-8? If not, what *do* they contain? > > I see that the Gen-ART review mentioned this also, and the response > will be to specify that all strings are encoded in UTF-8. Good. > > -- Section 6 -- > How is the reference to JSON Schema [I-D.zyp-json-schema] not > normative, when the 6.x subsections quite depend upon the > understanding of the schema format that it describes? > > I see that the Gen-ART review mentioned this also, but the response is > quite troubling. No, the mechanism you're using is not sufficiently > self explanatory. I understand it -- I do -- but I had to figure it > out (I decided not to go look at the Zyp draft), and we can't assume > that arbitrary implementors will get it right. We need a well defined > way to explain how JSON objects are constructed. And, unfortunately, > the JSON working group chose *not* to take on a work item for this > (which I was pushing for). > > We have at least three proposals (apart from Zyp, there's Newton > (draft-newton-json-content-rules), and there's the mechanism that I > proposed, which is used in Section 6.2 of RFC 7071), but nothing > that's being taken forward as a standard yet. > > -- Section 6.6.2 -- > The schema is missing the optional databaseChange property. > > -- Section 6.7.1 -- > The schema is missing the optional masterDeviceDesc property. > > -- Section 6.8.11 -- > The schema says that both properties are optional, but Section 5.14 > says that they're both required. > > -- Section 6.8.13 -- > The schema says that rulesetInfo is optional, but Section 5.9 says > that it's required. > > -- Section 7 -- > > The Database MAY redirect a PAWS request by returning a HTTP 3xx > response (as defined by HTTP/1.1 [RFC2616]). > ... > Since the Device may communicate > with a Database (which it authenticated) without user interaction, > when the response code is 301 (Moved Permanently), the Device MAY > redirect without asking a user for confirmation (note that this > represents an exception to the HTTP/1.1 [RFC2616] requirements for > HTTP POST methods). > > The references to RFC2616 need to change to RFC7231, now that 2616 is > obsolete. > I see that the Gen-ART review mentioned this also, and you plan to > change the reference. This should help you get that right: > > The change to 7231 also means that the note about the second citation > can change. 2616 said this about redirecting a POST: > > --- RFC 2616 --- > If the 301 status code is received in response to a request other > than GET or HEAD, the user agent MUST NOT automatically redirect the > request unless it can be confirmed by the user, since this might > change the conditions under which the request was issued. > ---------------- > > That advice has changed in 7231: > > --- RFC 7231 --- > Automatic redirection needs to done with > care for methods not known to be safe, as defined in Section 4.2.1, > since the user might not wish to redirect an unsafe request. > ---------------- > > In my view, that means that the parenthesized note in the quote above > can be removed from this document. I also suggest using a section > number in the citation, as you're citing a big document. So... > > OLD > The Database MAY redirect a PAWS request by returning a HTTP 3xx > response (as defined by HTTP/1.1 [RFC2616]). > NEW > The Database MAY redirect a PAWS request by returning a HTTP 3xx > response (as defined by HTTP/1.1 Semantics and Content [RFC7231], > Section 6.4). > END > > OLD > Since the Device may communicate > with a Database (which it authenticated) without user interaction, > when the response code is 301 (Moved Permanently), the Device MAY > redirect without asking a user for confirmation (note that this > represents an exception to the HTTP/1.1 [RFC2616] requirements for > HTTP POST methods). > NEW > Since the Device may communicate > with a Database (which it authenticated) without user interaction, > when the response code is 301 (Moved Permanently), the Device MAY > redirect without asking a user for confirmation, even though it > is in response to an HTTP POST request. > END > > -- Section 8.2 -- > > The parameter name SHOULD be lowerCamelCase. > > Why "SHOULD"? How does it affect interoperability? Wouldn't > "Parameter names use lowerCamelCase by convention." work fine? > > -- Section 9 -- > First, and most importantly, the IANA review interpreted your text to > say that the registration policies are Expert Review; I interpret your > text to say that they're Specification Required. Yet Vince replied to > the IANA review without correcting that. Which policy do you intend? > If it is Specification Required, you need to clear that up with IANA. > Or just deal with my other comments in this section, and that might > happen anyway. > > The text in this section seems to be commonly copied from somewhere. > Perhaps you could tell me whence you copied it, so we can make an > effort to stop people from doing that. > > The first paragraph is entirely unnecessary: please just remove it. > > The second paragraph and the list is fine, and the third is mostly OK, > except for the URI. You'll need to ask IANA how they want to receive > requests (by email or through a web URI), and specify that in > paragraph 3 instead of what's there now. > > The fourth paragraph really needs to be entirely re-thought: it is not > how IANA does expert review in the first place, and we shouldn't be > telling IANA how to run their process in the second place. > > The fourth paragraph should say that all registries use the > Specification Required policy [RFC5226], with a Designated Expert > appointed by the IESG. It should note that instructions to the DE as > to what she should look for and consider in evaluating a request are > given below in the descriptions of each registry. It should say that > the DE should take advice from the community through the designated > mailing list, and that is why the registrant should post to the > mailing list before formally requesting the registration from IANA. > All the rest of the mechanics are part of IANA's process, and should > not be specified here. > > One question: does it make sense for the review list to be a separate > list, or couldn't the WG mailing list be reused for that purpose? > > > ======================= COMMENT -- substantive ======================= > > General: > You appear to sometimes use "parameter" to refer to a structure (such > as GeoLocation) and also the fields within the parameter (see Section > 5.1, for example). I find this confusing, and suggest that you do not > use the same term for both. > > -- Section 3 -- > In step 4, should this not say a word or two about what message it > responds with? Might it respond, "To be, or not to be; that is the > question?" Or is there an expected sort of response? > > Step 5 is the first mention of registration. A reference to where > that process is explained would be useful here (as this step doesn't > seem to fit into the flow). > > In step 7, this is the first mention of a Slave Device, so referring > to "the Slave Device" doesn't make sense. Maybe you want something > like, "If a Slave Device has made a request to the Master Device, the > Master Device may verify..." ? > > It's not clear how step 7 relates to steps 6 and 8. > > In step 10, might it also send an error, refusal, or whatever? Or are > those all considered acknowledgment messages? > > Hm, it seems that steps 5 and 7 are actually explained in the > paragraph after the numbered steps. So do they really belong in the > numbered steps at all? > > -- Section 5.1 -- > > point: If present, it indicates that the GeoLocation represents a > point. > ... > region: If present, it indicates that the GeoLocation represents a > region. > > These make it sound as though these are boolean. It took me a bit to > realize that the values of each of these is actually a structure. I > think you mean this: > > NEW > point: If present, it specifies the GeoLocation as a point. > ... > region: If present, it specifies the GeoLocation as a region. > END > > -- Section 8.3 -- > Please get rid of the MAY in the first sentence. > > If an > appropriate category does not exist, it can use values in a different > range. > > What is the antecedent for "it"? It looks like it's "an appropriate > category", but that's clearly not right. Please fix. > > > ======================= COMMENT -- minor ======================= > > A small point in the header: > "iconectiv (formerly Telcordia Interconnection Solutions)" > I think it's fine to put that in the "Authors' Addresses" section, but > the header should just say "iconectiv". I realize that takes a little > inconvenient massaging of the XML, and probably isn't worth the > trouble for the I-D. Might just put that in an RFC Editor note.... > > General: > I like that your citations include the document names, as well as the > RFC numbers; thanks! It would be better if you put quotation marks > around the document names, to distinguish them from being part of your > text. > > -- Section 1 -- > > The document describes the use of HTTP/TLS as > transport for the protocol. > > This hits what's rather a peeve of mine: HTTP is not a transport > protocol; the transport protocol you're using is TCP. > > I'd be happier if you said something like this: > > OLD > This specification defines an extensible protocol to obtain available > spectrum from a geospatial database by a device with geo-location > capability. > NEW > This specification defines an extensible protocol, built on top of > HTTP and TLS, to obtain available spectrum from a geospatial database > by a device with geo-location capability. > END > > ...and then eliminate that last sentence. See also comments on > Section 4 and Section 7. > > -- Section 2.2 -- > > I suggest this: > > OLD > EIRP: Effective isotropically radiated power > ETSI: European Telecommunications Standards Institute > FCC: Federal Communications Commission > NEW > ETSI: European Telecommunications Standards Institute > > FCC: The U.S. Federal Communications Commission > END > > ... and then in Section 9.2.2.7, spell out EIRP, as it's only used in > that one place. > > -- Section 3 -- > Little grammar nit: > 1. The Master Device obtains (statically or dynamically) the URI > for a Database appropriate for its location to send subsequent > PAWS messages. > > Make it "location, to which to send". > > -- Section 3.1 -- > > These > requirements may be complex and involve device behavior that are not > easily parameterized. > > "Device behaviour" is singular, so "that is not", please. > > -- Section 4 -- > > Usage pet peeve: please change "comprise" to "compose", in the one > place it's used. > > HTTPS Binding (Section 7) describes the use of > HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and > optional device authentication. > > Please use "transferring", instead of "transporting", to avoid calling > HTTP a transport. > > -- Section 4.1.1 -- > > TBD Define message format > > You missed something here. Jus' sayin'. > > -- Section 4.4.1 -- > > Rulesets may mandate that it be the Device's > current location or allow it to be an anticipated location. > > This is probably as good a place as any to ask this: is there any > validation of the geo-location at all? If not, can such a mandate > have any real teeth? What is this *really* saying? > > -- Section 4.4.5 -- > The table says that "location" is required, but the text says it's not > always required. The table should say "see description". > > -- Section 4.5 -- > > Typically, a Slave Device needs a Master Device to ask the Database > on its behalf for available spectrum > > "Typically"? Isn't that the *definition* of a Slave Device? > > -- Section 5.5 -- > > All contact information MUST be expressed using the structure defined > by the vCard Format Specification [RFC6350]. > > I think it's best to include both references here, like this: > > NEW > All contact information MUST be expressed using the structure defined > by the vCard Format Specification [RFC6350], encoded in JSON [RFC 7095]. > END > > -- Section 5.7 -- > The subsections explain what additional "data" field each error might > use, but there are only sections for the ones that use the "data" > field. One has to assume that the absence of a subsection means that > the "data" field is not used for that error. It would be better to > say that in the table. I suggest adding one sentence to each error > description in the table except for -104, -105, and -201, as follows: > "This error does not use any additional data." > > -- Section 5.11 -- > The third table should be labelled "SpectrumProfilePoint". > > -- Section 5.12 -- > The second table should be labelled "SpectrumProfilePoint". > > -- Section 5.17.1 -- > > When the error code is OUTSIDE_COVERAGE, the Database MAY include an > ErrorData element within its as the "data" field > > You're missing the words "Error response" after "within its". > > -- Section 7 -- > > This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS > [RFC2818] as the transport mechanism for the PAWS protocol. > > As I've noted earlier, please say "as the transfer mechanism". Also, > it's really weird to describe the document in the same words as the > document title. I suggest just deleting the document title in this > case. This also applies to Section 10.1. > > -- Section 9.1.2 -- > The first paragraph was obviously written before the ETSI info was > added. Please adjust it accordingly. (I see that the Gen-ART review > mentioned this too, and it will be fixed.) > > You might add instructions to the DE with respect to handling > prefixes. Suppose, for example, I wanted to register something > starting with "fcc". Or perhaps with the initials of an organization > that hasn't yet registered anything, but reasonably might. > > -- Section 10.1 -- > The doubled "HTTP over TLS" comment applies here. Also, it's not at > all clear, when you say "these checks MAY be omitted," exactly what > checks you're saying may be omitted. > > In particular, the > validation path of the certificate must end in one of the client's > trust anchors, even if that trust anchor is the Database certificate > itself. A Master Device should allow for the fact that a Database > can change its certificate authorities (CAs) over time. > > Just a question here: did the WG consider DANE at all? > > Another question: is it really necessary to cover this stuff here? > Isn't it in 2818? > > -- Section 10.3 -- > > Using HTTP over TLS, messages protected by appropriate cypher suites > are also protected from eavesdropping or otherwise access by > unauthorized parties en route. > > What does "or otherwise access" mean? Apart from the grammar problem: > it would be better to say something substantive here, rather than > something vague. > > -- Section 11 -- > I wouldn't usually comment on a "Contributors" section, but it seems > odd to me to cite abandoned and long-expired drafts as references. It > might be better just to include the draft names, without making them > references. No? You're not actually suggesting that people read > them, just thanking the authors for their contributions. > > ============================================== > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --20cf307cfd0c88a0c904fe3da58d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Barry for the detailed comments.

It looks like some of your comments overlap two other comment sets in the = works,
for which I've responded to the list with proposed cha= nges, but are awaiting responses.

Should I try to fold all 3 sets of changes into a new 1= 3 draft? or would it be easier for you if I made 2 separate passes?

-vince


On Mon, Jul 14, 2014 at 12:31 PM, Barry Leiba <barryleiba@computer.o= rg> wrote:
Hey, PAWS folk.
As Pete has put the subject document on the 7 August telechat agenda,
though he still has it in "Waiting for AD Go Ahead" state, I deci= ded
to review it now, rather than wait. =C2=A0I've found quite a list of issues, from large to small, which I've sorted below into three
categories:

"DISCUSS" are those that I would put in a DISCUSS ballot during I= ESG
Evaluation. =C2=A0I think they're errors in the document that need to b= e
corrected, or else things that need to be discussed and resolved.

The most important in this category, and the only one I think will be
difficult to resolve, is how to specify the JSON payload formally.

"COMMENT -- substantive" are those that I would put in the
non-blocking comments, but that I think are important to deal with,
and that I'd hope we'd have a discussion about if the authors think= a
discussion is necessary.

"COMMENT -- minor" are minor editorial issues that I think would = be
better corrected, but that I'm not going to grump about further.
Discussion is always welcome, but should be pretty much unnecessary
for these.

I hope it's useful to get these comments earlier, rather than later. And, so, here they are, below. =C2=A0I've offered suggested text where = I
could, and I hope that helps as well.

Barry

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DISCU= SS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-- Section 4 --

=C2=A0 =C2=A0o =C2=A0Device Registration (Section 4.3) MAY be used by the M= aster Device
=C2=A0 =C2=A0 =C2=A0 and MAY be implemented by the Database, either as a se= parate
=C2=A0 =C2=A0 =C2=A0 component or as part of the Available Spectrum Query (= Section 4.4)
=C2=A0 =C2=A0 =C2=A0 component.

I don't think the first MAY is correct. =C2=A0If the database requires<= br> registration, it is *not* optional for the Master Device to use it. =C2=A0I=
think this needs some rework. =C2=A0The same is true with "Device
Validation".

This list also mixes "used", "supported", and "imp= lemented", without
making all the issues clear. =C2=A0If something MAY be used, does that mean=
it's optional to implement? =C2=A0If it MUST be supported, what does th= at
say about its use? =C2=A0And what's the difference between "suppor= ted" and
"implemented"?

I strongly suggest that, if you're going to say that, you make it all clear, as to both implementation/support and use. =C2=A0The note after the<= br> list that says that some things are obvious... nah, one of it is
obvious.

-- Section 4.1 --

=C2=A0 =C2=A0A Database MAY indicate that its URI will be changing by inclu= ding
=C2=A0 =C2=A0the URI of one or more alternate databases (See DbUpdateSpec =C2=A0 =C2=A0(Section 5.7)) in its responses to a Device. =C2=A0Before a Da= tabase
=C2=A0 =C2=A0ceases operation, for example, it MUST include DbUpdateSpec in= its
=C2=A0 =C2=A0responses to notify Devices.

I don't understand how the MAY and MUST are consistent with each
other. =C2=A0Can you explain or fix it?

-- Section 4.1.1 --

=C2=A0 =C2=A0When a Listing Server is used, the
=C2=A0 =C2=A0Device can save the database list and SHOULD contact the Datab= ase
=C2=A0 =C2=A0Listing Server periodically to update its list. =C2=A0The time= between
=C2=A0 =C2=A0such updates MUST be no longer than one week

Here's another 2119 conflict. =C2=A0It doesn't make sense to have a= MUST
for the time period if doing it at all is a SHOULD. =C2=A0Please sort this<= br> one out as well.

-- Section 4.2

=C2=A0 =C2=A0A Master Device SHOULD use the initialization procedure to exc= hange
=C2=A0 =C2=A0capability information with the Database whenever the Master D= evice
=C2=A0 =C2=A0powers up or initiates communication with the Database.

But in Section 4 you said "Initialization (Section 4.2) MAY be used by=
the Master Device," and now you're saying "SHOULD"? =C2= =A0You see why I'm
on about the 2119 inconsistencies?

=C2=A0 =C2=A0When a Master Device is
=C2=A0 =C2=A0configured manually with these parameterized-rule values, it d= oes not
=C2=A0 =C2=A0need to use the initialization procedure.

Dos that mean that when it's not configured with them, it *does* need to? =C2=A0In other words, is this really a "MUST use initialization un= less
it's pre-configured with the values" thing?

-- Section 4.2.1 --

=C2=A0 =C2=A0deviceDesc: =C2=A0The DeviceDescriptor (Section 5.2) for the D= evice is
=C2=A0 =C2=A0 =C2=A0 REQUIRED. =C2=A0If the Database does not support the d= evice or any of
=C2=A0 =C2=A0 =C2=A0 the rulesets specified in the device descriptor, it MU= ST return an
=C2=A0 =C2=A0 =C2=A0 error with the UNSUPPORTED (Table 1) code in the error= response.
=C2=A0 =C2=A0 =C2=A0 If the device descriptor does not contain any ruleset = IDs, the
=C2=A0 =C2=A0 =C2=A0 Database SHOULD return a list of RulesetInfo (Section = 5.6)
=C2=A0 =C2=A0 =C2=A0 parameters for each ruleset it supports at the specifi= ed location.

What this says to me is that the Master Device uses an empty list of
rulesets to query the list of supported rulesets. =C2=A0So: how does this work if the Database does not return its list of rulesets?
Presumably, the Master Device did this because it needs the list, and
then it didn't get it. =C2=A0What does it do now?

Also, this is worded a bit confusingly. =C2=A0The list is REQUIRED, so it&#= 39;s
not true that the Database SHOULD return a list. =C2=A0What you mean to
tell us is what the Database SHOULD include in the list. =C2=A0I think it&#= 39;s
really awkward to try to say that here in the query, rather than in
the next section in the response.

Try this:

OLD (Section 4.2.1)
=C2=A0 =C2=A0deviceDesc: =C2=A0The DeviceDescriptor (Section 5.2) for the D= evice is
=C2=A0 =C2=A0 =C2=A0 REQUIRED. =C2=A0If the Database does not support the d= evice or any of
=C2=A0 =C2=A0 =C2=A0 the rulesets specified in the device descriptor, it MU= ST return an
=C2=A0 =C2=A0 =C2=A0 error with the UNSUPPORTED (Table 1) code in the error= response.
=C2=A0 =C2=A0 =C2=A0 If the device descriptor does not contain any ruleset = IDs, the
=C2=A0 =C2=A0 =C2=A0 Database SHOULD return a list of RulesetInfo (Section = 5.6)
=C2=A0 =C2=A0 =C2=A0 parameters for each ruleset it supports at the specifi= ed location.
NEW
=C2=A0 =C2=A0deviceDesc: =C2=A0The DeviceDescriptor (Section 5.2) for the D= evice is
=C2=A0 =C2=A0 =C2=A0 REQUIRED. =C2=A0If the device descriptor does not cont= ain any ruleset
=C2=A0 =C2=A0 =C2=A0 IDs, the Master Device is asking the Database to retur= n a list of
=C2=A0 =C2=A0 =C2=A0 RulesetInfo (Section 5.6) parameters for each ruleset = it supports
=C2=A0 =C2=A0 =C2=A0 at the specified location.
END

OLD (Section 4.2.2)
=C2=A0 =C2=A0rulesetInfos: =C2=A0A list of RulesetInfo (Section 5.6) parame= ters MUST be
=C2=A0 =C2=A0 =C2=A0 included in the response. =C2=A0Each RulesetInfo param= eter corresponds
=C2=A0 =C2=A0 =C2=A0 to a ruleset supported by the Database and is applicab= le to the
=C2=A0 =C2=A0 =C2=A0 location specified in the INIT_REQ (Section 4.2.1) mes= sage. =C2=A0If
=C2=A0 =C2=A0 =C2=A0 the Device included a list of ruleset IDs in the Devic= eDescriptor
=C2=A0 =C2=A0 =C2=A0 parameter of its INIT_REQ message, each RulesetInfo pa= rameter in
=C2=A0 =C2=A0 =C2=A0 the response MUST match one of the specified ruleset I= Ds.
NEW
=C2=A0 =C2=A0rulesetInfos: =C2=A0A list of RulesetInfo (Section 5.6) parame= ters MUST be
=C2=A0 =C2=A0 =C2=A0 included in the response. =C2=A0Each RulesetInfo param= eter corresponds
=C2=A0 =C2=A0 =C2=A0 to a ruleset supported by the Database and is applicab= le to the
=C2=A0 =C2=A0 =C2=A0 location specified in the INIT_REQ (Section 4.2.1) mes= sage.

=C2=A0 =C2=A0 =C2=A0 If the Device included a list of ruleset IDs in the De= viceDescriptor
=C2=A0 =C2=A0 =C2=A0 parameter of its INIT_REQ message, each RulesetInfo pa= rameter in
=C2=A0 =C2=A0 =C2=A0 the response MUST match one of the specified ruleset I= Ds.

=C2=A0 =C2=A0 =C2=A0 If the DeviceDescriptor did not contain any ruleset ID= s, the
=C2=A0 =C2=A0 =C2=A0 Database SHOULD include in the list the RulesetInfo pa= rameters for
=C2=A0 =C2=A0 =C2=A0 each ruleset it supports at the specified location.
=C2=A0 =C2=A0 =C2=A0 If the Database does not support the device or any of = the rulesets
=C2=A0 =C2=A0 =C2=A0 specified in the DeviceDescriptor, it MUST instead ret= urn an
=C2=A0 =C2=A0 =C2=A0 error with the UNSUPPORTED (Table 1) code in the error= response.
END

-- Section 4.3.2 --

=C2=A0 =C2=A0If the Database accepts the
=C2=A0 =C2=A0registration for none of the rulesets it supports, the Databas= e MUST
=C2=A0 =C2=A0return the NOT_REGISTERED error (See Error Codes (Section 5.17= )).

I can't follow this sentence at all. =C2=A0Do you mean, "If the Da= tabase
does not accept the registration for any of the rulesets" ? =C2=A0Or d= o you
mean something else? =C2=A0Can you re-word this, please?

-- Section 5.8 --

=C2=A0 =C2=A0name: =C2=A0The display name for a database. =C2=A0It MAY cont= ain UTF-8.

What about all the other strings whose content format is unspecified?
Are they allowed to contain UTF-8? =C2=A0If not, what *do* they contain?
I see that the Gen-ART review mentioned this also, and the response
will be to specify that all strings are encoded in UTF-8. =C2=A0Good.

-- Section 6 --
How is the reference to JSON Schema [I-D.zyp-json-schema] not
normative, when the 6.x subsections quite depend upon the
understanding of the schema format that it describes?

I see that the Gen-ART review mentioned this also, but the response is
quite troubling. =C2=A0No, the mechanism you're using is not sufficient= ly
self explanatory. =C2=A0I understand it -- I do -- but I had to figure it out (I decided not to go look at the Zyp draft), and we can't assume that arbitrary implementors will get it right. =C2=A0We need a well defined=
way to explain how JSON objects are constructed. =C2=A0And, unfortunately,<= br> the JSON working group chose *not* to take on a work item for this
(which I was pushing for).

We have at least three proposals (apart from Zyp, there's Newton
(draft-newton-json-content-rules), and there's the mechanism that I
proposed, which is used in Section 6.2 of RFC 7071), but nothing
that's being taken forward as a standard yet.

-- Section 6.6.2 --
The schema is missing the optional databaseChange property.

-- Section 6.7.1 --
The schema is missing the optional masterDeviceDesc property.

-- Section 6.8.11 --
The schema says that both properties are optional, but Section 5.14
says that they're both required.

-- Section 6.8.13 --
The schema says that rulesetInfo is optional, but Section 5.9 says
that it's required.

-- Section 7 --

=C2=A0 =C2=A0The Database MAY redirect a PAWS request by returning a HTTP 3= xx
=C2=A0 =C2=A0response (as defined by HTTP/1.1 [RFC2616]).
...
=C2=A0 =C2=A0Since the Device may communicate
=C2=A0 =C2=A0with a Database (which it authenticated) without user interact= ion,
=C2=A0 =C2=A0when the response code is 301 (Moved Permanently), the Device = MAY
=C2=A0 =C2=A0redirect without asking a user for confirmation (note that thi= s
=C2=A0 =C2=A0represents an exception to the HTTP/1.1 [RFC2616] requirements= for
=C2=A0 =C2=A0HTTP POST methods).

The references to RFC2616 need to change to RFC7231, now that 2616 is obsol= ete.
I see that the Gen-ART review mentioned this also, and you plan to
change the reference. =C2=A0This should help you get that right:

The change to 7231 also means that the note about the second citation
can change. =C2=A02616 said this about redirecting a POST:

--- RFC 2616 ---
=C2=A0 =C2=A0If the 301 status code is received in response to a request ot= her
=C2=A0 =C2=A0than GET or HEAD, the user agent MUST NOT automatically redire= ct the
=C2=A0 =C2=A0request unless it can be confirmed by the user, since this mig= ht
=C2=A0 =C2=A0change the conditions under which the request was issued.
----------------

That advice has changed in 7231:

--- RFC 7231 ---
=C2=A0 =C2=A0Automatic redirection needs to done with
=C2=A0 =C2=A0care for methods not known to be safe, as defined in Section 4= .2.1,
=C2=A0 =C2=A0since the user might not wish to redirect an unsafe request. ----------------

In my view, that means that the parenthesized note in the quote above
can be removed from this document. =C2=A0I also suggest using a section
number in the citation, as you're citing a big document. =C2=A0So...
OLD
=C2=A0 =C2=A0The Database MAY redirect a PAWS request by returning a HTTP 3= xx
=C2=A0 =C2=A0response (as defined by HTTP/1.1 [RFC2616]).
NEW
=C2=A0 =C2=A0The Database MAY redirect a PAWS request by returning a HTTP 3= xx
=C2=A0 =C2=A0response (as defined by HTTP/1.1 Semantics and Content [RFC723= 1],
=C2=A0 =C2=A0Section 6.4).
END

OLD
=C2=A0 =C2=A0Since the Device may communicate
=C2=A0 =C2=A0with a Database (which it authenticated) without user interact= ion,
=C2=A0 =C2=A0when the response code is 301 (Moved Permanently), the Device = MAY
=C2=A0 =C2=A0redirect without asking a user for confirmation (note that thi= s
=C2=A0 =C2=A0represents an exception to the HTTP/1.1 [RFC2616] requirements= for
=C2=A0 =C2=A0HTTP POST methods).
NEW
=C2=A0 =C2=A0Since the Device may communicate
=C2=A0 =C2=A0with a Database (which it authenticated) without user interact= ion,
=C2=A0 =C2=A0when the response code is 301 (Moved Permanently), the Device = MAY
=C2=A0 =C2=A0redirect without asking a user for confirmation, even though i= t
=C2=A0 =C2=A0is in response to an HTTP POST request.
END

-- Section 8.2 --

=C2=A0 =C2=A0The parameter name SHOULD be lowerCamelCase.

Why "SHOULD"? =C2=A0 How does it affect interoperability? =C2=A0W= ouldn't
"Parameter names use lowerCamelCase by convention." work fine?
-- Section 9 --
First, and most importantly, the IANA review interpreted your text to
say that the registration policies are Expert Review; I interpret your
text to say that they're Specification Required. =C2=A0Yet Vince replie= d to
the IANA review without correcting that. =C2=A0Which policy do you intend?<= br> If it is Specification Required, you need to clear that up with IANA.
Or just deal with my other comments in this section, and that might
happen anyway.

The text in this section seems to be commonly copied from somewhere.
Perhaps you could tell me whence you copied it, so we can make an
effort to stop people from doing that.

The first paragraph is entirely unnecessary: please just remove it.

The second paragraph and the list is fine, and the third is mostly OK,
except for the URI. =C2=A0You'll need to ask IANA how they want to rece= ive
requests (by email or through a web URI), and specify that in
paragraph 3 instead of what's there now.

The fourth paragraph really needs to be entirely re-thought: it is not
how IANA does expert review in the first place, and we shouldn't be
telling IANA how to run their process in the second place.

The fourth paragraph should say that all registries use the
Specification Required policy [RFC5226], with a Designated Expert
appointed by the IESG. =C2=A0It should note that instructions to the DE as<= br> to what she should look for and consider in evaluating a request are
given below in the descriptions of each registry. =C2=A0It should say that<= br> the DE should take advice from the community through the designated
mailing list, and that is why the registrant should post to the
mailing list before formally requesting the registration from IANA.
All the rest of the mechanics are part of IANA's process, and should not be specified here.

One question: does it make sense for the review list to be a separate
list, or couldn't the WG mailing list be reused for that purpose?


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D COMME= NT -- substantive =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

General:
You appear to sometimes use "parameter" to refer to a structure (= such
as GeoLocation) and also the fields within the parameter (see Section
5.1, for example). =C2=A0I find this confusing, and suggest that you do not=
use the same term for both.

-- Section 3 --
In step 4, should this not say a word or two about what message it
responds with? =C2=A0Might it respond, "To be, or not to be; that is t= he
question?" =C2=A0Or is there an expected sort of response?

Step 5 is the first mention of registration. =C2=A0A reference to where
that process is explained would be useful here (as this step doesn't seem to fit into the flow).

In step 7, this is the first mention of a Slave Device, so referring
to "the Slave Device" doesn't make sense. =C2=A0Maybe you wan= t something
like, "If a Slave Device has made a request to the Master Device, the<= br> Master Device may verify..." ?

It's not clear how step 7 relates to steps 6 and 8.

In step 10, might it also send an error, refusal, or whatever? =C2=A0Or are=
those all considered acknowledgment messages?

Hm, it seems that steps 5 and 7 are actually explained in the
paragraph after the numbered steps. =C2=A0So do they really belong in the numbered steps at all?

-- Section 5.1 --

=C2=A0 =C2=A0point: =C2=A0If present, it indicates that the GeoLocation rep= resents a
=C2=A0 =C2=A0 =C2=A0 point.
...
=C2=A0 =C2=A0region: =C2=A0If present, it indicates that the GeoLocation re= presents a
=C2=A0 =C2=A0 =C2=A0 region.

These make it sound as though these are boolean. =C2=A0It took me a bit to<= br> realize that the values of each of these is actually a structure. =C2=A0I think you mean this:

NEW
=C2=A0 =C2=A0point: =C2=A0If present, it specifies the GeoLocation as a poi= nt.
...
=C2=A0 =C2=A0region: =C2=A0If present, it specifies the GeoLocation as a re= gion.
END

-- Section 8.3 --
Please get rid of the MAY in the first sentence.

=C2=A0 =C2=A0If an
=C2=A0 =C2=A0appropriate category does not exist, it can use values in a di= fferent
=C2=A0 =C2=A0range.

What is the antecedent for "it"? =C2=A0It looks like it's &qu= ot;an appropriate
category", but that's clearly not right. =C2=A0Please fix.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D COMME= NT -- minor =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

A small point in the header:
"iconectiv (formerly Telcordia Interconnection Solutions)"
I think it's fine to put that in the "Authors' Addresses"= section, but
the header should just say "iconectiv". =C2=A0I realize that take= s a little
inconvenient massaging of the XML, and probably isn't worth the
trouble for the I-D. =C2=A0Might just put that in an RFC Editor note....
General:
I like that your citations include the document names, as well as the
RFC numbers; thanks! =C2=A0It would be better if you put quotation marks around the document names, to distinguish them from being part of your
text.

-- Section 1 --

=C2=A0 =C2=A0The document describes the use of HTTP/TLS as
=C2=A0 =C2=A0transport for the protocol.

This hits what's rather a peeve of mine: HTTP is not a transport
protocol; the transport protocol you're using is TCP.

I'd be happier if you said something like this:

OLD
=C2=A0 =C2=A0This specification defines an extensible protocol to obtain av= ailable
=C2=A0 =C2=A0spectrum from a geospatial database by a device with geo-locat= ion
=C2=A0 =C2=A0capability.
NEW
=C2=A0 =C2=A0This specification defines an extensible protocol, built on to= p of
=C2=A0 =C2=A0HTTP and TLS, to obtain available spectrum from a geospatial d= atabase
=C2=A0 =C2=A0by a device with geo-location capability.
END

...and then eliminate that last sentence. =C2=A0See also comments on
Section 4 and Section 7.

-- Section 2.2 --

I suggest this:

OLD
=C2=A0 =C2=A0EIRP: =C2=A0Effective isotropically radiated power
=C2=A0 =C2=A0ETSI: =C2=A0European Telecommunications Standards Institute =C2=A0 =C2=A0FCC: =C2=A0Federal Communications Commission
NEW
=C2=A0 =C2=A0ETSI: =C2=A0European Telecommunications Standards Institute &l= t;http://etsi.org>
=C2=A0 =C2=A0FCC: =C2=A0The U.S. Federal Communications Commission <http://fcc.gov>
END

... and then in Section 9.2.2.7, spell out EIRP, as it's only used in that one place.

-- Section 3 --
Little grammar nit:
=C2=A0 =C2=A01. =C2=A0 The Master Device obtains (statically or dynamically= ) the URI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for a Database appropriate for its location to = send subsequent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 PAWS messages.

Make it "location, to which to send".

-- Section 3.1 --

=C2=A0 =C2=A0These
=C2=A0 =C2=A0requirements may be complex and involve device behavior that a= re not
=C2=A0 =C2=A0easily parameterized.

"Device behaviour" is singular, so "that is not", pleas= e.

-- Section 4 --

Usage pet peeve: please change "comprise" to "compose",= in the one
place it's used.

=C2=A0 =C2=A0HTTPS Binding (Section 7) describes the use of
=C2=A0 =C2=A0HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages= and
=C2=A0 =C2=A0optional device authentication.

Please use "transferring", instead of "transporting", t= o avoid calling
HTTP a transport.

-- Section 4.1.1 --

=C2=A0 =C2=A0TBD Define message format

You missed something here. =C2=A0Jus' sayin'.

-- Section 4.4.1 --

=C2=A0 =C2=A0Rulesets may mandate that it be the Device's
=C2=A0 =C2=A0current location or allow it to be an anticipated location.
This is probably as good a place as any to ask this: is there any
validation of the geo-location at all? =C2=A0If not, can such a mandate
have any real teeth? =C2=A0What is this *really* saying?

-- Section 4.4.5 --
The table says that "location" is required, but the text says it&= #39;s not
always required. =C2=A0The table should say "see description".
-- Section 4.5 --

=C2=A0 =C2=A0Typically, a Slave Device needs a Master Device to ask the Dat= abase
=C2=A0 =C2=A0on its behalf for available spectrum

"Typically"? =C2=A0Isn't that the *definition* of a Slave Dev= ice?

-- Section 5.5 --

=C2=A0 =C2=A0All contact information MUST be expressed using the structure = defined
=C2=A0 =C2=A0by the vCard Format Specification [RFC6350].

I think it's best to include both references here, like this:

NEW
=C2=A0 =C2=A0All contact information MUST be expressed using the structure = defined
=C2=A0 =C2=A0by the vCard Format Specification [RFC6350], encoded in JSON [= RFC 7095].
END

-- Section 5.7 --
The subsections explain what additional "data" field each error m= ight
use, but there are only sections for the ones that use the "data"=
field. =C2=A0One has to assume that the absence of a subsection means that<= br> the "data" field is not used for that error. =C2=A0It would be be= tter to
say that in the table. =C2=A0I suggest adding one sentence to each error description in the table except for -104, -105, and -201, as follows:
"This error does not use any additional data."

-- Section 5.11 --
The third table should be labelled "SpectrumProfilePoint".

-- Section 5.12 --
The second table should be labelled "SpectrumProfilePoint".

-- Section 5.17.1 --

=C2=A0 =C2=A0When the error code is OUTSIDE_COVERAGE, the Database MAY incl= ude an
=C2=A0 =C2=A0ErrorData element within its as the "data" field

You're missing the words "Error response" after "within = its".

-- Section 7 --

=C2=A0 =C2=A0This section describes the use of HTTP over TLS (HTTPS) HTTP O= ver TLS
=C2=A0 =C2=A0[RFC2818] as the transport mechanism for the PAWS protocol.
As I've noted earlier, please say "as the transfer mechanism"= . =C2=A0Also,
it's really weird to describe the document in the same words as the
document title. =C2=A0I suggest just deleting the document title in this case. =C2=A0This also applies to Section 10.1.

-- Section 9.1.2 --
The first paragraph was obviously written before the ETSI info was
added. =C2=A0Please adjust it accordingly. =C2=A0(I see that the Gen-ART re= view
mentioned this too, and it will be fixed.)

You might add instructions to the DE with respect to handling
prefixes. =C2=A0Suppose, for example, I wanted to register something
starting with "fcc". =C2=A0Or perhaps with the initials of an org= anization
that hasn't yet registered anything, but reasonably might.

-- Section 10.1 --
The doubled "HTTP over TLS" comment applies here. =C2=A0Also, it&= #39;s not at
all clear, when you say "these checks MAY be omitted," exactly wh= at
checks you're saying may be omitted.

=C2=A0 =C2=A0In particular, the
=C2=A0 =C2=A0validation path of the certificate must end in one of the clie= nt's
=C2=A0 =C2=A0trust anchors, even if that trust anchor is the Database certi= ficate
=C2=A0 =C2=A0itself. =C2=A0A Master Device should allow for the fact that a= Database
=C2=A0 =C2=A0can change its certificate authorities (CAs) over time.

Just a question here: did the WG consider DANE at all?

Another question: is it really necessary to cover this stuff here?
Isn't it in 2818?

-- Section 10.3 --

=C2=A0 =C2=A0Using HTTP over TLS, messages protected by appropriate cypher = suites
=C2=A0 =C2=A0are also protected from eavesdropping or otherwise access by =C2=A0 =C2=A0unauthorized parties en route.

What does "or otherwise access" mean? =C2=A0Apart from the gramma= r problem:
it would be better to say something substantive here, rather than
something vague.

-- Section 11 --
I wouldn't usually comment on a "Contributors" section, but i= t seems
odd to me to cite abandoned and long-expired drafts as references. =C2=A0It=
might be better just to include the draft names, without making them
references. =C2=A0No? =C2=A0You're not actually suggesting that people = read
them, just thanking the authors for their contributions.

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

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



--
-vince --20cf307cfd0c88a0c904fe3da58d-- From nobody Tue Jul 15 09:23: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 055CE1A0A9A for ; Tue, 15 Jul 2014 09:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 g9YH6TZMlb9A for ; Tue, 15 Jul 2014 09:23:19 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39AE1A0A96 for ; Tue, 15 Jul 2014 09:23:18 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so120783lab.36 for ; Tue, 15 Jul 2014 09:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qS0tD3K6SsbIPsHPYX1eEPUfrxuidHDlpTqMzQWFLOI=; b=v5n2n1qOdvh3L3nyKObY180vU9In2wcN1ZugBAYd53nq8TdZDXFjh7w59c0gR+wLTf K+3oB23I5h916PlR6LsZFAW/9j0ruELaYOsEahZuO88HtmAdO8a6QQ2ATxuU55Kh5Jcu bkk6kHcDjhHqjzlBI8abGj74yCw42kdevy7fFmD9TAgUEpdBPfnNHkNu0/YASlherz8+ I+RXTPNlP8uB503M+TFs0lxPUG7ujLstjwvOWK4qkOP9XNsL4dLI4wrUgRRPWnhbn9Or On3Ff19s0C0l6x4Nj8iD3E6p2ibK/Kt18aq/+e8pwJebHBz+59AaoVxAJeQoNEgUEqMb y3yw== MIME-Version: 1.0 X-Received: by 10.112.204.36 with SMTP id kv4mr1544716lbc.106.1405441397101; Tue, 15 Jul 2014 09:23:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Tue, 15 Jul 2014 09:23:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jul 2014 12:23:17 -0400 X-Google-Sender-Auth: OVllE9BTMnKFDcSN-EKV4O4vXCs Message-ID: From: Barry Leiba To: Vincent Chen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/T6QNBtbD4CA7kArLubaVud0w2-M Cc: "paws@ietf.org" Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APP AD) 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: Tue, 15 Jul 2014 16:23:20 -0000 > Should I try to fold all 3 sets of changes into a new 13 draft? or would it > be easier for you if I made 2 separate passes? You should take direction from Pete, but my preference would be to see everything folded in together. Barry From nobody Tue Jul 15 14:42:50 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 C7F0B1B2960; Tue, 15 Jul 2014 14:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] 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 XugZ1YOCYt1F; Tue, 15 Jul 2014 14:42:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566551B295D; Tue, 15 Jul 2014 14:42:41 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6FLgaZu007855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Tue, 15 Jul 2014 16:42:37 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53C5A04D.5040308@nostrum.com> Date: Tue, 15 Jul 2014 16:42:37 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Vincent Chen References: <53B592A2.2080202@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040105030105090708030504" Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Xuy0hzytOFoopIul9IYI60Dd0SQ Cc: "paws@ietf.org" , General Area Review Team , "ietf@ietf.org" , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Gen-art LC review: draft-ietf-paws-protocol-12 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: Tue, 15 Jul 2014 21:42:47 -0000 This is a multi-part message in MIME format. --------------040105030105090708030504 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/8/14, 9:21 PM, Vincent Chen wrote: > Robert, > > Thanks again for the review. I have place comments, questions, > suggested text inline for each of your comments. > Please take a look. I'll be in Toronto if you want to talk about any of these. Some small comments inline: > > -vince > > > On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks > wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-paws-protocol-12 > Reviewer: Robert Sparks > Review Date: 3 July, 2014 > IETF LC End Date: 7 July, 2014 > IESG Telechat date: 10 July, 2014 > > Summary: This document is not ready for publication as a Proposed > Standard. > > I apologize in advance if I've missed where one of the questions > below is already answered. There's a lot to take in here. > > Major Issues > > - The document says it "describes" the use of HTTP/TLS as the > transport for the protocol. Was it the intent to allow others? If > not, the language should be firmed up. > > > The protocol messages are meaningful independent of the transport, so > we did not want to prohibit others. It that frowned on? Well, your security considerations, at least, should talk about what you require of the transport if you don't use TLS. You're leaning heavily on TLS for things like server authentication for example. > > > - The document still says "TBD Define message format" in the > section on Listing Servers. I understand from reading the list > that what the document is going to say about Listing Servers is > going to change (to not include how you talk to them?). This > change needs to be finished before the document can be reviewed > for completeness. > > > Noted. Will ask again on the list. > > > - It's not clear when a server should use the HTTP level > redirection discussed in section 7 vs the databaseChange mechanism > in the protocol's responses. There should be some discussion about > what the Device should do when the databaseChange mechanism > results in a redirect loop. > > > Thanks for pointing this out. I propose removing the HTTP-level 301 > Moved Permanently mechanism and only have the databaseChange mechanism. The group will have to chew on this I guess. You can't forbid HTTP-level 3xx responses, and you still want well defined application behavior when they're received. > > Proposed modified text in Section 4.1: > A Database MAY indicate that its URI will be changing by including > the URI of one or more alternate databases (See DbUpdateSpec > (Section 5.7)) in its responses to a Device. Before a Database > ceases operation, for example, it MUST include DbUpdateSpec in its > responses to notify Devices. A Device will update its preconfigured > list of databases to replace (only) its entry for the responding > Database with the URIs of the alternate databases; the list of > alternate databases does not affect any other entries. Note that the > ordering of databases in the list does not imply any preference and > does not need to remain the same for every request. The Device > SHOULD detect infinite redirection loops; if a suitable database > cannot be contacted, the Device MUST treat this as equivalent to a > response indicating no available spectrum. > > > - The document needs to be clear where the primitive types (like > string, float, and integer) in the UML-ish diagrams in section 4 > are defined. I'm guessing from context that you're assuming the > definitions in RFC4627. If that's true, there are several places > that you talk about string where your text should change. RFC4627 > says string is UNICODE, and may be encoded many ways (see section > 3 of that document). If your intent is to restrict all strings to > UTF-8 encoding say that, and adjust the text you currently have > that mentions UTF-8. (The various places where you say a string > MAY contain UTF-8 do not make sense - if you're assuming the > encoding is UTF-8 and trying to reinforce that there may be > non-ASCII range UTF-8 here, say that explicitly). There are other > related phrases that don't make sense such as where you say things > like "The length of the string MUST NOT exceed 64 US-ASCII > characters." > > > OK. Specified UTF-8 and removed meaningless statements. > > Proposed added text in Section 4: > > The parameter tables in this section and Protocol Parameters > (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 > diagrams are loosely based on UML, and the data types are defined > either in Protocol Parameters (Section 5) or are one of the following > primitive or structured types: > > string A string, as defined by The JavaScript Object Notation (JSON) > Data Interchange Format [RFC7159], restricted to the UTF-8 > encoding. > > int A number, as defined by The JavaScript Object Notation (JSON) > Data Interchange Format [RFC7159], without a fractional or > exponent part. > > float A number, as defined by The JavaScript Object Notation (JSON) > Data Interchange Format [RFC7159]. > > boolean A boolean, as defined by The JavaScript Object Notation > (JSON) Data Interchange Format [RFC7159]. > > list A structured type the represents a list of elements, as defined > by The JavaScript Object Notation (JSON) Data Interchange Format > [RFC7159] array type. For each list parameter, its diagram and > description include a reference to the data type its list > elements. The diagram notation and description may include > additional constraints, such as minimum or maximum number of > elements. > > NOTE: All parameter names are case sensitive. Unless stated > otherwise, all string values are case sensitive. > > > - The descriptions of messages in section 4 all contain > *other:any. None of those are reflected in the concrete schema of > section 6. Should they be? > > > This was intended to be capture by the note in Section 6: > > NOTE: In general, all messages defined in this section are extensible > by adding additional properties to support ruleset-specific and > database-specific requirements. In all cases, the Device or Database > MUST ignore any parameter it does not understand. > > > - The INIT_RESP description requires one or more RulesetInfo > objects. What is a database supposed to do if it has no rulesets > to return (possibly because it doesn't have anything overlapping > with the list of ruleset IDs listed in the DeviceDescriptor in the > INIT_REQ.). Should this have been 0..* (along with the > corresponding change to the text), or is there an Error that the > database should return when this happens. If the latter, it would > be good to call it out in 4.2.2. > > > This was indicated in the prior section for INIT_REQ, but propose > adding the following as first paragraph: > > The initialization response message communicates database parameters > to the requesting device. This response is returned only when there > is at least one ruleset. Otherwise, the Database returns an error > response, as described in INIT_REQ (Section 4.2.1). > > > - Section 4.4 talks about returning OUTSIDE_COVERAGE when the > location specified in the request is outside the regulatory domain > (could that be domains?) supported by the database. The sections > on init and registration (4.2 and 4.3) don't have this discussion. > Should they? > > > Yes. Added to those requests. Thanks. > > > - A databaseChange (at least as described in 4.4) can provide one > or more alternate database URIs, affecting the Device's > configuration. When there's more than one, is there any preference > to what order the Device should try to use them in? Is there any > expectation that they will give the same answers to a given > request? If not, do you want to say anything about discouraging > devices from asking all the databases it knows about to find an > answer it likes best? > > > In general, there should be no difference in answers, because each > Database must also conform to the regulatory rules. There is no > significance implied by the list ordering. On the other hand, I don't > think we need language discouraging devices from asking multiple > databases, since they should have an understanding of the rules as well. > > See proposed text above that contains: > > Note that the > ordering of databases in the list does not imply any preference and > does not need to remain the same for every request. > > > - If the requirements to act as if there is no available > whitespace when you can't reach a Listing Server remain in the > document, the security considerations should call out that any > attack that would prevent reaching a Listing Server would result > in all devices relying on that Listing Server ceasing their use of > any whitespace. > > > Thanks. Added. > > > - Please check the description of 'timeRange' in section 5.9 > (SpectrumSpec). I think you meant to say "in which there is _NO_ > available spectrum". > > > Thanks for the catch! > > > - The definition of SpectrumProfile (section 5.12) needs > clarification. Is this allowed? > "profiles" : [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.24e8, "dbm": 37.0 } > ] > If so, what does it mean? Do I do linear interpolation between > points (33.5 dbm (~2.25 watts) at 521Mhz)? > Similarly, does this specify a ramp up and then back down? (shaped > like a ^)? > [ > {"hz": 5.18e8, "dbm": 30.0 }, > {"hz": 5.21e8, "dbm": 33.5 }, > {"hz": 5.24e8, "dbm": 30.0 } > ] > If not, what text disallows it? > > > This is explicitly allowed. We changed the encoding to allow this. > Propose modifying the first paragraph of 5.12 to the following: > > A spectrum profile is characterized by an ordered list of (frequency, > power) points that represents the shape of maximum permissible power > levels over a range of frequencies as a piecewise linear curve. > > Also add after the list of constraints: > > NOTE: This encoding allows presentation of "ramps" where the slope of > a line segment may be finite and non-zero. > > > > - You are using the schema language defined in > draft-zyp-json-schema to define your message format. That makes it > a normative reference. The draft is expired - are there plans to > progress it? > > > Yikes. The intent is not to define a strict, formal schema, but just > to have a way of defining the messages in a concise fashion. > Do you have a recommendation of what to do here? Are the descriptions > self-explanatory enough? or do I have to define > the "schema language". Check with your AD on the best way to handle this. > > > - Something needs to talk about case-sensitivity of the various > protocol elements. JSON-RPC says that member names are case > sensitive and is otherwise silent. The string "sensitive" doesn't > appear in RFC4627. So, you have an example that says > "authority":"us". Is that the same as "authority":"US", and where > does the spec answer that question? My read of JSON-RPC says that > "authority":"us" and "Authority":"us" are _not_ the same thing, > and that the second would not be a recognized property of a > RulesetInfo object. > > > You're right. See above proposed text defining the primitive types. > > > Minor Issues > > - I'm not finding where you define the protocol version. I see > "1.0" in the json examples in section 6. Where is it specified? > Within a given method, the only extension point I find other than > changing the protocol version is the *other concept in messages, > which MUST be ignored when either side doesn't understand them. So > there should be some discussion about what kind of change would > require the protocol version number to change. Suppose you wanted > to allow batching requests from several slaves into one request to > the database (similar to AVAIL_SPECTRUM_BATCH_REQ but allowing a > list of DeviceDescriptors perhaps). Does this require a new > protocol version, or is it just a new request type in this > version? If you think it's a new request-type, should there be a > request and response type and/or method registry? And yes, I see > how you could do this with JSON-RPC batch, but if that's where > you'd send this idea, why didn't you do AVAIL_SPECTRUM_BATCH_REQ > that way? (Possibly related: I can't figure out what "The > initialization message also represents extension points for > database implementations or rulesets that require the explicit > handshake." is trying to say. Can you rephrase that more simply?) > > > Good point. Propose adding a new section: > > 4.2. PAWS Version > > PAWS version uses a "." numbering scheme to indicate > versions of the protocol. The protocol versioning policy is intended > to allow the Device or Database to indicate the format of a message > and its understanding of PAWS functionality defined by that version. > No change is made to the version string for the addition of message > components which only add to extensible field values. The > number is incremented when the changes made to the protocol add > functionalities (methods), but do not change the existing > functionalities. The number is incremented when incompatible > changes are made to existing functionality. > > The current PAWS version is "1.0". > > > - It's not clear what it means to "support" a ruleset. I infer > that this means that the device has code that implements what's > required by the name. Can you state that explicitly? Does a Master > device have to have this code? Could it simply be a box that only > serves to answer requests from Slave devices? If so, why does it > care what the rulesets actually are. If a slave can ask and a > database can answer, should a master just shovel the bits, or is > there a requirement that the master device be configured to handle > a ruleset before a slave can ask about it? > > > OK. Propose update Terminology section to distinguish between > "ruleset" and "ruleset identifier": > > Ruleset: A ruleset represents a set of rules that governs the > operation of white space devices and Spectrum Databases. A > regulatory authority can define its own set of rules or adopt an > existing ruleset. When a Database or Device is said to "support a > ruleset", it means that it contains out-of-band knowledge of the > rules and that its hardware and software implementations conform > to those rules. > > Ruleset Identifier: A ruleset can be identified by an IANA- > registered identifier (see PAWS Ruleset ID Registry > (Section 9.1)). When a Database or Device indicates it supports a > ruleset identifier, it means that it conforms to the rules > associated with that identifier. A regulatory authority can > define and register its own ruleset identifiers, or it can use a > previously registered identifier if it adopts an existing ruleset. > > > - In the last paragraph of section 4.1 (before 4.1.1 starts), "If > the Device is already operating" assumes that the device could > only be operating if it had previously contacted some database. > The problem is that the device was able to reach a database at one > point and now it can't reach any. It would read more clearly if > you said that explicitly. > > > Proposed change: > > If the Device had previously contacted a database to get available > spectrum, but subsequently fails to contact a suitable database, the > spectrum the Device is currently using can be used for as long as the > spectrum data is valid; ... > > > - Please point somewhere for a definition of the terms > 'uncertainty' and 'confidence' (I suggest > draft-ietf-geopriv-uncertainty). The GEOPRIV working group has > gone through many iterations of disagreement about what these > terms mean and how they should be used. For a taste, skim some of > . > If you don't point to a hard definition, your implementation > community will have to go through the same arguments. > > > Done. Although regulatory authorities may prescribe their own definitions. > > > - Should the security considerations section talk about the risk > of collisions in serialNumber (since it is the only required > element in DeviceDescriptor, and isn't a particularly secret > thing)? Is there any harm at the database if two devices > innocently end up sending the same serial number (without > providing any of the optional information that would otherwise > disambiguate the devices)? Can a device learn anything useful > about another device by spoofing it? Is it possible that in some > regulatory realm, some devices would get more access than others, > encouraging devices to ask about what their competition gets to > do? Can harm be done by a device sending SPECTRUM_USE_NOTIFY > messages claiming to be some other serial number (and perhaps > manufacturer) maliciously? I think this needs more discussion than > what RFC6953 contains. > > > Re: Available spectrum. > The available spectrum depends on device type and location, not on > serial number. Consequently, there is no advantage to spoofing, and > there would be no additional information to be gained on spoofed devices. So, you can't gain information about someone else by claiming to be their device type either? > > If, in the future, there is some regulatory realm that would set up > rules differently, then I think security considerations would be > extended to handle those cases. > > Re: SPECTRUM_USE_NOTIFY > I suppose this depends on the specific regulatory domains (or > database implementations) that require it. Currently there is no harm, > since notifications do not change the available spectrum answers that > the Database returns to devices. > > So should I add these statements to the Security Considerations section? Consider calling out the possibility of SPECTRUM_USE_NOTIFY messages that are fraudulent (and perhaps how client authentication might protect against them)? > > > - The use of the "id" parameter from JSON-RPC deserves more > discussion. The JSON-RPC spec allows it to be string, numeric > (without a fractional part), NULL or missing. You've chosen to > require it (since you're not using json-rpc notifications), and > not allowing numeric values (why?). Are you making any other > assumptions about what it should contain? I think you're assuming > a level of uniqueness that would let you use the Batch mechanism > in section 6 of JSON-RPC (otherwise, the HTTP request/response > context is enough to associate the request and response and the id > might as well be constant). > > > Purely as a practical matter, handling a known type is easier than > multi-type. It should improve interoperability. Otherwise, its value > remains opaque to the Database. > > What is your recommendation here? Just adding a short description of the properties that you require of id. > > > - Section 7 says a server can reject a GET with a 404 - wouldn't > that have consequences for a later POST? Why wouldn't it use a 405? > > > Yes, it's supposed to be 405. > > > - The draft calls for the creation of a special list for review > requests for the IANA assignments. This may be ok (mailing lists > are easy to set up), but is there not an existing list that would > serve the purpose just as well? > > > I do not believe there is an existing list, unless it's standard > practice to re-use this discussion group (paws@ietf.org > ). > > > Nits > > - RFC 2616 has been obsoleted - the references should be updated. > > > Updating to RFC 7231 > > > - It would help to have an example of a ruleset in the definition > in the Terminology section and perhaps for that definition to more > strongly convey that it is a name in a namespace, and what that > rule means is elsewhere. (Right now the definition says that the > ruleset is the actual set of rules, not a name, and it made > reading the protocol overview much harder than it needed to be). > At the very least, pointing to the examples in section 9 early > would help. > > > See proposed text of Terminology above. > > > - Is the document loosely borrowing UML, or are the diagrams used > in section 4 of a format formally defined in some other RFC? A > pointer to a definition of the format, or a brief description > noting it's based on UML along with where the base types are > defined would be useful. > > > See proposed text of primitive types above. Do I need a reference to UML? > > > - "One approach to manage spectrum sharing" is awkward. Would "One > approach to managing spectrum sharing" or "One approach to the > management of spectrum sharing" work? > > > Thanks. Changing to "One approach to managing spectrum sharing" > > > - There are several instances of "The Device needs to use the > information to update its list". Consider clarifying 'needs to'. > Should this have been MUST? > > > These were changed based on comments from our AD (Pete), since they > are not a protocol requirement. > > > - "The vertices MUST be defined in a counter-clockwise direction" > assumes you are looking at them from above - please be explicit. > > > Thanks. Adding clarification. > > > - Section 9.1.2's first paragraph should say "FCC and ETSI" the > same way 9.2.2 does. You could generalize that to "any particular > set of authorities". > > > Thanks for the suggestion. Changing both to "any particular set of > authorities". > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > -- > -vince --------------040105030105090708030504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 7/8/14, 9:21 PM, Vincent Chen wrote:
Robert,

Thanks again for the review. I have place comments, questions, suggested text inline for each of your comments.
Please take a look.
I'll be in Toronto if you want to talk about any of these.

Some small comments inline:

-vince


On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-paws-protocol-12
Reviewer: Robert Sparks
Review Date: 3 July, 2014
IETF LC End Date: 7 July, 2014
IESG Telechat date: 10 July, 2014

Summary: This document is not ready for publication as a Proposed Standard.

I apologize in advance if I've missed where one of the questions below is already answered. There's a lot to take in here.

Major Issues

- The document says it "describes" the use of HTTP/TLS as the transport for the protocol. Was it the intent to allow others? If not, the language should be firmed up.

The protocol messages are meaningful independent of the transport, so we did not want to prohibit others. It that frowned on?

Well, your security considerations, at least, should talk about what you require of the transport if you don't use TLS. You're leaning heavily on TLS for things like server authentication for example.
 

- The document still says "TBD Define message format" in the section on Listing Servers. I understand from reading the list that what the document is going to say about Listing Servers is going to change (to not include how you talk to them?). This change needs to be finished before the document can be reviewed for completeness.

Noted. Will ask again on the list.
 

- It's not clear when a server should use the HTTP level redirection discussed in section 7 vs the databaseChange mechanism in the protocol's responses. There should be some discussion about what the Device should do when the databaseChange mechanism results in a redirect loop.

Thanks for pointing this out. I propose removing the HTTP-level 301 Moved Permanently mechanism and only have the databaseChange mechanism.
The group will have to chew on this I guess. You can't forbid HTTP-level 3xx responses, and you still want well defined application behavior when they're received.

Proposed modified text in Section 4.1:
   A Database MAY indicate that its URI will be changing by including
   the URI of one or more alternate databases (See DbUpdateSpec
   (Section 5.7)) in its responses to a Device.  Before a Database
   ceases operation, for example, it MUST include DbUpdateSpec in its
   responses to notify Devices.  A Device will update its preconfigured
   list of databases to replace (only) its entry for the responding
   Database with the URIs of the alternate databases; the list of
   alternate databases does not affect any other entries.  Note that the
   ordering of databases in the list does not imply any preference and
   does not need to remain the same for every request.  The Device
   SHOULD detect infinite redirection loops; if a suitable database
   cannot be contacted, the Device MUST treat this as equivalent to a
   response indicating no available spectrum.
  
 

- The document needs to be clear where the primitive types (like string, float, and integer) in the UML-ish diagrams in section 4 are defined. I'm guessing from context that you're assuming the definitions in RFC4627. If that's true, there are several places that you talk about string where your text should change. RFC4627 says string is UNICODE, and may be encoded many ways (see section 3 of that document). If your intent is to restrict all strings to UTF-8 encoding say that, and adjust the text you currently have that mentions UTF-8. (The various places where you say a string MAY contain UTF-8 do not make sense - if you're assuming the encoding is UTF-8 and trying to reinforce that there may be non-ASCII range UTF-8 here, say that explicitly). There are other related phrases that don't make sense such as where you say things like "The length of the string MUST NOT exceed 64 US-ASCII characters."

OK. Specified UTF-8 and removed meaningless statements.

Proposed added text in Section 4:

   The parameter tables in this section and Protocol Parameters
   (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
   diagrams are loosely based on UML, and the data types are defined
   either in Protocol Parameters (Section 5) or are one of the following
   primitive or structured types:

   string  A string, as defined by The JavaScript Object Notation (JSON)
      Data Interchange Format [RFC7159], restricted to the UTF-8
      encoding.

   int  A number, as defined by The JavaScript Object Notation (JSON)
      Data Interchange Format [RFC7159], without a fractional or
      exponent part.

   float  A number, as defined by The JavaScript Object Notation (JSON)
      Data Interchange Format [RFC7159].

   boolean  A boolean, as defined by The JavaScript Object Notation
      (JSON) Data Interchange Format [RFC7159].

   list  A structured type the represents a list of elements, as defined
      by The JavaScript Object Notation (JSON) Data Interchange Format
      [RFC7159] array type.  For each list parameter, its diagram and
      description include a reference to the data type its list
      elements.  The diagram notation and description may include
      additional constraints, such as minimum or maximum number of
      elements.

   NOTE: All parameter names are case sensitive.  Unless stated
   otherwise, all string values are case sensitive.


- The descriptions of messages in section 4 all contain *other:any. None of those are reflected in the concrete schema of section 6. Should they be?

This was intended to be capture by the note in Section 6:

   NOTE: In general, all messages defined in this section are extensible
   by adding additional properties to support ruleset-specific and
   database-specific requirements.  In all cases, the Device or Database
   MUST ignore any parameter it does not understand.
 

- The INIT_RESP description requires one or more RulesetInfo objects. What is a database supposed to do if it has no rulesets to return (possibly because it doesn't have anything overlapping with the list of ruleset IDs listed in the DeviceDescriptor in the INIT_REQ.). Should this have been 0..* (along with the corresponding change to the text), or is there an Error that the database should return when this happens. If the latter, it would be good to call it out in 4.2.2.

This was indicated in the prior section for INIT_REQ, but propose adding the following as first paragraph:

   The initialization response message communicates database parameters
   to the requesting device.  This response is returned only when there
   is at least one ruleset.  Otherwise, the Database returns an error
   response, as described in INIT_REQ (Section 4.2.1).

 

- Section 4.4 talks about returning OUTSIDE_COVERAGE when the location specified in the request is outside the regulatory domain (could that be domains?) supported by the database. The sections on init and registration (4.2 and 4.3) don't have this discussion. Should they?

Yes. Added to those requests. Thanks.
 

- A databaseChange (at least as described in 4.4) can provide one or more alternate database URIs, affecting the Device's configuration. When there's more than one, is there any preference to what order the Device should try to use them in? Is there any expectation that they will give the same answers to a given request? If not, do you want to say anything about discouraging devices from asking all the databases it knows about to find an answer it likes best?

In general, there should be no difference in answers, because each Database must also conform to the regulatory rules. There is no significance implied by the list ordering. On the other hand, I don't think we need language discouraging devices from asking multiple databases, since they should have an understanding of the rules as well.

See proposed text above that contains:

   Note that the
   ordering of databases in the list does not imply any preference and
   does not need to remain the same for every request.
 

- If the requirements to act as if there is no available whitespace when you can't reach a Listing Server remain in the document, the security considerations should call out that any attack that would prevent reaching a Listing Server would result in all devices relying on that Listing Server ceasing their use of any whitespace.

Thanks. Added.
 

- Please check the description of 'timeRange' in section 5.9 (SpectrumSpec). I think you meant to say "in which there is _NO_ available spectrum".

Thanks for the catch!
 

- The definition of SpectrumProfile (section 5.12) needs clarification. Is this allowed?
  "profiles" : [
    {"hz": 5.18e8, "dbm": 30.0 },
    {"hz": 5.24e8, "dbm": 37.0 }
  ]
If so, what does it mean? Do I do linear interpolation between points (33.5 dbm (~2.25 watts) at 521Mhz)?
Similarly, does this specify a ramp up and then back down? (shaped like a ^)?
  [
    {"hz": 5.18e8, "dbm": 30.0 },
    {"hz": 5.21e8, "dbm": 33.5 },
    {"hz": 5.24e8, "dbm": 30.0 }
  ]
If not, what text disallows it?

This is explicitly allowed. We changed the encoding to allow this. Propose modifying the first paragraph of  5.12 to the following:

   A spectrum profile is characterized by an ordered list of (frequency,
   power) points that represents the shape of maximum permissible power
   levels over a range of frequencies as a piecewise linear curve.

Also add after the list of constraints:

   NOTE: This encoding allows presentation of "ramps" where the slope of
   a line segment may be finite and non-zero.



- You are using the schema language defined in draft-zyp-json-schema to define your message format. That makes it a normative reference. The draft is expired - are there plans to progress it?

Yikes. The intent is not to define a strict, formal schema, but just to have a way of defining the messages in a concise fashion.
Do you have a recommendation of what to do here? Are the descriptions self-explanatory enough? or do I have to define
the "schema language".
Check with your AD on the best way to handle this.
 

- Something needs to talk about case-sensitivity of the various protocol elements. JSON-RPC says that member names are case sensitive and is otherwise silent. The string "sensitive" doesn't appear in RFC4627. So, you have an example that says "authority":"us". Is that the same as "authority":"US", and where does the spec answer that question? My read of JSON-RPC says that "authority":"us" and "Authority":"us" are _not_ the same thing, and that the second would not be a recognized property of a RulesetInfo object.

You're right. See above proposed text defining the primitive types.
 

Minor Issues

- I'm not finding where you define the protocol version. I see "1.0" in the json examples in section 6. Where is it specified? Within a given method, the only extension point I find other than changing the protocol version is the *other concept in messages, which MUST be ignored when either side doesn't understand them. So there should be some discussion about what kind of change would require the protocol version number to change. Suppose you wanted to allow batching requests from several slaves into one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but allowing a list of DeviceDescriptors perhaps). Does this require a new protocol version, or is it just a new request type in this version? If you think it's a new request-type, should there be a request and response type and/or method registry?  And yes, I see how you could do this with JSON-RPC batch, but if that's where you'd send this idea, why didn't you do AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figure out what "The initialization message also represents extension points for database implementations or rulesets that require the explicit handshake." is trying to say. Can you rephrase that more simply?)

Good point. Propose adding a new section:

4.2.  PAWS Version

   PAWS version uses a "<major>.<minor>" numbering scheme to indicate
   versions of the protocol.  The protocol versioning policy is intended
   to allow the Device or Database to indicate the format of a message
   and its understanding of PAWS functionality defined by that version.
   No change is made to the version string for the addition of message
   components which only add to extensible field values.  The <minor>
   number is incremented when the changes made to the protocol add
   functionalities (methods), but do not change the existing
   functionalities.  The <major> number is incremented when incompatible
   changes are made to existing functionality.

   The current PAWS version is "1.0".
 

- It's not clear what it means to "support" a ruleset. I infer that this means that the device has code that implements what's required by the name. Can you state that explicitly? Does a Master device have to have this code? Could it simply be a box that only serves to answer requests from Slave devices? If so, why does it care what the rulesets actually are. If a slave can ask and a database can answer, should a master just shovel the bits, or is there a requirement that the master device be configured to handle a ruleset before a slave can ask about it?

OK. Propose update Terminology section to distinguish between "ruleset" and "ruleset identifier":

   Ruleset:  A ruleset represents a set of rules that governs the
      operation of white space devices and Spectrum Databases.  A
      regulatory authority can define its own set of rules or adopt an
      existing ruleset.  When a Database or Device is said to "support a
      ruleset", it means that it contains out-of-band knowledge of the
      rules and that its hardware and software implementations conform
      to those rules.

   Ruleset Identifier:  A ruleset can be identified by an IANA-
      registered identifier (see PAWS Ruleset ID Registry
      (Section 9.1)).  When a Database or Device indicates it supports a
      ruleset identifier, it means that it conforms to the rules
      associated with that identifier.  A regulatory authority can
      define and register its own ruleset identifiers, or it can use a
      previously registered identifier if it adopts an existing ruleset.
 

- In the last paragraph of section 4.1 (before 4.1.1 starts), "If the Device is already operating" assumes that the device could only be operating if it had previously contacted some database. The problem is that the device was able to reach a database at one point and now it can't reach any.  It would read more clearly if you said that explicitly.

Proposed change:

   If the Device had previously contacted a database to get available
   spectrum, but subsequently fails to contact a suitable database, the
   spectrum the Device is currently using can be used for as long as the
   spectrum data is valid; ...
 

- Please point somewhere for a definition of the terms 'uncertainty' and 'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV working group has gone through many iterations of disagreement about what these terms mean and how they should be used. For a taste, skim some of <https://mailarchive.ietf.org/arch/search/?email_list=geopriv&q=uncertainty>. If you don't point to a hard definition, your implementation community will have to go through the same arguments.

Done. Although regulatory authorities may prescribe their own definitions.
 

- Should the security considerations section talk about the risk of collisions in serialNumber (since it is the only required element in DeviceDescriptor, and isn't a particularly secret thing)? Is there any harm at the database if two devices innocently end up sending the same serial number (without providing any of the optional information that would otherwise disambiguate the devices)? Can a device learn anything useful about another device by spoofing it? Is it possible that in some regulatory realm, some devices would get more access than others, encouraging devices to ask about what their competition gets to do? Can harm be done by a device sending SPECTRUM_USE_NOTIFY messages claiming to be some other serial number (and perhaps manufacturer) maliciously? I think this needs more discussion than what RFC6953 contains.

Re: Available spectrum.
  The available spectrum depends on device type and location, not on serial number. Consequently, there is no advantage to spoofing, and there would be no additional information to be gained on spoofed devices.
So, you can't gain information about someone else by claiming to be their device type either?

  If, in the future, there is some regulatory realm that would set up rules differently, then I think security considerations would be extended to handle those cases.

Re: SPECTRUM_USE_NOTIFY
  I suppose this depends on the specific regulatory domains (or database implementations) that require it. Currently there is no harm, since notifications do not change the available spectrum answers that the Database returns to devices.

So should I add these statements to the Security Considerations section?
Consider calling out the possibility of SPECTRUM_USE_NOTIFY messages that are fraudulent (and perhaps how client authentication might protect against them)?
 

- The use of the "id" parameter from JSON-RPC deserves more discussion. The JSON-RPC spec allows it to be string, numeric (without a fractional part), NULL or missing. You've chosen to require it (since you're not using json-rpc notifications), and not allowing numeric values (why?). Are you making any other assumptions about what it should contain? I think you're assuming a level of uniqueness that would let you use the Batch mechanism in section 6 of JSON-RPC (otherwise, the HTTP request/response context is enough to associate the request and response and the id might as well be constant).

Purely as a practical matter, handling a known type is easier than multi-type. It should improve interoperability. Otherwise, its value remains opaque to the Database.

What is your recommendation here?
Just adding a short description of the properties that you require of id.
 

- Section 7 says a server can reject a GET with a 404 - wouldn't that have consequences for a later POST? Why wouldn't it use a 405?

Yes, it's supposed to be 405.
 

- The draft calls for the creation of a special list for review requests for the IANA assignments. This may be ok (mailing lists are easy to set up), but is there not an existing list that would serve the purpose just as well?

I do not believe there is an existing list, unless it's standard practice to re-use this discussion group (paws@ietf.org).
 

Nits

- RFC 2616 has been obsoleted - the references should be updated.

Updating to RFC 7231
 

- It would help to have an example of a ruleset in the definition in the Terminology section and perhaps for that definition to more strongly convey that it is a name in a namespace, and what that rule means is elsewhere.  (Right now the definition says that the ruleset is the actual set of rules, not a name, and it made reading the protocol overview much harder than it needed to be). At the very least, pointing to the examples in section 9 early would help.

See proposed text of Terminology above.
 

- Is the document loosely borrowing UML, or are the diagrams used in section 4 of a format formally defined in some other RFC? A pointer to a definition of the format, or a brief description noting it's based on UML along with where the base types are defined would be useful.

See proposed text of primitive types above. Do I need a reference to UML?
 

- "One approach to manage spectrum sharing" is awkward. Would "One approach to managing spectrum sharing" or "One approach to the management of spectrum sharing" work?

Thanks. Changing to "One approach to managing spectrum sharing"
 

- There are several instances of "The Device needs to use the information to update its list". Consider clarifying 'needs to'. Should this have been MUST?

These were changed based on comments from our AD (Pete), since they are not a protocol requirement.


- "The vertices MUST be defined in a counter-clockwise direction" assumes you are looking at them from above - please be explicit.

Thanks. Adding clarification.
 

- Section 9.1.2's first paragraph should say "FCC and ETSI" the same way 9.2.2 does. You could generalize that to "any particular set of authorities".

Thanks for the suggestion. Changing both to "any particular set of authorities".
 

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



--
-vince

--------------040105030105090708030504-- From nobody Wed Jul 16 09:06: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 D28881B2BDF for ; Wed, 16 Jul 2014 09:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=unavailable 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 JuRSssd0pwEU for ; Wed, 16 Jul 2014 09:06:12 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB851B2BCE for ; Wed, 16 Jul 2014 09:06:06 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so2106719vcb.13 for ; Wed, 16 Jul 2014 09:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2shmLPF9yFu9uiFR53h97rzRDKD2jMokBOmhtdnmahk=; b=c+asL6dXyK3C73UXn2/IhUTEA8qjIp12/L4Ck88ET7ueOrTVynmunHwMl+OQS7NeML E5pzrdxJjNsogz5MDmLHuPHGm6lb6fuN/CibXzja8tj6ISuspGfCCAYLiPUcyJX1NnaL LvHUykinHd1rrQVjv2ZFhB9caAmVZqQdiIB6qKAcWvLV0wlEfATmgwZ4sJ1CR5ktbQKQ fThfn68cW9QlfxVUR8xua4IZst4Tmezt9H/A6yUcwYfcfzpNAsbKj6+OH3gkzi2BoCW8 fPDvJU30St9w++W78b8TyuFq2flCqpExC4NIJVWQ8RpK7cY0CMzA6W8ulID+XWMCpkMV 5Mag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2shmLPF9yFu9uiFR53h97rzRDKD2jMokBOmhtdnmahk=; b=fu+ozVcqcGx1JFbVTRfrAKboL2HikF1DyNJFssXC+tU2Llrw3HShTOtawIhEx62ZdP OQugloKDkCX3VCMxwk7ZovjqQFC1nNzUAFy2tO+PheHPvHoCNpOuVup27lWzKV3Bxo5m /f6pFPYB9AjLC1VHscVXImGCZgiP+AFT0KohJhbkoJaXi0OGMwKR6ARkG22q0Bx0U29j Vd9KaXedISdKeSaaCFCGlDfV7jTqiIB3tTtGuWLBGXdyyzzhEHNdv/edM+/5TyazvhVr Ll1PuK/7SR1j6+ksF11Y4gwhabH5nf0dctpwZ2Rd8ncGY/9a9LYpno8QKz1zTunlfy50 Tm3A== X-Gm-Message-State: ALoCoQkVoR4PA9TfFnOXXY459VquWp1eYltoxxBkegKz5Y8Cm/rhzJpOrhPIU7T7dEO7PnUapp3Y MIME-Version: 1.0 X-Received: by 10.52.232.200 with SMTP id tq8mr14511114vdc.32.1405526764343; Wed, 16 Jul 2014 09:06:04 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Wed, 16 Jul 2014 09:06:04 -0700 (PDT) In-Reply-To: <53C5A04D.5040308@nostrum.com> References: <53B592A2.2080202@nostrum.com> <53C5A04D.5040308@nostrum.com> Date: Wed, 16 Jul 2014 09:06:04 -0700 Message-ID: From: Vincent Chen To: Robert Sparks Content-Type: multipart/alternative; boundary=089e0122f5fa82e5bc04fe51b368 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Ez_3ww03t6MdXmYWWx7e0oFaI7Y Cc: "paws@ietf.org" , General Area Review Team , "ietf@ietf.org" , draft-ietf-paws-protocol@tools.ietf.org Subject: Re: [paws] Gen-art LC review: draft-ietf-paws-protocol-12 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: Wed, 16 Jul 2014 16:06:19 -0000 --089e0122f5fa82e5bc04fe51b368 Content-Type: text/plain; charset=UTF-8 Robert, Thanks again. On Tue, Jul 15, 2014 at 2:42 PM, Robert Sparks wrote: > > On 7/8/14, 9:21 PM, Vincent Chen wrote: > > Robert, > > Thanks again for the review. I have place comments, questions, suggested > text inline for each of your comments. > Please take a look. > > I'll be in Toronto if you want to talk about any of these. > Still trying to decide if I can make it... > > Some small comments inline: > > > -vince > > > On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks > wrote: > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-paws-protocol-12 >> Reviewer: Robert Sparks >> Review Date: 3 July, 2014 >> IETF LC End Date: 7 July, 2014 >> IESG Telechat date: 10 July, 2014 >> >> Summary: This document is not ready for publication as a Proposed >> Standard. >> >> I apologize in advance if I've missed where one of the questions below is >> already answered. There's a lot to take in here. >> >> Major Issues >> >> - The document says it "describes" the use of HTTP/TLS as the transport >> for the protocol. Was it the intent to allow others? If not, the language >> should be firmed up. >> > > The protocol messages are meaningful independent of the transport, so we > did not want to prohibit others. It that frowned on? > > > Well, your security considerations, at least, should talk about what you > require of the transport if you don't use TLS. You're leaning heavily on > TLS for things like server authentication for example. > Acknowledged. > > > >> >> - The document still says "TBD Define message format" in the section on >> Listing Servers. I understand from reading the list that what the document >> is going to say about Listing Servers is going to change (to not include >> how you talk to them?). This change needs to be finished before the >> document can be reviewed for completeness. >> > > Noted. Will ask again on the list. > > >> >> - It's not clear when a server should use the HTTP level redirection >> discussed in section 7 vs the databaseChange mechanism in the protocol's >> responses. There should be some discussion about what the Device should do >> when the databaseChange mechanism results in a redirect loop. >> > > Thanks for pointing this out. I propose removing the HTTP-level 301 > Moved Permanently mechanism and only have the databaseChange mechanism. > > The group will have to chew on this I guess. You can't forbid HTTP-level > 3xx responses, and you still want well defined application behavior when > they're received. > I see about not forbidding 3xx responses. Perhaps just clarification that the preferred mechanism is databaseChange. > > > Proposed modified text in Section 4.1: > A Database MAY indicate that its URI will be changing by including > the URI of one or more alternate databases (See DbUpdateSpec > (Section 5.7)) in its responses to a Device. Before a Database > ceases operation, for example, it MUST include DbUpdateSpec in its > responses to notify Devices. A Device will update its preconfigured > list of databases to replace (only) its entry for the responding > Database with the URIs of the alternate databases; the list of > alternate databases does not affect any other entries. Note that the > ordering of databases in the list does not imply any preference and > does not need to remain the same for every request. The Device > SHOULD detect infinite redirection loops; if a suitable database > cannot be contacted, the Device MUST treat this as equivalent to a > response indicating no available spectrum. > > > >> >> - The document needs to be clear where the primitive types (like string, >> float, and integer) in the UML-ish diagrams in section 4 are defined. I'm >> guessing from context that you're assuming the definitions in RFC4627. If >> that's true, there are several places that you talk about string where your >> text should change. RFC4627 says string is UNICODE, and may be encoded many >> ways (see section 3 of that document). If your intent is to restrict all >> strings to UTF-8 encoding say that, and adjust the text you currently have >> that mentions UTF-8. (The various places where you say a string MAY contain >> UTF-8 do not make sense - if you're assuming the encoding is UTF-8 and >> trying to reinforce that there may be non-ASCII range UTF-8 here, say that >> explicitly). There are other related phrases that don't make sense such as >> where you say things like "The length of the string MUST NOT exceed 64 >> US-ASCII characters." >> > > OK. Specified UTF-8 and removed meaningless statements. > > Proposed added text in Section 4: > > The parameter tables in this section and Protocol Parameters > (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 > diagrams are loosely based on UML, and the data types are defined > either in Protocol Parameters (Section 5) or are one of the following > primitive or structured types: > > string A string, as defined by The JavaScript Object Notation (JSON) > Data Interchange Format [RFC7159], restricted to the UTF-8 > encoding. > > int A number, as defined by The JavaScript Object Notation (JSON) > Data Interchange Format [RFC7159], without a fractional or > exponent part. > > float A number, as defined by The JavaScript Object Notation (JSON) > Data Interchange Format [RFC7159]. > > boolean A boolean, as defined by The JavaScript Object Notation > (JSON) Data Interchange Format [RFC7159]. > > list A structured type the represents a list of elements, as defined > by The JavaScript Object Notation (JSON) Data Interchange Format > [RFC7159] array type. For each list parameter, its diagram and > description include a reference to the data type its list > elements. The diagram notation and description may include > additional constraints, such as minimum or maximum number of > elements. > > NOTE: All parameter names are case sensitive. Unless stated > otherwise, all string values are case sensitive. > > >> - The descriptions of messages in section 4 all contain *other:any. None >> of those are reflected in the concrete schema of section 6. Should they be? >> > > This was intended to be capture by the note in Section 6: > > NOTE: In general, all messages defined in this section are extensible > by adding additional properties to support ruleset-specific and > database-specific requirements. In all cases, the Device or Database > MUST ignore any parameter it does not understand. > > > >> >> - The INIT_RESP description requires one or more RulesetInfo objects. >> What is a database supposed to do if it has no rulesets to return (possibly >> because it doesn't have anything overlapping with the list of ruleset IDs >> listed in the DeviceDescriptor in the INIT_REQ.). Should this have been >> 0..* (along with the corresponding change to the text), or is there an >> Error that the database should return when this happens. If the latter, it >> would be good to call it out in 4.2.2. >> > > This was indicated in the prior section for INIT_REQ, but propose adding > the following as first paragraph: > > The initialization response message communicates database parameters > to the requesting device. This response is returned only when there > is at least one ruleset. Otherwise, the Database returns an error > response, as described in INIT_REQ (Section 4.2.1). > > > >> >> - Section 4.4 talks about returning OUTSIDE_COVERAGE when the location >> specified in the request is outside the regulatory domain (could that be >> domains?) supported by the database. The sections on init and registration >> (4.2 and 4.3) don't have this discussion. Should they? >> > > Yes. Added to those requests. Thanks. > > >> >> - A databaseChange (at least as described in 4.4) can provide one or more >> alternate database URIs, affecting the Device's configuration. When there's >> more than one, is there any preference to what order the Device should try >> to use them in? Is there any expectation that they will give the same >> answers to a given request? If not, do you want to say anything about >> discouraging devices from asking all the databases it knows about to find >> an answer it likes best? >> > > In general, there should be no difference in answers, because each > Database must also conform to the regulatory rules. There is no > significance implied by the list ordering. On the other hand, I don't think > we need language discouraging devices from asking multiple databases, since > they should have an understanding of the rules as well. > > See proposed text above that contains: > > Note that the > ordering of databases in the list does not imply any preference and > does not need to remain the same for every request. > > >> >> - If the requirements to act as if there is no available whitespace when >> you can't reach a Listing Server remain in the document, the security >> considerations should call out that any attack that would prevent reaching >> a Listing Server would result in all devices relying on that Listing Server >> ceasing their use of any whitespace. >> > > Thanks. Added. > > >> >> - Please check the description of 'timeRange' in section 5.9 >> (SpectrumSpec). I think you meant to say "in which there is _NO_ available >> spectrum". >> > > Thanks for the catch! > > >> >> - The definition of SpectrumProfile (section 5.12) needs clarification. >> Is this allowed? >> "profiles" : [ >> {"hz": 5.18e8, "dbm": 30.0 }, >> {"hz": 5.24e8, "dbm": 37.0 } >> ] >> If so, what does it mean? Do I do linear interpolation between points >> (33.5 dbm (~2.25 watts) at 521Mhz)? >> Similarly, does this specify a ramp up and then back down? (shaped like a >> ^)? >> [ >> {"hz": 5.18e8, "dbm": 30.0 }, >> {"hz": 5.21e8, "dbm": 33.5 }, >> {"hz": 5.24e8, "dbm": 30.0 } >> ] >> If not, what text disallows it? >> > > This is explicitly allowed. We changed the encoding to allow this. > Propose modifying the first paragraph of 5.12 to the following: > > A spectrum profile is characterized by an ordered list of (frequency, > power) points that represents the shape of maximum permissible power > levels over a range of frequencies as a piecewise linear curve. > > Also add after the list of constraints: > > NOTE: This encoding allows presentation of "ramps" where the slope of > a line segment may be finite and non-zero. > > >> >> - You are using the schema language defined in draft-zyp-json-schema to >> define your message format. That makes it a normative reference. The draft >> is expired - are there plans to progress it? >> > > Yikes. The intent is not to define a strict, formal schema, but just to > have a way of defining the messages in a concise fashion. > Do you have a recommendation of what to do here? Are the descriptions > self-explanatory enough? or do I have to define > the "schema language". > > Check with your AD on the best way to handle this. > Acknowledged > > > >> >> - Something needs to talk about case-sensitivity of the various protocol >> elements. JSON-RPC says that member names are case sensitive and is >> otherwise silent. The string "sensitive" doesn't appear in RFC4627. So, you >> have an example that says "authority":"us". Is that the same as >> "authority":"US", and where does the spec answer that question? My read of >> JSON-RPC says that "authority":"us" and "Authority":"us" are _not_ the same >> thing, and that the second would not be a recognized property of a >> RulesetInfo object. >> > > You're right. See above proposed text defining the primitive types. > > >> >> Minor Issues >> >> - I'm not finding where you define the protocol version. I see "1.0" in >> the json examples in section 6. Where is it specified? Within a given >> method, the only extension point I find other than changing the protocol >> version is the *other concept in messages, which MUST be ignored when >> either side doesn't understand them. So there should be some discussion >> about what kind of change would require the protocol version number to >> change. Suppose you wanted to allow batching requests from several slaves >> into one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but >> allowing a list of DeviceDescriptors perhaps). Does this require a new >> protocol version, or is it just a new request type in this version? If you >> think it's a new request-type, should there be a request and response type >> and/or method registry? And yes, I see how you could do this with JSON-RPC >> batch, but if that's where you'd send this idea, why didn't you do >> AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figure out >> what "The initialization message also represents extension points for >> database implementations or rulesets that require the explicit handshake." >> is trying to say. Can you rephrase that more simply?) >> > > Good point. Propose adding a new section: > > 4.2. PAWS Version > > PAWS version uses a "." numbering scheme to indicate > versions of the protocol. The protocol versioning policy is intended > to allow the Device or Database to indicate the format of a message > and its understanding of PAWS functionality defined by that version. > No change is made to the version string for the addition of message > components which only add to extensible field values. The > number is incremented when the changes made to the protocol add > functionalities (methods), but do not change the existing > functionalities. The number is incremented when incompatible > changes are made to existing functionality. > > The current PAWS version is "1.0". > > >> >> - It's not clear what it means to "support" a ruleset. I infer that this >> means that the device has code that implements what's required by the name. >> Can you state that explicitly? Does a Master device have to have this code? >> Could it simply be a box that only serves to answer requests from Slave >> devices? If so, why does it care what the rulesets actually are. If a slave >> can ask and a database can answer, should a master just shovel the bits, or >> is there a requirement that the master device be configured to handle a >> ruleset before a slave can ask about it? >> > > OK. Propose update Terminology section to distinguish between "ruleset" > and "ruleset identifier": > > Ruleset: A ruleset represents a set of rules that governs the > operation of white space devices and Spectrum Databases. A > regulatory authority can define its own set of rules or adopt an > existing ruleset. When a Database or Device is said to "support a > ruleset", it means that it contains out-of-band knowledge of the > rules and that its hardware and software implementations conform > to those rules. > > Ruleset Identifier: A ruleset can be identified by an IANA- > registered identifier (see PAWS Ruleset ID Registry > (Section 9.1)). When a Database or Device indicates it supports a > ruleset identifier, it means that it conforms to the rules > associated with that identifier. A regulatory authority can > define and register its own ruleset identifiers, or it can use a > previously registered identifier if it adopts an existing ruleset. > > >> >> - In the last paragraph of section 4.1 (before 4.1.1 starts), "If the >> Device is already operating" assumes that the device could only be >> operating if it had previously contacted some database. The problem is that >> the device was able to reach a database at one point and now it can't reach >> any. It would read more clearly if you said that explicitly. >> > > Proposed change: > > If the Device had previously contacted a database to get available > spectrum, but subsequently fails to contact a suitable database, the > spectrum the Device is currently using can be used for as long as the > spectrum data is valid; ... > > >> >> - Please point somewhere for a definition of the terms 'uncertainty' and >> 'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV >> working group has gone through many iterations of disagreement about what >> these terms mean and how they should be used. For a taste, skim some of < >> https://mailarchive.ietf.org/arch/search/?email_list=geopriv&q=uncertainty>. >> If you don't point to a hard definition, your implementation community will >> have to go through the same arguments. >> > > Done. Although regulatory authorities may prescribe their own > definitions. > > >> >> - Should the security considerations section talk about the risk of >> collisions in serialNumber (since it is the only required element in >> DeviceDescriptor, and isn't a particularly secret thing)? Is there any harm >> at the database if two devices innocently end up sending the same serial >> number (without providing any of the optional information that would >> otherwise disambiguate the devices)? Can a device learn anything useful >> about another device by spoofing it? Is it possible that in some regulatory >> realm, some devices would get more access than others, encouraging devices >> to ask about what their competition gets to do? Can harm be done by a >> device sending SPECTRUM_USE_NOTIFY messages claiming to be some other >> serial number (and perhaps manufacturer) maliciously? I think this needs >> more discussion than what RFC6953 contains. >> > > Re: Available spectrum. > The available spectrum depends on device type and location, not on > serial number. Consequently, there is no advantage to spoofing, and there > would be no additional information to be gained on spoofed devices. > > So, you can't gain information about someone else by claiming to be their > device type either? > Correct. There's no device-specific information. > > > If, in the future, there is some regulatory realm that would set up > rules differently, then I think security considerations would be extended > to handle those cases. > > Re: SPECTRUM_USE_NOTIFY > I suppose this depends on the specific regulatory domains (or database > implementations) that require it. Currently there is no harm, since > notifications do not change the available spectrum answers that the > Database returns to devices. > > So should I add these statements to the Security Considerations section? > > Consider calling out the possibility of SPECTRUM_USE_NOTIFY messages that > are fraudulent (and perhaps how client authentication might protect against > them)? > Acknowledged. > > > >> >> - The use of the "id" parameter from JSON-RPC deserves more discussion. >> The JSON-RPC spec allows it to be string, numeric (without a fractional >> part), NULL or missing. You've chosen to require it (since you're not using >> json-rpc notifications), and not allowing numeric values (why?). Are you >> making any other assumptions about what it should contain? I think you're >> assuming a level of uniqueness that would let you use the Batch mechanism >> in section 6 of JSON-RPC (otherwise, the HTTP request/response context is >> enough to associate the request and response and the id might as well be >> constant). >> > > Purely as a practical matter, handling a known type is easier than > multi-type. It should improve interoperability. Otherwise, its value > remains opaque to the Database. > > What is your recommendation here? > > Just adding a short description of the properties that you require of id. > Ack. > > > >> >> - Section 7 says a server can reject a GET with a 404 - wouldn't that >> have consequences for a later POST? Why wouldn't it use a 405? >> > > Yes, it's supposed to be 405. > > >> >> - The draft calls for the creation of a special list for review requests >> for the IANA assignments. This may be ok (mailing lists are easy to set >> up), but is there not an existing list that would serve the purpose just as >> well? >> > > I do not believe there is an existing list, unless it's standard > practice to re-use this discussion group (paws@ietf.org). > > >> >> Nits >> >> - RFC 2616 has been obsoleted - the references should be updated. >> > > Updating to RFC 7231 > > >> >> - It would help to have an example of a ruleset in the definition in the >> Terminology section and perhaps for that definition to more strongly convey >> that it is a name in a namespace, and what that rule means is elsewhere. >> (Right now the definition says that the ruleset is the actual set of >> rules, not a name, and it made reading the protocol overview much harder >> than it needed to be). At the very least, pointing to the examples in >> section 9 early would help. >> > > See proposed text of Terminology above. > > >> >> - Is the document loosely borrowing UML, or are the diagrams used in >> section 4 of a format formally defined in some other RFC? A pointer to a >> definition of the format, or a brief description noting it's based on UML >> along with where the base types are defined would be useful. >> > > See proposed text of primitive types above. Do I need a reference to UML? > > >> >> - "One approach to manage spectrum sharing" is awkward. Would "One >> approach to managing spectrum sharing" or "One approach to the management >> of spectrum sharing" work? >> > > Thanks. Changing to "One approach to managing spectrum sharing" > > >> >> - There are several instances of "The Device needs to use the information >> to update its list". Consider clarifying 'needs to'. Should this have been >> MUST? >> > > These were changed based on comments from our AD (Pete), since they are > not a protocol requirement. > > >> - "The vertices MUST be defined in a counter-clockwise direction" assumes >> you are looking at them from above - please be explicit. >> > > Thanks. Adding clarification. > > >> >> - Section 9.1.2's first paragraph should say "FCC and ETSI" the same way >> 9.2.2 does. You could generalize that to "any particular set of >> authorities". >> > > Thanks for the suggestion. Changing both to "any particular set of > authorities". > > >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> > > > > -- > -vince > > > -- -vince --089e0122f5fa82e5bc04fe51b368 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

Thanks again.


On Tue, Jul 15, 2014 at 2:42 PM= , Robert Sparks <rjsparks@nostrum.com> wrote:
=20 =20 =20

On 7/8/14, 9:21 PM, Vincent Chen wrote:
Robert,

Thanks again for the review. I have place comments, questions, suggested text inline for each of your comments.
Please take a look.
I'll be in Toronto if you want to talk about any of these.

Still trying to d= ecide if I can make it...
=C2=A0

Some small comments inline:


-vince


On Thu, Jul 3, 2014 at 10:28 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/= GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-paws-protocol-12
Reviewer: Robert Sparks
Review Date: 3 July, 2014
IETF LC End Date: 7 July, 2014
IESG Telechat date: 10 July, 2014

Summary: This document is not ready for publication as a Proposed Standard.

I apologize in advance if I've missed where one of the questions below is already answered. There's a lot to tak= e in here.

Major Issues

- The document says it "describes" the use of HTTP/= TLS as the transport for the protocol. Was it the intent to allow others? If not, the language should be firmed up.

The protocol messages are meaningful independent of the transport, so we did not want to prohibit others. It that frowned on?

Well, your security considerations, at least, should talk about what you require of the transport if you don't use TLS. You're leani= ng heavily on TLS for things like server authentication for example.
=

Acknowledged.
=C2=A0

=C2=A0

- The document still says "TBD Define message format&quo= t; in the section on Listing Servers. I understand from reading the list that what the document is going to say about Listing Servers is going to change (to not include how you talk to them?). This change needs to be finished before the document can be reviewed for completeness.

Noted. Will ask again on the list.
=C2=A0

- It's not clear when a server should use the HTTP level redirection discussed in section 7 vs the databaseChange mechanism in the protocol's responses. There should be some discussion about what the Device should do when the databaseChange mechanism results in a redirect loop.

Thanks for pointing this out. I propose removing the HTTP-level 301 Moved Permanently mechanism and only have the databaseChange mechanism.
The group will have to chew on this I guess. You can't forbid HTTP-level 3xx responses, and you still want well defined application behavior when they're received.
=
I see about not forbidding 3xx respo= nses. Perhaps just clarification that the preferred mechanism is databaseCh= ange.
=C2=A0


Proposed modified text in Section 4.1:
=C2=A0 =C2=A0A Database MAY indicate that its URI will= be changing by including
=C2=A0 =C2=A0the URI of one or more alternate database= s (See DbUpdateSpec
=C2=A0 =C2=A0(Section 5.7)) in its responses to a Devi= ce. =C2=A0Before a Database
=C2=A0 =C2=A0ceases operation, for example, it MUST in= clude DbUpdateSpec in its
=C2=A0 =C2=A0responses to notify Devices. =C2=A0A Devi= ce will update its preconfigured
=C2=A0 =C2=A0list of databases to replace (only) its e= ntry for the responding
=C2=A0 =C2=A0Database with the URIs of the alternate databases; the list of
=C2=A0 =C2=A0alternate databases does not affect any o= ther entries. =C2=A0Note that the
=C2=A0 =C2=A0ordering of databases in the list does no= t imply any preference and
=C2=A0 =C2=A0does not need to remain the same for ever= y request. =C2=A0The Device
=C2=A0 =C2=A0SHOULD detect infinite redirection loops;= if a suitable database
=C2=A0 =C2=A0cannot be contacted, the Device MUST trea= t this as equivalent to a
=C2=A0 =C2=A0response indicating no available spectrum= .
=C2=A0=C2=A0
=C2=A0

- The document needs to be clear where the primitive types (like string, float, and integer) in the UML-ish diagrams in section 4 are defined. I'm guessing from context that you're assuming the definitions in RFC4627. If that's true, there are several places that you talk about string where your text should change. RFC4627 says string is UNICODE, and may be encoded many ways (see section 3 of that document). If your intent is to restrict all strings to UTF-8 encoding say that, and adjust the text you currently have that mentions UTF-8. (The various places where you say a string MAY contain UTF-8 do not make sense - if you're assuming the encoding is UTF-8 and trying to reinforce that there may be non-ASCII range UTF-8 here, say that explicitly). There are other related phrases that don't make sense such as where you say things like "= The length of the string MUST NOT exceed 64 US-ASCII characters."

OK. Specified UTF-8 and removed meaningless statements.

Proposed added text in Section 4:<= /font>

=C2=A0 =C2=A0The parameter tables in this section and Protocol Parameters
=C2=A0 =C2=A0(Section 5) are for reference and contain= the name of each parameter,
=C2=A0 =C2=A0the data type of each parameter, and whet= her the existence of the
=C2=A0 =C2=A0parameter is required for the protocol transaction in question. =C2=A0The
=C2=A0 =C2=A0diagrams are loosely based on UML, and th= e data types are defined
=C2=A0 =C2=A0either in Protocol Parameters (Section 5)= or are one of the following
=C2=A0 =C2=A0primitive or structured types:

=C2=A0 =C2=A0string =C2=A0A string, as defined by The = JavaScript Object Notation (JSON)
=C2=A0 =C2=A0 =C2=A0 Data Interchange Format [RFC7159]= , restricted to the UTF-8
=C2=A0 =C2=A0 =C2=A0 encoding.

=C2=A0 =C2=A0int =C2=A0A number, as defined by The Jav= aScript Object Notation (JSON)
=C2=A0 =C2=A0 =C2=A0 Data Interchange Format [RFC7159]= , without a fractional or
=C2=A0 =C2=A0 =C2=A0 exponent part.

=C2=A0 =C2=A0float =C2=A0A number, as defined by The J= avaScript Object Notation (JSON)
=C2=A0 =C2=A0 =C2=A0 Data Interchange Format [RFC7159]= .

=C2=A0 =C2=A0boolean =C2=A0A boolean, as defined by Th= e JavaScript Object Notation
=C2=A0 =C2=A0 =C2=A0 (JSON) Data Interchange Format [R= FC7159].

=C2=A0 =C2=A0list =C2=A0A structured type the represen= ts a list of elements, as defined
=C2=A0 =C2=A0 =C2=A0 by The JavaScript Object Notation= (JSON) Data Interchange Format
=C2=A0 =C2=A0 =C2=A0 [RFC7159] array type. =C2=A0For e= ach list parameter, its diagram and
=C2=A0 =C2=A0 =C2=A0 description include a reference t= o the data type its list
=C2=A0 =C2=A0 =C2=A0 elements. =C2=A0The diagram notat= ion and description may include
=C2=A0 =C2=A0 =C2=A0 additional constraints, such as m= inimum or maximum number of
=C2=A0 =C2=A0 =C2=A0 elements.

=C2=A0 =C2=A0NOTE: All parameter names are case sensit= ive. =C2=A0Unless stated
=C2=A0 =C2=A0otherwise, all string values are case sen= sitive.


- The descriptions of messages in section 4 all contain *other:any. None of those are reflected in the concrete schema of section 6. Should they be?

This was intended to be capture by the note in Section 6:

=C2=A0 =C2=A0NOTE: In general, all= messages defined in this section are extensible
=C2=A0 =C2=A0by adding additional properties to support ruleset-specific and
=C2=A0 =C2=A0database-specific requirements. =C2=A0In all cases, the Device or Database
=C2=A0 =C2=A0MUST ignore any param= eter it does not understand.
=C2=A0

- The INIT_RESP description requires one or more RulesetInfo objects. What is a database supposed to do if it has no rulesets to return (possibly because it doesn't have anything overlapping with the list of ruleset IDs listed in the DeviceDescriptor in the INIT_REQ.). Should this have been 0..* (along with the corresponding change to the text), or is there an Error that the database should return when this happens. If the latter, it would be good to call it out in 4.2.2.

This was indicated in the prior section for INIT_REQ, but propose adding the following as first paragraph:

=C2=A0 =C2=A0The initialization response message commu= nicates database parameters
=C2=A0 =C2=A0to the requesting device. =C2=A0This resp= onse is returned only when there
=C2=A0 =C2=A0is at least one ruleset. =C2=A0Otherwise,= the Database returns an error
=C2=A0 =C2=A0response, as described in INIT_REQ (Secti= on 4.2.1).

=C2=A0

- Section 4.4 talks about returning OUTSIDE_COVERAGE when the location specified in the request is outside the regulatory domain (could that be domains?) supported by the database. The sections on init and registration (4.2 and 4.3) don't have this discussion. Should they?

Yes. Added to those requests. Thanks.
=C2=A0

- A databaseChange (at least as described in 4.4) can provide one or more alternate database URIs, affecting the Device's configuration. When there's more than one, i= s there any preference to what order the Device should try to use them in? Is there any expectation that they will give the same answers to a given request? If not, do you want to say anything about discouraging devices from asking all the databases it knows about to find an answer it likes best?

In general, there should be no difference in answers, because each Database must also conform to the regulatory rules. There is no significance implied by the list ordering. On the other hand, I don't think we need language discouraging devices from asking multiple databases, since they should have an understanding of the rules as well.

See proposed text above that contains:

=C2=A0 =C2=A0Note that the
=C2=A0 =C2=A0ordering of databases in the list does not i= mply any preference and
=C2=A0 =C2=A0does not need to remain the same for ever= y request.
=C2=A0

- If the requirements to act as if there is no available whitespace when you can't reach a Listing Server remain i= n the document, the security considerations should call out that any attack that would prevent reaching a Listing Server would result in all devices relying on that Listing Server ceasing their use of any whitespace.

Thanks. Added.
=C2=A0

- Please check the description of 'timeRange' in sect= ion 5.9 (SpectrumSpec). I think you meant to say "in which there is _NO_ available spectrum".

Thanks for the catch!
=C2=A0

- The definition of SpectrumProfile (section 5.12) needs clarification. Is this allowed?
=C2=A0 "profiles" : [
=C2=A0 =C2=A0 {"hz": 5.18e8, "dbm": 30.0 = },
=C2=A0 =C2=A0 {"hz": 5.24e8, "dbm": 37.0 = }
=C2=A0 ]
If so, what does it mean? Do I do linear interpolation between points (33.5 dbm (~2.25 watts) at 521Mhz)?
Similarly, does this specify a ramp up and then back down? (shaped like a ^)?
=C2=A0 [
=C2=A0 =C2=A0 {"hz": 5.18e8, "dbm": 30.0 = },
=C2=A0 =C2=A0 {"hz": 5.21e8, "dbm": 33.5 = },
=C2=A0 =C2=A0 {"hz": 5.24e8, "dbm": 30.0 = }
=C2=A0 ]
If not, what text disallows it?

This is explicitly allowed. We changed the encoding to allow this. Propose modifying the first paragraph of =C2=A05.12 to the following:<= /div>

=C2=A0 =C2=A0A spectrum profile is characterized by an ordered list of (frequency,
=C2=A0 =C2=A0power) points that represents the shape o= f maximum permissible power
=C2=A0 =C2=A0levels over a range of frequencies as a piecewise linear curve.

Also add after the list of constraints:

=C2=A0 =C2=A0NOTE: This encoding allows presentation= of "ramps" where the slope of
=C2=A0 =C2=A0a line segment may be finite and non-ze= ro.



- You are using the schema language defined in draft-zyp-json-schema to define your message format. That makes it a normative reference. The draft is expired - are there plans to progress it?

Yikes. The intent is not to define a strict, formal schema, but just to have a way of defining the messages in a concise fashion.
Do you have a recommendation of what to do here? Are the descriptions self-explanatory enough? or do I have to define
the "schema language".
Check with your AD on the best way = to handle this.

Acknowledged
=C2=A0

=C2=A0

- Something needs to talk about case-sensitivity of the various protocol elements. JSON-RPC says that member names are case sensitive and is otherwise silent. The string "sensitive" doesn't appear in RFC4627. So, you = have an example that says "authority":"us". Is th= at the same as "authority":"US", and where does the spec= answer that question? My read of JSON-RPC says that "authority"= :"us" and "Authority":"us" are _not_ the same t= hing, and that the second would not be a recognized property of a RulesetInfo object.

You're right. See above propos= ed text defining the primitive types.
=C2=A0

Minor Issues

- I'm not finding where you define the protocol version. = I see "1.0" in the json examples in section 6. Where = is it specified? Within a given method, the only extension point I find other than changing the protocol version is the *other concept in messages, which MUST be ignored when either side doesn't understand them. So there should be some discussion about what kind of change would require the protocol version number to change. Suppose you wanted to allow batching requests from several slaves into one request to the database (similar to AVAIL_SPECTRUM_BATCH_REQ but allowing a list of DeviceDescriptors perhaps). Does this require a new protocol version, or is it just a new request type in this version? If you think it's a new request-type, should there be a request and response type and/or method registry? =C2=A0And yes, I see how you could do this with JSON-RPC batch, but if that's where you'd send this i= dea, why didn't you do AVAIL_SPECTRUM_BATCH_REQ that way? (Possibly related: I can't figure out what "The initialization message also represents extension points for database implementations or rulesets that require the explicit handshake." is trying to say. Can you rephrase that more simply?)

Good point. Propose adding a new section:

4.2. =C2=A0PAWS Version

=C2=A0 =C2=A0PAWS version uses a "<major>.<minor>" numbering scheme to indicate
=C2=A0 =C2=A0versions of the proto= col. =C2=A0The protocol versioning policy is intended
=C2=A0 =C2=A0to allow the Device o= r Database to indicate the format of a message
=C2=A0 =C2=A0and its understanding= of PAWS functionality defined by that version.
=C2=A0 =C2=A0No change is made to = the version string for the addition of message
=C2=A0 =C2=A0components which only= add to extensible field values. =C2=A0The <minor>
=C2=A0 =C2=A0number is incremented= when the changes made to the protocol add
=C2=A0 =C2=A0functionalities (meth= ods), but do not change the existing
=C2=A0 =C2=A0functionalities. =C2= =A0The <major> number is incremented when incompatible
=C2=A0 =C2=A0changes are made to e= xisting functionality.

=C2=A0 =C2=A0The current PAWS vers= ion is "1.0".
=C2=A0

- It's not clear what it means to "support" a r= uleset. I infer that this means that the device has code that implements what's required by the name. Can you state tha= t explicitly? Does a Master device have to have this code? Could it simply be a box that only serves to answer requests from Slave devices? If so, why does it care what the rulesets actually are. If a slave can ask and a database can answer, should a master just shovel the bits, or is there a requirement that the master device be configured to handle a ruleset before a slave can ask about it?

OK. Propose update Terminology section to distinguish between "ruleset" and &quo= t;ruleset identifier":

=C2=A0 =C2=A0Ruleset: =C2=A0A rule= set represents a set of rules that governs the
=C2=A0 =C2=A0 =C2=A0 operation of = white space devices and Spectrum Databases. =C2=A0A
=C2=A0 =C2=A0 =C2=A0 regulatory au= thority can define its own set of rules or adopt an
=C2=A0 =C2=A0 =C2=A0 existing rule= set. =C2=A0When a Database or Device is said to "support a
=C2=A0 =C2=A0 =C2=A0 ruleset"= , it means that it contains out-of-band knowledge of the
=C2=A0 =C2=A0 =C2=A0 rules and tha= t its hardware and software implementations conform
=C2=A0 =C2=A0 =C2=A0 to those rule= s.

=C2=A0 =C2=A0Ruleset Identifier: = =C2=A0A ruleset can be identified by an IANA-
=C2=A0 =C2=A0 =C2=A0 registered id= entifier (see PAWS Ruleset ID Registry
=C2=A0 =C2=A0 =C2=A0 (Section 9.1)= ). =C2=A0When a Database or Device indicates it supports a
=C2=A0 =C2=A0 =C2=A0 ruleset ident= ifier, it means that it conforms to the rules
=C2=A0 =C2=A0 =C2=A0 associated wi= th that identifier. =C2=A0A regulatory authority can
=C2=A0 =C2=A0 =C2=A0 define and re= gister its own ruleset identifiers, or it can use a
=C2=A0 =C2=A0 =C2=A0 previously regis= tered identifier if it adopts an existing ruleset.
=C2=A0

- In the last paragraph of section 4.1 (before 4.1.1 starts), "If the Device is already operating" assum= es that the device could only be operating if it had previously contacted some database. The problem is that the device was able to reach a database at one point and now it can'= t reach any. =C2=A0It would read more clearly if you said that explicitly.

Proposed change:

=C2=A0 =C2=A0If the Device had p= reviously contacted a database to get available
=C2=A0 =C2=A0spectrum, but subse= quently fails to contact a suitable database, the
=C2=A0 =C2=A0spectrum the Device= is currently using can be used for as long as the
=C2=A0 =C2=A0spectrum data is va= lid; ...
=C2=A0

- Please point somewhere for a definition of the terms 'uncertainty' and 'confidence' (I suggest draft-ietf-geopriv-uncertainty). The GEOPRIV working group has gone through many iterations of disagreement about what these terms mean and how they should be used. For a taste, skim some of <https://mailarchive.ietf.org/arch/search/?email_list=3Dgeopriv&q=3Dunc= ertainty>. If you don't point to a hard definition, your implementation community will have to go through the same arguments.

Done. Although regulatory authorities may prescribe their own definitions.
=C2=A0

- Should the security considerations section talk about the risk of collisions in serialNumber (since it is the only required element in DeviceDescriptor, and isn't a particularly secret thing)? Is there any harm at the database if two devices innocently end up sending the same serial number (without providing any of the optional information that would otherwise disambiguate the devices)? Can a device learn anything useful about another device by spoofing it? Is it possible that in some regulatory realm, some devices would get more access than others, encouraging devices to ask about what their competition gets to do? Can harm be done by a device sending SPECTRUM_USE_NOTIFY messages claiming to be some other serial number (and perhaps manufacturer) maliciously? I think this needs more discussion than what RFC6953 contains.

Re: Available spectrum.
=C2=A0 The available spectrum depends on device type and location, not on serial number. Consequently, there is no advantage to spoofing, and there would be no additional information to be gained on spoofed devices.
So, you can't gain information about someone else by claiming to be their device type either?

Correct. There's no device-specific information.
=C2=A0


=C2=A0 If, in the futur= e, there is some regulatory realm that would set up rules differently, then I think security considerations would be extended to handle those cases.

Re: SPECTRUM_USE_NOTIFY
=C2=A0 I suppose this depends on the specific regulatory domains (or database implementations) that require it. Currently there is no harm, since notifications do not change the available spectrum answers that the Database returns to devices.

So should I add these statements to the Security Considerations section?
Consider calling out the possibility of SPECTRUM_USE_NOTIFY messages that are fraudulent (and perhaps how client authentication might protect against them)?

Acknowledged.
=C2=A0

=C2=A0

- The use of the "id" parameter from JSON-RPC deser= ves more discussion. The JSON-RPC spec allows it to be string, numeric (without a fractional part), NULL or missing. You've chosen to require it (since you're not using json-rpc notifications), and not allowing numeric values (why?). Are you making any other assumptions about what it should contain? I think you're assuming a level of uniqueness that would let you use the Batch mechanism in section 6 of JSON-RPC (otherwise, the HTTP request/response context is enough to associate the request and response and the id might as well be constant).

Purely as a practical matter, handling a known type is easier than multi-type. It should improve interoperability. Otherwise, its value remains opaque to the Database.

What is your recommendation here?<= /font>
Just adding a short description of the properties that you require of id.

=
Ack.
=C2=A0

=C2=A0

- Section 7 says a server can reject a GET with a 404 - wouldn't that have consequences for a later POST? Why wouldn't it use a 405?

Yes, it's supposed to be 405.<= /font>
=C2=A0

- The draft calls for the creation of a special list for review requests for the IANA assignments. This may be ok (mailing lists are easy to set up), but is there not an existing list that would serve the purpose just as well?

I do not believe there is an existing list, unless it's standard practice to re-use this discussion group (paws@ietf.org).
=C2=A0

Nits

- RFC 2616 has been obsoleted - the references should be updated.

Updating to RFC 7231
=C2=A0

- It would help to have an example of a ruleset in the definition in the Terminology section and perhaps for that definition to more strongly convey that it is a name in a namespace, and what that rule means is elsewhere. =C2=A0(Righ= t now the definition says that the ruleset is the actual set of rules, not a name, and it made reading the protocol overview much harder than it needed to be). At the very least, pointing to the examples in section 9 early would help.

See proposed text of Terminology above.
=C2=A0

- Is the document loosely borrowing UML, or are the diagrams used in section 4 of a format formally defined in some other RFC? A pointer to a definition of the format, or a brief description noting it's based on UML along wit= h where the base types are defined would be useful.

See proposed text of primitive types above. Do I need a reference to UML?
=C2=A0

- "One approach to manage spectrum sharing" is awkw= ard. Would "One approach to managing spectrum sharing" o= r "One approach to the management of spectrum sharing" work?

Thanks. Changing to "One appr= oach to managing spectrum sharing"
=C2=A0

- There are several instances of "The Device needs to us= e the information to update its list". Consider clarifying 'needs to'. Should this have been MUST?

These were changed based on comments from our AD (Pete), since they are not a protocol requirement.


- "The vertices MUST be defined in a counter-clockwise direction" assumes you are looking at them from above - please be explicit.

Thanks. Adding clarification.
=C2=A0

- Section 9.1.2's first paragraph should say "FCC an= d ETSI" the same way 9.2.2 does. You could generalize that to "any particular set of authorities".

Thanks for the suggestion. Changing both to "any particular set of authorities&qu= ot;.
=C2=A0

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



--
-vince




--
-vince
--089e0122f5fa82e5bc04fe51b368-- From nobody Fri Jul 18 13:38:19 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 872201A0146 for ; Fri, 18 Jul 2014 13:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.321 X-Spam-Level: * X-Spam-Status: No, score=1.321 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 S4fZ6yxK8yZA for ; Fri, 18 Jul 2014 13:38:11 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFD01A00C3 for ; Fri, 18 Jul 2014 13:38:11 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id im17so8515024vcb.3 for ; Fri, 18 Jul 2014 13:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m4JvXKzYze9NjK0yzu2GqrYzGIbQq3Mas9EaHvxwICg=; b=F1Apo20TtnkxTt/WCsRtziPMsB1R5CIq1/7och5LmHgVc7k3LQFJFYDp7fKX+iz4DS s7bxHMATR4NtmKmSyxnoPf01DukfPqUH36uh5kMFvoED/BuZMZtNtOaotsJ/IUMQfGjG /U2+b0NtlTjq+HhSUB9mv/FZLMOlqRGMy2HL2Ekvt+40b17PvL55IBjn78au5XLuZlRe aq+s0ZlBHKfuXUs63FiqCOYNnT5i67j+nsXaiEKNZVXgBj0cCIWaP8VaW1vJb22iHe/2 aT6HS90ZBixQgFo+o+0GH2o28Whu7SybxmBgKdqhsw1NW6whCnb6SjfAIjJTkZXDkWzG hrgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=m4JvXKzYze9NjK0yzu2GqrYzGIbQq3Mas9EaHvxwICg=; b=OXQ/ago6h1JTFanwQKV6TcYvVM4ShJQKRGO28wvMeau4ZEkqV3SydRzIeVmAjWjVqq q25i9DdkbHXDD9scGFPSURLw6aABTwl6htnVvIBCE8xl0vAc1jFopfP5fpZS9bCGTy50 D7MLHFjeQ59L0nu5gs96FCx5Qp2XwC/Nmq/YdfQjTaZLC16++zsrs/63hT4DULViNkQz gkn/MXoQu+tvL4cEB+oM7FDEwrlRayhGcBx11EhzZ/lSAPyVxTT+Hv/8M8/maDYvZufQ m4cNb2IFasXWPGS/dGeqomc4BSoXJ3aPBN3A47jW8sORNTLvmKCAIfN0CKp0ZDG6dSZJ qBaw== X-Gm-Message-State: ALoCoQk+sTgc6X8XIh6lQJYlNibKggChKYk6p7+R0VRyDeyjDhvxEcFY5Wz0cbVIm09CXivaflFe MIME-Version: 1.0 X-Received: by 10.52.232.200 with SMTP id tq8mr8130089vdc.32.1405715889980; Fri, 18 Jul 2014 13:38:09 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Fri, 18 Jul 2014 13:38:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Jul 2014 13:38:09 -0700 Message-ID: From: Vincent Chen To: Barry Leiba Content-Type: multipart/alternative; boundary=089e0122f5fa471f8f04fe7dbcc5 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/DUnDVvKQEq851E7wC2yzUrpW0Fo Cc: "paws@ietf.org" Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APP AD) 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: Fri, 18 Jul 2014 20:38:17 -0000 --089e0122f5fa471f8f04fe7dbcc5 Content-Type: text/plain; charset=UTF-8 Barry, Thanks again for the detailed comments. A couple issues remain unresolved: - How to describe JSON schema - Usage of "parameter" Will you be available for the PAWS session on Tues to discuss further? I've included additional comments/answers inline. On Mon, Jul 14, 2014 at 12:31 PM, Barry Leiba wrote: > Hey, PAWS folk. > As Pete has put the subject document on the 7 August telechat agenda, > though he still has it in "Waiting for AD Go Ahead" state, I decided > to review it now, rather than wait. I've found quite a list of > issues, from large to small, which I've sorted below into three > categories: > > "DISCUSS" are those that I would put in a DISCUSS ballot during IESG > Evaluation. I think they're errors in the document that need to be > corrected, or else things that need to be discussed and resolved. > > The most important in this category, and the only one I think will be > difficult to resolve, is how to specify the JSON payload formally. > > "COMMENT -- substantive" are those that I would put in the > non-blocking comments, but that I think are important to deal with, > and that I'd hope we'd have a discussion about if the authors think a > discussion is necessary. > > "COMMENT -- minor" are minor editorial issues that I think would be > better corrected, but that I'm not going to grump about further. > Discussion is always welcome, but should be pretty much unnecessary > for these. > > I hope it's useful to get these comments earlier, rather than later. > And, so, here they are, below. I've offered suggested text where I > could, and I hope that helps as well. > > Barry > > ======================= DISCUSS ======================= > > -- Section 4 -- > > o Device Registration (Section 4.3) MAY be used by the Master Device > and MAY be implemented by the Database, either as a separate > component or as part of the Available Spectrum Query (Section 4.4) > component. > > I don't think the first MAY is correct. If the database requires > registration, it is *not* optional for the Master Device to use it. I > think this needs some rework. The same is true with "Device > Validation". > Based on comments from our AD, we wanted to separate requirements for the protocol itself from database-specific and regulatory-domain requirements. Thus, from the protocol's perspective, it's a MAY. Having said that, the text can be clarified a bit. Suggestion: o Device Registration (Section 4.4) MAY be used by the Master Device and MAY be implemented by the Database. When implementing Device Registration, the Database MAY implement it either as a separate component or as part of the Available Spectrum Query (Section 4.5) component. > > This list also mixes "used", "supported", and "implemented", without > making all the issues clear. If something MAY be used, does that mean > it's optional to implement? If it MUST be supported, what does that > say about its use? And what's the difference between "supported" and > "implemented"? > Agreed it's confusing. Replaced "supported" by "implemented", since that's what's intended. The work "supported" still exists in the doc when referring to "supporting a set of rules" or "rulesets". There's also an added not in the Terminologies section. > > I strongly suggest that, if you're going to say that, you make it all > clear, as to both implementation/support and use. The note after the > list that says that some things are obvious... nah, one of it is > obvious. > > -- Section 4.1 -- > > A Database MAY indicate that its URI will be changing by including > the URI of one or more alternate databases (See DbUpdateSpec > (Section 5.7)) in its responses to a Device. Before a Database > ceases operation, for example, it MUST include DbUpdateSpec in its > responses to notify Devices. > > I don't understand how the MAY and MUST are consistent with each > other. Can you explain or fix it? > Ah, I see....MAY refers to the Database's ability to change its URI. Reword: A Database MAY change its URI, but before it changes its URI, it MUST indicate so by including the URI of one or more alternate databases (See DbUpdateSpec (Section 5.7)) in its responses to a Device. Before a Database ceases operation, for example, it MUST include DbUpdateSpec in its responses to notify Devices. > > -- Section 4.1.1 -- > > 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 > > Here's another 2119 conflict. It doesn't make sense to have a MUST > for the time period if doing it at all is a SHOULD. Please sort this > one out as well. > You're right. Changed MUST to SHOULD. > > -- Section 4.2 > > A Master Device SHOULD use the initialization procedure to exchange > capability information with the Database whenever the Master Device > powers up or initiates communication with the Database. > > But in Section 4 you said "Initialization (Section 4.2) MAY be used by > the Master Device," and now you're saying "SHOULD"? You see why I'm > on about the 2119 inconsistencies? > The MAY in Section 4 is an oversight. Changed to SHOULD. > > When a Master Device is > configured manually with these parameterized-rule values, it does not > need to use the initialization procedure. > > Dos that mean that when it's not configured with them, it *does* need > to? In other words, is this really a "MUST use initialization unless > it's pre-configured with the values" thing? > Thanks. You're right. Reworded: When a Master Device is not configured manually with these parameterized-rule values, it MUST use the initialization procedure. > -- Section 4.2.1 -- > > deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is > REQUIRED. If the Database does not support the device or any of > the rulesets specified in the device descriptor, it MUST return an > error with the UNSUPPORTED (Table 1) code in the error response. > If the device descriptor does not contain any ruleset IDs, the > Database SHOULD return a list of RulesetInfo (Section 5.6) > parameters for each ruleset it supports at the specified location. > > What this says to me is that the Master Device uses an empty list of > rulesets to query the list of supported rulesets. So: how does this > work if the Database does not return its list of rulesets? > Presumably, the Master Device did this because it needs the list, and > then it didn't get it. What does it do now? > > Also, this is worded a bit confusingly. The list is REQUIRED, so it's > not true that the Database SHOULD return a list. What you mean to > tell us is what the Database SHOULD include in the list. I think it's > really awkward to try to say that here in the query, rather than in > the next section in the response. > > Try this: > > OLD (Section 4.2.1) > deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is > REQUIRED. If the Database does not support the device or any of > the rulesets specified in the device descriptor, it MUST return an > error with the UNSUPPORTED (Table 1) code in the error response. > If the device descriptor does not contain any ruleset IDs, the > Database SHOULD return a list of RulesetInfo (Section 5.6) > parameters for each ruleset it supports at the specified location. > NEW > deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is > REQUIRED. If the device descriptor does not contain any ruleset > IDs, the Master Device is asking the Database to return a list of > RulesetInfo (Section 5.6) parameters for each ruleset it supports > at the specified location. > END > > OLD (Section 4.2.2) > rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be > included in the response. Each RulesetInfo parameter corresponds > to a ruleset supported by the Database and is applicable to the > location specified in the INIT_REQ (Section 4.2.1) message. If > the Device included a list of ruleset IDs in the DeviceDescriptor > parameter of its INIT_REQ message, each RulesetInfo parameter in > the response MUST match one of the specified ruleset IDs. > NEW > rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be > included in the response. Each RulesetInfo parameter corresponds > to a ruleset supported by the Database and is applicable to the > location specified in the INIT_REQ (Section 4.2.1) message. > > If the Device included a list of ruleset IDs in the DeviceDescriptor > parameter of its INIT_REQ message, each RulesetInfo parameter in > the response MUST match one of the specified ruleset IDs. > > If the DeviceDescriptor did not contain any ruleset IDs, the > Database SHOULD include in the list the RulesetInfo parameters for > each ruleset it supports at the specified location. > > If the Database does not support the device or any of the rulesets > specified in the DeviceDescriptor, it MUST instead return an > error with the UNSUPPORTED (Table 1) code in the error response. > END > Thanks for the suggestions. Done. > > -- Section 4.3.2 -- > > If the Database accepts the > registration for none of the rulesets it supports, the Database MUST > return the NOT_REGISTERED error (See Error Codes (Section 5.17)). > > I can't follow this sentence at all. Do you mean, "If the Database > does not accept the registration for any of the rulesets" ? Or do you > mean something else? Can you re-word this, please? > Heh, I was afraid "any" is ambiguous. "If the Database does not accept the registration for any of the rulesets": - Does that mean if, out of 3, one was not acceptable, it passes the "any" test? - Or does that mean "none of them" Hence...the attempt at being more precise by using "none". > -- Section 5.8 -- > > name: The display name for a database. It MAY contain UTF-8. > > What about all the other strings whose content format is unspecified? > Are they allowed to contain UTF-8? If not, what *do* they contain? > > I see that the Gen-ART review mentioned this also, and the response > will be to specify that all strings are encoded in UTF-8. Good. > Done. > > -- Section 6 -- > How is the reference to JSON Schema [I-D.zyp-json-schema] not > normative, when the 6.x subsections quite depend upon the > understanding of the schema format that it describes? > > I see that the Gen-ART review mentioned this also, but the response is > quite troubling. No, the mechanism you're using is not sufficiently > self explanatory. I understand it -- I do -- but I had to figure it > out (I decided not to go look at the Zyp draft), and we can't assume > that arbitrary implementors will get it right. We need a well defined > way to explain how JSON objects are constructed. And, unfortunately, > the JSON working group chose *not* to take on a work item for this > (which I was pushing for). > > We have at least three proposals (apart from Zyp, there's Newton > (draft-newton-json-content-rules), and there's the mechanism that I > proposed, which is used in Section 6.2 of RFC 7071), but nothing > that's being taken forward as a standard yet. > I guess the 3rd option is to just describe by example. Hopefully we can discuss this at the F2F. > > -- Section 6.6.2 -- > The schema is missing the optional databaseChange property. > Done > > -- Section 6.7.1 -- > The schema is missing the optional masterDeviceDesc property. > Done > > -- Section 6.8.11 -- > The schema says that both properties are optional, but Section 5.14 > says that they're both required. > Done > > -- Section 6.8.13 -- > The schema says that rulesetInfo is optional, but Section 5.9 says > that it's required. > Done > > -- Section 7 -- > > The Database MAY redirect a PAWS request by returning a HTTP 3xx > response (as defined by HTTP/1.1 [RFC2616]). > ... > Since the Device may communicate > with a Database (which it authenticated) without user interaction, > when the response code is 301 (Moved Permanently), the Device MAY > redirect without asking a user for confirmation (note that this > represents an exception to the HTTP/1.1 [RFC2616] requirements for > HTTP POST methods). > > The references to RFC2616 need to change to RFC7231, now that 2616 is > obsolete. > I see that the Gen-ART review mentioned this also, and you plan to > change the reference. This should help you get that right: > > The change to 7231 also means that the note about the second citation > can change. 2616 said this about redirecting a POST: > > --- RFC 2616 --- > If the 301 status code is received in response to a request other > than GET or HEAD, the user agent MUST NOT automatically redirect the > request unless it can be confirmed by the user, since this might > change the conditions under which the request was issued. > ---------------- > > That advice has changed in 7231: > > --- RFC 7231 --- > Automatic redirection needs to done with > care for methods not known to be safe, as defined in Section 4.2.1, > since the user might not wish to redirect an unsafe request. > ---------------- > > In my view, that means that the parenthesized note in the quote above > can be removed from this document. I also suggest using a section > number in the citation, as you're citing a big document. So... > > OLD > The Database MAY redirect a PAWS request by returning a HTTP 3xx > response (as defined by HTTP/1.1 [RFC2616]). > NEW > The Database MAY redirect a PAWS request by returning a HTTP 3xx > response (as defined by HTTP/1.1 Semantics and Content [RFC7231], > Section 6.4). > END > > OLD > Since the Device may communicate > with a Database (which it authenticated) without user interaction, > when the response code is 301 (Moved Permanently), the Device MAY > redirect without asking a user for confirmation (note that this > represents an exception to the HTTP/1.1 [RFC2616] requirements for > HTTP POST methods). > NEW > Since the Device may communicate > with a Database (which it authenticated) without user interaction, > when the response code is 301 (Moved Permanently), the Device MAY > redirect without asking a user for confirmation, even though it > is in response to an HTTP POST request. > END > Done for the above. > > -- Section 8.2 -- > > The parameter name SHOULD be lowerCamelCase. > > Why "SHOULD"? How does it affect interoperability? Wouldn't > "Parameter names use lowerCamelCase by convention." work fine? > Agreed. Changed. > > -- Section 9 -- > First, and most importantly, the IANA review interpreted your text to > say that the registration policies are Expert Review; I interpret your > text to say that they're Specification Required. Yet Vince replied to > the IANA review without correcting that. Which policy do you intend? > If it is Specification Required, you need to clear that up with IANA. > Or just deal with my other comments in this section, and that might > happen anyway. > Thanks for pointing that out. I'll add to the comment. > > The text in this section seems to be commonly copied from somewhere. > Perhaps you could tell me whence you copied it, so we can make an > effort to stop people from doing that. > I don't remember precisely, but I recall I was reviewing some OAUTH docs at the time. RFC6749 > > The first paragraph is entirely unnecessary: please just remove it. > Done > > The second paragraph and the list is fine, and the third is mostly OK, > except for the URI. You'll need to ask IANA how they want to receive > requests (by email or through a web URI), and specify that in > paragraph 3 instead of what's there now. > FYI. From http://www.iana.org, you can navigate to a "Protocol Registration Forms" page to submit requests for new assignments. > > The fourth paragraph really needs to be entirely re-thought: it is not > how IANA does expert review in the first place, and we shouldn't be > telling IANA how to run their process in the second place. > > The fourth paragraph should say that all registries use the > Specification Required policy [RFC5226], with a Designated Expert > appointed by the IESG. It should note that instructions to the DE as > to what she should look for and consider in evaluating a request are > given below in the descriptions of each registry. It should say that > the DE should take advice from the community through the designated > mailing list, and that is why the registrant should post to the > mailing list before formally requesting the registration from IANA. > All the rest of the mechanics are part of IANA's process, and should > not be specified here. > Thanks. Proposed text: All registries use the Specification Required policy [RFC5226], with a Designated Expert appointed by the IESG. Specific criteria that the Designated Expert should use in assessing registrations are given below in the description of each registry. The Designated Expert should take advice from the community through the paws@ietf.org mailing list, and the registrant is encouraged to post to the mailing list before formally requesting the registration from IANA. The intention is that new registrations will be accompanied by a published specification. But in order to allow for the allocation of values prior to publication of the specification, the Designated Expert can approve allocations once it seems clear that the specification will be published. Is the last part (about allocation before publication of spec) also process that should be omitted? Or are they instructions to the DE? > One question: does it make sense for the review list to be a separate > list, or couldn't the WG mailing list be reused for that purpose? > I don't think there's a reason not to. Just didn't know the process. Will propose just to use paws@ietf.org. > > > ======================= COMMENT -- substantive ======================= > > General: > You appear to sometimes use "parameter" to refer to a structure (such > as GeoLocation) and also the fields within the parameter (see Section > 5.1, for example). I find this confusing, and suggest that you do not > use the same term for both. > You're right. Perhaps, when referring to a structure, I should use "object" in the JSON sense? > > -- Section 3 -- > In step 4, should this not say a word or two about what message it > responds with? Might it respond, "To be, or not to be; that is the > question?" Or is there an expected sort of response? > Changed. > > Step 5 is the first mention of registration. A reference to where > that process is explained would be useful here (as this step doesn't > seem to fit into the flow). > > In step 7, this is the first mention of a Slave Device, so referring > to "the Slave Device" doesn't make sense. Maybe you want something > like, "If a Slave Device has made a request to the Master Device, the > Master Device may verify..." ? > > It's not clear how step 7 relates to steps 6 and 8. > Thanks. Reworded these steps: 6. The Master Device sends an available-spectrum request message to the Database. The message may be on behalf of a Slave Device that made a request to the Master Device. 7. If the Master Device is making a request on behalf of a Slave Device, the Master Device may verify with the Database that the Slave Device is valid. 8. The Database responds with an available-spectrum response message in the body of the HTTP response. > > In step 10, might it also send an error, refusal, or whatever? Or are > those all considered acknowledgment messages? > This should be considered a notification (fire and forget) call from the Device. Suggested rewording: 9. The Master Device may send a spectrum-usage notification message to the Database. The notification is purely informational. 10. If the Database receives a spectrum-usage notification message, it responds by sending the Master Device a spectrum-usage acknowledgement message. Since the notification is purely informational, the Master Device does not need to process the Database response. > Hm, it seems that steps 5 and 7 are actually explained in the > paragraph after the numbered steps. So do they really belong in the > numbered steps at all? > The numbered steps are supposed to correspond to the order in which these steps happen, so I think it's important to leave them there. > > -- Section 5.1 -- > > point: If present, it indicates that the GeoLocation represents a > point. > ... > region: If present, it indicates that the GeoLocation represents a > region. > > These make it sound as though these are boolean. It took me a bit to > realize that the values of each of these is actually a structure. I > think you mean this: > > NEW > point: If present, it specifies the GeoLocation as a point. > ... > region: If present, it specifies the GeoLocation as a region. > END > Done. > > -- Section 8.3 -- > Please get rid of the MAY in the first sentence. > Done. > > If an > appropriate category does not exist, it can use values in a different > range. > > What is the antecedent for "it"? It looks like it's "an appropriate > category", but that's clearly not right. Please fix. > Done. Rewording: If an appropriate category does not exist, a value from a different range may be used. > > ======================= COMMENT -- minor ======================= > > A small point in the header: > "iconectiv (formerly Telcordia Interconnection Solutions)" > I think it's fine to put that in the "Authors' Addresses" section, but > the header should just say "iconectiv". I realize that takes a little > inconvenient massaging of the XML, and probably isn't worth the > trouble for the I-D. Might just put that in an RFC Editor note.... > I'll take a look later :) > > General: > I like that your citations include the document names, as well as the > RFC numbers; thanks! It would be better if you put quotation marks > around the document names, to distinguish them from being part of your > text. > Done. > > -- Section 1 -- > > The document describes the use of HTTP/TLS as > transport for the protocol. > > This hits what's rather a peeve of mine: HTTP is not a transport > protocol; the transport protocol you're using is TCP. > > I'd be happier if you said something like this: > > OLD > This specification defines an extensible protocol to obtain available > spectrum from a geospatial database by a device with geo-location > capability. > NEW > This specification defines an extensible protocol, built on top of > HTTP and TLS, to obtain available spectrum from a geospatial database > by a device with geo-location capability. > END > > ...and then eliminate that last sentence. See also comments on > Section 4 and Section 7. > Done. > -- Section 2.2 -- > > I suggest this: > > OLD > EIRP: Effective isotropically radiated power > ETSI: European Telecommunications Standards Institute > FCC: Federal Communications Commission > NEW > ETSI: European Telecommunications Standards Institute > > FCC: The U.S. Federal Communications Commission > END > > ... and then in Section 9.2.2.7, spell out EIRP, as it's only used in > that one place. > Done. > > -- Section 3 -- > Little grammar nit: > 1. The Master Device obtains (statically or dynamically) the URI > for a Database appropriate for its location to send subsequent > PAWS messages. > > Make it "location, to which to send". > Done. > > -- Section 3.1 -- > > These > requirements may be complex and involve device behavior that are not > easily parameterized. > > "Device behaviour" is singular, so "that is not", please. > Done. > > -- Section 4 -- > > Usage pet peeve: please change "comprise" to "compose", in the one > place it's used. > > HTTPS Binding (Section 7) describes the use of > HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and > optional device authentication. > > Please use "transferring", instead of "transporting", to avoid calling > HTTP a transport. > Done. > > -- Section 4.1.1 -- > > TBD Define message format > > You missed something here. Jus' sayin'. > Acknowledged. > > -- Section 4.4.1 -- > > Rulesets may mandate that it be the Device's > current location or allow it to be an anticipated location. > > This is probably as good a place as any to ask this: is there any > validation of the geo-location at all? If not, can such a mandate > have any real teeth? What is this *really* saying? > There is no requirement for Database to validate. Devices typically go through separate certification (e.g., FCC) to ensure they conform to the rules. Likewise, Databases may also need to be certified, depending on regulatory requirements. > -- Section 4.4.5 -- > The table says that "location" is required, but the text says it's not > always required. The table should say "see description". > Done. > > -- Section 4.5 -- > > Typically, a Slave Device needs a Master Device to ask the Database > on its behalf for available spectrum > > "Typically"? Isn't that the *definition* of a Slave Device? > Oops. Done. > > -- Section 5.5 -- > > All contact information MUST be expressed using the structure defined > by the vCard Format Specification [RFC6350]. > > I think it's best to include both references here, like this: > > NEW > All contact information MUST be expressed using the structure defined > by the vCard Format Specification [RFC6350], encoded in JSON [RFC 7095]. > END > Done. > > -- Section 5.7 -- > The subsections explain what additional "data" field each error might > use, but there are only sections for the ones that use the "data" > field. One has to assume that the absence of a subsection means that > the "data" field is not used for that error. It would be better to > say that in the table. I suggest adding one sentence to each error > description in the table except for -104, -105, and -201, as follows: > "This error does not use any additional data." > Done. > > -- Section 5.11 -- > The third table should be labelled "SpectrumProfilePoint". > Done. > > -- Section 5.12 -- > The second table should be labelled "SpectrumProfilePoint". > Done. > > -- Section 5.17.1 -- > > When the error code is OUTSIDE_COVERAGE, the Database MAY include an > ErrorData element within its as the "data" field > > You're missing the words "Error response" after "within its". > Done. > > -- Section 7 -- > > This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS > [RFC2818] as the transport mechanism for the PAWS protocol. > > As I've noted earlier, please say "as the transfer mechanism". Also, > it's really weird to describe the document in the same words as the > document title. I suggest just deleting the document title in this > case. This also applies to Section 10.1. > Done. > > -- Section 9.1.2 -- > The first paragraph was obviously written before the ETSI info was > added. Please adjust it accordingly. (I see that the Gen-ART review > mentioned this too, and it will be fixed.) > Done. > > You might add instructions to the DE with respect to handling > prefixes. Suppose, for example, I wanted to register something > starting with "fcc". Or perhaps with the initials of an organization > that hasn't yet registered anything, but reasonably might. > Done. > > -- Section 10.1 -- > The doubled "HTTP over TLS" comment applies here. Also, it's not at > all clear, when you say "these checks MAY be omitted," exactly what > checks you're saying may be omitted. > Verification of the SANs. Added some text. > > In particular, the > validation path of the certificate must end in one of the client's > trust anchors, even if that trust anchor is the Database certificate > itself. A Master Device should allow for the fact that a Database > can change its certificate authorities (CAs) over time. > > Just a question here: did the WG consider DANE at all? > It was brought up, but not discussed further. > > Another question: is it really necessary to cover this stuff here? > Isn't it in 2818? > I believe the WG thought it would be good to restate. > > -- Section 10.3 -- > > Using HTTP over TLS, messages protected by appropriate cypher suites > are also protected from eavesdropping or otherwise access by > unauthorized parties en route. > > What does "or otherwise access" mean? Apart from the grammar problem: > it would be better to say something substantive here, rather than > something vague. > Changed to "or otherwise unrestricted reading". > > -- Section 11 -- > I wouldn't usually comment on a "Contributors" section, but it seems > odd to me to cite abandoned and long-expired drafts as references. It > might be better just to include the draft names, without making them > references. No? You're not actually suggesting that people read > them, just thanking the authors for their contributions. > Done. > > ============================================== > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --089e0122f5fa471f8f04fe7dbcc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry,

Thanks again for the detailed co= mments. A couple issues remain unresolved:
=C2=A0- How to describ= e JSON schema
=C2=A0- Usage of "parameter"
Will you be available for the PAWS session on Tues to discuss further?

I've included additional comments/answers inline.<= /div>



On Mon, Jul 14, 2014 at 12:31 PM, Barry Leiba <barryleiba@computer.o= rg> wrote:
Hey, PAWS folk.
As Pete has put the subject document on the 7 August telechat agenda,
though he still has it in "Waiting for AD Go Ahead" state, I deci= ded
to review it now, rather than wait. =C2=A0I've found quite a list of issues, from large to small, which I've sorted below into three
categories:

"DISCUSS" are those that I would put in a DISCUSS ballot during I= ESG
Evaluation. =C2=A0I think they're errors in the document that need to b= e
corrected, or else things that need to be discussed and resolved.

The most important in this category, and the only one I think will be
difficult to resolve, is how to specify the JSON payload formally.

"COMMENT -- substantive" are those that I would put in the
non-blocking comments, but that I think are important to deal with,
and that I'd hope we'd have a discussion about if the authors think= a
discussion is necessary.

"COMMENT -- minor" are minor editorial issues that I think would = be
better corrected, but that I'm not going to grump about further.
Discussion is always welcome, but should be pretty much unnecessary
for these.

I hope it's useful to get these comments earlier, rather than later. And, so, here they are, below. =C2=A0I've offered suggested text where = I
could, and I hope that helps as well.

Barry

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DISCU= SS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-- Section 4 --

=C2=A0 =C2=A0o =C2=A0Device Registration (Section 4.3) MAY be used by the M= aster Device
=C2=A0 =C2=A0 =C2=A0 and MAY be implemented by the Database, either as a se= parate
=C2=A0 =C2=A0 =C2=A0 component or as part of the Available Spectrum Query (= Section 4.4)
=C2=A0 =C2=A0 =C2=A0 component.

I don't think the first MAY is correct. =C2=A0If the database requires<= br> registration, it is *not* optional for the Master Device to use it. =C2=A0I=
think this needs some rework. =C2=A0The same is true with "Device
Validation".

Based on comments from our AD, we wanted to separate requirements for th= e
protocol itself from database-sp= ecific and regulatory-domain requirements. Thus, from
the protocol's perspective, it's a MAY= .

Having said that, the text can be clarified a bit. Suggestion= :

=C2=A0 =C2=A0o =C2=A0Device Registration (Section 4.4) MAY be used by = the Master Device
=C2=A0 =C2=A0 = =C2=A0 and MAY be implemented by the Database. =C2=A0When implementing Devi= ce
=C2=A0 =C2=A0 =C2=A0 Registration, the Databas= e MAY implement it either as a separate
=C2=A0 =C2=A0 =C2=A0 component or as part of the Available Spectrum Q= uery (Section 4.5)
=C2=A0 =C2=A0 =C2=A0 component.

=C2=A0

This list also mixes "used", "supported", and "imp= lemented", without
making all the issues clear. =C2=A0If something MAY be used, does that mean=
it's optional to implement? =C2=A0If it MUST be supported, what does th= at
say about its use? =C2=A0And what's the difference between "suppor= ted" and
"implemented"?

Agreed it's confusing. Replaced "supported" by &quo= t;implemented", since that's
what's intended. The work "supported" still exists in the= doc when referring to
"supporting a set of rules" or "= ;rulesets". There's also an added not in the
Terminologies section.
=C2=A0

I strongly suggest that, if you're going to say that, you make it all clear, as to both implementation/support and use. =C2=A0The note after the<= br> list that says that some things are obvious... nah, one of it is
obvious.

-- Section 4.1 --

=C2=A0 =C2=A0A Database MAY indicate that its URI will be changing by inclu= ding
=C2=A0 =C2=A0the URI of one or more alternate databases (See DbUpdateSpec =C2=A0 =C2=A0(Section 5.7)) in its responses to a Device. =C2=A0Before a Da= tabase
=C2=A0 =C2=A0ceases operation, for example, it MUST include DbUpdateSpec in= its
=C2=A0 =C2=A0responses to notify Devices.

I don't understand how the MAY and MUST are consistent with each
other. =C2=A0Can you explain or fix it?

Ah, I see....MAY refers to the Database's abil= ity to change its URI.=C2=A0Rewor= d:

=
=C2=A0 =C2=A0A Database MAY change its URI, but before it changes its = URI, it MUST
=C2=A0 =C2=A0indicate so by including the URI of one= or more alternate databases
=C2=A0 =C2=A0(See DbUpdateSpec (Section 5.7)) in its responses to a De= vice.
=C2=A0 =C2=A0Before a Database ceases operation, for exampl= e, it MUST include
=C2=A0 =C2=A0DbUpdateSpec in its responses to = notify Devices. =C2=A0
=C2=A0

-- Section 4.1.1 --

=C2=A0 =C2=A0When a Listing Server is used, the
=C2=A0 =C2=A0Device can save the database list and SHOULD contact the Datab= ase
=C2=A0 =C2=A0Listing Server periodically to update its list. =C2=A0The time= between
=C2=A0 =C2=A0such updates MUST be no longer than one week

Here's another 2119 conflict. =C2=A0It doesn't make sense to have a= MUST
for the time period if doing it at all is a SHOULD. =C2=A0Please sort this<= br> one out as well.

You're right. Changed MUST to SHOULD.
=C2=A0

-- Section 4.2

=C2=A0 =C2=A0A Master Device SHOULD use the initialization procedure to exc= hange
=C2=A0 =C2=A0capability information with the Database whenever the Master D= evice
=C2=A0 =C2=A0powers up or initiates communication with the Database.

But in Section 4 you said "Initialization (Section 4.2) MAY be used by=
the Master Device," and now you're saying "SHOULD"? =C2= =A0You see why I'm
on about the 2119 inconsistencies?

The MAY in Section 4 is an oversight. Changed to SHOULD= .
=C2=A0

=C2=A0 =C2=A0When a Master Device is
=C2=A0 =C2=A0configured manually with these parameterized-rule values, it d= oes not
=C2=A0 =C2=A0need to use the initialization procedure.

Dos that mean that when it's not configured with them, it *does* need to? =C2=A0In other words, is this really a "MUST use initialization un= less
it's pre-configured with the values" thing?
<= br>
Thanks. You're right. Reworded:

=C2=A0 =C2=A0When a Master Device is not
=C2=A0 =C2=A0configured manually with these pa= rameterized-rule values, it MUST use
=C2=A0 =C2=A0the initialization procedure.



-- Section 4.2.1 --

=C2=A0 =C2=A0deviceDesc: =C2=A0The DeviceDescriptor (Section 5.2) for the D= evice is
=C2=A0 =C2=A0 =C2=A0 REQUIRED. =C2=A0If the Database does not support the d= evice or any of
=C2=A0 =C2=A0 =C2=A0 the rulesets specified in the device descriptor, it MU= ST return an
=C2=A0 =C2=A0 =C2=A0 error with the UNSUPPORTED (Table 1) code in the error= response.
=C2=A0 =C2=A0 =C2=A0 If the device descriptor does not contain any ruleset = IDs, the
=C2=A0 =C2=A0 =C2=A0 Database SHOULD return a list of RulesetInfo (Section = 5.6)
=C2=A0 =C2=A0 =C2=A0 parameters for each ruleset it supports at the specifi= ed location.

What this says to me is that the Master Device uses an empty list of
rulesets to query the list of supported rulesets. =C2=A0So: how does this work if the Database does not return its list of rulesets?
Presumably, the Master Device did this because it needs the list, and
then it didn't get it. =C2=A0What does it do now?

Also, this is worded a bit confusingly. =C2=A0The list is REQUIRED, so it&#= 39;s
not true that the Database SHOULD return a list. =C2=A0What you mean to
tell us is what the Database SHOULD include in the list. =C2=A0I think it&#= 39;s
really awkward to try to say that here in the query, rather than in
the next section in the response.

Try this:

OLD (Section 4.2.1)
=C2=A0 =C2=A0deviceDesc: =C2=A0The DeviceDescriptor (Section 5.2) for the D= evice is
=C2=A0 =C2=A0 =C2=A0 REQUIRED. =C2=A0If the Database does not support the d= evice or any of
=C2=A0 =C2=A0 =C2=A0 the rulesets specified in the device descriptor, it MU= ST return an
=C2=A0 =C2=A0 =C2=A0 error with the UNSUPPORTED (Table 1) code in the error= response.
=C2=A0 =C2=A0 =C2=A0 If the device descriptor does not contain any ruleset = IDs, the
=C2=A0 =C2=A0 =C2=A0 Database SHOULD return a list of RulesetInfo (Section = 5.6)
=C2=A0 =C2=A0 =C2=A0 parameters for each ruleset it supports at the specifi= ed location.
NEW
=C2=A0 =C2=A0deviceDesc: =C2=A0The DeviceDescriptor (Section 5.2) for the D= evice is
=C2=A0 =C2=A0 =C2=A0 REQUIRED. =C2=A0If the device descriptor does not cont= ain any ruleset
=C2=A0 =C2=A0 =C2=A0 IDs, the Master Device is asking the Database to retur= n a list of
=C2=A0 =C2=A0 =C2=A0 RulesetInfo (Section 5.6) parameters for each ruleset = it supports
=C2=A0 =C2=A0 =C2=A0 at the specified location.
END

OLD (Section 4.2.2)
=C2=A0 =C2=A0rulesetInfos: =C2=A0A list of RulesetInfo (Section 5.6) parame= ters MUST be
=C2=A0 =C2=A0 =C2=A0 included in the response. =C2=A0Each RulesetInfo param= eter corresponds
=C2=A0 =C2=A0 =C2=A0 to a ruleset supported by the Database and is applicab= le to the
=C2=A0 =C2=A0 =C2=A0 location specified in the INIT_REQ (Section 4.2.1) mes= sage. =C2=A0If
=C2=A0 =C2=A0 =C2=A0 the Device included a list of ruleset IDs in the Devic= eDescriptor
=C2=A0 =C2=A0 =C2=A0 parameter of its INIT_REQ message, each RulesetInfo pa= rameter in
=C2=A0 =C2=A0 =C2=A0 the response MUST match one of the specified ruleset I= Ds.
NEW
=C2=A0 =C2=A0rulesetInfos: =C2=A0A list of RulesetInfo (Section 5.6) parame= ters MUST be
=C2=A0 =C2=A0 =C2=A0 included in the response. =C2=A0Each RulesetInfo param= eter corresponds
=C2=A0 =C2=A0 =C2=A0 to a ruleset supported by the Database and is applicab= le to the
=C2=A0 =C2=A0 =C2=A0 location specified in the INIT_REQ (Section 4.2.1) mes= sage.

=C2=A0 =C2=A0 =C2=A0 If the Device included a list of ruleset IDs in the De= viceDescriptor
=C2=A0 =C2=A0 =C2=A0 parameter of its INIT_REQ message, each RulesetInfo pa= rameter in
=C2=A0 =C2=A0 =C2=A0 the response MUST match one of the specified ruleset I= Ds.

=C2=A0 =C2=A0 =C2=A0 If the DeviceDescriptor did not contain any ruleset ID= s, the
=C2=A0 =C2=A0 =C2=A0 Database SHOULD include in the list the RulesetInfo pa= rameters for
=C2=A0 =C2=A0 =C2=A0 each ruleset it supports at the specified location.
=C2=A0 =C2=A0 =C2=A0 If the Database does not support the device or any of = the rulesets
=C2=A0 =C2=A0 =C2=A0 specified in the DeviceDescriptor, it MUST instead ret= urn an
=C2=A0 =C2=A0 =C2=A0 error with the UNSUPPORTED (Table 1) code in the error= response.
END

Thanks for = the suggestions. Done.
=C2=A0

-- Section 4.3.2 --

=C2=A0 =C2=A0If the Database accepts the
=C2=A0 =C2=A0registration for none of the rulesets it supports, the Databas= e MUST
=C2=A0 =C2=A0return the NOT_REGISTERED error (See Error Codes (Section 5.17= )).

I can't follow this sentence at all. =C2=A0Do you mean, "If the Da= tabase
does not accept the registration for any of the rulesets" ? =C2=A0Or d= o you
mean something else? =C2=A0Can you re-word this, please?

Heh, I was afraid "any"= is ambiguous.

"If the Database does not accept the regist= ration for any of the rulesets":

= =C2=A0- Does that mean if, out of 3, one was not acceptable, it passes the = "any" test?
=C2=A0- Or d= oes that mean "none of them"

= Hence...the attempt at being more precise by using "none".=


-- Section 5.8 --

=C2=A0 =C2=A0name: =C2=A0The display name for a database. =C2=A0It MAY cont= ain UTF-8.

What about all the other strings whose content format is unspecified?
Are they allowed to contain UTF-8? =C2=A0If not, what *do* they contain?
I see that the Gen-ART review mentioned this also, and the response
will be to specify that all strings are encoded in UTF-8. =C2=A0Good.

Done.
=C2=A0

-- Section 6 --
How is the reference to JSON Schema [I-D.zyp-json-schema] not
normative, when the 6.x subsections quite depend upon the
understanding of the schema format that it describes?

I see that the Gen-ART review mentioned this also, but the response is
quite troubling. =C2=A0No, the mechanism you're using is not sufficient= ly
self explanatory. =C2=A0I understand it -- I do -- but I had to figure it out (I decided not to go look at the Zyp draft), and we can't assume that arbitrary implementors will get it right. =C2=A0We need a well defined=
way to explain how JSON objects are constructed. =C2=A0And, unfortunately,<= br> the JSON working group chose *not* to take on a work item for this
(which I was pushing for).

We have at least three proposals (apart from Zyp, there's Newton
(draft-newton-json-content-rules), and there's the mechanism that I
proposed, which is used in Section 6.2 of RFC 7071), but nothing
that's being taken forward as a standard yet.

=
I guess the 3rd option is to just descri= be by example. Hopefully we can
di= scuss this at the F2F.
=C2=A0

-- Section 6.6.2 --
The schema is missing the optional databaseChange property.
Done=C2=A0

-- Section 6.7.1 --
The schema is missing the optional masterDeviceDesc property.
Done=C2=A0
=C2=A0

-- Section 6.8.11 --
The schema says that both properties are optional, but Section 5.14
says that they're both required.
Done=C2=A0
=C2=A0

-- Section 6.8.13 --
The schema says that rulesetInfo is optional, but Section 5.9 says
that it's required.
Done= =C2=A0
=C2=A0

-- Section 7 --

=C2=A0 =C2=A0The Database MAY redirect a PAWS request by returning a HTTP 3= xx
=C2=A0 =C2=A0response (as defined by HTTP/1.1 [RFC2616]).
...
=C2=A0 =C2=A0Since the Device may communicate
=C2=A0 =C2=A0with a Database (which it authenticated) without user interact= ion,
=C2=A0 =C2=A0when the response code is 301 (Moved Permanently), the Device = MAY
=C2=A0 =C2=A0redirect without asking a user for confirmation (note that thi= s
=C2=A0 =C2=A0represents an exception to the HTTP/1.1 [RFC2616] requirements= for
=C2=A0 =C2=A0HTTP POST methods).

The references to RFC2616 need to change to RFC7231, now that 2616 is obsol= ete.
I see that the Gen-ART review mentioned this also, and you plan to
change the reference. =C2=A0This should help you get that right:

The change to 7231 also means that the note about the second citation
can change. =C2=A02616 said this about redirecting a POST:

--- RFC 2616 ---
=C2=A0 =C2=A0If the 301 status code is received in response to a request ot= her
=C2=A0 =C2=A0than GET or HEAD, the user agent MUST NOT automatically redire= ct the
=C2=A0 =C2=A0request unless it can be confirmed by the user, since this mig= ht
=C2=A0 =C2=A0change the conditions under which the request was issued.
----------------

That advice has changed in 7231:

--- RFC 7231 ---
=C2=A0 =C2=A0Automatic redirection needs to done with
=C2=A0 =C2=A0care for methods not known to be safe, as defined in Section 4= .2.1,
=C2=A0 =C2=A0since the user might not wish to redirect an unsafe request. ----------------

In my view, that means that the parenthesized note in the quote above
can be removed from this document. =C2=A0I also suggest using a section
number in the citation, as you're citing a big document. =C2=A0So...
OLD
=C2=A0 =C2=A0The Database MAY redirect a PAWS request by returning a HTTP 3= xx
=C2=A0 =C2=A0response (as defined by HTTP/1.1 [RFC2616]).
NEW
=C2=A0 =C2=A0The Database MAY redirect a PAWS request by returning a HTTP 3= xx
=C2=A0 =C2=A0response (as defined by HTTP/1.1 Semantics and Content [RFC723= 1],
=C2=A0 =C2=A0Section 6.4).
END

OLD
=C2=A0 =C2=A0Since the Device may communicate
=C2=A0 =C2=A0with a Database (which it authenticated) without user interact= ion,
=C2=A0 =C2=A0when the response code is 301 (Moved Permanently), the Device = MAY
=C2=A0 =C2=A0redirect without asking a user for confirmation (note that thi= s
=C2=A0 =C2=A0represents an exception to the HTTP/1.1 [RFC2616] requirements= for
=C2=A0 =C2=A0HTTP POST methods).
NEW
=C2=A0 =C2=A0Since the Device may communicate
=C2=A0 =C2=A0with a Database (which it authenticated) without user interact= ion,
=C2=A0 =C2=A0when the response code is 301 (Moved Permanently), the Device = MAY
=C2=A0 =C2=A0redirect without asking a user for confirmation, even though i= t
=C2=A0 =C2=A0is in response to an HTTP POST request.
END

Done for th= e above.
=C2=A0

-- Section 8.2 --

=C2=A0 =C2=A0The parameter name SHOULD be lowerCamelCase.

Why "SHOULD"? =C2=A0 How does it affect interoperability? =C2=A0W= ouldn't
"Parameter names use lowerCamelCase by convention." work fine?

Agreed. Changed.= =C2=A0
=C2=A0

-- Section 9 --
First, and most importantly, the IANA review interpreted your text to
say that the registration policies are Expert Review; I interpret your
text to say that they're Specification Required. =C2=A0Yet Vince replie= d to
the IANA review without correcting that. =C2=A0Which policy do you intend?<= br> If it is Specification Required, you need to clear that up with IANA.
Or just deal with my other comments in this section, and that might
happen anyway.

= Thanks for pointing that out. I'll add to the comment.=C2=A0
=C2=A0

The text in this section seems to be commonly copied from somewhere.
Perhaps you could tell me whence you copied it, so we can make an
effort to stop people from doing that.

= I don't remember precisely, but I recall I was = reviewing some OAUTH docs at the time.
RFC6749
=C2=A0

The first paragraph is entirely unnecessary: please just remove it.

Done=C2=A0
=C2=A0

The second paragraph and the list is fine, and the third is mostly OK,
except for the URI. =C2=A0You'll need to ask IANA how they want to rece= ive
requests (by email or through a web URI), and specify that in
paragraph 3 instead of what's there now.

FYI. From http://www.iana.org, you can navigate to a "Protoco= l Registration Forms" page to submit requests
for new assignments.
=C2=A0

The fourth paragraph really needs to be entirely re-thought: it is not
how IANA does expert review in the first place, and we shouldn't be
telling IANA how to run their process in the second place.

The fourth paragraph should say that all registries use the
Specification Required policy [RFC5226], with a Designated Expert
appointed by the IESG. =C2=A0It should note that instructions to the DE as<= br> to what she should look for and consider in evaluating a request are
given below in the descriptions of each registry. =C2=A0It should say that<= br> the DE should take advice from the community through the designated
mailing list, and that is why the registrant should post to the
mailing list before formally requesting the registration from IANA.
All the rest of the mechanics are part of IANA's process, and should not be specified here.

=C2=A0Thanks. Proposed text:

=C2=A0 =C2=A0All regi= stries use the Specification Required policy [RFC5226], with
=C2=A0 =C2=A0a Designated Expert appointed by = the IESG. =C2=A0Specific criteria that
=C2=A0 =C2=A0the Designated Expert should use = in assessing registrations are given
=C2=A0 =C2=A0below in the description of each registry. =C2=A0The Design= ated Expert
=C2=A0 =C2=A0should take advice from the commu= nity through the paws@ie= tf.org
=C2=A0 =C2=A0mailing list, and the registrant = is encouraged to post to the mailing
=C2=A0 =C2=A0list before formally requesting the registration from IANA.= =C2=A0The
=C2=A0 =C2=A0intention is that new registrations wi= ll be accompanied by a
=C2=A0 =C2=A0published specification. =C2=A0Bu= t in order to allow for the allocation of
=C2=A0 =C2=A0values prior to publication of the specification, the = Designated
=C2=A0 =C2=A0Expert can approve allocations once it= seems clear that the
=C2=A0 =C2=A0specification will be published.<= /font>

Is the last p= art (about allocation before publication of spec) also process that should = be omitted?
Or are they instructions to the DE?


One question: does it make sense for the review list to be a separate
list, or couldn't the WG mailing list be reused for that purpose?

I don't think th= ere's a reason not to. Just didn't know the process.
Will propose just to use paws@ietf.org.
=C2=A0


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D COMME= NT -- substantive =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

General:
You appear to sometimes use "parameter" to refer to a structure (= such
as GeoLocation) and also the fields within the parameter (see Section
5.1, for example). =C2=A0I find this confusing, and suggest that you do not=
use the same term for both.

You're right. Perhaps, when referring to a structure, I sh= ould use "object" in the JSON sense?
=C2=A0

-- Section 3 --
In step 4, should this not say a word or two about what message it
responds with? =C2=A0Might it respond, "To be, or not to be; that is t= he
question?" =C2=A0Or is there an expected sort of response?

Changed.
= =C2=A0

Step 5 is the first mention of registration. =C2=A0A reference to where
that process is explained would be useful here (as this step doesn't seem to fit into the flow).

In step 7, this is the first mention of a Slave Device, so referring
to "the Slave Device" doesn't make sense. =C2=A0Maybe you wan= t something
like, "If a Slave Device has made a request to the Master Device, the<= br> Master Device may verify..." ?

It's not clear how step 7 relates to steps 6 and 8.

Tha= nks. Reworded these steps:

=C2=A0 =C2=A06. =C2=A0 The Master Device = sends an available-spectrum request message to
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 the Database. =C2=A0The message may be on behalf of a Slave D= evice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that made a request to the Mast= er Device.

=C2=A0 =C2=A07. =C2=A0 If the Master Device is making a= request on behalf of a Slave
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Device,= the Master Device may verify with the Database that the
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Slave Device is valid.

=C2=A0 =C2=A08. =C2=A0 The Database responds with an availab= le-spectrum response
=C2=A0 =C2=A0 =C2=A0 =C2=A0 message in the b= ody of the HTTP response.

=C2=A0
=C2=A0

In step 10, might it also send an error, refusal, or whatever? =C2=A0Or are=
those all considered acknowledgment messages?

This should be considered a notification (fi= re and forget) call from the Device.
Suggested rewording:

= =C2=A0 =C2=A09. =C2=A0 The Master Device may send a spectrum-usage notifica= tion message
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 to the Database. =C2=A0The notification is purely informational.

= =C2=A0 =C2=A010. =C2=A0If the Database receives a spectrum-usage notificati= on message,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 it responds by sending the Master Device a spectrum-usage
=C2=A0 =C2=A0 =C2=A0 =C2=A0 acknowledgement me= ssage. =C2=A0Since the notification is purely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 informational, the Master Device d= oes not need to process the
=C2=A0= =C2=A0 =C2=A0 =C2=A0 Database response.=C2=A0


Hm, it seems that steps 5 and 7 are actually explained in the
paragraph after the numbered steps. =C2=A0So do they really belong in the numbered steps at all?

The numbered steps are supposed to correspond to the order in which= these steps
happen, so I think it= 's important to leave them there.
=C2=A0

-- Section 5.1 --

=C2=A0 =C2=A0point: =C2=A0If present, it indicates that the GeoLocation rep= resents a
=C2=A0 =C2=A0 =C2=A0 point.
...
=C2=A0 =C2=A0region: =C2=A0If present, it indicates that the GeoLocation re= presents a
=C2=A0 =C2=A0 =C2=A0 region.

These make it sound as though these are boolean. =C2=A0It took me a bit to<= br> realize that the values of each of these is actually a structure. =C2=A0I think you mean this:

NEW
=C2=A0 =C2=A0point: =C2=A0If present, it specifies the GeoLocation as a poi= nt.
...
=C2=A0 =C2=A0region: =C2=A0If present, it specifies the GeoLocation as a re= gion.
END

Done.=C2=A0=

-- Section 8.3 --
Please get rid of the MAY in the first sentence.

Done.=C2=A0
=C2=A0
=

=C2=A0 =C2=A0If an
=C2=A0 =C2=A0appropriate category does not exist, it can use values in a di= fferent
=C2=A0 =C2=A0range.

What is the antecedent for "it"? =C2=A0It looks like it's &qu= ot;an appropriate
category", but that's clearly not right. =C2=A0Please fix.

Done. Rewording:

=C2=A0 If an
=C2=A0 =C2=A0appropriate category does not exi= st, a value from a different range
=C2=A0 =C2=A0may be used.=C2=A0



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D COMME= NT -- minor =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

A small point in the header:
"iconectiv (formerly Telcordia Interconnection Solutions)"
I think it's fine to put that in the "Authors' Addresses"= section, but
the header should just say "iconectiv". =C2=A0I realize that take= s a little
inconvenient massaging of the XML, and probably isn't worth the
trouble for the I-D. =C2=A0Might just put that in an RFC Editor note....

I'll take a l= ook later :)
=C2=A0

General:
I like that your citations include the document names, as well as the
RFC numbers; thanks! =C2=A0It would be better if you put quotation marks around the document names, to distinguish them from being part of your
text.

Done.
=C2=A0

-- Section 1 --

=C2=A0 =C2=A0The document describes the use of HTTP/TLS as
=C2=A0 =C2=A0transport for the protocol.

This hits what's rather a peeve of mine: HTTP is not a transport
protocol; the transport protocol you're using is TCP.

I'd be happier if you said something like this:

OLD
=C2=A0 =C2=A0This specification defines an extensible protocol to obtain av= ailable
=C2=A0 =C2=A0spectrum from a geospatial database by a device with geo-locat= ion
=C2=A0 =C2=A0capability.
NEW
=C2=A0 =C2=A0This specification defines an extensible protocol, built on to= p of
=C2=A0 =C2=A0HTTP and TLS, to obtain available spectrum from a geospatial d= atabase
=C2=A0 =C2=A0by a device with geo-location capability.
END

...and then eliminate that last sentence. =C2=A0See also comments on
Section 4 and Section 7.
=C2=A0
Done.


-- Section 2.2 --

I suggest this:

OLD
=C2=A0 =C2=A0EIRP: =C2=A0Effective isotropically radiated power
=C2=A0 =C2=A0ETSI: =C2=A0European Telecommunications Standards Institute =C2=A0 =C2=A0FCC: =C2=A0Federal Communications Commission
NEW
=C2=A0 =C2=A0ETSI: =C2=A0European Telecommunications Standards Institute &l= t;http://etsi.org>
=C2=A0 =C2=A0FCC: =C2=A0The U.S. Federal Communications Commission <http://fcc.gov>
END

... and then in Section 9.2.2.7, spell out EIRP, as it's only used in that one place.

Done.=C2=A0

-- Section 3 --
Little grammar nit:
=C2=A0 =C2=A01. =C2=A0 The Master Device obtains (statically or dynamically= ) the URI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for a Database appropriate for its location to = send subsequent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 PAWS messages.

Make it "location, to which to send".

Done.=C2=A0

-- Section 3.1 --

=C2=A0 =C2=A0These
=C2=A0 =C2=A0requirements may be complex and involve device behavior that a= re not
=C2=A0 =C2=A0easily parameterized.

"Device behaviour" is singular, so "that is not", pleas= e.

D= one.=C2=A0

-- Section 4 --

Usage pet peeve: please change "comprise" to "compose",= in the one
place it's used.

=C2=A0 =C2=A0HTTPS Binding (Section 7) describes the use of
=C2=A0 =C2=A0HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages= and
=C2=A0 =C2=A0optional device authentication.

Please use "transferring", instead of "transporting", t= o avoid calling
HTTP a transport.

Done.=C2=A0

-- Section 4.1.1 --

=C2=A0 =C2=A0TBD Define message format

You missed something here. =C2=A0Jus' sayin'.

Acknowledged.=C2= =A0

-- Section 4.4.1 --

=C2=A0 =C2=A0Rulesets may mandate that it be the Device's
=C2=A0 =C2=A0current location or allow it to be an anticipated location.
This is probably as good a place as any to ask this: is there any
validation of the geo-location at all? =C2=A0If not, can such a mandate
have any real teeth? =C2=A0What is this *really* saying?
There is no requiremen= t for Database to validate. Devices typically go through
<= span style=3D"color:rgb(0,0,255)">separate certification (e.g., FCC) to ens= ure they conform to the rules. Likewise,
Databases may also need to be certi= fied, depending on regulatory requirements.


-- Section 4.4.5 --
The table says that "location" is required, but the text says it&= #39;s not
always required. =C2=A0The table should say "see description".

Done.<= /span>=C2=A0

-- Section 4.5 --

=C2=A0 =C2=A0Typically, a Slave Device needs a Master Device to ask the Dat= abase
=C2=A0 =C2=A0on its behalf for available spectrum

"Typically"? =C2=A0Isn't that the *definition* of a Slave Dev= ice?

Oops. Done.=C2=A0

-- Section 5.5 --

=C2=A0 =C2=A0All contact information MUST be expressed using the structure = defined
=C2=A0 =C2=A0by the vCard Format Specification [RFC6350].

I think it's best to include both references here, like this:

NEW
=C2=A0 =C2=A0All contact information MUST be expressed using the structure = defined
=C2=A0 =C2=A0by the vCard Format Specification [RFC6350], encoded in JSON [= RFC 7095].
END

= Done.=C2=A0

-- Section 5.7 --
The subsections explain what additional "data" field each error m= ight
use, but there are only sections for the ones that use the "data"=
field. =C2=A0One has to assume that the absence of a subsection means that<= br> the "data" field is not used for that error. =C2=A0It would be be= tter to
say that in the table. =C2=A0I suggest adding one sentence to each error description in the table except for -104, -105, and -201, as follows:
"This error does not use any additional data."
Done.=C2=A0

-- Section 5.11 --
The third table should be labelled "SpectrumProfilePoint".

Done.=C2=A0

-- Section 5.12 --
The second table should be labelled "SpectrumProfilePoint".

Done.=C2=A0

-- Section 5.17.1 --

=C2=A0 =C2=A0When the error code is OUTSIDE_COVERAGE, the Database MAY incl= ude an
=C2=A0 =C2=A0ErrorData element within its as the "data" field

You're missing the words "Error response" after "within = its".

Done.=C2=A0

-- Section 7 --

=C2=A0 =C2=A0This section describes the use of HTTP over TLS (HTTPS) HTTP O= ver TLS
=C2=A0 =C2=A0[RFC2818] as the transport mechanism for the PAWS protocol.
As I've noted earlier, please say "as the transfer mechanism"= . =C2=A0Also,
it's really weird to describe the document in the same words as the
document title. =C2=A0I suggest just deleting the document title in this case. =C2=A0This also applies to Section 10.1.

Done.=C2=A0

-- Section 9.1.2 --
The first paragraph was obviously written before the ETSI info was
added. =C2=A0Please adjust it accordingly. =C2=A0(I see that the Gen-ART re= view
mentioned this too, and it will be fixed.)

<= div>Done.=C2=A0

You might add instructions to the DE with respect to handling
prefixes. =C2=A0Suppose, for example, I wanted to register something
starting with "fcc". =C2=A0Or perhaps with the initials of an org= anization
that hasn't yet registered anything, but reasonably might.

Done.=C2= =A0

-- Section 10.1 --
The doubled "HTTP over TLS" comment applies here. =C2=A0Also, it&= #39;s not at
all clear, when you say "these checks MAY be omitted," exactly wh= at
checks you're saying may be omitted.

Verification of the SANs. Added some text.=
=C2=A0

=C2=A0 =C2=A0In particular, the
=C2=A0 =C2=A0validation path of the certificate must end in one of the clie= nt's
=C2=A0 =C2=A0trust anchors, even if that trust anchor is the Database certi= ficate
=C2=A0 =C2=A0itself. =C2=A0A Master Device should allow for the fact that a= Database
=C2=A0 =C2=A0can change its certificate authorities (CAs) over time.

Just a question here: did the WG consider DANE at all?

It was brought up, but n= ot discussed further.=C2=A0

Another question: is it really necessary to cover this stuff here?
Isn't it in 2818?

I believe the WG thought it would be good to restate.=C2=A0

-- Section 10.3 --

=C2=A0 =C2=A0Using HTTP over TLS, messages protected by appropriate cypher = suites
=C2=A0 =C2=A0are also protected from eavesdropping or otherwise access by =C2=A0 =C2=A0unauthorized parties en route.

What does "or otherwise access" mean? =C2=A0Apart from the gramma= r problem:
it would be better to say something substantive here, rather than
something vague.

Changed to "or otherwise unrestricted reading".=C2=A0

-- Section 11 --
I wouldn't usually comment on a "Contributors" section, but i= t seems
odd to me to cite abandoned and long-expired drafts as references. =C2=A0It=
might be better just to include the draft names, without making them
references. =C2=A0No? =C2=A0You're not actually suggesting that people = read
them, just thanking the authors for their contributions.
Done.=C2=A0

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

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



--
-vince
--089e0122f5fa471f8f04fe7dbcc5-- From nobody Sat Jul 26 09:52:01 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 270D81B2859 for ; Sat, 26 Jul 2014 09:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 6dzzK-QduFLa for ; Sat, 26 Jul 2014 09:51:50 -0700 (PDT) Received: from ls-mx3.csir.co.za (mx-3.csir.co.za [146.64.10.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E759F1B285A for ; Sat, 26 Jul 2014 09:51:44 -0700 (PDT) Received: from pta-emo.csir.co.za (pta-emo.csir.co.za [146.64.100.109]) by ls-mx3.csir.co.za (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s6QGpVgx024634 for ; Sat, 26 Jul 2014 18:51:33 +0200 Received: from PTA-EMO-MTA by pta-emo.csir.co.za with Novell_GroupWise; Sat, 26 Jul 2014 18:51:11 +0200 Message-Id: <53D3F89D0200009E00099BAB@pta-emo.csir.co.za> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Sat, 26 Jul 2014 18:51:09 +0200 From: "Luzango Mfupe" To: , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part596BD46D.4__=" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (ls-mx3.csir.co.za [146.64.10.248]); Sat, 26 Jul 2014 18:51:33 +0200 (SAST) X-CSIR-MailScanner-Information: Please contact the ISP for more information X-CSIR-MailScanner-ID: s6QGpVgx024634 X-CSIR-MailScanner: Found to be clean X-CSIR-MailScanner-From: lmfupe@csir.co.za X-CSIR-MailScanner-Watermark: 1406998293.70728@7FHJg4iTd585v3QRS6EfnA Archived-At: http://mailarchive.ietf.org/arch/msg/paws/BoXvul9ccNlYS0OH_CaMDbCQN-o Cc: paws@ietf.org Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APP AD) 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: Sat, 26 Jul 2014 16:51:59 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part596BD46D.4__= Content-Type: multipart/alternative; boundary="=__Part596BD46D.5__=" --=__Part596BD46D.5__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Vince, Folks, I am glad to see things are moving to the right direction and hopefully soon we will finalise this work. I just found some few not very critical issues that needs some fixing in in my opinion: 5.11. Spectrum Here the document talk about the FCC and OFCOM/ETSI spectral profile presentation requirements (i.e, power levels over a set of frequency ranges. However, there is only one type of example (OFCOM/ETSI specific) that is provided throughout the document. I think we need to add another set of example that is FCC specific. Would something like this below suffice for the FCC specific example? “resolutionBwHz”: 1e5, “profiles”: [ { "Hz": 5.18e8, "Hz": 5.24e8, “dbm”: 24 ] }, 6.8.3. Antenna Characteristics We only have the AMSL and AGL as options for antenna height Types. I don't see why we should not also list HAAT as a third option, I am pretty sure this is/can be used in some implementations. Kind Regards, Luzango. >>> Vincent Chen 07/18/14 10:38 PM >>> Barry, Thanks again for the detailed comments. A couple issues remain unresolved: - How to describe JSON schema - Usage of "parameter" Will you be available for the PAWS session on Tues to discuss further? I've included additional comments/answers inline. On Mon, Jul 14, 2014 at 12:31 PM, Barry Leiba wrote: Hey, PAWS folk. As Pete has put the subject document on the 7 August telechat agenda, though he still has it in "Waiting for AD Go Ahead" state, I decided to review it now, rather than wait. I've found quite a list of issues, from large to small, which I've sorted below into three categories: "DISCUSS" are those that I would put in a DISCUSS ballot during IESG Evaluation. I think they're errors in the document that need to be corrected, or else things that need to be discussed and resolved. The most important in this category, and the only one I think will be difficult to resolve, is how to specify the JSON payload formally. "COMMENT -- substantive" are those that I would put in the non-blocking comments, but that I think are important to deal with, and that I'd hope we'd have a discussion about if the authors think a discussion is necessary. "COMMENT -- minor" are minor editorial issues that I think would be better corrected, but that I'm not going to grump about further. Discussion is always welcome, but should be pretty much unnecessary for these. I hope it's useful to get these comments earlier, rather than later. And, so, here they are, below. I've offered suggested text where I could, and I hope that helps as well. Barry ======================= DISCUSS ======================= -- Section 4 -- o Device Registration (Section 4.3) MAY be used by the Master Device and MAY be implemented by the Database, either as a separate component or as part of the Available Spectrum Query (Section 4.4) component. I don't think the first MAY is correct. If the database requires registration, it is *not* optional for the Master Device to use it. I think this needs some rework. The same is true with "Device Validation". Based on comments from our AD, we wanted to separate requirements for the protocol itself from database-specific and regulatory-domain requirements. Thus, from the protocol's perspective, it's a MAY. Having said that, the text can be clarified a bit. Suggestion: o Device Registration (Section 4.4) MAY be used by the Master Device and MAY be implemented by the Database. When implementing Device Registration, the Database MAY implement it either as a separate component or as part of the Available Spectrum Query (Section 4.5) component. This list also mixes "used", "supported", and "implemented", without making all the issu say about its use? And what's the difference between "supported" and "implemented"? Agreed it's confusing. Replaced "supported" by "implemented", since that's what's intended. The work "supported" still exists in the doc when referring to "supporting a set of rules" or "rulesets". There's also an added not in the Terminologies section. I strongly suggest that, if you're going to say that, you make it all clear, as to both implementation/support and use. The note after the list that says that some things are obvious... nah, one of it is obvious. -- Section 4.1 -- A Database MAY indicate that its URI will be changing by including the URI of one or more alternate databases (See DbUpdateSpec (Section 5.7)) in its responses to a Device. Before a Database ceases operation, for example, it MUST include DbUpdateSpec in its responses to notify Devices. I don't understand how the MAY and MUST are consistent with each other. Can you explain or fix it? Ah, I see....MAY refers to the Database's ability to change its URI. Reword: A Database MAY change its URI, but before it changes its URI, it MUST indicate so by including the URI of one or more alternate databases (See DbUpdateSpec (Section 5.7)) in its responses to a Device. Before a Database ceases operation, for example, it MUST include DbUpdateSpec in its responses to notify Devices. -- Section 4.1.1 -- 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 Here's another 2119 conflict. It doesn't make sense to have a MUST for the time period if doing it at all is a SHOULD. Please sort this one out as well. You're right. Changed MUST to SHOULD. -- Section 4.2 A Master Device SHOULD use the initialization procedure to exchange capability information with the Database whenever the Master Device powers up or initiates communication with the Database. But in Section 4 you said "Initialization (Section 4.2) MAY be used by the Master Device," and now you're saying "SHOULD"? You see why I'm on about the 2119 inconsistencies? The MAY in Section 4 is an oversight. Changed to SHOULD. When a Master Device is configured manually with these parameterized-rule values, it does not need to use the initialization procedure. Dos that mean that when it's not configured with them, it *does* need to? In other words, is this really a "MUST use initialization unless it's pre-configured with the values" thing? Thanks. You're right. Reworded: When a Master Device is not configured manually with these parameterized-rule values, it MUST use the initialization procedure. -- Section 4.2.1 -- deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is REQUIRED. If the Database does not support the device or any of the rulesets specified in the device descriptor, it MUST return an error with the UNSUPPORTED (Table 1) code in the error response. If the device descriptor does not contain any ruleset IDs, the Database SHOULD return a list of RulesetInfo (Section 5.6) parameters for each ruleset it supports at the specified location. What this says to me is that the Master Device uses an empty list of rulesets to query the list of supported rulesets. So: how does this work if the Database does not return its list of rulesets? Presumably, the Master Device did this because it needs the list, and then it didn't get it. What does it do now? Also, this is worded a bit confusingly. The list is REQUIRED, so it's not true that the Database SHOULD return a list. What you mean to tell us is what the Database SHOULD include in the list. I think it's really awkward to try to say that here in the query, rather than deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is REQUIRED. If the Database does not support the device or any of the rulesets specified in the device descriptor, it MUST return an error with the UNSUPPORTED (Table 1) code in the error response. If the device descriptor does not contain any ruleset IDs, the Database SHOULD return a list of RulesetInfo (Section 5.6) parameters for each ruleset it supports at the specified location. NEW deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is REQUIRED. If the device descriptor does not contain any ruleset IDs, the Master Device is asking the Database to return a list of RulesetInfo (Section 5.6) parameters for each ruleset it supports at the specified location. END OLD (Section 4.2.2) rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be included in the response. Each RulesetInfo parameter corresponds to a ruleset supported by the Database and is applicable to the location specified in the INIT_REQ (Section 4.2.1) message. If the Device included a list of ruleset IDs in the DeviceDescriptor parameter of its INIT_REQ message, each RulesetInfo parameter in the response MUST match one of the specified ruleset IDs. NEW rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be included in the response. Each RulesetInfo parameter corresponds to a ruleset supported by the Database and is applicable to the location specified in the INIT_REQ (Section 4.2.1) message. If the Device included a list of ruleset IDs in the DeviceDescriptor parameter of its INIT_REQ message, each RulesetInfo parameter in the response MUST match one of the specified ruleset IDs. If the DeviceDescriptor did not contain any ruleset IDs, the Database SHOULD include in the list the RulesetInfo parameters for each ruleset it supports at the specified location. If the Database does not support the device or any of the rulesets specified in the DeviceDescriptor, it MUST instead return an error with the UNSUPPORTED (Table 1) code in the error response. END Thanks for the suggestions. Done. -- Section 4.3.2 -- If the Database accepts the registration for none of the rulesets it supports, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). I can't follow this sentence at all. Do you mean, "If the Database does not accept the registration for any of the rulesets" ? Or do you mean something else? Can you re-word this, please? Heh, I was afraid "any" is ambiguous. "If the Database does not accept the registration for any of the rulesets": - Does that mean if, out of 3, one was not acceptable, it passes the "any" test? - Or does that mean "none of them" Hence...the attempt at being more precise by using "none". -- Section 5.8 -- name: The display name for a database. It MAY contain UTF-8. What about all the other strings whose content format is unspecified? Are they allowed to contain UTF-8? If not, what *do* they contain? I see that the Gen-ART review mentioned this also, and the response will be to specify that all strings are encoded in UTF-8. Good. Done. -- Section 6 -- How is the reference to JSON Schema [I-D.zyp-json-schema] not normative, when the 6.x subsections quite depend upon the understanding of the schema format that it describes? I see that the Gen-ART review mentioned this also, but the response is quite troubling. No, the mechanism you're using is not sufficiently self explanatory. I understand it -- I do -- but I had to figure it out (I decided not to go look at the Zyp draft), and we can't assume that arbitrary implementors will get it right. We need a well defined way to explain how JSON objects are con (which I was pushing for). We have at least three proposals (apart from Zyp, there's Newton (draft-newton-json-content-rules), and there's the mechanism that I proposed, which is used in Section 6.2 of RFC 7071), but nothing that's being taken forward as a standard yet. I guess the 3rd option is to just describe by example. Hopefully we can discuss this at the F2F. -- Section 6.6.2 -- The schema is missing the optional databaseChange property. Done -- Section 6.7.1 -- The schema is missing the optional masterDeviceDesc property. Done -- Section 6.8.11 -- The schema says that both properties are optional, but Section 5.14 says that they're both required. Done -- Section 6.8.13 -- The schema says that rulesetInfo is optional, but Section 5.9 says that it's required. Done -- Section 7 -- The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by HTTP/1.1 [RFC2616]). ... Since the Device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation (note that this represents an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods). The references to RFC2616 need to change to RFC7231, now that 2616 is obsolete. I see that the Gen-ART review mentioned this also, and you plan to change the reference. This should help you get that right: The change to 7231 also means that the note about the second citation can change. 2616 said this about redirecting a POST: --- RFC 2616 --- If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued. ---------------- That advice has changed in 7231: --- RFC 7231 --- Automatic redirection needs to done with care for methods not known to be safe, as defined in Section 4.2.1, since the user might not wish to redirect an unsafe request. ---------------- In my view, that means that the parenthesized note in the quote above can be removed from this document. I also suggest using a section number in the citation, as you're citing a big document. So... OLD The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by HTTP/1.1 [RFC2616]). NEW The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by HTTP/1.1 Semantics and Content [RFC7231], Section 6.4). END OLD Since the Device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation (note that this represents an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods). NEW Since the Device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation, even though it is in response to an HTTP POST request. END Done for the above. -- Section 8.2 -- The parameter name SHOULD be lowerCamelCase. Why "SHOULD"? How does it affect interoperability? Wouldn't "Parameter names use lowerCamelCase by convention." work fine? Agreed. Changed. -- Section 9 -- First, and most importantly, the IANA review interpreted your text to say that the registration policies are Expert Review; I interpret your text to say that they're Specification Required. Yet Vince replied to the IANA review without correcting that. Which policy do you intend? If it is Specification Required, you need to clear that up with IANA. Or just deal with my othe The text in this section seems to be commonly copied from somewhere. Perhaps you could tell me whence you copied it, so we can make an effort to stop people from doing that. I don't remember precisely, but I recall I was reviewing some OAUTH docs at the time. RFC6749 The first paragraph is entirely unnecessary: please just remove it. Done The second paragraph and the list is fine, and the third is mostly OK, except for the URI. You'll need to ask IANA how they want to receive requests (by email or through a web URI), and specify that in paragraph 3 instead of what's there now. FYI. From http://www.iana.org, you can navigate to a "Protocol Registration Forms" page to submit requests for new assignments. The fourth paragraph really needs to be entirely re-thought: it is not how IANA does expert review in the first place, and we shouldn't be telling IANA how to run their process in the second place. The fourth paragraph should say that all registries use the Specification Required policy [RFC5226], with a Designated Expert appointed by the IESG. It should note that instructions to the DE as to what she should look for and consider in evaluating a request are given below in the descriptions of each registry. It should say that the DE should take advice from the community through the designated mailing list, and that is why the registrant should post to the mailing list before formally requesting the registration from IANA. All the rest of the mechanics are part of IANA's process, and should not be specified here. Thanks. Proposed text: All registries use the Specification Required policy [RFC5226], with a Designated Expert appointed by the IESG. Specific criteria that the Designated Expert should use in assessing registrations are given below in the description of each registry. The Designated Expert should take advice from the community through the paws@ietf.org mailing list, and the registrant is encouraged to post to the mailing list before formally requesting the registration from IANA. The intention is that new registrations will be accompanied by a published specification. But in order to allow for the allocation of values prior to publication of the specification, the Designated Expert can approve allocations once it seems clear that the specification will be published. Is the last part (about allocation before publication of spec) also process that should be omitted? Or are they instructions to the DE? One question: does it make sense for the review list to be a separate list, or couldn't the WG mailing list be reused for that purpose? I don't think there's a reason not to. Just didn't know the process. Will propose just to use paws@ietf.org. ======================= COMMENT -- substantive ======================= General: You appear to sometimes use "parameter" to refer to a structure (such as GeoLocation) and also the fields within the parameter (see Section 5.1, for example). I find this confusing, and suggest that you do not use the same term for both. You're right. Perhaps, when referring to a structure, I should use "object" in the JSON sense? -- Section 3 -- In step 4, should this not say a word or two about what message it responds with? Might it respond, "To be, or not to be; that is the question?" Or is there an expected sort of response? Changed. Step 5 is the first mention of registration. A reference to where that process is explained would be useful here (as this step doesn't seem to fit into the flow). In step 7, this is the first mention of a Slave Device, so referring to "the Slave Device" doesn't make sense. Maybe you want something like, "If a Slave Device has made a request to the Master Device, the Master Device may verify..." ? It's not clear how step 7 relates to steps 6 and 8. Thanks. Reworded these steps: 6. The the Database. The message may be on behalf of a Slave Device that made a request to the Master Device. 7. If the Master Device is making a request on behalf of a Slave Device, the Master Device may verify with the Database that the Slave Device is valid. 8. The Database responds with an available-spectrum response message in the body of the HTTP response. In step 10, might it also send an error, refusal, or whatever? Or are those all considered acknowledgment messages? This should be considered a notification (fire and forget) call from the Device. Suggested rewording: 9. The Master Device may send a spectrum-usage notification message to the Database. The notification is purely informational. 10. If the Database receives a spectrum-usage notification message, it responds by sending the Master Device a spectrum-usage acknowledgement message. Since the notification is purely informational, the Master Device does not need to process the Database response. Hm, it seems that steps 5 and 7 are actually explained in the paragraph after the numbered steps. So do they really belong in the numbered steps at all? The numbered steps are supposed to correspond to the order in which these steps happen, so I think it's important to leave them there. -- Section 5.1 -- point: If present, it indicates that the GeoLocation represents a point. ... region: If present, it indicates that the GeoLocation represents a region. These make it sound as though these are boolean. It took me a bit to realize that the values of each of these is actually a structure. I think you mean this: NEW point: If present, it specifies the GeoLocation as a point. ... region: If present, it specifies the GeoLocation as a region. END Done. -- Section 8.3 -- Please get rid of the MAY in the first sentence. Done. If an appropriate category does not exist, it can use values in a different range. What is the antecedent for "it"? It looks like it's "an appropriate category", but that's clearly not right. Please fix. Done. Rewording: If an appropriate category does not exist, a value from a different range may be used. ======================= COMMENT -- minor ======================= A small point in the header: "iconectiv (formerly Telcordia Interconnection Solutions)" I think it's fine to put that in the "Authors' Addresses" section, but the header should just say "iconectiv". I realize that takes a little inconvenient massaging of the XML, and probably isn't worth the trouble for the I-D. Might just put that in an RFC Editor note.... I'll take a look later :) General: I like that your citations include the document names, as well as the RFC numbers; thanks! It would be better if you put quotation marks around the document names, to distinguish them from being part of your text. Done. -- Section 1 -- The document describes the use of HTTP/TLS as transport for the protocol. This hits what's rather a peeve of mine: HTTP is not a transport protocol; the transport protocol you're using is TCP. I'd be happier if you said something like this: OLD This specification defines an extensible protocol to obtain available spectrum from a geospatial database by a device with geo-location capability. NEW This specification defines an extensible protocol, built on top of HTTP and TLS, to obtain available spectrum from a geospatial database by a device with geo-location capability. END ...and then eliminate that last sentence. See also comments on Section 4 and Section 7. Done. -- Section 2.2 -- I suggest this: OLD EIRP: Effective isotropically radiated power ETSI: European Telecommunications Standards Institute FCC: Federal Communications Commission NEW ... and then in Section 9.2.2.7, spell out EIRP, as it's only used in that one place. Done. -- Section 3 -- Little grammar nit: 1. The Master Device obtains (statically or dynamically) the URI for a Database appropriate for its location to send subsequent PAWS messages. Make it "location, to which to send". Done. -- Section 3.1 -- These requirements may be complex and involve device behavior that are not easily parameterized. "Device behaviour" is singular, so "that is not", please. Done. -- Section 4 -- Usage pet peeve: please change "comprise" to "compose", in the one place it's used. HTTPS Binding (Section 7) describes the use of HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and optional device authentication. Please use "transferring", instead of "transporting", to avoid calling HTTP a transport. Done. -- Section 4.1.1 -- TBD Define message format You missed something here. Jus' sayin'. Acknowledged. -- Section 4.4.1 -- Rulesets may mandate that it be the Device's current location or allow it to be an anticipated location. This is probably as good a place as any to ask this: is there any validation of the geo-location at all? If not, can such a mandate have any real teeth? What is this *really* saying? There is no requirement for Database to validate. Devices typically go through separate certification (e.g., FCC) to ensure they conform to the rules. Likewise, Databases may also need to be certified, depending on regulatory requirements. -- Section 4.4.5 -- The table says that "location" is required, but the text says it's not always required. The table should say "see description". Done. -- Section 4.5 -- Typically, a Slave Device needs a Master Device to ask the Database on its behalf for available spectrum "Typically"? Isn't that the *definition* of a Slave Device? Oops. Done. -- Section 5.5 -- All contact information MUST be expressed using the structure defined by the vCard Format Specification [RFC6350]. I think it's best to include both references here, like this: NEW All contact information MUST be expressed using the structure defined by the vCard Format Specification [RFC6350], encoded in JSON [RFC 7095]. END Done. -- Section 5.7 -- The subsections explain what additional "data" field each error might use, but there are only sections for the ones that use the "data" field. One has to assume that the absence of a subsection means that the "data" field is not used for that error. It would be better to say that in the table. I suggest adding one sentence to each error description in the table except for -104, -105, and -201, as follows: "This error does not use any additional data." Done. -- Section 5.11 -- The third table should be labelled "SpectrumProfilePoint". Done. -- Section 5.12 -- The second table should be labelled "SpectrumProfilePoint". Done. -- Section 5.17.1 -- When the error code is OUTSIDE_COVERAGE, the Database MAY include an ErrorData element within its as the "data" field You're missing the words "Error response" after "within its". Done. -- Section 7 -- This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS [RFC2818] as the transport mechanism for the PAWS protocol. As I've noted earlier, please say "as the transfer mechanism". Also, it's really weird to describe the document in the same words as the document title. I suggest just deleting the document title in this case. This also applies to Section 10.1. Done. -- Section 9.1.2 -- The first paragraph was obviously written before the ETSI info was added. Please adjust it accordingly. (I see that the Gen-ART review mentioned this too, and it will be fixed.) Done. You might add instructions to the DE with starting with "fcc". Or perhaps with the initials of an organization that hasn't yet registered anything, but reasonably might. Done. -- Section 10.1 -- The doubled "HTTP over TLS" comment applies here. Also, it's not at all clear, when you say "these checks MAY be omitted," exactly what checks you're saying may be omitted. Verification of the SANs. Added some text. In particular, the validation path of the certificate must end in one of the client's trust anchors, even if that trust anchor is the Database certificate itself. A Master Device should allow for the fact that a Database can change its certificate authorities (CAs) over time. Just a question here: did the WG consider DANE at all? It was brought up, but not discussed further. Another question: is it really necessary to cover this stuff here? Isn't it in 2818? I believe the WG thought it would be good to restate. -- Section 10.3 -- Using HTTP over TLS, messages protected by appropriate cypher suites are also protected from eavesdropping or otherwise access by unauthorized parties en route. What does "or otherwise access" mean? Apart from the grammar problem: it would be better to say something substantive here, rather than something vague. Changed to "or otherwise unrestricted reading". -- Section 11 -- I wouldn't usually comment on a "Contributors" section, but it seems odd to me to cite abandoned and long-expired drafts as references. It might be better just to include the draft names, without making them references. No? You're not actually suggesting that people read them, just thanking the authors for their contributions. Done. ============================================== _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. --=__Part596BD46D.5__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML Hi Vince, Folk= s,

I am glad to see things= are moving to the right direction and hopefully soon we will finalise this= work.

I just found = some few not very critical issues that needs some fixing in in my opinion:<= /font>

5.11.  Spectrum=


Here the document talk about the FCC and OFCOM/ETSI = spectral profile presentation requirements (i.e, power levels over a set of=  frequenc= y ranges. However, there is only one type of example (OFCOM/ETSI specific) that is p= rovided throughout the document. I think we need to add another set of exam= ple that is FCC specific. 

=

Would something like this below = suffice for the FCC specific example?

   &nb= sp;

      =E2=80=9CresolutionBwHz=E2=80= =9D: 1e5,

      =E2=80=9Cprofiles=E2=80=9D: [=

       {

        "Hz": 5.18e8,

        "Hz": 5.24e8,

        =E2=80=9Cdbm=E2=80=9D:= 24

]       },



<= font face=3D"Courier New, monospace" color=3D"#0000ff">6.8.3. Antenna Ch= aracteristics 

We only have the AMSL and AGL as opt= ions for antenna height Types.

I don't see  why we should not also li= st HAAT as a third option, I am pretty sure this= is/can be used in some implementations.

Kind Regards,

Luzango.


>>> Vince= nt Chen <vchen@google.com> 07/18/14 10:38 PM >>>
<= div dir=3D"ltr" style=3D"font-family: Tahoma, sans-serif; font-size: 13px;"= >Barry,
Thanks again for the detailed comments. A couple issues rem= ain unresolved:
 - How to describe JSON schema
&nb= sp;- Usage of "parameter"

Will you be available for the PAWS= session on Tues to discuss further?

I've included additional= comments/answers inline.



On Mon, Jul 14, 2014 at 12:31 PM, Barry Leiba <barryleiba@computer.org> wrote:
Hey, P= AWS folk.
As Pete has put the subject document on the 7 August telechat= agenda,
though he still has it in "Waiting for AD Go Ahead" state, I d= ecided
to review it now, rather than wait.  I've found quite a lis= t of
issues, from large to small, which I've sorted below into three categories:

"DISCUSS" are those that I would put in a DISCUSS ba= llot during IESG
Evaluation.  I think they're errors in the docume= nt that need to be
corrected, or else things that need to be discussed = and resolved.

The most important in this category, and the only on= e I think will be
difficult to resolve, is how to specify the JSON payl= oad formally.

"COMMENT -- substantive" are those that I would put = in the
non-blocking comments, but that I think are important to deal wi= th,
and that I'd hope we'd have a discussion about if the authors think= a
discussion is necessary.

"COMMENT -- minor" are minor edito= rial issues that I think would be
better corrected, but that I'm not go= ing to grump about further.
Discussion is always welcome, but should be= pretty much unnecessary
for these.

I hope it's useful to get = these comments earlier, rather than later.
And, so, here they are, belo= w.  I've offered suggested text where I
could, and I hope that hel= ps as well.

Barry

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DISCUSS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

-- Section 4 --

  =  o  Device Registration (Section 4.3) MAY be used by the Master D= evice
      and MAY be implemented by the Database, eith= er as a separate
      component or as part of the Avail= able Spectrum Query (Section 4.4)
      component.
<= br> I don't think the first MAY is correct.  If the database requires<= br> registration, it is *not* optional for the Master Device to use it. &nb= sp;I
think this needs some rework.  The same is true with "Device<= br> Validation".

Based on = comments from our AD, we wanted to separate requirements for the
protocol itself from database-specific and r= egulatory-domain requirements. Thus, from
the protocol's perspective, it's a MAY.

Having said th= at, the text can be clarified a bit. Suggestion:

  &= nbsp;o  Device Registration (Section 4.4) MAY be used by the Master De= vice
      and MAY = be implemented by the Database.  When implementing Device
=
      Registration, the Databa= se MAY implement it either as a separate
      component or as part of the Available Spectrum = Query (Section 4.5)
   =   component.

 
=
This list also mixes "used", "supported", and "implemented", without<= br> making all the issues clear.  If something MAY be used, does that = mean
it's optional to implement?  If it MUST be supported, what do= es that
say about its use?  And what's the difference between "sup= ported" and
"implemented"?

Agreed it's confusing. Replaced "supported" by "implemented", since th= at's
what's intended. The work "su= pported" still exists in the doc when referring to
"supporting a set of rules" or "rulesets". There's also a= n added not in the
Terminologies s= ection.
 

I strongly sugg= est that, if you're going to say that, you make it all
clear, as to bot= h implementation/support and use.  The note after the
list that sa= ys that some things are obvious... nah, one of it is
obvious.

= -- Section 4.1 --

   A Database MAY indicate that its UR= I will be changing by including
   the URI of one or more alt= ernate databases (See DbUpdateSpec
   (Section 5.7)) in its r= esponses to a Device.  Before a Database
   ceases opera= tion, for example, it MUST include DbUpdateSpec in its
   res= ponses to notify Devices.

I don't understand how the MAY and MUST = are consistent with each
other.  Can you explain or fix it?

Ah, I see....MAY refers to the D= atabase's ability to change its URI. Reword:

   A Database MAY change its U= RI, but before it changes its URI, it MUST
   indicate = so by including the URI of one or more alternate databases
 = ;  (See DbUpdateSpec (Section 5.7)) in its responses to a Device.
   Before a Database ceases operation, for example, it MUST= include
   DbUpdateSpec in its responses to notify Dev= ices.  
 

-- = Section 4.1.1 --

   When a Listing Server is used, the    Device can save the database list and SHOULD contact the Da= tabase
   Listing Server periodically to update its list. &nb= sp;The time between
   such updates MUST be no longer than on= e week

Here's another 2119 conflict.  It doesn't make sense t= o have a MUST
for the time period if doing it at all is a SHOULD.  = ;Please sort this
one out as well.

You're right. Changed MUST to SHOULD.
 <= /div>

-- Section 4.2

   A Master D= evice SHOULD use the initialization procedure to exchange
   = capability information with the Database whenever the Master Device
&nb= sp;  powers up or initiates communication with the Database.

= But in Section 4 you said "Initialization (Section 4.2) MAY be used by
= the Master Device," and now you're saying "SHOULD"?  You see why I'm on about the 2119 inconsistencies?

The MAY in Section 4 is an oversight. Changed to SHOULD.
 

   When a Master D= evice is
   configured manually with these parameterized-rule= values, it does not
   need to use the initialization proced= ure.

Dos that mean that when it's not configured with them, it *do= es* need
to?  In other words, is this really a "MUST use initializ= ation unless
it's pre-configured with the values" thing?

Thanks. You're right. Reworded:

   When a Master Device is not
   configured manually with these parameterized-rule= values, it MUST use
   = the initialization procedure.



--= Section 4.2.1 --

   deviceDesc:  The DeviceDescrip= tor (Section 5.2) for the Device is
      REQUIRED. &nbs= p;If the Database does not support the device or any of
    &= nbsp; the rulesets specified in the device descriptor, it MUST return an       error with the UNSUPPORTED (Table 1) code in the err= or response.
      If the device descriptor does not con= tain any ruleset IDs, the
      Database SHOULD return a= list of RulesetInfo (Section 5.6)
      parameters for = each ruleset it supports at the specified location.

What this says= to me is that the Master Device uses an empty list of
rulesets to quer= y the list of supported rulesets.  So: how does this
work if the D= atabase does not return its list of rulesets?
Presumably, the Master De= vice did this because it needs the list, and
then it didn't get it. &nb= sp;What does it do now?

Also, this is worded a bit confusingly. &n= bsp;The list is REQUIRED, so it's
not true that the Database SHOULD ret= urn a list.  What you mean to
tell us is what the Database SHOULD = include in the list.  I think it's
really awkward to try to say th= at here in the query, rather than in
the next section in the response.<= br>
Try this:

OLD (Section 4.2.1)
   deviceDesc= :  The DeviceDescriptor (Section 5.2) for the Device is
  &nb= sp;   REQUIRED.  If the Database does not support the device or a= ny of
      the rulesets specified in the device descrip= tor, it MUST return an
      error with the UNSUPPORTED = (Table 1) code in the error response.
      If the devic= e descriptor does not contain any ruleset IDs, the
     = Database SHOULD return a list of RulesetInfo (Section 5.6)
  &nbs= p;   parameters for each ruleset it supports at the specified location= .
NEW
   deviceDesc:  The DeviceDescriptor (Section = 5.2) for the Device is
      REQUIRED.  If the devi= ce descriptor does not contain any ruleset
      IDs, th= e Master Device is asking the Database to return a list of
   = ;   RulesetInfo (Section 5.6) parameters for each ruleset it supports<= br>       at the specified location.
END

OLD (S= ection 4.2.2)
   rulesetInfos:  A list of RulesetInfo (S= ection 5.6) parameters MUST be
      included in the res= ponse.  Each RulesetInfo parameter corresponds
     = ; to a ruleset supported by the Database and is applicable to the
 = ;     location specified in the INIT_REQ (Section 4.2.1) message.=  If
      the Device included a list of ruleset ID= s in the DeviceDescriptor
      parameter of its INIT_RE= Q message, each RulesetInfo parameter in
      the respo= nse MUST match one of the specified ruleset IDs.
NEW
   r= ulesetInfos:  A list of RulesetInfo (Section 5.6) parameters MUST be       included in the response.  Each RulesetInfo pa= rameter corresponds
      to a ruleset supported by the = Database and is applicable to the
      location specifi= ed in the INIT_REQ (Section 4.2.1) message.

      I= f the Device included a list of ruleset IDs in the DeviceDescriptor
&nb= sp;     parameter of its INIT_REQ message, each RulesetInfo param= eter in
      the response MUST match one of the specifi= ed ruleset IDs.

      If the DeviceDescriptor did n= ot contain any ruleset IDs, the
      Database SHOULD in= clude in the list the RulesetInfo parameters for
      e= ach ruleset it supports at the specified location.

    &= nbsp; If the Database does not support the device or any of the rulesets       specified in the DeviceDescriptor, it MUST instead r= eturn an
      error with the UNSUPPORTED (Table 1) code= in the error response.
END

Thanks for the suggestions. Done.
 

-- Section 4.3.2 --

   If the Database = accepts the
   registration for none of the rulesets it suppo= rts, the Database MUST
   return the NOT_REGISTERED error (Se= e Error Codes (Section 5.17)).

I can't follow this sentence at all= .  Do you mean, "If the Database
does not accept the registration = for any of the rulesets" ?  Or do you
mean something else?  C= an you re-word this, please?

Heh, I was afraid "any" is ambiguous.

"If the Database does = not accept the registration for any of the rulesets":

 - = Does that mean if, out of 3, one was not acceptable, it passes the "any" te= st?
 - Or does that mean "non= e of them"

= Hence...the attempt at being more precise by using = "none".


-- Section 5.8 --

&= nbsp;  name:  The display name for a database.  It MAY conta= in UTF-8.

What about all the other strings whose content format is= unspecified?
Are they allowed to contain UTF-8?  If not, what *do= * they contain?

I see that the Gen-ART review mentioned this also,= and the response
will be to specify that all strings are encoded in UT= F-8.  Good.

Done.
 

-- Section 6 --
How is= the reference to JSON Schema [I-D.zyp-json-schema] not
normative, when= the 6.x subsections quite depend upon the
understanding of the schema = format that it describes?

I see that the Gen-ART review mentioned = this also, but the response is
quite troubling.  No, the mechanism= you're using is not sufficiently
self explanatory.  I understand = it -- I do -- but I had to figure it
out (I decided not to go look at t= he Zyp draft), and we can't assume
that arbitrary implementors will get= it right.  We need a well defined
way to explain how JSON objects= are constructed.  And, unfortunately,
the JSON working group chos= e *not* to take on a work item for this
(which I was pushing for).
=
We have at least three proposals (apart from Zyp, there's Newton
(= draft-newton-json-content-rules), and there's the mechanism that I
prop= osed, which is used in Section 6.2 of RFC 7071), but nothing
that's bei= ng taken forward as a standard yet.

I guess the 3rd option is to just describe by example. Hopefully = we can
discuss this at the F2F.
 

-- Section 6.6.2 --
= The schema is missing the optional databaseChange property.
Done 

= -- Section 6.7.1 --
The schema is missing the optional masterDeviceDes= c property.
Done <= /div>
 

-- Section 6.8.11 --
The s= chema says that both properties are optional, but Section 5.14
says tha= t they're both required.
Done&= nbsp;
 

-- Section 6.8.1= 3 --
The schema says that rulesetInfo is optional, but Section 5.9 says=
that it's required.
Done&= nbsp;
 

-- Section 7 --<= br>
   The Database MAY redirect a PAWS request by returning= a HTTP 3xx
   response (as defined by HTTP/1.1 [RFC2616]). ...
   Since the Device may communicate
   w= ith a Database (which it authenticated) without user interaction,
 = ;  when the response code is 301 (Moved Permanently), the Device MAY    redirect without asking a user for confirmation (note that = this
   represents an exception to the HTTP/1.1 [RFC2616] req= uirements for
   HTTP POST methods).

The references = to RFC2616 need to change to RFC7231, now that 2616 is obsolete.
I see = that the Gen-ART review mentioned this also, and you plan to
change the= reference.  This should help you get that right:

The change = to 7231 also means that the note about the second citation
can change. =  2616 said this about redirecting a POST:

--- RFC 2616 ---    If the 301 status code is received in response to a request = other
   than GET or HEAD, the user agent MUST NOT automatica= lly redirect the
   request unless it can be confirmed by the= user, since this might
   change the conditions under which = the request was issued.
----------------

That advice has chang= ed in 7231:

--- RFC 7231 ---
   Automatic redirectio= n needs to done with
   care for methods not known to be safe= , as defined in Section 4.2.1,
   since the user might not wi= sh to redirect an unsafe request.
----------------

In my view,= that means that the parenthesized note in the quote above
can be remov= ed from this document.  I also suggest using a section
number in t= he citation, as you're citing a big document.  So...

OLD
=    The Database MAY redirect a PAWS request by returning a HTTP 3= xx
   response (as defined by HTTP/1.1 [RFC2616]).
NEW    The Database MAY redirect a PAWS request by returning a HTTP= 3xx
   response (as defined by HTTP/1.1 Semantics and Conten= t [RFC7231],
   Section 6.4).
END

OLD
 =  Since the Device may communicate
   with a Database (w= hich it authenticated) without user interaction,
   when the = response code is 301 (Moved Permanently), the Device MAY
   r= edirect without asking a user for confirmation (note that this
  &= nbsp;represents an exception to the HTTP/1.1 [RFC2616] requirements for
=    HTTP POST methods).
NEW
   Since the Device= may communicate
   with a Database (which it authenticated) = without user interaction,
   when the response code is 301 (M= oved Permanently), the Device MAY
   redirect without asking = a user for confirmation, even though it
   is in response to = an HTTP POST request.
END

Done for the above.
 

= -- Section 8.2 --

   The parameter name SHOULD be lower= CamelCase.

Why "SHOULD"?   How does it affect interoperabilit= y?  Wouldn't
"Parameter names use lowerCamelCase by convention." w= ork fine?

Agreed. Changed.=  
 

-- Section 9 --<= br> First, and most importantly, the IANA review interpreted your text to say that the registration policies are Expert Review; I interpret your text to say that they're Specification Required.  Yet Vince replied= to
the IANA review without correcting that.  Which policy do you = intend?
If it is Specification Required, you need to clear that up with= IANA.
Or just deal with my other comments in this section, and that mi= ght
happen anyway.

Tha= nks for pointing that out. I'll add to the comment. 
=  

The text in this section seems to be com= monly copied from somewhere.
Perhaps you could tell me whence you copie= d it, so we can make an
effort to stop people from doing that.

I don't remember precisely, but I = recall I was reviewing some OAUTH docs at the time.
RFC6749
 
=
The first paragraph is entirely unnecessary: please just remove it.

Done 
 

The second paragraph and the list is fi= ne, and the third is mostly OK,
except for the URI.  You'll need t= o ask IANA how they want to receive
requests (by email or through a web= URI), and specify that in
paragraph 3 instead of what's there now.
=

FYI. From http://www.iana.org, you can navigate to= a "Protocol Registration Forms" page to submit requests
= for new assignments.
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
The fourth paragraph really needs to be entirely re-t= hought: it is not
how IANA does expert review in the first place, and w= e shouldn't be
telling IANA how to run their process in the second plac= e.

The fourth paragraph should say that all registries use the
= Specification Required policy [RFC5226], with a Designated Expert
appo= inted by the IESG.  It should note that instructions to the DE as
= to what she should look for and consider in evaluating a request are
gi= ven below in the descriptions of each registry.  It should say that the DE should take advice from the community through the designated
m= ailing list, and that is why the registrant should post to the
mailing = list before formally requesting the registration from IANA.
All the res= t of the mechanics are part of IANA's process, and should
not be specif= ied here.

 Thanks. Pr= oposed text:

   All registries use the Specifica= tion Required policy [RFC5226], with
   a Designated Expert appointed by the IESG.  Specific = criteria that
   the De= signated Expert should use in assessing registrations are given
   below in the description of each= registry.  The Designated Expert
   should take advice from the community through the paws@ietf.org
=
   mailing list, and the registrant= is encouraged to post to the mailing
   list before formally requesting the registration from IANA= .  The
   intentio= n is that new registrations will be accompanied by a
   published specification.  But in orde= r to allow for the allocation of
&= nbsp;  values prior to publication of the specification, the Designate= d
   Expert can approve= allocations once it seems clear that the
   specification will be published.
Is the last part (about allocation before pu= blication of spec) also process that should be omitted?
<= font color=3D"#0000ff">Or are they instructions to the DE?

=

One question: does it make sense for the review list= to be a separate
list, or couldn't the WG mailing list be reused for t= hat purpose?

I don't think= there's a reason not to. Just didn't know the process.
<= font color=3D"#0000ff">Will propose just to use paws@ietf.org.
 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D COMMENT -- substantive =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

General:
You appear to= sometimes use "parameter" to refer to a structure (such
as GeoLocation= ) and also the fields within the parameter (see Section
5.1, for exampl= e).  I find this confusing, and suggest that you do not
use the sa= me term for both.

You're r= ight. Perhaps, when referring to a structure, I should use "object" in the = JSON sense?
 

-- Section = 3 --
In step 4, should this not say a word or two about what message it=
responds with?  Might it respond, "To be, or not to be; that is t= he
question?"  Or is there an expected sort of response?

Changed.
 

Step 5 is the first mention of registration. &nbs= p;A reference to where
that process is explained would be useful here (= as this step doesn't
seem to fit into the flow).

In step 7, th= is is the first mention of a Slave Device, so referring
to "the Slave D= evice" doesn't make sense.  Maybe you want something
like, "If a S= lave Device has made a request to the Master Device, the
Master Device = may verify..." ?

It's not clear how step 7 relates to steps 6 and = 8.

Thanks. Reworded these steps:

  &= nbsp;6.   The Master Device sends an available-spectrum request messag= e to
        the Database.  The mess= age may be on behalf of a Slave Device
       = ; that made a request to the Master Device.

   7. =   If the Master Device is making a request on behalf of a Slave
<= div>        Device, the Master Device may verify with t= he Database that the
        Slave Device is = valid.

   8.   The Database respon= ds with an available-spectrum response
       = ; message in the body of the HTTP response.

 
 

In step 10, might it also s= end an error, refusal, or whatever?  Or are
those all considered a= cknowledgment messages?

Th= is should be considered a notification (fire and forget) call from the Devi= ce.
Suggested rewording:

   9.   The Master Device may send a spectrum-usage noti= fication message
    &nb= sp;   to the Database.  The notification is purely informational.=

   10.  If the Database receives a spectrum-us= age notification message,
  &= nbsp;     it responds by sending the Master Device a spectrum-usa= ge
        ac= knowledgement message.  Since the notification is purely
<= div>        informational, the = Master Device does not need to process the
        Database response. 
=

Hm, it seems that steps 5 and 7 are actually exp= lained in the
paragraph after the numbered steps.  So do they real= ly belong in the
numbered steps at all?

The numbered steps are supposed to correspond to the orde= r in which these steps
happen, so = I think it's important to leave them there.
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
-- Section 5.1 --

   point:  = If present, it indicates that the GeoLocation represents a
   = ;   point.
...
   region:  If present, it indic= ates that the GeoLocation represents a
      region.
=
These make it sound as though these are boolean.  It took me a b= it to
realize that the values of each of these is actually a structure.=  I
think you mean this:

NEW
   point: &nbs= p;If present, it specifies the GeoLocation as a point.
...
  &= nbsp;region:  If present, it specifies the GeoLocation as a region. END

Done. 

-- Section 8.3 --
Please get rid of the MAY = in the first sentence.

Done. 
 

&nb= sp;  If an
   appropriate category does not exist, it ca= n use values in a different
   range.

What is the an= tecedent for "it"?  It looks like it's "an appropriate
category", = but that's clearly not right.  Please fix.

Done. Rewording:

  If an<= /font>
   appropriate category= does not exist, a value from a different range
   may be used. 



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D COMMENT -- minor =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

A small point in the header:
"iconectiv = (formerly Telcordia Interconnection Solutions)"
I think it's fine to pu= t that in the "Authors' Addresses" section, but
the header should just = say "iconectiv".  I realize that takes a little
inconvenient massa= ging of the XML, and probably isn't worth the
trouble for the I-D. &nbs= p;Might just put that in an RFC Editor note....

I'll take a look later :)
 

General:
I like that your citations include th= e document names, as well as the
RFC numbers; thanks!  It would be= better if you put quotation marks
around the document names, to distin= guish them from being part of your
text.

Done.
 

-- Section 1 --

 =  The document describes the use of HTTP/TLS as
   trans= port for the protocol.

This hits what's rather a peeve of mine: HT= TP is not a transport
protocol; the transport protocol you're using is = TCP.

I'd be happier if you said something like this:

OLD<= br>    This specification defines an extensible protocol to obtai= n available
   spectrum from a geospatial database by a devic= e with geo-location
   capability.
NEW
   T= his specification defines an extensible protocol, built on top of
 = ;  HTTP and TLS, to obtain available spectrum from a geospatial databa= se
   by a device with geo-location capability.
END
<= br> ...and then eliminate that last sentence.  See also comments on Section 4 and Section 7.
 
Done.


-- Section 2.2 --

= I suggest this:

OLD
   EIRP:  Effective isotrop= ically radiated power
   ETSI:  European Telecommunicati= ons Standards Institute
   FCC:  Federal Communications = Commission
NEW
   ETSI:  European Telecommunications= Standards Institute <http= ://etsi.org>
   FCC:  The U.S. Federal Communicat= ions Commission <http://fcc= .gov>
END

... and then in Section 9.2.2.7, spell out EI= RP, as it's only used in
that one place.

Done. 

-- Section 3 --
Little grammar nit:
   1. &n= bsp; The Master Device obtains (statically or dynamically) the URI
&nbs= p;       for a Database appropriate for its location to send= subsequent
        PAWS messages.

Make it= "location, to which to send".

Done. 

-= - Section 3.1 --

   These
   requirements = may be complex and involve device behavior that are not
   ea= sily parameterized.

"Device behaviour" is singular, so "that is no= t", please.

Done. 

-- Section 4 --
=
Usage pet peeve: please change "comprise" to "compose", in the one
= place it's used.

   HTTPS Binding (Section 7) describes= the use of
   HTTPS (HTTP Over TLS [RFC2818]) for transporti= ng PAWS messages and
   optional device authentication.
<= br> Please use "transferring", instead of "transporting", to avoid calling<= br> HTTP a transport.

Done. 

-- Section= 4.1.1 --

   TBD Define message format

You miss= ed something here.  Jus' sayin'.

<= span style=3D"color:rgb(0,0,255)">Acknowledged. 

-- Section 4.4.1 --

   Rulesets may mandat= e that it be the Device's
   current location or allow it to = be an anticipated location.

This is probably as good a place as an= y to ask this: is there any
validation of the geo-location at all? &nbs= p;If not, can such a mandate
have any real teeth?  What is this *r= eally* saying?

There is no requirement for Database to validate. Devices typica= lly go through
separate= certification (e.g., FCC) to ensure they conform to the rules. Likewise,
Databases may also need= to be certified, depending on regulatory requirements.


-- Section 4.4.5 --
The table says that "location" = is required, but the text says it's not
always required.  The tabl= e should say "see description".

Done. 

= -- Section 4.5 --

   Typically, a Slave Device needs a M= aster Device to ask the Database
   on its behalf for availab= le spectrum

"Typically"?  Isn't that the *definition* of a Sl= ave Device?

Oops. Done. 

-- Section 5.5= --

   All contact information MUST be expressed using t= he structure defined
   by the vCard Format Specification [RF= C6350].

I think it's best to include both references here, like th= is:

NEW
   All contact information MUST be expressed= using the structure defined
   by the vCard Format Specifica= tion [RFC6350], encoded in JSON [RFC 7095].
END

Done. 

-- Section 5.7 --
The subsections explain what addi= tional "data" field each error might
use, but there are only sections f= or the ones that use the "data"
field.  One has to assume that the= absence of a subsection means that
the "data" field is not used for th= at error.  It would be better to
say that in the table.  I su= ggest adding one sentence to each error
description in the table except= for -104, -105, and -201, as follows:
"This error does not use any add= itional data."

Done. 

-- Section 5.11 = --
The third table should be labelled "SpectrumProfilePoint".

Done.&= nbsp;

-- Section 5.12 --
The second table s= hould be labelled "SpectrumProfilePoint".

Done. 

-- Section 5.17.1 --

   When the error code is= OUTSIDE_COVERAGE, the Database MAY include an
   ErrorData e= lement within its as the "data" field

You're missing the words "Er= ror response" after "within its".

Done. 
-- Section 7 --

   This section describes the use of H= TTP over TLS (HTTPS) HTTP Over TLS
   [RFC2818] as the transp= ort mechanism for the PAWS protocol.

As I've noted earlier, please= say "as the transfer mechanism".  Also,
it's really weird to desc= ribe the document in the same words as the
document title.  I sugg= est just deleting the document title in this
case.  This also appl= ies to Section 10.1.

Done. 

-- Section = 9.1.2 --
The first paragraph was obviously written before the ETSI info= was
added.  Please adjust it accordingly.  (I see that the G= en-ART review
mentioned this too, and it will be fixed.)

Done. =

You might add instructions to the DE with resp= ect to handling
prefixes.  Suppose, for example, I wanted to regis= ter something
starting with "fcc".  Or perhaps with the initials o= f an organization
that hasn't yet registered anything, but reasonably m= ight.

Done. 

-- Section 10.1 --
The= doubled "HTTP over TLS" comment applies here.  Also, it's not at
= all clear, when you say "these checks MAY be omitted," exactly what
che= cks you're saying may be omitted.

Verification of the SANs. Added some text.
<= div> 

   In particular, the
=    validation path of the certificate must end in one of the clie= nt's
   trust anchors, even if that trust anchor is the Datab= ase certificate
   itself.  A Master Device should allow= for the fact that a Database
   can change its certificate a= uthorities (CAs) over time.

Just a question here: did the WG consi= der DANE at all?

It was brought up, but not discussed further. 
=

Another question: is it really necessary to co= ver this stuff here?
Isn't it in 2818?

<= div>I believe the WG thought it would be= good to restate. 

-- Section 10.3 = --

   Using HTTP over TLS, messages protected by appropr= iate cypher suites
   are also protected from eavesdropping o= r otherwise access by
   unauthorized parties en route.
<= br> What does "or otherwise access" mean?  Apart from the grammar prob= lem:
it would be better to say something substantive here, rather than<= br> something vague.

Changed to "or otherwise unrestricted reading".&nbs= p;

-- Section 11 --
I wouldn't usually comm= ent on a "Contributors" section, but it seems
odd to me to cite abandon= ed and long-expired drafts as references.  It
might be better just= to include the draft names, without making them
references.  No? =  You're not actually suggesting that people read
them, just thanki= ng the authors for their contributions.

Done. 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
paws mailing lis= t
paws@ietf.org<= br> https://www.ietf.org/mailman/listinfo/paws


--
-vince

--=20
This message is subject to the CSIR's copyright terms and conditions,= e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,=20
and is believed to be clean.


Please consider the environment before printing this email. --=__Part596BD46D.5__=-- --=__Part596BD46D.4__=-- From nobody Mon Jul 28 09:54:46 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 F15091A0503 for ; Mon, 28 Jul 2014 09:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 VbKCUUvN6qW9 for ; Mon, 28 Jul 2014 09:54:41 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B5F1A0452 for ; Mon, 28 Jul 2014 09:54:41 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so2858496vcb.34 for ; Mon, 28 Jul 2014 09:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wS2fh9igvAExxa3lwff3Eq7McP0CySLOa6NP3aPxYx8=; b=Umr6gjkgq7pAL02vH2BkMIBYh01iL5xVOta9RF4OuGc56nE3fV5eLucwbluus8U9do 1r+gsGBpEgdCQHwl3i16c3iRXYX41pfWgNTEftBR0WWzg0MpwQPz52kMcbyRB1I3VRrM aLA4D+mgwqcxYet8hBveiejYx08dXx1jD+Da5PD12+jq5oTdWD9CIhxoHq+XoGnIld0q qiWKOhp3ek2juoem2HAxEM22xUBqGgN3u0QhlCT7AyDfmJYNlQ8SDg6AkV+lce5W6rQk P93Tt8DVDksPqx3/rqYnxBhojMzZ0Asd8zHFzv7K00v3meuZhdrybvctnp/+Rbl/YFCu mG7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wS2fh9igvAExxa3lwff3Eq7McP0CySLOa6NP3aPxYx8=; b=LSH7++Ht3bzwviUN3I5lyoY1v3+ToLuokB8n1toquWfg5Ir34q3fZjYIbSdWCcBDxv RcWnTtAQdk/0LCuZ6+zD/AGZYddqSn1i5KPOH5T5iT+LTdOociRHD5sHVL8joQsSExIh gUCOX1PPcgGsKqeZcV5/gFvElcklOUMGjYMUHBgVXenTUEwlLD+wvQY+l5ZuDI/1eZXy 1I8veTV0is0CGxksT2iYjmIWZ+QFYW9wowfN+UKQ1lFG+ENBCdWHH57ecXs5xNY3yCkw LSI6uD/cRw8vhx3EKcT2q35YLyB9liwvTOZ77umlGNZs7ns0b0PdLcdi+lj3ZPSzUMmi YVjw== X-Gm-Message-State: ALoCoQmV9bDSLXI65zG27IzQ8PMyCre+nN+J1G1yRV3ZQ5Cs9sEdDtvp9slY4BHam5Hm2PcMrQep MIME-Version: 1.0 X-Received: by 10.52.168.134 with SMTP id zw6mr9774255vdb.37.1406566480520; Mon, 28 Jul 2014 09:54:40 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Mon, 28 Jul 2014 09:54:40 -0700 (PDT) In-Reply-To: <53D3F89D0200009E00099BAB@pta-emo.csir.co.za> References: <53D3F89D0200009E00099BAB@pta-emo.csir.co.za> Date: Mon, 28 Jul 2014 09:54:40 -0700 Message-ID: From: Vincent Chen To: Luzango Mfupe Content-Type: multipart/alternative; boundary=089e016350946cc57e04ff43c7cb Archived-At: http://mailarchive.ietf.org/arch/msg/paws/9vEpsfVpz9tBKhbiVVbn0uMj_yk Cc: "paws@ietf.org" , Barry Leiba Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APP AD) 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, 28 Jul 2014 16:54:43 -0000 --089e016350946cc57e04ff43c7cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Luzango, Thanks for your suggestions. On Sat, Jul 26, 2014 at 9:51 AM, Luzango Mfupe wrote: > Hi Vince, Folks, > > I am glad to see things are moving to the right direction and hopefully > soon we will finalise this work. > > I just found some few not very critical issues that needs some fixing in > in my opinion: > > *5.11. Spectrum* > > > Here the document talk about the FCC and OFCOM/ETSI spectral profile > presentation requirements (i.e, power levels over a set of frequency > ranges. However, there is only one type of example (OFCOM/ETSI specific) > that is provided throughout the document. I think we need to add another > set of example that is FCC specific. > > > Would something like this below suffice for the FCC specific example? > > > > =E2=80=9CresolutionBwHz=E2=80=9D: 1e5, > > =E2=80=9Cprofiles=E2=80=9D: [ > > { > > "Hz": 5.18e8, > > "Hz": 5.24e8, > > =E2=80=9Cdbm=E2=80=9D: 24 > > ] }, > > > > Ah. I see. We can add a single resolution-bandwidth example for completeness. > *6.8.3. Antenna Characteristics* > > We only have the *AMSL* and *AGL *as options for antenna height Types. > > I don't see why we should not also list *HAAT* as a third option, I am > pretty sure this is/can be used in some implementations. > Actually, these height types represents what can be directly measured by the device itself or by the installer. I do not believe HAAT is directly measurable. It also tends to be US-centric. If, however, there were to be new enum values, we could add them via the IANA process. -vince > > Kind Regards, > > *Luzango.* > > > --089e016350946cc57e04ff43c7cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Luzango,

Thanks for your suggestions= .


On Sat= , Jul 26, 2014 at 9:51 AM, Luzango Mfupe <lmfupe@csir.co.za>= wrote:
Hi Vince, Folks,

I am glad to see things are moving to the right direction and hope= fully soon we will finalise this work.

I just found some few not very cri= tical issues that needs some fixing in in my opinion:

<= span style=3D"letter-spacing:0.0px">5.11.=C2=A0 Spectrum


Here the=C2=A0document=C2=A0talk about the FCC and OFCOM/ETSI spectr= al profile presentation requirements (i.e, power levels over a set of=C2=A0= frequency ranges.= =C2=A0However, the= re is only one type of example (OFCOM/ETSI specific) that is provided throu= ghout the document. I think we need to add another set of example that is F= CC specific.=C2=A0


Would something li= ke this below suffice for the FCC specific example?

=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 =C2=A0 =E2=80=9CresolutionBwHz=E2=80=9D: 1e5,=

=C2=A0 =C2=A0 =C2=A0 =E2=80=9Cprofiles=E2=80=9D: [

=C2=A0=C2=A0 =C2=A0 =C2=A0 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Hz": 5.18e8,<= /span>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Hz": 5.24e8,<= /span>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=9Cdbm=E2=80=9D: 24

] =C2=A0 =C2=A0 =C2=A0 },




Ah. I see. We= can add a single resolution-bandwidth example for completeness.
=
=C2=A0
<= div><= div>6.8.3. Anten= na Characteristics=C2=A0

We only hav= e the AMSL and AGL as options for antenna height Types.

I don't= see =C2=A0why we should not also list HAAT as a=C2=A0third=C2=A0opt= ion, I=C2=A0am pretty sure=C2=A0this is/can be used in some implementations= .

Actually, these height t= ypes represents what can be directly measured by the device itself or by th= e installer. I do not believe HAAT is directly measurable.
It als= o tends to be US-centric.

If, however, there were to be new enum values, we could= add them via the IANA process.

-vince
= =C2=A0
<= div>

Kind Re= gards,

Luzango.=


--089e016350946cc57e04ff43c7cb-- From nobody Tue Jul 29 09:49:51 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 D87891A040F for ; Tue, 29 Jul 2014 09:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 PnsMrj23zf3j for ; Tue, 29 Jul 2014 09:49:48 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5671A032A for ; Tue, 29 Jul 2014 09:49:47 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id 10so7150360lbg.12 for ; Tue, 29 Jul 2014 09:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h7YnGn53Z89DChCTzCmT0kige9cspmr4QJK0iEE39SA=; b=Tu9sbd/P+w2IB6BoVMTqh3+V7C7G5X6aUDrrt8Qopay+q/TT0D4CuYuL8r3KvS0q3l AJlEfX6kzNyYhsx+ydxEY3AND2TvV/0vgdMNKxfqKTKrk8MgUtkBgIiBkCu1norEMsKV saGJLBcSSKxYYBi2ZXuM6Unxbn0qJDttgatTto46e6SEdehwN1ql1B6tA7yxP+QqXDPI GKRC9O5UPWGmLZya3ERzrxmAfl6tA3lD68rRJ55af57kDZ5IVYm69mHJBTQMuSJMr/Kq roqdtxTE+pgQTNLHA7R2nJt8+dNlWb5ISqbYvYwfcFe7iH0MzkzCZGU+mKcR478pcm3B e+5Q== MIME-Version: 1.0 X-Received: by 10.152.25.162 with SMTP id d2mr3813164lag.82.1406652585202; Tue, 29 Jul 2014 09:49:45 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Tue, 29 Jul 2014 09:49:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Jul 2014 12:49:45 -0400 X-Google-Sender-Auth: 5Oi3P02XeRiJeWYYhDsnU7moKQI Message-ID: From: Barry Leiba To: Vincent Chen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/xPgGMo9509u7XD5L8i0mckUe2f0 Cc: "paws@ietf.org" Subject: Re: [paws] Review of draft-ietf-paws-protocol-12 (by the other APP AD) 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: Tue, 29 Jul 2014 16:49:50 -0000 Hi, Vince. Sorry not to be responding to this until now, but IETF week got in the way... and we did have a good lunch talk, and dealt with the most important issues. Further comments below, only on things that I think need further comment. For anything you don't see, assume I'm happy with your response and carry on. Barry >> ======================= DISCUSS ======================= >> >> -- Section 4 -- >> >> o Device Registration (Section 4.3) MAY be used by the Master Device >> and MAY be implemented by the Database, either as a separate >> component or as part of the Available Spectrum Query (Section 4.4) >> component. >> >> I don't think the first MAY is correct. If the database requires >> registration, it is *not* optional for the Master Device to use it. I >> think this needs some rework. The same is true with "Device >> Validation". > > Based on comments from our AD, we wanted to separate requirements for the > protocol itself from database-specific and regulatory-domain requirements. > Thus, from the protocol's perspective, it's a MAY. I understand the desire, but I disagree with how you're trying to separate it. From a protocol perspective I absolutely think it's not a MAY: when it's required, it's required... so under some conditions it's optional -- or perhaps even disallowed -- and under others it's required (the protocol doesn't work if you don't do it). > Having said that, the text can be clarified a bit. Suggestion: > > o Device Registration (Section 4.4) MAY be used by the Master Device > and MAY be implemented by the Database. When implementing Device > Registration, the Database MAY implement it either as a separate > component or as part of the Available Spectrum Query (Section 4.5) > component. I don't think this helps. But see below. Below is here. I think that part of the problem is in trying to stuff 2119 key words in where they don't really fit. This list is one of those places. So let me make the suggestion that you take out the 2119 key words from here, and instead talk about what the implementation and use requirements are in understandable plain English. I'll take a stab at it, to show what I mean: o Database Discovery (Section 4.1) is a required component for the Master Device. o Initialization (Section 4.2) is a required component for the Master Device and the Database. It is used by the Master Device when certain necessary information has not been preconfigured. o Device Registration (Section 4.3) is a required component for the Master Device and an optional component for the Database. It can be implemented as a separate component, or as part of the Available Spectrum Query (Section 4.4) component. It is used by the Master Device when the Database requires it. o Available Spectrum Query (Section 4.4) is a required component for the Master Device and the Database. o Spectrum Use Notify (Section 4.4.5) is an optional component for the Master Device and a required component for the Database. Its use by the Master Device is optional; if it is used, the Database is required to accept it. o Device Validation (Section 4.5) is a required component for the Master Device and an optional component for the Database. It is used by the Master Device when the Database requires it. Of course, check that I got those right, and play with them as needed. You certainly could make all the "required" and "optional" into "REQUIRED" and "OPTIONAL", but I don't think it would be doing anyone a service, honestly. See what Pete thinks about this, as you've obviously discussed this bit with Pete before. >> -- Section 4.3.2 -- >> >> If the Database accepts the >> registration for none of the rulesets it supports, the Database MUST >> return the NOT_REGISTERED error (See Error Codes (Section 5.17)). >> >> I can't follow this sentence at all. Do you mean, "If the Database >> does not accept the registration for any of the rulesets" ? Or do you >> mean something else? Can you re-word this, please? > > Heh, I was afraid "any" is ambiguous. > > "If the Database does not accept the registration for any of the rulesets": > > - Does that mean if, out of 3, one was not acceptable, it passes the "any" > test? > - Or does that mean "none of them" > > Hence...the attempt at being more precise by using "none". Ahhhhhhh. I see. I hadn't read it that way. Glrf. How about this, then?: NEW If the Database fails to accept the registration for all of the rulesets it supports, the Database MUST return the NOT_REGISTERED error (See Error Codes (Section 5.17)). END >> -- Section 6 -- >> How is the reference to JSON Schema [I-D.zyp-json-schema] not >> normative, when the 6.x subsections quite depend upon the >> understanding of the schema format that it describes? >> >> I see that the Gen-ART review mentioned this also, but the response is >> quite troubling. No, the mechanism you're using is not sufficiently >> self explanatory. I understand it -- I do -- but I had to figure it >> out (I decided not to go look at the Zyp draft), and we can't assume >> that arbitrary implementors will get it right. We need a well defined >> way to explain how JSON objects are constructed. And, unfortunately, >> the JSON working group chose *not* to take on a work item for this >> (which I was pushing for). >> >> We have at least three proposals (apart from Zyp, there's Newton >> (draft-newton-json-content-rules), and there's the mechanism that I >> proposed, which is used in Section 6.2 of RFC 7071), but nothing >> that's being taken forward as a standard yet. > > I guess the 3rd option is to just describe by example. Hopefully we can > discuss this at the F2F. And we did, and we've decided to go with description by example. This point is settled -- modulo, of course, seeing the result, but I have every confidence. >> The second paragraph and the list is fine, and the third is mostly OK, >> except for the URI. You'll need to ask IANA how they want to receive >> requests (by email or through a web URI), and specify that in >> paragraph 3 instead of what's there now. > > FYI. From http://www.iana.org, you can navigate to a "Protocol Registration > Forms" page to submit requests for new assignments. Right... I was suggesting that you need to sort things out with IANA to make sure you have a form, and work out with IANA the best way to refer to the form here. It might be best to have a URI for the form directly, if IANA thinks it will be persistent. Or perhaps some other advice will be better. But it's probably not best to just tell people to go to the main IANA page, and expect them to click around and find it themselves. > Thanks. Proposed text: > > All registries use the Specification Required policy [RFC5226], with > a Designated Expert appointed by the IESG. Specific criteria that > the Designated Expert should use in assessing registrations are given > below in the description of each registry. The Designated Expert > should take advice from the community through the paws@ietf.org > mailing list, and the registrant is encouraged to post to the mailing > list before formally requesting the registration from IANA. The > intention is that new registrations will be accompanied by a > published specification. But in order to allow for the allocation of > values prior to publication of the specification, the Designated > Expert can approve allocations once it seems clear that the > specification will be published. > > Is the last part (about allocation before publication of spec) also process > that should be omitted? Or are they instructions to the DE? I think that text is fine, and, yes, saying that the DE can approve early allocations is fine -- not all registries are suitable for that. >> ======================= COMMENT -- substantive ======================= >> >> General: >> You appear to sometimes use "parameter" to refer to a structure (such >> as GeoLocation) and also the fields within the parameter (see Section >> 5.1, for example). I find this confusing, and suggest that you do not >> use the same term for both. > > You're right. Perhaps, when referring to a structure, I should use "object" > in the JSON sense? I think we've settled on "structure" for this, so this one's done also. >> Hm, it seems that steps 5 and 7 are actually explained in the >> paragraph after the numbered steps. So do they really belong in the >> numbered steps at all? > > The numbered steps are supposed to correspond to the order in which these > steps happen, so I think it's important to leave them there. Indeed, and your re-wording of the various steps looks good to me; thanks. >> ======================= COMMENT -- minor ======================= All OK in this section >> ============================================== From nobody Tue Jul 29 18:55:37 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 403E91B2A38; Tue, 29 Jul 2014 18:55:34 -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 rvwv0qJpckci; Tue, 29 Jul 2014 18:55:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 016BE1B29ED; Tue, 29 Jul 2014 18:55:33 -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.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140730015533.11945.80335.idtracker@ietfa.amsl.com> Date: Tue, 29 Jul 2014 18:55:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/HtimHaKuNuJhQB0POLxVfulmmi8 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-13.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: Wed, 30 Jul 2014 01:55:34 -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-13.txt Pages : 88 Date : 2014-07-29 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 managing 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-13 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/ From nobody Tue Jul 29 19:10:17 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 5B4F11B2A58 for ; Tue, 29 Jul 2014 19:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 wwb5jaT4nd-p for ; Tue, 29 Jul 2014 19:10:12 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946521B2A54 for ; Tue, 29 Jul 2014 19:10:11 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so842610vcb.34 for ; Tue, 29 Jul 2014 19:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iBpbzUhMng70XGe0j6HhmvatZyMpVndESsAqY3d2ydY=; b=pzAwdKAZz5KBxeRA6aq3LASyBh0U8ZiQkL44L8O3xuXOoZymo9eyuRrvypHUxGlZE0 TsWqgNBieKXbXMkglEASkHqH2hnzTsapSDC9Ihr0HbdsWxVnm0dab5vc6aLlIKUAIHGY Td+0IYSouOvc9LIcZqTZuZaQkMMnERsDWPLaynHN7sXmcmbTjxI5hmwikD6w95ZBr+CN VI0esmzWWgyFWg2A8mxrmAcWbfkleXLXdsnIYZ2qhiU8kyEyUR4x6C9hles13ikHEyIL sFZU3IzdTydIs7HyTJYc3QgLXpk91QSajB8YCwacRBO9/A+AkOVYeUunI18irnGUEEku BimQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=iBpbzUhMng70XGe0j6HhmvatZyMpVndESsAqY3d2ydY=; b=by8s6n1XQoii4wPadR/n17IK5kmQhUjlp6BohTLAms1sqNR+EcH27Q0ZfUTpWkGvw7 5tfP2Li18ghYOQVGZ2KYQlgh4LGU6fOj1gnbmhX2fFCEs6E/yoq/f6cIhfS3JDNHIO5V ew36gKN3xsMmJa7SUE2OTP4M18Y5iGuhUC9du3hGe3XQza0aSHlgGxWKj83sXKHd4EGN VMu0I/hI8fn+su9fBC4C0fJnQ/fCAoDO48H152ItNOhX/ONXmIQ4bXUNdp/scri9bq7p it0fSpSumiQyt455eeAq7goMJHlWKknuFqAvM++/4GYjgKWHLLyQDf/yu8+pobdSq3Lk 2G5A== X-Gm-Message-State: ALoCoQkZPBEpxKzjGtMUKwkvQabNsEqIQpDJXSA1IWlUIdsQ46lToVJKiZfHaSMyPqdCrSwYrDHA MIME-Version: 1.0 X-Received: by 10.220.167.2 with SMTP id o2mr938393vcy.8.1406686210658; Tue, 29 Jul 2014 19:10:10 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Tue, 29 Jul 2014 19:10:10 -0700 (PDT) Date: Tue, 29 Jul 2014 19:10:10 -0700 Message-ID: From: Vincent Chen To: Barry Leiba , Robert Sparks , "paws@ietf.org" , Pete Resnick Content-Type: multipart/alternative; boundary=089e011618cee5b49b04ff5fa730 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/sCoOmV_Tp0J6sFQCICUsudKYbSM Subject: [paws] New PAWS draft uploaded 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: Wed, 30 Jul 2014 02:10:13 -0000 --089e011618cee5b49b04ff5fa730 Content-Type: text/plain; charset=UTF-8 All, I've uploaded a new draft of PAWS that I believe addresses all the points raised by the ADs, Gen-ART, and at the F2F. The major change is the simplification of Section 6 for JSON encoding, reducing it to a number of examples. Summary of changes: o Define primitive types in Section 4, specifying UTF-8 for strings and remove UTF-8 references elsewhere. o Replace or rephrase "parameter" when reference is to higher-level structure. o Replace "MUST" with non-2119 language (maximum length is xxx octets. o Rephrase statements that reflected regulatory, not PAWS requirements (e.g., deletion of "MUST" or "MAY" and rephrasing as a regulatory requirement). o Replace "Paws protocol (redundant) to "PAWS" o Change "geo-location" to "geolocation" o General references to "Database" changed to "database." o Simplify Section 6 by showing several JSON encoding examples. o Change "Device" to "device" o Moved treatment of List Server as discovery mechanism to Appendix and added JSON-encoded DB List Server response example. Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-13 Please take a look and comment. Thanks! -- -vince --089e011618cee5b49b04ff5fa730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

I've uploaded a new draft of P= AWS that I believe addresses all the points raised by
the ADs, Ge= n-ART, and at the F2F.

The major change is the sim= plification of Section 6 for JSON encoding, reducing it to a number of exam= ples.

Summary of changes:
   o  Define primitive typ=
es in Section 4, specifying UTF-8 for strings
      and remove UTF-8 references elsewhere.

   o  Replace or rephrase "parameter" when reference is to higher=
-level
      structure.

   o  Replace "MUST" with non-2119 language (maximum length is xx=
x
      octets.

   o  Rephrase statements that reflected regulatory, not PAWS
      requirements (e.g., deletion of "MUST" or "MAY" a=
nd rephrasing as
      a regulatory requirement).

   o  Replace "Paws protocol (redundant) to "PAWS"

   o  Change "geo-location" to "geolocation"

   o  General references to "Database" changed to "database.=
"

   o  Simplify Section 6 by showing several JSON encoding examples.

   o  Change "Device" to "device"

   o  Moved treatment of List Server as discovery mechanism to
      Appendix and added JSON-encoded DB List Server response example.


Please take a look and comment. Thanks!
--
-vi= nce
--089e011618cee5b49b04ff5fa730-- From nobody Thu Jul 31 11:20:11 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 4A5051A030C for ; Thu, 31 Jul 2014 11:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 vELeR-P8jJEH for ; Thu, 31 Jul 2014 11:20:06 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDAE1A0303 for ; Thu, 31 Jul 2014 11:20:05 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so4845889vcb.8 for ; Thu, 31 Jul 2014 11:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7VKjP3GfDADFBCPwa9BrZCCmtYFKLUMaBqQBK6kATsY=; b=o6G5kBOx2dxwhhSRYhCGs+ijhNlj1DR5+N1+7esML1f+JW80mwbUtu52GM70R+ka91 93c44jWpiNw/guJE4wf7jeCT5+R6zzBqtN3TrI6jnHyE/prlUx2oheF8VZ6JlQBHbdup bgmY/toSuQDmpKzbDvgKXtYvF/8Ww8YSZIpCFQYPaC+4u/MGB13QJ7hsHP3jpF/OpjYY +cEaQJj17qpY/qyDQPrxeyAMSOtD3xJaq4+xtLLCBc9Vp+zNXG2ROCQ8JjDJB+94wFEj em652iWLn3UHtMFTc1mS4qbH3e/FqruQEEgs48M0kARSPWwKoyCKqL8159pFD51TEpjX Pf1A== MIME-Version: 1.0 X-Received: by 10.220.144.147 with SMTP id z19mr15293400vcu.26.1406830804692; Thu, 31 Jul 2014 11:20:04 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.181.71 with HTTP; Thu, 31 Jul 2014 11:20:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 14:20:04 -0400 X-Google-Sender-Auth: w_XLdqGkNPyQJEoHwwGrFugcezo Message-ID: From: Barry Leiba To: Vincent Chen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/e3T5WxQwsLCMjUitRBmOV7FqlD8 Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] New PAWS draft uploaded 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: Thu, 31 Jul 2014 18:20:08 -0000 > I've uploaded a new draft of PAWS that I believe addresses all the points > raised by the ADs, Gen-ART, and at the F2F. Vince, thanks so much for the quick work on getting this done. Essentially all my points have been addressed. I have this ready to post as a non-blocking, minor comment whenever Pete creates a ballot for the document: ---------------------------------------- A small point in the header: "iconectiv (formerly Telcordia Interconnection Solutions)" I think it's fine to put that in the "Authors' Addresses" section, but the header should just say "iconectiv". I realize that takes a little inconvenient massaging of the XML, and probably isn't worth the trouble for the I-D. Might just put that in an RFC Editor note.... -- Section 2.2 -- As a very minor thing, I suggest this (adding URIs for the agencies, and specifying "U.S." for FCC): OLD ETSI: European Telecommunications Standards Institute FCC: Federal Communications Commission NEW ETSI: European Telecommunications Standards Institute FCC: The U.S. Federal Communications Commission END -- Section 6 -- As I had concerns in version -12 with the use of JSON schema language that hasn't been fully specified and is in an expired I-D, I should explicitly say that I'm happy with what Section 6 and its subsections look like in version -13. Thanks for the fix! ---------------------------------------- Barry From nobody Thu Jul 31 12:17:35 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 1B2B71A00C2 for ; Thu, 31 Jul 2014 12:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 79bIlRt6rXFX for ; Thu, 31 Jul 2014 12:17:31 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F521A008C for ; Thu, 31 Jul 2014 12:17:31 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id ij19so4895225vcb.25 for ; Thu, 31 Jul 2014 12:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z/QDiwu763Kve2dPl4qrN+lQgA2q2ZFS/VkXwvKSXjM=; b=bGntB7OoCrEK0SIBCLXBhytIwglU9fhKMRXZP1a+tnityBj3+y0AuBwPJphL8uLOPv SimZ6P4j4iWRPigimdN8jwZt6+rC1bJpXV3XubkhJ7dn8dZTM7EEtOtU0AEdySCDA1jd DYIdwlWmTiekJSNPWTijNYNhJm+3cb7f+OroZlAy32JrNoQ648zielfn2N+JkcK3xaaQ zbUx3Ij8stG/RCoX+JMXk0ivjSXFMLNcNNmxsDdeZ4prpfdSIsAe7emmmSl2o8NXpBoh 3AQZsBoJnc/z4EbYkDRlwdl4Gf260eBNzk9CFNgDT+e2NvpyAQ91NR4VcD9WnEB2MN3h ddkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z/QDiwu763Kve2dPl4qrN+lQgA2q2ZFS/VkXwvKSXjM=; b=N8rgrFch3O1TKyLTjjExqZu/Gtu3d/8+so6V6P8rVeyEkH2Q6x45kho5PQ1C0Q5D4j TKGfPQ7mBC1l6BVYXFnX7E8+PFg+6ZLthpEjnGBzWHh0uP2jvUsOBsLVQ3h0sImLMpW+ pJTSPtOZw8nBXdRql1XzunMJC/odCeuASAySUmpJm80xFoW19POyQdAHf1F8zsYouV1q 3FtNtYe4o8QsdwlwQmQ+IusM582M7bGRbCmueJqyplmo9IOI1S75aIQhjuy7p/iR2XO6 9L4ETqQRjTiAqIxG8+QJUHco/tjkgqmX8iRwZovxAKZJoeqm6+MWEEAfzDB3I+NdfGMS FCxw== X-Gm-Message-State: ALoCoQkniLEReApBowNS59PAqcR62gUv+1wkSgYno9R+MZLrUj/j8yucBO+RBx+Rroiw89mU7fgr MIME-Version: 1.0 X-Received: by 10.220.252.198 with SMTP id mx6mr366937vcb.15.1406834250412; Thu, 31 Jul 2014 12:17:30 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Thu, 31 Jul 2014 12:17:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 12:17:30 -0700 Message-ID: From: Vincent Chen To: Barry Leiba Content-Type: multipart/alternative; boundary=089e013a044ac1147404ff821fae Archived-At: http://mailarchive.ietf.org/arch/msg/paws/FPsPx2dhhsozh2sVez8jJeLhgQY Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] New PAWS draft uploaded 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: Thu, 31 Jul 2014 19:17:33 -0000 --089e013a044ac1147404ff821fae Content-Type: text/plain; charset=UTF-8 Barry, Thanks for the review! On Thu, Jul 31, 2014 at 11:20 AM, Barry Leiba wrote: > > I've uploaded a new draft of PAWS that I believe addresses all the points > > raised by the ADs, Gen-ART, and at the F2F. > > Vince, thanks so much for the quick work on getting this done. > Essentially all my points have been addressed. I have this ready to > post as a non-blocking, minor comment whenever Pete creates a ballot > for the document: > > ---------------------------------------- > A small point in the header: > "iconectiv (formerly Telcordia Interconnection Solutions)" > I think it's fine to put that in the "Authors' Addresses" section, but > the header should just say "iconectiv". I realize that takes a little > inconvenient massaging of the XML, and probably isn't worth the > trouble for the I-D. Might just put that in an RFC Editor note.... > Done. Added an RFC Editor note. > > -- Section 2.2 -- > As a very minor thing, I suggest this (adding URIs for the agencies, > and specifying "U.S." for FCC): > > OLD > ETSI: European Telecommunications Standards Institute > FCC: Federal Communications Commission > NEW > ETSI: European Telecommunications Standards Institute > > FCC: The U.S. Federal Communications Commission > > END > > Done. Thanks for the reminder on adding "U.S.". > -- Section 6 -- > As I had concerns in version -12 with the use of JSON schema language > that hasn't been fully specified and is in an expired I-D, I should > explicitly say that I'm happy with what Section 6 and its subsections > look like in version -13. Thanks for the fix! > I'm glad it was rather painless :) > ---------------------------------------- > > Barry > Given that I want to update the IANA language some more, I have another draft ready to upload (incorporating these changes). Should I do that now? -- -vince --089e013a044ac1147404ff821fae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Barry,

Thanks for the review!


On Thu, Jul 31, 2= 014 at 11:20 AM, Barry Leiba <barryleiba@computer.org>= wrote:
> I've uploaded a new= draft of PAWS that I believe addresses all the points
> raised by the ADs, Gen-ART, and at the F2F.

Vince, thanks so much for the quick work on getting this done.
Essentially all my points have been addressed. =C2=A0I have this ready to post as a non-blocking, minor comment whenever Pete creates a ballot
for the document:

----------------------------------------
A small point in the header:
"iconectiv (formerly Telcordia Interconnection Solutions)"
I think it's fine to put that in the "Authors' Addresses"= section, but
the header should just say "iconectiv". =C2=A0I realize that take= s a little
inconvenient massaging of the XML, and probably isn't worth the
trouble for the I-D. =C2=A0Might just put that in an RFC Editor note....

Done. Added an RFC Editor note.
=C2=A0

-- Section 2.2 --
As a very minor thing, I suggest this (adding URIs for the agencies,
and specifying "U.S." for FCC):

OLD
=C2=A0 =C2=A0ETSI: =C2=A0European Telecommunications Standards Institute =C2=A0 =C2=A0FCC: =C2=A0Federal Communications Commission
NEW
=C2=A0 =C2=A0ETSI: =C2=A0European Telecommunications Standards Institute =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://etsi.org>
=C2=A0 =C2=A0FCC: =C2=A0The U.S. Federal Communications Commission
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://fcc.gov>
END


Done. Thanks for the reminder on addin= g "U.S.".
=C2=A0
-- Section 6 --
As I had concerns in version -12 with the use of JSON schema language
that hasn't been fully specified and is in an expired I-D, I should
explicitly say that I'm happy with what Section 6 and its subsections look like in version -13. =C2=A0Thanks for the fix!
I'm glad it was rather painless :)
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> ----------------------------------------

Barry

Given that I want to update the IANA language some m= ore, I have another draft ready to upload (incorporating these changes). Sh= ould I do that now?

--
-vince --089e013a044ac1147404ff821fae-- From nobody Thu Jul 31 12:31:11 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 0C22E1A0084 for ; Thu, 31 Jul 2014 12:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 QHf1YZLg8IAt for ; Thu, 31 Jul 2014 12:31:09 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D39591A0058 for ; Thu, 31 Jul 2014 12:31:08 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so2465708lam.14 for ; Thu, 31 Jul 2014 12:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QXhWvVsbLBBbKynQhqaPLoK+SDr3euWSb3zeCuKwuXY=; b=ayP2mSAaXY3s5TGu2KmlMbPW7NNFKJsqgN0zgE6P/xrdXRs9eflu0zRFjDUI0aeO/i rO3UDA7YZorscNokxFbt1wVllTaU4Ci6kHZUxcy1otzSyqKSf98c6pJ9Fa3K9yqlJK4z /yVM5lEf4kiQPHhSJqTsZiVMQX//JJ0ZSRMdeYrHyQ15gkS7mCk06JiiqDjlKKFjzh+V bhbsqX1PwRC6B8KM+fEMsBnlVSvI1vqpBIUYacgPrXJEZjEsKvtJaqcZCM+mYO9xTEhB XQSoFQyjd3bxyjXTNiKwxhKb7jiuwCHdvelmMrMs3y0yEflAjURBSjVIY2JK4Uo6ya95 e8ow== MIME-Version: 1.0 X-Received: by 10.153.4.37 with SMTP id cb5mr350609lad.3.1406835067191; Thu, 31 Jul 2014 12:31:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Thu, 31 Jul 2014 12:31:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 15:31:07 -0400 X-Google-Sender-Auth: hPtvSN3L0wkXifFFBo-bShi4CXs Message-ID: From: Barry Leiba To: Vincent Chen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/pU7Izhz2OK9kQriUzFJJilMzxtY Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] New PAWS draft uploaded 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: Thu, 31 Jul 2014 19:31:10 -0000 > Given that I want to update the IANA language some more, I have another > draft ready to upload (incorporating these changes). Should I do that now? I think you should, unless Pete has other ideas for some reason. As I always say: revisions are cheap. b From nobody Thu Jul 31 12:33:20 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 550BB1A0142 for ; Thu, 31 Jul 2014 12:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 S1FvDvT14iXY for ; Thu, 31 Jul 2014 12:33:15 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB79E1A011E for ; Thu, 31 Jul 2014 12:33:15 -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=1406835195; x=1438371195; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DQfGA7Jb+yEGzTN9RNDm1QEJY55x/yYlGO75+NyJuD8=; b=uvVH0wISOnPjsGe1c6Bp/dKTr/pTOLzuOoP9tQdY/R74hHh2yNQqUphp IlMCEkX4lbfWqsYQwCeg0xpHWBPybJmBe9A8cjLtioUz+GjJE1ty45A44 dNq1cBK1zCKtRZFEZRN9cVP45JeBU1B68EeuxbtaPEoZ8OiyM0OpjIMYC I=; X-IronPort-AV: E=McAfee;i="5600,1067,7516"; a="55239437" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 31 Jul 2014 12:33:15 -0700 X-IronPort-AV: E=Sophos;i="5.01,774,1400050800"; d="scan'208";a="776769139" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jul 2014 12:33:16 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 31 Jul 2014 12:33:14 -0700 Message-ID: <53DA99F9.4050508@qti.qualcomm.com> Date: Thu, 31 Jul 2014 14:33:13 -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: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/paws/BBsrqMbCXWEUHM7u4vh-uj4ycus Cc: "paws@ietf.org" Subject: Re: [paws] New PAWS draft uploaded 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: Thu, 31 Jul 2014 19:33:18 -0000 On 7/31/14 2:31 PM, Barry Leiba wrote: >> Given that I want to update the IANA language some more, I have another >> draft ready to upload (incorporating these changes). Should I do that now? >> > I think you should, unless Pete has other ideas for some reason. As I > always say: revisions are cheap. > Yeah, please go right ahead. Once I hear from Robert, I will likely send this out for a second Last Call, given the extent of the changes, so having the latest-and-greatest in there would be good. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Jul 31 12:48:20 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 6DAD01A000F; Thu, 31 Jul 2014 12:48:17 -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 ze7MjCArFjll; Thu, 31 Jul 2014 12:48:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D641A0028; Thu, 31 Jul 2014 12:48:16 -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.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731194816.535.96765.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 12:48:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/tD2BxdtUBD11cTydLBjw_mJ5RQc Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-14.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: Thu, 31 Jul 2014 19:48:17 -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-14.txt Pages : 89 Date : 2014-07-31 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 managing 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-14 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/ From nobody Thu Jul 31 12:49:05 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 99D8E1A0028 for ; Thu, 31 Jul 2014 12:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 wr2XYDRwmicD for ; Thu, 31 Jul 2014 12:49:01 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F7C1A000F for ; Thu, 31 Jul 2014 12:49:01 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so5068223vcb.4 for ; Thu, 31 Jul 2014 12:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gh1rvYE7eVnLWyN8wbXEq8PM3T/EuMXXjUx2fw2y1Ow=; b=anMfab17f96z6MJK3Tj7xTb32Qykp5VN6jqVlm3xpe+ueSFnJEe4Ir3dZD6td+0tjN J3p75ZAlo4gUgM/peXSGM6w3oAm5p+x9bfqexGy0JXwiphK/MhMc+5RdRNOvYQV3Q+np jjQ+xK3ycbkKHwO8XTC8DQO8wdEYO5Rz1rDZLAqIrwTor83zKYJ5tm7v4jMvNbtVX+2q 7Cw1mzskYD8tszYRdJ0RNofbP+b+t3ghzajkSo69ub9LSTcjkSjVMMuq0jiIZrqdK205 cbvZYZ6krCSlOHDKYsI+TmIwCs9g5XdpDlUMH/bok+U8NEmAlxD7XBOdNQdVanSuFrFE FVjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gh1rvYE7eVnLWyN8wbXEq8PM3T/EuMXXjUx2fw2y1Ow=; b=E9LMwHbj2Egk/9dD7b0pHWbfmTtQBCbcR1lQ3KZS7irLuAAfASNO1JN9LKSaB+KLnr GjpRAK7juYIaVpHdy8to62J71XF2PSbdsrUbQRe/W+cm2IuzTii4pHdOSIyPvwNKht8i L7mYfb9cnn9RUYzhL1HBl0aIkuYvr9DBgH6At8gHZduq9U9GvOCvO2yQ0061wyyGqBPH chFlTmCBrx566Viz87Vq94a0Px25+6I31whCXpyztOQ+tCC+8dZPBBPlDSi48EZNRDl6 fRhwF+pSL+5UcmkMZGdpAq/GF+mnb+9thaLZhO53uQQ8v+1K3DURHl1EygzeCg7qWrrH D8qw== X-Gm-Message-State: ALoCoQmDWB8LroEuTksbNhR1b34kpX56Edc4Uyu3TXpT0pX/pEwSxohqSR8b8XZZfNnFYFe/ktji MIME-Version: 1.0 X-Received: by 10.52.168.134 with SMTP id zw6mr531273vdb.37.1406836140715; Thu, 31 Jul 2014 12:49:00 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Thu, 31 Jul 2014 12:49:00 -0700 (PDT) In-Reply-To: <53DA99F9.4050508@qti.qualcomm.com> References: <53DA99F9.4050508@qti.qualcomm.com> Date: Thu, 31 Jul 2014 12:49:00 -0700 Message-ID: From: Vincent Chen To: Pete Resnick Content-Type: multipart/alternative; boundary=089e016350946cd2f504ff829055 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/wZyu-_smOwjg1V9eSfLEAmupggg Cc: "paws@ietf.org" , Barry Leiba Subject: Re: [paws] New PAWS draft uploaded 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: Thu, 31 Jul 2014 19:49:04 -0000 --089e016350946cd2f504ff829055 Content-Type: text/plain; charset=UTF-8 Thanks. Draft 14 uploaded. -vince On Thu, Jul 31, 2014 at 12:33 PM, Pete Resnick wrote: > On 7/31/14 2:31 PM, Barry Leiba wrote: > >> Given that I want to update the IANA language some more, I have another >>> draft ready to upload (incorporating these changes). Should I do that >>> now? >>> >>> >> I think you should, unless Pete has other ideas for some reason. As I >> always say: revisions are cheap. >> >> > > Yeah, please go right ahead. Once I hear from Robert, I will likely send > this out for a second Last Call, given the extent of the changes, so having > the latest-and-greatest in there would be good. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -- -vince --089e016350946cd2f504ff829055 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. Draft 14 uploaded.

-vince
=


On Thu,= Jul 31, 2014 at 12:33 PM, Pete Resnick <presnick@qti.qualcomm.com= > wrote:
On 7= /31/14 2:31 PM, Barry Leiba wrote:
Given that I want to update the IANA language some more, I have another
draft ready to upload (incorporating these changes). Should I do that now?<= br> =C2=A0 =C2=A0 =C2=A0
I think you should, unless Pete has other ideas for some reason. =C2=A0As I=
always say: revisions are cheap.
=C2=A0 =C2=A0

Yeah, please go right ahead. Once I hear from Robert, I will likely send th= is out for a second Last Call, given the extent of the changes, so having t= he latest-and-greatest in there would be good.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478




-- -vince
--089e016350946cd2f504ff829055-- From nobody Thu Jul 31 14:55:36 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 AF7E71A0195 for ; Thu, 31 Jul 2014 14:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 5H869oJRDxlG for ; Thu, 31 Jul 2014 14:55:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA4D1A0191 for ; Thu, 31 Jul 2014 14:55:32 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VLtS1C094108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Thu, 31 Jul 2014 16:55:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53DABB50.3030200@nostrum.com> Date: Thu, 31 Jul 2014 16:55:28 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pete Resnick , Barry Leiba References: <53DA99F9.4050508@qti.qualcomm.com> In-Reply-To: <53DA99F9.4050508@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/paws/rqJw58z5NRu_tLi25DG9tyY0q_w Cc: "paws@ietf.org" Subject: Re: [paws] New PAWS draft uploaded 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: Thu, 31 Jul 2014 21:55:33 -0000 This all looks very good to me. I've reviewed the diff between 12 and 14, and read through 14. Thanks for the very nice work on simplifying section 6, Vincent! This isn't worth holding the document up in any way, but as it's going through the rest of it's processing consider, in 6.1, saying that the id should be generated uniquely enough to allow the use of JSON-RPC batch? RjS On 7/31/14, 2:33 PM, Pete Resnick wrote: > On 7/31/14 2:31 PM, Barry Leiba wrote: >>> Given that I want to update the IANA language some more, I have another >>> draft ready to upload (incorporating these changes). Should I do >>> that now? >> I think you should, unless Pete has other ideas for some reason. As I >> always say: revisions are cheap. > > Yeah, please go right ahead. Once I hear from Robert, I will likely > send this out for a second Last Call, given the extent of the changes, > so having the latest-and-greatest in there would be good. > > pr > From nobody Thu Jul 31 21:47:19 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 3C63E1A03ED for ; Thu, 31 Jul 2014 21:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 6VBsBAb07WCM for ; Thu, 31 Jul 2014 21:47:17 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FE51A03E4 for ; Thu, 31 Jul 2014 21:47:16 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf12so5878197vcb.12 for ; Thu, 31 Jul 2014 21:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=twQrzCWaA9vwOjH7YvCZRBHqlm847rFk3EvCqtzh5Jk=; b=fLR3Y/UyeiBAnoskEQ2rSQNBA6+BnWXMYFzvxF0ya9p4itWoH2tgbi8+AfsQzlKY94 F0sANkz1s3Y7qVvg1xiYi7Y9GrB7u7jgrAqHVWpYaF/MjUpwhnfblegPIiG8Xfz7rLkK fNiDDyYFn7ixNMUXvl5iq9/jTY/16au4LbEygs58OleasNvMALKqXTogB4n97Bb3Ql+G VnMmbjkzJuMosKva0KLRohVZ5kcxT++udcmaTzJ4iGEEeKAvllLUIlZX7inIL1Y77Sbf IKN/3yiPyWbwTj3+2I+hVLzbdZWb9hcxY9fl6rqYLTOfyCU47FArLJ5OmxsUDGAorF6W y3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=twQrzCWaA9vwOjH7YvCZRBHqlm847rFk3EvCqtzh5Jk=; b=IEsQ0ujW8mHyCLXbhymr0lEIUs81aVotrHuEpn9gpgfQ1KYjcoBLCZK1FzcdnxKv4L RE/9IXTBfc3gdxBVBsc/hlxl5Qg4CvEE38KPrxaqKH0v83p+iszYUmoC9zz3Hx4EjOOE O9lJjx2mqP1/ZCePWy8sx73QrUS7y/pYKTJAtFUaQBwaGOqEDFDkzTDiJxPtLC0He7Ij XT1wq+Z49DNxjR42r9d5hpWXAIaC4B62GTrxCy/B/o00UZuDC+Hv+c/aXf/e5fMvbP8I 7e+DY40hQepvQATrIzDGksMEsRb09dSHdAauG3xRlVC7DQDb7HCWnjAF96iItArUB7QK dDUg== X-Gm-Message-State: ALoCoQn/QV2PX4L/rq+1rEXqQATGaLiPr1f5afa9UPk1DKePuWtVrvcQWpz6PsGwhJFVJkHwKGq4 MIME-Version: 1.0 X-Received: by 10.52.239.6 with SMTP id vo6mr2791317vdc.59.1406868435830; Thu, 31 Jul 2014 21:47:15 -0700 (PDT) Received: by 10.52.118.3 with HTTP; Thu, 31 Jul 2014 21:47:15 -0700 (PDT) In-Reply-To: <53DABB50.3030200@nostrum.com> References: <53DA99F9.4050508@qti.qualcomm.com> <53DABB50.3030200@nostrum.com> Date: Thu, 31 Jul 2014 21:47:15 -0700 Message-ID: From: Vincent Chen To: Robert Sparks Content-Type: multipart/alternative; boundary=001a1135f4765d22db04ff8a154e Archived-At: http://mailarchive.ietf.org/arch/msg/paws/1zSKlN7At0IEBKm8kh9XcgyTuzE Cc: "paws@ietf.org" , Pete Resnick , Barry Leiba Subject: Re: [paws] New PAWS draft uploaded 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: Fri, 01 Aug 2014 04:47:18 -0000 --001a1135f4765d22db04ff8a154e Content-Type: text/plain; charset=UTF-8 Robert, Thanks for the review. On Thu, Jul 31, 2014 at 2:55 PM, Robert Sparks wrote: > This all looks very good to me. > > I've reviewed the diff between 12 and 14, and read through 14. > Thanks for the very nice work on simplifying section 6, Vincent! > > This isn't worth holding the document up in any way, but as it's going > through the rest of it's processing > consider, in 6.1, saying that the id should be generated uniquely enough > to allow the use of JSON-RPC batch? > Hmmm...I'm now not sure we should support JSON-RPC batching, since batching is built into some of the PAWS methods: - AVAIL_SPECTRUM_BATCH_REQ - DEV_VALID_REQ It might get confusing to support two different mechanisms. > > RjS > > > > On 7/31/14, 2:33 PM, Pete Resnick wrote: > >> On 7/31/14 2:31 PM, Barry Leiba wrote: >> >>> Given that I want to update the IANA language some more, I have another >>>> draft ready to upload (incorporating these changes). Should I do that >>>> now? >>>> >>> I think you should, unless Pete has other ideas for some reason. As I >>> always say: revisions are cheap. >>> >> >> Yeah, please go right ahead. Once I hear from Robert, I will likely send >> this out for a second Last Call, given the extent of the changes, so having >> the latest-and-greatest in there would be good. >> >> pr >> >> > -- -vince --001a1135f4765d22db04ff8a154e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robert,

Thanks for the review.


On Thu, Jul 31, = 2014 at 2:55 PM, Robert Sparks <rjsparks@nostrum.com> wro= te:
This all looks very good to me.

I've reviewed the diff between 12 and 14, and read through 14.
Thanks for the very nice work on simplifying section 6, Vincent!

This isn't worth holding the document up in any way, but as it's go= ing through the rest of it's processing
consider, in 6.1, =C2=A0saying that the id should be generated uniquely eno= ugh to allow the use of JSON-RPC batch?

Hmmm...I'm now not sure we should support JSON-RPC batching, since bat= ching is built into some of the
PAWS methods:

=C2=A0- AVAIL_SPECTRUM_BATCH_RE= Q
=C2=A0- DEV_VALID_REQ

It might get con= fusing to support two different mechanisms.
=C2=A0

RjS



On 7/31/14, 2:33 PM, Pete Resnick wrote:
On 7/31/14 2:31 PM, Barry Leiba wrote:
Given that I want to update the IANA language some more, I have another
draft ready to upload (incorporating these changes). Should I do that now?<= br>
I think you should, unless Pete has other ideas for some reason. =C2=A0As I=
always say: revisions are cheap.

Yeah, please go right ahead. Once I hear from Robert, I will likely send th= is out for a second Last Call, given the extent of the changes, so having t= he latest-and-greatest in there would be good.

pr





--
= -vince --001a1135f4765d22db04ff8a154e--