Re: [paws] need for DB initialization message

[Peter McCann <[e-mail]>]

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
> 
> 
> 
>  -----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