Thanks Kathleen,
On Tue, Aug 26, 2014 at 1:58 PM, Kathleen Moriarty < [email protected]> 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 <[email protected]> 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, <[email protected]> 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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
