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. > > 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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
