Re: [paws] Stephen Farrell's No Objection on draft-ietf-paws-protocol-15: (with COMMENT)

Vincent Chen <vchen@google.com> Fri, 29 August 2014 16:59 UTC

Return-Path: <vchen@google.com>
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 40E931A0685 for <paws@ietfa.amsl.com>; Fri, 29 Aug 2014 09:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 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.668, 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 QchaJrdkf3A9 for <paws@ietfa.amsl.com>; Fri, 29 Aug 2014 09:59:52 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063711A0688 for <paws@ietf.org>; Fri, 29 Aug 2014 09:59:51 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id la4so2824497vcb.29 for <paws@ietf.org>; Fri, 29 Aug 2014 09:59: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=5FLpGTjfmFx+y3ACxOLBHC/KvfvkmYBVRxvzS3zsYhk=; b=G0VmZk/E7AOeU6JukJKI3OGlPwcl3j6ZfVjEj3Huxt7SvdNDoweZHU3QG3fMOf9Oi4 v150IwldIC2Y/76tVQGf85TWPZph86UCPH+xA+mttaPCN8UWIfKoRdsHRYkTSZfytzJP +LpR+/ubVze3Pb9xl/3KozvCfPIyNDURfzzm3VlG1P8hnVH1G2R16sUJF0Q8CFrDmKbX nVaL9/bQkUyeB6Hr+Y+ok1CWrMPbH7JR3QYGQr6M+LN+lWoX68lkvvnfwgjMSbk9SmwJ dm13PILeZjC82YVJCH3fy7oEAwAmyMAdNYJRtfbezh0euQDg1HMRlp0Z2zGHG4HHIAgd tkBg==
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=5FLpGTjfmFx+y3ACxOLBHC/KvfvkmYBVRxvzS3zsYhk=; b=hh82xzxgJtDMXMLWsJvQ0RSBGP+ITDprblLJdbL4P5Bbidb2VqC/voJmpF8Ilk32rO lVv5MAGQvi/7ALkwZ8c5awIRR97kpYfCLC3ClMK0cg/2nFT4DK5WMLYIIgqubVhPw+F5 cC2v+3sFEXYApEGcIlmI15sS3CJm6jrQMhzrqkW2m6cpptc91tCLeWZTjGsi8vHPU/W3 djPqcOudH2HIQv1gtJSD+aEjKydrN8GHXlLYyyq7D0AlF/OpL4JbShmQA4jO1023faAg 7IPgcpHh5QBd2EB8lSnyV6EoCqSW3BD82P4EDPQIDHAkbxG35hHeTPfWk1YCBr6I4LLN WWxQ==
X-Gm-Message-State: ALoCoQkXSw3FhkdLuIojvoVMP0E4J/8cMW1cSlXxgULei/cDx9OsKoIRJS/3jdEy7pzrLUjTQhDu
MIME-Version: 1.0
X-Received: by 10.52.15.36 with SMTP id u4mr884076vdc.91.1409331590975; Fri, 29 Aug 2014 09:59:50 -0700 (PDT)
Received: by 10.52.177.226 with HTTP; Fri, 29 Aug 2014 09:59:50 -0700 (PDT)
In-Reply-To: <20140829144108.28129.36677.idtracker@ietfa.amsl.com>
References: <20140829144108.28129.36677.idtracker@ietfa.amsl.com>
Date: Fri, 29 Aug 2014 09:59:50 -0700
Message-ID: <CABEV9RNykrMn+h8kxmz42cufEPHkmB4qAWW2M9PVpKpaobZJeg@mail.gmail.com>
From: Vincent Chen <vchen@google.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=20cf3030c505d9edba0501c7940e
Archived-At: http://mailarchive.ietf.org/arch/msg/paws/K7MDgFjWsrAIhLPy8_UsnZaM5FM
Cc: "paws@ietf.org" <paws@ietf.org>, "paws-chairs@tools.ietf.org" <paws-chairs@tools.ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-paws-protocol@tools.ietf.org
Subject: Re: [paws] Stephen Farrell's No Objection on draft-ietf-paws-protocol-15: (with COMMENT)
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws/>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Aug 2014 16:59:54 -0000

Stephen,

Thanks for the review.

Just for the record. I'll respond to each of the comments.


On Fri, Aug 29, 2014 at 7:41 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-paws-protocol-15: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
>
> Thanks for sorting out my discuss points.
>
> I didn't fully check the location stuff is now all ok, but I
> expect that since others had related discuss points
> it'll be checked more thoroughly (and it looks ok to
> me too)
>
> S.
>
>
> --- old comments below, didn't check if they were handled or
> not, but feel free to keep chatting about 'em if that's useful
>
> - write-up: its a pity that coders haven't gotten together more
> openly and done interop, but I guess different businesses are
> different.
>

FWIW, there are various trials occurring in the UK and I believe
participants have been using draft versions of PAWS successfully.


>
> - section 1, last para: I realise authorized devices is what
> the WG are interested in, but the protocol ought not require
> that, so the last sentence here is wrong - it surely should
> be: s/device is authorized to operate/device operates/
>

Done.


>
> - Ruleset: I hope there's a NULL, meaning "no rules":-)
>

I don't believe NULL makes sense, since spectrum is a regulated "resource".
Devices must always operate according to some rules.

- 4.4.1 - nothing stops a device lying about location, right?
>

Correct. There's a catch-all in Section 10 that we are not trying to
protect against
rogue devices, since a rogue device can just use spectrum without ever
asking a DB.


> - 4.5 - the slave location vs. master location seems unclear
> to me. Can you clarify?
>

Done. Added clarifying paragraph to the section.


>
> - 4.5.1 - timestamp has to be UTC right? You only seem to
> indicate that via the "Z" in the timestamp format which I
> expect could be easily missed. Suggest you emphasise that. You
> should probably also say if truncated timestamps are ok, for
> example just to the minute granularity without specifying
> seconds.  I assume that's not allowed? And lastly, please
> specify if the start (resp. end) of the second (or whatever)
> unit is when a device gains (resp. looses) spectrum. (Or add a
> global statement on timezones where you earlier said that
> identifiers are case sensitive by default.) Some of this is in
> 5.14, but I'm not sure if that's enough. (It could be.)
>

Done. Added global statement to Section 4.


>
> - 5.2 - I don't get why you need X.520 here.
>

Removed.


>
> - 5.5 - could a vCard value just be (the moral equivalent of)
> "Internet" or "I'm not telling"?
>

Done. Rearranged description to make it more clear that specific
requirements
are defined by ruleset in IANA section.


>
> - section 7: Saying the master device MUST implement server
> auth is confusing, since the master device is the TLS client,
> right?
>

Done. Removed and added reference to TLS BCP for guidance.


>
> - Section 10: Under the privacy bullet you should also
> recognise that an authorized entity can be privacy invasive
> (e.g. selling contact information, sending all on to law
> enforcement without permission).
>

Done. Added statements regarding privacy policies.


> - Section 10: Given diginotar and similar (incl. by nation
> states), having the master device send its identifying
> information in its first message means that simply saying "use
> TLS" is not enough. You need to say "TLS, assuming the PKI
> used is ok,..." or similar.
>
>
> Done. Added qualifying phrase.



-- 
-vince