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

[Vincent Chen <[e-mail]>]

Thanks Kathleen,


On Tue, Aug 26, 2014 at 1:58 PM, Kathleen Moriarty <
[e-mail]> wrote:

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

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


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



-- 
-vince