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

[Vincent Chen <[e-mail]>]

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 <[e-mail]>
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