Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

From: <[email-masked]>
Date: Mon, 5 Mar 2012 19:45:56 +0000

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: Tue, 6 Mar 2012 17:45:13 +0000

All

I believe that the WG draft has an omission in P.11 relating to the parameters that MAY be sent from the master device to the database. The data model in D.1 allows for location uncertainty, height and height uncertainty. These items are not mentioned in the parameters in P.11, and all (except height uncertainty) are required by Ofcom in http://www.cept.org/Documents/se-43/4161/SE43(12)Info03_Draft-UK-regulatory-requirements-for-white-space-devices-in-the-UHF-TV-band. I propose the following change:

P.11:  The protocol MUST support a channel query request from the master device to the database.  The channel query request message MUST include parameters as required by local regulatory requirement.  These parameters MAY include device location, <Insert>location uncertainty, device height, height uncertainty, </Insert>device ID, manufacturer's serial number, and antenna characteristic information.

Regards

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 05 March 2012 19:46
To: [email-masked]
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

Thanks, Gabor

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 6 Mar 2012 18:17:57 -0500

Hi all,

I have taken a look at the Ofcom requirements reference on the CEPT site
and besides the points raised by Andy I believe the following protocol
requirements should also be addressed in the PAWS requirements doc:

-          Ofcom 3.11 A master WSD must communicate its technology
identifier to a WSDB - This is needed to identify the type of RAT being
used, beyond the antenna, power and channel characteristics. Having said
that, we had some issues in IEEE 802.21 where we were playing a horse
race with the constantly evolving 802.11, 3GPP, etc PHY technologies, so
perhaps another approach could be to specify directly the modulation,
medium access method, etc. instead of the actual RAT ID. We don't need
to define the actual solution now, as long as the requirement allows it
in the future. Suggested text:

o   D.5:   The Data Model MUST support specifying an ID of the
transmitter device.  This ID would contain the ID of the transmitter
device that has been certified by a regulatory body for its regulatory
domain.  The Data Model MUST support a device class. <Insert> The Data
Model MUST support specifying information about the type of RAT of the
transmitter device.</Insert>

-          Ofcom 3.15    A master WSD must communicate to a WSDB whether
it, and its associated slave WSDs, are fixed devices or portable/mobile
devices - Not sure if this is covered by "device class" in D.5. Since
Device Class is not defined in the document, I would suggest either
defining it as including fixed vs. mobile/portable characteristics, or
adding a sentence at the end of D.5 such as "The Data Model MUST support
specifying whether the transmitter device is fixed or mobile/portable."

-          Ofcom 3.16    A fixed master WSD may communicate to a WSDB
whether it, and its associated fixed slave WSDs, are indoor devices or
outdoor devices - Similar to the previous 3.15 requirement. I would
suggest either adding a definition for Device Class including indoor or
outdoor characteristics, or adding a sentence in D.5 like "The Data
Model MAY support specifying whether the transmitter is an outdoor or
indoor device."

Also, I believe we need to add some clarification on the following:

-          P.14/P.15 state that the protocol must support a "validation
request from the master to the database to validate a slave device". Is
this a master relaying a request to the WSDB on behalf of a slave? It is
not clear what validation means. It would be good to provide some more
explanatory text.

-          Now that the CEPT version of the Ofcom requirements is
publicly available we should add a reference to the document in Section
3.3 "Background information on white space in the UK."

Regards,

Juan Carlos 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, March 05, 2012 2:46 PM
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-usecase
s-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: Don Joslyn <[email-masked]>
Date: Wed, 7 Mar 2012 16:40:46 -0500

Re:

-          P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text.

In the context of FCC certified databases and devices, Fixed or Mode II TVBD (master devices) must verify that the FCC identifier (FCC ID) of the Mode I device (slave) is valid before sending a channel list to the slave.

In other words, before a master device sends a channel list to a slave device, the master device must send a verification request message to the database to validate the slave's reported FCC ID. The master may only send a channel list to the slave device after the database has validated the FCC ID by sending a success in the reply to a verification request message.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Zuniga, Juan Carlos
Sent: Tuesday, March 06, 2012 6:18 PM
To: [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details

Hi all,

I have taken a look at the Ofcom requirements reference on the CEPT site and besides the points raised by Andy I believe the following protocol requirements should also be addressed in the PAWS requirements doc:

-          Ofcom 3.11 A master WSD must communicate its technology identifier to a WSDB - This is needed to identify the type of RAT being used, beyond the antenna, power and channel characteristics. Having said that, we had some issues in IEEE 802.21 where we were playing a horse race with the constantly evolving 802.11, 3GPP, etc PHY technologies, so perhaps another approach could be to specify directly the modulation, medium access method, etc. instead of the actual RAT ID. We don't need to define the actual solution now, as long as the requirement allows it in the future. Suggested text:

o   D.5:   The Data Model MUST support specifying an ID of the transmitter device.  This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain.  The Data Model MUST support a device class. <Insert> The Data Model MUST support specifying information about the type of RAT of the transmitter device.</Insert>

-          Ofcom 3.15    A master WSD must communicate to a WSDB whether it, and its associated slave WSDs, are fixed devices or portable/mobile devices - Not sure if this is covered by "device class" in D.5. Since Device Class is not defined in the document, I would suggest either defining it as including fixed vs. mobile/portable characteristics, or adding a sentence at the end of D.5 such as "The Data Model MUST support specifying whether the transmitter device is fixed or mobile/portable."

-          Ofcom 3.16    A fixed master WSD may communicate to a WSDB whether it, and its associated fixed slave WSDs, are indoor devices or outdoor devices - Similar to the previous 3.15 requirement. I would suggest either adding a definition for Device Class including indoor or outdoor characteristics, or adding a sentence in D.5 like "The Data Model MAY support specifying whether the transmitter is an outdoor or indoor device."

-          P.14/P.15 state that the protocol must support a "validation request from the master to the database to validate a slave device". Is this a master relaying a request to the WSDB on behalf of a slave? It is not clear what validation means. It would be good to provide some more explanatory text.

-          Now that the CEPT version of the Ofcom requirements is publicly available we should add a reference to the document in Section 3.3 "Background information on white space in the UK."

Regards,

Juan Carlos

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, March 05, 2012 2:46 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

Thanks, Gabor

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 8 Mar 2012 10:57:26 -0500

Hi Don,

Thanks for the explanation. After reading it the text makes sense.
However, I still believe the explanation should be included in the text
to make it clearer. Perhaps the explanation you provide in the last
paragraph can be added in point 8 of Use Case 4.2.2 Wide-Area or Rural
Internet broadband access, stating something like "In some regulatory
domains, before a master device sends a channel list..."

JC

From: Don Joslyn [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2012 4:41 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]
Subject: RE: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03:protocol details

Re: 

In the context of FCC certified databases and devices, Fixed or Mode II
TVBD (master devices) must verify that the FCC identifier (FCC ID) of
the Mode I device (slave) is valid before sending a channel list to the
slave.

In other words, before a master device sends a channel list to a slave
device, the master device must send a verification request message to
the database to validate the slave's reported FCC ID. The master may
only send a channel list to the slave device after the database has
validated the FCC ID by sending a success in the reply to a verification
request message.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zuniga, Juan Carlos
Sent: Tuesday, March 06, 2012 6:18 PM
To: [email-masked]; [email-masked]
Subject: Re: [paws] WGLC for
draft-ietf-paws-problem-stmt-usecases-rqmts-03: protocol details

Hi all,

Regards,

Juan Carlos 

Thanks, Gabor

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 17:19:17 +0000

Thanks Andy, I will include this in the update.

Kind Regards,
Scott

From: ext com <[email-masked]<mailto:[email-masked]>>
Date: Tue, 6 Mar 2012 17:45:13 +0000
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Gabor Bajko <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

All

Regards

Andy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 05 March 2012 19:46
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

Thanks, Gabor

_______________________________________________ paws mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/paws

---

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

The document was meant to be structured in a way that the list of parameters to be exchanged between the entities are described in the Data Model Requirements part, while the protocol operation requirements described in the Protocol Requirements part. P.11 and P.12 should not include any wording on the list of parameters, then it would be no confusion.
I'll include this comment into my chair's review.

-          Gabor

From: ext [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 06, 2012 9:45 AM
To: [email-masked]; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]; [email-masked]
Subject: RE: WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts-03

All

Regards

Andy

Thanks, Gabor