Hi Gabor, Comments below: Scott->
Kind Regards, Scott On 3/22/12 4:45 PM, "ext [email protected]" <[email protected]> wrote: >Here's my chair review of the >http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases- >rqmts-03.txt draft: > > >In version 2 of the draft there was a use case about offloading, which >disappeared in this version. I believe that was a valid use case and see >no reason for it to be deleted. I think it should be put back. > >Requirement D.1: >s/for the location determination/of the location determination > >D.2, D.3: I believe the URIs should not be specified in the Data Model, >but rather discovered during the WSDB discovery procedure. Can you >confirm these? If yes, then these requirements should be deleted. Scott->If the discovery procedure "uses" the Data Model, then D.2 & D.3 should remain. If the discovery procedure operates independently of the Data Model, then these should be deleted. I.E. The intent was that at some point the URIs will be transported as data via PAWS (discovery procedure) and thus should be in the Data Model. Perhaps there is a separate Data Model (e.g. Schema) for discovery and a separate Data Model for the other aspects of PAWS. IMHO this is not a requirements issue (beyond the discussions already mentioned by John), but an issue to be determined in the specification of the protocol solution. > >D.4: isn't the regulatory domain also discovered? The Data Model might >also list the regulatory domain, I see no harm in it, but then that is >not a mandatory requirement any more. Scott->If PAWS supports more than one regulatory domain (e.g. UK Ofcom and US FCC), then knowledge of the regulatory domain is a MUST requirement. Else how to know which information elements to include to the signals? > >D.10: I think channel availability should either be specified for a >location or for an area, but not both. Change the requirement to: >"The Data Model MUST support specifying channel availability > information for a single location or for an area in the form >of a geodetic-shape." Scott->I believe the protocol signaling can support channel request for a single location (point) or an area (geodetic shape) -- I.E. No reason to ask for and receive both at the same time. But the Data Model must support both points & shapes so that fixed location and mobility may be supported in the protocol. > >P.2: Since P.1 requires database discovery, I see no need for this >requirement. Scott->P.1 is about finding a database to use. P.2 is about accessing the database directly (as allowed by FCC) or accessing the database through a listing service (as allowed by Ofcom). > >P.6, P.7: s/MUST be integrity protected/MUST support integrity protection > >P.11, P.12: The Data Model already specifies what parameters need to be >supported, you do not need to replicate the text here. It looks like >keeping the first sentence in these requirements is sufficient, the rest >can be removed. Scott->Keeping only the first sentence removes the MUST and MAY qualifiers which are not specified anywhere in the Data Model. > >P.13, P.16: the interface between the slave and the master device is >currently out of scope, these requirements should be removed for now. > >P.17 is a radio interface functionality, not something ietf can specify, >so this should be removed too. > >P.18: s/lists/information > >P.19 is also captured earlier in D.10, no need to replicate it. Scott->D.10 only describes storage, i.e. two types of variables. P.19 describes when to use the variables. > > >- Gabor > > >From: [email protected] [mailto:[email protected]] On Behalf Of >Bajko Gabor (Nokia-CIC/SiliconValley) >Sent: Monday, March 05, 2012 11:46 AM >To: [email protected] >Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03 > >The authors of the use cases and requirements draft have just posted a >new version of the draft and indicated that there are no unresolved >comments/issues they are aware of. > >Therefore, I'd like to initiate a WG Last Call for comments on >http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases- >rqmts-03.txt > >Please review the draft and send your comments to the list by March 20th, >2012. > >If you review the draft and have no comments, send a note to the list >that the draft is good as it is, we need these notes as much as we need >the actual comments. > >Thanks, Gabor > >_______________________________________________ >paws mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
