Subject: Re: [paws] FW: Hello folks

From: "Parker, Erik" <[email-masked]>
Date: Mon, 7 Feb 2011 18:36:57 -0800

Thanks, also explains the pki or other validation mechanism of legit source and crypto need, hence the https suggestion :)

Erik

Sent from my phone.

-----Original Message-----
From: Paul Lambert [[email-masked]]
Received: Monday, 07 Feb 2011, 6:14pm
To: Parker, Erik [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: RE: [paws] FW: Hello folks

Authentication is required: http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf

Web technologies (HTTPS/XML) is too often applied as the hammer to fix all problems … however inappropriately.   This is more akin to DRM for spectrum usage than a new web API for integrators.  Users/integrators will not have access to the “change to any channel” knob.

Paul

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

From: Parker, Erik [mailto:[email-masked]]
Sent: Monday, February 07, 2011 5:55 PM
To: Paul Lambert
Cc: [email-masked]
Subject: Re: [paws] FW: Hello folks

On Feb 7, 2011, at 5:27 PM, Paul Lambert wrote:

HTTPS sounded like a serious proposal …
Why not UDP based?
Paul

Sorry my response was in private reply, unsure why it was forwarded to the list hours later since it provided no valuable information in it.

HTTPS itself could have been serious, but the 'and we're done' part sounded like humor to me.

For corporations utilizing these databases, a TCP based transport method is likely going to be easier to handle from a filtering perspective, but either would certainly work.  It's unclear to me what data is being sent that would actually require cryptography, unless there is a want to have private for-profit databases with their own unique source of information.   Is there a thought that the 9 providers will be licensing this data and access,  so devices will need an authentication mechanism to access it?

The FCCs own searchable (and available in raw tsv) database is out there today which makes it pretty easy to process the actual data of lat/lon, channel utilization.  Not sure about other regions.   It'd be seemingly ideal to have a simple API that can be called, send a lat/lon with a search radius and return results. Though, it's unclear to me if the database should be enforcing things like radius and search area, and it how the hardware will actually ensure it is where it's suppose to be. (ie, like Carrier based pico cells including GPS to ensure they are being used within the proper regions to avoid "free" international calling).   Does it remain an honor system that people input their devices are where they say they are, a technical integration of GPS,  or an auto detection mechanism in the unit that scans and fingerprints channel utilization nearby to narrow down the possible locations its in? (ie, I see data on this 15 frequencies, the only possible area I could be is..  these 10 locations).

It would be nice to have web based APIs available though, as integrators would not have to learn too many different things.   I could certainly see an easy to implement Busybox tool compiled that can speak whatever language so busybox/embedded Linux based systems would have a trivial time implementing the protocol without any custom libraries required beyond being able to speak HTTP..

--
Erik

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

From: Parker, Erik [mailto:erparker@]
Sent: Monday, February 07, 2011 2:27 PM
To: Richard Shockey
Subject: Re: [paws] Hello folks

I think your humor may have been lost on some of the list.. :)

On Feb 7, 2011, at 11:18 AM, Richard Shockey wrote:

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

<ATT00001..txt>

<ATT00001..txt>

---

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

Essentially yes .. the other factor is time to market and the existence of
available code for imbedded systems and the code base is not too heavy to
impact BOM costs.   The presumption here is that no one wants to invent a
new protocol for this and whatever mechanism must allow for extensibility
security and authentication..though why authentication is required at query
is not well understood. Provisioning I understand The security aspect seems
to be that the FCC is afraid of man in the middle attacks but .whatever.

The HTTPS suggestion was very serious. The presumed response is a XML file
defining the parameters. Restful HTTPS PUT for provisioning if necessary.
I've had some experience with this in dealing with this. The DRINKS WG is
look at the same type of transport protocols for XML provisioning objects
involving numbering databases.

So something line https://tvws.fcc.gov/lat/long  where lat long in whatever
format  WGS 84 or NAD27 presumably WGS 84 since it is common to GPS systems?
You simply define the rule for creating the URI expression. 

In RFC 3761 we defined a similar rule to construct a query but used DNS as
the protocol. 

2.4.  Valid Databases

   At present only one DDDS Database is specified for this Application.

   "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS

   Database" (RFC 3403) [2] specifies a DDDS Database that uses the

   NAPTR DNS resource record to contain the rewrite rules.  The Keys for

   this database are encoded as domain-names.

   The output of the First Well Known Rule for the ENUM Application is

   the E.164 number minus all non-digit characters except for the +.  In

   order to convert this to a unique key in this Database the string is

   converted into a domain-name according to this algorithm:

   1. Remove all characters with the exception of the digits.  For

      example, the First Well Known Rule produced the Key

      "+442079460148".  This step would simply remove the leading "+",

      producing "442079460148".

   2. Put dots (".") between each digit.  Example:

      4.4.2.0.7.9.4.6.0.1.4.8

   3. Reverse the order of the digits.  Example:

      8.4.1.0.6.4.9.7.0.2.4.4

   4. Append the string ".e164.arpa" to the end.  Example:

      8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa

   This domain-name is used to request NAPTR records which may contain

   the end result or, if the flags field is blank, produces new keys in

   the form of domain-names from the DNS.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Parker, Erik
Sent: Monday, February 07, 2011 9:37 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] FW: Hello folks

Thanks, also explains the pki or other validation mechanism of legit source
and crypto need, hence the https suggestion :)

Erik

Sent from my phone.

-----Original Message----- 
From: Paul Lambert [[email-masked]]
Received: Monday, 07 Feb 2011, 6:14pm
To: Parker, Erik [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: RE: [paws] FW: Hello folks

Authentication is required:
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf 

Web technologies (HTTPS/XML) is too often applied as the hammer to fix all
problems . however inappropriately.   This is more akin to DRM for spectrum
usage than a new web API for integrators.  Users/integrators will not have
access to the "change to any channel" knob.

Paul

 

HTTPS sounded like a serious proposal .

Why not UDP based?

Paul

Sorry my response was in private reply, unsure why it was forwarded to the
list hours later since it provided no valuable information in it. 

HTTPS itself could have been serious, but the 'and we're done' part sounded
like humor to me. 

For corporations utilizing these databases, a TCP based transport method is
likely going to be easier to handle from a filtering perspective, but either
would certainly work.  It's unclear to me what data is being sent that would
actually require cryptography, unless there is a want to have private
for-profit databases with their own unique source of information.   Is there
a thought that the 9 providers will be licensing this data and access,  so
devices will need an authentication mechanism to access it?

The FCCs own searchable (and available in raw tsv) database is out there
today which makes it pretty easy to process the actual data of lat/lon,
channel utilization.  Not sure about other regions.   It'd be seemingly
ideal to have a simple API that can be called, send a lat/lon with a search
radius and return results. Though, it's unclear to me if the database should
be enforcing things like radius and search area, and it how the hardware
will actually ensure it is where it's suppose to be. (ie, like Carrier based
pico cells including GPS to ensure they are being used within the proper
regions to avoid "free" international calling).   Does it remain an honor
system that people input their devices are where they say they are, a
technical integration of GPS,  or an auto detection mechanism in the unit
that scans and fingerprints channel utilization nearby to narrow down the
possible locations its in? (ie, I see data on this 15 frequencies, the only
possible area I could be is..  these 10 locations).

It would be nice to have web based APIs available though, as integrators
would not have to learn too many different things.   I could certainly see
an easy to implement Busybox tool compiled that can speak whatever language
so busybox/embedded Linux based systems would have a trivial time
implementing the protocol without any custom libraries required beyond being
able to speak HTTP..  

--

Erik

 

 

 

So HTTPS GET and we're done? J

Richard Shockey
Shockey Consulting

<ATT00001..txt>

<ATT00001..txt>