[paws] need for DB initialization message

<Gabor.Bajko@nokia.com> Fri, 10 August 2012 00:02 UTC

Return-Path: <Gabor.Bajko@nokia.com>
X-Original-To: paws@ietfa.amsl.com
Delivered-To: paws@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6E121F846A for <paws@ietfa.amsl.com>; Thu, 9 Aug 2012 17:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaDpwIhIsGj9 for <paws@ietfa.amsl.com>; Thu, 9 Aug 2012 17:02:05 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A3B9A21F8464 for <paws@ietf.org>; Thu, 9 Aug 2012 17:02:04 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7A022Ft000588 for <paws@ietf.org>; Fri, 10 Aug 2012 03:02:02 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Aug 2012 03:02:59 +0300
Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.168]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0283.004; Fri, 10 Aug 2012 02:02:01 +0200
From: Gabor.Bajko@nokia.com
To: paws@ietf.org
Thread-Topic: need for DB initialization message
Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXw==
Date: Fri, 10 Aug 2012 00:02:01 +0000
Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F@008-AM1MPN1-006.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.23.137.91]
Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601FAFF1F008AM1MPN1006mg_"
MIME-Version: 1.0
X-OriginalArrivalTime: 10 Aug 2012 00:02:59.0490 (UTC) FILETIME=[80AC0020:01CD768B]
X-Nokia-AV: Clean
Subject: [paws] need for DB initialization message
X-BeenThere: paws@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Protocol to Access White Space database \(PAWS\)" <paws.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/paws>, <mailto:paws-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/paws>
List-Post: <mailto:paws@ietf.org>
List-Help: <mailto:paws-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/paws>, <mailto:paws-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 00:02:07 -0000

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