Subject: [paws] need for DB initialization message

From: <[email-masked]>
Date: Fri, 10 Aug 2012 00:02:01 +0000

Folks,

During the Vancouver F2F discussions we had some good discussions, but no agreement on whether an initialization message, as proposed in draft-das is necessary or not.
You may check the minutes to see what was said at the mike: http://www.ietf.org/proceedings/84/minutes/minutes-84-paws

People spoke mostly in favor, but there were people who also said that this message is redundant with registration message.

Question#1: need for an initialization message
Unfortunately we did not have time to discuss the DB discovery aspect, and that may be related to this topic. The only DB discovery document available currently, http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, that the master device contacts a pre-provisioned discovery server and provides its location, and in return the discovery server returns the URI of the DB for that regulatory domain. At this point, the master device knows which DB to contact, but it does not necessarily know what regulatory domain that DB belongs to. Thus, it doesn't know what are the operating rules, whether it has to authenticate, or register, etc.
Thus, it seems logical to me that the master device first queries the DB to find out the regulatory domain. We even have such a requirement in the requirement draft, requirement:
"P.3:   The protocol MUST support determination of regulatory             domain governing its current location."
The information about the regulatory domain may be cached, and the master device may not need to place that query every time, but this message exchange may be necessary in certain cases. Any comments to this point?

Question#2
Then, it is a slightly separate issue, if this message exchange has to take place, then what additional information the DB returns. draft-das proposes that regulatory domain specific information be returned to the master device.

Question#3
Yet another separate point is that draft-das proposes to use this initialization message also to initiate client authentication (putting shared secret vs cert issue aside for the time being). In cases when the master device does not know the regulatory domain it is in, then it does not know whether authentication is required in that regulatory domain or not; so why would initiate authentication then? Similar comment applies to draft-wei, where it is proposed that after DB discovery the master device authenticates at TLS layer and performs registration; how does it know that it has to authenticate and register, if it doesn't know the regulatory domain?

In my opinion (chair hat off), the sequence of events should be sg like this:

1.       DB discovery (may be skipped if cached information available)

2.       Regulatory domain query (may be skipped if cached information available)

3.       Authentication (if required)

4.       Registration (if required)

5.       Channel availability query (may be combined with registration?)

Comments are welcome and expected.

-          Gabor

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Aug 2012 20:14:50 -0400

<as individual>
I'm not so sure you need something separate for domain.  ISTM that the DB discovery could return it (possibly as a parameter on the DB URI).  OTOH, you might very well want to receive from the DB some kind of data specification (that is, what is required to be provided in the registration), rather than having it totally wired in to domain.  That means, to me, that the registration is a 4 way message exchange:
1. Device to DB: Authenticate me please
2. DB to device: Authentication accepted, send me this data
3. Device to DB: Here is my registration data
4. DB to device: Registration succeeded.

Now, having said that, you might just get authentication out of the TLS session establishment, this not needing step 1.

Brian

On Aug 9, 2012, at 8:02 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

Question#1: need for an initialization message
Unfortunately we did not have time to discuss the DB discovery aspect, and that may be related to this topic. The only DB discovery document available currently, http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes, that the master device contacts a pre-provisioned discovery server and provides its location, and in return the discovery server returns the URI of the DB for that regulatory domain. At this point, the master device knows which DB to contact, but it does not necessarily know what regulatory domain that DB belongs to. Thus, it doesn’t know what are the operating rules, whether it has to authenticate, or register, etc.
Thus, it seems logical to me that the master device first queries the DB to find out the regulatory domain. We even have such a requirement in the requirement draft, requirement:
“P.3:   The protocol MUST support determination of regulatory             domain governing its current location.”
The information about the regulatory domain may be cached, and the master device may not need to place that query every time, but this message exchange may be necessary in certain cases. Any comments to this point?

Question#2

Question#3
Yet another separate point is that draft-das proposes to use this initialization message also to initiate client authentication (putting shared secret vs cert issue aside for the time being). In cases when the master device does not know the regulatory domain it is in, then it does not know whether authentication is required in that regulatory domain or not; so why would initiate authentication then? Similar comment applies to draft-wei, where it is proposed that after DB discovery the master device authenticates at TLS layer and performs registration; how does it know that it has to authenticate and register, if it doesn’t know the regulatory domain?

-          Gabor

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 09 Aug 2012 21:25:08 -0400

Related suggestion:  Assuming we have a discovery protocol which can 
return a URI, the protocol semantics should be such that the URI can be 
the final DB URI, or another intermediary in the process.  Thus, the 
protocol should not lock in that there can be only 0 or 1 intermediaries 
in the resolution, but should allow several.  (We already have suggested 
cases where at least two are needed, one to determine where you are by 
asking your vendor, and one to determine who you can talk to by asking 
your local regulator.)

Yours,
Joel

On 8/9/2012 8:02 PM, [email-masked] wrote:
> Folks,
>
> During the Vancouver F2F discussions we had some good discussions, but
> no agreement on whether an initialization message, as proposed in
> draft-das is necessary or not.
>
> You may check the minutes to see what was said at the mike:
> http://www.ietf.org/proceedings/84/minutes/minutes-84-paws
>
> People spoke mostly in favor, but there were people who also said that
> this message is redundant with registration message.
>
> Unfortunately we did not have time to discuss the DB discovery aspect,
> and that may be related to this topic. The only DB discovery document
> available currently,
> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt, proposes,
> that the master device contacts a pre-provisioned discovery server and
> provides its location, and in return the discovery server returns the
> URI of the DB for that regulatory domain. At this point, the master
> device knows which DB to contact, but it does not necessarily know what
> regulatory domain that DB belongs to. Thus, it doesn’t know what are the
> operating rules, whether it has to authenticate, or register, etc.
>
> Thus, it seems logical to me that the master device first queries the DB
> to find out the regulatory domain. We even have such a requirement in
> the requirement draft, requirement:
>
> “P.3:   The protocol MUST support determination of
> regulatory             domain governing its current location.”
>
> The information about the regulatory domain may be cached, and the
> master device may not need to place that query every time, but this
> message exchange may be necessary in certain cases. Any comments to this
> point?
>
> Question#2
>
> Then, it is a slightly separate issue, if this message exchange has to
> take place, then what additional information the DB returns. draft-das
> proposes that regulatory domain specific information be returned to the
> master device.
>
> Question#3
>
> Yet another separate point is that draft-das proposes to use this
> initialization message also to initiate client authentication (putting
> shared secret vs cert issue aside for the time being). In cases when the
> master device does not know the regulatory domain it is in, then it does
> not know whether authentication is required in that regulatory domain or
> not; so why would initiate authentication then? Similar comment applies
> to draft-wei, where it is proposed that after DB discovery the master
> device authenticates at TLS layer and performs registration; how does it
> know that it has to authenticate and register, if it doesn’t know the
> regulatory domain?
>
> 1.DB discovery (may be skipped if cached information available)
>
> 2.Regulatory domain query (may be skipped if cached information available)
>
> 3.Authentication (if required)
>
> 4.Registration (if required)
>
> 5.Channel availability query (may be combined with registration?)
>
> -Gabor
> [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 9 Aug 2012 21:27:07 -0400

Yeah, that also handles the situation where discovery gets you the national list and then you choose one from the list.

Brian

---

From: <[email-masked]>
Date: Fri, 10 Aug 2012 23:33:18 +0000

While I agree that re-direction from an intermediary to the final recipient should not be disallowed, I don't think the use case you are describing is a valid one. The master needs to know its location before engaging into DB discovery. If it doesn't, then it can use some existing mechanism to find it out (eg, RFC5985) prior to the DB discovery process, but that for me is a separate transaction.

The current DB discovery mechanism described in http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes that the master knows its location before performing DB discovery; after which it needs to do a regulatory domain discovery as well. Brian suggested regulatory domain could be a parameter of the DB URI, thus no need for separate regulatory domain discovery. Any other suggestions?

- Gabor 

-----Original Message-----
From: ext Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, August 09, 2012 6:25 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] need for DB initialization message

Related suggestion:  Assuming we have a discovery protocol which can return a URI, the protocol semantics should be such that the URI can be the final DB URI, or another intermediary in the process.  Thus, the protocol should not lock in that there can be only 0 or 1 intermediaries in the resolution, but should allow several.  (We already have suggested cases where at least two are needed, one to determine where you are by asking your vendor, and one to determine who you can talk to by asking your local regulator.)

Yours,
Joel

On 8/9/2012 8:02 PM, [email-masked] wrote:
> no agreement on wether an initialization message, as proposed in
> regulatory domain that DB belongs to. Thus, it doesn't know what are the
> "P.3:   The protocol MUST support determination of
> regulatory             domain governing its current location."
>
> know that it has to authenticate and register, if it doesn't know the
> regulatory domain?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 Aug 2012 20:17:16 -0400

The master has to know its location in geographic coordinates (GPS, 
etc.)   As far as I know, we have not assumed that the maps to translate 
that into political domains are known to the master a priori.

There are deployment scenarios (cell towers come to mind) where the 
master can probably be provisioned with the right administrative 
information.  There are other scenarios where that is not obviously 
achievable.

Yours,
Joel

---

From: Peter McCann <[email-masked]>
Date: Mon, 13 Aug 2012 14:45:08 +0000

Agree with Joel.

I think a LOST-style service (a) is good for discovering a server associated
with a regulatory domain.  After that, you can query the regulator (b) to find
approved databases.  Then, you can choose one of those databases with which
you have a relationship or that you know through some means will service
your request (c).  The protocol for (b) and (c) could both be PAWS, if we
just add some sort of indirection to our specification.

-Pete

Joel M. Halpern wrote:
>> While I agree that re-direction from an intermediary to the final
> recipient should not be disallowed, I don't think the use case you are
> describing is a valid one. The master needs to know its location
> before engaging into DB discovery. If it doesn't, then it can use some
> existing mechanism to find it out (eg, RFC5985) prior to the DB
> discovery process, but that for me is a separate transaction.
>> 
>> The current DB discovery mechanism described in
> http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes
> that the master knows its location before performing DB discovery;
> after which it needs to do a regulatory domain discovery as well.
> Brian suggested regulatory domain could be a parameter of the DB URI,
> thus no need for separate regulatory domain discovery. Any other suggestions?
>> 
>> - Gabor
>> 
>> return a URI, the protocol semantics should be such that the URI can
>> be the final DB URI, or another intermediary in the process.  Thus,
>> the protocol should not lock in that there can be only 0 or 1
>> intermediaries in the resolution, but should allow several.  (We
>> already have suggested cases where at least two are needed, one to
>> determine where you are by asking your vendor, and one to determine
>> who you can talk to by asking your local regulator.)
>> 
>> Yours,
>> Joel
>> 
>>> During the Vancouver F2F discussions we had some good discussions,
>>> but no agreement on wether an initialization message, as proposed
>>> in draft-das is necessary or not.
>>> 
>>> People spoke mostly in favor, but there were people who also said
>>> that this message is redundant with registration message.
>>> 
>>> device knows which DB to contact, but it does not necessarily know
>>> what regulatory domain that DB belongs to. Thus, it doesn't know what
>>> are the operating rules, whether it has to authenticate, or register,
>>> etc.
>>> 
>>> Thus, it seems logical to me that the master device first queries the
>>> DB to find out the regulatory domain. We even have such a requirement
>>> in the requirement draft, requirement:
>>> 
>>> message exchange may be necessary in certain cases. Any comments to
>>> this point?
>>> 
>>> Question#2
>>> 
>>> Then, it is a slightly separate issue, if this message exchange has
>>> to take place, then what additional information the DB returns.
>>> draft-das proposes that regulatory domain specific information be
>>> returned to the master device.
>>> 
>>> Question#3
>>> 
>>> shared secret vs cert issue aside for the time being). In cases when
>>> the master device does not know the regulatory domain it is in, then
>>> it does not know whether authentication is required in that regulatory
>>> domain or not; so why would initiate authentication then? Similar
>>> comment applies to draft-wei, where it is proposed that after DB
>>> discovery the master device authenticates at TLS layer and performs
>>> registration; how does it know that it has to authenticate and
>>> register, if it doesn't know the regulatory domain?
>>> 
>>> In my opinion (chair hat off), the sequence of events should be sg
>>> like
>>> this:
>>>

---

From: <[email-masked]>
Date: Mon, 13 Aug 2012 16:56:17 +0000

Hi Gabor,

You stated below:
>http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes that
>the master knows its location before performing DB discovery;

That¹s not how we intended it in the I-D.
The master device knows about the address associated with a database
discovery server. The master device has awareness such as CellIDs or SSIDs
or GPS co-ordinates etc which it sends to the database discovery server.
The database discovery server can use such information to identify the
devices current location and/or regulatory domain.

-Raj 

On 8/10/12 6:33 PM, "Bajko Gabor (Nokia-CIC/SiliconValley)"
<[email-masked]> wrote:

>describing is a valid one. The master needs to know its location before
>engaging into DB discovery. If it doesn't, then it can use some existing
>mechanism to find it out (eg, RFC5985) prior to the DB discovery process,
>but that for me is a separate transaction.
>
>http://www.ietf.org/id/draft-probasco-paws-discovery-01.txt assumes that
>the master knows its location before performing DB discovery; after which
>it needs to do a regulatory domain discovery as well. Brian suggested
>regulatory domain could be a parameter of the DB URI, thus no need for
>separate regulatory domain discovery. Any other suggestions?
>
>- Gabor 
>

---

From: <[email-masked]>
Date: Thu, 16 Aug 2012 23:11:40 +0000

This thread was a bit derailed, so I'd like to get back to the original question, which was whether we need a DB initialization message as proposed in draft-das or not.

We seem to converge on the discovery of the regulatory domain, ie that the regulatory domain can be discovered during the DB discovery process, and we do not need a separate message to ask the DB what regulatory domain the master is in.

Then, the question is whether the masters need to contact the DB prior to any other communication, to learn the operating rules for that regulatory domain. The alternative would be that the masters are preconfigured with the operating rules for the regulatory domains they are going to operate in.

In the F2F, there were opinions on both sides, but not enough to call a consensus. So, please send your preference on the need for DB initialization, to the list. We need to make a decision on this and some other issues, so we could move forward creating a wg document.

-          Gabor

From: ext Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, August 09, 2012 5:15 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] need for DB initialization message

<as individual>

Brian

Folks,

Question#2

Question#3

-          Gabor

---

From: Manikkoth Sajeev <[email-masked]>
Date: Thu, 16 Aug 2012 19:41:28 -0700 (PDT)

My vote for DB initialization to be present. As I understand initialization message can be sent upon initial pwer on and reboot scenarios followed by a registration message. And a registration only message when ever otherwise required, typically a link failure, or any other updates from master. Many protocols retain messages this way.

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002
Email: [email-masked]
http://www.linkedin.com/in/mksajeev

________________________________
 From: "[email-masked]" <[email-masked]>
To: [email-masked] 
Sent: Friday, 17 August 2012, 4:41
Subject: Re: [paws] need for DB initialization message

This thread was a bit derailed, so I’d like to get back to the original question, which was whether we need a DB initialization message as proposed in draft-das or not. 

  
  
-          Gabor 
  
From:ext Rosen, Brian [mailto:[email-masked]] 
Sent: Thursday, August 09, 2012 5:15 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] need for DB initialization message   
  
<as individual> 

Brian  
   
On Aug 9, 2012, at 8:02 PM, <[email-masked]> wrote:  

Folks,  

   
   
Question#2  
   
Question#3  

   
   
-          Gabor

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 17 Aug 2012 09:00:37 -0400

What I notice when I look at regulations is how we see different classes of information required at different points in the regulation-required interchanges  that wouldn't occur to us protocol designers.  I think it is foolish to hard wire any specific piece of information to any specific protocol exchange, because some regulator will do something we would classify as silly, but the implementations are stuck.  As an example, in the US regulations, there is information that we would classify as "registration" data required to be in the "spectrum query" message exchange.

So, I do see that a great deal of information exchanged will need to be flexible where it goes.

In this regard, I think that when a device first connects to a database, there will be information exchanged, and I'll bet there will be circumstances where the information the client sends will depend in some way on information the server has.  I think this may also happen on the spectrum query.  Therefore, I would like to make sure that it's possible to have 3 way exchanges in all circumstances.  Client to server, server to client, client to server.   This is not a 3 way message exchange on an unreliable transport.  It lets the client send information dependent on what it gets from the server.

So, my answer is more complex.  I don't think we need a separate message to ask about the regulatory domain.  I think the "registration" message exchange is a 3 way exchange.  If you wanted to send regulatory domain in the second message, and get regulatory required information not sent in the first message sent in the third message of the transaction, that would work for me.

Brian <as individual>

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Aug 2012 19:11:40 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] need for DB initialization message

-          Gabor

Cc: [email-masked]<mailto:[email-masked]>

<as individual>

Brian

Folks,

Question#2

Question#3

-          Gabor

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 04:37:46 +0000

We've seen no objections in having a DB initialization message, for the purpose of learning the operating rules for the regulatory domain. My take is that this message is sent by the master device on a need basis.
I am assuming we have agreement on this, so let's take this into consideration for the wg document, and move forward.

-          Gabor

From: ext Rosen, Brian [mailto:[email-masked]]
Sent: Friday, August 17, 2012 6:01 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]
Subject: Re: [paws] need for DB initialization message

Brian <as individual>

-          Gabor

<as individual>

Brian

Folks,

Question#2

Question#3

-          Gabor