Subject: [paws] Chair review of draft-ietf-paws-problem-stmt-usecases-rqmts-03

From: <[email-masked]>
Date: Thu, 22 Mar 2012 21:45:52 +0000

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.

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.

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

P.2: Since P.1 requires database discovery, I see no need for this requirement.

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.

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. 

- Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Monday, March 05, 2012 11:46 AM
To: [email-masked]
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

---

From: <[email-masked]>
Date: Mon, 26 Mar 2012 21:32:43 +0000

Hi Gabor,

Comments below: Scott->

Kind Regards,
Scott

On 3/22/12 4:45 PM, "ext [email-masked]" <[email-masked]>
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:
>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:
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
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.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.
>
Scott->D.10 only describes storage, i.e. two types of variables. P.19
describes when to use the variables.
>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 
>
>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-masked]
>https://www.ietf.org/mailman/listinfo/paws