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

[Kathleen Moriarty <[e-mail]>]

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.


On Tue, Aug 26, 2014 at 4:07 AM, Vincent Chen <[e-mail]> wrote:

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

>
>    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
>
>
> On Tue, Aug 26, 2014 at 12:59 AM, <[e-mail]> wrote:
>
>>
>> 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.
>>
>>
>
>
> --
> -vince
>



-- 

Best regards,
Kathleen