Subject: [paws] Hello folks

From: "Richard Shockey" <[email-masked]>
Date: Mon, 7 Feb 2011 14:18:40 -0500

So HTTPS GET and we're done? J 

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
< <mailto:richard(at)shockey.us> mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 19:22:17 +0000

I think the details are in terms of specifying the data model. What is requested and gets delivered needs to be agreed upon.

-Raj

From: ext Richard Shockey <[email-masked]<mailto:[email-masked]>>
Date: Mon, 7 Feb 2011 14:18:40 -0500
To: <[email-masked]<mailto:[email-masked]>>
Subject: [paws] Hello folks

So HTTPS GET and we’re done? :)

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

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

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 19:27:10 +0000

There are 3 aspects to the work to be done here:

  1.  Discovering the correct database from which to obtain the information
  2.  The data model itself
  3.  Security aspects (Authenticating the source of the information, verification of the entity requesting the information, etc.)

-Raj

Richard Shockey
Shockey Consulting

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 8 Feb 2011 09:57:38 -0500

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 07, 2011 2:27 PM
To: [email-masked]; [email-masked]
Subject: Re: [paws] Hello folks

1.       Discovering the correct database from which to obtain the
information 

In the case of the US the source of the data is well understood. Though for
value added applications there may be more than one source that may need to
be aggregated into the DB.

2.       The data model itself 

XML .. was there really any choice?

3.       Security aspects (Authenticating the source of the information,
verification of the entity requesting the information, etc.)

Source authentication may be a national specific issue but verification of
the entity is requesting is also optional.  Why would the TVWS DB want to
know who is querying, except for value added services. This is a feature not
a mandate.

-Raj

From: ext Richard Shockey <[email-masked]>
Date: Mon, 7 Feb 2011 14:18:40 -0500
To: <[email-masked]>
Subject: [paws] Hello folks

Richard Shockey
Shockey Consulting

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

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 08 Feb 2011 08:48:05 -0800

in line

On Tue, 2011-02-08 at 09:57 -0500, Richard Shockey wrote:
>  
> 
>  
> 
> From:[email-masked] [mailto:[email-masked]] 
> In the case of the US the source of the data is well understood.
> Though for value added applications there may be more than one source
> that may need to be aggregated into the DB.
> 
> 2.       The data model itself 
> 
Welllllll, there's a little bit more to the problem.  XML is indeed an
appropriate toolset, but you need a schema.  

Prior art.  Look at what Common Access Protocol did.  Here the subject
(emergency alert messages) is different but the mechanism is identical
-- schema built on XML base.

XML does, however, give a leg up on 3 below vvvvv

> 3.       Security aspects (Authenticating the source of the
> information, verification of the entity requesting the information,
> etc.)

Make sure we have security applied to the right object: the data.
Authenticity of the data is the correct formulation of the requirement.

https doesn't meet this requirement -- it secures the (tcp) connection,
not the data.  But use of the XML-sign primitive does.  (this will make
the database operation look more like an authenticated SNMP get
operation).  

> 
> Source authentication may be a national specific issue but
> verification of the entity is requesting is also optional.  Why would
> the TVWS DB want to know who is querying, except for value added
> services. This is a feature not a mandate.
> 
Both the request and the answer should be authenticated ... allows
control of spurious queries to the database (in what could be a
saturation DOS attack).
> So HTTPS GET and we’re done? J 
> 
>  
> 
> Richard Shockey
> Shockey Consulting
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 8 Feb 2011 14:31:37 -0500

in line

WELLLL of course .. I was simplifying the answer a bit. Its not like we would use a CSV or something like that. In addition to a common schema defining the extensibility mechanism.   

Humm maybe overkill but it’s a valid point.  You are moving into the realm I'm most concerned with which is a top heavy protocol that is expensive to implement at the device layer. But with a common XML schema HTTPS transport security and data validation you have a reasonable architecture. 

I'm assuming you concur with the concept that NO NEW protocol's here.  

We have a sufficiently large tool box to choose from.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Feb 2011 11:51:40 -0800

> appropriate toolset, but you need a schema.
No. The basic managed entities - radios are not speaking XML and the data structures are not so complicated as to require XML.

> I'm assuming you concur with the concept that NO NEW protocol's here.
No.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Shockey
> Sent: Tuesday, February 08, 2011 11:32 AM
> To: [email-masked]
> WELLLL of course .. I was simplifying the answer a bit. Its not like we
> would use a CSV or something like that. In addition to a common schema
> defining the extensibility mechanism.
> 
> 
> Humm maybe overkill but it’s a valid point.  You are moving into the
> realm I'm most concerned with which is a top heavy protocol that is
> expensive to implement at the device layer. But with a common XML
> schema HTTPS transport security and data validation you have a
> reasonable architecture.
>

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 20:43:55 +0000

On 2/8/11 1:31 PM, "ext Richard Shockey" <[email-masked]> wrote:

>Humm maybe overkill but it¹s a valid point.  You are moving into the
>expensive to implement at the device layer. But with a common XML schema
>HTTPS transport security and data validation you have a reasonable
>architecture. 
>

Agree with this assumption. No new protocol to be specified per se. But a
datamodel/schema as well as discovery and security aspects to be specified.

-Raj

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 8 Feb 2011 16:18:14 -0500

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]] 
Sent: Tuesday, February 08, 2011 2:52 PM
To: Richard Shockey; [email-masked]
Subject: RE: [paws] Hello folks

Humm for basic channel information maybe but I'm thinking of extensibility. Would it be a large hit to the imbedded system in the radio? Memory processor?

No.

Paul

Any particular reason why? What would be the relative alternatives?

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Feb 2011 13:32:49 -0800

Some of us do NOT see "new" protocols as more difficult.  For embedded devices large existing protocols are quick to specify, but potentially very top heavy in implementation (XML).

It seem premature to force HTTPS/XML as a solution just because it exists.  Seems like we should be discussing requirements and needs versus force fitting web centric programming into constrained devices. 

Also - there may be other "existing protocols" other than HTTPS that could be used ... it just depends what you consider an appropriate wrapper for your data.  

I'd propose that there are significant advantages to a connectionless protocol. 

Imagine DNS implemented with HTTPS and XML - getting IP addresses is just a data schema problem, right? No.  Decisions on connectionless versus connection oriented should be made first.  Efficiency and the nature of the encoding is important.  This is a protocol supporting potentially very frequent link layer oriented queries.  The core data formats will be natively TLV formats defined by IEEE 802.11af.

Paul

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Tuesday, February 08, 2011 1:18 PM
> To: Paul Lambert; [email-masked]
> No. The basic managed entities - radios are not speaking XML and the
> data structures are not so complicated as to require XML.
> 
> Humm for basic channel information maybe but I'm thinking of
> extensibility. Would it be a large hit to the imbedded system in the
> radio? Memory processor?
>

---

From: "Dave Halasz" <[email-masked]>
Date: Tue, 8 Feb 2011 16:48:17 -0500

What types of devices will typically access the database? Constrained
clients? Or devices such as an 802.11 Access Point?

	Dave H.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Lambert
Sent: Tuesday, February 08, 2011 4:33 PM
To: Richard Shockey; [email-masked]
Subject: Re: [paws] Hello folks

Some of us do NOT see "new" protocols as more difficult.  For embedded
devices large existing protocols are quick to specify, but potentially very
top heavy in implementation (XML).

It seem premature to force HTTPS/XML as a solution just because it exists.
Seems like we should be discussing requirements and needs versus force
fitting web centric programming into constrained devices. 

Also - there may be other "existing protocols" other than HTTPS that could
be used ... it just depends what you consider an appropriate wrapper for
your data.  

I'd propose that there are significant advantages to a connectionless
protocol. 

Imagine DNS implemented with HTTPS and XML - getting IP addresses is just a
data schema problem, right? No.  Decisions on connectionless versus
connection oriented should be made first.  Efficiency and the nature of the
encoding is important.  This is a protocol supporting potentially very
frequent link layer oriented queries.  The core data formats will be
natively TLV formats defined by IEEE 802.11af.

Paul

> Any particular reason why? What would be the relative alternatives?

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

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 21:54:32 +0000

Multiple device types could access the database. Access points, Handheld
mobile devices and possibly other types as well.

-Raj

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 8 Feb 2011 17:53:02 -0500

Well I certainly share your concerns about top heavy protocols in imbedded devices. We're just kicking ideas around here pre BOF to demonstrate interest in doing the work. Though having dealt with IETF WG's as a BOF/WG chair for many years its always useful to try and see if there is a consensus on scope before charter discussions commence. 

I can almost guarantee this will end up in APPS and there will be a argument from the AD's "So why aren't you thinking about HTTPS here?" I'm not trying to be prescriptive only realistic based on considerable prior knowledge of how the process ultimately works. That said I can almost guarantee that this work will have the total support of the IESG. Understand I'm a true believer ..this is bigger than sliced bread. 

The sooner a group forms to write that ID the better. Lots of links to the R&O's and other international activity. A formal IETF liaison letter to 802 will have to be crafted as well. 

My guess is one BOF will be enough if there are sufficient ID's available after Prague describing the problem space. 

As for frequency of query the FCC is only talking about once a day. I haven’t heard with the folks in Canada or the EC are thinking if at all.  

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]] 
Sent: Tuesday, February 08, 2011 4:33 PM
To: Richard Shockey; [email-masked]
Subject: RE: [paws] Hello folks

Paul

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Feb 2011 15:28:13 -0800

> As for frequency of query the FCC is only talking about once a day.

If you walk down the street at 3 mph a query is required every 37 seconds. At 60 mph queries are every 1.9 seconds.

A connectionless transport is required with minimal overhead.

Paul

Paul A. Lambert |  Marvell  | +1 650 787 9141

> Sent: Tuesday, February 08, 2011 2:53 PM
> Well I certainly share your concerns about top heavy protocols in
> imbedded devices. We're just kicking ideas around here pre BOF to
> demonstrate interest in doing the work. Though having dealt with IETF
> WG's as a BOF/WG chair for many years its always useful to try and see
> if there is a consensus on scope before charter discussions commence.
> 
> I can almost guarantee this will end up in APPS and there will be a
> argument from the AD's "So why aren't you thinking about HTTPS here?"
> I'm not trying to be prescriptive only realistic based on considerable
> prior knowledge of how the process ultimately works. That said I can
> almost guarantee that this work will have the total support of the
> IESG. Understand I'm a true believer ..this is bigger than sliced
> bread.
> 
> The sooner a group forms to write that ID the better. Lots of links to
> the R&O's and other international activity. A formal IETF liaison
> letter to 802 will have to be crafted as well.
> 
> My guess is one BOF will be enough if there are sufficient ID's
> available after Prague describing the problem space.
> 
> As for frequency of query the FCC is only talking about once a day. I
> haven’t heard with the folks in Canada or the EC are thinking if at
> all.
> 
> devices large existing protocols are quick to specify, but potentially
> very top heavy in implementation (XML).
> 
> It seem premature to force HTTPS/XML as a solution just because it
> exists.  Seems like we should be discussing requirements and needs
> versus force fitting web centric programming into constrained devices.
> 
> Also - there may be other "existing protocols" other than HTTPS that
> could be used ... it just depends what you consider an appropriate
> wrapper for your data.
> 
> Imagine DNS implemented with HTTPS and XML - getting IP addresses is
> just a data schema problem, right? No.  Decisions on connectionless
> versus connection oriented should be made first.  Efficiency and the
> nature of the encoding is important.  This is a protocol supporting
> potentially very frequent link layer oriented queries.  The core data
> formats will be natively TLV formats defined by IEEE 802.11af.
> 
> Paul
> 
> 
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 Feb 2011 09:15:11 +0200

> A connectionless transport is required with minimal overhead.

Please read http://tools.ietf.org/html/rfc5405 esp. Section 3.

Lars

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 15:16:55 +0000

Hi,

>
> If you walk down the street at 3 mph a query is
>required every 37 seconds. At 60 mph queries are
>every 1.9 seconds.
>
That's one solution, sure. But there are ways to mitigate the frequency of contacting the database. According to the FCC, a device can load channel availability information for multiple locations and use that for operation.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Paul Lambert
Sent: Tuesday, February 08, 2011 5:28 PM
To: Richard Shockey; [email-masked]
Subject: Re: [paws] Hello folks

Paul

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 15:37:20 +0000

On 2/8/11 3:32 PM, "ext Paul Lambert" <[email-masked]> wrote:

>exists.  Seems like we should be discussing requirements and needs versus
>force fitting web centric programming into constrained devices.
>
>Imagine DNS implemented with HTTPS and XML - getting IP addresses is just
>a data schema problem, right? No.  Decisions on connectionless versus
>connection oriented should be made first.  Efficiency and the nature of
>the encoding is important.  This is a protocol supporting potentially
>very frequent link layer oriented queries.  The core data formats will be

Why do you presume that the data formats have to be TLVs?
Also why specifically 11af? 11af is one of the air-interfaces that can be
used in this spectrum. But it is not limited to it.
And hence the protocol between the devices and the database needs to be
air-interface agnostic.

-Raj

---

From: Paul Lambert <[email-masked]>
Date: Wed, 9 Feb 2011 12:13:39 -0800

It may or may not be TLV - why do you assume XML versus ASN.1, JSON, YAML, etc?
If the primary work is data representation - meeting the requirements of known radio interfaces would be essential.

> Sent: Wednesday, February 09, 2011 7:37 AM
> To: Paul Lambert; [email-masked]; [email-masked]
> versus
> just
> >> > Welllllll, there's a little bit more to the problem.  XML is
> indeed
> >> an

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 10 Feb 2011 17:15:57 -0500

Are you guys ready to put on a BOF yet? 1 hour might not be enough. 

Have you applied? 

Do you have anything like drafts ready? The best thing would be IMHO
informational on the scope of the problem statement and pointers to whatever
US and International activity is going on out there.

---

From: <[email-masked]>
Date: Thu, 10 Feb 2011 23:14:18 +0000

Hi Richard,

Yes, we have put in a BoF request and it is approved.
So we will be meeting at IETF80. Please see:
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

We are working on a few drafts (Problem statement and requirements, Intro
to white spaces).
Of course if you have something in mind, please do submit an I-D.

Rgds,
-Raj

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 11 Feb 2011 11:38:14 +0100

Hi,

Actually the approval of the BoF is conditional, because at the time of
the discussion in the IESG and IAB there was little supporting material.
What this conditional approval means is that space is reserved and the
BoF will happen but only if there is more sustained activity on its
preparation and the following materials are prepared: 

- an Internet-Draft that describes the problem statement for the future
work and identifies the possible pieces of work, positioning them
relative to other work out of the IETF or within the IETF
- a proposed charter for the future Working Group

These two deliverables need to show up as soon as possible. The mail
list was formed for the people who initiated this work to prepare and
gather support and input - I expect more intense activity before a final
approval of the BoF in Prague can be granted. 

Thanks and Regards,

Dan
(your sponsoring AD)

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, February 11, 2011 1:14 AM
> Subject: Re: [paws] So next steps...
> 
> 
> Hi Richard,
> 
> We are working on a few drafts (Problem statement and 
> requirements, Intro to white spaces).
> >informational on the scope of the problem statement and pointers to 
> >whatever US and International activity is going on out there.
> >