Re: [Gen-art] [paws] Gen-art LC review: draft-ietf-paws-protocol-12
Vincent Chen <vchen@google.com> Tue, 08 July 2014 09:33 UTC
Return-Path: <vchen@google.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0F11B27C7 for <gen-art@ietfa.amsl.com>; Tue, 8 Jul 2014 02:33:30 -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 1cgOs5cvkNNs for <gen-art@ietfa.amsl.com>; Tue, 8 Jul 2014 02:33:27 -0700 (PDT)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F741B27C2 for <gen-art@ietf.org>; Tue, 8 Jul 2014 02:33:23 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id id10so5175905vcb.16 for <gen-art@ietf.org>; 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=Ys7LyG0gt/FL2CDuMoMBfPrPt4OgdPdQibXt3sVnUyK4urPMDA3U6VEZspmSHmCOIU f+7DQ6U7w7T5ShRkhTMjteQ1YXwIYWfGbRe55TITsEM/Ewn3VSk5x8uRTFaioiND8JXT DNhL01C+v5h2gjqwYX8I+I4QrcJXBQhHvOR1+C115Kgho49uf3r+QYwZLRn6TgcDFiTK dWfiO66YRD3GZ1JwiKV/jX5cKkP/nPVUm9NpSZwjE3x0FgSdP6hHX5qZgdsB0udYlBvU bkCVFWLSzRPgbb9Gbt8F/6CcWZHJoBCMCf9FomU2OY1kGBkJkT5LcMoc/KRYIoIaoAqm r6wA==
X-Gm-Message-State: ALoCoQl5YhUJ1sdCy1RRnGIYusbSg9x9kQTbryF9oefMYnEzF5T53fqYU2mEbc2mIp8FtBmd6QTW
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, 08 Jul 2014 02:33:22 -0700
Message-ID: <CABEV9RMVBftqDUS2-aQiOEsfw9yL_RMM92gbSY5VdrmmKM57WQ@mail.gmail.com>
From: Vincent Chen <vchen@google.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary="089e013a28645fe8ac04fdab4818"
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/NPrs9tuRRMCyROgMToIGXbsjZ9s
X-Mailman-Approved-At: Tue, 08 Jul 2014 04:51:05 -0700
Cc: "paws@ietf.org" <paws@ietf.org>, General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, draft-ietf-paws-protocol@tools.ietf.org
Subject: Re: [Gen-art] [paws] Gen-art LC review: draft-ietf-paws-protocol-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jul 2014 09:33:30 -0000
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 <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 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
- [Gen-art] Gen-art LC review: draft-ietf-paws-prot… Robert Sparks
- Re: [Gen-art] [paws] Gen-art LC review: draft-iet… Vincent Chen
- Re: [Gen-art] [paws] Gen-art LC review: draft-iet… Vincent Chen
- Re: [Gen-art] [paws] Gen-art LC review: draft-iet… Robert Sparks
- Re: [Gen-art] [paws] Gen-art LC review: draft-iet… Vincent Chen