Re: [paws] need for DB initialization message
"Rosen, Brian" <Brian.Rosen@neustar.biz> Mon, 13 August 2012 17:58 UTC
Return-Path: <brian.rosen@neustar.biz>
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 8879C21F8722 for <paws@ietfa.amsl.com>; Mon, 13 Aug 2012 10:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.13
X-Spam-Level:
X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 EH44btWIDqvX for <paws@ietfa.amsl.com>; Mon, 13 Aug 2012 10:58:47 -0700 (PDT)
Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7D321F8717 for <paws@ietf.org>; Mon, 13 Aug 2012 10:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1344880828; x=1660236644; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=KfGkyaHnZ/aacHj8UdK/H tI9oHIOqN+sinnmoAL+c/o=; b=CSKrq/BwBnx0ubbGXh6dhUFu+PnMbVakJ6nQ7 8ldIYE9n/PEqmdEoXHl+dDWi3DQic+6iho34Q3tF4LaQqyqTw==
Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12588253; Mon, 13 Aug 2012 14:00:27 -0400
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 13 Aug 2012 13:58:30 -0400
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Mon, 13 Aug 2012 13:58:30 -0400
Thread-Topic: [paws] need for DB initialization message
Thread-Index: Ac12he0A+5h4j+uqT6e4F6BpK7EzXwAAEnAAADHrtdAAENwZAAB0JGqAAABxXLj//7sdgP//h/i+
Message-ID: <55A5A9A87506CB4BA580BF9D531957DA690227B8@STNTEXCH01.cis.neustar.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: coh4EqUIIzrDAVZAckIxrw==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
To: "'basavaraj.patil@nokia.com'" <basavaraj.patil@nokia.com>, "'peter.mccann@huawei.com'" <peter.mccann@huawei.com>, "'jmh@joelhalpern.com'" <jmh@joelhalpern.com>, "'gabor.bajko@nokia.com'" <gabor.bajko@nokia.com>
Cc: "'paws@ietf.org'" <paws@ietf.org>
Subject: Re: [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: Mon, 13 Aug 2012 17:58:48 -0000
in what way is it overkill? You pass a location and a short URN in, using a simple HTTP exchange, and you get a (set of) URIs out. The extra stuff it does (like recur/iterate) is useful. About the only feature we don't need is validate, which is trivial to not support (since it's optional). Please cite a specific aspect of LoST which is overkill for us. Brian <as individual> -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Monday, August 13, 2012 01:49 PM Eastern Standard Time To: Rosen, Brian; peter.mccann@huawei.com; jmh@joelhalpern.com; Gabor.Bajko@nokia.com Cc: paws@ietf.org Subject: Re: [paws] need for DB initialization message I think that LoST is a bit of an overkill for what is really needed in the context of PAWS for database discovery. The WSDB discovery server (as per draft-probasco-paws-discovery-01.txt) can provide the master device with information about the relevant WSDB (or list of DBs) to query as well as the regulatory domain that it is currently located in. -Raj On 8/13/12 9:55 AM, "ext Rosen, Brian" <Brian.Rosen@neustar.biz> wrote: ><as individual> >I prefer LoST for discovery. LoST can do recur/iterate like DNS, and it >can return more than one URI. That would allow the base LoST discovery >to find a server that returned the list. The initial LoST query returns >the list server, and a recur or iterate returns the list. > >Brian > > > > -----Original Message----- >From: Peter McCann [mailto:Peter.McCann@huawei.com] >Sent: Monday, August 13, 2012 10:47 AM Eastern Standard Time >To: Joel M. Halpern; Gabor.Bajko@nokia.com >Cc: paws@ietf.org >Subject: Re: [paws] need for DB initialization message > >Agree with Joel. > >I think a LOST-style service (a) is good for discovering a server >associated >with a regulatory domain. After that, you can query the regulator (b) to >find >approved databases. Then, you can choose one of those databases with >which >you have a relationship or that you know through some means will service >your request (c). The protocol for (b) and (c) could both be PAWS, if we >just add some sort of indirection to our specification. > >-Pete > > >Joel M. Halpern wrote: >> 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, Gabor.Bajko@nokia.com 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:jmh@joelhalpern.com] >>> Sent: Thursday, August 09, 2012 6:25 PM >>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>> Cc: paws@ietf.org >>> 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, Gabor.Bajko@nokia.com 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 >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws
- [paws] need for DB initialization message Gabor.Bajko
- Re: [paws] need for DB initialization message Rosen, Brian
- Re: [paws] need for DB initialization message Joel M. Halpern
- Re: [paws] need for DB initialization message Rosen, Brian
- Re: [paws] need for DB initialization message Gabor.Bajko
- Re: [paws] need for DB initialization message Joel M. Halpern
- Re: [paws] need for DB initialization message Peter McCann
- Re: [paws] need for DB initialization message Rosen, Brian
- Re: [paws] need for DB initialization message Peter McCann
- Re: [paws] need for DB initialization message Basavaraj.Patil
- Re: [paws] need for DB initialization message Basavaraj.Patil
- Re: [paws] need for DB initialization message Rosen, Brian
- Re: [paws] need for DB initialization message Gabor.Bajko
- Re: [paws] need for DB initialization message Manikkoth Sajeev
- Re: [paws] need for DB initialization message Rosen, Brian
- Re: [paws] need for DB initialization message Gabor.Bajko