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