Yeah, that also handles the situation where discovery gets you the national list and then you choose one from the list.
Brian On Aug 9, 2012, at 9:25 PM, "Joel M. Halpern" <[email protected]> wrote: > 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 whether 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
