Re: [paws] need for DB initialization message

[<[e-mail]>]

Hi Gabor,

You stated below:
>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;

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)"
<[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