Paws session: Tuesday 2013-11-05, 1440 – 1550, Vancouver
WG website: https://datatracker.ietf.org/wg/paws/ 
Agenda:
1.administrivia, 5min
2. status update (chairs, 5 min)
3. IPR declarations, issues with them? 5 min
4. presentation of http://www.ietf.org/id/draft-ietf-paws-protocol-06.txt issues, max 40 min
5. http://datatracker.ietf.org/doc/draft-wei-paws-database-discovery/ 30 min

Meeting Minutes:
1. Chair’s introductory remarks and status, see http://www.ietf.org/proceedings/88/slides/slides-88-paws-0.pptx 
a. Blue sheet reminder
b. Jabber scribe: Brian Rosen
c. Minute taker: Dorothy Stanley
d. IPR declarations: 2 IPR declarations received
i. Does anyone have issues?
ii. Comment: believe the declaration is a restatement.
iii. Only one of them, the other one is new, declared 2 months ago
iv. Discussion in jabber room on scope of IPR declaration.
v. No issues raised with either IPR declarations on the list, since notices received. Nobody comes to the mike to raise any issue. Chairs assume nobody has any issues with the IPRs.

2. Protocol Draft, see https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ and http://www.ietf.org/proceedings/88/slides/slides-88-paws-1.pptx 
a. Review status of the PAWS protocol document – version -06
b. Re-review proposed changes for -07, these were proposed and agreed in the last f2f, confirmed on the list.
i. Terminology
ii. Parameter name changes
iii. Update vCard to jCard encoding
iv. Multiple rule set support in single response
c. New items for -07
i. Clarify event-time intervals and spectrum. Event-time intervals within a single set of schedules MUST be disjoint. 
ii. Added parameters for master vs slave. When master makes request on behalf of slave device, regulatory rules may require information about the slave device; info provided. Provide location of client device, if available. Master device location is provided, client location may be provided in addition, if known.
1. Client may or may not know its location. Optional to provide.
2. Master location is already known. What is use case for master to resend its location? Targeted towards stateless databases.
3. Believe stateless DBs are non-existent.
4. Fair enough.
iii. Top level time range and frequency range – not confirmed on the list (yet)
iv. Type fixes.
d. Remaining open items – 3issues
i. Ability to distinguish between “explicit off” and “No Information”
1. Added top level event time and frequency ranges; enables DB to return info about the event and frequency. Outside that range, no information.
2. If don’t have info about a channel/time, assume all other intervals are not available.
3. May have multiple models supported by radio.
4. Question of semantics; tell me what I can use and when. If don’t have explicit info, can’t use.  Level of explicitness under discussion.
5. Meta information about channel plan – some devices want; gets confused with what can be used right now. Encode separately.
6. Proposal to adding optional items to the list in SpectrumSpec. Chair: any objection? No objection. Are the definitions clear? Definitions to be reviewed to make sure definition is clear and unambiguous. Editor to propose text to the list.
ii. Open item – Encode slopes?
1. Some info might be useful to encode in SpectrumResponse.
2. Reduces amount of regulatory specific logic in firmware. Rule vs construction. 
3. Example: FCC white space rules uses slopes in their emission limits for channels 36 through 38.
4. Propose: include ability to deliver info, no requirement to use.
5. Is slope encoding to encode transmit spectrum mask? But that’s a single band mask; doesn’t cover use of 3 adjacent channels; different than saying “these channels can be used”
6. Goal is to protect incumbents using the spectrum.  Want to say “your OOB emissions must be below a certain level”. All about interference.
7. When both channels are available – need to adhere to individual channel restrictions. For both incumbent and other unlicensed devices? 
8. Per channel transmit mask and applicable channels – provide information separately.
9. There is a data structure describing availability. Separate data structure for spectrum mask applicable.
10. Is mask per channel needed to be sent all the time? Depends on regulatory domain.
11. Transmit spectrum mask – sounds like a release 2 item. Is there agreement to defer on all slope info?
12. FCC channel 36 slope info needed? Either follow the slope or use minimum value.
13. Could send more info to optimize firmware. But defer to later time.
14. Encoding Examples: is there no value to option 2? Do we include option 2 in the spec now to cover channel 36?
15. If defer, then device needs to know that is required on channel 36.
16. Could include encoding of option 2 (optimized) but defer spectrum mask.
17. Are there “time of day” considerations? Yes, included in the DB.
18. Can provide info on each piece in the encoding already.
19. Encode channels, power, get away from rules. Frequency boundaries vary.
20. Desire to build multi-nation devices. Want to avoid knowing what “channel 3” means everywhere. How much info in first version of the protocol?
21. Channel and slope, or smaller and larger frequency.
22. Current draft has spectrum profile encoding, want to change.
23. Ok to encode slope, separate spectrum transmit mask and spectrum availability mask. Transmit mask and spectrum availability mask are not the same thing.
24. Take back to list.
25. Plan – add capability to encode simple slope data; explicit text to say that semantics do not cover out of band discussion with adjacent channels (deferred to subsequent release).
26. Also band edge transmission limits not included.
27. Editor (Vince) to propose text on the list

3. PAWS Database Discovery, see https://datatracker.ietf.org/doc/draft-wei-paws-database-discovery/ and http://www.ietf.org/proceedings/88/slides/slides-88-paws-2.pptx 
a. Review of issues from IETF 87 (Berlin) and Resolutions
i. “DS server doesn’t know the pre-configuration”
ii. “R2”should maintain information for not only one regulatory body”
iii. “Whole point of a discover service is to find server or servers for a number of countries/regulatory domains.
iv. “Ofcom model for getting the databases – requirement to de-accredit a database”
1. Don’t de-accredit; get a new list of accredited DBs every day. Listing service needs to be consulted, but not required to be first server contacted. 
2. IANA runs a time zone database. 
3. Use LOST. Who runs the LOST server? Follow E-911 model. 
4. Not an IETF WG problem then becomes an IAB liaising problem.
5. How to discover the right server for the area you’re in.
6. With emergency services, regulators to point to are obvious.
7. List of authorized DBs changes slowly. Need to deal with this; 
v. “DS server doesn’t know the pre-configuration”
vi. “Who sets up the WSDB DS” 
1. Bootstrap not solved yet. Like cellular roaming? Roaming partners configured into the device. Master connected to internet, connection to home DB and go from there.
vii. Scenarios that need DB discovery
viii. May have multiple DBs, but not all devices can go to all DBs – commercial relationships. Mandatory to implement, optional to use.
ix. DB Discovery introduction – request/response protocol based on LoST. Problem with matching on URL. 
x. How does the device find the LoST server? In emergency services, its local, service provider provides sever address: DHCP option provides local LoST server.
b. Continue to need a solution; keep list discussion going. Draft not ready for WG adoption. 
c. If we are stuck on an external problem, get “unstuck”; get discussion going to determine that there is need for an external entity. Draft has to come to that conclusion.
4. Meeting adjourned 1550.