My vote for DB initialization to be present. As I understand initialization
message can be sent upon initial pwer on and reboot scenarios followed by a
registration message. And a registration only message when ever otherwise
required, typically a link failure, or any other updates from master. Many
protocols retain messages this way.
Best Regards,
Sajeev Manikkoth
Mobile: +918792292002
Email: [email protected]
http://www.linkedin.com/in/mksajeev
________________________________
From: "[email protected]" <[email protected]>
To: [email protected]
Sent: Friday, 17 August 2012, 4:41
Subject: Re: [paws] need for DB initialization message
This thread was a bit derailed, so I’d like to get back to the original
question, which was whether we need a DB initialization message as proposed in
draft-das or not.
We seem to converge on the discovery of the regulatory domain, ie that the
regulatory domain can be discovered during the DB discovery process, and we do
not need a separate message to ask the DB what regulatory domain the master is
in.
Then, the question is whether the masters need to contact the DB prior to any
other communication, to learn the operating rules for that regulatory domain.
The alternative would be that the masters are preconfigured with the operating
rules for the regulatory domains they are going to operate in.
In the F2F, there were opinions on both sides, but not enough to call a
consensus. So, please send your preference on the need for DB initialization,
to the list. We need to make a decision on this and some other issues, so we
could move forward creating a wg document.
- Gabor
From:ext Rosen, Brian [mailto:[email protected]]
Sent: Thursday, August 09, 2012 5:15 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email protected]
Subject: Re: [paws] need for DB initialization message
<as individual>
I'm not so sure you need something separate for domain. ISTM that the DB
discovery could return it (possibly as a parameter on the DB URI). OTOH, you
might very well want to receive from the DB some kind of data specification
(that is, what is required to be provided in the registration), rather than
having it totally wired in to domain. That means, to me, that the registration
is a 4 way message exchange:
1. Device to DB: Authenticate me please
2. DB to device: Authentication accepted, send me this data
3. Device to DB: Here is my registration data
4. DB to device: Registration succeeded.
Now, having said that, you might just get authentication out of the TLS session
establishment, this not needing step 1.
Brian
On Aug 9, 2012, at 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
