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

From: "Stephen Farrell" <[email-masked]>
Date: Fri, 29 Aug 2014 07:41:08 -0700

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. 

- 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/

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

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

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

- 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.)

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

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

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

- 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).

- 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.

---

From: Vincent Chen <[email-masked]>
Date: Fri, 29 Aug 2014 09:59:50 -0700

Stephen,

Thanks for the review.

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

> http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

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

> 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.

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

Done. Added clarifying paragraph to the section.

> 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.

> "Internet" or "I'm not telling"?

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

> auth is confusing, since the master device is the TLS client,

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

> enforcement without permission).

Done. Added statements regarding privacy policies.

> Done. Added qualifying phrase.

-- 
-vince