Re: [paws] DB discovery [was: RE: need for DB initialization message]

[<[e-mail]>]

I think we are saying the same thing. As you summarize, we can only choose between provisioning or discovery; if we choose discovery, we have to make sure the discovery mechanism is supported in all access networks where a master may be present. Since usually deployment is outside of ietf's control, this would be hard to achieve. 
If we choose provisioning, we only need a root server and that being provisioned in the masters.

Wrt to the use of LoST, if we anyway need an I-D to describe the DB provisioning, change the encoding to JSON, and profile it down to the minimum set of messages required, then it doesn't make much difference to me whether we reference the LoST RFC, or come up with our own protocol. 

What Scott described in the discovery document is in line with your point 2. below (what you call provisioning), so perhaps it could be a good start. But we need to hear other people's opinion as well. So please comment.

- Gabor

-----Original Message-----
From: ext Rosen, Brian [mailto:[e-mail]] 
Sent: Thursday, August 16, 2012 12:28 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [e-mail]
Subject: Re: [paws] DB discovery [was: RE: need for DB initialization message]

<as individual>
Discovery HAS to be independent of regulator or a device would be hard wired to a country.  The first step is to figure out what country you are in, then the path is dependent on how that regulatory domain works - and some may require you query a regulator operated (or contracted) mechanism that lists available DBs in that domain. But first, you need to figure out what country you are in, and then you need to contact something inside that country.

So, the first step discovery isn't something national, and it has to have polygons for countries.  That is what LoST does.  You can reinvent LoST, but that¹s what it does - keep a set of polygons, and have a list of URIs associated with each polygon, plus the equivalent if you have a street address instead of a lat/lon.

You are (rightly) worried about how you find that server.  As far as I know, there are three choices, and only 3.

1. Some entity runs a "root" server that everyone uses - the URI to it is ("well known") 2. Every device is provisioned with a root server that someone runs
("provisioned")
3. The local environment provides the URI of a root server like other local services (DHCP or some equivalent of it) ("local discovery")

Any one regulator won't run the root server.

Trying to decide on a single well known one takes something along the lines of ITU-T and some funding mechanism

So, you get to provisioning and local discovery.
If we choose provisioning, who runs it (or at least who chooses it, which has the "who pays for it" problem) If we choose local discovery, then how do we get it deployed?

And, the master lives on some access network.  Whether or not the master can make emergency calls is not relevant - the basic notion is that ISPs of any sort can't control devices connected to it directly OR INDIRECTLY, and thus they all have to support emergency calls, which means LoST.  But the time frame for deployment IS an issue.

Brian




On 8/16/12 3:05 PM, "[e-mail]" <[e-mail]> wrote:

>The discovery service would not necessarily be operated by the 
>manufacturer, it could eg be the regulator itself, or the db admin.
>AFAIK, currently there is no LoST server discovery mechanism supported 
>in the access networks,, thus we need to do sg about it if we want this 
>ecosystem to take off in the near future.
>What comes to supporting LoST for emergency calling purposes, note that 
>WS master devices may not be the ones making emergency calls, thus they 
>won't come with LoST support.
>- Gabor
>
>-----Original Message-----
>From: ext Rosen, Brian [mailto:[e-mail]]
>Sent: Monday, August 13, 2012 12:12 PM
>To: Bajko Gabor (Nokia-CIC/SiliconValley); Patil Basavaraj 
>(Nokia-CIC/Dallas); '[e-mail]'; '[e-mail]'
>Cc: '[e-mail]'
>Subject: RE: DB discovery [was: RE: [paws] need for DB initialization 
>message]
>
>The U-NAPTR is only part of LoST discovery.  If you don't like it, your 
>only alternative is provisioning, but some folks seem to like 
>provisioning.  We have a whole lot of experience with service discovery.
>There are no simple mechanisms that work globally without support from 
>some kind of infrastructure.  To me, the notion that a device 
>manufacturer will support a discovery service for the lifetime of the 
>device is less likely as ISP support for LoST, since the latter will be 
>needed for emergency calling.
>
>If we needed to do a json encoding of LoST, no one will object.
>
>The only subset we need is a single URN (although you could imagine a 
>country specific URN), and no validation.
>The service boundary part is very handy for a mobile device to 
>determine when it has moved beyond the boundary served by the same URN.  
>This would happen if you roamed across a border.  It's not a required 
>element on the server, and the client can ignore it.
>
>Brian <as individual>
>
>
>
> -----Original Message-----
>From:   [e-mail] [mailto:[e-mail]]
>Sent:   Monday, August 13, 2012 02:46 PM Eastern Standard Time
>To:     Rosen, Brian; [e-mail]; [e-mail];
>[e-mail]
>Cc:     [e-mail]
>Subject:        DB discovery [was: RE: [paws] need for DB initialization
>message]
>
>I could also see a few things why LoST might not be the best fit for 
>WSDB
>discovery:
>
>LoST does not specify LoST server discovery. There is a separate RFC on 
>discovering LoST using DHCP, but that's not deployment friendly. So a 
>discovery mechanism, eg the one described in Raj's document, is needed 
>anyway.
>
>LoST relies on U-NAPTR, and we all know how difficult is to get DNS 
>admins add new records to their zones.
>
>The WG seems to prefer JSON encoding to XML, to be able to support 
>lightweight devices, LoST uses XML.
>
>There is a lot of stuff in LoST, we would need a very small subset of it.
>
>- Gabor
>
>-----Original Message-----
>From: ext Rosen, Brian [mailto:[e-mail]]
>Sent: Monday, August 13, 2012 10:59 AM
>To: Patil Basavaraj (Nokia-CIC/Dallas); '[e-mail]'; 
>'[e-mail]'; Bajko Gabor (Nokia-CIC/SiliconValley)
>Cc: '[e-mail]'
>Subject: RE: [paws] need for DB initialization message
>
>in what way is it overkill?  You pass a location and a short URN in, 
>using a simple HTTP exchange, and you get a (set of) URIs out.  The 
>extra stuff it does (like recur/iterate) is useful.  About the only 
>feature we don't need is validate, which is trivial to not support 
>(since it's optional).
>
>Please cite a specific aspect of LoST which is overkill for us.
>
>Brian <as individual>
>
>
>
> -----Original Message-----
>From:   [e-mail] [mailto:[e-mail]]
>Sent:   Monday, August 13, 2012 01:49 PM Eastern Standard Time
>To:     Rosen, Brian; [e-mail]; [e-mail];
>[e-mail]
>Cc:     [e-mail]
>Subject:        Re: [paws] need for DB initialization message
>
>
>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
>
>_______________________________________________
>paws mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/paws