Subject: Re: [paws] need for DB initialization message

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 13 Aug 2012 10:55:27 -0400

<as individual>
I prefer LoST for discovery.  LoST can do recur/iterate like DNS, and it can return more than one URI.  That would allow the base LoST discovery to find a server that returned the list.  The initial LoST query returns the list server, and a recur or iterate returns the list.

Brian

 -----Original Message-----
From: 	Peter McCann [mailto:[email-masked]]
Sent:	Monday, August 13, 2012 10:47 AM Eastern Standard Time
To:	Joel M. Halpern; [email-masked]
Cc:	[email-masked]
Subject:	Re: [paws] need for DB initialization message

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:
> 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
> 
> On 8/10/2012 7:33 PM, [email-masked] 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
>> 
>> -----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:
>>> Folks,
>>> 
>>> 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.
>>> 
>>> 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
>>> 

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

---

From: Peter McCann <[email-masked]>
Date: Mon, 13 Aug 2012 15:04:01 +0000

That would work too.

-Pete

Rosen, Brian wrote:
> <as individual>
> I prefer LoST for discovery.  LoST can do recur/iterate like DNS, and
> it can return more than one URI.  That would allow the base LoST
> discovery to find a server that returned the list.  The initial LoST
> query returns the list server, and a recur or iterate returns the list.
> 
> Brian
> 
> 
> 
> 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:
>> 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.
>> 
>> 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
>> Brian suggested regulatory domain could be a parameter of the DB
>> URI, thus no need for separate regulatory domain discovery. Any
>> other
> suggestions?
>>> 
>>> - Gabor
>>> 
>>> 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
>>> 
>>>> but no agreement on wether an initialization message, as proposed in
>>>> draft-das is necessary or not.
>>>> 
>>>> 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:
>>>> 
>>>> 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.
>>>> 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?
>>>>

---

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

I think that LoST is a bit of an overkill for what is really needed in the
context of PAWS for database discovery.
The WSDB discovery server (as per draft-probasco-paws-discovery-01.txt)
can provide the master device with information about the relevant WSDB (or
list of DBs) to query as well as the regulatory domain that it is
currently located in.

-Raj 

On 8/13/12 9:55 AM, "ext Rosen, Brian" <[email-masked]> wrote:

><as individual>
>I prefer LoST for discovery.  LoST can do recur/iterate like DNS, and it
>can return more than one URI.  That would allow the base LoST discovery
>to find a server that returned the list.  The initial LoST query returns
>the list server, and a recur or iterate returns the list.
>
>Brian
>
>
>
>associated