Subject: [paws] New Version Notification - draft-ietf-paws-protocol-15.txt

From: [email-masked]
Date: Tue, 26 Aug 2014 00:59:02 -0700

A new version (-15) has been submitted for draft-ietf-paws-protocol:
http://www.ietf.org/internet-drafts/draft-ietf-paws-protocol-15.txt

Sub state has been changed to AD Followup from Revised ID Needed

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15

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.

IETF Secretariat.

---

From: Vincent Chen <[email-masked]>
Date: Tue, 26 Aug 2014 01:07:24 -0700

All,

I've taken a stab at addressing all the DISCUSS points and comments.
Hopefully this moves us closer.

Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-15

Summary of updates:
   o  Clarified why spectrum-notify is "informational"

   o  Clarified that device registration is typically only required for
      fixed devices

   o  Global statement about timestamp format and must be UTC

   o  Global statement about MISSING error returned, whether it's
      required by PAWS or ruleset

   o  Clarified UNSUPPORTED error

   o  Mandate that Database-change must be included in all responses a
      minimum of 2 weeks before change

   o  Clarified that preconfigured values are ruleset specific
      (INIT_RESP)

   o  Added reference to FCC ruleset for registration of Fixed Devices

   o  Make deviceOwner and serialNumber optional at PAWS level and
      required on a per-ruleset basis

   o  Update description for "location" to be where device intends to
      operate, rather than "current location"

   o  For REGISTRATION_RESP, add clarification that when it is returned,
      it will have at least one RulesetInfo.  Otherwise, it's an
      UNSUPPORTED error.

   o  Clarified that, when a Master Device asks for spectrum on behalf
      of a Slave Device, there are 2 locations in the message and
      changed masterDeviceLocation to be required

   o  Indicate that power levels are typically EIRP (as opposed to
      conducted power to the antenna)

   o  Added description for a "schedule"

   o  Add intro to DEVICE_VALID_REQ

   o  TLS: Follow best practices to improve security and interop.
      Reference draft-ietf-uta-tls-bcp

   o  TLS: Use OCSP for better performance; RFC6960

   o  TLS: When using client auth, Database determines acceptable root
      CAs

   o  Extensibility: Add statement that no extensions that return device
      information will not be accepted

   o  Clarify IANA instructions for the Ruleset ID Registry

   o  Security: Acknowledge that unauthorized access to device
      registration, other sensitive device info is a risk, and indicate
      that privacy policies must be published and implement to control
      access.

Thanks!

-vince

-- 
-vince

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 26 Aug 2014 16:58:17 -0400

Thank you for the updates, my discuss will be cleared in a minute.  I have
a comment below to assist with one of the other points from Stephen.

>    o  TLS: Use OCSP for better performance; RFC6960
OCSP Stapling improves performance over just OCSP, but not for leaving out
OCSP all together.  Security is improved as well.
If you keep the sentence in about OCSP, I think you need all 3 references:
RFC6066, RFC6961, and RFC6960.  If you just wanted to follow the guidance
in draft-ietf-uta-tls-bcp, they already covered this.

-- 

Best regards,
Kathleen

---

From: Vincent Chen <[email-masked]>
Date: Tue, 26 Aug 2014 15:12:35 -0700

Thanks Kathleen,

> in draft-ietf-uta-tls-bcp, they already covered this.

I see. By referencing draft-ietf-uta-tls-bcp, I don't have to list OCSP
explicitly. I like that :)

-- 
-vince