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
