Re: [paws] need for DB initialization message

[<[e-mail]>]

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" <[e-mail]> 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
>
>
>
> -----Original Message-----
>From: 	Peter McCann [mailto:[e-mail]]
>Sent:	Monday, August 13, 2012 10:47 AM Eastern Standard Time
>To:	Joel M. Halpern; [e-mail]
>Cc:	[e-mail]
>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, [e-mail] 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:[e-mail]]
>>> Sent: Thursday, August 09, 2012 6:25 PM
>>> To: Bajko Gabor (Nokia-CIC/SiliconValley)
>>> Cc: [e-mail]
>>> 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, [e-mail] 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/paws
>_______________________________________________
>paws mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/paws