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