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