From bernie@ietf.hoeneisen.ch Fri Mar 5 05:14:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B9E28C28B for ; Fri, 5 Mar 2010 05:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3Iu6Ha1P4XB for ; Fri, 5 Mar 2010 05:14:29 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 3850428C28D for ; Fri, 5 Mar 2010 05:14:23 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NnXME-0006FA-KD; Fri, 05 Mar 2010 14:14:22 +0100 Date: Fri, 5 Mar 2010 14:14:22 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] BoF Agenda X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 13:14:30 -0000 Hi, I have just uploaded the current version of the BoF agenda to the Tools: http://www3.ietf.org/proceedings/10mar/agenda/e2md.txt For you convenience I have pasted the current version below. Changes might still occur. cheers, Bernie ----- Agenda E.164 to MetaData (E2MD) BoF IETF-77, Anaheim, CA, USA ----------------------------------- State: Draft Author: Bernie Hoeneisen Last Modified: 2010-03-05 BOF CHAIRS: Bernie Hoeneisen Dean Willis DATE/TIME/VENUE: Wed, 24 Mar 2010 / 1510-1610 / Redondo AGENDA: 1. Administrivia (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Presentations - Problem Statement (Bernie Hoeneisen, 10 min) draft-hoeneisen-e164-to-metadata-02 - Use Cases related to E2MD: - unused (void) (N.N., 5 min) draft-ietf-enum-unused-04 - cnam (Rich Shockey, 5 min) draft-ietf-enum-cnam-08 - send-n (Ray Bellis, 5 min) draft-bellis-enum-send-n-02 3. Open discussion (15 min) 4. Conclusions and Next Steps (Chairs/ADs, 15 min) NOTE: As we only got a 1 hour slot approved, we need to be strict on timing. Therefore, during the presentations, only "questions for clarification" are permitted, but no contributions to the discussion. The discussion will be opened only after all the presentations have been held. From bernie@ietf.hoeneisen.ch Fri Mar 5 05:20:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF3E3A8A5E for ; Fri, 5 Mar 2010 05:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DAHUjzVfryI for ; Fri, 5 Mar 2010 05:20:32 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 49B423A8F8C for ; Fri, 5 Mar 2010 05:20:30 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NnXSB-0006Gb-4K for e2md@ietf.org; Fri, 05 Mar 2010 14:20:31 +0100 Date: Fri, 5 Mar 2010 14:20:31 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Updated charter proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 13:20:33 -0000 Hi, I have updated the proposed e2md charter implementing the feedback I have received so far. Please find the current version on: http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt Please send all your feedback, comments or statements about this charter to the e2md list by next Wed, March 10th! cheers, Bernie, e2md BoF co-chair From dean.willis@softarmor.com Fri Mar 5 12:40:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C9628C34D for ; Fri, 5 Mar 2010 12:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCknv-r1EBJR for ; Fri, 5 Mar 2010 12:40:11 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5243528C318 for ; Fri, 5 Mar 2010 12:40:11 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o25KeCSZ026426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 5 Mar 2010 14:40:13 -0600 Message-Id: <1AC7B262-F30B-47B0-AB4A-3F6CBA5D9186@softarmor.com> From: Dean Willis To: e2md@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Mar 2010 14:40:06 -0600 X-Mailer: Apple Mail (2.936) Subject: [e2md] Is part of the SPID "metadata" and if so, what are the security properties? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:40:12 -0000 Please pardon the fumbling; I'm still trying to wrap my head around the fundamental problem of e2md. In the North American ISDN world, we have this thing called called a SPID: http://en.wikipedia.org/wiki/Service_Profile_Identifier This is a sequence of digits that identifies an ISDN circuit (a B channel). The SPID includes the E.164 number associated with the B channel, and it its most recent incarnation two digits of Terminal Identifier and 2 digits of Sharing terminal identifier. All in all, the SPID is basically the AOR+GRUU of ISDN. The service provider's provisioning database includes all sorts of things about the B-channel identified by the SPID, like whether its set up to handle voice calls or data transport, whether it is actually assigned to a switch right now, etc. These are relatively permanent aspects of the B-channel. For example, the database doesn't include the channel's DND status indicator, it's current hook status, or who it is in session with. It's been suggested to me that most of this "provisioning database" stuff associated with a SPID is what we're calling "metadata" in the current context. It's data about a "name" (aka, phone number) that might need to be known elsewhere before deciding whether or not a call should be placed to that name. For example, an originating mode might note that the targeted name is currently not-in-service, and therefore give an error message to the user without having to try an actually call set-up (INVITE). Does this SPID-related stuff seem like metadata? If it is, what are its security properties? Does it hurt if "the world" knows that for +19725199190 that the number is "in service" and that it is currently serviced by Verizon Dallas, without having to actually call the number and find out? If we put this data into ENUM/DNS, what are the risks associated with cache-poisoning attack like? is it any worse for an attacker to be able to convince my callers that my number has been disconnected than it is for the attacker to simply divert my calls elsewhere (including including into a black hole)? What about other sorts of data connected to that identifier, like my billing name and address? If my number were "unlisted", I certainly wouldn' want somebody to be able to do a DNS tree-walk and mine out my phone number. What about my address, registered bank account, etc.? Even touchier. -- Dean From dean.willis@softarmor.com Fri Mar 5 12:52:57 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4BD28C34D for ; Fri, 5 Mar 2010 12:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnYoC51aGw4I for ; Fri, 5 Mar 2010 12:52:56 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3E73928C318 for ; Fri, 5 Mar 2010 12:52:56 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o25Kqki8026540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Mar 2010 14:52:47 -0600 Message-Id: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> From: Dean Willis To: Bernhard Hoeneisen Content-Type: multipart/alternative; boundary=Apple-Mail-8--395131533 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Mar 2010 14:52:40 -0600 X-Mailer: Apple Mail (2.936) Cc: Robert Sparks , e2md@ietf.org Subject: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:52:58 -0000 --Apple-Mail-8--395131533 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit E.164 to MetaData (E2MD) (proposed charter) ------------------------ Last Modified: 2010-03-05 Additional information is available at tools.ietf.org/wg/e2md [not yet in use] Chair(s): * TBA Real-time Applications and Infrastructure Area Director(s): * Robert Sparks * Cullen Jennings Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings Mailing Lists: General Discussion: e2md@ietf.org Listinfo: https://www.ietf.org/mailman/listinfo/e2md To Subscribe: e2md-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/e2md/index.html Description of Working Group: Abstract E.164 to MetaData (E2MD) will use of the Domain Name System (DNS) either "make" before "use" or delete "of" in the preceding for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. IS thsi true? I thought we were adding metadata mapping alongside the URI mapping for the e.164 number Background ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. Thus, ENUM can be used to look up the services associated with an E.164 number. However, it is controversial whether or not the result of an ENUM lookup should always be intended to establish a communications session using the URI found in the corresponding Naming Authority Pointer (NAPTR) DNS Resource Record (RR). No, it's not. The result of an ENUM lookup is either nothing or a URI. Are you saying that encoding other cruft into the URI that makes the URI non-usable for contact purpose is controversial? That's not controversial either; it's inane. Problem Statement Several proposals for Enumservice registrations do not fulfill the above mentioned interpretation, which suggests that an ENUM lookup should always be intended to result in a communications session. These proposals are therefore virtually locked in the process. Such proposals include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, and 'send-n' to describe the structure of an ENUM tree. Another issue is that the result of an ENUM (E2U) lookup always needs to be an URI, which unnecessarily complicates simple mappings. The authors of such Enumservice proposals tried to circumvent the issues by introducing the 'data' URI scheme or inventing completely new URI schemes, with limited success however. The main objection remained that an ENUM lookup should always result in a URI intended to establish a communications session. Proposal The E2MD Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application E2MD, which can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. The resulting metadata can be used (for example) to provide hints about properties of certain ENUM domains or to provide information that can be used as attributes of an E.164 number. Zooks! This sounds like a big job, developing a Whole New System. Would just adding some resource records to the DNS that encode specific items of metadata suffice? IS "metadata" an unbounded representation space, or is it scoped to specific items (perhaps extensible through more RFCs and an IANA registry? E2MD will provide the means for services related to E.164 numbers that do not fit into the concept of ENUM (E2U), and thus a way forward for such existing ENUM WG documents in the queue. Along with the E2MD DDDS application a new IANA registry will be specified for registration of E2MD services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similarly as specified for Enumservice registrations. Not sure I like this; I can see a registry for new resource- records or subfields thereof (services? Gimme a vocabulary break!) but I'm guessing we need more than Expert Review to protect the security/ privacy sensitivity aspects. The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification. Limitations of the DNS are to be considered while defining the protocol; in particular packet size restrictions of deployed DNS transport. The E2MD Working Group may take on further proposals for E2MD service registrations (e.g. send-n) until the IANA registration for E2MD services is approved by the IESG. Out-Of-Scope E2MD shall not be specified as a general purpose lookup nor as bulk transfer protocol, but rather focus on clear use cases related to E.164 numbers. Goals and Milestones: Aug 2010 Submit Internet Draft(s) for the E2MD DDDS application and its IANA registry specification to IESG Dec 2010 Submit 'cnam' and 'unused' as E2MD service registrations (Informational) to IESG XXX 2011 Close the E2MD Working Group (or recharter) Internet-Drafts: http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 http://tools.ietf.org/html/draft-ietf-enum-unused-04 http://tools.ietf.org/html/draft-ietf-enum-cnam-08 (http://tools.ietf.org/html/draft-bellis-enum-send-n-02) Request For Comments: None --Apple-Mail-8--395131533 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit 
E.164 to MetaData (E2MD) (proposed charter)
------------------------

Last Modified: 2010-03-05

Additional information is available at tools.ietf.org/wg/e2md
[not yet in use]


Chair(s):

    * TBA

Real-time Applications and Infrastructure Area Director(s):

    * Robert Sparks <rjsparks@nostrum.com>
    * Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:

    * Cullen Jennings <fluffy@cisco.com>


Mailing Lists:

   General Discussion: e2md@ietf.org
   Listinfo: https://www.ietf.org/mailman/listinfo/e2md
   To Subscribe: e2md-request@ietf.org
   In Body: subscribe
   Archive: http://www.ietf.org/mail-archive/web/e2md/index.html



Description of Working Group:

Abstract

   E.164 to MetaData (E2MD) will use of the Domain Name System (DNS)
<dw> either "make" before "use" or delete "of" in the preceding</dw>
   for resolving E.164 numbers into metadata to provide information
   about E.164 numbers in cases where E.164 Number to URI Mapping
   (ENUM) can not be used.

<dw> IS thsi true? I thought we were adding metadata mapping alongside the URI mapping for the e.164 number </dw>


Background

   ENUM provides an identifier mapping mechanism to map E.164 numbers
   to Uniform Resource Identifiers (URIs) using the DNS.

   Thus, ENUM can be used to look up the services associated with an
   E.164 number.  However, it is controversial whether or not the result
   of an ENUM lookup should always be intended to establish a
   communications session using the URI found in the corresponding
   Naming Authority Pointer (NAPTR) DNS Resource Record (RR).

<dw> No, it's not. The result of an ENUM lookup is either nothing or a URI. Are you saying that encoding other cruft into the URI that makes the URI non-usable for contact purpose is controversial? That's not controversial either; it's inane. <dw>

Problem Statement

   Several proposals for Enumservice registrations do not fulfill the
   above mentioned interpretation, which suggests that an ENUM lookup
   should always be intended to result in a communications session.
   These proposals are therefore virtually locked in the process.
   Such proposals include (but are not limited to) Enumservices for
   'cnam' to provide information about the calling party name,
   'unused' to provide a hint that a number is not in use, and
   'send-n' to describe the structure of an ENUM tree.

   Another issue is that the result of an ENUM (E2U) lookup always
   needs to be an URI, which unnecessarily complicates simple mappings.

   The authors of such Enumservice proposals tried to circumvent the
   issues by introducing the 'data' URI scheme or inventing completely
   new URI schemes, with limited success however.  The main objection
   remained that an ENUM lookup should always result in a URI intended
   to establish a communications session.


Proposal

   The E2MD Working Group is chartered to develop a new Dynamic
   Delegation Discovery System (DDDS) application E2MD, which can be
   used with DNS NAPTR RRs for resolving E.164 numbers into metadata.
   The resulting metadata can be used (for example) to provide hints
   about properties of certain ENUM domains or to provide information
   that can be used as attributes of an E.164 number.
<dw>Zooks! This sounds like a big job, developing a Whole New System. Would just adding some resource records to the DNS that encode specific items of metadata suffice? IS "metadata" an unbounded representation space, or is it scoped to specific items (perhaps extensible through more RFCs and an IANA registry?</dw>

   E2MD will provide the means for services related to E.164 numbers
   that do not fit into the concept of ENUM (E2U), and thus a
   way forward for such existing ENUM WG documents in the queue.

   Along with the E2MD DDDS application a new IANA registry will be
   specified for registration of E2MD services. The registration policy
   shall be Expert Review and Specification Required (see RFC 5226),
   similarly as specified for Enumservice registrations.
<dw>Not sure I like this; I can see a registry for new resource-records or subfields thereof (services? Gimme a vocabulary break!) but I'm guessing we need more than Expert Review to protect the security/privacy sensitivity aspects.</dw>

   The E2MD specifications shall reuse as much as possible from the ENUM
   DDDS and its IANA registry specification.

   Limitations of the DNS are to be considered while defining the
   protocol; in particular packet size restrictions of deployed DNS
   transport.

   The E2MD Working Group may take on further proposals for E2MD service
   registrations (e.g. send-n) until the IANA registration for E2MD
   services is approved by the IESG.


Out-Of-Scope

   E2MD shall not be specified as a general purpose lookup nor as bulk
   transfer protocol, but rather focus on clear use cases related to
   E.164 numbers.


Goals and Milestones:

   Aug 2010  Submit Internet Draft(s) for the E2MD DDDS application and
             its IANA registry specification to IESG

   Dec 2010  Submit 'cnam' and 'unused' as E2MD service registrations
             (Informational) to IESG

   XXX 2011  Close the E2MD Working Group (or recharter)


Internet-Drafts:

   http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02
   http://tools.ietf.org/html/draft-ietf-enum-unused-04
   http://tools.ietf.org/html/draft-ietf-enum-cnam-08
   (http://tools.ietf.org/html/draft-bellis-enum-send-n-02)


Request For Comments:

   None

--Apple-Mail-8--395131533-- From dean.willis@softarmor.com Fri Mar 5 12:59:27 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B902D28C347 for ; Fri, 5 Mar 2010 12:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfNwWXHvRyzj for ; Fri, 5 Mar 2010 12:59:27 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E576228C318 for ; Fri, 5 Mar 2010 12:59:26 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o25KxIiO026586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Mar 2010 14:59:19 -0600 Message-Id: <2769B2E3-ABB0-44DD-85A5-FF65E79C64E0@softarmor.com> From: Dean Willis To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Mar 2010 14:59:12 -0600 References: X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] BoF Agenda X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:59:27 -0000 I like the proposed charter pretty well. However, I'd like to hear some discussion of what I think are the big thorny open issues with the problem statement: 1) Is "metadata" a wide-open concept, or do we need a fairly high- level of consensus on each schema change? This leads into the question expert-review vs standards action required for each new element. 2) How do we draw make sure that the privacy and attack sensitivity of each metadata element (metadatum?) Can we do this with usage and review guidelines? What to do about the wankers who say "This is for private NEUM databases only, the information Will NEVER be made public"? 3) What sort of representation format for metadata do we envision? XML? How does this play against DNS size issues? Maybe I just missed the discussion and you have these thorns already trimmed down; is so, please educated me. -- Dean From richard@shockey.us Fri Mar 5 13:26:11 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480AC28C368 for ; Fri, 5 Mar 2010 13:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc9ypKceIYEf for ; Fri, 5 Mar 2010 13:26:08 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id B5B4A3A8AE6 for ; Fri, 5 Mar 2010 13:26:08 -0800 (PST) Received: (qmail 29751 invoked by uid 0); 5 Mar 2010 21:26:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 5 Mar 2010 21:26:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=O1rVBg2EaHagPbxh1Gfyn/VYwJS11djqB1euzw6pb4TXgT7/b1FIFzc2peHX1Hlzkw0zUsR+Y+9Z9GcnAj6jxyJUV2X/3pT0UFZ854gpacFKXrlFWxopWhIOOfrhbcJ+; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nnf2B-0004UV-5h; Fri, 05 Mar 2010 14:26:11 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Bernie Hoeneisen'" References: <2769B2E3-ABB0-44DD-85A5-FF65E79C64E0@softarmor.com> In-Reply-To: <2769B2E3-ABB0-44DD-85A5-FF65E79C64E0@softarmor.com> Date: Fri, 5 Mar 2010 16:26:08 -0500 Message-ID: <024401cabcaa$792e9a80$6b8bcf80$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq8psDge5cwIxdHSGuA6SCXTmJPNQAAkWqw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] BoF Agenda X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 21:26:11 -0000 inline -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, March 05, 2010 3:59 PM To: Bernie Hoeneisen Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] BoF Agenda I like the proposed charter pretty well. However, I'd like to hear some discussion of what I think are the big thorny open issues with the problem statement: 1) Is "metadata" a wide-open concept, or do we need a fairly high- level of consensus on each schema change? This leads into the question expert-review vs standards action required for each new element. IMHO expert review the way we have done with the ENUM services registry for E2U in our revision of 3761 would work just fine. http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide-19 2) How do we draw make sure that the privacy and attack sensitivity of each metadata element (metadatum?) Can we do this with usage and review guidelines? What to do about the wankers who say "This is for private NEUM databases only, the information Will NEVER be made public"? Good point but we covered that issue when the ENUM WG approved CNAM draft. My text is here. http://tools.ietf.org/html/draft-ietf-enum-cnam-08 6. Distribution of CNAM Data The distribution of CNAM data is often highly restricted. The NAPTR records described herein should not be part of the e164.arpa DNS tree. Distribution of this NAPTR data would be either within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access. If such data was distributed in an open DNS system, a national regulatory body may have jurisdiction, especially since CNAM information may contain Personally Identifying Information. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How Personally Identifying Information is collected, distributed and subsequently regulated is out of the scope of this document Security considerations: The distribution of CNAM data is often highly restricted. Distribution of this data would typically be either within a service providers internal network, or on a private basis between one or more parties using a variety of security mechanisms to prohibit general public access. It should be noted that this content type is designed to carry potentially personal information and as such, may be subject to restrictions within various national jurisdictions. In many cases, the actual information that needs to be protected is the combination of the Name associated with the Telephone Number or the association of the name with the telephone call. So, it will be necessary to protect the response to the query that provides the association between the two elements. The pstn URI defined in this document is assumed to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPSec [15] and sometimes by physically protecting the underlying network. In any case, the provider should ensure that measures are taken to prevent both fraud and unauthorized disclosure by using a combination of authentication and Encryption. 3) What sort of representation format for metadata do we envision? XML? How does this play against DNS size issues? Text string? CNAM=William Tecumseh Sherman;SPID=A45BB21 I'm open minded here Maybe I just missed the discussion and you have these thorns already trimmed down; is so, please educated me. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Fri Mar 5 13:40:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EBF28C361 for ; Fri, 5 Mar 2010 13:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGv1ZIuDZlDs for ; Fri, 5 Mar 2010 13:40:31 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 5BC993A8E65 for ; Fri, 5 Mar 2010 13:40:31 -0800 (PST) Received: (qmail 29133 invoked by uid 0); 5 Mar 2010 21:40:34 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 5 Mar 2010 21:40:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=F/vVjXf3O7LeiQvKiijElbv6yZE/FfcZE3C0/DbQ3BrNrOl32s1hSYUeWWwzcPsa2+X5lzqZoZLxvd1HYy5KSFWkZjsL5CkKoiOUk9O8giOIq47ilV9T1YxLonJM44aa; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NnfG5-0001yv-MM; Fri, 05 Mar 2010 14:40:33 -0700 From: "Richard Shockey" To: "'Dean Willis'" , References: <1AC7B262-F30B-47B0-AB4A-3F6CBA5D9186@softarmor.com> In-Reply-To: <1AC7B262-F30B-47B0-AB4A-3F6CBA5D9186@softarmor.com> Date: Fri, 5 Mar 2010 16:40:31 -0500 Message-ID: <024501cabcac$7b47cba0$71d762e0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq8pBEJc3OKVw4nQk67FfS9EsQGDAABq4Xw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: Re: [e2md] Is part of the SPID "metadata" and if so, what are the security properties? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 21:40:33 -0000 The usage of SPID in the private ENUM context is to find the service provider of record. And all of this data is private usage as I point out in my previous note. SPID in this context is a North Americian PSTN thing. In addition there is work being undertaken in the ITU for a "global SIPD" for the purpose of facilitating global intercarrier interconnection. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, March 05, 2010 3:40 PM To: e2md@ietf.org Subject: [e2md] Is part of the SPID "metadata" and if so, what are the security properties? Please pardon the fumbling; I'm still trying to wrap my head around the fundamental problem of e2md. In the North American ISDN world, we have this thing called called a SPID: http://en.wikipedia.org/wiki/Service_Profile_Identifier This is a sequence of digits that identifies an ISDN circuit (a B channel). The SPID includes the E.164 number associated with the B channel, and it its most recent incarnation two digits of Terminal Identifier and 2 digits of Sharing terminal identifier. All in all, the SPID is basically the AOR+GRUU of ISDN. The service provider's provisioning database includes all sorts of things about the B-channel identified by the SPID, like whether its set up to handle voice calls or data transport, whether it is actually assigned to a switch right now, etc. These are relatively permanent aspects of the B-channel. For example, the database doesn't include the channel's DND status indicator, it's current hook status, or who it is in session with. It's been suggested to me that most of this "provisioning database" stuff associated with a SPID is what we're calling "metadata" in the current context. It's data about a "name" (aka, phone number) that might need to be known elsewhere before deciding whether or not a call should be placed to that name. For example, an originating mode might note that the targeted name is currently not-in-service, and therefore give an error message to the user without having to try an actually call set-up (INVITE). Does this SPID-related stuff seem like metadata? If it is, what are its security properties? Does it hurt if "the world" knows that for +19725199190 that the number is "in service" and that it is currently serviced by Verizon Dallas, without having to actually call the number and find out? If we put this data into ENUM/DNS, what are the risks associated with cache-poisoning attack like? is it any worse for an attacker to be able to convince my callers that my number has been disconnected than it is for the attacker to simply divert my calls elsewhere (including including into a black hole)? What about other sorts of data connected to that identifier, like my billing name and address? If my number were "unlisted", I certainly wouldn' want somebody to be able to do a DNS tree-walk and mine out my phone number. What about my address, registered bank account, etc.? Even touchier. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Fri Mar 5 14:00:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA6428C393 for ; Fri, 5 Mar 2010 14:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eddgdRUTPsuj for ; Fri, 5 Mar 2010 14:00:53 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 5C65528B23E for ; Fri, 5 Mar 2010 14:00:52 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NnfZY-0001EA-9M; Fri, 05 Mar 2010 23:00:40 +0100 Date: Fri, 5 Mar 2010 23:00:40 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Dean Willis In-Reply-To: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> Message-ID: References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: Robert Sparks , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 22:00:54 -0000 Hi Dean Thanks for your review and feedback. My comments inline. On Fri, 5 Mar 2010, Dean Willis wrote: > Abstract > > E.164 to MetaData (E2MD) will use of the Domain Name System (DNS) > > either "make" before "use" or delete "of" in the preceding Will be fixed. > for resolving E.164 numbers into metadata to provide information > about E.164 numbers in cases where E.164 Number to URI Mapping > (ENUM) can not be used. > > IS thsi true? I thought we were adding metadata mapping alongside the U > RI mapping for the e.164 number As per current proposal http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 there can be E2M and E2U records alongside in the same zone. E2M records resolve to a URI or to ASCII text (E2U records resolve always to a URI as per ENUM). > ENUM provides an identifier mapping mechanism to map E.164 numbers > to Uniform Resource Identifiers (URIs) using the DNS. > > Thus, ENUM can be used to look up the services associated with an > E.164 number. However, it is controversial whether or not the result > of an ENUM lookup should always be intended to establish a > communications session using the URI found in the corresponding > Naming Authority Pointer (NAPTR) DNS Resource Record (RR). > > No, it's not. The result of an ENUM lookup is either nothing or a URI. > Are you saying that encoding other cruft into the URI that makes the URI non > -usable for contact purpose is controversial? That's not controversial eithe > r; it's inane. As you say ENUM lookups can resolve to either nothing or to a URI. If it resolves to a URI, the URI can be intended to establish communications. The controversy starts, if the resulting URI is not intended for communications. This is where e2md starts... > Proposal > > The E2MD Working Group is chartered to develop a new Dynamic > Delegation Discovery System (DDDS) application E2MD, which can be > used with DNS NAPTR RRs for resolving E.164 numbers into metadata. > The resulting metadata can be used (for example) to provide hints > about properties of certain ENUM domains or to provide information > that can be used as attributes of an E.164 number. > > Zooks! This sounds like a big job, developing a Whole New System. Would > just adding some resource records to the DNS that encode specific items of m > etadata suffice? IS "metadata" an unbounded representation space, or is it s > coped to specific items (perhaps extensible through more RFCs and an IANA re > gistry? The E2MD and ENUM systems are to a large extent analog. We do not need to reinvent the wheel here and even existing code can be reused. Thus, the preferred approach is to copy - paste - modify the existing ENUM specs. > Along with the E2MD DDDS application a new IANA registry will be > specified for registration of E2MD services. The registration policy > shall be Expert Review and Specification Required (see RFC 5226), > similarly as specified for Enumservice registrations. > > Not sure I like this; I can see a registry for new resource-records or s > ubfields thereof (services? Gimme a vocabulary break!) but I'm guessing we n > eed more than Expert Review to protect the security/privacy sensitivity aspe > cts. Expert review guidelines certainly must cover security/privacy considerations, as it is the case with Enumservices. Whether or not Expert Review is sufficient for e2md-services is an interesting question. I believe it is sufficient as it is the case with Enumservices. cheers, Bernie From lconroy@insensate.co.uk Sat Mar 6 11:36:25 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1511228C0F2 for ; Sat, 6 Mar 2010 11:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5C8zHCfKHC7 for ; Sat, 6 Mar 2010 11:36:24 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id CC1BD3A8AA0 for ; Sat, 6 Mar 2010 11:36:23 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id E34B211236E; Sat, 6 Mar 2010 19:36:24 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> Date: Sat, 6 Mar 2010 19:36:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9104CBDF-3066-4DC8-8C47-37027BAE887A@insensate.co.uk> References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: Bernhard Hoeneisen , e2md@ietf.org, Robert Sparks Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 19:36:25 -0000 Hi Dean, folks, I may agree with Dean on inanity, or I may not; for now, I'm unsure. Thus, a question for clarification: I contend that... An ENUM lookup returns a set of rules (one or more NAPTRs), and any of those rules may be usable by one client and not-usable by another. A client might not support the contact form (URI scheme), or interpret the URI value differently from another client (e.g. private ENUM architectures with local DNS views meaning the client interprets a contact's target domain differently, ...). I further contend that... A publisher/server don't process each query differently (unless we are not in Kansas anymore, and it's some voodoo DNS server -- in which case speak to DNSEXT, not this proposed group). All the clients get all the rules, and once sorted it's up to each one of them to decide which of the returned rules to discard as unusable. So ... The cruft I may have in a NAPTR's constructed URI might make the URI contact non-usable **FOR SOME QUERYING CLIENTS** WHO DON"T HAVE OTHER DATA TO COMPLETE EFFECTVE RESOLUTION OF THE CONTACT TARGET. Other clients do have that data and so can work with the returned data. Q: Is this inane? [it looks pretty close to NICC's approach, or GSMA's or ...] all the best, Lawrence On 5 Mar 2010, at 20:52, Dean Willis wrote: > Background >=20 > ENUM provides an identifier mapping mechanism to map E.164 numbers > to Uniform Resource Identifiers (URIs) using the DNS. >=20 > Thus, ENUM can be used to look up the services associated with an > E.164 number. However, it is controversial whether or not the = result > of an ENUM lookup should always be intended to establish a > communications session using the URI found in the corresponding > Naming Authority Pointer (NAPTR) DNS Resource Record (RR). >=20 > No, it's not. The result of an ENUM lookup is either nothing or a = URI. Are you saying that encoding other cruft into the URI that makes = the URI non-usable for contact purpose is controversial? That's not = controversial either; it's inane. From richard@shockey.us Sat Mar 6 12:33:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B5A28C1FE for ; Sat, 6 Mar 2010 12:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMo6+3xbIU0k for ; Sat, 6 Mar 2010 12:32:54 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 3A72B3A8B56 for ; Sat, 6 Mar 2010 12:32:54 -0800 (PST) Received: (qmail 24367 invoked by uid 0); 6 Mar 2010 20:32:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 6 Mar 2010 20:32:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=QNDGMk2r9rkHKNe1Moovg6HJi8mfNF0G6iEZ2gYodAcJ8Hc9IWIv6UUDRa0bHxiWvU11UjUGHi9PvdKzqCzfzea7wXItwH0xHQirdJhczXDB8ISrn1mBn+7lJtdA/GkY; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1No0gC-0000de-Qx; Sat, 06 Mar 2010 13:32:57 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Bernhard Hoeneisen'" References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> In-Reply-To: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> Date: Sat, 6 Mar 2010 15:32:53 -0500 Message-ID: <000001cabd6c$3389ffc0$9a9dff40$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CABD42.4AB3F7C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq8pdhrj8glBhG7QeiSAaQhfCK0cgABxsig Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: 'Robert Sparks' , e2md@ietf.org Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 20:33:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CABD42.4AB3F7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We are going to have to re work this a bit. comments in line. From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, March 05, 2010 3:53 PM To: Bernhard Hoeneisen Cc: Robert Sparks; e2md@ietf.org Subject: [e2md] Draft charter, comments inline E.164 to MetaData (E2MD) (proposed charter) ------------------------ Last Modified: 2010-03-05 Additional information is available at tools.ietf.org/wg/e2md [not yet in use] Chair(s): * TBA Real-time Applications and Infrastructure Area Director(s): * Robert Sparks * Cullen Jennings Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings Mailing Lists: General Discussion: e2md@ietf.org Listinfo: https://www.ietf.org/mailman/listinfo/e2md To Subscribe: e2md-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/e2md/index.html Description of Working Group: Abstract E.164 to MetaData (E2MD) will use of the Domain Name System (DNS) either "make" before "use" or delete "of" in the preceding for resolving E.164 numbers into metadata to provide information about E.164 numbers in cases where E.164 Number to URI Mapping (ENUM) can not be used. IS thsi true? I thought we were adding metadata mapping alongside the URI mapping for the e.164 number E.164 to MetaData (E2MD) will build on RFC 3761 in either public or private instantiations to provide information about E.164 numbers in those cases where metadata about E.164 numbers cannot be expressed as URI's. Background ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. Thus, ENUM can be used to look up the services associated with an E.164 number. However, it is controversial whether or not the result of an ENUM lookup should always be intended to establish a communications session using the URI found in the corresponding Naming Authority Pointer (NAPTR) DNS Resource Record (RR). No, it's not. The result of an ENUM lookup is either nothing or a URI. Are you saying that encoding other cruft into the URI that makes the URI non-usable for contact purpose is controversial? That's not controversial either; it's inane. Yea I think we can delete the second paragraph. It provides no useful charter function. Problem Statement Several proposals for Enumservice registrations cannot currently be expressed as URI'. Such proposals include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, and 'send-n' to describe the structure of an ENUM tree or various forms of Service Provider Identification data (SPID) The authors of such Enumservice proposals tried to resolve these issues by introducing the 'data' URI scheme or inventing completely new URI schemes. Proposal The E2MD Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application E2MD, which can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. The resulting metadata can be used (for example) to provide hints about properties of certain ENUM domains or to provide information that can be used as attributes of an E.164 number. Zooks! This sounds like a big job, developing a Whole New System. Would just adding some resource records to the DNS that encode specific items of metadata suffice? IS "metadata" an unbounded representation space, or is it scoped to specific items (perhaps extensible through more RFCs and an IANA registry? E2MD will provide the means for data related to E.164 numbers that do not fit into the classic concept of ENUM (E2U) Along with the E2MD DDDS application a new IANA registry will be specified for registration of E2MD services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similarly as specified for Enumservice registrations. Not sure I like this; I can see a registry for new resource-records or subfields thereof (services? Gimme a vocabulary break!) but I'm guessing we need more than Expert Review to protect the security/privacy sensitivity aspects. As I mentioned in a earlier note we will certainly have to address issues of security and privacy here but we have sufficient models and deployments that address these concerns. This is old ground in ENUM terms and in fact is already being done in non standard environments. We can add flags to the registry to indicate concern but remember a great deal of this will be used in private closed environments. We have sample text that could be incorporated into the charter as noted from the CNAM draft. < RS IDEA> Distribution of E2MD Data The distribution of E2MD data could be highly restricted or contain Publically Identifying Information (PII). The NAPTR records developed by the WG could, in some cases, be inappropriate to be part of the e164.arpa DNS tree or any portion of the general DNS. Distribution of this NAPTR data would be either within a service providers internal network, or on a private basis between one or more parties using a variety of well known security mechanisms to prohibit general public access. If such PII data was distributed in an open DNS system, a national regulatory body may have jurisdiction. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How Personally Identifying Information is collected, distributed and subsequently regulated is out of the scope of the WG. The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification. Limitations of the DNS are to be considered while defining the protocol; in particular packet size restrictions of deployed DNS transport. The E2MD Working Group may take on further proposals for E2MD service registrations (e.g. send-n) until the IANA registration for E2MD services is approved by the IESG. Out-Of-Scope E2MD shall not be specified as a general purpose lookup nor as bulk transfer protocol, but rather focus on clear use cases related to E.164 numbers. Goals and Milestones: Aug 2010 Submit Internet Draft(s) for the E2MD DDDS application and its IANA registry specification to IESG Dec 2010 Submit 'cnam' and 'unused' as E2MD service registrations (Informational) to IESG XXX 2011 Close the E2MD Working Group (or recharter) Internet-Drafts: http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 http://tools.ietf.org/html/draft-ietf-enum-unused-04 http://tools.ietf.org/html/draft-ietf-enum-cnam-08 (http://tools.ietf.org/html/draft-bellis-enum-send-n-02) Request For Comments: None ------=_NextPart_000_0001_01CABD42.4AB3F7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 We are going to have to re work this a bit… = comments in line.

 

From:= e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of = Dean Willis
Sent: Friday, March 05, 2010 3:53 PM
To: Bernhard Hoeneisen
Cc: Robert Sparks; e2md@ietf.org
Subject: [e2md] Draft charter, comments inline = <dw>

 

E.164 to MetaData (E2MD) (proposed =
charter)
------------------------
 
Last Modified: =
2010-03-05
 
Additional =
information is available at =
tools.ietf.org/wg/e2md
[not yet in =
use]
 
 
Chair(s):
 
 =
;   * =
TBA
 
Real-time =
Applications and Infrastructure Area =
Director(s):
 
  =
;  * Robert Sparks <rjsparks@nostrum.com>
    * Cullen Jennings <fluffy@cisco.com>
 
Real-time Applications and =
Infrastructure Area =
Advisor:
 
  &nb=
sp; * Cullen Jennings <fluffy@cisco.com>
 
 
Mailing =
Lists:
 
   =
General Discussion: e2md@ietf.org
&nbs=
p;  Listinfo: https://www.ietf.org/=
mailman/listinfo/e2md
   To =
Subscribe: e2md-request@ietf.org
   In Body: =
subscribe
   Archive: http://www.=
ietf.org/mail-archive/web/e2md/index.html
&=
nbsp;
 
 
=

Description of Working =
Group:
 
Abstract
 
   E.164 to MetaData =
(E2MD) will use of the Domain Name System (DNS)
<dw> either =
"make" before "use" or delete "of" in the =
preceding</dw>
 
  =
 for resolving E.164 numbers into metadata to provide =
information
   about E.164 numbers in =
cases where E.164 Number to URI =
Mapping
   (ENUM) can not be =
used.
 
<dw> IS thsi =
true? I thought we were adding metadata mapping alongside the URI =
mapping for the e.164 number </dw>
 
 
<RS =
REVISED TEXT> E.164 to MetaData (E2MD) will build on RFC 3761 in =
either public or private instantiations to provide information about =
E.164 numbers in those cases where metadata about E.164 numbers cannot =
be expressed as URI’s. =

 
 
=

Background
 
 &n=
bsp; ENUM provides an identifier mapping mechanism to map E.164 =
numbers
   to Uniform Resource =
Identifiers (URIs) using the =
DNS.
 
   Thus, =
ENUM can be used to look up the services associated with =
an
   E.164 number.  However, it is =
controversial whether or not the =
result
   of an ENUM lookup should always =
be intended to establish a
   =
communications session using the URI found in the =
corresponding
   Naming Authority Pointer =
(NAPTR) DNS Resource Record =
(RR).
 
<dw> No, it's =
not. The result of an ENUM lookup is either nothing or a URI. Are you =
saying that encoding other cruft into the URI that makes the URI =
non-usable for contact purpose is controversial? That's not =
controversial either; it's inane. =
<dw>
 
<RS> =
Yea I think we can delete the second paragraph. It provides no useful =
charter function.
 
 <=
/o:p>
<REWRITE RS>
Problem =
Statement
 
   =
Several proposals for Enumservice registrations cannot currently be =
expressed as =
URI’.
 
  =
 Such proposals include (but are not limited to) Enumservices =
for
   'cnam' to provide information =
about the calling party name,
   'unused' =
to provide a hint that a number is not in use, =
and
   'send-n' to describe the structure =
of an ENUM tree or various forms of Service Provider Identification data =
(SPID) 
 
   =
The authors of such Enumservice proposals tried to resolve =
these
   issues by introducing the 'data' =
URI scheme or inventing completely
   new =
URI schemes. =

 
 
=

Proposal
 
 &nbs=
p; The E2MD Working Group is chartered to develop a new =
Dynamic
   Delegation Discovery System =
(DDDS) application E2MD, which can be
   =
used with DNS NAPTR RRs for resolving E.164 numbers into =
metadata.
   The resulting metadata can =
be used (for example) to provide hints
   =
about properties of certain ENUM domains or to provide =
information
   that can be used as =
attributes of an E.164 =
number.
 
 
<dw>Zooks! =
This sounds like a big job, developing a Whole New System. Would just =
adding some resource records to the DNS that encode specific items of =
metadata suffice? IS "metadata" an unbounded representation =
space, or is it scoped to specific items (perhaps extensible through =
more RFCs and an IANA =
registry?</dw>
 
 
<RS>  =

 
   E2MD will =
provide the means for data related to E.164 =
numbers
   that do not fit into the =
classic concept of ENUM =
(E2U)
 
   =
Along with the E2MD DDDS application a new IANA registry will =
be
   specified for registration of E2MD =
services. The registration policy
   =
shall be Expert Review and Specification Required (see RFC =
5226),
   similarly as specified for =
Enumservice =
registrations.
 
<dw>Not sure =
I like this; I can see a registry for new resource-records or subfields =
thereof (services? Gimme a vocabulary break!) but I'm guessing we need =
more than Expert Review to protect the security/privacy sensitivity =
aspects.</dw>
 
<=
RS> As I mentioned in a earlier note we will certainly have to =
address issues of security and privacy here but we have sufficient =
models and deployments that address these concerns. This is old ground =
in ENUM terms and in fact is already being done in non standard =
environments. We can add flags to the registry to indicate concern but =
remember a great deal of this will be used in private closed =
environments. We have sample text that could be incorporated into the =
charter as noted from the CNAM =
draft.
 
 =

< RS IDEA>
 



Distribution of E2MD Data



    



        &nbs=
p;
The distribution of E2MD data could be highly restricted or contain =
Publically Identifying
Information (PII). The NAPTR records developed by the WG could, in some =
cases, be
inappropriate to be part of =
the         
e164.arpa DNS tree or any portion of the general DNS.  Distribution =
of
this NAPTR data would be either within a service providers internal =
network, or
on a private basis between one or more parties using a variety of well =
known security
mechanisms to prohibit general public access.



    



        &nbs=
p; If
such PII data was distributed in an open DNS system, a national =
regulatory body
may have jurisdiction.



Such a body may choose to restrict distribution =
of the
data in such a way that it may not pass over =
that         
country's national borders.  How Personally Identifying Information =
is
collected, distributed and subsequently regulated is out of the scope of =
the
WG.



 
 
   The =
E2MD specifications shall reuse as much as possible from the =
ENUM
   DDDS and its IANA registry =
specification.
 
 &nb=
sp; Limitations of the DNS are to be considered while defining =
the
   protocol; in particular packet =
size restrictions of deployed DNS
   =
transport.
 
   =
The E2MD Working Group may take on further proposals for E2MD =
service
   registrations (e.g. send-n) =
until the IANA registration for E2MD
   =
services is approved by the =
IESG.
 
 <=
/pre>
Out-Of-Scope
 
&=
nbsp;  E2MD shall not be specified as a general purpose lookup nor =
as bulk
   transfer protocol, but rather =
focus on clear use cases related to
   =
E.164 =
numbers.
 
 
Goals and =
Milestones:
 
  =
 Aug 2010  Submit Internet Draft(s) for the E2MD DDDS application =
and
        =
     its IANA registry specification to =
IESG
 
   Dec =
2010  Submit 'cnam' and 'unused' as E2MD service =
registrations
      &n=
bsp;      (Informational) to =
IESG
 
   XXX =
2011  Close the E2MD Working Group (or =
recharter)
 
 
Internet-Drafts:
 
   h=
ttp://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02
   http://tool=
s.ietf.org/html/draft-ietf-enum-unused-04
 =
  http://tools.=
ietf.org/html/draft-ietf-enum-cnam-08
 &nbs=
p; (http://to=
ols.ietf.org/html/draft-bellis-enum-send-n-02)
<=
o:p> 
 
Request For =
Comments:
 
   =
None
------=_NextPart_000_0001_01CABD42.4AB3F7C0-- From lconroy@insensate.co.uk Sat Mar 6 13:12:00 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 029D728C21A for ; Sat, 6 Mar 2010 13:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kKGJbPxy-38 for ; Sat, 6 Mar 2010 13:11:33 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 7DBFB28C1FF for ; Sat, 6 Mar 2010 13:11:32 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 8E76C112433; Sat, 6 Mar 2010 21:11:34 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <000001cabd6c$3389ffc0$9a9dff40$@us> Date: Sat, 6 Mar 2010 21:11:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> <000001cabd6c$3389ffc0$9a9dff40$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1077) Cc: 'Bernhard Hoeneisen' , 'Robert Sparks' , e2md@ietf.org Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 21:12:01 -0000 Hi Richard, folks, If I read it properly, I like this draft charter; the revisions help a = lot. I do have a few comments on the revised text * Please can we say this is based on RFC3761bis et al, NOT on 3761. This matters as the registration process is streamlined in the updated = docs, AND 3761bis has P-, which might be a helpful item for PII/Data = Protection use. * Please can we avoid ' typos? Its making my eye's bleed. c/URI's/URIs/ c/URI'./URI./ * Please can someone produce a clean copy of the new proposed charter -- It's getting hard to see the text. Finally, as an aside, writing a new DDDS Application spec is actually = quite a short task; writing a DDDS database spec is also a fairly short task. Taking an = existing one as a model this can be done readily in a slow week. I know -- I tried it and cross = checked against 340x. [In theory we could not only blend some bits of E2U, but even dump NAPTR = for some other RR -- to do the latter is unwise, if only as it would also require a new RR = type spec, but ...] The real issue is the process for such a set of changes can be long, = from publication, review, agreement, through approval, publication, selection of experts to = priming IANA, before we're open for business. I assume the timescales are for publication as WGLC'd = drafts? all the best, Lawrence On 6 Mar 2010, at 20:32, Richard Shockey wrote: > We are going to have to re work this a bit. comments in line. >=20 >=20 >=20 > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Dean > Willis > Sent: Friday, March 05, 2010 3:53 PM > To: Bernhard Hoeneisen > Cc: Robert Sparks; e2md@ietf.org > Subject: [e2md] Draft charter, comments inline >=20 >=20 >=20 > E.164 to MetaData (E2MD) (proposed charter) > ------------------------ >=20 > Last Modified: 2010-03-05 >=20 > Additional information is available at tools.ietf.org/wg/e2md > [not yet in use] >=20 >=20 > Chair(s): >=20 > * TBA >=20 > Real-time Applications and Infrastructure Area Director(s): >=20 > * Robert Sparks > * Cullen Jennings >=20 > Real-time Applications and Infrastructure Area Advisor: >=20 > * Cullen Jennings >=20 >=20 > Mailing Lists: >=20 > General Discussion: e2md@ietf.org > Listinfo: https://www.ietf.org/mailman/listinfo/e2md > To Subscribe: e2md-request@ietf.org > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/e2md/index.html >=20 >=20 >=20 > Description of Working Group: >=20 > Abstract >=20 > E.164 to MetaData (E2MD) will use of the Domain Name System (DNS) > either "make" before "use" or delete "of" in the preceding >=20 > for resolving E.164 numbers into metadata to provide information > about E.164 numbers in cases where E.164 Number to URI Mapping > (ENUM) can not be used. >=20 > IS thsi true? I thought we were adding metadata mapping alongside = the > URI mapping for the e.164 number >=20 >=20 > E.164 to MetaData (E2MD) will build on RFC 3761 in = either > public or private instantiations to provide information about E.164 = numbers > in those cases where metadata about E.164 numbers cannot be expressed = as > URI's.=20 >=20 >=20 > Background >=20 > ENUM provides an identifier mapping mechanism to map E.164 numbers > to Uniform Resource Identifiers (URIs) using the DNS. >=20 > Thus, ENUM can be used to look up the services associated with an > E.164 number. However, it is controversial whether or not the = result > of an ENUM lookup should always be intended to establish a > communications session using the URI found in the corresponding > Naming Authority Pointer (NAPTR) DNS Resource Record (RR). >=20 > No, it's not. The result of an ENUM lookup is either nothing or a = URI. > Are you saying that encoding other cruft into the URI that makes the = URI > non-usable for contact purpose is controversial? That's not = controversial > either; it's inane. >=20 > Yea I think we can delete the second paragraph. It provides no = useful > charter function. >=20 >=20 > > Problem Statement >=20 > Several proposals for Enumservice registrations cannot currently be > expressed as URI'. >=20 > Such proposals include (but are not limited to) Enumservices for > 'cnam' to provide information about the calling party name, > 'unused' to provide a hint that a number is not in use, and > 'send-n' to describe the structure of an ENUM tree or various forms = of > Service Provider Identification data (SPID)=20 >=20 > The authors of such Enumservice proposals tried to resolve these > issues by introducing the 'data' URI scheme or inventing completely > new URI schemes.=20 >=20 >=20 > Proposal >=20 > The E2MD Working Group is chartered to develop a new Dynamic > Delegation Discovery System (DDDS) application E2MD, which can be > used with DNS NAPTR RRs for resolving E.164 numbers into metadata. > The resulting metadata can be used (for example) to provide hints > about properties of certain ENUM domains or to provide information > that can be used as attributes of an E.164 number. >=20 >=20 > Zooks! This sounds like a big job, developing a Whole New System. = Would > just adding some resource records to the DNS that encode specific = items of > metadata suffice? IS "metadata" an unbounded representation space, or = is it > scoped to specific items (perhaps extensible through more RFCs and an = IANA > registry? >=20 >=20 > =20 >=20 > E2MD will provide the means for data related to E.164 numbers > that do not fit into the classic concept of ENUM (E2U) >=20 > Along with the E2MD DDDS application a new IANA registry will be > specified for registration of E2MD services. The registration policy > shall be Expert Review and Specification Required (see RFC 5226), > similarly as specified for Enumservice registrations. >=20 > Not sure I like this; I can see a registry for new = resource-records or > subfields thereof (services? Gimme a vocabulary break!) but I'm = guessing we > need more than Expert Review to protect the security/privacy = sensitivity > aspects. >=20 > As I mentioned in a earlier note we will certainly have to = address > issues of security and privacy here but we have sufficient models and > deployments that address these concerns. This is old ground in ENUM = terms > and in fact is already being done in non standard environments. We can = add > flags to the registry to indicate concern but remember a great deal of = this > will be used in private closed environments. We have sample text that = could > be incorporated into the charter as noted from the CNAM draft. >=20 >=20 > < RS IDEA> >=20 >=20 > Distribution of E2MD Data >=20 >=20 >=20 > The distribution of E2MD data could be highly restricted or > contain Publically Identifying Information (PII). The NAPTR records > developed by the WG could, in some cases, be inappropriate to be part = of the > e164.arpa DNS tree or any portion of the general DNS. Distribution of = this > NAPTR data would be either within a service providers internal = network, or > on a private basis between one or more parties using a variety of well = known > security mechanisms to prohibit general public access. >=20 >=20 >=20 > If such PII data was distributed in an open DNS system, a = national > regulatory body may have jurisdiction. >=20 > Such a body may choose to restrict distribution of the data in such a = way > that it may not pass over that country's national borders. = How > Personally Identifying Information is collected, distributed and > subsequently regulated is out of the scope of the WG. >=20 >=20 >=20 > The E2MD specifications shall reuse as much as possible from the = ENUM > DDDS and its IANA registry specification. >=20 > Limitations of the DNS are to be considered while defining the > protocol; in particular packet size restrictions of deployed DNS > transport. >=20 > The E2MD Working Group may take on further proposals for E2MD = service > registrations (e.g. send-n) until the IANA registration for E2MD > services is approved by the IESG. >=20 >=20 > Out-Of-Scope >=20 > E2MD shall not be specified as a general purpose lookup nor as bulk > transfer protocol, but rather focus on clear use cases related to > E.164 numbers. >=20 >=20 > Goals and Milestones: >=20 > Aug 2010 Submit Internet Draft(s) for the E2MD DDDS application and > its IANA registry specification to IESG >=20 > Dec 2010 Submit 'cnam' and 'unused' as E2MD service registrations > (Informational) to IESG >=20 > XXX 2011 Close the E2MD Working Group (or recharter) >=20 >=20 > Internet-Drafts: >=20 > http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 > http://tools.ietf.org/html/draft-ietf-enum-unused-04 > http://tools.ietf.org/html/draft-ietf-enum-cnam-08 > (http://tools.ietf.org/html/draft-bellis-enum-send-n-02) >=20 >=20 > Request For Comments: >=20 > None >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Sat Mar 6 14:35:46 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B26B3A9017 for ; Sat, 6 Mar 2010 14:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmWjkCXDpBk4 for ; Sat, 6 Mar 2010 14:35:42 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 198A03A900B for ; Sat, 6 Mar 2010 14:35:41 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1No2az-0007tW-F2; Sat, 06 Mar 2010 23:35:41 +0100 Date: Sat, 6 Mar 2010 23:35:41 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <000001cabd6c$3389ffc0$9a9dff40$@us> Message-ID: References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> <000001cabd6c$3389ffc0$9a9dff40$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-751221086-1267914941=:28763" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 22:35:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-751221086-1267914941=:28763 Content-Type: TEXT/PLAIN; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Rich On Sat, 6 Mar 2010, Richard Shockey wrote: > =A0=A0 for resolving E.164 numbers into metadata to provide information > =A0=A0 about E.164 numbers in cases where E.164 Number to URI Mapping > =A0=A0 (ENUM) can not be used. >=20 > IS thsi true? I thought we were adding metadata mapping alongside=20 > the URI mapping for the e.164 number >=20 > E.164 to MetaData (E2MD) will build on RFC 3761 in=20 > either public or private instant iations to provide information about=20 > E.164 numbers in those cases where metadata about E.164 numbers cannot=20 > be expressed as URI=A2s. Are you proposing that an E2M(D) lookup should never result in an URI? If so, how should we treat the following cases: - 'unused', to provide more information about the reason at some http-URI - pointers to more complicated data-structures, e.g. XML; i.e. the XML data itself is not in the NAPTR RR (too long), but instead a pointer to some server providing the XML data. (the indirection case) cheers, Bernie --37663318-751221086-1267914941=:28763-- From richard@shockey.us Sun Mar 7 08:45:51 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F813A90DE for ; Sun, 7 Mar 2010 08:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU6IdGfEaZ8M for ; Sun, 7 Mar 2010 08:45:50 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 314AB3A90DF for ; Sun, 7 Mar 2010 08:45:50 -0800 (PST) Received: (qmail 14334 invoked by uid 0); 7 Mar 2010 16:45:53 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 7 Mar 2010 16:45:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=L5iSlwIHXQSPVqu3kRNuK9IeN+TMkEn0GIyD+pw4dRFrwKUSQ660lTY+pXi585TPmxNqJHlZ/xfs5MTfw9jB0uFk9NQO+zrfkFRt/beA5TqDhICQygy1UeSy6rOBLjsI; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NoJc0-0003VC-NK; Sun, 07 Mar 2010 09:45:53 -0700 From: "Richard Shockey" To: "'Bernie Hoeneisen'" References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> <000001cabd6c$3389ffc0$9a9dff40$@us> In-Reply-To: Date: Sun, 7 Mar 2010 11:45:50 -0500 Message-ID: <00b601cabe15$a585cb00$f0916100$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acq9fVzcHB6YYHv1STmzZD6FL8xOmAAl4Ncg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 16:45:51 -0000 OK I understand ..then you say RS REVISED TEXT 2> E.164 to MetaData (E2MD) will build on RFC 3761bis in either public or private instantiations to provide information about = E.164 numbers. In some cases, metadata about E.164 numbers might not be = expressed as URI?s as required by the E2U DDDS application described in RFC 3761. -----Original Message----- From: Bernie Hoeneisen [mailto:bernie@ietf.hoeneisen.ch]=20 Sent: Saturday, March 06, 2010 5:36 PM To: Richard Shockey Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Draft charter, comments inline Hi Rich On Sat, 6 Mar 2010, Richard Shockey wrote: > =A0=A0 for resolving E.164 numbers into metadata to provide = information > =A0=A0 about E.164 numbers in cases where E.164 Number to URI Mapping > =A0=A0 (ENUM) can not be used. >=20 > IS thsi true? I thought we were adding metadata mapping alongside = > the URI mapping for the e.164 number >=20 > E.164 to MetaData (E2MD) will build on RFC 3761 in=20 > either public or private instant iations to provide information about=20 > E.164 numbers in those cases where metadata about E.164 numbers cannot = > be expressed as URI?s. Are you proposing that an E2M(D) lookup should never result in an URI? If so, how should we treat the following cases: - 'unused', to provide more information about the reason at some = http-URI - pointers to more complicated data-structures, e.g. XML; i.e. the XML data itself is not in the NAPTR RR (too long), but instead a pointer to some server providing the XML data. (the indirection case) cheers, Bernie From jay@nzrs.net.nz Sun Mar 7 13:35:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C5328C1BF for ; Sun, 7 Mar 2010 13:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NHOype7+MP1 for ; Sun, 7 Mar 2010 13:35:53 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 919F33A91B0 for ; Sun, 7 Mar 2010 13:35:53 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 883912DA535; Mon, 8 Mar 2010 10:35:55 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY4lkx4e-Dge; Mon, 8 Mar 2010 10:35:55 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 53D922DA42B; Mon, 8 Mar 2010 10:35:55 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <00b601cabe15$a585cb00$f0916100$@us> Date: Mon, 8 Mar 2010 10:35:54 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <34B1E314-CCF3-4FA8-996D-682BC3200D5C@nzrs.net.nz> References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> <000001cabd6c$3389ffc0$9a9dff40$@us> <00b601cabe15$a585cb00$f0916100$@us> To: Richard Shockey , Bernie Hoeneisen X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 21:35:54 -0000 I support the draft charter with Richard's edited edits. I would add my support to two views already expressed: 1. Creating a new DDDS is not difficult and both far more appropriate = and deliverable than a new RR. In fact a new RR would be quite wrong = for this. We have NAPTR and have to stick with until someone, anyone = please, comes up with a complete replacement. 2. The privacy issues are out of scope for this group to try to solve = and are identical to those that come with ENUM, where they have been = adequately addressed in the CNAM draft. Personally I would not even = identify them as it all comes down to personal prejudice and personal = choice within the context of the bleeding obvious. I doubt SMTP would = ever have been developed if the privacy hand grenade had been lobbed in = at regular intervals. best Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From lendl@nic.at Mon Mar 8 01:48:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C763A682A for ; Mon, 8 Mar 2010 01:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgqtGxf0-E7s for ; Mon, 8 Mar 2010 01:48:30 -0800 (PST) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 8DEFC3A6804 for ; Mon, 8 Mar 2010 01:48:26 -0800 (PST) Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 098CC4C534 for ; Mon, 8 Mar 2010 10:48:29 +0100 (CET) Message-ID: <4B94C7ED.20108@nic.at> Date: Mon, 08 Mar 2010 10:48:29 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: e2md@ietf.org References: <6D332FF8-7815-423F-94ED-52293A13CDEC@softarmor.com> <000001cabd6c$3389ffc0$9a9dff40$@us> <00b601cabe15$a585cb00$f0916100$@us> <34B1E314-CCF3-4FA8-996D-682BC3200D5C@nzrs.net.nz> In-Reply-To: <34B1E314-CCF3-4FA8-996D-682BC3200D5C@nzrs.net.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] Draft charter, comments inline X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 09:48:32 -0000 A few comments from my side: On 07.03.2010 22:35, Jay Daley wrote: > > 1. Creating a new DDDS is not difficult and both far more appropriate > and deliverable than a new RR. Yes. See e.g. http://tools.ietf.org/id/draft-lendl-domain-policy-ddds-02.txt where I key off the domain and not ENUM-like on the E.164. > In fact a new RR would be quite wrong > for this. We have NAPTR and have to stick with until someone, anyone > please, comes up with a complete replacement. Well, you can either go with an ENUM clone, or you might want to restrict what features of the NAPTR you actually want to use, e.g. * non-terminals * RE parsing I don't have the reference handy, but under the name S-NAPTR something a bit more lightweight has already been proposed. This is still the same NAPTR RR on the wire, just the interpretation changed a bit. > 2. The privacy issues are out of scope for this group to try to solve > and are identical to those that come with ENUM, where they have been > adequately addressed in the CNAM draft. Yes and no. In terms of PII, yes. But if you talk about SPIDs and call routing, I have the nagging feeling that a lot of folks here and in other IETF lists miss the fact that once you consider multi-homed corporate PBXs and want to do fully featured call routing from/to them, then the global E.164->SPID mapping data must de-facto be public. There just is no way around that. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From dean.willis@softarmor.com Thu Mar 11 12:36:21 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21613A6BEB for ; Thu, 11 Mar 2010 12:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbUcejhqe4Lu for ; Thu, 11 Mar 2010 12:36:20 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B4E423A6C2D for ; Thu, 11 Mar 2010 12:25:18 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2BKOIcZ021646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Mar 2010 14:24:20 -0600 Message-Id: From: Dean Willis To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 14:24:13 -0600 X-Mailer: Apple Mail (2.936) Cc: Robert Sparks , Gonzalo Camarillo Subject: [e2md] New proposed charter for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 20:36:21 -0000 Bernie and I just iterated on the charter proposal based on current feedback and a call yesterday with the ADs, and below is the meat of our current proposal. Note that Richard had suggested adding the open issue about metadata sensitivity explicitly into the charter with a declaration that this problem is "out of scope". We suspect that won't fly, and would like to instead use some of our Anaheim meeting time to discuss this issue and possible resolutions. ------- Description of Working Group: Abstract E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI Mapping) in either public or private instantiations to provide additional information about E.164 (telephone) numbers. In some use cases, information (metadata) about E.164 numbers cannot be expressed as a URI (Uniform Resource Identifier) as required by the ENUM DDDS (Dynamic Delegation Discovery System) described in RFC 3761bis. Therefore, E2MD will define a different mechanism for expressing metadata. The initial expectation is that this mechanism will be a new DDDS for metadata, based on RFC 3761bis, that returns standardized metadata instead of URIs. Background ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically used to look up the services associated with an E.164 number, each of which is represented by a URI. However, there is more information about a telephone number that may be useful when establishing a communications session using that phone number. For example, this information might be used to decide or what sort of communications session to establish using that phone number, or whether to accept a communications session offered by someone using that phone number. We refer to this information as "metadata". Several example use cases for metadata have been documented as Internet drafts, and will be considered during the work of E2MD for inclusion in the group's work product. Typically, this metadata information is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis innapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. Previous Enumservice proposals tried to resolve these issues by using the 'data' URI scheme or inventing completely new URI schemes, however it is believed that such proposals do not satisfy the general use case for metadata, and a new approach is required. Problem Statement Typically, the phone-number asssociated metadata is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis inapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. The initially favored approach is to define an additional ENUM service (E2M) that maps phone-numbers to metadata that will operate in parallel to the current ENUM service (E2U), which maps phpne numbers to URIs. Current proposals for metadata to be addressed by E2MD include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, 'send-n' to describe the structure of an ENUM tree, "spid" to describe a service provider identifier, "itad" to describe an internet telephony administrative domain, etc. Scope of Working Group: The E2MD Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application that can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will provide the means for data related to E.164 numbers that do not fit into the classic concept of ENUM (E2U). The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification. Along with the E2MD DDDS application a new IANA registry will be specified for registration of E2MD services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similar to those specified for Enumservice (E2U) registrations. Limitations of the DNS are to be considered while defining the protocol; in particular packet size restrictions of deployed DNS transport. The E2MD Working Group may take on further proposals for E2MD service registrations (e.g. send-n) until the IANA registration for E2MD services is approved by the IESG. E2MD shall not be specified as a general purpose lookup nor as bulk transfer protocol, but rather focus on clear use cases related to E. 164 numbers. Goals and Milestones: Aug 2010 Submit Internet Draft(s) for the E2MD DDDS application and its IANA registry specification to IESG Dec 2010 Submit 'cnam' and 'unused' as E2MD service registrations (Informational) to IESG XXX 2011 Close the E2MD Working Group (or recharter) From dean.willis@softarmor.com Thu Mar 11 12:44:40 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B9063A6B66 for ; Thu, 11 Mar 2010 12:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmLYlKCM3TRd for ; Thu, 11 Mar 2010 12:44:39 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8B2E23A6C94 for ; Thu, 11 Mar 2010 12:33:55 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2BKXUpG021698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Mar 2010 14:33:31 -0600 Message-Id: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> From: Dean Willis To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 14:33:24 -0600 X-Mailer: Apple Mail (2.936) Cc: Robert Sparks , Gonzalo Camarillo Subject: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 20:44:40 -0000 Bernie and I discussed the agenda yesterday with the ADs. We are considering the following alternative structure for the agenda due to the severe time constraints. What do you folks think? ------- AGENDA: 1. Administrivia (Chairs, 5 min) * Note takers, Jabber scribes * Agenda bashing 2. Problem Statement and Example Use Cases -- Bernie, 10 min (one slide per topic) * General problem statement: draft-hoeneisen-e164-to-metadata-02 * unused/void: draft-ietf-enum-unused-04 * cnam: draft-ietf-enum-cnam-08 * send-n: draft-bellis-enum-send-n-02 3. Open Issues with E2MD -- Dean, 10 min * Issues of DNS characteristics and metadata Cacheing properties Distribution latency / propagation "Globally" interesting (no localized queries) * Privacy issues: Is the DNS the "right place" for all metadata? Can we bound the metadata for public use? Can we constrain this with an applicability statement? 3. Open discussion on issues -- 15 min 4. Discussion of Charter -- Bernie -- 15 min 5. Conclusions and polls -- Chairs -- 5 min From richard@shockey.us Thu Mar 11 13:04:10 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1042F3A6924 for ; Thu, 11 Mar 2010 13:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyQKuQAkOirm for ; Thu, 11 Mar 2010 13:04:08 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 6D88C3A68AF for ; Thu, 11 Mar 2010 13:02:05 -0800 (PST) Received: (qmail 31287 invoked by uid 0); 11 Mar 2010 21:02:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 11 Mar 2010 21:02:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=gJdzJtu0Arc6/LfkpwDZZXESalNZABDiqL0jgQvbR/0Ks+UIRDiYTxsfjcaZZIwko/y/RWR0Jli0Gd57zh8W0oiNBqRaU4a1UiqsCB56gyCckhwHecBbjwqPeZ5VXWy0; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NppWE-0002sx-JM; Thu, 11 Mar 2010 14:02:10 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'E.164 To MetaData BOF discussion list'" References: In-Reply-To: Date: Thu, 11 Mar 2010 16:02:07 -0500 Message-ID: <00a901cac15e$1cf3d970$56db8c50$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrBWocFB4zVVhk4SEG1YINDQsqmmgAAvm1A Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: 'Robert Sparks' , 'Gonzalo Camarillo' Subject: Re: [e2md] New proposed charter for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:04:10 -0000 Why won't it fly, since CNAM itself is one of the core types of metadata under discussion? The issue is easily analogous to location data in SIP. We do tools not policy. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, March 11, 2010 3:24 PM To: E.164 To MetaData BOF discussion list Cc: Robert Sparks; Gonzalo Camarillo Subject: [e2md] New proposed charter for E2MD Bernie and I just iterated on the charter proposal based on current feedback and a call yesterday with the ADs, and below is the meat of our current proposal. Note that Richard had suggested adding the open issue about metadata sensitivity explicitly into the charter with a declaration that this problem is "out of scope". We suspect that won't fly, and would like to instead use some of our Anaheim meeting time to discuss this issue and possible resolutions. ------- Description of Working Group: Abstract E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI Mapping) in either public or private instantiations to provide additional information about E.164 (telephone) numbers. In some use cases, information (metadata) about E.164 numbers cannot be expressed as a URI (Uniform Resource Identifier) as required by the ENUM DDDS (Dynamic Delegation Discovery System) described in RFC 3761bis. Therefore, E2MD will define a different mechanism for expressing metadata. The initial expectation is that this mechanism will be a new DDDS for metadata, based on RFC 3761bis, that returns standardized metadata instead of URIs. Background ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically used to look up the services associated with an E.164 number, each of which is represented by a URI. However, there is more information about a telephone number that may be useful when establishing a communications session using that phone number. For example, this information might be used to decide or what sort of communications session to establish using that phone number, or whether to accept a communications session offered by someone using that phone number. We refer to this information as "metadata". Several example use cases for metadata have been documented as Internet drafts, and will be considered during the work of E2MD for inclusion in the group's work product. Typically, this metadata information is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis innapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. Previous Enumservice proposals tried to resolve these issues by using the 'data' URI scheme or inventing completely new URI schemes, however it is believed that such proposals do not satisfy the general use case for metadata, and a new approach is required. Problem Statement Typically, the phone-number asssociated metadata is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis inapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. The initially favored approach is to define an additional ENUM service (E2M) that maps phone-numbers to metadata that will operate in parallel to the current ENUM service (E2U), which maps phpne numbers to URIs. Current proposals for metadata to be addressed by E2MD include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, 'send-n' to describe the structure of an ENUM tree, "spid" to describe a service provider identifier, "itad" to describe an internet telephony administrative domain, etc. Scope of Working Group: The E2MD Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application that can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will provide the means for data related to E.164 numbers that do not fit into the classic concept of ENUM (E2U). The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification. Along with the E2MD DDDS application a new IANA registry will be specified for registration of E2MD services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similar to those specified for Enumservice (E2U) registrations. Limitations of the DNS are to be considered while defining the protocol; in particular packet size restrictions of deployed DNS transport. The E2MD Working Group may take on further proposals for E2MD service registrations (e.g. send-n) until the IANA registration for E2MD services is approved by the IESG. E2MD shall not be specified as a general purpose lookup nor as bulk transfer protocol, but rather focus on clear use cases related to E. 164 numbers. Goals and Milestones: Aug 2010 Submit Internet Draft(s) for the E2MD DDDS application and its IANA registry specification to IESG Dec 2010 Submit 'cnam' and 'unused' as E2MD service registrations (Informational) to IESG XXX 2011 Close the E2MD Working Group (or recharter) _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Thu Mar 11 13:08:06 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48533A67F4 for ; Thu, 11 Mar 2010 13:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ1y2a2iXLiC for ; Thu, 11 Mar 2010 13:08:03 -0800 (PST) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 6AF843A67E5 for ; Thu, 11 Mar 2010 13:08:02 -0800 (PST) Received: (qmail 16590 invoked by uid 0); 11 Mar 2010 21:08:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 11 Mar 2010 21:08:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=iZyT+9XFzSvtbfKfrxlBeaZo1l5BKg9JUMtm63M0fCyh39oBE2YWQDfdnL98BGyzmbgPrPoKQ0W0B0vJ9qgGO22SOyOFIOMvaOQ8NeT4yd6zu1ddV5Ch9eUilfR6+Tl4; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nppby-0005su-Hu; Thu, 11 Mar 2010 14:08:06 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'E.164 To MetaData BOF discussion list'" References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> In-Reply-To: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> Date: Thu, 11 Mar 2010 16:08:03 -0500 Message-ID: <00aa01cac15e$f11dd070$d3597150$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrBW7ELQsT+c+DxQPCdfjnqsh1ZhwAApMLA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: 'Robert Sparks' , 'Gonzalo Camarillo' Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:08:06 -0000 Well #3 for 10 min given the time frame strikes me as "end world hunger issues". You can make a case that alternatively that SIP signaling itself might be another way to transport metadata this but we seem to be restraining ourselves to public and private DNS methodologies first which is OK with me. I'm very weary of discussions that could drift into policy. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, March 11, 2010 3:33 PM To: E.164 To MetaData BOF discussion list Cc: Robert Sparks; Gonzalo Camarillo Subject: [e2md] Proposed agenda change for E2md at Anaheim Bernie and I discussed the agenda yesterday with the ADs. We are considering the following alternative structure for the agenda due to the severe time constraints. What do you folks think? ------- AGENDA: 1. Administrivia (Chairs, 5 min) * Note takers, Jabber scribes * Agenda bashing 2. Problem Statement and Example Use Cases -- Bernie, 10 min (one slide per topic) * General problem statement: draft-hoeneisen-e164-to-metadata-02 * unused/void: draft-ietf-enum-unused-04 * cnam: draft-ietf-enum-cnam-08 * send-n: draft-bellis-enum-send-n-02 3. Open Issues with E2MD -- Dean, 10 min * Issues of DNS characteristics and metadata Cacheing properties Distribution latency / propagation "Globally" interesting (no localized queries) * Privacy issues: Is the DNS the "right place" for all metadata? Can we bound the metadata for public use? Can we constrain this with an applicability statement? 3. Open discussion on issues -- 15 min 4. Discussion of Charter -- Bernie -- 15 min 5. Conclusions and polls -- Chairs -- 5 min _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Thu Mar 11 13:13:18 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25C63A68D4 for ; Thu, 11 Mar 2010 13:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suwv6TyVvhtx for ; Thu, 11 Mar 2010 13:13:15 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 585313A684E for ; Thu, 11 Mar 2010 13:13:01 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2BLD2XB022104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Mar 2010 15:13:04 -0600 Message-Id: From: Dean Willis To: Richard Shockey In-Reply-To: <00a901cac15e$1cf3d970$56db8c50$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 15:12:57 -0600 References: <00a901cac15e$1cf3d970$56db8c50$@us> X-Mailer: Apple Mail (2.936) Cc: 'Robert Sparks' , "'E.164 To MetaData BOF discussion list'" , 'Gonzalo Camarillo' Subject: Re: [e2md] New proposed charter for E2MD X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:13:18 -0000 On Mar 11, 2010, at 3:02 PM, Richard Shockey wrote: > Why won't it fly, since CNAM itself is one of the core types of > metadata > under discussion? The issue is easily analogous to location data in > SIP. We > do tools not policy. > The argument goes like this: The DNS wonks and privacy/security wonks are going to get upset if we hit them with a charter explicitly for developing a protocol whose intended use is only private/restricted networks. That's just not what they think the IETF does. But if we have a dual-use (Internet/intranet) protocol that conveys a multiplicity of information elements, and some of those information elements have sensitivities that require applicability statements restricting them to intranets, then we have a lot of precedents that might get us somewhere with forming a WG. The fact that we don't have a consensus on how to handle the sensitive elements yet is what necessitates talking it through in the BOF. Talking about controversial subjects in a BOF is always fraught with hazard, so we're trying to stage it in smoothly. The ideas is "We have all of these use cases, and only SOME of them have sensitivities. The other use-cases are no-brainers, we can just do them. How are we going to deal with the sensitive use cases?" Of course, if we can get an on-list consensus sorted out between now and then, it'll make the BOF run a lot smoother. -- Dean From dean.willis@softarmor.com Thu Mar 11 13:36:39 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292C83A6894 for ; Thu, 11 Mar 2010 13:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TneN83cUbwuM for ; Thu, 11 Mar 2010 13:36:38 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EB3B63A688D for ; Thu, 11 Mar 2010 13:36:34 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2BLaZM3022243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Mar 2010 15:36:36 -0600 Message-Id: From: Dean Willis To: "Richard Shockey" In-Reply-To: <00aa01cac15e$f11dd070$d3597150$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 15:36:29 -0600 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> X-Mailer: Apple Mail (2.936) Cc: 'Robert Sparks' , "'E.164 To MetaData BOF discussion list'" , 'Gonzalo Camarillo' Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:36:39 -0000 On Mar 11, 2010, at 3:08 PM, Richard Shockey wrote: > Well #3 for 10 min given the time frame strikes me as "end world > hunger > issues". You can make a case that alternatively that SIP signaling > itself > might be another way to transport metadata this but we seem to be > restraining ourselves to public and private DNS methodologies first > which is > OK with me. > I think we have two (or perhaps three) classes of metadata under discussion. One class of metadata is the sort of globally-useful asker-independent sort of stuff that the DNS thrives on. "Unused" is a perfect example of this sort of data. It's like putting the semantics of the "placeholder" web page created by most registrars directly into the DNS. It's presence indicates that the relevant phone number is in fact serviced by the ITAD in question, but that it is not currently mapped to a phone number and calling it would be pointless. It's refresh/ caching/propagation/TTL characteristics are also perfect for the DNS. ITAD-identifier (Which ITAD owns this number?) might well be a member of this class, although that;s subject to some debate: some people want to use this for a next-hop route identifier, which makes it NOT structurally suitable for the DNS. And some people seem to think that there might be national restrictions on divulging this information to the public or conflicts with LNP structural mandates, making the metadata NOT politically suited for the DNS. CNAM is structurally perfectly suitable for the DNS. But the DNS mapping between phone number and calling party name is reversible, which has consequences. in classic telephony, caller-ID masking and "unlisted" numbers are two distinct services. If one metadatum is used for both we could get into a problem where enabling caller-ID effectively makes the number publicly listed, and/or making a number publicly listed prevents placing a call with caller-ID suppressed. This is why we've (IETF) previously said caller-ID (both calling-name and calling-number) is better as a SIP level thing, which lets it be controlled by the SSP on a call-by-call basis. Certainly one could obviate some of the these data access concerns by hiding the entire DNS from untrusted users, but that's it's own world of ugly hack. We see that it might be easier to charter a working group that would define multiple data elements, SOME of which might require hiding the DNS, than it would be to charter a working group that would by definition assume that ALL of its data elements being put into the DNS require hiding from the world. So we have data elements that are 1) structurally and politically appropriate for the DNS, 2) structurally appropriate but politically questionable for the DNS, such that they might require hiding the DNS from untrusted accessors, and 3) Structurally inappropriate for the DNS because they require requester-specific response determination, immediate propagation, large responses, or other things that the DNS just doesn't do well. The E2MD group has to provide a mechanism that allows for the determination of which category each proposed use case falls into, and we have to decide how we're going to handle use-cases (like CNAM) that aren't quite right for the DNS because of political, not structural, concerns. Requiring an applicability statement for the use case that restricts a DNS serving that metadata to private use might be a reasonable solution. If so, E2MD has to make this distinction on case- by-case basis. Other solutions, such as encrypting the data with a key known to only a subset of the users of the DNS might also provide adequate solutions; such would also have to be addressed on a case-by- case basis. -- Dean From richard@shockey.us Thu Mar 11 14:59:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CAD3A6957 for ; Thu, 11 Mar 2010 14:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvmcqrZIWkHJ for ; Thu, 11 Mar 2010 14:59:43 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 20D9F3A6833 for ; Thu, 11 Mar 2010 14:59:37 -0800 (PST) Received: (qmail 20826 invoked by uid 0); 11 Mar 2010 22:59:42 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 11 Mar 2010 22:59:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:x-cr-hashedpuzzle:x-cr-puzzleid:X-Identified-User; b=B6FpcSoAIJTnmMJA2cA3YEB+msQAoIUieGMqJaAZGfMk8ZKXGyeTj3UJITcxxRWuTtHrqsNL5Q0YNegdGN1qftRUkBU2WVaP0LTPzxkj5jILMx1OyqUmuUXetbXm7ovZ; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NprLy-0007Vi-JJ; Thu, 11 Mar 2010 15:59:42 -0700 From: "Richard Shockey" To: "'Dean Willis'" References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> In-Reply-To: Date: Thu, 11 Mar 2010 17:59:39 -0500 Message-ID: <00ca01cac16e$883aaaf0$98b000d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrBYvVOu6vEyqMrSFS065dDjB7EbQABuThA Content-Language: en-us x-cr-hashedpuzzle: Fcg= Djch FpET Idst I8/v J7T4 LaBe OIrk PRxw Q1ay YW36 bXBN po6p pw/U sa0o wFuZ; 4; ZABlAGEAbgAuAHcAaQBsAGwAaQBzAEAAcwBvAGYAdABhAHIAbQBvAHIALgBjAG8AbQA7AGUAMgBtAGQAQABpAGUAdABmAC4AbwByAGcAOwBnAG8AbgB6AGEAbABvAC4AYwBhAG0AYQByAGkAbABsAG8AQABlAHIAaQBjAHMAcwBvAG4ALgBjAG8AbQA7AHIAagBzAEAAbgBvAHMAdAByAHUAbQAuAGMAbwBtAA==; Sosha1_v1; 7; {FF258B87-4DE6-4E69-9783-7DFEE8069CD1}; cgBpAGMAaABhAHIAZABAAHMAaABvAGMAawBlAHkALgB1AHMA; Thu, 11 Mar 2010 22:59:30 GMT; UgBFADoAIABbAGUAMgBtAGQAXQAgAFAAcgBvAHAAbwBzAGUAZAAgAGEAZwBlAG4AZABhACAAYwBoAGEAbgBnAGUAIABmAG8AcgAgAEUAMgBtAGQAIABhAHQAIABBAG4AYQBoAGUAaQBtAA== x-cr-puzzleid: {FF258B87-4DE6-4E69-9783-7DFEE8069CD1} X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: 'Robert Sparks' , "'E.164 To MetaData BOF discussion list'" , 'Gonzalo Camarillo' Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 22:59:44 -0000 I don't buy the argument that it's this WG's task to define what is and is not appropriate for the use of DNS. OR defining how data may or may not be used. If there are restrictions on the use of SPID's and CNAM, ITAD's whatever that is a matter for National Regulatory Authorities period. And as a reminder the use of the entire ENUM 164.arpa tree are governed by NRA's for each CC are defined by the MOU between the ITU and the IAB. That policy..WG don't do policy. A substantial number of these use cases will not be used in situations where the data will never ever be visible to the single root DNS but only in private closed instantiations. Nearly half of the ENUM trees out there and proposed are in fact non visible. It should be apparent that the real use case here for non visible meta data are those use / business cases that will attempt to substitute E2MD data for TCAP look ups. I still have my NO TCAP cap BTW. The real problem is that folks are going off and doing all sorts of crazy things and its time to standardize the elements and process as we did with ENUM registrations and go home. This was hopefully to a simple WG to wrap up loose elements that the ENUM WG didn't want to tackle. And I remind you that we already have defined how LNP data looks in URI's and SIP and there seems to be no problem there. RFC 4694 I think my suggestion of text to punt this entire issue in the charter made more sense. It should go back in. Distribution of E2MD Data The distribution of E2MD data could be highly restricted or contain Publically Identifying Information (PII). The NAPTR records developed by the WG could, in some cases, be inappropriate to be part of the RFC 3761bis e164.arpa DNS tree or any portion of the general DNS. Distribution of this NAPTR data would be either within a service provider's internal network, or on a private basis between one or more parties using a variety of well known security mechanisms to prohibit general public access. If such PII data was distributed in an open DNS system, a national regulatory body may have jurisdiction. Such a body may choose to restrict distribution of the data in such a way that it may not pass over that country's national borders. How Personally Identifying Information is collected, distributed and subsequently regulated is out of the scope of the WG. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, March 11, 2010 4:36 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list'; 'Robert Sparks'; 'Gonzalo Camarillo' Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim On Mar 11, 2010, at 3:08 PM, Richard Shockey wrote: > Well #3 for 10 min given the time frame strikes me as "end world > hunger > issues". You can make a case that alternatively that SIP signaling > itself > might be another way to transport metadata this but we seem to be > restraining ourselves to public and private DNS methodologies first > which is > OK with me. > I think we have two (or perhaps three) classes of metadata under discussion. One class of metadata is the sort of globally-useful asker-independent sort of stuff that the DNS thrives on. "Unused" is a perfect example of this sort of data. It's like putting the semantics of the "placeholder" web page created by most registrars directly into the DNS. It's presence indicates that the relevant phone number is in fact serviced by the ITAD in question, but that it is not currently mapped to a phone number and calling it would be pointless. It's refresh/ caching/propagation/TTL characteristics are also perfect for the DNS. ITAD-identifier (Which ITAD owns this number?) might well be a member of this class, although that;s subject to some debate: some people want to use this for a next-hop route identifier, which makes it NOT structurally suitable for the DNS. And some people seem to think that there might be national restrictions on divulging this information to the public or conflicts with LNP structural mandates, making the metadata NOT politically suited for the DNS. CNAM is structurally perfectly suitable for the DNS. But the DNS mapping between phone number and calling party name is reversible, which has consequences. in classic telephony, caller-ID masking and "unlisted" numbers are two distinct services. If one metadatum is used for both we could get into a problem where enabling caller-ID effectively makes the number publicly listed, and/or making a number publicly listed prevents placing a call with caller-ID suppressed. This is why we've (IETF) previously said caller-ID (both calling-name and calling-number) is better as a SIP level thing, which lets it be controlled by the SSP on a call-by-call basis. Certainly one could obviate some of the these data access concerns by hiding the entire DNS from untrusted users, but that's it's own world of ugly hack. We see that it might be easier to charter a working group that would define multiple data elements, SOME of which might require hiding the DNS, than it would be to charter a working group that would by definition assume that ALL of its data elements being put into the DNS require hiding from the world. So we have data elements that are 1) structurally and politically appropriate for the DNS, 2) structurally appropriate but politically questionable for the DNS, such that they might require hiding the DNS from untrusted accessors, and 3) Structurally inappropriate for the DNS because they require requester-specific response determination, immediate propagation, large responses, or other things that the DNS just doesn't do well. The E2MD group has to provide a mechanism that allows for the determination of which category each proposed use case falls into, and we have to decide how we're going to handle use-cases (like CNAM) that aren't quite right for the DNS because of political, not structural, concerns. Requiring an applicability statement for the use case that restricts a DNS serving that metadata to private use might be a reasonable solution. If so, E2MD has to make this distinction on case- by-case basis. Other solutions, such as encrypting the data with a key known to only a subset of the users of the DNS might also provide adequate solutions; such would also have to be addressed on a case-by- case basis. -- Dean From dean.willis@softarmor.com Thu Mar 11 15:50:00 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601843A6849 for ; Thu, 11 Mar 2010 15:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaTquYli-NES for ; Thu, 11 Mar 2010 15:49:58 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B8ADB3A6835 for ; Thu, 11 Mar 2010 15:49:58 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2BNnxDu023098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Mar 2010 17:50:00 -0600 Message-Id: <01A49B90-4EE1-4D7F-A00A-6E0074D35D87@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <00ca01cac16e$883aaaf0$98b000d0$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 17:49:54 -0600 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> X-Mailer: Apple Mail (2.936) Cc: 'Robert Sparks' , "'E.164 To MetaData BOF discussion list'" , 'Gonzalo Camarillo' Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:50:00 -0000 On Mar 11, 2010, at 4:59 PM, Richard Shockey wrote: > I don't buy the argument that it's this WG's task to define what is > and is > not appropriate for the use of DNS. OR defining how data may or may > not be > used. If there are restrictions on the use of SPID's and CNAM, ITAD's > whatever that is a matter for National Regulatory Authorities > period. And as > a reminder the use of the entire ENUM 164.arpa tree are governed by > NRA's > for each CC are defined by the MOU between the ITU and the IAB. That > policy..WG don't do policy. No, we don't do policy. We define protocols for the Internet. > A substantial number of these use cases will not be used in > situations where > the data will never ever be visible to the single root DNS but only in > private closed instantiations. Nearly half of the ENUM trees out > there and > proposed are in fact non visible. The counter-argument: they ought to be using some sort of industry- forum web-service API for looking up this data, not the DNS. Or if they want to use a hacked-up DNS, they needn't waste our time with it. We (IETF) DO NOT DO PROTOCOLS FOR PRIVATE NETWORKS. If we're going to do a protocol, it is going to have general applicability, have a thorough security analysis including a threat model and defenses against identified threats where possible, and come with warning labels about inappropriate usage or indefensible threats. > > It should be apparent that the real use case here for non visible > meta data > are those use / business cases that will attempt to substitute E2MD > data for > TCAP look ups. I still have my NO TCAP cap BTW. The real problem is > that > folks are going off and doing all sorts of crazy things and its time > to > standardize the elements and process as we did with ENUM > registrations and > go home. This was hopefully to a simple WG to wrap up loose elements > that > the ENUM WG didn't want to tackle. > > And I remind you that we already have defined how LNP data looks in > URI's > and SIP and there seems to be no problem there. RFC 4694 I didn't say that we couldn't handle LNP. I just said that some people have raised questions about how LNP data interacts with E2MD, and that as a consequence, we may have to be prepared to answer those questions. > > I think my suggestion of text to punt this entire issue in the > charter made > more sense. It should go back in. > Fine, but from what the ADs told us on yesterday's call. don't count on getting a working group formed as a result. We're going to have to confront their concerns and come up with well-reasoned answers, not just tell them to stop being silly. > Distribution of E2MD Data > > The distribution of E2MD data could be highly restricted or contain > Publically Identifying Information (PII). The NAPTR records > developed by the > WG could, in some cases, be inappropriate to be part of the RFC > 3761bis > e164.arpa DNS tree or any portion of the general DNS. Distribution > of this > NAPTR data would be either within a service provider's internal > network, or > on a private basis between one or more parties using a variety of > well known > security mechanisms to prohibit general public access. > > If such PII data was distributed in an open DNS system, a national > regulatory body may have jurisdiction. Such a body may choose to > restrict > distribution of the data in such a way that it may not pass over that > country's national borders. How Personally Identifying Information is > collected, distributed and subsequently regulated is out of the > scope of the > WG. > Perhaps the above could be recast in a way less likely to draw fire. How about: --- Some of the metadata standardized by E2MD may be subject to policy constraints within certain administrative jurisdictions, such as national boundaries. When such policy constraints exist, it is the responsibility of E2MD operators to comply with those constraints on the handling of metadata. The E2MD working group will not attempt to anticipate or mandate such policies. Rather, it is assumed that if policy constraints exist for access to the metadata in an E2MD database, then such policy will be enforced by the E2MD operator through enforcement of access controls on the entire E2MD database affected by the policy constraints. In particular, the E2MD working group will not address AAA issues within the E2MD framework. --- Note hoe the above states that their might be E2MD databases that have restricted access and are not part of teh general ENUM tree, but doesn't rub their noses in it. Makes it potentially easier for them to pretend they didn't notice. Or possibly in the RFC we might say: ---- Security Considerations The data in the E2MD database may or may not require privacy, integrity protection, or authentication. Such protections, if required, are not addressed by this specification, but are left to the operators of the affected E2MD systems to implement using well-known methods including walled gardens, private networks, firewalls, fear, uncertainty, doubt, and general obfuscation. If users put data into E2MD or rely on the data in E2MD in such a way that, when compromised, any damage results, don't blame the IETF because we warned you right here. This specification contains no further analysis of the threat models posed by unauthorized access to the E2MD databases because frankly, if you're running E2MD, then you wouldn't understand the analysis and we chose not to bother writing it up. --- Does that about sum it up? -- Dean From lconroy@insensate.co.uk Thu Mar 11 17:23:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58D33A69CC for ; Thu, 11 Mar 2010 17:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f5QaZ3elMnH for ; Thu, 11 Mar 2010 17:23:12 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 6631D3A69B8 for ; Thu, 11 Mar 2010 17:22:28 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 646E7114420; Fri, 12 Mar 2010 01:22:33 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <01A49B90-4EE1-4D7F-A00A-6E0074D35D87@softarmor.com> Date: Fri, 12 Mar 2010 01:22:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <288EAA61-D166-4FCE-B91F-8ACAA1945949@insensate.co.uk> References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <01A49B90-4EE1-4D7F-A00A-6E0074D35D87@softarmor.com> To: Dean Willis , Richard Shockey X-Mailer: Apple Mail (2.1077) Cc: Robert Sparks , "E.164 To MetaData BOF discussion list" , Gonzalo Camarillo Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 01:23:20 -0000 Hi Dean, Richard, ADs, folks, Re. IETF does not do limited applicability protocols. Of course it doesn't (well, except for some SIP extensions :). However, I note this from section 2.4.3.1 of the current 3761bis-05: " Finally, any Enumservice type that starts with the facet "P-" is intended for use exclusively on private networks. As such, NAPTRs containing Enumservice types starting "P-" should not be seen on the global Internet. Even if an ENUM client recognizes and can engage in the Enumservice, it may be incapable of resolving the URI generated by the containing NAPTR. These Enumservices WILL NOT be registered. Such Enumservices MUST NOT be provisioned in any system that provides answers to DNS queries for NAPTR resource record sets from entities outside the private network context in which these Enumservices are intended for use. Unless an ENUM client is sure that it is connected to the private network for which these NAPTRs are provisioned and intended, it MUST discard any NAPTR with an Enumservice type that starts with the "P-" facet. " This was pulled in so that those people who insist on doing perverse things in the privacy of their own networks can tag the content so the vicar knows not to attempt to parse it. This privacy (or not) spat is different, and the DDDS application is going to be different, but I don't see why we can't leverage this kind of approach. We now return you to ... all the best, Lawrence On 11 Mar 2010, at 23:49, Dean Willis wrote: > On Mar 11, 2010, at 4:59 PM, Richard Shockey wrote: >> I don't buy the argument that it's this WG's task to define what is = and is >> not appropriate for the use of DNS. OR defining how data may or may = not be >> used. If there are restrictions on the use of SPID's and CNAM, ITAD's >> whatever that is a matter for National Regulatory Authorities period. = And as >> a reminder the use of the entire ENUM 164.arpa tree are governed by = NRA's >> for each CC are defined by the MOU between the ITU and the IAB. That >> policy..WG don't do policy. >=20 > No, we don't do policy. We define protocols for the Internet. >=20 >=20 >> A substantial number of these use cases will not be used in = situations where >> the data will never ever be visible to the single root DNS but only = in >> private closed instantiations. Nearly half of the ENUM trees out = there and >> proposed are in fact non visible. >=20 > The counter-argument: they ought to be using some sort of = industry-forum web-service API for looking up this data, not the DNS. Or = if they want to use a hacked-up DNS, they needn't waste our time with = it. We (IETF) DO NOT DO PROTOCOLS FOR PRIVATE NETWORKS. If we're going = to do a protocol, it is going to have general applicability, have a = thorough security analysis including a threat model and defenses against = identified threats where possible, and come with warning labels about = inappropriate usage or indefensible threats. >=20 >>=20 >> It should be apparent that the real use case here for non visible = meta data >> are those use / business cases that will attempt to substitute E2MD = data for >> TCAP look ups. I still have my NO TCAP cap BTW. The real problem is = that >> folks are going off and doing all sorts of crazy things and its time = to >> standardize the elements and process as we did with ENUM = registrations and >> go home. This was hopefully to a simple WG to wrap up loose elements = that >> the ENUM WG didn't want to tackle. >>=20 >> And I remind you that we already have defined how LNP data looks in = URI's >> and SIP and there seems to be no problem there. RFC 4694 >=20 > I didn't say that we couldn't handle LNP. I just said that some people = have raised questions about how LNP data interacts with E2MD, and that = as a consequence, we may have to be prepared to answer those questions. >=20 >>=20 >> I think my suggestion of text to punt this entire issue in the = charter made >> more sense. It should go back in. >>=20 >=20 > Fine, but from what the ADs told us on yesterday's call. don't count = on getting a working group formed as a result. We're going to have to = confront their concerns and come up with well-reasoned answers, not just = tell them to stop being silly. >=20 >> Distribution of E2MD Data >>=20 >> The distribution of E2MD data could be highly restricted or contain >> Publically Identifying Information (PII). The NAPTR records developed = by the >> WG could, in some cases, be inappropriate to be part of the RFC = 3761bis >> e164.arpa DNS tree or any portion of the general DNS. Distribution = of this >> NAPTR data would be either within a service provider's internal = network, or >> on a private basis between one or more parties using a variety of = well known >> security mechanisms to prohibit general public access. >>=20 >> If such PII data was distributed in an open DNS system, a national >> regulatory body may have jurisdiction. Such a body may choose to = restrict >> distribution of the data in such a way that it may not pass over that >> country's national borders. How Personally Identifying Information = is >> collected, distributed and subsequently regulated is out of the scope = of the >> WG. >>=20 >=20 > Perhaps the above could be recast in a way less likely to draw fire. >=20 > How about: >=20 > --- > Some of the metadata standardized by E2MD may be subject to policy = constraints within certain administrative jurisdictions, such as = national boundaries. When such policy constraints exist, it is the = responsibility of E2MD operators to comply with those constraints on the = handling of metadata. The E2MD working group will not attempt to = anticipate or mandate such policies. Rather, it is assumed that if = policy constraints exist for access to the metadata in an E2MD database, = then such policy will be enforced by the E2MD operator through = enforcement of access controls on the entire E2MD database affected by = the policy constraints. In particular, the E2MD working group will not = address AAA issues within the E2MD framework. > --- >=20 > Note hoe the above states that their might be E2MD databases that have = restricted access and are not part of teh general ENUM tree, but doesn't = rub their noses in it. Makes it potentially easier for them to pretend = they didn't notice. >=20 >=20 >=20 > Or possibly in the RFC we might say: >=20 > ---- > Security Considerations >=20 > The data in the E2MD database may or may not require privacy, = integrity protection, or authentication. Such protections, if required, = are not addressed by this specification, but are left to the operators = of the affected E2MD systems to implement using well-known methods = including walled gardens, private networks, firewalls, fear, = uncertainty, doubt, and general obfuscation. If users put data into E2MD = or rely on the data in E2MD in such a way that, when compromised, any = damage results, don't blame the IETF because we warned you right here. >=20 > This specification contains no further analysis of the threat models = posed by unauthorized access to the E2MD databases because frankly, if = you're running E2MD, then you wouldn't understand the analysis and we = chose not to bother writing it up. > --- >=20 > Does that about sum it up? >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Thu Mar 11 19:47:58 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F633A6A11 for ; Thu, 11 Mar 2010 19:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcO3iXD9nfQn for ; Thu, 11 Mar 2010 19:47:57 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 34CA03A6990 for ; Thu, 11 Mar 2010 19:47:57 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2C3lvTY024511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Mar 2010 21:47:58 -0600 Message-Id: From: Dean Willis To: Lawrence Conroy In-Reply-To: <288EAA61-D166-4FCE-B91F-8ACAA1945949@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 21:47:51 -0600 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <01A49B90-4EE1-4D7F-A00A-6E0074D35D87@softarmor.com> <288EAA61-D166-4FCE-B91F-8ACAA1945949@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: Robert Sparks , "E.164 To MetaData BOF discussion list" , Gonzalo Camarillo Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 03:47:58 -0000 On Mar 11, 2010, at 7:22 PM, Lawrence Conroy wrote: > Hi Dean, Richard, ADs, folks, > Re. IETF does not do limited applicability protocols. > Of course it doesn't (well, except for some SIP extensions :). I feel so guilty about those! > > However, I note this from section 2.4.3.1 of the current 3761bis-05: > > " Finally, any Enumservice type that starts with the facet "P-" is > intended for use exclusively on private networks. As such, NAPTRs > containing Enumservice types starting "P-" should not be seen on the > global Internet. Even if an ENUM client recognizes and can engage > in > the Enumservice, it may be incapable of resolving the URI generated > by the containing NAPTR. These Enumservices WILL NOT be registered. As we noted in SIP, the P-headers were one of our more egregious mistakes. The header "P-" might as well mean "permanent". > > Such Enumservices MUST NOT be provisioned in any system that > provides > answers to DNS queries for NAPTR resource record sets from entities > outside the private network context in which these Enumservices are > intended for use. Unless an ENUM client is sure that it is > connected > to the private network for which these NAPTRs are provisioned and > intended, it MUST discard any NAPTR with an Enumservice type that > starts with the "P-" facet. > " > > This was pulled in so that those people who insist on doing perverse > things in the privacy of their own networks can tag the content so the > vicar knows not to attempt to parse it. > > This privacy (or not) spat is different, and the DDDS application is > going to be different, but I don't see why we can't leverage this kind > of approach. Interesting. One approach would be to use conventional-looking NAPTR record with a new P-service to return an HTTP URI, which, on an authenticated GET, could return a relatively large XML document that contains all the perverse bits of metadata we might want. This approach kills multiple birds with one stone: 1) It keeps the thing in ENUM a URI. 2) It mitigates the "large DNS response problem:. 3) It allows an authentication check before revealing sensitive information, suitable for use on the big-I Internet. 4) It allows Daryl Malas' egress-route thingy to return requester- differentiated answers (ok, this only SORTOF works, because the URI might well be in the wrong domain for returning anything useful, necessitating an HTTP "transparent proxy" to make it work right). -- Dean From jay@nzrs.net.nz Thu Mar 11 20:06:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD883A6A62 for ; Thu, 11 Mar 2010 20:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujvWrhio0lco for ; Thu, 11 Mar 2010 20:06:30 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 37A193A6A57 for ; Thu, 11 Mar 2010 20:06:25 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 6D27F2DAAA3; Fri, 12 Mar 2010 17:06:30 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqUPDr5DKobY; Fri, 12 Mar 2010 17:06:30 +1300 (NZDT) Received: from [192.168.1.4] (121-73-187-20.dsl.telstraclear.net [121.73.187.20]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A6CE52DA271; Fri, 12 Mar 2010 17:06:29 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <00ca01cac16e$883aaaf0$98b000d0$@us> Date: Fri, 12 Mar 2010 17:06:28 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 04:06:31 -0000 On 12/03/2010, at 11:59 AM, Richard Shockey wrote: > I don't buy the argument that it's this WG's task to define what is = and is > not appropriate for the use of DNS. OR defining how data may or may = not be > used. If there are restrictions on the use of SPID's and CNAM, ITAD's > whatever that is a matter for National Regulatory Authorities period. = And as > a reminder the use of the entire ENUM 164.arpa tree are governed by = NRA's > for each CC are defined by the MOU between the ITU and the IAB. That > policy..WG don't do policy. I completely agree. We are discussing the hypothetical situation where = *some* authorities (I use the term loosely) *may* decide to make *some* = parts of this protocol not suitable for public DNS. Exactly the same = outside context issue applies to ENUM and probably many other protocols. That is not a specific privacy concern for this protocol. cheers Jay >=20 > A substantial number of these use cases will not be used in situations = where > the data will never ever be visible to the single root DNS but only in > private closed instantiations. Nearly half of the ENUM trees out there = and > proposed are in fact non visible.=20 >=20 > It should be apparent that the real use case here for non visible meta = data > are those use / business cases that will attempt to substitute E2MD = data for > TCAP look ups. I still have my NO TCAP cap BTW. The real problem is = that > folks are going off and doing all sorts of crazy things and its time = to > standardize the elements and process as we did with ENUM registrations = and > go home. This was hopefully to a simple WG to wrap up loose elements = that > the ENUM WG didn't want to tackle. >=20 > And I remind you that we already have defined how LNP data looks in = URI's > and SIP and there seems to be no problem there. RFC 4694 >=20 > I think my suggestion of text to punt this entire issue in the charter = made > more sense. It should go back in. >=20 > Distribution of E2MD Data >=20 > The distribution of E2MD data could be highly restricted or contain > Publically Identifying Information (PII). The NAPTR records developed = by the > WG could, in some cases, be inappropriate to be part of the RFC = 3761bis > e164.arpa DNS tree or any portion of the general DNS. Distribution of = this > NAPTR data would be either within a service provider's internal = network, or > on a private basis between one or more parties using a variety of well = known > security mechanisms to prohibit general public access. >=20 > If such PII data was distributed in an open DNS system, a national > regulatory body may have jurisdiction. Such a body may choose to = restrict > distribution of the data in such a way that it may not pass over that > country's national borders. How Personally Identifying Information is > collected, distributed and subsequently regulated is out of the scope = of the > WG. >=20 >=20 >=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, March 11, 2010 4:36 PM > To: Richard Shockey > Cc: 'E.164 To MetaData BOF discussion list'; 'Robert Sparks'; 'Gonzalo > Camarillo' > Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim >=20 >=20 > On Mar 11, 2010, at 3:08 PM, Richard Shockey wrote: >=20 >> Well #3 for 10 min given the time frame strikes me as "end world =20 >> hunger >> issues". You can make a case that alternatively that SIP signaling =20= >> itself >> might be another way to transport metadata this but we seem to be >> restraining ourselves to public and private DNS methodologies first =20= >> which is >> OK with me. >>=20 >=20 > I think we have two (or perhaps three) classes of metadata under =20 > discussion. >=20 > One class of metadata is the sort of globally-useful asker-independent = =20 > sort of stuff that the DNS thrives on. "Unused" is a perfect example =20= > of this sort of data. It's like putting the semantics of the =20 > "placeholder" web page created by most registrars directly into the =20= > DNS. It's presence indicates that the relevant phone number is in fact = =20 > serviced by the ITAD in question, but that it is not currently mapped =20= > to a phone number and calling it would be pointless. It's refresh/=20 > caching/propagation/TTL characteristics are also perfect for the DNS. >=20 > ITAD-identifier (Which ITAD owns this number?) might well be a member = =20 > of this class, although that;s subject to some debate: some people =20 > want to use this for a next-hop route identifier, which makes it NOT =20= > structurally suitable for the DNS. And some people seem to think that =20= > there might be national restrictions on divulging this information to =20= > the public or conflicts with LNP structural mandates, making the =20 > metadata NOT politically suited for the DNS. >=20 > CNAM is structurally perfectly suitable for the DNS. But the DNS =20 > mapping between phone number and calling party name is reversible, =20 > which has consequences. in classic telephony, caller-ID masking and =20= > "unlisted" numbers are two distinct services. If one metadatum is used = =20 > for both we could get into a problem where enabling caller-ID =20 > effectively makes the number publicly listed, and/or making a number =20= > publicly listed prevents placing a call with caller-ID suppressed. =20 > This is why we've (IETF) previously said caller-ID (both calling-name =20= > and calling-number) is better as a SIP level thing, which lets it be =20= > controlled by the SSP on a call-by-call basis. >=20 > Certainly one could obviate some of the these data access concerns by =20= > hiding the entire DNS from untrusted users, but that's it's own world =20= > of ugly hack. We see that it might be easier to charter a working =20 > group that would define multiple data elements, SOME of which might =20= > require hiding the DNS, than it would be to charter a working group =20= > that would by definition assume that ALL of its data elements being =20= > put into the DNS require hiding from the world. >=20 > So we have data elements that are 1) structurally and politically =20 > appropriate for the DNS, 2) structurally appropriate but politically =20= > questionable for the DNS, such that they might require hiding the DNS =20= > from untrusted accessors, and 3) Structurally inappropriate for the =20= > DNS because they require requester-specific response determination, =20= > immediate propagation, large responses, or other things that the DNS =20= > just doesn't do well. >=20 > The E2MD group has to provide a mechanism that allows for the =20 > determination of which category each proposed use case falls into, and = =20 > we have to decide how we're going to handle use-cases (like CNAM) that = =20 > aren't quite right for the DNS because of political, not structural, =20= > concerns. Requiring an applicability statement for the use case that =20= > restricts a DNS serving that metadata to private use might be a =20 > reasonable solution. If so, E2MD has to make this distinction on case-=20= > by-case basis. Other solutions, such as encrypting the data with a key = =20 > known to only a subset of the users of the DNS might also provide =20 > adequate solutions; such would also have to be addressed on a case-by-=20= > case basis. >=20 >=20 > -- > Dean >=20 >=20 >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Thu Mar 11 21:00:32 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2313A6A11 for ; Thu, 11 Mar 2010 21:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-1.447, BAYES_00=-2.599, TVD_PH_REC=2.996] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iASvvjRiLToB for ; Thu, 11 Mar 2010 21:00:32 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 044833A6A08 for ; Thu, 11 Mar 2010 21:00:28 -0800 (PST) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2C50TXq024886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 11 Mar 2010 23:00:31 -0600 Message-Id: <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> From: Dean Willis To: Jay Daley In-Reply-To: <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Mar 2010 23:00:24 -0600 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 05:00:33 -0000 On Mar 11, 2010, at 10:06 PM, Jay Daley wrote: > On 12/03/2010, at 11:59 AM, Richard Shockey wrote: > >> I don't buy the argument that it's this WG's task to define what is >> and is >> not appropriate for the use of DNS. OR defining how data may or may >> not be >> used. If there are restrictions on the use of SPID's and CNAM, ITAD's >> whatever that is a matter for National Regulatory Authorities >> period. And as >> a reminder the use of the entire ENUM 164.arpa tree are governed by >> NRA's >> for each CC are defined by the MOU between the ITU and the IAB. That >> policy..WG don't do policy. > > I completely agree. We are discussing the hypothetical situation > where *some* authorities (I use the term loosely) *may* decide to > make *some* parts of this protocol not suitable for public DNS. > Exactly the same outside context issue applies to ENUM and probably > many other protocols. > > That is not a specific privacy concern for this protocol. Okay, so if you have an "unlisted" phone number for which you paid extra money, do you really want your name and phone number listed together in a searchable fashion in the DNS? Is that a privacy concern? If so, then we DEFINITELY have privacy concerns around the CNAM use case. How about you're making a phone call and have turned on the"'withold caller ID" function, but the associated calling name is in the DNS and can be queried? Is that a privacy concern? If so, then we MAY have even more privacy concerns around the CNAM use case. Do you want to advertise exactly how your ISDN trunk line is provisioned and what services are associated with it? If so, then we MAY have some privacy concerns around the SPID use case (depending on how the SPID is formatted). Would you want your operator to add your billing address, authentication key, account number (which can correlate to other records and reveal "private" phone numbers through a cross match) or other personal information to the DNS? If not, then you MAY want to have somebody review proposed new metadata elements for compliance with privacy rules before the new elements are registered with IANA and therefore made into standards. Or you might want an applicability statement somewhere in the specification that says "If you put this information into a DNS, it MUST be a private DNS, by which we mean (insert your favorite list of what it means to be a private DNS here)." Do our other use cases have privacy concerns? They very well might. Judging by the apathy level of the people who have been proposing this stuff, it wouldn't surprise me a bit. So how is the E2MD working group going to discover these issues, and what sort of mechanism or guidance are we going to offer implementors in our protocol specification to help them deal with those issues? We have to have some sort of answer to those questions before the IESG and IAB will let us form an IETF working group -- and saying "Those are just implementation problems" IS NOT AN ACCEPTABLE ANSWER. If we don't have a better answer, we will NOT have a working group. If we have the assumption that all E2MD metadata is always held only in private DNS servers that can be queried only by carrier systems and that they'll never misconfigure something that leaks information, then we don't have any worries. Of course, we also don't have a big-I Internet protocol, so we don't need to be doing this in the IETF (and we won't be getting a working group). Go bother the ITU or some other standards body who cares about intranets and phone networks. But if you want to develop an Internet protocol, you have to realize that the work requires a detailed Security Considerations section, which includes a threat model, risk assessment, and detailed guidance on how to keep those threats from becoming real damages. It's something that's required in EVERY LAST RFC, although it's certainly better done in some than in others. -- Dean From jay@nzrs.net.nz Thu Mar 11 23:10:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E661E3A6965 for ; Thu, 11 Mar 2010 23:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.006 X-Spam-Level: * X-Spam-Status: No, score=1.006 tagged_above=-999 required=5 tests=[AWL=-3.005, BAYES_40=-0.185, J_CHICKENPOX_43=0.6, J_CHICKENPOX_83=0.6, TVD_PH_REC=2.996] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR2jCJ8861tZ for ; Thu, 11 Mar 2010 23:10:28 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 52B673A6BA8 for ; Thu, 11 Mar 2010 23:10:16 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 74AF52DAAA0; Fri, 12 Mar 2010 20:10:21 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMfzc3syCcko; Fri, 12 Mar 2010 20:10:21 +1300 (NZDT) Received: from [192.168.1.4] (121-73-187-20.dsl.telstraclear.net [121.73.187.20]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A5EE82DA271; Fri, 12 Mar 2010 20:10:20 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> Date: Fri, 12 Mar 2010 20:10:19 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 07:10:30 -0000 Apologies in advance if any of this comes across as rude, it is not my = intention. On 12/03/2010, at 6:00 PM, Dean Willis wrote: > Okay, so if you have an "unlisted" phone number for which you paid = extra money, do you really want your name and phone number listed = together in a searchable fashion in the DNS? Is that a privacy concern? = If so, then we DEFINITELY have privacy concerns around the CNAM use = case. There are three characteristics of your argument that erroneously = transposes layer 9 concerns into concerns about this protocol. They = are: 1. The potential for misuse of this or any other protocol 2. Nature of the legal entity whose data is published 3. Local laws on privacy, choice and how they are enforced and complied = with. The best way I can explain this is with an example. What if someone = puts my address into a TXT record under a public DNS tree? Well, they = already have: dig nzrs.tel txt dig nzrs.tel naptr The key things to note is that this was my choice under the business = model of .tel to publish my work address and email. I could have = chosen to publish my home address under jaydaley.tel, which again is a = choice made through the L9 system about which the protocol is ignorant. = Someone else could have published my personal details under = jaydaley.tel, which is a misuse of both the protocol and the L9 system = that the protocol is agnostic about. A foolish telco might register my = phone number under .tel and published my personal details, again a = misuse that violates local laws that the protocol is not responsible = for. CNAM is *exactly* the same - there will be appropriate L9 controls and = issues around its use that is nothing to do with this protocol. =20 =46rom this explanation comes two critical assertions: =20 - This same set of L9 concerns could be similarly transposed into almost = any protocol and so clearly they are not specific to a protocol. - No protocol can reasonably do anything about these concerns So in other words, this whole issue of privacy is a red herring. Well = intentioned I'm sure, but still a red herring. kind regards Jay > How about you're making a phone call and have turned on the"'withold = caller ID" function, but the associated calling name is in the DNS and = can be queried? Is that a privacy concern? If so, then we MAY have even = more privacy concerns around the CNAM use case. > Do you want to advertise exactly how your ISDN trunk line is = provisioned and what services are associated with it? If so, then we MAY = have some privacy concerns around the SPID use case (depending on how = the SPID is formatted). >=20 > Would you want your operator to add your billing address, = authentication key, account number (which can correlate to other records = and reveal "private" phone numbers through a cross match) or other = personal information to the DNS? If not, then you MAY want to have = somebody review proposed new metadata elements for compliance with = privacy rules before the new elements are registered with IANA and = therefore made into standards. Or you might want an applicability = statement somewhere in the specification that says "If you put this = information into a DNS, it MUST be a private DNS, by which we mean = (insert your favorite list of what it means to be a private DNS here)." >=20 > Do our other use cases have privacy concerns? They very well might. = Judging by the apathy level of the people who have been proposing this = stuff, it wouldn't surprise me a bit. So how is the E2MD working group = going to discover these issues, and what sort of mechanism or guidance = are we going to offer implementors in our protocol specification to help = them deal with those issues? We have to have some sort of answer to = those questions before the IESG and IAB will let us form an IETF working = group -- and saying "Those are just implementation problems" IS NOT AN = ACCEPTABLE ANSWER. If we don't have a better answer, we will NOT have a = working group. >=20 > If we have the assumption that all E2MD metadata is always held only = in private DNS servers that can be queried only by carrier systems and = that they'll never misconfigure something that leaks information, then = we don't have any worries. Of course, we also don't have a big-I = Internet protocol, so we don't need to be doing this in the IETF (and we = won't be getting a working group). Go bother the ITU or some other = standards body who cares about intranets and phone networks. But if you = want to develop an Internet protocol, you have to realize that the work = requires a detailed Security Considerations section, which includes a = threat model, risk assessment, and detailed guidance on how to keep = those threats from becoming real damages. It's something that's required = in EVERY LAST RFC, although it's certainly better done in some than in = others. >=20 >=20 > -- > Dean --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Fri Mar 12 06:34:56 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 429D63A6BE6 for ; Fri, 12 Mar 2010 06:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=-1.730, BAYES_40=-0.185, J_CHICKENPOX_43=0.6, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH0n6GcgPPPw for ; Fri, 12 Mar 2010 06:34:55 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 070843A6CEB for ; Fri, 12 Mar 2010 06:23:11 -0800 (PST) Received: from [192.168.2.118] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2CEN5rM029740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Mar 2010 08:23:08 -0600 Message-ID: <4B9A4E44.6090708@softarmor.com> Date: Fri, 12 Mar 2010 08:23:00 -0600 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jay Daley References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> In-Reply-To: <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 14:34:56 -0000 Jay Daley wrote: > Apologies in advance if any of this comes across as rude, it is not my intention. > > On 12/03/2010, at 6:00 PM, Dean Willis wrote: > >> Okay, so if you have an "unlisted" phone number for which you paid extra money, do you really want your name and phone number listed together in a searchable fashion in the DNS? Is that a privacy concern? If so, then we DEFINITELY have privacy concerns around the CNAM use case. >> > > There are three characteristics of your argument that erroneously transposes layer 9 concerns into concerns about this protocol. They are: > > 1. The potential for misuse of this or any other protocol > 2. Nature of the legal entity whose data is published > 3. Local laws on privacy, choice and how they are enforced and complied with. > > The best way I can explain this is with an example. What if someone puts my address into a TXT record under a public DNS tree? Well, they already have: > > dig nzrs.tel txt > dig nzrs.tel naptr > > The key things to note is that this was my choice under the business model of .tel to publish my work address and email. I could have chosen to publish my home address under jaydaley.tel, which again is a choice made through the L9 system about which the protocol is ignorant. Someone else could have published my personal details under jaydaley.tel, which is a misuse of both the protocol and the L9 system that the protocol is agnostic about. A foolish telco might register my phone number under .tel and published my personal details, again a misuse that violates local laws that the protocol is not responsible for. > > CNAM is *exactly* the same - there will be appropriate L9 controls and issues around its use that is nothing to do with this protocol. > > From this explanation comes two critical assertions: > > - This same set of L9 concerns could be similarly transposed into almost any protocol and so clearly they are not specific to a protocol. > - No protocol can reasonably do anything about these concerns > > So in other words, this whole issue of privacy is a red herring. Well intentioned I'm sure, but still a red herring. > Perhaps a red herring, but one we have to nail down before the WG will be authorized. You are aware that the entire use case for CNAM is to put your private phone number into the DNS, right? It's not "potentially abusable" like TXT records. It's "almost sure to be a problem unless the ISP does something different from standard practice for DNS." When this condition applies, the protocol has to give guidance, at the very least something like "If you use this extension to put restricted numbers into the DNS, you MUST make sure that the DNS tree you are putting them into is not publicly accessible." I'm not making this stuff up, and it isn't me we have to convince -- although I do believe that if we can't convince me, the probability of convincing the IESG and IAB is pretty low. -- Dean From jim@rfc1035.com Fri Mar 12 07:13:42 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31DF3A6B69 for ; Fri, 12 Mar 2010 07:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx3S2judEKen for ; Fri, 12 Mar 2010 07:13:42 -0800 (PST) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 456813A6BEA for ; Fri, 12 Mar 2010 06:55:40 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 05757154208B; Fri, 12 Mar 2010 14:55:44 +0000 (GMT) Message-Id: <61A11818-656B-4BD5-A192-0B321C8505B5@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4B9A4E44.6090708@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 12 Mar 2010 14:55:43 +0000 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> <4B9A4E44.6090708@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: [e2md] private data in the public DNS X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:13:42 -0000 On 12 Mar 2010, at 14:23, Dean Willis wrote: > You are aware that the entire use case for CNAM is to put your private > phone number into the DNS, right? It's not "potentially abusable" like > TXT records. It's "almost sure to be a problem unless the ISP does > something different from standard practice for DNS." When this > condition > applies, the protocol has to give guidance, at the very least > something > like "If you use this extension to put restricted numbers into the > DNS, > you MUST make sure that the DNS tree you are putting them into is not > publicly accessible." There of course has to be some language somewhere which can speak to this issue. It can't be ignored or brushed aside as a Layer9+ matter. However there is an alternative solution which some consider ugly. It is possible to encrypt NAPTR records. [Purists *hate* this.] Telnic uses this approach in .tel so the public DNS can hold contact data which can only be decoded by friends and family. It uses public-key crypto: the handshaking and provisioning is left as an exercise for the reader. Something that's still on my To Do list is to find out what happened to the IDs that were published about this scheme and get them out as Informational RFCs. From richard@shockey.us Fri Mar 12 08:30:26 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DAF3A685E for ; Fri, 12 Mar 2010 08:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_00=-2.599, TVD_PH_REC=2.996] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFKVd1eroPQ3 for ; Fri, 12 Mar 2010 08:30:24 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id E73D63A6C79 for ; Fri, 12 Mar 2010 08:18:25 -0800 (PST) Received: (qmail 13411 invoked by uid 0); 12 Mar 2010 16:18:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 12 Mar 2010 16:18:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=M34O2MkA2CPGVLmQtSs8npB3YO5Ntj6hqXd5wTAmdHf6460nbyxhOAxjNev6tNG/vH1GQt4zzPznZwqeuUFzNeRioyFGmRM/TAXlGL08bSPv06Kk2Y7Ql06ADTYOqeS3; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nq7ZH-0005QQ-LE; Fri, 12 Mar 2010 09:18:31 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Jay Daley'" References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> In-Reply-To: <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> Date: Fri, 12 Mar 2010 11:18:29 -0500 Message-ID: <001201cac1ff$a768b980$f63a2c80$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrBoPaePPJ/H+0lRZin0MpO4KRPvgAXZ3pg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 16:30:27 -0000 Dean .. This is totally absurd now and it needs to stop. You are essentially arguing that ENUM should not have been formed at all or that E2MD has no business in the IETF since it MAY relate to internal carrier interoperability between the PSTN and SIP. The original ENUM charter always recognized that the protocol would be used for this stuff no one had a issue with this until you started this thread. " 2. The working group will examine and document the use of RFC 3761 to facilitate network interconnection for services using E.164 addressing. The working group will coordinate its activities with other IETF Working groups, existing or to be chartered, that are investigating elements of peering and or interconnection for VoIP or other services that typically use E.164 addressing. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data." -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, March 12, 2010 12:00 AM To: Jay Daley Cc: Richard Shockey; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim On Mar 11, 2010, at 10:06 PM, Jay Daley wrote: > On 12/03/2010, at 11:59 AM, Richard Shockey wrote: > >> I don't buy the argument that it's this WG's task to define what is >> and is >> not appropriate for the use of DNS. OR defining how data may or may >> not be >> used. If there are restrictions on the use of SPID's and CNAM, ITAD's >> whatever that is a matter for National Regulatory Authorities >> period. And as >> a reminder the use of the entire ENUM 164.arpa tree are governed by >> NRA's >> for each CC are defined by the MOU between the ITU and the IAB. That >> policy..WG don't do policy. > > I completely agree. We are discussing the hypothetical situation > where *some* authorities (I use the term loosely) *may* decide to > make *some* parts of this protocol not suitable for public DNS. > Exactly the same outside context issue applies to ENUM and probably > many other protocols. > > That is not a specific privacy concern for this protocol. Okay, so if you have an "unlisted" phone number for which you paid extra money, do you really want your name and phone number listed together in a searchable fashion in the DNS? Is that a privacy concern? If so, then we DEFINITELY have privacy concerns around the CNAM use case. How about you're making a phone call and have turned on the"'withold caller ID" function, but the associated calling name is in the DNS and can be queried? Is that a privacy concern? If so, then we MAY have even more privacy concerns around the CNAM use case. Do you want to advertise exactly how your ISDN trunk line is provisioned and what services are associated with it? If so, then we MAY have some privacy concerns around the SPID use case (depending on how the SPID is formatted). Would you want your operator to add your billing address, authentication key, account number (which can correlate to other records and reveal "private" phone numbers through a cross match) or other personal information to the DNS? If not, then you MAY want to have somebody review proposed new metadata elements for compliance with privacy rules before the new elements are registered with IANA and therefore made into standards. Or you might want an applicability statement somewhere in the specification that says "If you put this information into a DNS, it MUST be a private DNS, by which we mean (insert your favorite list of what it means to be a private DNS here)." Do our other use cases have privacy concerns? They very well might. Judging by the apathy level of the people who have been proposing this stuff, it wouldn't surprise me a bit. So how is the E2MD working group going to discover these issues, and what sort of mechanism or guidance are we going to offer implementors in our protocol specification to help them deal with those issues? We have to have some sort of answer to those questions before the IESG and IAB will let us form an IETF working group -- and saying "Those are just implementation problems" IS NOT AN ACCEPTABLE ANSWER. If we don't have a better answer, we will NOT have a working group. If we have the assumption that all E2MD metadata is always held only in private DNS servers that can be queried only by carrier systems and that they'll never misconfigure something that leaks information, then we don't have any worries. Of course, we also don't have a big-I Internet protocol, so we don't need to be doing this in the IETF (and we won't be getting a working group). Go bother the ITU or some other standards body who cares about intranets and phone networks. But if you want to develop an Internet protocol, you have to realize that the work requires a detailed Security Considerations section, which includes a threat model, risk assessment, and detailed guidance on how to keep those threats from becoming real damages. It's something that's required in EVERY LAST RFC, although it's certainly better done in some than in others. -- Dean From jay@nzrs.net.nz Fri Mar 12 11:16:26 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E14C3A689A for ; Fri, 12 Mar 2010 11:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=1.803, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zVOZnnMLjNd for ; Fri, 12 Mar 2010 11:16:25 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 300AC3A676A for ; Fri, 12 Mar 2010 11:16:25 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 77E4C2DAF08; Sat, 13 Mar 2010 08:16:30 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwKupU83ugU7; Sat, 13 Mar 2010 08:16:30 +1300 (NZDT) Received: from [192.168.1.4] (121-73-187-20.dsl.telstraclear.net [121.73.187.20]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id EECCA2DA511; Sat, 13 Mar 2010 08:16:29 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <4B9A4E44.6090708@softarmor.com> Date: Sat, 13 Mar 2010 08:16:28 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <56CDDA92-B894-47C4-9F85-9F257C20B48E@nzrs.net.nz> References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> <4B9A4E44.6090708@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 19:16:26 -0000 On 13/03/2010, at 3:23 AM, Dean Willis wrote: > Perhaps a red herring, but one we have to nail down before the WG will > be authorized. >=20 > You are aware that the entire use case for CNAM is to put your private > phone number into the DNS, right? Eh? ENUM by very definition means putting my private phone number into = the DNS. Are you seriously suggesting the privacy issue is the very = existence of a telephone number as a domain name or did you actually = mean the data associated with it? cheers Jay > It's not "potentially abusable" like > TXT records. It's "almost sure to be a problem unless the ISP does > something different from standard practice for DNS." When this = condition > applies, the protocol has to give guidance, at the very least = something > like "If you use this extension to put restricted numbers into the = DNS, > you MUST make sure that the DNS tree you are putting them into is not > publicly accessible." >=20 > I'm not making this stuff up, and it isn't me we have to convince -- > although I do believe that if we can't convince me, the probability of > convincing the IESG and IAB is pretty low. >=20 >=20 > -- > Dean --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From richard@shockey.us Sun Mar 14 17:57:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5A33A684B for ; Sun, 14 Mar 2010 17:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVL7MnOvuUXa for ; Sun, 14 Mar 2010 17:57:03 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id C0DB53A68C5 for ; Sun, 14 Mar 2010 17:57:03 -0700 (PDT) Received: (qmail 25770 invoked by uid 0); 15 Mar 2010 00:57:10 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 15 Mar 2010 00:57:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ianpwQ3WirIfLPRYpSN9BAW0gfjiQfXzdgOa/zfNHKnu3ZvPbKXiVpoZ2shnIpKl/qunWjztZTbYlcvR5y8Wl0r9tlQlxxGE6pF4yfq9P/dgxbv3OxcDJ1tHzNh21DkL; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NqycI-0006ir-0o; Sun, 14 Mar 2010 18:57:10 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <01A49B90-4EE1-4D7F-A00A-6E0074D35D87@softarmor.com> In-Reply-To: Date: Sun, 14 Mar 2010 20:57:07 -0400 Message-ID: <001301cac3da$6fed9b10$4fc8d130$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrDwzk/9ath2NehSCm0mGNnSG9C+wAFxdXA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 00:57:04 -0000 +1 a good working start. I captures the essence. -----Original Message----- From: Bernie Hoeneisen [mailto:bernie@hoeneisen.ch] Sent: Sunday, March 14, 2010 6:11 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim On Thu, 11 Mar 2010, Dean Willis wrote: > How about: > > --- > Some of the metadata standardized by E2MD may be subject to policy > constraints within certain administrative jurisdictions, such as national > boundaries. When such policy constraints exist, it is the responsibility of > E2MD operators to comply with those constraints on the handling of metadata. > The E2MD working group will not attempt to anticipate or mandate such > policies. Rather, it is assumed that if policy constraints exist for access > to the metadata in an E2MD database, then such policy will be enforced by the > E2MD operator through enforcement of access controls on the entire E2MD > database affected by the policy constraints. In particular, the E2MD working > group will not address AAA issues within the E2MD framework. > --- @Rich: Does this work with you? cheers, Bernie From dean.willis@softarmor.com Sun Mar 14 19:37:07 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CEA3A6833 for ; Sun, 14 Mar 2010 19:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.192 X-Spam-Level: X-Spam-Status: No, score=-1.192 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWZm4x3SmMGa for ; Sun, 14 Mar 2010 19:37:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 62F8D3A67B5 for ; Sun, 14 Mar 2010 19:37:06 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2F2bAl4019270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 14 Mar 2010 21:37:12 -0500 Message-Id: <52E0CBCE-650D-4936-B193-31E40548BA2B@softarmor.com> From: Dean Willis To: Jay Daley In-Reply-To: <56CDDA92-B894-47C4-9F85-9F257C20B48E@nzrs.net.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 14 Mar 2010 21:37:05 -0500 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> <4B9A4E44.6090708@softarmor.com> <56CDDA92-B894-47C4-9F85-9F257C20B48E@nzrs.net.nz> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 02:37:07 -0000 On Mar 12, 2010, at 1:16 PM, Jay Daley wrote: > > On 13/03/2010, at 3:23 AM, Dean Willis wrote: > >> Perhaps a red herring, but one we have to nail down before the WG >> will >> be authorized. >> >> You are aware that the entire use case for CNAM is to put your >> private >> phone number into the DNS, right? > > Eh? ENUM by very definition means putting my private phone number > into the DNS. Are you seriously suggesting the privacy issue is the > very existence of a telephone number as a domain name or did you > actually mean the data associated with it? Let me restate that: Put your private phone number LINKED TO YOUR NAME, into the DNS. So if I want Jay Daley's private number, I can just grep the zone file. -- Dean From lconroy@insensate.co.uk Mon Mar 15 03:01:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCA13A68B4 for ; Mon, 15 Mar 2010 03:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c99hgjcZkQV3 for ; Mon, 15 Mar 2010 03:01:33 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 244103A6863 for ; Mon, 15 Mar 2010 03:01:32 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 60E641163AE; Mon, 15 Mar 2010 10:01:38 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <52E0CBCE-650D-4936-B193-31E40548BA2B@softarmor.com> Date: Mon, 15 Mar 2010 10:01:39 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1A50498F-45AE-493A-A963-BB614A51103F@insensate.co.uk> References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> <4B9A4E44.6090708@softarmor.com> <56CDDA92-B894-47C4-9F85-9F257C20B48E@nzrs.net.nz> <52E0CBCE-650D-4936-B193-31E40548BA2B@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 10:01:35 -0000 Hi Dean, difficult to know where to start, but... ?!?grep the zone file?!?=20 - Jay Daley has published this information, through his choice, in a = *non-ENUM* domain. Otherwise how the heck are you going to find out which number is = associated with Jay Daley? ENUM is a "forward" directory FROM number TO data/metadata, not the = other way around. The reverse directory you're looking for would require you to collect = the data for every ENUM domain in the World. - to do that you will need to have the zone files for every domain in = the world. There could be billions of these files. Are you going to AXFR them all? No-one has an obligation to accept zone file access requests for ENUM = domains. Certainly, it is unlikely that everyone has any such obligation, and = would respond. - Go bribe his carrier; it's about the only sane way to find out that = information. all the best, Lawrence On 15 Mar 2010, at 02:37, Dean Willis wrote: >=20 > On Mar 12, 2010, at 1:16 PM, Jay Daley wrote: >=20 >>=20 >> On 13/03/2010, at 3:23 AM, Dean Willis wrote: >>=20 >>> Perhaps a red herring, but one we have to nail down before the WG = will >>> be authorized. >>>=20 >>> You are aware that the entire use case for CNAM is to put your = private >>> phone number into the DNS, right? >>=20 >> Eh? ENUM by very definition means putting my private phone number = into the DNS. Are you seriously suggesting the privacy issue is the = very existence of a telephone number as a domain name or did you = actually mean the data associated with it? >=20 > Let me restate that: Put your private phone number LINKED TO YOUR = NAME, into the DNS. >=20 > So if I want Jay Daley's private number, I can just grep the zone = file. >=20 > -- > Dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From Ray.Bellis@nominet.org.uk Mon Mar 15 06:31:16 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777403A67D3 for ; Mon, 15 Mar 2010 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v790m420xwxF for ; Mon, 15 Mar 2010 06:31:15 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 0FDB23A67A5 for ; Mon, 15 Mar 2010 06:31:14 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=My4SNH1TaLd1r3RqdVjfS254Xh3Pai8wW+U4L6J0KO2gI32rSfNeaeqN 7GCp+t7qVakstnDULECoexEswkkf5e/uw1hsMi0OkjTv6UPhUDQH9/vOH KQU3xNBRVWFcwhw; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1268659883; x=1300195883; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Proposed=20agenda=20change=20for=20E2md=20at=20Anahei m|Date:=20Mon,=2015=20Mar=202010=2013:31:20=20+0000 |Message-ID:=20|To:=20"Richard=20Shockey "=20|Cc:=20"'Bernie=20Hoeneisen'"=20< bernie@hoeneisen.ch>,=0D=0A=09"'E.164=20To=20MetaData=20B OF=20discussion=20list'"=20|MIME-Version: =201.0|In-Reply-To:=20<001301cac3da$6fed9b10$4fc8d130$@us >|References:=20<22C967D5-A76D-459E-B422-1489B274D811@sof tarmor.com>=09<00aa01cac15e$f11dd070$d3597150$@us>=0D=0A =09 =09<00ca01cac16e$883aaaf0$98b000d0$@us>=0D=0A=09<01A49B90 -4EE1-4D7F-A00A-6E0074D35D87@softarmor.com>=09=20<001 301cac3da$6fed9b10$4fc8d130$@us>; bh=kDCDM2jW5+FKlENHo2VBoJ8sJQ46aCOH7jpchVDvtlE=; b=fTPIDCOFeHPSqi+8Pt+qr/fOJVOzYGw6a1ObwOzSw0oWHMYfyBZh17YJ 3gpcUDlUYZW6UB0sGTjj2p5QrjjFKcVc3h+7xOWSVRA4M0oViGxqz9vK7 vPKS17MEBGBoR+I; X-IronPort-AV: E=Sophos;i="4.49,643,1262563200"; d="scan'208";a="17027208" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 15 Mar 2010 13:31:21 +0000 In-Reply-To: <001301cac3da$6fed9b10$4fc8d130$@us> References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <01A49B90-4EE1-4D7F-A00A-6E0074D35D87@softarmor.com> <001301cac3da$6fed9b10$4fc8d130$@us> To: "Richard Shockey" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 15 Mar 2010 13:31:20 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 15/03/2010 01:31:21 PM, Serialize complete at 15/03/2010 01:31:21 PM Content-Type: multipart/alternative; boundary="=_alternative 004A477A802576E7_=" Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:31:16 -0000 This is a multipart message in MIME format. --=_alternative 004A477A802576E7_= Content-Type: text/plain; charset="US-ASCII" > +1 a good working start. I captures the essence. I'm happy with the first sentence. It draws attention to the possibility of regulatory and/or privacy issues, without mandating anything. However, I'm not happy with: "it is assumed that if policy constraints exist for access to the metadata in an E2MD database, then such policy will be enforced by the E2MD operator through enforcement of access controls on the entire E2MD database affected by the policy constraints." IMHO, "access controls on the entire E2MD database" is too restrictive, and unnecessarily constrains the solution space (both by method - "access controls", and scope - "entire database"). kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 004A477A802576E7_= Content-Type: text/html; charset="US-ASCII"
> +1 a good working start. I captures the essence.
I'm happy with the first sentence.   It draws attention to the possibility of regulatory and/or privacy issues, without mandating anything.

However, I'm not happy with: "it is assumed that if policy constraints exist for access to the metadata in an E2MD database, then such policy will be enforced by the E2MD operator through enforcement of access controls on the entire E2MD database affected by the policy constraints."

IMHO, "access controls on the entire E2MD database" is too restrictive, and unnecessarily constrains the solution space (both by method - "access controls", and scope - "entire database").

kind regards,

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
 --=_alternative 004A477A802576E7_=-- From dean.willis@softarmor.com Mon Mar 15 13:52:02 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9C73A676A for ; Mon, 15 Mar 2010 13:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHDIVzISBeGi for ; Mon, 15 Mar 2010 13:52:01 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8EA1F3A6813 for ; Mon, 15 Mar 2010 13:52:00 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2FKptPJ028289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Mar 2010 15:51:57 -0500 Message-Id: <3D9E3DDE-71E0-49F8-8D1F-26664809C1DF@softarmor.com> From: Dean Willis To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1-468817821 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 15 Mar 2010 15:51:50 -0500 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <01A49B90-4EE1-4D7F-A00A-6E0074D35D87@softarmor.com> <001301cac3da$6fed9b10$4fc8d130$@us> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 20:52:02 -0000 --Apple-Mail-1-468817821 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 15, 2010, at 8:31 AM, Ray.Bellis@nominet.org.uk wrote: > > > +1 a good working start. I captures the essence. > > I'm happy with the first sentence. It draws attention to the > possibility of regulatory and/or privacy issues, without mandating > anything. > > However, I'm not happy with: "it is assumed that if policy > constraints exist for access to the metadata in an E2MD database, > then such policy will be enforced by the E2MD operator through > enforcement of access controls on the entire E2MD database affected > by the policy constraints." > > IMHO, "access controls on the entire E2MD database" is too > restrictive, and unnecessarily constrains the solution space (both > by method - "access controls", and scope - "entire database"). > So, you want it to say that the E2MD operator will just have to deal with the problem somehow, but that the E2MD working group will give no guidance on how they might deal with it? Or do you want something more like adding "Other mechanisms may be applicable, but are outside the scope of the E2MD working group" to the text proposed above? -- Dean --Apple-Mail-1-468817821 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 15, 2010, = at 8:31 AM, Ray.Bellis@nominet.org.uk = wrote:


> +1 a good working start. I = captures the essence.
I'm = happy with the first sentence.   It draws attention to the = possibility of regulatory and/or privacy issues, without mandating = anything.

However, I'm not = happy with: "it is assumed that if policy constraints exist for access = to the metadata in an E2MD database, then such policy will be enforced = by the E2MD operator through enforcement of access controls on the = entire E2MD database affected by the policy constraints." =

IMHO, "access controls on the entire E2MD = database" is too restrictive, and unnecessarily constrains the solution = space (both by method - "access controls", and scope - "entire = database").


So, you = want it to say that the E2MD operator will just have to deal with the = problem somehow, but that the E2MD working group will give no guidance = on how they might deal with it?

Or do you want = something more like adding "Other mechanisms may be applicable, but are = outside the scope of the E2MD working group" to the text proposed = above?

--
Dean

= --Apple-Mail-1-468817821-- From dean.willis@softarmor.com Mon Mar 15 14:05:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA9F3A6BE2 for ; Mon, 15 Mar 2010 14:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.174 X-Spam-Level: X-Spam-Status: No, score=-1.174 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+jscCNboQBk for ; Mon, 15 Mar 2010 14:05:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B5FA73A6BD8 for ; Mon, 15 Mar 2010 14:05:18 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2FL5Ncm028382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Mar 2010 16:05:25 -0500 Message-Id: <6B7089B0-0956-4507-ABC1-B25CEBDFB0BB@softarmor.com> From: Dean Willis To: Lawrence Conroy In-Reply-To: <1A50498F-45AE-493A-A963-BB614A51103F@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 15 Mar 2010 16:05:17 -0500 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> <4B9A4E44.6090708@softarmor.com> <56CDDA92-B894-47C4-9F85-9F257C20B48E@nzrs.net.nz> <52E0CBCE-650D-4936-B193-31E40548BA2B@softarmor.com> <1A50498F-45AE-493A-A963-BB614A51103F@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 21:05:20 -0000 On Mar 15, 2010, at 5:01 AM, Lawrence Conroy wrote: > Hi Dean, > difficult to know where to start, but... ?!?grep the zone file?!? Ok, that's an oversimplification. But E.164 numbers are predictable. If I can guess what country you're in (even better if I can guess the area code and exchange), then I can just do lookups on each phone number until I find the one with your name attached to it. For example, if you know I have an unlisted phone number at Terlingua Ranch (which is served by exchange +1 972 519 xxxx) you only need an average of 5,000 lookups to figure out which phone number is my unlisted number (and in practice, less than that. since the number is in the lower 5,000). Sure, you could make 5,000 phone calls and listen for me, but it's a lot easier to write a Perl script to make the DNS calls. This is one of the reasons many companies are loathe to put PTR records out there -- they can be reverse-discovered through prediction, allowing a competitor or hacker to more easily map your IT infrastructure. But such records aren't contractually -protected confidential information, like subscriber identity might be. More guidance on the risks and how to cover them may well be needed. Some of our people seem to be saying "There are no risks, and if there were, there is no guidance needed because this stuff is all on intranets anyhow." This isn't going to get us a working group. > > - Jay Daley has published this information, through his choice, in a > *non-ENUM* domain. > Otherwise how the heck are you going to find out which number is > associated with Jay Daley? > ENUM is a "forward" directory FROM number TO data/metadata, not the > other way around. > The reverse directory you're looking for would require you to > collect the data for every > ENUM domain in the World. Jay's free to publish HIS information wherever he wants. AT&T is NOT free to publish my information in violation of my "unpublished" phone number service for which I pay extra. And if they publish it in an easily-hackable way, they're going to face some considerable court damages by the time my lawyer gets through with them. Now, I suspect they're smart enough to not screw up (after all, look at how good my UMTS 850 coverage is), but it is the convention of the IETF that our protocols have a reasonable "Security Considerations" section built right in to the RFC. -- Dean From jay@nzrs.net.nz Mon Mar 15 14:29:39 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09AE3A6818 for ; Mon, 15 Mar 2010 14:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuXz8xpBRLur for ; Mon, 15 Mar 2010 14:29:38 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A18FF3A680C for ; Mon, 15 Mar 2010 14:29:38 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id AA3242DA372; Tue, 16 Mar 2010 10:29:45 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-GV47+EUm9q; Tue, 16 Mar 2010 10:29:45 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 5BDE52DA152; Tue, 16 Mar 2010 10:29:45 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <52E0CBCE-650D-4936-B193-31E40548BA2B@softarmor.com> Date: Tue, 16 Mar 2010 10:29:44 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <1809E90E-505F-4802-A288-650BCAF2BD34@nzrs.net.nz> References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> <4B9A4E44.6090708@softarmor.com> <56CDDA92-B894-47C4-9F85-9F257C20B48E@nzrs.net.nz> <52E0CBCE-650D-4936-B193-31E40548BA2B@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 21:29:40 -0000 On 15/03/2010, at 3:37 PM, Dean Willis wrote: > Let me restate that: Put your private phone number LINKED TO YOUR = NAME, into the DNS. You are misrepresenting CNAM here. CNAM only enables the *subscriber = name* to be put into the DNS, which is only a private name if the = subscriber is a) a natural person an b) in a jurisdiction where that is = considered a private data combination. Even if both tests are met, the = regulation of that jurisdiction would include rules for publishing that = data combination with such barriers as opt-in by the subscriber. Even if we go to an extreme and assume all private names are not opted = in then what remains is a substantive and important use case of = non-private subscriber names, such as those for companies, organisations = and other subscribers that are not natural persons. In my jurisdiction, = as with many I suspect, there are rules that *require* companies to = accurately identify themselves. cheers Jay >=20 > So if I want Jay Daley's private number, I can just grep the zone = file. >=20 > -- > Dean --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Mon Mar 15 15:21:37 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0A63A69AA for ; Mon, 15 Mar 2010 15:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp2vHRIhlt9K for ; Mon, 15 Mar 2010 15:21:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7782F3A69E7 for ; Mon, 15 Mar 2010 15:21:02 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2FML7fl029002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Mar 2010 17:21:08 -0500 Message-Id: <16EA1760-0F9E-4EDC-B26A-FF82E3C11833@softarmor.com> From: Dean Willis To: Jay Daley In-Reply-To: <1809E90E-505F-4802-A288-650BCAF2BD34@nzrs.net.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 15 Mar 2010 17:21:01 -0500 References: <22C967D5-A76D-459E-B422-1489B274D811@softarmor.com> <00aa01cac15e$f11dd070$d3597150$@us> <00ca01cac16e$883aaaf0$98b000d0$@us> <6BC117E0-A451-487B-844C-06FFA07D4A9F@nzrs.net.nz> <28EAE779-9FA7-4417-920C-A7CBA1626E22@softarmor.com> <95FF6AC1-F910-4812-BB36-D575273D9A31@nzrs.net.nz> <4B9A4E44.6090708@softarmor.com> <56CDDA92-B894-47C4-9F85-9F257C20B48E@nzrs.net.nz> <52E0CBCE-650D-4936-B193-31E40548BA2B@softarmor.com> <1809E90E-505F-4802-A288-650BCAF2BD34@nzrs.net.nz> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed agenda change for E2md at Anaheim X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 22:21:37 -0000 On Mar 15, 2010, at 4:29 PM, Jay Daley wrote: > On 15/03/2010, at 3:37 PM, Dean Willis wrote: > >> Let me restate that: Put your private phone number LINKED TO YOUR >> NAME, into the DNS. > > You are misrepresenting CNAM here. CNAM only enables the > *subscriber name* to be put into the DNS, which is only a private > name if the subscriber is a) a natural person an b) in a > jurisdiction where that is considered a private data combination. > Even if both tests are met, the regulation of that jurisdiction > would include rules for publishing that data combination with such > barriers as opt-in by the subscriber. > In the PSTN, even "unlisted" telephone numbers may allow calling-name display. In my jurisdiction, I believe calling name and calling number are both presented if the unlisted subscriber has not selected an option for blocking calling-number. > Even if we go to an extreme and assume all private names are not > opted in then what remains is a substantive and important use case > of non-private subscriber names, such as those for companies, > organisations and other subscribers that are not natural persons. > In my jurisdiction, as with many I suspect, there are rules that > *require* companies to accurately identify themselves. > I never said the use case was invalid. I said, and am continuing to say, that some use cases require guidance above and beyond "don't be stupid" in our protocol specifications. Providing such guidance means that the work needs a detailed security analysis with a threat model, and needs defenses ranging from "must implement" specifications through "best practice" guidelines to be documented and published in conjunction with the specification. The proposed working group MUST embrace doing appropriate security analysis and MUST commit to providing appropriate defenses as part of its deliverable work scope. It is unacceptable to charter a working group that refuses to acknowledge these responsibilities and commit to meeting them. We don't have to have an answer as to what specific technical solutions nor operational guidelines we will produce; we can't know those in advance of doing the work. However, we also cannot declare in our charter that such concerns are "out of scope". They are not out of scope, and MUST be explicitly part of the scope of the working group, or the working group is not going to be chartered within the IETF. I don't care if you think I'm being paranoid. The Security Area directors are professionally far more paranoid than I could ever manage, truly "These are paid experts, kids, do not attempt to be this paranoid yourself" sorts of people. THEY WILL BE PLACING REQUIREMENTS ON OUR WORK. If we are not prepared to step up and work through those requirements, then we might as well just stay home, because out specifications will NOT be published as standards-track RFCs if we don't make these people happy. That's the process. I did not invent this process. But I am here to help make sure that we come up with a work plan that is consistent with the process. -- Dean From bernie@ietf.hoeneisen.ch Mon Mar 15 16:16:15 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F8A3A66B4 for ; Mon, 15 Mar 2010 16:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi39riCuW6pK for ; Mon, 15 Mar 2010 16:16:13 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 682E23A6881 for ; Mon, 15 Mar 2010 16:16:06 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NrJW7-0005oJ-TB for e2md@ietf.org; Tue, 16 Mar 2010 00:16:11 +0100 Date: Tue, 16 Mar 2010 00:16:11 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 23:16:15 -0000 Hi, Thanks for all the feedback and discussions on- and off-list! Based on these discussions, Dean and myself made an update to the proposed charter and we would like to know your opinion about it. The substantial changes were in section "Scope of Working Group". We also added there paragraphe about security considerations, which might trigger some further discussions... The whole currently proposed charter can be fetched from http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt For your convenience you can find a copy-paste of the section "Description of Working Group" below. cheers, Bernie ---- Description of Working Group ---------------------------- Abstract -------- E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI Mapping) in either public or private instantiations to provide additional information about E.164 (telephone) numbers. In some use cases, information (metadata) about E.164 numbers cannot be expressed as a URI (Uniform Resource Identifier) as required by the ENUM DDDS (Dynamic Delegation Discovery System) described in RFC 3761bis. Therefore, E2MD will define a different mechanism for expressing metadata. The initial expectation is that this mechanism will be a new DDDS for metadata, based on RFC 3761bis, that returns standardized metadata instead of URIs. Background ---------- ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically used to look up the services associated with an E.164 number, each of which is represented by a URI. However, there is more information about a telephone number that may be useful when establishing a communications session using that phone number. For example, this information might be used to decide or what sort of communications session to establish using that phone number, or whether to accept a communications session offered by someone using that phone number. We refer to this information as "metadata". Several example use cases for metadata have been documented as Internet drafts, and will be considered during the work of E2MD for inclusion in the group's work product. Typically, this metadata information is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis innapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. Previous Enumservice proposals tried to resolve these issues by using the 'data' URI scheme or inventing completely new URI schemes, however it is believed that such proposals do not satisfy the general use case for metadata, and a new approach is required. Problem Statement ----------------- Typically, the phone-number asssociated metadata is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis inapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. The initially favored approach is to define an additional ENUM service (E2M) that maps phone-numbers to metadata that will operate in parallel to the current ENUM service (E2U), which maps phone numbers to URIs. Current proposals for metadata to be addressed by E2MD include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, 'send-n' to describe the structure of an ENUM tree, 'spid' to describe a service provider identifier, 'itad' to describe an internet telephony administrative domain, etc. Scope of Working Group ---------------------- The E2MD Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application that can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will provide the means for data related to E.164 numbers that do not fit into the classic concept of ENUM (E2U). The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification. Along with the E2MD DDDS application a new IANA registry will be specified for registration of E2MD services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similar to those specified for Enumservice (E2U) registrations. Limitations of the DNS are to be considered while defining the protocol; in particular packet size restrictions of deployed DNS transport. E2MD shall not be specified as a general purpose lookup nor as bulk transfer protocol, but rather focus on clear use cases related to E.164 numbers. The E2MD working group will, for each specification published, follow IETF practices and include a thorough Security Considerations section. These Security Considerations sections will include detailed threat models. Further, the specifications will include "MUST Implement" defensive mechanisms, operational guidelines, and/or applicability statements relative to particular metadata as appropriate. Some of the metadata standardized by E2MD may be subject to policy constraints within certain administrative jurisdictions, such as national boundaries. When such policy constraints exist, it is the responsibility of E2MD operators to comply with those constraints on the handling of metadata. The E2MD working group will not attempt to anticipate or mandate such policies. Rather, it is assumed that if policy constraints exist for access to the metadata in an E2MD database, then such policy will be enforced by the E2MD operator. In particular, the E2MD working group will not address AAA issues within the E2MD framework. A major product of the E2MD working group is to define a process and review model for the registration of new E2MD services with IANA. Until this process is in place, the E2MD working group will act as the central point for discussion and review of proposals for new E2MD services. From bernie@ietf.hoeneisen.ch Mon Mar 15 16:24:35 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827883A68A3 for ; Mon, 15 Mar 2010 16:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsM64GUhnngF for ; Mon, 15 Mar 2010 16:24:33 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 8EF6B3A689A for ; Mon, 15 Mar 2010 16:24:30 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NrJeG-0005qq-UW for e2md@ietf.org; Tue, 16 Mar 2010 00:24:37 +0100 Date: Tue, 16 Mar 2010 00:24:36 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Updated agenda X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 23:24:35 -0000 Hi, I have updated and submitted the agenda for the e2md BoF to the materials manager: http://www.ietf.org/proceedings/10mar/agenda/e2md.txt For your convenience it is also copied below. Note that the biggest Open Issue (#3 on the agenda) is getting the group to understand the need for security considerations in our documents and commit to doing the required work. (This requirement comes from IESG/IAB.) If we can get this resolved on the mailing list before the meeting, much of this time will be freed up for other discussions. cheers, Dean & Bernie ---- Agenda E.164 to MetaData (E2MD) BoF IETF-77, Anaheim, CA, USA ----------------------------------- State: Draft Author: Bernie Hoeneisen Last Modified: 2010-03-15 BOF CHAIRS: Bernie Hoeneisen Dean Willis DATE/TIME/VENUE: Wed, 24 Mar 2010 / 1510-1610 / Redondo AGENDA: 1. Administrivia (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Presentations (Bernie Hoeneisen et al., 15 min) - General Problem Statement draft-hoeneisen-e164-to-metadata-02 - Use Cases related to E2MD: - unused (void) draft-ietf-enum-unused-04 - cnam draft-ietf-enum-cnam-08 - send-n draft-bellis-enum-send-n-02 3. Open Issues with E2MD (Dean, 10 min) 4. Open Discussion on Issues (10 min) 5. Discussion of Charter (Bernie, 10 min) 6. Conclusions and Next Steps (Chairs/ADs, 10 min) NOTE: As we only got a 1 hour slot approved, we need to be strict on timing. From richard@shockey.us Tue Mar 16 08:32:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10993A6B57 for ; Tue, 16 Mar 2010 08:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBjH7OT7++EU for ; Tue, 16 Mar 2010 08:32:28 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 6AB5E3A67B3 for ; Tue, 16 Mar 2010 08:32:28 -0700 (PDT) Received: (qmail 14355 invoked by uid 0); 16 Mar 2010 15:32:37 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 16 Mar 2010 15:32:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=R8yyKIp01fr5NhC8vUo2S5cBtx5RpK+oklEnW/zQkIIrF/bzSybLB+CNLib/ed0gs/Sj/1z9oRqUb6qE6yx98MKaN0P/mGyVSYd/dAlf6/unUaAWkTcERKn9o4zuYFza; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NrYl2-00078n-NA; Tue, 16 Mar 2010 09:32:36 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" , "'E.164 To MetaData BOF discussion list'" References: In-Reply-To: Date: Tue, 16 Mar 2010 11:32:33 -0400 Message-ID: <020d01cac51d$e6a49670$b3edc350$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrElYjuMVn/HD0vRGWuMxus4TzXDwAh+WvQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 15:32:30 -0000 The E2MD working group will, for each specification published, follow IETF practices and include a thorough Security Considerations section. These Security Considerations sections will include detailed threat models. Further, the specifications will include "MUST Implement" defensive mechanisms, operational guidelines, and/or applicability statements relative to particular metadata as appropriate. RS> This is redundant we all know that there are security requirements for RFC's. We don't need detailed threat models this is DNS technology that is well documented. We know how the DNS is used. I think this section needs to be removed. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Bernie Hoeneisen Sent: Monday, March 15, 2010 7:16 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Updated Charter Proposal Hi, Thanks for all the feedback and discussions on- and off-list! Based on these discussions, Dean and myself made an update to the proposed charter and we would like to know your opinion about it. The substantial changes were in section "Scope of Working Group". We also added there paragraphe about security considerations, which might trigger some further discussions... The whole currently proposed charter can be fetched from http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt For your convenience you can find a copy-paste of the section "Description of Working Group" below. cheers, Bernie ---- Description of Working Group ---------------------------- Abstract -------- E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI Mapping) in either public or private instantiations to provide additional information about E.164 (telephone) numbers. In some use cases, information (metadata) about E.164 numbers cannot be expressed as a URI (Uniform Resource Identifier) as required by the ENUM DDDS (Dynamic Delegation Discovery System) described in RFC 3761bis. Therefore, E2MD will define a different mechanism for expressing metadata. The initial expectation is that this mechanism will be a new DDDS for metadata, based on RFC 3761bis, that returns standardized metadata instead of URIs. Background ---------- ENUM provides an identifier mapping mechanism to map E.164 numbers to Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically used to look up the services associated with an E.164 number, each of which is represented by a URI. However, there is more information about a telephone number that may be useful when establishing a communications session using that phone number. For example, this information might be used to decide or what sort of communications session to establish using that phone number, or whether to accept a communications session offered by someone using that phone number. We refer to this information as "metadata". Several example use cases for metadata have been documented as Internet drafts, and will be considered during the work of E2MD for inclusion in the group's work product. Typically, this metadata information is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis innapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. Previous Enumservice proposals tried to resolve these issues by using the 'data' URI scheme or inventing completely new URI schemes, however it is believed that such proposals do not satisfy the general use case for metadata, and a new approach is required. Problem Statement ----------------- Typically, the phone-number asssociated metadata is such that it cannot be described using a URI consistent those returned by a lookup using RFC 3761bis, making a direct use of RFC 3761bis inapropriate. However, the basic lookup mechanism of RFC 3761bis appears to provide a good foundation for a metadata service, so E2MD will work from this basis. The initially favored approach is to define an additional ENUM service (E2M) that maps phone-numbers to metadata that will operate in parallel to the current ENUM service (E2U), which maps phone numbers to URIs. Current proposals for metadata to be addressed by E2MD include (but are not limited to) Enumservices for 'cnam' to provide information about the calling party name, 'unused' to provide a hint that a number is not in use, 'send-n' to describe the structure of an ENUM tree, 'spid' to describe a service provider identifier, 'itad' to describe an internet telephony administrative domain, etc. Scope of Working Group ---------------------- The E2MD Working Group is chartered to develop a new Dynamic Delegation Discovery System (DDDS) application that can be used with DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will provide the means for data related to E.164 numbers that do not fit into the classic concept of ENUM (E2U). The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification. Along with the E2MD DDDS application a new IANA registry will be specified for registration of E2MD services. The registration policy shall be Expert Review and Specification Required (see RFC 5226), similar to those specified for Enumservice (E2U) registrations. Limitations of the DNS are to be considered while defining the protocol; in particular packet size restrictions of deployed DNS transport. E2MD shall not be specified as a general purpose lookup nor as bulk transfer protocol, but rather focus on clear use cases related to E.164 numbers. The E2MD working group will, for each specification published, follow IETF practices and include a thorough Security Considerations section. These Security Considerations sections will include detailed threat models. Further, the specifications will include "MUST Implement" defensive mechanisms, operational guidelines, and/or applicability statements relative to particular metadata as appropriate. Some of the metadata standardized by E2MD may be subject to policy constraints within certain administrative jurisdictions, such as national boundaries. When such policy constraints exist, it is the responsibility of E2MD operators to comply with those constraints on the handling of metadata. The E2MD working group will not attempt to anticipate or mandate such policies. Rather, it is assumed that if policy constraints exist for access to the metadata in an E2MD database, then such policy will be enforced by the E2MD operator. In particular, the E2MD working group will not address AAA issues within the E2MD framework. A major product of the E2MD working group is to define a process and review model for the registration of new E2MD services with IANA. Until this process is in place, the E2MD working group will act as the central point for discussion and review of proposals for new E2MD services. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From Ray.Bellis@nominet.org.uk Tue Mar 16 08:37:49 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285A93A67B3; Tue, 16 Mar 2010 08:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da5cGtdQhBjB; Tue, 16 Mar 2010 08:37:47 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 2159A3A68DD; Tue, 16 Mar 2010 08:37:40 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=qfnJvxem7xzh8i9Aap8cN2sDRexnqmHfLQzbB3d4TlqESOKoXXkvKFmU zmkDANFoM0M+cY6JxNokhhO/KyfVvW7hD/1KDl+9GMZKJ/H9VtqZCPMOk Gbovfsmq0wvoo4I; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1268753876; x=1300289876; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Updated=20Charter=20Proposal|Date:=20Tue,=2016=20Mar =202010=2015:37:45=20+0000|Message-ID:=20|To:=20"Richard=20Shockey"=20|Cc:=20 "'Bernie=20Hoeneisen'"=20,=0D =0A=09"'E.164=20To=20MetaData=20BOF=20discussion=20list'" =20,=0D=0A=09e2md-bounces@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<020d01cac51d$e6a4967 0$b3edc350$@us>|References:=20=20<020d01cac51d$e6a496 70$b3edc350$@us>; bh=U1OWE9kbM2wIttflaZYmoEPVEA256E6GzpnxNfC+LKU=; b=wTOC7W4Lh0EtruU15UtWxORbbCf+bp2z7OM2AoJgMZ3lzBdXCWgYnPSb DPRLuv0/mTQMBjqCQJHU94dQ6Bxf39v7eavb9PRnhxVrLP3LnIw36R8sk ww9LBwXWepo5TvZ; X-IronPort-AV: E=Sophos;i="4.49,650,1262563200"; d="scan'208";a="22644942" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 16 Mar 2010 15:37:47 +0000 In-Reply-To: <020d01cac51d$e6a49670$b3edc350$@us> References: <020d01cac51d$e6a49670$b3edc350$@us> To: "Richard Shockey" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 16 Mar 2010 15:37:45 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 16/03/2010 03:37:46 PM, Serialize complete at 16/03/2010 03:37:46 PM Content-Type: multipart/alternative; boundary="=_alternative 0055DAFB802576E8_=" Cc: e2md-bounces@ietf.org, 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 15:37:49 -0000 This is a multipart message in MIME format. --=_alternative 0055DAFB802576E8_= Content-Type: text/plain; charset="US-ASCII" > RS> This is redundant we all know that there are security requirements for > RFC's. We don't need detailed threat models this is DNS technology that is > well documented. We know how the DNS is used. > > I think this section needs to be removed. +1 I'm fine with the new text that replaces the bit I complained about yesterday. Ray --=_alternative 0055DAFB802576E8_= Content-Type: text/html; charset="US-ASCII"
> RS> This is redundant we all know that there are security requirements for
> RFC's. We don't need detailed threat models this is DNS technology that is
> well documented. We know how the DNS is used.
>
> I think this section needs to be removed.

+1

I'm fine with the new text that replaces the bit I complained about yesterday.

Ray
--=_alternative 0055DAFB802576E8_=-- From dean.willis@softarmor.com Tue Mar 16 12:41:13 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7D33A692E for ; Tue, 16 Mar 2010 12:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r9epKo2VWdw for ; Tue, 16 Mar 2010 12:41:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A61C83A6898 for ; Tue, 16 Mar 2010 12:41:12 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GJfBOL006495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 14:41:13 -0500 Message-Id: <6F5E2DEC-0D6B-4CDD-AD38-8781DBF1D6DA@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <020d01cac51d$e6a49670$b3edc350$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 14:41:06 -0500 References: <020d01cac51d$e6a49670$b3edc350$@us> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 19:41:13 -0000 On Mar 16, 2010, at 10:32 AM, Richard Shockey wrote: > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations > section. These Security Considerations sections will include detailed > threat models. Further, the specifications will include "MUST > Implement" defensive mechanisms, operational guidelines, and/or > applicability statements relative to particular metadata as > appropriate. > > > RS> This is redundant we all know that there are security > requirements for > RFC's. We don't need detailed threat models this is DNS technology > that is > well documented. We know how the DNS is used. > > I think this section needs to be removed. This section was specifically added because postings on our E2MD discussion list seemed to indicate that some of our participants thought that E2MD should be somehow excepted from these requirements and explicitly say so in our charter. Going forward, we need a clear consensus that E2MD will be a "good citizen of the IETF" and play by the rules. If putting this explicitly into our charter helps both us and the IESG/IAB understand that we have developed such a consensus, then it is useful to have it there. Seriously, there is a question here. Are we going to look at each use case separately, and say "This use case is OK for the public Internet, but that use case is only ok in Intranets, and this other use case is so sensitive that it needs per- element encryption?" Or are we going to adopt a blanket policy of saying "Gee, some of our data might be sensitive. If you think it is sensitive, just don't show it to anybody who might abuse it." If the former, then we need to develop guidelines by which an expert reviewer can make a decision about any proposed future registration (Specification Required), or by which the IETF as a whole could make such a call (Standards Track). -- Dean From bernie@ietf.hoeneisen.ch Tue Mar 16 12:51:27 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1713E3A6767 for ; Tue, 16 Mar 2010 12:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE4EKvbSb1-Q for ; Tue, 16 Mar 2010 12:51:25 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 183173A693A for ; Tue, 16 Mar 2010 12:51:18 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NrcnU-0002JU-St; Tue, 16 Mar 2010 20:51:24 +0100 Date: Tue, 16 Mar 2010 20:51:24 +0100 (CET) From: 'Bernie Hoeneisen' X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <020d01cac51d$e6a49670$b3edc350$@us> Message-ID: References: <020d01cac51d$e6a49670$b3edc350$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 19:51:27 -0000 Hi Rich I see your point. However, this is at most redundant for specifications published as RFC, but other specifications are not automatically covered by RFC 3552 / BCP 72. How about replacing the 2nd sentence with a reference to the RFC 3552 / BCP 72, such as? The E2MD working group will, for each specification published, follow IETF practices and include a thorough Security Considerations section as defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on Security Considerations". Can we all agree to this? cheers, Bernie On Tue, 16 Mar 2010, Richard Shockey wrote: > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations > section. These Security Considerations sections will include detailed > threat models. Further, the specifications will include "MUST > Implement" defensive mechanisms, operational guidelines, and/or > applicability statements relative to particular metadata as > appropriate. > > > RS> This is redundant we all know that there are security requirements for > RFC's. We don't need detailed threat models this is DNS technology that is > well documented. We know how the DNS is used. > > I think this section needs to be removed. > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Bernie Hoeneisen > Sent: Monday, March 15, 2010 7:16 PM > To: E.164 To MetaData BOF discussion list > Subject: [e2md] Updated Charter Proposal > > Hi, > > Thanks for all the feedback and discussions on- and off-list! > > Based on these discussions, Dean and myself made an update to the proposed > charter and we would like to know your opinion about it. The substantial > changes were in section "Scope of Working Group". We also added there > paragraphe about security considerations, which might trigger some further > discussions... > > The whole currently proposed charter can be fetched from > > http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt > > For your convenience you can find a copy-paste of the section "Description > of > Working Group" below. > > cheers, > Bernie > > ---- > > > Description of Working Group > ---------------------------- > > > Abstract > -------- > > E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI > Mapping) in either public or private instantiations to provide > additional information about E.164 (telephone) numbers. In some use > cases, information (metadata) about E.164 numbers cannot be expressed > as a URI (Uniform Resource Identifier) as required by the ENUM DDDS > (Dynamic Delegation Discovery System) described in RFC 3761bis. > Therefore, E2MD will define a different mechanism for expressing > metadata. The initial expectation is that this mechanism will be a new > DDDS for metadata, based on RFC 3761bis, that returns standardized > metadata instead of URIs. > > > Background > ---------- > > ENUM provides an identifier mapping mechanism to map E.164 numbers to > Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically > used to look up the services associated with an E.164 number, each of > which is represented by a URI. > > However, there is more information about a telephone number that may > be useful when establishing a communications session using that phone > number. For example, this information might be used to decide or what > sort of communications session to establish using that phone number, > or whether to accept a communications session offered by someone using > that phone number. We refer to this information as "metadata". Several > example use cases for metadata have been documented as Internet > drafts, and will be considered during the work of E2MD for inclusion > in the group's work product. > > Typically, this metadata information is such that it cannot be > described using a URI consistent those returned by a lookup using RFC > 3761bis, making a direct use of RFC 3761bis innapropriate. However, > the basic lookup mechanism of RFC 3761bis appears to provide a good > foundation for a metadata service, so E2MD will work from this basis. > > Previous Enumservice proposals tried to resolve these issues by using > the 'data' URI scheme or inventing completely new URI schemes, however > it is believed that such proposals do not satisfy the general use case > for metadata, and a new approach is required. > > > Problem Statement > ----------------- > > Typically, the phone-number asssociated metadata is such that it > cannot be described using a URI consistent those returned by a lookup > using RFC 3761bis, making a direct use of RFC 3761bis inapropriate. > However, the basic lookup mechanism of RFC 3761bis appears to provide > a good foundation for a metadata service, so E2MD will work from this > basis. The initially favored approach is to define an additional ENUM > service (E2M) that maps phone-numbers to metadata that will operate in > parallel to the current ENUM service (E2U), which maps phone numbers > to URIs. > > Current proposals for metadata to be addressed by E2MD include (but > are not limited to) Enumservices for 'cnam' to provide information > about the calling party name, 'unused' to provide a hint that a > number is not in use, 'send-n' to describe the structure of an ENUM > tree, 'spid' to describe a service provider identifier, 'itad' to > describe an internet telephony administrative domain, etc. > > > Scope of Working Group > ---------------------- > > The E2MD Working Group is chartered to develop a new Dynamic > Delegation Discovery System (DDDS) application that can be used with > DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will > provide the means for data related to E.164 numbers that do not fit > into the classic concept of ENUM (E2U). > > The E2MD specifications shall reuse as much as possible from the ENUM > DDDS and its IANA registry specification. Along with the E2MD DDDS > application a new IANA registry will be specified for registration of > E2MD services. The registration policy shall be Expert Review and > Specification Required (see RFC 5226), similar to those specified for > Enumservice (E2U) registrations. > > Limitations of the DNS are to be considered while defining the > protocol; in particular packet size restrictions of deployed DNS > transport. > > E2MD shall not be specified as a general purpose lookup nor as bulk > transfer protocol, but rather focus on clear use cases related to > E.164 numbers. > > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations > section. These Security Considerations sections will include detailed > threat models. Further, the specifications will include "MUST > Implement" defensive mechanisms, operational guidelines, and/or > applicability statements relative to particular metadata as > appropriate. > > Some of the metadata standardized by E2MD may be subject to policy > constraints within certain administrative jurisdictions, such as > national boundaries. When such policy constraints exist, it is the > responsibility of E2MD operators to comply with those constraints on > the handling of metadata. The E2MD working group will not attempt to > anticipate or mandate such policies. Rather, it is assumed that if > policy constraints exist for access to the metadata in an E2MD > database, then such policy will be enforced by the E2MD operator. In > particular, the E2MD working group will not address AAA issues within > the E2MD framework. > > A major product of the E2MD working group is to define a process and > review model for the registration of new E2MD services with > IANA. Until this process is in place, the E2MD working group will act > as the central point for discussion and review of proposals for new > E2MD services. > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From dean.willis@softarmor.com Tue Mar 16 12:52:16 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204DA3A699F for ; Tue, 16 Mar 2010 12:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvaCqkaa2u0B for ; Tue, 16 Mar 2010 12:52:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2EC673A6971 for ; Tue, 16 Mar 2010 12:52:05 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GJq1CG006600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 14:52:03 -0500 Message-Id: <3AC72D2D-394B-4F88-A1B4-43A959ABA191@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <020d01cac51d$e6a49670$b3edc350$@us> Content-Type: multipart/alternative; boundary=Apple-Mail-11-551624269 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 14:51:56 -0500 References: <020d01cac51d$e6a49670$b3edc350$@us> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 19:52:16 -0000 --Apple-Mail-11-551624269 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 16, 2010, at 10:32 AM, Richard Shockey wrote: > > > RS> This is redundant we all know that there are security > requirements for > RFC's. We don't need detailed threat models this is DNS technology > that is > well documented. We know how the DNS is used. > Apparently some people either don't understand how the DNS works, or haven't thought the threat models for all possible metadata. I certainly fall into at least the second camp, because I don't yet know what "all possible metadata" encompasses, and I'm pretty sure I can imagine some stuff that is potentially problematic. Remember, people will be adding new metadata long after "we" (the E2MD working group) are gone. I'm sure somebody will come up with something pretty crazy . . . -- Dean --Apple-Mail-11-551624269 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 16, 2010, = at 10:32 AM, Richard Shockey wrote:


RS> This is redundant we all know = that there are security requirements for
RFC's. We don't need = detailed threat models this is DNS technology that is
well = documented. We know how the DNS is = used.


Apparently some people = either don't understand how the DNS works, or haven't thought the threat = models for all possible metadata. I certainly fall into at least the = second camp, because I don't yet know what "all possible metadata" = encompasses, and I'm pretty sure I can imagine some stuff that is = potentially problematic. Remember, people will be adding new metadata = long after "we" (the E2MD working group) are gone. I'm sure somebody = will come up with something pretty crazy . . = .

--
Dean
= --Apple-Mail-11-551624269-- From richard@shockey.us Tue Mar 16 13:09:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62BC3A6B56 for ; Tue, 16 Mar 2010 13:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWisTnnkAVMh for ; Tue, 16 Mar 2010 13:09:25 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 4118D3A6AA3 for ; Tue, 16 Mar 2010 13:09:17 -0700 (PDT) Received: (qmail 31815 invoked by uid 0); 16 Mar 2010 20:09:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 16 Mar 2010 20:09:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=PqzEEN/tRbEfh47VH09dwAqSB6/jxhVciaeAa8TM2JTCLiBLwgPDL1yqeAn3kuT6FXzLoTATAypgoaoYHwD63GGmt40arBzkt3xHu4VSop4vvOeI4RjMVeLaaO6VF0ct; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nrd4v-0003rM-O9; Tue, 16 Mar 2010 14:09:26 -0600 From: "Richard Shockey" To: "'Bernie Hoeneisen'" References: <020d01cac51d$e6a49670$b3edc350$@us> In-Reply-To: Date: Tue, 16 Mar 2010 16:09:22 -0400 Message-ID: <029301cac544$925c9730$b715c590$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFQhJbbjRjy0YMSPCLKJJvewus8AAAmj8g Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 20:09:30 -0000 Of course this is documented custom and practice in the IETF. -----Original Message----- From: 'Bernie Hoeneisen' [mailto:bernie@ietf.hoeneisen.ch] Sent: Tuesday, March 16, 2010 3:51 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] Updated Charter Proposal Hi Rich I see your point. However, this is at most redundant for specifications published as RFC, but other specifications are not automatically covered by RFC 3552 / BCP 72. How about replacing the 2nd sentence with a reference to the RFC 3552 / BCP 72, such as? The E2MD working group will, for each specification published, follow IETF practices and include a thorough Security Considerations section as defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on Security Considerations". Can we all agree to this? cheers, Bernie On Tue, 16 Mar 2010, Richard Shockey wrote: > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations > section. These Security Considerations sections will include detailed > threat models. Further, the specifications will include "MUST > Implement" defensive mechanisms, operational guidelines, and/or > applicability statements relative to particular metadata as > appropriate. > > > RS> This is redundant we all know that there are security requirements for > RFC's. We don't need detailed threat models this is DNS technology that is > well documented. We know how the DNS is used. > > I think this section needs to be removed. > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Bernie Hoeneisen > Sent: Monday, March 15, 2010 7:16 PM > To: E.164 To MetaData BOF discussion list > Subject: [e2md] Updated Charter Proposal > > Hi, > > Thanks for all the feedback and discussions on- and off-list! > > Based on these discussions, Dean and myself made an update to the proposed > charter and we would like to know your opinion about it. The substantial > changes were in section "Scope of Working Group". We also added there > paragraphe about security considerations, which might trigger some further > discussions... > > The whole currently proposed charter can be fetched from > > http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt > > For your convenience you can find a copy-paste of the section "Description > of > Working Group" below. > > cheers, > Bernie > > ---- > > > Description of Working Group > ---------------------------- > > > Abstract > -------- > > E.164 to MetaData (E2MD) will build on ENUM (E.164 Number to URI > Mapping) in either public or private instantiations to provide > additional information about E.164 (telephone) numbers. In some use > cases, information (metadata) about E.164 numbers cannot be expressed > as a URI (Uniform Resource Identifier) as required by the ENUM DDDS > (Dynamic Delegation Discovery System) described in RFC 3761bis. > Therefore, E2MD will define a different mechanism for expressing > metadata. The initial expectation is that this mechanism will be a new > DDDS for metadata, based on RFC 3761bis, that returns standardized > metadata instead of URIs. > > > Background > ---------- > > ENUM provides an identifier mapping mechanism to map E.164 numbers to > Uniform Resource Identifiers (URIs) using the DNS. ENUM is typically > used to look up the services associated with an E.164 number, each of > which is represented by a URI. > > However, there is more information about a telephone number that may > be useful when establishing a communications session using that phone > number. For example, this information might be used to decide or what > sort of communications session to establish using that phone number, > or whether to accept a communications session offered by someone using > that phone number. We refer to this information as "metadata". Several > example use cases for metadata have been documented as Internet > drafts, and will be considered during the work of E2MD for inclusion > in the group's work product. > > Typically, this metadata information is such that it cannot be > described using a URI consistent those returned by a lookup using RFC > 3761bis, making a direct use of RFC 3761bis innapropriate. However, > the basic lookup mechanism of RFC 3761bis appears to provide a good > foundation for a metadata service, so E2MD will work from this basis. > > Previous Enumservice proposals tried to resolve these issues by using > the 'data' URI scheme or inventing completely new URI schemes, however > it is believed that such proposals do not satisfy the general use case > for metadata, and a new approach is required. > > > Problem Statement > ----------------- > > Typically, the phone-number asssociated metadata is such that it > cannot be described using a URI consistent those returned by a lookup > using RFC 3761bis, making a direct use of RFC 3761bis inapropriate. > However, the basic lookup mechanism of RFC 3761bis appears to provide > a good foundation for a metadata service, so E2MD will work from this > basis. The initially favored approach is to define an additional ENUM > service (E2M) that maps phone-numbers to metadata that will operate in > parallel to the current ENUM service (E2U), which maps phone numbers > to URIs. > > Current proposals for metadata to be addressed by E2MD include (but > are not limited to) Enumservices for 'cnam' to provide information > about the calling party name, 'unused' to provide a hint that a > number is not in use, 'send-n' to describe the structure of an ENUM > tree, 'spid' to describe a service provider identifier, 'itad' to > describe an internet telephony administrative domain, etc. > > > Scope of Working Group > ---------------------- > > The E2MD Working Group is chartered to develop a new Dynamic > Delegation Discovery System (DDDS) application that can be used with > DNS NAPTR RRs for resolving E.164 numbers into metadata. E2MD will > provide the means for data related to E.164 numbers that do not fit > into the classic concept of ENUM (E2U). > > The E2MD specifications shall reuse as much as possible from the ENUM > DDDS and its IANA registry specification. Along with the E2MD DDDS > application a new IANA registry will be specified for registration of > E2MD services. The registration policy shall be Expert Review and > Specification Required (see RFC 5226), similar to those specified for > Enumservice (E2U) registrations. > > Limitations of the DNS are to be considered while defining the > protocol; in particular packet size restrictions of deployed DNS > transport. > > E2MD shall not be specified as a general purpose lookup nor as bulk > transfer protocol, but rather focus on clear use cases related to > E.164 numbers. > > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations > section. These Security Considerations sections will include detailed > threat models. Further, the specifications will include "MUST > Implement" defensive mechanisms, operational guidelines, and/or > applicability statements relative to particular metadata as > appropriate. > > Some of the metadata standardized by E2MD may be subject to policy > constraints within certain administrative jurisdictions, such as > national boundaries. When such policy constraints exist, it is the > responsibility of E2MD operators to comply with those constraints on > the handling of metadata. The E2MD working group will not attempt to > anticipate or mandate such policies. Rather, it is assumed that if > policy constraints exist for access to the metadata in an E2MD > database, then such policy will be enforced by the E2MD operator. In > particular, the E2MD working group will not address AAA issues within > the E2MD framework. > > A major product of the E2MD working group is to define a process and > review model for the registration of new E2MD services with > IANA. Until this process is in place, the E2MD working group will act > as the central point for discussion and review of proposals for new > E2MD services. > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From dean.willis@softarmor.com Tue Mar 16 13:23:16 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD573A6A64 for ; Tue, 16 Mar 2010 13:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWV0ptwtz6SB for ; Tue, 16 Mar 2010 13:23:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0FAD13A6AB3 for ; Tue, 16 Mar 2010 13:23:15 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GKNEpI006869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 15:23:16 -0500 Message-Id: <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> From: Dean Willis To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 15:23:09 -0500 References: <020d01cac51d$e6a49670$b3edc350$@us> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 20:23:16 -0000 On Mar 16, 2010, at 2:51 PM, Bernie Hoeneisen wrote: > Hi Rich > > I see your point. However, this is at most redundant for > specifications published as RFC, but other specifications are not > automatically covered by RFC 3552 / BCP 72. > > How about replacing the 2nd sentence with a reference to the RFC > 3552 / BCP 72, such as? > > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations > section as > defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on > Security Considerations". I think you're missing the point I was trying to make. The E2MD group is most likely going to develop a process for registering future metadata extensions. Part of this process needs to be guidance on how to handle security considerations for metadata. I believe this needs to include the decision process that we used in handling the use-cases that are currently before us. If, in considering the current use cases we say "Gee, this is just DNS data, and we ALL know the properties of DNS data, so these use cases need no review" then that's the decision process we're leaving to future reviewers of E2MD proposals. If no more consideration is needed, then why don't we just open the E2MD registration process up as first-come, first-served and be done with it? -- Dean From bernie@ietf.hoeneisen.ch Tue Mar 16 13:44:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595BA3A6990 for ; Tue, 16 Mar 2010 13:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXpARGgbnSBP for ; Tue, 16 Mar 2010 13:44:27 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id F31043A69E1 for ; Tue, 16 Mar 2010 13:44:26 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nrdcq-0002hO-By; Tue, 16 Mar 2010 21:44:28 +0100 Date: Tue, 16 Mar 2010 21:44:28 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Dean Willis In-Reply-To: <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> Message-ID: References: <020d01cac51d$e6a49670$b3edc350$@us> <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 20:44:28 -0000 Dean, We have a similar case for Enumservice registrations, see: http://tools.ietf.org/html/draft-ietf-enum-enumservices-guide The e2md registration process will be based in that document. The following section in that document address your concerns, such as: --- 3.3. Security Requirements An analysis of security issues is REQUIRED for all registered Enumservices. (This is in accordance with the basic requirements for all IETF protocols.) All descriptions of security issues MUST be as accurate and extensive as feasible. In particular, a statement that there are "no security issues associated with this Enumservice" must not be confused with "the security issues associated with this Enumservice have not been assessed". There is no requirement that an Enumservice must be completely free of security risks. Nevertheless, all known security risks MUST be identified in an Enumservice Specification. The security considerations section of Enumservice Specifications is subject to continuing evaluation and modification, in accordance with Section 11.7. Some of the issues to be looked at in a security analysis of an Enumservice are: 1. Complex Enumservices may include provisions for directives that institute actions on a user's resources. In many cases provision can be made to specify arbitrary actions in an unrestricted fashion which may then have devastating results (especially if there is a risk for a new ENUM look-up, and because of that an infinite loop in the overall resolution process of the E.164 number). 2. Complex Enumservices may include provisions for directives that institute actions which, while not directly harmful, may result in disclosure of information that either facilitates a subsequent attack or else violates the users' privacy in some way. 3. An Enumservice might be targeted for applications that require some sort of security assurance but do not provide the necessary security mechanisms themselves. For example, an Enumservice could be defined for storage of confidential security services information such as alarm systems or message service passcodes, which in turn require an external confidentiality service. --- 5.5. Security Considerations (MANDATORY [section in the specification]) A section explaining any potential security threats that are unique to the given registration MUST be included. This MUST also include any information about access to Personally Identifiable Information (PII). An Enumservice Specification SHOULD NOT include general and obvious security recommendations, such as securing servers with strong password authentication. [RFC3552] provides guidance to write a good Security Considerations section, Section 10.2 of this document contains guidance specific to Enumservice registration. --- 7.2. Review Guidelines Generally, the "Expert Review" process of an Enumservice MUST follow the guidelines documented in Section 3.3 of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226]. The experts MUST evaluate the criterion as set out in [RFC5226], as well as consider the following: o Verify conformance with the ENUM specification [I-D.ietf-enum-3761bis]. o Verify that the requirements set out in this document (Section 3, Section 5) are met. This includes check for completeness and whether all the aspects described in Section 3 and Section 5 are sufficiently addressed. [...] --- 10.2. Enumservice Security Considerations Guideline [I-D.ietf-enum-3761bis] already outlines security considerations affecting ENUM as a whole. Enumservice Specifications do not need to and SHOULD NOT repeat considerations already listed in that document. However, Enumservice Specifications SHOULD include a reference to that section. ENUM refers to resources using existing URI Schemes and protocols. Enumservice Specifications do not need to and SHOULD NOT repeat security considerations affecting those protocols and URI Schemes themselves. However, in some cases, the inclusion of those protocols and URI Schemes into ENUM specifically could introduce new security issues. In these cases, those issues or risks MUST be covered in the "Security Considerations" section of the Enumservice Specification. Authors should pay particular attention to any indirect risks that are associated with a proposed Enumservice, including cases where the proposed Enumservice could lead to the discovery or disclosure of Personally Identifiable Information (PII). ---- Anything missing? cheers, Bernie On Tue, 16 Mar 2010, Dean Willis wrote: > > On Mar 16, 2010, at 2:51 PM, Bernie Hoeneisen wrote: > >> Hi Rich >> >> I see your point. However, this is at most redundant for specifications >> published as RFC, but other specifications are not automatically covered by >> RFC 3552 / BCP 72. >> >> How about replacing the 2nd sentence with a reference to the RFC 3552 / BCP >> 72, such as? >> >> The E2MD working group will, for each specification published, follow >> IETF practices and include a thorough Security Considerations section as >> defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on >> Security Considerations". > > > I think you're missing the point I was trying to make. > > The E2MD group is most likely going to develop a process for registering > future metadata extensions. > > Part of this process needs to be guidance on how to handle security > considerations for metadata. I believe this needs to include the decision > process that we used in handling the use-cases that are currently before us. > If, in considering the current use cases we say "Gee, this is just DNS data, > and we ALL know the properties of DNS data, so these use cases need no > review" then that's the decision process we're leaving to future reviewers of > E2MD proposals. If no more consideration is needed, then why don't we just > open the E2MD registration process up as first-come, first-served and be done > with it? > > -- > Dean > From richard@shockey.us Tue Mar 16 14:01:16 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1E43A67C0 for ; Tue, 16 Mar 2010 14:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DHVqWiX+xon for ; Tue, 16 Mar 2010 14:01:15 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 66C593A696F for ; Tue, 16 Mar 2010 14:01:12 -0700 (PDT) Received: (qmail 14714 invoked by uid 0); 16 Mar 2010 21:01:21 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 16 Mar 2010 21:01:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=H6AfSu2p/kNXsg3WBD/Cl3xB96/hK1QDm2jVAcnXDIU1f7m0zxcGaAcSruXrkzJJzp2G6BC+AizukacoiAwNSnAmy//xaE+7vzsoogNzcGI1kpG8Fs0P6FrQ/6CM1b1I; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NrdtB-00063U-3M; Tue, 16 Mar 2010 15:01:21 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Bernie Hoeneisen'" References: <020d01cac51d$e6a49670$b3edc350$@us> <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> In-Reply-To: <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> Date: Tue, 16 Mar 2010 17:01:17 -0400 Message-ID: <02a001cac54b$d33845e0$79a8d1a0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrFRofJIKKxzy5tRnmJggSizzP1OwABNjTw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 21:01:16 -0000 Can we just get the WG formed first? What instructions the WG gives to the expert reviewers should be covered in the drafts not the charter and we have a good start for doing that in the enumservice registration documents. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, March 16, 2010 4:23 PM To: Bernie Hoeneisen Cc: Richard Shockey; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] Updated Charter Proposal On Mar 16, 2010, at 2:51 PM, Bernie Hoeneisen wrote: > Hi Rich > > I see your point. However, this is at most redundant for > specifications published as RFC, but other specifications are not > automatically covered by RFC 3552 / BCP 72. > > How about replacing the 2nd sentence with a reference to the RFC > 3552 / BCP 72, such as? > > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations > section as > defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on > Security Considerations". I think you're missing the point I was trying to make. The E2MD group is most likely going to develop a process for registering future metadata extensions. Part of this process needs to be guidance on how to handle security considerations for metadata. I believe this needs to include the decision process that we used in handling the use-cases that are currently before us. If, in considering the current use cases we say "Gee, this is just DNS data, and we ALL know the properties of DNS data, so these use cases need no review" then that's the decision process we're leaving to future reviewers of E2MD proposals. If no more consideration is needed, then why don't we just open the E2MD registration process up as first-come, first-served and be done with it? -- Dean From dean.willis@softarmor.com Tue Mar 16 14:59:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2233A67AC for ; Tue, 16 Mar 2010 14:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FR8zHiMxV1fo for ; Tue, 16 Mar 2010 14:59:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1AC6B3A67B0 for ; Tue, 16 Mar 2010 14:59:30 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GLxQeN007638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 16:59:28 -0500 Message-Id: <82568A8D-97B5-4006-A88D-246590FB7859@softarmor.com> From: Dean Willis To: Richard Shockey In-Reply-To: <02a001cac54b$d33845e0$79a8d1a0$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 16:59:21 -0500 References: <020d01cac51d$e6a49670$b3edc350$@us> <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> <02a001cac54b$d33845e0$79a8d1a0$@us> X-Mailer: Apple Mail (2.936) Cc: 'Bernie Hoeneisen' , "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 21:59:31 -0000 On Mar 16, 2010, at 4:01 PM, Richard Shockey wrote: > Can we just get the WG formed first? Have to have an acceptable charter to form a WG. > > What instructions the WG gives to the expert reviewers should be > covered in > the drafts not the charter and we have a good start for doing that > in the > enumservice registration documents. Fair question. Can the charter say that the WG expects to have to develop instructions for expert reviewers and expects to draw heavily on the enumservice registration documents in doing so? If it does, I think this would go a long way towards answering (or at least informing) critics who think that E2MD believes this has already been completely resolved. -- Dean From bernie@ietf.hoeneisen.ch Tue Mar 16 15:07:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A68D3A6813 for ; Tue, 16 Mar 2010 15:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yI4zqdKhPJ+p for ; Tue, 16 Mar 2010 15:07:23 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 3BCB83A67F7 for ; Tue, 16 Mar 2010 15:07:22 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nrev7-0003AC-BY; Tue, 16 Mar 2010 23:07:25 +0100 Date: Tue, 16 Mar 2010 23:07:25 +0100 (CET) From: 'Bernie Hoeneisen' X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Dean Willis In-Reply-To: <82568A8D-97B5-4006-A88D-246590FB7859@softarmor.com> Message-ID: References: <020d01cac51d$e6a49670$b3edc350$@us> <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> <02a001cac54b$d33845e0$79a8d1a0$@us> <82568A8D-97B5-4006-A88D-246590FB7859@softarmor.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 22:07:24 -0000 Dean, On Tue, 16 Mar 2010, Dean Willis wrote: >> What instructions the WG gives to the expert reviewers should be covered in >> the drafts not the charter and we have a good start for doing that in the >> enumservice registration documents. > > Fair question. > > Can the charter say that the WG expects to have to develop instructions for > expert reviewers and expects to draw heavily on the enumservice registration > documents in doing so? I believe the current charter proposal already covers this implicitely: "The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification." cheers, Bernie From dean.willis@softarmor.com Tue Mar 16 16:00:25 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9E33A690E for ; Tue, 16 Mar 2010 16:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VsoQe0+OiQJ for ; Tue, 16 Mar 2010 16:00:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7E5FC3A6824 for ; Tue, 16 Mar 2010 16:00:24 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GN0LK1008216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 18:00:22 -0500 Message-Id: <5EE371D1-1CDA-4033-BB64-BC5EA5DD1CC2@softarmor.com> From: Dean Willis To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 18:00:16 -0500 References: <020d01cac51d$e6a49670$b3edc350$@us> <7349E590-F44F-4075-ABCE-635D96B29B0F@softarmor.com> <02a001cac54b$d33845e0$79a8d1a0$@us> <82568A8D-97B5-4006-A88D-246590FB7859@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 23:00:25 -0000 On Mar 16, 2010, at 5:07 PM, Bernie Hoeneisen wrote: > Dean, > > On Tue, 16 Mar 2010, Dean Willis wrote: > >>> What instructions the WG gives to the expert reviewers should be >>> covered in >>> the drafts not the charter and we have a good start for doing that >>> in the >>> enumservice registration documents. >> >> Fair question. >> >> Can the charter say that the WG expects to have to develop >> instructions for expert reviewers and expects to draw heavily on >> the enumservice registration documents in doing so? > > I believe the current charter proposal already covers this > implicitely: > > "The E2MD specifications shall reuse as much as possible from the > ENUM > DDDS and its IANA registry specification." > We've learned something about "implicit" over the years, have we not? -- Dean From Ray.Bellis@nominet.org.uk Wed Mar 17 02:56:56 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD533A695A for ; Wed, 17 Mar 2010 02:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCogyQXXewSM for ; Wed, 17 Mar 2010 02:56:55 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id CF7793A67FA for ; Wed, 17 Mar 2010 02:56:54 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=ep6XRg7TfOt6LOJD51YYsAf9JV6nafTpe+kTWd2LN6nNZuqvRIXIidL+ /jvZN/BpG7K6lL0XwfuIQvudWCQ8ldh5ZNNkPlcfaVfxHsNoIjK4TaEJG 8i91+asdQCSP09M; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1268819825; x=1300355825; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Updated=20Charter=20Proposal|Date:=20Wed,=2017=20Mar =202010=2009:57:00=20+0000|Message-ID:=20|To:=20'Bernie=20Hoeneisen'=20 |Cc:=20"'E.164=20To=20MetaData=20BOF=20discussion=20list' "=20,=0D=0A=09Richard=20Shockey=20|MIME-Version:=201.0|In-Reply-To:=20 |References:=20=09<020d01cac51d$e6a49670$b3edc350$@us >=20; bh=KLiupCcWjmoL27af5SnRX7laA/DATgXecgomj7UaOjY=; b=Wt2f1+5R3VgMUzbIfiMW2GtI7bdMqJZRuBx2geC0jd1t0JMpJhq6lsgv anwTvyNyVhpW6XfHv5xXKEqMX2Red5SlCdPRNJeVwMCqX6ad8P0lB2Tph J7y27xc5V6cc2TC; X-IronPort-AV: E=Sophos;i="4.49,656,1262563200"; d="scan'208";a="22658754" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 17 Mar 2010 09:57:03 +0000 In-Reply-To: References: <020d01cac51d$e6a49670$b3edc350$@us> To: 'Bernie Hoeneisen' MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 17 Mar 2010 09:57:00 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 17/03/2010 09:57:02 AM, Serialize complete at 17/03/2010 09:57:02 AM Content-Type: multipart/alternative; boundary="=_alternative 0036A868802576E9_=" Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 09:56:56 -0000 This is a multipart message in MIME format. --=_alternative 0036A868802576E9_= Content-Type: text/plain; charset="US-ASCII" > How about replacing the 2nd sentence with a reference to the RFC 3552 / > BCP 72, such as? > > The E2MD working group will, for each specification published, follow > IETF practices and include a thorough Security Considerations section as > defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on > Security Considerations". > > Can we all agree to this? That works for me. Ray --=_alternative 0036A868802576E9_= Content-Type: text/html; charset="US-ASCII"
> How about replacing the 2nd sentence with a reference to the RFC 3552 /
> BCP 72, such as?
>
>    The E2MD working group will, for each specification published, follow
>    IETF practices and include a thorough Security Considerations section as
>    defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on
>    Security Considerations".
>
> Can we all agree to this?
That works for me.

Ray

--=_alternative 0036A868802576E9_=-- From jay@nzrs.net.nz Wed Mar 17 13:12:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024BC3A697C for ; Wed, 17 Mar 2010 13:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qmBVnQiAHMt for ; Wed, 17 Mar 2010 13:12:33 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 2936E3A6963 for ; Wed, 17 Mar 2010 13:12:33 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id B93822DB143; Thu, 18 Mar 2010 09:12:42 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juxmSRLAkf1y; Thu, 18 Mar 2010 09:12:42 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 3F7982DB13B; Thu, 18 Mar 2010 09:12:42 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Thu, 18 Mar 2010 09:12:41 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <001ED37F-A8A1-4D8E-BBEF-CECD44FBC088@nzrs.net.nz> References: <020d01cac51d$e6a49670$b3edc350$@us> To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Updated Charter Proposal X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 20:12:34 -0000 On 17/03/2010, at 10:57 PM, Ray.Bellis@nominet.org.uk wrote: >=20 > > How about replacing the 2nd sentence with a reference to the RFC = 3552 /=20 > > BCP 72, such as? > >=20 > > The E2MD working group will, for each specification published, = follow > > IETF practices and include a thorough Security Considerations = section as > > defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on > > Security Considerations". > >=20 > > Can we all agree to this? >=20 > That works for me.=20 >=20 > Ray=20 me too. Jay >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From fluffy@cisco.com Wed Mar 17 16:05:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A013A69A8 for ; Wed, 17 Mar 2010 16:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.769 X-Spam-Level: X-Spam-Status: No, score=-109.769 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkODdqCfsMS6 for ; Wed, 17 Mar 2010 16:05:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8FB0E3A68C0 for ; Wed, 17 Mar 2010 16:05:27 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHL9oEurR7Hu/2dsb2JhbACbJHOgHphwhHYEgxo X-IronPort-AV: E=Sophos;i="4.51,261,1267401600"; d="scan'208";a="168011065" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 17 Mar 2010 23:05:38 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2HN5br0022245; Wed, 17 Mar 2010 23:05:37 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> Date: Wed, 17 Mar 2010 17:05:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <597269ED-BC94-458F-A38E-198E003A7375@cisco.com> References: <201002252200.XAA07138@TR-Sys.de> <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> To: Lawrence Conroy X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org, bernie@ietf.hoeneisen.ch Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 23:05:28 -0000 On Feb 25, 2010, at 3:25 PM, Lawrence Conroy wrote: > SCTP has the major *benefit* that it is unknown to Firewall/Home = Gateways, so they don't think they know about it, and so don't try to = proxy//break it :). Nearly every NAT/FW I use just drops packets it does not understand. If = there was some protocol that NAT/FW just ignored, I'm sure it would be = very popular.=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From lconroy@insensate.co.uk Wed Mar 17 17:12:08 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918633A68A0 for ; Wed, 17 Mar 2010 17:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj4Ge7JViApU for ; Wed, 17 Mar 2010 17:12:07 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 1704D3A6A92 for ; Wed, 17 Mar 2010 17:12:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 7CD5F117532; Thu, 18 Mar 2010 00:12:16 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <597269ED-BC94-458F-A38E-198E003A7375@cisco.com> Date: Thu, 18 Mar 2010 00:12:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <836DC8E0-5D09-403A-92D3-84419688A368@insensate.co.uk> References: <201002252200.XAA07138@TR-Sys.de> <03BCDEFE-47AE-49E2-829F-60693E8F5064@insensate.co.uk> <597269ED-BC94-458F-A38E-198E003A7375@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] [DNSOP] charter discussion kick-off X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 00:12:09 -0000 Hi Cullen, folks, I have no idea why this one took so long to get here. Still, on the day that Dean "came out" as a Skype user ... There's a simple answer -- get yourself a cheaper gateway. Expensive (badly written) ones get in the way; my home gateway doesn't even try. It's the trying that's a problem. They think they understand DNS/UDP so they break it. Fortunately I don't have the money for an expensive one, and mine does let weird stuff through (most home gateways do, or torrents wouldn't work and they wouldn't be sold). all the best, Lawrence On 17 Mar 2010, at 23:05, Cullen Jennings wrote: >=20 > On Feb 25, 2010, at 3:25 PM, Lawrence Conroy wrote: >=20 >> SCTP has the major *benefit* that it is unknown to Firewall/Home = Gateways, so they don't think they know about it, and so don't try to = proxy//break it :). >=20 > Nearly every NAT/FW I use just drops packets it does not understand. = If there was some protocol that NAT/FW just ignored, I'm sure it would = be very popular.=20 >=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 From fluffy@cisco.com Wed Mar 17 18:01:57 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1673A6921 for ; Wed, 17 Mar 2010 18:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.763 X-Spam-Level: X-Spam-Status: No, score=-109.763 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIK4HKEmdR4E for ; Wed, 17 Mar 2010 18:01:57 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E67A63A67E6 for ; Wed, 17 Mar 2010 18:01:56 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvULAO8XoUurR7Hu/2dsb2JhbAAcmwhzm2+Yc4R2BIMa X-IronPort-AV: E=Sophos;i="4.51,262,1267401600"; d="scan'208";a="101855707" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 18 Mar 2010 00:37:55 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2I0bsjo006737 for ; Thu, 18 Mar 2010 00:37:54 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 17 Mar 2010 18:37:53 -0600 Message-Id: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> To: e2md@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 01:01:57 -0000 Typically the IETF attempts to produce protocols that have reasonable = privacy and security characteristics (See BCP 61). For the most part, = the IETF does protocols that are applicable to the "Internet" but there = are some notable exceptions - for example DHCP. Charters are one of the things that define what the IETF is doing and = also what is out of scope for any WG to do. Regardless of what we have = done with ENUM, DNS, and others in the past, part of the purpose of this = BOF would be to see if we can get consensus on what we want to do in the = future. I would be surprised to see people willing to just ignore any = privacy issues. It seems the two leading proposal for dealing with the = privacy issues could roughly be categorized as 1) don't put private = things in DNS or 2) don't allow the DNS out of a private space. Both of = these have pros/cons. I was hopping some useful discussion of these, or = discussion of other alternatives, might be one of the things that comes = out of the BOF. Cullen =20 From dean.willis@softarmor.com Thu Mar 18 00:33:07 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A378B3A68E1 for ; Thu, 18 Mar 2010 00:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0O7CMCtErH0 for ; Thu, 18 Mar 2010 00:33:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 884113A6894 for ; Thu, 18 Mar 2010 00:33:06 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2I7WOpF021720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Mar 2010 02:32:26 -0500 Message-Id: <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> From: Dean Willis To: Cullen Jennings In-Reply-To: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 02:32:18 -0500 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 07:33:07 -0000 On Mar 17, 2010, at 7:37 PM, Cullen Jennings wrote: > I was hopping some useful discussion of these, or discussion of > other alternatives, might be one of the things that comes out of the > BOF. > Other alternatives I have heard so far include: 1) Encrypting the metadata; it's in the public DNS, but not compromised as reading it takes a key. Key management is the issue. 2) Putting an HTTP link to the metadata into the DNS instead of the raw metadata. The web server can then do conventional web-AAA checks to decide what to return. This has the added advantage of allowing different results to be returned based on aspects of the requestor, such as identity, location, etc. This might also work for Daryl's egress routing scenario. For example: cnam=https://meta.example.com/cnam/+19725199190 From fluffy@cisco.com Thu Mar 18 07:29:14 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0143A6BFD for ; Thu, 18 Mar 2010 07:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.88 X-Spam-Level: X-Spam-Status: No, score=-109.88 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNPgq++z7Bgs for ; Thu, 18 Mar 2010 07:29:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 950973A6BF8 for ; Thu, 18 Mar 2010 07:29:13 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE/VoUurRN+K/2dsb2JhbACbLXOhC5hygkyCLQSDHQ X-IronPort-AV: E=Sophos;i="4.51,267,1267401600"; d="scan'208";a="247265351" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2010 14:29:25 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2IETOLl025893; Thu, 18 Mar 2010 14:29:24 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> Date: Thu, 18 Mar 2010 08:29:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:29:14 -0000 On Mar 18, 2010, at 1:32 AM, Dean Willis wrote: > 2) Putting an HTTP link to the metadata into the DNS instead of the = raw metadata. The web server can then do conventional web-AAA checks to = decide what to return. This has the added advantage of allowing = different results to be returned based on aspects of the requestor, such = as identity, location, etc. This might also work for Daryl's egress = routing scenario. >=20 > For example: cnam=3Dhttps://meta.example.com/cnam/+19725199190 Speaking of such things, one person asked me, why use DNS at all. Why = not just do a HTTPS lookup like https://meta.example.com/+19725199190/cnam=20 I realized I could not really answer that question.=20 Cullen From Ray.Bellis@nominet.org.uk Thu Mar 18 07:40:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48A53A6C0F for ; Thu, 18 Mar 2010 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC42H9TaqfdH for ; Thu, 18 Mar 2010 07:40:31 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 5AC683A6C13 for ; Thu, 18 Mar 2010 07:40:31 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=SCHUQ7GaJ1VCUvB/yo8Fw7jWfHfTpStPMqOmdGV4tMkPk82+0T1bF5jU migHXrfxRg10EBryNvO1sGUNSbSxnUtgneyxAJ6oUXMlXvlg900V0tNjA TN+5++dGFSXeu6w; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1268923243; x=1300459243; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20What=20the=20IETF=20does=20and=20does=20not=20do |Date:=20Thu,=2018=20Mar=202010=2014:40:40=20+0000 |Message-ID:=20|To:=20Cullen=20Jennings =20|Cc:=20e2md@ietf.org|MIME-Version: =201.0|In-Reply-To:=20<33DFACFE-AB03-4622-B0A8-735409ADF6 62@cisco.com>|References:=20<773A981B-0F0A-4B3C-87D4-49B3 4BAF402F@cisco.com>=09<27C46C43-3BD0-44BF-A319-9B71CACFDD F3@softarmor.com>=20<33DFACFE-AB03-4622-B0A8-735409ADF662 @cisco.com>; bh=4TqLSoxkG+irmq4acPLxGkiIiIQ89Fa9cdl34YSc6Kc=; b=daNmBImuUkxg2gtZCe8S9XDYrFNgd5nb7GXs/MJUv7x27S97lnY9pb9t AF+RYRucGMhBj0DHYdptB+7XvFd6HJNlrgQ70t3TLiU0tdkOrHPwft/JM N7cP/7QuUHxYsqp; X-IronPort-AV: E=Sophos;i="4.51,267,1267401600"; d="scan'208";a="17120991" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 18 Mar 2010 14:40:42 +0000 In-Reply-To: <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> To: Cullen Jennings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 18 Mar 2010 14:40:40 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 18/03/2010 02:40:42 PM, Serialize complete at 18/03/2010 02:40:42 PM Content-Type: multipart/alternative; boundary="=_alternative 0050A10B802576EA_=" Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:40:33 -0000 This is a multipart message in MIME format. --=_alternative 0050A10B802576EA_= Content-Type: text/plain; charset="US-ASCII" > Speaking of such things, one person asked me, why use DNS at all. > Why not just do a HTTPS lookup like > > https://meta.example.com/+19725199190/cnam > > I realized I could not really answer that question. For a start: 1. it's not hierarchical - hence there's no way to divide responsibility 2. it's slower than DNS - although that's obviously still a problem if you use E2MD -> HTTP redirection 3. using DNS allows E2MD results to be delivered "for free" at the same time as E2U lookups. Ray --=_alternative 0050A10B802576EA_= Content-Type: text/html; charset="US-ASCII"
> Speaking of such things, one person asked me, why use DNS at all.
> Why not just do a HTTPS lookup like
>
> https://meta.example.com/+19725199190/cnam
>
> I realized I could not really answer that question.

For a start:

1.  it's not hierarchical

   - hence there's no way to divide responsibility

2.  it's slower than DNS

   - although that's obviously still a problem if you
     use E2MD -> HTTP redirection

3.  using DNS allows E2MD results to be delivered "for free"
    at the same time as E2U lookups.

Ray


--=_alternative 0050A10B802576EA_=-- From jim@rfc1035.com Thu Mar 18 07:45:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3BE73A6C1C for ; Thu, 18 Mar 2010 07:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywd1pqMsuEhb for ; Thu, 18 Mar 2010 07:45:31 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id E5BAC3A6C13 for ; Thu, 18 Mar 2010 07:45:30 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id D25D5154208B; Thu, 18 Mar 2010 14:45:39 +0000 (GMT) Message-Id: <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> From: Jim Reid To: Cullen Jennings In-Reply-To: <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 14:45:39 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 14:45:31 -0000 On 18 Mar 2010, at 14:29, Cullen Jennings wrote: > Speaking of such things, one person asked me, why use DNS at all. > Why not just do a HTTPS lookup like > > https://meta.example.com/+19725199190/cnam Because the overhead of setting up a TCP connection, then doing SSL authentication over it will always lose to a DNS query-response over UCP. It's not just the extra packets and latency -- a big deal in things like 3G networks where users get to pay by the packet -- but the impact on the web servers, SBCs or whatever that would get bombarded with bazillions of presumably short-lived TCP connections. From bernie@ietf.hoeneisen.ch Thu Mar 18 08:06:41 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4877E3A688F for ; Thu, 18 Mar 2010 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=-1.795, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1es-E4aLtvRq for ; Thu, 18 Mar 2010 08:06:40 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id C90283A686D for ; Thu, 18 Mar 2010 08:06:39 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NsHJA-0005g9-DO for e2md@ietf.org; Thu, 18 Mar 2010 16:06:48 +0100 Date: Thu, 18 Mar 2010 16:06:48 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Yet another charter iteration X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:06:41 -0000 Hi, Thanks again for the interesting discussions we had on- and off-list! As a result, the charter has reached a fair maturity level by now. Dean and myself have slightly adjusted the wording in the scope section of the charter, and rearranged some paragraphes. As usual, you can find the most recent version on: http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt For your convenience you can find a diff -u below. Please send any comments you might have NOW as we are finalizing the charter proposal by tonight. cheers, Bernie --- cvs diff: Diffing . Index: e2md-proposed-charter.txt =================================================================== RCS file: /var/lib/cvs/var/www/ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt,v retrieving revision 1.7 diff -u -r1.7 e2md-proposed-charter.txt --- e2md-proposed-charter.txt 16 Mar 2010 20:02:40 -0000 1.7 +++ e2md-proposed-charter.txt 18 Mar 2010 14:54:35 -0000 @@ -110,6 +110,19 @@ provide the means for data related to E.164 numbers that do not fit into the classic concept of ENUM (E2U). +Furthermore, the E2MD working group will produce guidelines for the +development and review of future proposals for E2MD service +specifications, as well as define a registration process for future +E2MD services. Until this process is in place, the E2MD working group +will act as the central point for discussion and review of proposals +for new E2MD services. + +The E2MD working group will ensure that each E2MD service +specification published follows IETF practices and, in particular, +includes a thorough Security Considerations section as defined in RFC +3552 / BCP 72 "Guidelines for Writing RFC Text on Security +Considerations". + The E2MD specifications shall reuse as much as possible from the ENUM DDDS and its IANA registry specification. Along with the E2MD DDDS application a new IANA registry will be specified for registration of @@ -125,11 +138,6 @@ transfer protocol, but rather focus on clear use cases related to E.164 numbers. -The E2MD working group will, for each specification published, follow -IETF practices and include a thorough Security Considerations section as -defined in RFC 3552 / BCP 72 "Guidelines for Writing RFC Text on -Security Considerations". - Some of the metadata standardized by E2MD may be subject to policy constraints within certain administrative jurisdictions, such as national boundaries. When such policy constraints exist, it is the @@ -141,12 +149,6 @@ particular, the E2MD working group will not address AAA issues within the E2MD framework. -A major product of the E2MD working group is to define a process and -review model for the registration of new E2MD services with -IANA. Until this process is in place, the E2MD working group will act -as the central point for discussion and review of proposals for new -E2MD services. - Goals and Milestones -------------------- From richard@shockey.us Thu Mar 18 08:16:02 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42BE53A688F for ; Thu, 18 Mar 2010 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NletRu3J5Q+0 for ; Thu, 18 Mar 2010 08:16:00 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 342A03A67D3 for ; Thu, 18 Mar 2010 08:16:00 -0700 (PDT) Received: (qmail 19132 invoked by uid 0); 18 Mar 2010 15:16:11 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 18 Mar 2010 15:16:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=KwYi4qFG2K82ZOwSii7bo4D/I+3ZbfpX3DTKm42VSKrYYwHRoiaJnEpocUGkCHz0qT+KCI3DCQCvZro5/FWuajd8USdf8gz/+j2chOvH68HMQBWsxK+cdVhshciAVEzr; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NsHSF-0001UN-H2; Thu, 18 Mar 2010 09:16:11 -0600 From: "Richard Shockey" To: "'Jim Reid'" , "'Cullen Jennings'" References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> In-Reply-To: <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> Date: Thu, 18 Mar 2010 11:16:08 -0400 Message-ID: <010e01cac6ad$f00f0b00$d02d2100$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrGqbC21I5GpYUzSPeG7w0A5IDk3AAA6Cdw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:16:02 -0000 And the vendors wont put new stacks in the proxy/softswitches. SIP and ENUM are there, they work, proven and scalable. Modifications to existing implementations are minimal. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jim Reid Sent: Thursday, March 18, 2010 10:46 AM To: Cullen Jennings Cc: e2md@ietf.org Subject: [e2md] HTTPS as an alterative to DNS lookup On 18 Mar 2010, at 14:29, Cullen Jennings wrote: > Speaking of such things, one person asked me, why use DNS at all. > Why not just do a HTTPS lookup like > > https://meta.example.com/+19725199190/cnam Because the overhead of setting up a TCP connection, then doing SSL authentication over it will always lose to a DNS query-response over UCP. It's not just the extra packets and latency -- a big deal in things like 3G networks where users get to pay by the packet -- but the impact on the web servers, SBCs or whatever that would get bombarded with bazillions of presumably short-lived TCP connections. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Thu Mar 18 08:20:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C597D3A6C27 for ; Thu, 18 Mar 2010 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.809 X-Spam-Level: X-Spam-Status: No, score=-0.809 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix9uD3IdNq94 for ; Thu, 18 Mar 2010 08:20:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6FB9C3A67D3 for ; Thu, 18 Mar 2010 08:20:49 -0700 (PDT) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IFKw6T026086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 10:20:59 -0500 Message-ID: <4BA244D4.4070107@softarmor.com> Date: Thu, 18 Mar 2010 10:20:52 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Cullen Jennings References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> In-Reply-To: <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: [e2md] why not just http? was: What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:20:55 -0000 Cullen Jennings wrote: > Speaking of such things, one person asked me, why use DNS at all. Why > not just do a HTTPS lookup like > https://meta.example.com/+19725199190/cnam > > I realized I could not really answer that question. > 1) Some of the metadata works really nicely for the cached-distribution model of the DNS. 2) we have a way to discover the local DNS server -- DHCP. 3) a centralized root HTTP would be overloaded, so some sort of distributed model is required. We could use anycast to find a server, but would still need a method for selectively propagating the data to that server. DNS already has this, called "recursive query". Yes, we could reinvent this using HTTP, at which point we are well on our way to making a new DNS based on HTTP. This might be a good idea, but it requires a different sort of buy-in. 4) The DNS model is really handy in a closed environment; change the data in the root server, and all the secondaries and caches get updated hands-free. This leads people to want to use the DNS for distributing local-knowledge data like egress SIP routes even though these data do not fit well into the public DNS topology. As a consequence of these properties combined with the fact that we are already using the DNS to answer the question "What is the SIP URI for this phone number?", the DNS appears to be well situated to answer "What (or where) are the metadata for this phone number?" The DNS appears to be much less well-suited (although in some cases useful) for answering locally-specific questions, like "What is the optimum route for me to use in order to reach this phone number?", as such queries require a selective-response capability that the DNS does not, in general, provide and which can be synthesized operationally only in very restricted environments. It does appear that a hybrid model, DNS->HTTP->metadata, could increase the range of cases wherein the system could selectively respond based on characteristics of the requester. -- dean From richard@shockey.us Thu Mar 18 08:21:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CC63A6BE3 for ; Thu, 18 Mar 2010 08:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pe10AXlEutya for ; Thu, 18 Mar 2010 08:21:48 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id AA3153A6C2C for ; Thu, 18 Mar 2010 08:21:40 -0700 (PDT) Received: (qmail 32373 invoked by uid 0); 18 Mar 2010 15:21:52 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 18 Mar 2010 15:21:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=aCF30vnDy5h7hngEFJC1q5AJ9RLVkU/3CCu/sdTRaHGn0SbliY78Iww95CNWLG0YhaPmrUNAZaEdVMkEf04QavtM05ryZz2yBWkm+R+4p37tsRMzWR4Arf0J2CCP31mh; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NsHXk-0004jk-5B; Thu, 18 Mar 2010 09:21:52 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Cullen Jennings'" References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> In-Reply-To: <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> Date: Thu, 18 Mar 2010 11:21:48 -0400 Message-ID: <010f01cac6ae$bb16e750$3144b5f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrGbUjiMmDrxMq7SQyiV/eZYaA/agAQPbSA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:21:50 -0000 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, March 18, 2010 3:32 AM To: Cullen Jennings Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do On Mar 17, 2010, at 7:37 PM, Cullen Jennings wrote: > I was hopping some useful discussion of these, or discussion of > other alternatives, might be one of the things that comes out of the > BOF. > Other alternatives I have heard so far include: 1) Encrypting the metadata; it's in the public DNS, but not compromised as reading it takes a key. Key management is the issue. RS> If people want to encrypt things that's fine put but in private deployments in the field the encryption is usually at Layer 2 or so . IP sec between network elements. 2) Putting an HTTP link to the metadata into the DNS instead of the raw metadata. The web server can then do conventional web-AAA checks to decide what to return. This has the added advantage of allowing different results to be returned based on aspects of the requestor, such as identity, location, etc. This might also work for Daryl's egress routing scenario. For example: cnam=https://meta.example.com/cnam/+19725199190 >RS There is nothing wrong with this but it cant be a requirement to use. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Thu Mar 18 08:30:45 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEEF73A635F for ; Thu, 18 Mar 2010 08:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H2R1Sbi-+GE for ; Thu, 18 Mar 2010 08:30:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7F8613A6B4C for ; Thu, 18 Mar 2010 08:30:44 -0700 (PDT) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IFUqKQ026167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 10:30:54 -0500 Message-ID: <4BA24727.4020009@softarmor.com> Date: Thu, 18 Mar 2010 10:30:47 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jim Reid References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> In-Reply-To: <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:30:45 -0000 Jim Reid wrote: > On 18 Mar 2010, at 14:29, Cullen Jennings wrote: > >> Speaking of such things, one person asked me, why use DNS at all. Why >> not just do a HTTPS lookup like >> >> https://meta.example.com/+19725199190/cnam > > Because the overhead of setting up a TCP connection, then doing SSL > authentication over it will always lose to a DNS query-response over > UCP. It's not just the extra packets and latency -- a big deal in > things like 3G networks where users get to pay by the packet -- but > the impact on the web servers, SBCs or whatever that would get > bombarded with bazillions of presumably short-lived TCP connections. > Why not have a long-lived HTTP connection to your nameserver(s), which maintains long-lived connections back upstream for recursion and shorter-lived connections to peers? Yes, it is a rewrite of DNS. Is that bad? -- dean From dean.willis@softarmor.com Thu Mar 18 08:36:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6AD3A6A40 for ; Thu, 18 Mar 2010 08:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yr4-7r4TyyM for ; Thu, 18 Mar 2010 08:36:32 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 978A53A65A6 for ; Thu, 18 Mar 2010 08:36:31 -0700 (PDT) Received: from [192.168.2.108] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IFadaG026213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 10:36:41 -0500 Message-ID: <4BA24882.7000808@softarmor.com> Date: Thu, 18 Mar 2010 10:36:34 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Richard Shockey References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> In-Reply-To: <010f01cac6ae$bb16e750$3144b5f0$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:36:33 -0000 Richard Shockey wrote: > > Other alternatives I have heard so far include: > > 1) Encrypting the metadata; it's in the public DNS, but not > compromised as reading it takes a key. Key management is the issue. > > RS> If people want to encrypt things that's fine put but in private > deployments in the field the encryption is usually at Layer 2 or so . IP sec > between network elements. > > That's fine for private deployments, but the DNS is a fairly public sort of thing. How do we solve privacy problems on the Internet? And no, DNSSEC is not an answer here. > 2) Putting an HTTP link to the metadata into the DNS instead of the > raw metadata. The web server can then do conventional web-AAA checks > to decide what to return. This has the added advantage of allowing > different results to be returned based on aspects of the requestor, > such as identity, location, etc. This might also work for Daryl's > egress routing scenario. > > For example: cnam=https://meta.example.com/cnam/+19725199190 > > > >> RS There is nothing wrong with this but it cant be a requirement to use. >> I'd see it as a fair alternative to saying "you can't put that metadata into the public DNS", so public or mixed-use DNS environments could well require a mechanism like that for sensitive metadata. -- Dean From richard@shockey.us Thu Mar 18 08:53:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2013A6974 for ; Thu, 18 Mar 2010 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bOEO8nNlPai for ; Thu, 18 Mar 2010 08:53:28 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 889D53A6940 for ; Thu, 18 Mar 2010 08:53:28 -0700 (PDT) Received: (qmail 13001 invoked by uid 0); 18 Mar 2010 15:53:40 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 18 Mar 2010 15:53:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=U9mc/a7aLPN+GjIrC/BFJfa7Kq3feZoeeqAZNG/yVQ2jsbBvDRixRURsue1AYZf0dvCj3WoPZLXyidOpzS6NgrmivlNQoUlNpbhcs1gxkwkUN+KcT9O2LxLCKKJPwCmG; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NsI2V-0008C7-UN; Thu, 18 Mar 2010 09:53:40 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Jim Reid'" References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> In-Reply-To: <4BA24727.4020009@softarmor.com> Date: Thu, 18 Mar 2010 11:53:36 -0400 Message-ID: <014001cac6b3$2c34e4b0$849eae10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrGsAJhRcaDpdyMSzW7tVtF+NqFRAAAxt5g Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:53:30 -0000 > Because the overhead of setting up a TCP connection, then doing SSL > authentication over it will always lose to a DNS query-response over > UCP. It's not just the extra packets and latency -- a big deal in > things like 3G networks where users get to pay by the packet -- but > the impact on the web servers, SBCs or whatever that would get > bombarded with bazillions of presumably short-lived TCP connections. > Why not have a long-lived HTTP connection to your nameserver(s), which maintains long-lived connections back upstream for recursion and shorter-lived connections to peers? Yes, it is a rewrite of DNS. Is that bad? RS> NO IMHO it just wont deploy. -- dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From jim@rfc1035.com Thu Mar 18 08:53:39 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B10663A6A6F for ; Thu, 18 Mar 2010 08:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP7HlJ3u51s8 for ; Thu, 18 Mar 2010 08:53:39 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id CC9FA3A6974 for ; Thu, 18 Mar 2010 08:53:38 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 8C033154208B; Thu, 18 Mar 2010 15:53:48 +0000 (GMT) Message-Id: <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BA24727.4020009@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 15:53:48 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:53:39 -0000 On 18 Mar 2010, at 15:30, Dean Willis wrote: > Why not have a long-lived HTTP connection to your nameserver(s), which > maintains long-lived connections back upstream for recursion and > shorter-lived connections to peers? I'm not sure I understand you. Why would this hypothetical HTTP- capable name server need to maintain a long-lived connection to an upstream resolver? Surely it would resolve things for itself? And what do you mean by a connection to a peer? What would this HTTP-capable name server be connecting to and why? > Yes, it is a rewrite of DNS. Is that bad? Yes. Very bad. Very, very bad. DNS is too deeply embedded in the guts of the Internet to undergo a radical rewrite or the mother of all flag days. And anyway long-lived connections are not going to work particularly well for devices which move around the network by design. From richard@shockey.us Thu Mar 18 08:56:59 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 023DE3A6C6D for ; Thu, 18 Mar 2010 08:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4pwk74wGXUq for ; Thu, 18 Mar 2010 08:56:58 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 753C53A6C59 for ; Thu, 18 Mar 2010 08:56:56 -0700 (PDT) Received: (qmail 32561 invoked by uid 0); 18 Mar 2010 15:57:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 18 Mar 2010 15:57:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=gItUVyXLtdO4ZJAtOMm1u2P44AUytwdzvq/aU4UmFRcid+9J9zeQ/szDl2ivlGKv2vfJv3OTyjOg0EzzVKVhSiwWmznozC0kwcHyK8uEI4AzARCDIEB8nFZRKwGoT0Ra; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NsI5q-0001ub-T1; Thu, 18 Mar 2010 09:57:07 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Cullen Jennings'" , "'Hadriel Kaplan'" References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <4BA244D4.4070107@softarmor.com> In-Reply-To: <4BA244D4.4070107@softarmor.com> Date: Thu, 18 Mar 2010 11:57:03 -0400 Message-ID: <014101cac6b3$a79054a0$f6b0fde0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrGrqUZPjsgH9A/SXiOcpe+24u5yQABMUxA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] why not just http? was: What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:56:59 -0000 As a consequence of these properties combined with the fact that we are already using the DNS to answer the question "What is the SIP URI for this phone number?", the DNS appears to be well situated to answer "What (or where) are the metadata for this phone number?" The DNS appears to be much less well-suited (although in some cases useful) for answering locally-specific questions, like "What is the optimum route for me to use in order to reach this phone number?", as such queries require a selective-response capability that the DNS does not, in general, provide and which can be synthesized operationally only in very restricted environments. It does appear that a hybrid model, DNS->HTTP->metadata, could increase the range of cases wherein the system could selectively respond based on characteristics of the requester. RS> you could do it in ENUM if Hadriel Kaplan's source URI draft were adopted. So Hadriel what is the status of that draft? :-) -- dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From jim@rfc1035.com Thu Mar 18 08:57:48 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5121D3A6911 for ; Thu, 18 Mar 2010 08:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwKCKTHUbjgN for ; Thu, 18 Mar 2010 08:57:47 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id BD7833A6C30 for ; Thu, 18 Mar 2010 08:57:45 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id ED276154208B; Thu, 18 Mar 2010 15:57:55 +0000 (GMT) Message-Id: <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BA24882.7000808@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 15:57:55 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 15:57:48 -0000 On 18 Mar 2010, at 15:36, Dean Willis wrote: > That's fine for private deployments, but the DNS is a fairly public > sort > of thing. How do we solve privacy problems on the Internet? That's like asking how do we solve world hunger. It's out of scope for this list/WG. It is possible to safely publish private data in the public DNS. Public key crypto is being used in .tel to encrypt NAPTRs as data URIs. From richard@shockey.us Thu Mar 18 09:00:17 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71593A699D for ; Thu, 18 Mar 2010 09:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.472 X-Spam-Level: X-Spam-Status: No, score=-0.472 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjX44EMZG23l for ; Thu, 18 Mar 2010 09:00:16 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 4E7A53A6BFA for ; Thu, 18 Mar 2010 09:00:13 -0700 (PDT) Received: (qmail 5337 invoked by uid 0); 18 Mar 2010 16:00:25 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 18 Mar 2010 16:00:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=kp5daBrTJSt/R0mSH7GEutsvBXGe7l+aerW+4AqIuLLLG9r5ux6YzhJMSUbPAENVNiB5d2q5eq/TLk08TrQA+5DuS84RUtyzPk7fHQhobPCTZsSXTN7HtP4+EheBR00h; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NsI92-0003rv-UL; Thu, 18 Mar 2010 10:00:25 -0600 From: "Richard Shockey" To: "'Dean Willis'" References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> In-Reply-To: <4BA24882.7000808@softarmor.com> Date: Thu, 18 Mar 2010 12:00:21 -0400 Message-ID: <014201cac6b4$1d99ebc0$58cdc340$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrGsNCdDBB6TOAIQPC6JMn8z/EJrgAAuiUw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 16:00:17 -0000 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, March 18, 2010 11:37 AM To: Richard Shockey Cc: 'Cullen Jennings'; e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do Richard Shockey wrote: > > Other alternatives I have heard so far include: > > 1) Encrypting the metadata; it's in the public DNS, but not > compromised as reading it takes a key. Key management is the issue. > > RS> If people want to encrypt things that's fine put but in private > deployments in the field the encryption is usually at Layer 2 or so . IP sec > between network elements. > > That's fine for private deployments, but the DNS is a fairly public sort of thing. How do we solve privacy problems on the Internet? RS> RATHOLE ALERT RATHOLE ALERT RATHOLE ALERT :-) How do we solve privacy problems on the Internet...humm just think about that for a moment. :-) And no, DNSSEC is not an answer here. > 2) Putting an HTTP link to the metadata into the DNS instead of the > raw metadata. The web server can then do conventional web-AAA checks > to decide what to return. This has the added advantage of allowing > different results to be returned based on aspects of the requestor, > such as identity, location, etc. This might also work for Daryl's > egress routing scenario. > > For example: cnam=https://meta.example.com/cnam/+19725199190 > > > >> RS There is nothing wrong with this but it cant be a requirement to use. >> I'd see it as a fair alternative to saying "you can't put that metadata into the public DNS", so public or mixed-use DNS environments could well require a mechanism like that for sensitive metadata. Rs I'd rather say .."you really sholdn't put that data in the public DNS" or a bunch of guys in dark suits and big Chevrolet Suburbans are going to come and get you. -- Dean From dean.willis@softarmor.com Thu Mar 18 12:29:22 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13B13A68A8 for ; Thu, 18 Mar 2010 12:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-1.601, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p-oW8J6c3nK for ; Thu, 18 Mar 2010 12:29:22 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 303CC3A686D for ; Thu, 18 Mar 2010 12:29:22 -0700 (PDT) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IJTUkU028467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 14:29:32 -0500 Message-ID: <4BA27F15.1060702@softarmor.com> Date: Thu, 18 Mar 2010 14:29:25 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Richard Shockey References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <014001cac6b3$2c34e4b0$849eae10$@us> In-Reply-To: <014001cac6b3$2c34e4b0$849eae10$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 19:29:23 -0000 Richard Shockey wrote: >> Because the overhead of setting up a TCP connection, then doing SSL >> authentication over it will always lose to a DNS query-response over >> UCP. It's not just the extra packets and latency -- a big deal in >> things like 3G networks where users get to pay by the packet -- but >> the impact on the web servers, SBCs or whatever that would get >> bombarded with bazillions of presumably short-lived TCP connections. >> >> > Why not have a long-lived HTTP connection to your nameserver(s), which > maintains long-lived connections back upstream for recursion and > shorter-lived connections to peers? Yes, it is a rewrite of DNS. Is that > bad? > > > RS> NO IMHO it just wont deploy. > > -- That's what everybody said about TCP based presence and IM systems, and they seem to work pretty well. -- Dean From jay@nzrs.net.nz Thu Mar 18 12:35:15 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC3C3A69B2 for ; Thu, 18 Mar 2010 12:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[AWL=-1.368, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkT0HnszAIkU for ; Thu, 18 Mar 2010 12:35:14 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id BB8FF3A67B4 for ; Thu, 18 Mar 2010 12:35:14 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id F187E2DB118; Fri, 19 Mar 2010 08:35:25 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeUdPcEfVUXd; Fri, 19 Mar 2010 08:35:25 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 899B82DAAAC; Fri, 19 Mar 2010 08:35:25 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <4BA27F15.1060702@softarmor.com> Date: Fri, 19 Mar 2010 08:35:24 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <014001cac6b3$2c34e4b0$849eae10$@us> <4BA27F15.1060702@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 19:35:15 -0000 On 19/03/2010, at 8:29 AM, Dean Willis wrote: >> Why not have a long-lived HTTP connection to your nameserver(s), = which >> maintains long-lived connections back upstream for recursion and >> shorter-lived connections to peers? Yes, it is a rewrite of DNS. Is = that >> bad? >>=20 >>=20 >> RS> NO IMHO it just wont deploy. >>=20 >> -- >=20 > That's what everybody said about TCP based presence and IM systems, = and > they seem to work pretty well. That is completely and utterly different!=20 Of all the protocols out there DNS is probably the most scrutinised, the = one where changes get the most input and the most carefully changed. = You can't just suggest a rewrite of DNS on a whim and expect to be taken = seriously.=20 Jay=20 >=20 > -- > Dean >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Thu Mar 18 12:46:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2383A6808 for ; Thu, 18 Mar 2010 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFknHXxHiGJo for ; Thu, 18 Mar 2010 12:46:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 17D043A65A6 for ; Thu, 18 Mar 2010 12:46:27 -0700 (PDT) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IJjtAx028677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 14:45:57 -0500 Message-ID: <4BA282EE.6060405@softarmor.com> Date: Thu, 18 Mar 2010 14:45:50 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jim Reid References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> In-Reply-To: <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 19:46:28 -0000 Jim Reid wrote: > On 18 Mar 2010, at 15:30, Dean Willis wrote: > >> Why not have a long-lived HTTP connection to your nameserver(s), which >> maintains long-lived connections back upstream for recursion and >> shorter-lived connections to peers? > > I'm not sure I understand you. Why would this hypothetical HTTP-capable > name server need to maintain a long-lived connection to an upstream > resolver? Surely it would resolve things for itself? And what do you > mean by a connection to a peer? What would this HTTP-capable name server > be connecting to and why? A name server can only resolve things for itself that it is either authoritative for (primary or secondary) or that has cached. It has to go upstream occasionally. For example, the NS for subdoomain "research.softarmor.com" frequently talks to the NS for domain "softarmor.com". Why wouldn't a long-lived connection work here? Similarly, once "research.softarmor.com" has used "softarmor.com" to find "marketing.softarmor.com", it may well connect directly to "marketing.softarmor.com" to find the IP address for URI "sip:bob@bob.marketing.softarmor.com". My guess is that it "research" talks to "marketing" fairly frequently (or at least their name servers do). Why wouldn't an HTTP connection work here? Another way to model this is a straight-up port of current DNS, with zone transfers being simple HTTP GET requests on the zone files, etc. wherein the HTTP layer is tuned to hold up the TCP connection "as long as reasonable", for which there are several evident mechanisms. > >> Yes, it is a rewrite of DNS. Is that bad? > > Yes. Very bad. Very, very bad. DNS is too deeply embedded in the guts of > the Internet to undergo a radical rewrite or the mother of all flag > days. And anyway long-lived connections are not going to work > particularly well for devices which move around the network by design. > ENUM and metadata aren't all that entrenched. And the hacks that we keep making with longer and longer resource records, along with other hacks to return requester-specific data, etc. are going to give those guts a bad case of indigestion if we're not careful. Also, there's no reason a migration to HTTP couldn't happen in a backward-compatible manner. It would be pretty straightforward to build a server that works in both modes, and then use a modifier at the NS level to indicate support for the new protocol at the server. New protocol systems would talk to new protocol systems using the new protocol, and everybody else would use the crufty old DNS we know and love. Although once again: this would be outside the scope of E2MD, which is still the fundamental answer to Cullen's question if the "we involved is E2MD. -- Dean -- dean From dean.willis@softarmor.com Thu Mar 18 12:55:45 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C4F33A6B62 for ; Thu, 18 Mar 2010 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXf51yoxvXqT for ; Thu, 18 Mar 2010 12:55:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8E4323A6A87 for ; Thu, 18 Mar 2010 12:55:44 -0700 (PDT) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IJtss1028740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 14:55:56 -0500 Message-ID: <4BA28545.1020901@softarmor.com> Date: Thu, 18 Mar 2010 14:55:49 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jim Reid References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> In-Reply-To: <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 19:55:45 -0000 Jim Reid wrote: > On 18 Mar 2010, at 15:36, Dean Willis wrote: > >> That's fine for private deployments, but the DNS is a fairly public sort >> of thing. How do we solve privacy problems on the Internet? > > That's like asking how do we solve world hunger. It's out of scope for > this list/WG. Okay, I'll restate. How do WE (the E2MD group) solve privacy problems for the metadata we're proposing to shove into the DNS, when that DNS is used on the Internet? > > It is possible to safely publish private data in the public DNS. Public > key crypto is being used in .tel to encrypt NAPTRs as data URIs. > Excellent! That's an answer to the question "how do we solve privacy problems for dns-delivered metadata on the Internet. Is this answer (or something like it for metadata that is not a URI) acceptable for consideration in the E2MD process, or are we just going to say "if there is sensitive data in your records, just use a private network and for your private DNS, and don't blame us if it leaks" Look, I'm not trying to be obtuse and say we can't solve the problem and therefore must not even try. There are several potential solutions. I'm saying we have to RECOGNIZE that there is a problem (step 1 of 12, right?), see if we can agree what that problem generally is, and plan to come up with a problem statement along with one or more solutions in that problem space. I don't even want a final solution now (unless one is blindingly obvious) -- I just want people to understand that this is part of the problem that we need to work on, and to commit to doing that work if the WG is approved. -- Dean From dean.willis@softarmor.com Thu Mar 18 13:03:38 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA87C3A6BA8 for ; Thu, 18 Mar 2010 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-1.548, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvRuC8SXWOQf for ; Thu, 18 Mar 2010 13:03:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6D2A03A6BAC for ; Thu, 18 Mar 2010 13:03:37 -0700 (PDT) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IK3kOM028829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 15:03:47 -0500 Message-ID: <4BA2871C.5040504@softarmor.com> Date: Thu, 18 Mar 2010 15:03:40 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Richard Shockey References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <014201cac6b4$1d99ebc0$58cdc340$@us> In-Reply-To: <014201cac6b4$1d99ebc0$58cdc340$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 20:03:38 -0000 Richard Shockey wrote: > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] >> That's fine for private deployments, but the DNS is a fairly public sort >> of thing. How do we solve privacy problems on the Internet? > > > RS> RATHOLE ALERT RATHOLE ALERT RATHOLE ALERT :-) How do we solve privacy > problems on the Internet...humm just think about that for a moment. :-) > C'mon Richard. You know that we were talking about the privacy of ENUM metadata, not solving the Internet's privacy problem as a hole. That's a cheap shot, so I think you owe me a not-so-cheap shot from the hotel bar! > Rs I'd rather say .."you really sholdn't put that data in the public DNS" or > a bunch of guys in dark suits and big Chevrolet Suburbans are going to come > and get you. Ok, that's a possible answer, too. It does raise the question of why the IETF is standardizing data that can't be put on the Internet, but at least it recognizes the problem. It does leave the question "What advice do we give to people about deciding which data should and should not be put unprotected on the real Internet". And it leaves the question of where to record that advice, as well as who records it. I'm thinking that the advice is important, and that the proposed WG needs to decide what advice to give and needs to document that advice in an RFC as part of our work product. -- dean From jay@nzrs.net.nz Thu Mar 18 13:04:53 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6BA3A65A6 for ; Thu, 18 Mar 2010 13:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.483 X-Spam-Level: X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDcng8kjIdl2 for ; Thu, 18 Mar 2010 13:04:52 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id DCAC93A63D3 for ; Thu, 18 Mar 2010 13:04:51 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 36BD02DAAAD; Fri, 19 Mar 2010 09:05:03 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWa4UEMsYuil; Fri, 19 Mar 2010 09:05:03 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 9370F2DA530; Fri, 19 Mar 2010 09:05:02 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> Date: Fri, 19 Mar 2010 09:05:02 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 20:04:53 -0000 On 18/03/2010, at 1:37 PM, Cullen Jennings wrote: > Charters are one of the things that define what the IETF is doing and = also what is out of scope for any WG to do. Regardless of what we have = done with ENUM, DNS, and others in the past, part of the purpose of this = BOF would be to see if we can get consensus on what we want to do in the = future. I would be surprised to see people willing to just ignore any = privacy issues. It seems the two leading proposal for dealing with the = privacy issues could roughly be categorized as 1) don't put private = things in DNS or 2) don't allow the DNS out of a private space. That hasn't captured it at all. The various views are: 1. Putting private data in DNS automatically means it cannot go into a = public tree making this a private protocol and therefore out of scope = for the IETF. 2. There are mechanisms to obscure private data that could be used such = as encryption or indirection. 3. The data we are talking about may or may not be private that depends = on the legal status of the subscriber and the laws of local = jurisdictions not on the data per se and so the protocol should allow = that differentiation to be flagged in the data but leave the = appropriateness of publishing what might be classed as private data to = the local jurisdiction. 4. The privacy issues faced by e2md are entirely the same as ENUM and = so can simply pull over the wording and reasoning from there. 5. The privacy issues faced by e2md are qualitatively different from = ENUM because of the nature of the data. > Both of these have pros/cons. I was hopping some useful discussion of = these, or discussion of other alternatives, might be one of the things = that comes out of the BOF. I would suggest that a logical path needs to be worked through rather = than the "statement of belief" tennis we are currently engaged in. My = suggestion is: Q1. Is the nature of the data proposed for e2md different from the data = in ENUM such that it should have different privacy considerations? If the answer is no then we can just pull over the wording and reasoning = from ENUM (p1), if it is yes then we move onto question 2. Q2. Is the data always private or is that down to externalities to the = protocol, such as the legal status of a subscriber? If the answer is always private then it implies we *must* have = mechanisms to obscure data that *must* be used otherwise this becomes a = private protocol (p2). =20 If the answer is that externalities determine what is private then we = move onto question 3. Q3. Is it sufficient that the protocol acknowledges that the result of = privacy protection for certain subscribers is the omission of their data = (and that it flags that as the reason) or should we provide an obscuring = mechanism to allow that data to be included? If the answer is that omission is sufficient then the scope stops there = (p3). If we should accommodate publication of the data in an obscured = way then we will get to the scope that includes that (p4). My personal view is that we should be at p1 but I can live with getting = to p4 as a compromise. regards Jay=20 >=20 > Cullen >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Thu Mar 18 13:22:56 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CEC23A6ADA for ; Thu, 18 Mar 2010 13:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-1.530, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8i8v6ON-N18 for ; Thu, 18 Mar 2010 13:22:55 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 97DF53A6916 for ; Thu, 18 Mar 2010 13:22:52 -0700 (PDT) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2IKN1RU028987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Mar 2010 15:23:03 -0500 Message-ID: <4BA28BA0.1070207@softarmor.com> Date: Thu, 18 Mar 2010 15:22:56 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jay Daley References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 20:22:58 -0000 This is excellent work! Jay Daley wrote: > Q1. Is the nature of the data proposed for e2md different from the > data in ENUM such that it should have different privacy > considerations? > > If the answer is no then we can just pull over the wording and > reasoning from ENUM (p1), if it is yes then we move onto question 2. > I believe the answer is "yes", at least for some of the metadata. For example, putting the calling name for my unlisted phone number into the DNS is clearly a different thing than is listing the SIP URI at which I prefer those calls to be routed by. > Q2. Is the data always private or is that down to externalities to > the protocol, such as the legal status of a subscriber? Excellent question; one might reasonably include externalities that relate not to the subscriber, but the consumer of the metadata. I believe that not all metadata is always private. Some might be always private, but certain elements such as "unused" are clearly interesting at a public scale. And there IS a big furball around status of the subscriber. For example, many legal domains restrict information about minors. > > If the answer is always private then it implies we *must* have > mechanisms to obscure data that *must* be used otherwise this becomes > a private protocol (p2). > > If the answer is that externalities determine what is private then we > move onto question 3. > > Q3. Is it sufficient that the protocol acknowledges that the result > of privacy protection for certain subscribers is the omission of > their data (and that it flags that as the reason) or should we > provide an obscuring mechanism to allow that data to be included? We may also need to address privacy protection affecting certain consumers of the data rather than the subscriber. For example, one might wish to obscure parts of metadata across one peering relationship, but not another. Or an operator might consider part of the metadata private with respect to the general public, but authorize access to that same part for diagnostic and law enforcement purposes. But please, please do not let me turn this into a repeat of the redistribution-allowed fight in GEOPRIV. -- dean From fluffy@cisco.com Thu Mar 18 13:56:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6A03A6BCA for ; Thu, 18 Mar 2010 13:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.696 X-Spam-Level: X-Spam-Status: No, score=-109.696 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUhaouiorGZ2 for ; Thu, 18 Mar 2010 13:56:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6EAAD3A69EC for ; Thu, 18 Mar 2010 13:56:17 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPIwokurR7Ht/2dsb2JhbACbLHOjDZkDhHkEgx0 X-IronPort-AV: E=Sophos;i="4.51,269,1267401600"; d="scan'208";a="309955414" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 18 Mar 2010 20:56:29 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2IKuSmG020919; Thu, 18 Mar 2010 20:56:29 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 18 Mar 2010 14:56:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <58B44719-9D31-4E0D-872C-F6CAF6B3F410@cisco.com> References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 20:56:19 -0000 Thanks Ray,=20 So just to make sure I am understanding the deployments correctly for = the E2MD data, the hierarchal is important because in the practical = deployments will have a bunch of different administrative domains that = are responsible for metadata for different numbers. On Mar 18, 2010, at 8:40 AM, Ray.Bellis@nominet.org.uk wrote: >=20 > > Speaking of such things, one person asked me, why use DNS at all.=20 > > Why not just do a HTTPS lookup like > >=20 > > https://meta.example.com/+19725199190/cnam=20 > >=20 > > I realized I could not really answer that question.=20 >=20 > For a start:=20 >=20 > 1. it's not hierarchical=20 >=20 > - hence there's no way to divide responsibility=20 >=20 > 2. it's slower than DNS=20 >=20 > - although that's obviously still a problem if you=20 > use E2MD -> HTTP redirection=20 >=20 > 3. using DNS allows E2MD results to be delivered "for free"=20 > at the same time as E2U lookups.=20 >=20 > Ray=20 >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Thu Mar 18 13:56:25 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8433B3A6C05 for ; Thu, 18 Mar 2010 13:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.692 X-Spam-Level: X-Spam-Status: No, score=-109.692 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwCmocysfhkk for ; Thu, 18 Mar 2010 13:56:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CEE8C3A69EC for ; Thu, 18 Mar 2010 13:56:24 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPIwokurR7Ht/2dsb2JhbACbLHOjDZkDhHkEgx0 X-IronPort-AV: E=Sophos;i="4.51,269,1267401600"; d="scan'208";a="309955464" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 18 Mar 2010 20:56:36 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2IKuSmH020919; Thu, 18 Mar 2010 20:56:36 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> Date: Thu, 18 Mar 2010 14:56:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 20:56:25 -0000 Thanks Jim So making sure I understand the requirement here ... we need to be able = to lookup the metadata from an end users phone or terminal? Clearly if = we it was only needed from the call agents or SBC in the middle of the = network, long lived connections would work fine. (I realize we also need = to be able to make metadata queries from the call agents, SBC, etc. ) Do = I have the right understanding here? On Mar 18, 2010, at 8:45 AM, Jim Reid wrote: > On 18 Mar 2010, at 14:29, Cullen Jennings wrote: >=20 >> Speaking of such things, one person asked me, why use DNS at all. Why = not just do a HTTPS lookup like >>=20 >> https://meta.example.com/+19725199190/cnam >=20 > Because the overhead of setting up a TCP connection, then doing SSL = authentication over it will always lose to a DNS query-response over = UCP. It's not just the extra packets and latency -- a big deal in things = like 3G networks where users get to pay by the packet -- but the impact = on the web servers, SBCs or whatever that would get bombarded with = bazillions of presumably short-lived TCP connections. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From lconroy@insensate.co.uk Thu Mar 18 13:58:32 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF6C3A6BCA for ; Thu, 18 Mar 2010 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VE4G-OksiJns for ; Thu, 18 Mar 2010 13:58:30 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 2604C3A69EC for ; Thu, 18 Mar 2010 13:58:30 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 3B660117AF5; Thu, 18 Mar 2010 20:58:41 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <4BA282EE.6060405@softarmor.com> Date: Thu, 18 Mar 2010 20:58:41 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> <4BA282EE.6060405@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 20:58:32 -0000 Hi again Dean, Jim, folks, Apart from the traditionally mistaken dig at ENUM, what is this about? I get this impression this is WAAAAAAAY too unfocussed for what should be a "small bite". I expect to see implementations of what was proposed in the charter out the door by the end of this year. This stuff is a very close fit to DNS usage patterns. Data doesn't change often, it's a huge database with distributed control, and it needs the performance that would p**s all over any secure web set up. No surprise that this stuff is intending to use DNS (and steal all the work already done on ENUM). All very focussed. Dean, Cullen, I get that you believe there are security issues. I also get everyone else saying that they know there are security issues with every piece of sensitive data placed into DNS (or anywhere else on the Interwebs). I expect them to do as they have already said they will, and note this in big friendly letters on the front cover of each document. Just like we all did in ENUM. Any more than that is Country-specific PII/DP **POLICY**, and doing anything more than a general advisory to not put your current location in your domain (or the front page of facebook) is not the IETF's job. ENUM did all it could in that direction, and I see no signs that E2MD has succumbed to the Web 2.0 view of privacy. I suspect that implied accusation is what rankles some of us -- we DO know about this and we DO warn folk. We have to deal with Governments and their separate and randomly whacky views on what IS required/banned/optional depending on who's asking/... So why do I still see examples of a fluffy cloud that seems to be enveloping this stuff? - For those of you with a life (and not on all the other MLs), Dean seems to be re-inventing the ideas on a new transport for DNS (using SCTP). Why long-lived connections via HTTPS? Because it's there, I guess, and because the expertise in DNSEXT (and the "the purgatory of TCPM") is not considered. I *hope* the intent is NOT to try to provide an alternative take on "DNS-NG" -- as Jay says, that is for another bunch who can, do, and will grind exceedingly small on any such change to DNS. [For the joy of that discussion so far, search namedroppers for SCTP or TCP] - I also note what looks like an attempt to introduce general privacy controls into the DNS. Again, that's dnsext's job if it's anyone's. [For the narrow ENUM/E2MD take on controls, Jim's already said that he needs to look at x-crypto again -- brave man]. Me, I want to get this stuff out the door in an agreed form -- otherwise it will be another piece of data to put in TXT records and x-services. This is not, I hope, a Cult. We now return you to a discussion of the things we hope to standardise. all the best, Lawrence On 18 Mar 2010, at 19:45, Dean Willis wrote: > Jim Reid wrote: >> On 18 Mar 2010, at 15:30, Dean Willis wrote: >> >>> Why not have a long-lived HTTP connection to your nameserver(s), which >>> maintains long-lived connections back upstream for recursion and >>> shorter-lived connections to peers? >> >> I'm not sure I understand you. Why would this hypothetical HTTP-capable >> name server need to maintain a long-lived connection to an upstream >> resolver? Surely it would resolve things for itself? And what do you >> mean by a connection to a peer? What would this HTTP-capable name server >> be connecting to and why? > > A name server can only resolve things for itself that it is either > authoritative for (primary or secondary) or that has cached. It has to > go upstream occasionally. For example, the NS for subdoomain > "research.softarmor.com" frequently talks to the NS for domain > "softarmor.com". Why wouldn't a long-lived connection work here? > > Similarly, once "research.softarmor.com" has used "softarmor.com" to > find "marketing.softarmor.com", it may well connect directly to > "marketing.softarmor.com" to find the IP address for URI > "sip:bob@bob.marketing.softarmor.com". My guess is that it "research" > talks to "marketing" fairly frequently (or at least their name servers > do). Why wouldn't an HTTP connection work here? > > Another way to model this is a straight-up port of current DNS, with > zone transfers being simple HTTP GET requests on the zone files, etc. > wherein the HTTP layer is tuned to hold up the TCP connection "as long > as reasonable", for which there are several evident mechanisms. > >> >>> Yes, it is a rewrite of DNS. Is that bad? >> >> Yes. Very bad. Very, very bad. DNS is too deeply embedded in the guts of >> the Internet to undergo a radical rewrite or the mother of all flag >> days. And anyway long-lived connections are not going to work >> particularly well for devices which move around the network by design. >> > > ENUM and metadata aren't all that entrenched. And the hacks that we keep > making with longer and longer resource records, along with other hacks > to return requester-specific data, etc. are going to give those guts a > bad case of indigestion if we're not careful. > > Also, there's no reason a migration to HTTP couldn't happen in a > backward-compatible manner. It would be pretty straightforward to build > a server that works in both modes, and then use a modifier at the NS > level to indicate support for the new protocol at the server. New > protocol systems would talk to new protocol systems using the new > protocol, and everybody else would use the crufty old DNS we know and love. > > Although once again: this would be outside the scope of E2MD, which is > still the fundamental answer to Cullen's question if the "we involved is > E2MD. > > -- > Dean > > -- > dean > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From jim@rfc1035.com Thu Mar 18 14:17:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A65B3A6900 for ; Thu, 18 Mar 2010 14:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHKuYnexk2Z4 for ; Thu, 18 Mar 2010 14:17:33 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 99EAB3A6968 for ; Thu, 18 Mar 2010 14:17:32 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 7FE9B154208B; Thu, 18 Mar 2010 21:17:42 +0000 (GMT) Message-Id: <796B7B6C-4435-4015-8AFE-26042261F43D@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BA282EE.6060405@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 21:17:42 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> <4BA282EE.6060405@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 21:17:34 -0000 On 18 Mar 2010, at 19:45, Dean Willis wrote: > A name server can only resolve things for itself that it is either > authoritative for (primary or secondary) or that has cached. Nope. Resolution is the process of making iterative queries starting at some place in the tree until an authoritative server provides the answer to some query. Authoritative servers don't have to resolve anything. Some implementations of these don't even have code to *make* queries. By implication, these don't have caches either. A name server can answer a query when (a) it is authoritative for the zone in question; (b) has cached the answer from an earlier lookup it made; (c) resolves the query from a client my making iterative queries to other servers. The choice of (a), (b) or (c) (or some combination of these) is down to local policy and configuration. > It has to go upstream occasionally. For example, the NS for subdoomain > "research.softarmor.com" frequently talks to the NS for domain > "softarmor.com". The DNS doesn't work that way. Sorry. If it did, it would mean every authoritative name server would be in regular contact with those for its parent zones. And so on. They're not. An authoritative name server doesn't have to talk to any other name server. It only has to answer queries. > Why wouldn't a long-lived connection work here? See above. There's no reason why a name server for research.softarmor.com would need to ever speak to a name server for softarmor.com. The softarmor.com servers don't speak to the .com name servers. And the .com name servers don't speak to the root name servers. > Similarly, once "research.softarmor.com" has used "softarmor.com" to > find "marketing.softarmor.com", it may well connect directly to > "marketing.softarmor.com" to find the IP address for URI > "sip:bob@bob.marketing.softarmor.com". My guess is that it "research" > talks to "marketing" fairly frequently (or at least their name servers > do). Why wouldn't an HTTP connection work here? Let's assume that DNS works the way you've guessed. [It doesn't.] How many long-lived TCP connections is the name server for research.softarmor.com going to maintain? How will it choose between them when it runs out of file descriptors? It's not easy to model DNS traffic in the same way as say HTTP because DNS lookups regularly entail diversions into lookups in other domains. ie to resolve A, the server needs to resolve B, C & D to get to the name servers of E, F & G to find the addresses of the name servers for A. Try doing a dig +trace on some domain name to see what's really going on when a name gets resolved. You'll be surprised. > Another way to model this is a straight-up port of current DNS, with > zone transfers being simple HTTP GET requests on the zone files, etc. > wherein the HTTP layer is tuned to hold up the TCP connection "as long > as reasonable", for which there are several evident mechanisms. Dean, this is truly bizarre. For many zones these days, there is no "zone file" any more: there's a real database holding the zone data. And many folk don't allow copies of their zones to be slurped by axfr (or HTTP GETs in your model) for all sorts of reasons, some sensible, others stupid... I wonder if you've thought this through. The Internet would collapse -- as would the .com name servers -- if every lookup for a name in the .com domain meant pulling down the 4GB or so of .com "zone file". One of the design goals of the DNS is to save every host on the net from knowing about everything in the name space. [That's why the ARPAnet gave up on hosts.txt 25 years ago.] Your proposal violates that. It simply won't scale. From jim@rfc1035.com Thu Mar 18 14:37:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644B93A6BA8 for ; Thu, 18 Mar 2010 14:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.046 X-Spam-Level: X-Spam-Status: No, score=-0.046 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV7ZkFT32zl2 for ; Thu, 18 Mar 2010 14:37:30 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 77E6B3A69F0 for ; Thu, 18 Mar 2010 14:37:30 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 0B13A154208B; Thu, 18 Mar 2010 21:37:41 +0000 (GMT) Message-Id: <650A33F3-2799-4E2A-A903-785ADFE887F0@rfc1035.com> From: Jim Reid To: Cullen Jennings In-Reply-To: <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 21:37:40 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 21:37:31 -0000 On 18 Mar 2010, at 20:56, Cullen Jennings wrote: > So making sure I understand the requirement here ... we need to be > able to lookup the metadata from an end users phone or terminal? Well we (for some definition of "we") should not make assumptions about what will or won't lookup metadata if that results in coming up with something that can't be made to scale. DNS over long-lived TCP connections (or something that mimics that) has those inherent limitations. There are good reasons why almost all DNS traffic goes over UDP. And why web server generally don't like to maintain long- lived TCP connections from their clients. > Clearly if we it was only needed from the call agents or SBC in the > middle of the network, long lived connections would work fine. I don't think so. How many SBCs and call agents will the typical operator have? Long-lived connections between 'em is an N-squared probem. That gives me the heebie-jeebies. Keeping state and coherency across this matrix will be difficult and perhaps impossible when N is large. Then there are the interconnects between each operator's SBCs (or equivalent). Which begins to smell like an N-cubed problem. I'm not sure there's any point continuing this thread. Dean's (throwaway?) idea of displacing DNS with HTTPS seems to have emerged from a misunderstanding of how DNS works. So it may be better to climb out of this rat-hole now instead of carry on digging. From jim@rfc1035.com Thu Mar 18 14:46:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB5A3A6857 for ; Thu, 18 Mar 2010 14:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEccvS4nkGTI for ; Thu, 18 Mar 2010 14:46:54 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 5BA433A680B for ; Thu, 18 Mar 2010 14:46:54 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id E3C39154208B; Thu, 18 Mar 2010 21:47:04 +0000 (GMT) Message-Id: From: Jim Reid To: Dean Willis In-Reply-To: <4BA28545.1020901@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 21:47:04 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> <4BA28545.1020901@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 21:46:55 -0000 On 18 Mar 2010, at 19:55, Dean Willis wrote: >> It is possible to safely publish private data in the public DNS. >> Public >> key crypto is being used in .tel to encrypt NAPTRs as data URIs. >> > > Excellent! That's an answer to the question "how do we solve privacy > problems for dns-delivered metadata on the Internet. Is this answer > (or > something like it for metadata that is not a URI) acceptable for > consideration in the E2MD process I think it could be. For the E2MD process, just define a suitable NAPTR service type and a data URI and we're done. Or if this list would be prepared to run with http://tools.ietf.org/html/draft-timms-encrypt-naptr-01 we're already done. :-) The issues of managing keys and provisioning the encrypted NAPTRs is of course left as an exercise for the reader. :-) From richard@shockey.us Thu Mar 18 17:50:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62D903A6C46 for ; Thu, 18 Mar 2010 17:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.071 X-Spam-Level: X-Spam-Status: No, score=-0.071 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaWXX+fdn6Ra for ; Thu, 18 Mar 2010 17:50:54 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 3F6DC3A6C3C for ; Thu, 18 Mar 2010 17:50:54 -0700 (PDT) Received: (qmail 15622 invoked by uid 0); 19 Mar 2010 00:51:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 19 Mar 2010 00:51:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=meQ4R7udgfgafwwphmr1/+RAhtewsLKnSY2GcZKbZYcYMzc3tvbChcTE6aPZV7c0Xk+WIk5eYHPtMBQ7Cg6wT0V7TXFOCUB4taVbkj189avFqT5UCnSnREtGCZ/Uc9W2; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NsQQc-00068D-5m; Thu, 18 Mar 2010 18:51:06 -0600 From: "Richard Shockey" To: "'Cullen Jennings'" , "'Jim Reid'" References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> In-Reply-To: <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> Date: Thu, 18 Mar 2010 20:51:02 -0400 Message-ID: <022e01cac6fe$405f4a20$c11dde60$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrG3YEhVV2at/AqRL67Y6Ks6BSkJAAHqUiw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 00:50:55 -0000 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Thursday, March 18, 2010 4:57 PM To: Jim Reid Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup Thanks Jim So making sure I understand the requirement here ... we need to be able to lookup the metadata from an end users phone or terminal? RS> In my principal use cases neither..typically internal network proxies or SBC's. And the query is to highly localized directory/location servers. That is why I argue that the meta data problem is both a ENUM and a SIP issue some carriers have a preference for one vs the other. I don't care. There is nothing wrong with giving folks both a hammer and a socket wrench and let them choose the tool. It's the TCAP replacement model here. A session comes into my network what do I do? I need data about this session what do I do? Data from multiple sources can be aggregated and returned by a single query via 3761 localized assuming that the network can trust the source of the query. We may need a new form of SIP redirect here but I don't want to go there. It is then presented with all available data about that session and returns an "answer" that answer may be URI's or metadata that prompts a secondary form of look up or a localized policy driven result. Clearly if we it was only needed from the call agents or SBC in the middle of the network, long lived connections would work fine. (I realize we also need to be able to make metadata queries from the call agents, SBC, etc. ) Do I have the right understanding here? RS> Yes and no ..there are multiple use cases here that some such as the classic e164.arpa ones use the public DNS but others are not but both could also support PSTN transitional environments in classic voice centric networks. IF you are ATT and want to shut of the PSTN ( according to their FCC filings) you still need to query for data internally and that is what private ENUM is many environments does extremely well. On Mar 18, 2010, at 8:45 AM, Jim Reid wrote: > On 18 Mar 2010, at 14:29, Cullen Jennings wrote: > >> Speaking of such things, one person asked me, why use DNS at all. Why not just do a HTTPS lookup like >> >> https://meta.example.com/+19725199190/cnam > > Because the overhead of setting up a TCP connection, then doing SSL authentication over it will always lose to a DNS query-response over UCP. It's not just the extra packets and latency -- a big deal in things like 3G networks where users get to pay by the packet -- but the impact on the web servers, SBCs or whatever that would get bombarded with bazillions of presumably short-lived TCP connections. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Thu Mar 18 17:58:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF3C3A6BBB for ; Thu, 18 Mar 2010 17:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks3+tB50JtfR for ; Thu, 18 Mar 2010 17:58:23 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id DC84C3A6881 for ; Thu, 18 Mar 2010 17:58:23 -0700 (PDT) Received: (qmail 23512 invoked by uid 0); 19 Mar 2010 00:58:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 19 Mar 2010 00:58:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=VMib8sKekjGSHrDXgf3yJvUU/6MWe56FYGjfrml9ejEoO7gA1Jq042nWIa0bwc/pT1fEcjou95VQBFOBm4jihr/Q5Cv7+gYis4hOTHC9qmBzBCgWH3NLXhqS2IWqPHyY; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NsQXr-0000ud-Um; Thu, 18 Mar 2010 18:58:36 -0600 From: "Richard Shockey" To: "'Jim Reid'" , "'Dean Willis'" References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> <4BA282EE.6060405@softarmor.com> <796B7B6C-4435-4015-8AFE-26042261F43D@rfc1035.com> In-Reply-To: <796B7B6C-4435-4015-8AFE-26042261F43D@rfc1035.com> Date: Thu, 18 Mar 2010 20:58:32 -0400 Message-ID: <023201cac6ff$4c75d030$e5617090$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrG4HWDgrgTjAmwSiaMiLTnmha9hQAHe5SQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 00:58:24 -0000 One of the design goals of the DNS is to save every host on the net from knowing about everything in the name space. [That's why the ARPAnet gave up on hosts.txt 25 years ago.] Your proposal violates that. It simply won't scale. RS> Right but what we do know from the split DNS experience is that some results are more authoritative than others about internal network topology. The confusion Dean is bringing to the table here is what those of us in the ENUM wars have known for ever. There are two views of data. In the classic E.164 world there is, sometimes, a marked preference for knowing everything you can locally and demanding that that the response to a query be done in 120 ms. Heck memory resident terabyte resident databases are cheap and fast and a lot less expensive than classic PSTN Service Control Points. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Thu Mar 18 20:36:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18EC23A6824 for ; Thu, 18 Mar 2010 20:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.381 X-Spam-Level: X-Spam-Status: No, score=-1.381 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jHmfb1iuPGW for ; Thu, 18 Mar 2010 20:36:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 12C113A6782 for ; Thu, 18 Mar 2010 20:36:43 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2J3aquf031580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Mar 2010 22:36:54 -0500 Message-Id: <5F68F26D-B471-4590-9517-0DC11944FF59@softarmor.com> From: Dean Willis To: Lawrence Conroy In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 22:36:45 -0500 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> <4BA282EE.6060405@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 03:36:44 -0000 On Mar 18, 2010, at 3:58 PM, Lawrence Conroy wrote: > Hi again Dean, Jim, folks, > Apart from the traditionally mistaken dig at ENUM, what is this about? > > I get this impression this is WAAAAAAAY too unfocussed for what should > be a "small bite". I expect to see implementations of what was > proposed > in the charter out the door by the end of this year. > What are you talking about, Lawrence? The stuff that I said was clearly outside the scope of ENUM because it constituted a replacement for DNS? > This stuff is a very close fit to DNS usage patterns. Data doesn't > change > often, it's a huge database with distributed control, and it needs the > performance that would p**s all over any secure web set up. No > surprise > that this stuff is intending to use DNS (and steal all the work > already > done on ENUM). All very focussed. While I have not proposed that we reinvent DNS, once you add DNS security, the performance difference relative to HTTPS isn't as dramatic as you might think. You are using DNSSEC, aren't you? Why not? > Dean, Cullen, I get that you believe there are security issues. I also > get everyone else saying that they know there are security issues with > every piece of sensitive data placed into DNS (or anywhere else on the > Interwebs). > I expect them to do as they have already said they will, and note this > in big friendly letters on the front cover of each document. Just like > we all did in ENUM. That might be suitable. But I'd like us to understand that's what we're doing, and that we're doing it on an element-by-element basis, not just as a blanket statement for every document the WG might produce. > > Any more than that is Country-specific PII/DP **POLICY**, and doing > anything more than a general advisory to not put your current location > in your domain (or the front page of facebook) is not the IETF's job. > ENUM did all it could in that direction, and I see no signs that > E2MD has succumbed to the Web 2.0 view of privacy. I suspect that > implied accusation is what rankles some of us -- we DO know about > this and we DO warn folk. We have to deal with Governments and their > separate and randomly whacky views on what IS required/banned/optional > depending on who's asking/... Well, here's he counterpoint. By proposing that our charter contain a blanket statement saying in effect that privacy and security issues are Somebody Else's Problem, we started looking like people who wither did not understand or did not care about the issues. That set off Big Red Flags that I'm trying to get pulled in by saying, in our proposed charter, that we both understand the security questions and are going to deal with them. That's it, and that's all there is to it. > > So why do I still see examples of a fluffy cloud that seems to be > enveloping this stuff? > Because you aren't reading what was actually written, maybe? > - For those of you with a life (and not on all the other MLs), Dean > seems to be re-inventing the ideas on a new transport for DNS (using > SCTP). > Why long-lived connections via HTTPS? Because it's there, I guess, and > because the expertise in DNSEXT (and the "the purgatory of TCPM") is > not considered. Cullen asked the question "Why aren't we doing metadata with HTTP?" I answered -- "because doing so would lead us down the path of reinventing DNS using HTTP. It's not necessarily a bad idea (as some have suggested) but it is OUTSIDE THE PROPOSED SCOPE FOR E2MD." I HAVE NOT PROPOSED TO GO THERE IN E2MD! AFAIK, NOBODY HAS! > > I *hope* the intent is NOT to try to provide an alternative take > on "DNS-NG" -- as Jay says, that is for another bunch who can, do, > and will grind exceedingly small on any such change to DNS. > [For the joy of that discussion so far, search namedroppers for SCTP > or TCP] > Aarg! Richard misquotes me, and everybody reacts to his misquote. > - I also note what looks like an attempt to introduce general privacy > controls into the DNS. Again, that's dnsext's job if it's anyone's. > [For the narrow ENUM/E2MD take on controls, Jim's already said that > he needs to look at x-crypto again -- brave man]. If you're going to put generally sensitive data into the DNS, you may well need general privacy controls. Or you might just decide that the DNS is NOT the place to put your sensitive data. It is OK for E2MD to say "That use case contains such sensitive data that we don't want it in the DNS. Go find another mechanism." Will the WG be willing to make that call, and will it be willing to write guidelines to help reviewers who come after us make that call? I hope so. From dean.willis@softarmor.com Thu Mar 18 21:03:07 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D913A683A for ; Thu, 18 Mar 2010 21:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=-1.506, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzve0yjK7D9h for ; Thu, 18 Mar 2010 21:03:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8A8263A677C for ; Thu, 18 Mar 2010 21:03:06 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2J43GWt031751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Mar 2010 23:03:17 -0500 Message-Id: <17F263E4-E50A-41C5-814E-E557226CCEFA@softarmor.com> From: Dean Willis To: Jim Reid In-Reply-To: <796B7B6C-4435-4015-8AFE-26042261F43D@rfc1035.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 23:03:10 -0500 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> <4BA282EE.6060405@softarmor.com> <796B7B6C-4435-4015-8AFE-26042261F43D@rfc1035.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 04:03:07 -0000 On Mar 18, 2010, at 4:17 PM, Jim Reid wrote: > On 18 Mar 2010, at 19:45, Dean Willis wrote: > >> A name server can only resolve things for itself that it is either >> authoritative for (primary or secondary) or that has cached. > > Nope. Resolution is the process of making iterative queries starting > at some place in the tree until an authoritative server provides the > answer to some query. Authoritative servers don't have to resolve > anything. Some implementations of these don't even have code to > *make* queries. By implication, these don't have caches either. That's an euphemistic play on resolution. Another way to look at it is "everything that happens when an app calls gethostbyname" and invovles "libresolv" or the local equivalent. This library is by the "resolver" and what it does is "resolution". Historically, the set of hosts to use for the library was configured in "resolv.conf", which also hints at doing resolution. Note also that what happens in "the DNS" isn't necessarily the only way to make a name service work. If the name server isn't authoritative, and doesn't have a cache, it can't answer directly. Somebody else has to get asked. This could happen in a couple of obvious ways. The name server could "pass the buck" by looking for an authoritative server and then querying there, or it could return a reference to an authoritative server and let the client handle the query, or it could just give up and hope the client finds another way to answer the query, or it could return another thing that the client should query on in order to get somewhere. Oddly enough, all of these approaches have, I believe, been exercised at some point in the evolution of SIP's "name server" functionality, which is called a "location server" in RFC 3261. Any heirarchical directory service has essentially the same pallet of potential mechanisms, and one can readily envision a replacement DNS that works just a little different from current DNS but uses relatively long-lived HTTP sessions for transport, rather than UDP. One could also envision one using XMPP, for that matter. > > A name server can answer a query when (a) it is authoritative for > the zone in question; (b) has cached the answer from an earlier > lookup it made; (c) resolves the query from a client my making > iterative queries to other servers. The choice of (a), (b) or (c) > (or some combination of these) is down to local policy and > configuration. > >> It has to go upstream occasionally. For example, the NS for >> subdoomain >> "research.softarmor.com" frequently talks to the NS for domain >> "softarmor.com". > > The DNS doesn't work that way. Sorry. If it did, it would mean every > authoritative name server would be in regular contact with those for > its parent zones. And so on. They're not. An authoritative name > server doesn't have to talk to any other name server. It only has to > answer queries. An authoritative name server will frequently handle requests from other servers, such as for zone transfers.. That's talking. > >> Why wouldn't a long-lived connection work here? > > See above. There's no reason why a name server for > research.softarmor.com would need to ever speak to a name server for > softarmor.com. The softarmor.com servers don't speak to the .com > name servers. And the .com name servers don't speak to the root name > servers. > >> Similarly, once "research.softarmor.com" has used "softarmor.com" to >> find "marketing.softarmor.com", it may well connect directly to >> "marketing.softarmor.com" to find the IP address for URI >> "sip:bob@bob.marketing.softarmor.com". My guess is that it "research" >> talks to "marketing" fairly frequently (or at least their name >> servers >> do). Why wouldn't an HTTP connection work here? > > Let's assume that DNS works the way you've guessed. [It doesn't.] > How many long-lived TCP connections is the name server for > research.softarmor.com going to maintain? How will it choose between > them when it runs out of file descriptors? How does my browser know which connections to discard? Varies by browser. A weighted discard prioritization factoring LRU against least- used would seem to be reasonable. > It's not easy to model DNS traffic in the same way as say HTTP > because DNS lookups regularly entail diversions into lookups in > other domains. ie to resolve A, the server needs to resolve B, C & D > to get to the name servers of E, F & G to find the addresses of the > name servers for A. > > Try doing a dig +trace on some domain name to see what's really > going on when a name gets resolved. You'll be surprised. > >> Another way to model this is a straight-up port of current DNS, with >> zone transfers being simple HTTP GET requests on the zone files, etc. >> wherein the HTTP layer is tuned to hold up the TCP connection "as >> long >> as reasonable", for which there are several evident mechanisms. > > Dean, this is truly bizarre. For many zones these days, there is no > "zone file" any more: there's a real database holding the zone data. > And many folk don't allow copies of their zones to be slurped by > axfr (or HTTP GETs in your model) for all sorts of reasons, some > sensible, others stupid... I wonder if you've thought this through. > The Internet would collapse -- as would the .com name servers -- if > every lookup for a name in the .com domain meant pulling down the > 4GB or so of .com "zone file". I certainly didn't suggest that every query be replaced by a zone transfer. I did say that where zone transfers occur, one could effectively GET the entire zone. Or, in your terminology as I infer it, one could do a database table replication over TCP More specifically, I did ay that individual query operations could technically be done using TCP (perhaps in an HTTP API) rather than UDP. Sure, there's more overhead on TCP. But IF we persist in making the query results humongous through putting arbitrary metadata in them, we're going to need TCP to handle those queries anyhow. Every time somebody says "But if we switch from UDP to TCP, the Internet will collapse!" they seem to eventually be proven wrong. > > One of the design goals of the DNS is to save every host on the net > from knowing about everything in the name space. [That's why the > ARPAnet gave up on hosts.txt 25 years ago.] Your proposal violates > that. It simply won't scale. > Perhaps I haven't been clear. But it doesn't really matter here, as doing this is clearly OUTSIDE THE SCOPE OF E2MD, other than perhaps pondering whether particular E2MD use cases are well-handled by the current DNS. -- Dean From dean.willis@softarmor.com Thu Mar 18 21:16:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9793A67F7 for ; Thu, 18 Mar 2010 21:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-1.396, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWxwfK1KsLtg for ; Thu, 18 Mar 2010 21:16:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0A3E63A682C for ; Thu, 18 Mar 2010 21:16:25 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2J4GXK7031842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Mar 2010 23:16:35 -0500 Message-Id: From: Dean Willis To: Richard Shockey In-Reply-To: <022e01cac6fe$405f4a20$c11dde60$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Mar 2010 23:16:27 -0500 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> <022e01cac6fe$405f4a20$c11dde60$@us> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: [e2md] SIP as an alternative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 04:16:50 -0000 On Mar 18, 2010, at 7:51 PM, Richard Shockey wrote: > > > RS> In my principal use cases neither..typically internal network > proxies or > SBC's. And the query is to highly localized directory/location > servers. That > is why I argue that the meta data problem is both a ENUM and a SIP > issue > some carriers have a preference for one vs the other. I don't care. Richard has spoken several times of using SIP as a lookup mechanism for the metadata. Each time, we've sort of skipped past it to argue about DNS use cases. But there may be another model or two in what he's been hinting at. As I understand it, the model Richard has in mind is that either the metadata would be added to the incoming signaling by the proxy network so that the end-point would not have to query for it, or that the metadata would be provided in some sort of 3XX response to a request, so that the requesting node could use the metadata in its next signaling round. This raises the question of how the SIP servers acquire the metadata themselves, which might be through ENUM or provisioning or something else. But what if we hybridized? Perhaps the NAPTR could point at a "metadata URI", either on a per- metadata field level (as I did in the HTTP example that nobody seems to have noticed) or for all metadata relative to a NAPTR. If this URI were formatted as a SIP URI, we could then do a SUBSCRIBE against the URI, and receive a return NOTIFY containing the metadata. So: a SIP event package that reports metadata for telephone numbers, which we use ENUM to bootstrap. Like the HTTP model, this lets the SIP server do things like AAA, make privacy decisions, and selectively answer based on characteristics of the requester. Does this approach have any merit? Here's a usage scenario: 1) Alice calls Bob, using a telephone number for source and target. 2) Bob's UA receives the call and wants to display Calling Name. 3) Bob's UA does an ENUM lookup on Alices' phone number, and gets a SIP URI for her metadata. 4) Bob SUBSCRIBES to the URI, the server realizes that Alice does not have an unlisted number, and NOTIFIES Bob with all the metadata he's allowed to see. -- Dean From Ray.Bellis@nominet.org.uk Fri Mar 19 04:01:42 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549133A6975 for ; Fri, 19 Mar 2010 04:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngvdbkR-MSHu for ; Fri, 19 Mar 2010 04:01:41 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id AB7FA3A69BC for ; Fri, 19 Mar 2010 04:01:33 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=iPevdfXjBEz4ItJ3gOHFVDvSaEImY5HNk+E9oVsLxE5zYDyYuQ1tZSxK 9vX+wJ3LmuwbGFPEp6ldN+mKO+ErWmRf9f2yoj+ehp+UNyjxPma14+Kl/ /kuYk5/7tVmUICd; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1268996508; x=1300532508; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20SIP=20as=20an=20alternative=20to=20DNS=20lookup|Date: =20Fri,=2019=20Mar=202010=2011:01:44=20+0000|Message-ID: =20|To:=20Dean=20Willis=20|Cc:=20e2md@ietf.org|MIME-Version:=201.0 |In-Reply-To:=20|References:=20<773A981B-0F0A-4B3C-87D4-49B34B AF402F@cisco.com>=09<27C46C43-3BD0-44BF-A319-9B71CACFDDF3 @softarmor.com>=0D=0A=09<33DFACFE-AB03-4622-B0A8-735409AD F662@cisco.com>=09<899A653A-4EE1-474B-81FE-06F0CE56A7F6@r fc1035.com>=0D=0A=09<69328774-65A4-4E38-8AAD-51FEE9843354 @cisco.com>=09<022e01cac6fe$405f4a20$c11dde60$@us>=20; bh=Sa2wH/Xw1nhm6aNdX/xK1XouwojjGGnQwpYGuOQjCWw=; b=ZB/ePGcmox+uTN4IDUs2rBAPUdhpKFbxzch+v2MRaOOFdH//Ndb0JsA1 sPkT3C35lIfRZh4BMhXeohccxafH5S49KpFRBfhowmSQvGLCmcCFySH7K gISV4hAdUOLtBQD; X-IronPort-AV: E=Sophos;i="4.51,273,1267401600"; d="scan'208";a="22710893" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 19 Mar 2010 11:01:45 +0000 In-Reply-To: References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> <022e01cac6fe$405f4a20$c11dde60$@us> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Fri, 19 Mar 2010 11:01:44 +0000 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 19/03/2010 11:01:45 AM, Serialize complete at 19/03/2010 11:01:45 AM Content-Type: multipart/alternative; boundary="=_alternative 003C9595802576EB_=" Cc: e2md@ietf.org Subject: Re: [e2md] SIP as an alternative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 11:01:42 -0000 This is a multipart message in MIME format. --=_alternative 003C9595802576EB_= Content-Type: text/plain; charset="US-ASCII" > So: a SIP event package that reports metadata for telephone numbers, > which we use ENUM to bootstrap. Like the HTTP model, this lets the SIP > server do things like AAA, make privacy decisions, and selectively > answer based on characteristics of the requester. > > Does this approach have any merit? No, IMHO this approach has absolutely zero merit because NOT EVERY NETWORK USES SIP!! Ray --=_alternative 003C9595802576EB_= Content-Type: text/html; charset="US-ASCII"
> So: a SIP event package that reports metadata for telephone numbers,  
> which we use ENUM to bootstrap. Like the HTTP model, this lets the SIP  
> server do things like AAA, make privacy decisions, and selectively  
> answer based on characteristics of the requester.
>
> Does this approach have any merit?
No, IMHO this approach has absolutely zero merit because NOT EVERY NETWORK USES SIP!!

Ray
--=_alternative 003C9595802576EB_=-- From lconroy@insensate.co.uk Fri Mar 19 04:18:41 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0053A6847 for ; Fri, 19 Mar 2010 04:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15qzXRmNw75h for ; Fri, 19 Mar 2010 04:18:39 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id B6A323A68DE for ; Fri, 19 Mar 2010 04:18:38 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5CA52117D75; Fri, 19 Mar 2010 11:18:50 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Fri, 19 Mar 2010 11:18:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <45B8FF51-FF8E-4F89-B5C7-FEA4B484D537@insensate.co.uk> References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> <022e01cac6fe$405f4a20$c11dde60$@us> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1077) Cc: e2md@ietf.org Subject: Re: [e2md] SIP as an alternative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 11:18:41 -0000 Hi Ray, Dean, folks, To clarify, not every network uses SIP for all these functions; some = use IMS. (with different functions carried out using different methods in = different nets). Many still rely on traditional (C)SS#7 interconnects, as they "work". = Sigh. E2MD via DNS may or may not be used; this is an attempt to provide = another tool for the box. For those networks that DO use SIP, *and* use it for those = purposes in the way we expect, a SIP-based approach could work. For the rest... all the best, Lawrence On 19 Mar 2010, at 11:01, Ray.Bellis@nominet.org.uk wrote: >> So: a SIP event package that reports metadata for telephone numbers,=20= >> which we use ENUM to bootstrap. Like the HTTP model, this lets the = SIP=20 >> server do things like AAA, make privacy decisions, and selectively=20 >> answer based on characteristics of the requester. >> Does this approach have any merit? >=20 > No, IMHO this approach has absolutely zero merit because NOT EVERY = NETWORK=20 > USES SIP!! > Ray From jim@rfc1035.com Fri Mar 19 05:41:14 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 489323A6938 for ; Fri, 19 Mar 2010 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.016 X-Spam-Level: X-Spam-Status: No, score=0.016 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppH+vyQLLHcK for ; Fri, 19 Mar 2010 05:41:13 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 6DB0D3A6906 for ; Fri, 19 Mar 2010 05:41:12 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 658B4154208B; Fri, 19 Mar 2010 12:41:23 +0000 (GMT) Message-Id: From: Jim Reid To: Dean Willis In-Reply-To: <17F263E4-E50A-41C5-814E-E557226CCEFA@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Mar 2010 12:41:22 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> <4BA282EE.6060405@softarmor.com> <796B7B6C-4435-4015-8AFE-26042261F43D@rfc1035.com> <17F263E4-E50A-41C5-814E-E557226CCEFA@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 12:41:14 -0000 On 19 Mar 2010, at 04:03, Dean Willis wrote: > That's an euphemistic play on resolution. No it isn't. What I said is the strictly correct definition of that term in a DNS context. > Another way to look at it is "everything that happens when an app > calls gethostbyname" and invovles "libresolv" or the local > equivalent. This library is by the "resolver" and what it does is > "resolution". Historically, the set of hosts to use for the library > was configured in "resolv.conf", which also hints at doing resolution. You're now talking about stub resolvers. These do not do true resolution. They make one query, wait for a response and give up if no reply is received. A stub resolver has no knowledge of the name space or the root name servers and cannot follow a referral response. A true resolver does all of these things. In the early days of DNS people didn't make a distinction between a proper resolver and a stub resolver. They do now, thanks largely to DNSSEC. The names of that stub resolver library and its config file (and their man pages) are an archeological relic from those faraway and naive days. > Note also that what happens in "the DNS" isn't necessarily the only > way to make a name service work. True. But what other name service exists today which is (a) deployed; (b) scalable and (c) ubiquitious. Frankly, DNS is the only game in town. If you think this list/WG can come up with something better, go ahead. Be aware though that that particular path is littered with the corpses of things which have tried and failed to displace DNS. >>> It has to go upstream occasionally. For example, the NS for >>> subdoomain >>> "research.softarmor.com" frequently talks to the NS for domain >>> "softarmor.com". >> >> The DNS doesn't work that way. Sorry. If it did, it would mean >> every authoritative name server would be in regular contact with >> those for its parent zones. And so on. They're not. An >> authoritative name server doesn't have to talk to any other name >> server. It only has to answer queries. > > An authoritative name server will frequently handle requests from > other servers, such as for zone transfers.. That's talking. Sure. But there is no reason for an authoritative server to make zone transfers from parent servers. Or vice versa. The name servers for softarmor.com don't (and can't) slurp the .com zone. The .com name servers don't talk to the softarmor.com zone's servers in any way either. BTW it's bad DNS practice to have parent and child zones on the same name server because it allows broken or non-existent delegations to appear to work. > I certainly didn't suggest that every query be replaced by a zone > transfer. That seemed to be what you were implying with all that babble about long-lived TCP connections to "upstream servers" (whatever they might be). > Every time somebody says "But if we switch from UDP to TCP, the > Internet will collapse!" they seem to eventually be proven wrong. I didn't say that. I did say a model of resolution that relied on zone transfers (or equivalent) would cause meltdown. Assuming it could ever be made to work and scale. Which it can't. From dean.willis@softarmor.com Fri Mar 19 11:24:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29BDF3A68EF for ; Fri, 19 Mar 2010 11:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[AWL=-1.473, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ7yJWoDwzlG for ; Fri, 19 Mar 2010 11:24:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 660FB3A67EE for ; Fri, 19 Mar 2010 11:24:47 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2JIOv61006030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Mar 2010 13:24:58 -0500 Message-Id: <270707C0-AF58-4825-B986-7FC414873B84@softarmor.com> From: Dean Willis To: Jim Reid In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Mar 2010 13:24:51 -0500 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <4BA24727.4020009@softarmor.com> <73BBB955-DE46-40D1-9AC4-3063592152F2@rfc1035.com> <4BA282EE.6060405@softarmor.com> <796B7B6C-4435-4015-8AFE-26042261F43D@rfc1035.com> <17F263E4-E50A-41C5-814E-E557226CCEFA@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] HTTPS as an alterative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 18:24:50 -0000 On Mar 19, 2010, at 7:41 AM, Jim Reid wrote: > On 19 Mar 2010, at 04:03, Dean Willis wrote: > >> That's an euphemistic play on resolution. > > No it isn't. What I said is the strictly correct definition of that > term in a DNS context. > >> Another way to look at it is "everything that happens when an app >> calls gethostbyname" and invovles "libresolv" or the local >> equivalent. This library is by the "resolver" and what it does is >> "resolution". Historically, the set of hosts to use for the >> library was configured in "resolv.conf", which also hints at doing >> resolution. > > You're now talking about stub resolvers. These do not do true > resolution. They make one query, wait for a response and give up if > no reply is received. A stub resolver has no knowledge of the name > space or the root name servers and cannot follow a referral > response. A true resolver does all of these things. In the early > days of DNS people didn't make a distinction between a proper > resolver and a stub resolver. They do now, thanks largely to DNSSEC. > My point exactly. The process that a DNS server goes through to answer the query made by a "resolver" is "resolution". SIP's resolution procedure is more general; every UA is expected to handle a referral response. > The names of that stub resolver library and its config file (and > their man pages) are an archeological relic from those faraway and > naive days. > >> Note also that what happens in "the DNS" isn't necessarily the only >> way to make a name service work. > > True. But what other name service exists today which is (a) > deployed; (b) scalable and (c) ubiquitious. Frankly, DNS is the > only game in town. If you think this list/WG can come up with > something better, go ahead. Be aware though that that particular > path is littered with the corpses of things which have tried and > failed to displace DNS. > >>>> It has to go upstream occasionally. For example, the NS for >>>> subdoomain >>>> "research.softarmor.com" frequently talks to the NS for domain >>>> "softarmor.com". >>> >>> The DNS doesn't work that way. Sorry. If it did, it would mean >>> every authoritative name server would be in regular contact with >>> those for its parent zones. And so on. They're not. An >>> authoritative name server doesn't have to talk to any other name >>> server. It only has to answer queries. >> >> An authoritative name server will frequently handle requests from >> other servers, such as for zone transfers.. That's talking. > > Sure. But there is no reason for an authoritative server to make > zone transfers from parent servers. Or vice versa. The name servers > for softarmor.com don't (and can't) slurp the .com zone. The .com > name servers don't talk to the softarmor.com zone's servers in any > way either. BTW it's bad DNS practice to have parent and child zones > on the same name server because it allows broken or non-existent > delegations to appear to work. One more time, I never said that the name servers for softarmor.com need to slurp the .com zone. They do, however, make relatively frequent queries for SOA within the ".com" space. A connectivity graph will show them talking fairly frequently to these "upstream" nodes, especially after a restart. The frequently used relationships are candidates for some sort of reused TCP connection. > >> I certainly didn't suggest that every query be replaced by a zone >> transfer. > > That seemed to be what you were implying with all that babble about > long-lived TCP connections to "upstream servers" (whatever they > might be). HTTP has changed since 1.0; 1.1 prefers relatively long-lived connections that can process multiple queries. Haven't used the connection lately and no more queries in the pipeline? Close it! Modern TCP stacks can also handle vastly more connected TCP sockets; they don't use file descriptors and thereby avoid the 16-it handle limit. People working on the SIP list went through this enumeration five or six years ago during one of our regular TCP vs UDP fights. "Upstream" servers, for example, might include the root servers that the softarmor.com name server gets primed with at boot time (/etc/bind/ db.root) > >> Every time somebody says "But if we switch from UDP to TCP, the >> Internet will collapse!" they seem to eventually be proven wrong. > > I didn't say that. I did say a model of resolution that relied on > zone transfers (or equivalent) would cause meltdown. Assuming it > could ever be made to work and scale. Which it can't. > Okay, I'll buy that. But what about a model that uses TCP connections instead of UDP connections for queries? I'm thinking this is an order N increase, where N is relatively small, say perhaps 6 or so, if there's no reuse of connections. The more connections are reused, the more this decreases. Plus we save a bit in the database engine on resubmitted queries because of something UDP having gotten lost in the net somewhere. -- Dean From dean.willis@softarmor.com Fri Mar 19 11:27:08 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AC43A6929 for ; Fri, 19 Mar 2010 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c301rlLiMrt7 for ; Fri, 19 Mar 2010 11:27:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2A05F3A691C for ; Fri, 19 Mar 2010 11:27:06 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2JIRGja006051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Mar 2010 13:27:18 -0500 Message-Id: <181F6D03-5AB1-4DB6-8375-2DB20A91C452@softarmor.com> From: Dean Willis To: Lawrence Conroy In-Reply-To: <45B8FF51-FF8E-4F89-B5C7-FEA4B484D537@insensate.co.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Mar 2010 13:27:11 -0500 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <899A653A-4EE1-474B-81FE-06F0CE56A7F6@rfc1035.com> <69328774-65A4-4E38-8AAD-51FEE9843354@cisco.com> <022e01cac6fe$405f4a20$c11dde60$@us> <45B8FF51-FF8E-4F89-B5C7-FEA4B484D537@insensate.co.uk> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] SIP as an alternative to DNS lookup X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 18:27:08 -0000 On Mar 19, 2010, at 6:18 AM, Lawrence Conroy wrote: > Hi Ray, Dean, folks, > To clarify, not every network uses SIP for all these functions; some > use IMS. > (with different functions carried out using different methods in > different nets). > Many still rely on traditional (C)SS#7 interconnects, as they > "work". Sigh. > > E2MD via DNS may or may not be used; this is an attempt to provide > another tool > for the box. For those networks that DO use SIP, *and* use it for > those purposes > in the way we expect, a SIP-based approach could work. For the rest... Running SIP as a query protocol doesn't really require that SIP be the core signaling protocol, you know. Would ENUM+HTTP for metadata retrieval be more broadly applicable than ENUM+SIP-Events? Possibly. It's certainly easier to implement with basic off-the-shelf libraries. -- Dean From dean.willis@softarmor.com Fri Mar 19 12:03:05 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82DC13A6955 for ; Fri, 19 Mar 2010 12:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKIx-hcX3E4a for ; Fri, 19 Mar 2010 12:03:04 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4ADFE3A68C6 for ; Fri, 19 Mar 2010 12:03:04 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2JJ3F9d006299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 19 Mar 2010 14:03:17 -0500 Message-Id: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> From: Dean Willis To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Mar 2010 14:03:10 -0500 X-Mailer: Apple Mail (2.936) Subject: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:03:05 -0000 We touched on this earlier, but got derailed by the "Why don't we just use HTTP for everything" question that Cullen did us the honor to ask. Current proposals as I understand them call for either: 1) encoding metadata into a "data" URI (which is considered pretty hokey by the URI people, as the hunk of data is NOT universal, and while it may be a resource, it's not an indicator and also isn't used to initiate a communications session directly, making it inconsistent with the "u" flag in the Naptr record). 2) creating a new Enumservice name, like "E2MD", that can return a text string containing the metadata (the basic model in draft- hoeneisen-e164-to-metadata-02). Currently, the expressible range of metadata is unbounded by this draft; the same string holds ALL the metadata elements, presumably in a syntactically delimited form something like name-value pairs. In some use cases, there is arguably a need to privacy-protect some of the values, so we might have to encrypt some of them. This raises key management questions. 3) Creating a new Enumservice for each type of metadata, and encoding the metadata appropriately. AFAIk, we haven't talked about this one much yet 4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned string to be an absolute URI. We're not exactly sure what this URI has in it, yet. Let's talk about what we could do with #4 by using a hybrid of ENUM for the lookup and some other protocol, specifically HTTP, for the result phase. We could reasonably put the metadata in a file/record/member (pick your own terminology) and stick the URI for that metadata into the E2MD NAPTR record as an absolute URI. In this approach, to find someone's CNAM, I would first get their NAPTR from ENUM using the phone number, then do an HTTP GET operation on the resulting URI to retrieve the metadata, then pull the CNAM out of the metadata. This has a couple of big options over putting the metadata directly into ENUM: 1) The metadata can conceivably be large, which allegedly makes for problems with DNS' use of UDP. 2) The web server can use standard AAA mechanisms to decide whether the requester is authorized to see the metadata, and if so, which metadata to return. 3) HTTP allows the web server to use other information known about the requester to decide how to answer the query. This is useful for a lot of cases that people have been proposing to build around enum, like egress route selections. 4) HTTP request parameters can be used to select a subset of the metadata for the query, for example just asking for calling name or in- use status. There are some obvious potential issues: 1) The HTTP server has to be reachable from the requester. We KNOW that DNS was in some way reachable already; how much of a burden is to expect HTTP to work too? 2) The HTTP server might be capacity-constrained. Of course, we have HTTP tricks to deal with this, like load-balancers, anycast, etc. 3) It's arguably more overhead; there's an additional TCP setup, perhaps TLS, perhaps a challenge/response sequence. Would the E2MD working group be willing to consider this sort of approach, or are we restricting ourselves to a pure DNS model? -- Dean From richard@shockey.us Fri Mar 19 12:29:14 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58873A6832 for ; Fri, 19 Mar 2010 12:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[AWL=-1.104, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpr6713S-FiF for ; Fri, 19 Mar 2010 12:29:13 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 87A393A67AE for ; Fri, 19 Mar 2010 12:29:13 -0700 (PDT) Received: (qmail 23937 invoked by uid 0); 19 Mar 2010 19:29:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 19 Mar 2010 19:29:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Jz1WWHEX7zVgbuVzrhbeXwL75VOsMPncwv9DrtiW92xma0L6/rUnzLNp8W6v9AT2J618yXI3A6bmMkP/8ZtEXc1PDIg5mdQoHDUEZ9WWYLibTpe7odVYP+b2MYGhk2FG; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nshss-0004kg-Ed; Fri, 19 Mar 2010 13:29:26 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'E.164 To MetaData BOF discussion list'" References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> In-Reply-To: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> Date: Fri, 19 Mar 2010 15:29:22 -0400 Message-ID: <015401cac79a$7aeb6a60$70c23f20$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrHlteeFzz18bkgTzyLpgb8h9ClPQAAaCCg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:29:14 -0000 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Friday, March 19, 2010 3:03 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] HTTP as an adjunct to ENUM lookups for metadata We touched on this earlier, but got derailed by the "Why don't we just use HTTP for everything" question that Cullen did us the honor to ask. Current proposals as I understand them call for either: 1) encoding metadata into a "data" URI (which is considered pretty hokey by the URI people, as the hunk of data is NOT universal, and while it may be a resource, it's not an indicator and also isn't used to initiate a communications session directly, making it inconsistent with the "u" flag in the Naptr record). RS > Yep .. been there done that with my old CNAM draft. 2) creating a new Enumservice name, like "E2MD", that can return a text string containing the metadata (the basic model in draft- hoeneisen-e164-to-metadata-02). Currently, the expressible range of metadata is unbounded by this draft; the same string holds ALL the metadata elements, presumably in a syntactically delimited form something like name-value pairs. In some use cases, there is arguably a need to privacy-protect some of the values, so we might have to encrypt some of them. This raises key management questions. 3) Creating a new Enumservice for each type of metadata, and encoding the metadata appropriately. AFAIk, we haven't talked about this one much yet RS> Us old ENUM types have been over this for years. Presumable the syntax could be E2MD+foo as in E2MD+SIPD where the metadata is SPID=xxxxxx; 4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned string to be an absolute URI. We're not exactly sure what this URI has in it, yet. Let's talk about what we could do with #4 by using a hybrid of ENUM for the lookup and some other protocol, specifically HTTP, for the result phase. We could reasonably put the metadata in a file/record/member (pick your own terminology) and stick the URI for that metadata into the E2MD NAPTR record as an absolute URI. In this approach, to find someone's CNAM, I would first get their NAPTR from ENUM using the phone number, then do an HTTP GET operation on the resulting URI to retrieve the metadata, then pull the CNAM out of the metadata. This has a couple of big options over putting the metadata directly into ENUM: RS I still think this whole concept is undeployable since it would require the network elements using E2MD to add an additional stack and the resulting code overhead, though the option I'd certainly keep open since folks might come up with ideas we haven't thought of yet. Most of the use cases we've gone over here are relatively simple text strings. If people want to use HTTP for stuff fine then write up a use case in the registration procedure we'll define. But for the first phases here simple text strings will work just fine. 1) The metadata can conceivably be large, which allegedly makes for problems with DNS' use of UDP. 2) The web server can use standard AAA mechanisms to decide whether the requester is authorized to see the metadata, and if so, which metadata to return. 3) HTTP allows the web server to use other information known about the requester to decide how to answer the query. This is useful for a lot of cases that people have been proposing to build around enum, like egress route selections. 4) HTTP request parameters can be used to select a subset of the metadata for the query, for example just asking for calling name or in- use status. There are some obvious potential issues: 1) The HTTP server has to be reachable from the requester. We KNOW that DNS was in some way reachable already; how much of a burden is to expect HTTP to work too? 2) The HTTP server might be capacity-constrained. Of course, we have HTTP tricks to deal with this, like load-balancers, anycast, etc. 3) It's arguably more overhead; there's an additional TCP setup, perhaps TLS, perhaps a challenge/response sequence. Would the E2MD working group be willing to consider this sort of approach, or are we restricting ourselves to a pure DNS model? -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From kcartwright@tnsi.com Fri Mar 19 12:31:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45C83A68E6 for ; Fri, 19 Mar 2010 12:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=-1.320, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJZf0vGbYkQp for ; Fri, 19 Mar 2010 12:31:30 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id B77B03A67EC for ; Fri, 19 Mar 2010 12:31:29 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41625192; Fri, 19 Mar 2010 15:31:32 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 19 Mar 2010 15:31:33 -0400 From: "Cartwright, Kenneth" To: Dean Willis , E.164 To MetaData BOF discussion list Date: Fri, 19 Mar 2010 15:31:31 -0400 Thread-Topic: [e2md] HTTP as an adjunct to ENUM lookups for metadata Thread-Index: AcrHltv8LweDtk2NQdiEq5Zr9NG6jAAAsmcA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> In-Reply-To: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:31:30 -0000 The document draft-hoeneisen-e164-to-metadata-02 proposal does not propose = what you describe in number 2 below (a new ENUM service called E2MD that co= ntains a single string that holds ALL the metadata). It proposes a new DDD= S service called E2MD (not a new ENUM service), which can be used to serve = up sub-sets of meta-data elements that are grouped by a Service-Type:SubTyp= e pair (not All the metadata in a single string). Your number 3 below a *l= ittle* more accurately captures what the draft is proposing. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dea= n Willis Sent: Friday, March 19, 2010 3:03 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] HTTP as an adjunct to ENUM lookups for metadata We touched on this earlier, but got derailed by the "Why don't we just use HTTP for everything" question that Cullen did us the honor to ask. Current proposals as I understand them call for either: 1) encoding metadata into a "data" URI (which is considered pretty hokey by the URI people, as the hunk of data is NOT universal, and while it may be a resource, it's not an indicator and also isn't used to initiate a communications session directly, making it inconsistent with the "u" flag in the Naptr record). 2) creating a new Enumservice name, like "E2MD", that can return a text string containing the metadata (the basic model in draft- hoeneisen-e164-to-metadata-02). Currently, the expressible range of metadata is unbounded by this draft; the same string holds ALL the metadata elements, presumably in a syntactically delimited form something like name-value pairs. In some use cases, there is arguably a need to privacy-protect some of the values, so we might have to encrypt some of them. This raises key management questions. 3) Creating a new Enumservice for each type of metadata, and encoding the metadata appropriately. AFAIk, we haven't talked about this one much yet 4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned string to be an absolute URI. We're not exactly sure what this URI has in it, yet. Let's talk about what we could do with #4 by using a hybrid of ENUM for the lookup and some other protocol, specifically HTTP, for the result phase. We could reasonably put the metadata in a file/record/member (pick your own terminology) and stick the URI for that metadata into the E2MD NAPTR record as an absolute URI. In this approach, to find someone's CNAM, I would first get their NAPTR from ENUM using the phone number, then do an HTTP GET operation on the resulting URI to retrieve the metadata, then pull the CNAM out of the metadata. This has a couple of big options over putting the metadata directly into ENUM: 1) The metadata can conceivably be large, which allegedly makes for problems with DNS' use of UDP. 2) The web server can use standard AAA mechanisms to decide whether the requester is authorized to see the metadata, and if so, which metadata to return. 3) HTTP allows the web server to use other information known about the requester to decide how to answer the query. This is useful for a lot of cases that people have been proposing to build around enum, like egress route selections. 4) HTTP request parameters can be used to select a subset of the metadata for the query, for example just asking for calling name or in- use status. There are some obvious potential issues: 1) The HTTP server has to be reachable from the requester. We KNOW that DNS was in some way reachable already; how much of a burden is to expect HTTP to work too? 2) The HTTP server might be capacity-constrained. Of course, we have HTTP tricks to deal with this, like load-balancers, anycast, etc. 3) It's arguably more overhead; there's an additional TCP setup, perhaps TLS, perhaps a challenge/response sequence. Would the E2MD working group be willing to consider this sort of approach, or are we restricting ourselves to a pure DNS model? -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jay@nzrs.net.nz Fri Mar 19 19:57:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3DD3A6862 for ; Fri, 19 Mar 2010 19:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.468 X-Spam-Level: X-Spam-Status: No, score=0.468 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRfmN-pYVyHe for ; Fri, 19 Mar 2010 19:57:30 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A77053A67F4 for ; Fri, 19 Mar 2010 19:57:29 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id CCD212DAA98; Sat, 20 Mar 2010 15:57:41 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHKvI1FJeMYw; Sat, 20 Mar 2010 15:57:41 +1300 (NZDT) Received: from [192.168.1.4] (121-73-175-54.dsl.telstraclear.net [121.73.175.54]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 3B0C82DA36A; Sat, 20 Mar 2010 15:57:41 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> Date: Sat, 20 Mar 2010 15:57:39 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 02:57:30 -0000 On 20/03/2010, at 8:03 AM, Dean Willis wrote: >=20 > We touched on this earlier, but got derailed by the "Why don't we just = use HTTP for everything" question that Cullen did us the honor to ask. HONOR?!! Has this suddenly become the ITU while I had my back turned? Jay >=20 >=20 > Current proposals as I understand them call for either: >=20 > 1) encoding metadata into a "data" URI (which is considered pretty = hokey by the URI people, as the hunk of data is NOT universal, and while = it may be a resource, it's not an indicator and also isn't used to = initiate a communications session directly, making it inconsistent with = the "u" flag in the Naptr record). >=20 > 2) creating a new Enumservice name, like "E2MD", that can return a = text string containing the metadata (the basic model in = draft-hoeneisen-e164-to-metadata-02). Currently, the expressible range = of metadata is unbounded by this draft; the same string holds ALL the = metadata elements, presumably in a syntactically delimited form = something like name-value pairs. In some use cases, there is arguably a = need to privacy-protect some of the values, so we might have to encrypt = some of them. This raises key management questions. >=20 >=20 > 3) Creating a new Enumservice for each type of metadata, and encoding = the metadata appropriately. AFAIk, we haven't talked about this one much = yet >=20 > 4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned = string to be an absolute URI. We're not exactly sure what this URI has = in it, yet. >=20 >=20 >=20 >=20 > Let's talk about what we could do with #4 by using a hybrid of ENUM = for the lookup and some other protocol, specifically HTTP, for the = result phase. >=20 > We could reasonably put the metadata in a file/record/member (pick = your own terminology) and stick the URI for that metadata into the E2MD = NAPTR record as an absolute URI. >=20 > In this approach, to find someone's CNAM, I would first get their = NAPTR from ENUM using the phone number, then do an HTTP GET operation on = the resulting URI to retrieve the metadata, then pull the CNAM out of = the metadata. >=20 > This has a couple of big options over putting the metadata directly = into ENUM: >=20 > 1) The metadata can conceivably be large, which allegedly makes for = problems with DNS' use of UDP. >=20 > 2) The web server can use standard AAA mechanisms to decide whether = the requester is authorized to see the metadata, and if so, which = metadata to return. >=20 > 3) HTTP allows the web server to use other information known about the = requester to decide how to answer the query. This is useful for a lot of = cases that people have been proposing to build around enum, like egress = route selections. >=20 > 4) HTTP request parameters can be used to select a subset of the = metadata for the query, for example just asking for calling name or = in-use status. >=20 >=20 >=20 > There are some obvious potential issues: >=20 >=20 > 1) The HTTP server has to be reachable from the requester. We KNOW = that DNS was in some way reachable already; how much of a burden is to = expect HTTP to work too? >=20 > 2) The HTTP server might be capacity-constrained. Of course, we have = HTTP tricks to deal with this, like load-balancers, anycast, etc. >=20 > 3) It's arguably more overhead; there's an additional TCP setup, = perhaps TLS, perhaps a challenge/response sequence. >=20 >=20 >=20 > Would the E2MD working group be willing to consider this sort of = approach, or are we restricting ourselves to a pure DNS model? >=20 > -- > Dean >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Sat Mar 20 10:22:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06F53A685A for ; Sat, 20 Mar 2010 10:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-1.436, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYzGMIiyGytp for ; Sat, 20 Mar 2010 10:22:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4CAAE3A6AB5 for ; Sat, 20 Mar 2010 10:20:49 -0700 (PDT) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2KHL0le015361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Mar 2010 12:21:02 -0500 Message-ID: <4BA503F7.6020806@softarmor.com> Date: Sat, 20 Mar 2010 12:20:55 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 17:22:04 -0000 Cartwright, Kenneth wrote: > The document draft-hoeneisen-e164-to-metadata-02 proposal does not > propose what you describe in number 2 below (a new ENUM service > called E2MD that contains a single string that holds ALL the > metadata). It proposes a new DDDS service called E2MD (not a new > ENUM service), which can be used to serve up sub-sets of meta-data > elements that are grouped by a Service-Type:SubType pair (not All the > metadata in a single string). Your number 3 below a *little* more > accurately captures what the draft is proposing. > Thanks, that's helpful. I've been a little sloppy on the difference between an ENUM service and a DDDS service -- the outside world seems to use the terms interchangeably, as in "any use of a NAPTR record to point to a phone number thingy". As I understand it, ENUM is a DDDS service more properly called E2U, and Bernie's proposal defines a new DDDS service E2M which has similar properties to E2U, except that the strings returned are metadata instead of URIs used to initiate a session. This proposal also extends the NAPTR syntax of RFC 2915 to add a "t" flag for "text" to get around the "data isn't a URI" debate. For each named metadata type, it uses a subtype name that attaches to the E2M service name to indicate that metadata type (ex. E2M+CNAM). For each metadata element (for example, a CNAM) there is one record in the DNS. Additional elements require additional records. Individual metadata elements are therefore size-limited by the fact that they're in a DNS record, which raises size issues for privacy protection techniques such as encryption. Does this more accurately match your read of Bernie's draft? Open question in my head: Why are we extending the RFC 2915 syntax with a "t" flag instead of using its "p" flag? There's probably a good reason, but it isn't apparent to me at the moment. -- Dean From dean.willis@softarmor.com Sat Mar 20 10:23:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAF03A69CC for ; Sat, 20 Mar 2010 10:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqhdBogJRdrR for ; Sat, 20 Mar 2010 10:23:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1AC0C3A6A7E for ; Sat, 20 Mar 2010 10:22:33 -0700 (PDT) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2KHMj5J015406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Mar 2010 12:22:47 -0500 Message-ID: <4BA50460.8090808@softarmor.com> Date: Sat, 20 Mar 2010 12:22:40 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jay Daley References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 17:23:44 -0000 Jay Daley wrote: > On 20/03/2010, at 8:03 AM, Dean Willis wrote: > >> We touched on this earlier, but got derailed by the "Why don't we >> just use HTTP for everything" question that Cullen did us the honor >> to ask. > > HONOR?!! Has this suddenly become the ITU while I had my back > turned? Sorry, too much Dumas in my childhood reading. Cullen's question was in the nature of something that starts a duel, making it a matter of honor. -- Dean From trutkowski@netmagic.com Sat Mar 20 10:51:38 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913E73A6867 for ; Sat, 20 Mar 2010 10:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.731 X-Spam-Level: * X-Spam-Status: No, score=1.731 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76TYB4GK+9RD for ; Sat, 20 Mar 2010 10:51:37 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 480A93A67F0 for ; Sat, 20 Mar 2010 10:51:37 -0700 (PDT) Received: from [192.168.0.173] ([unknown] [173.72.150.224]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KZL00FSDDM12AW2@vms173003.mailsrvcs.net> for e2md@ietf.org; Sat, 20 Mar 2010 12:51:41 -0500 (CDT) Message-id: <4BA50B29.5060407@netmagic.com> Date: Sat, 20 Mar 2010 13:51:37 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-version: 1.0 To: Dean Willis References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BA503F7.6020806@softarmor.com> In-reply-to: <4BA503F7.6020806@softarmor.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 17:51:38 -0000 Hi all, You should be thinking outside of the E164 box. the proposal is equally applicable to another major ITU-T namespace - OIDs - that are about to be instantiated in DNS exactly as has the E164 namespace. It is known as the OID Resolver proposal and about to be adopted by joint ISO/ITU-T action. Interestingly, the only existing means for doing any OID lookups for metadata is an HTTP adjunct that was built several years ago. See http://www.oid-info.com/ Many of those working in this area are looking forward to great things from the new IETF e2md effort. The operative focal point on the ITU-T side is a group known as Q.12/17 which manages the OID namespace standard together with ISO|IEC SC6. Among other things, the namespace is positioned to be the principal global home for providers (i.e., using IETF Enterprise Number OIDs), RFIDs, and eHealth objects, in addition to legacy uses like SNMP MIBs and X.509 certificate policies. --tony From richard@shockey.us Sat Mar 20 11:48:25 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCAA3A6967 for ; Sat, 20 Mar 2010 11:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.36 X-Spam-Level: X-Spam-Status: No, score=0.36 tagged_above=-999 required=5 tests=[AWL=-1.371, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jedm1fCPpIqs for ; Sat, 20 Mar 2010 11:48:24 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id C3EB43A6962 for ; Sat, 20 Mar 2010 11:48:22 -0700 (PDT) Received: (qmail 17206 invoked by uid 0); 20 Mar 2010 18:48:37 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 20 Mar 2010 18:48:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Er7Fy7EaWN/0qvQz2kTK6L4AOjPi+Vczq7XnBLlNTn8iMPiGZphOic/JWIb7KkdZasxh+tFPcLdqF75Mr7OAKtC+O92qShfiCZpi8vwV6g21V28bE+UAnmx9y/6Bw1oe; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nt3iv-0001hx-7X; Sat, 20 Mar 2010 12:48:37 -0600 From: "Richard Shockey" To: , "'Dean Willis'" References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BA503F7.6020806@softarmor.com> <4BA50B29.5060407@netmagic.com> In-Reply-To: <4BA50B29.5060407@netmagic.com> Date: Sat, 20 Mar 2010 14:48:32 -0400 Message-ID: <001b01cac85d$f17104b0$d4530e10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrIVgdgRkpDlMx2RBGiN4SWeTerFgAB4VUQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 18:48:25 -0000 Brother Tony! Identity .. sure there is certainly no limit to the kinds of things that can be defined here its just defining the protocol and a simple registration procedure like we did in the ENUM WG. E.164 is the low hanging fruit and some carrier need some specific things but the E.164 use case is a good start. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Saturday, March 20, 2010 1:52 PM To: Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata Hi all, You should be thinking outside of the E164 box. the proposal is equally applicable to another major ITU-T namespace - OIDs - that are about to be instantiated in DNS exactly as has the E164 namespace. It is known as the OID Resolver proposal and about to be adopted by joint ISO/ITU-T action. Interestingly, the only existing means for doing any OID lookups for metadata is an HTTP adjunct that was built several years ago. See http://www.oid-info.com/ Many of those working in this area are looking forward to great things from the new IETF e2md effort. The operative focal point on the ITU-T side is a group known as Q.12/17 which manages the OID namespace standard together with ISO|IEC SC6. Among other things, the namespace is positioned to be the principal global home for providers (i.e., using IETF Enterprise Number OIDs), RFIDs, and eHealth objects, in addition to legacy uses like SNMP MIBs and X.509 certificate policies. --tony _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From Ray.Bellis@nominet.org.uk Sat Mar 20 12:07:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2160C3A69C3 for ; Sat, 20 Mar 2010 12:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.245 X-Spam-Level: X-Spam-Status: No, score=-5.245 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8IjLtI7-KuO for ; Sat, 20 Mar 2010 12:07:27 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id B36AE3A691C for ; Sat, 20 Mar 2010 12:07:26 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=PABtcaAdDA8Sq+kcuqGOB70HozewBfhDaY2/9z5x+nfOoeAIe2+PElJS EhSwCr+2Qza4kdIP55bPPtXAImycJMrjavAvrvSw/SAHYSrAWHv6QdDl/ qYGFLrWNuSA0Wn0; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269112062; x=1300648062; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20HTTP=20as=20an=20adjunct=20to=20ENUM=20lookups=20for =20metadata|Date:=20Sat,=2020=20Mar=202010=2011:07:38=20- 0800|Message-ID:=20|To:=20Dean=20Willis =20|Cc:=20"E.164=20To=20MetaDa ta=20BOF=20discussion=20list"=20 |MIME-Version:=201.0|In-Reply-To:=20<4BA503F7.6020806@sof tarmor.com>|References:=20<6EA90E2C-9087-436F-9D22-916DA6 66C3B8@softarmor.com>=09<754963199212404AB8E9CFCA6C3D0CDA 0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com>=20<4BA503F7.6 020806@softarmor.com>; bh=0MLuUeIEem+31NM99lvUO+KiOLrDdexJELw60lu3xCo=; b=Bbo7Zm1dvFTUCDSTm+RkcqgGJdB032hvNWNYkfkP1fPBJxrfX5UHkyzC qrDaybDEhcbvaI+I11Iop54HtsrIStIL4V8icGa35V42pD/tePAlBGDgw dx+YB/gPrktY4zT; X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="17184205" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 20 Mar 2010 19:07:39 +0000 In-Reply-To: <4BA503F7.6020806@softarmor.com> References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BA503F7.6020806@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Sat, 20 Mar 2010 11:07:38 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 20/03/2010 07:07:38 PM, Serialize complete at 20/03/2010 07:07:38 PM Content-Type: multipart/alternative; boundary="=_alternative 0069115E882576EC_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 19:07:34 -0000 This is a multipart message in MIME format. --=_alternative 0069115E882576EC_= Content-Type: text/plain; charset="US-ASCII" > As I understand it, ENUM is a DDDS service more properly called E2U, and > Bernie's proposal defines a new DDDS service E2M which has similar > properties to E2U, except that the strings returned are metadata instead > of URIs used to initiate a session. This proposal also extends the NAPTR > syntax of RFC 2915 to add a "t" flag for "text" to get around the "data > isn't a URI" debate. For each named metadata type, it uses a subtype > name that attaches to the E2M service name to indicate that metadata > type (ex. E2M+CNAM). For each metadata element (for example, a CNAM) > there is one record in the DNS. Additional elements require additional > records. > > ... > > Does this more accurately match your read of Bernie's draft? Yes, exactly. Ray --=_alternative 0069115E882576EC_= Content-Type: text/html; charset="US-ASCII"
> As I understand it, ENUM is a DDDS service more properly called E2U, and
> Bernie's proposal defines a new DDDS service E2M which has similar
> properties to E2U, except that the strings returned are metadata instead
> of URIs used to initiate a session. This proposal also extends the NAPTR
> syntax of RFC 2915 to add a "t" flag for "text" to get around the "data
> isn't a URI" debate. For each named metadata type, it uses a subtype
> name that attaches to the E2M service name to indicate that metadata
> type (ex. E2M+CNAM). For each metadata element (for example, a CNAM)
> there is one record in the DNS. Additional elements require additional
> records.
>
> ...
>
> Does this more accurately match your read of Bernie's draft?
Yes, exactly.

Ray
--=_alternative 0069115E882576EC_=-- From lendl@nic.at Sat Mar 20 12:44:01 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBA83A67EE for ; Sat, 20 Mar 2010 12:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.559 X-Spam-Level: X-Spam-Status: No, score=0.559 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6hWIVNVqk9F for ; Sat, 20 Mar 2010 12:44:00 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 271EB3A68F7 for ; Sat, 20 Mar 2010 12:43:55 -0700 (PDT) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 662734C2F8 for ; Sat, 20 Mar 2010 20:44:09 +0100 (CET) Message-ID: <4BA5258C.8000600@nic.at> Date: Sat, 20 Mar 2010 20:44:12 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: e2md@ietf.org References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <33DFACFE-AB03-4622-B0A8-735409ADF662@cisco.com> <58B44719-9D31-4E0D-872C-F6CAF6B3F410@cisco.com> In-Reply-To: <58B44719-9D31-4E0D-872C-F6CAF6B3F410@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] What the IETF does and does not do X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 19:44:02 -0000 On 18.03.2010 21:56, Cullen Jennings wrote: > > So just to make sure I am understanding the deployments correctly for > the E2MD data, the hierarchal is important because in the practical > deployments will have a bunch of different administrative domains that > are responsible for metadata for different numbers. > IMHO this is one of the questions we need to ask right at the beginning. If the answer is no to Cullen's question, then we don't make use of one of DNS' primary features, making perhaps other solutions better suited. Let's be a bit more systematic about those questions. Q1 (Cullen): Will parts of the namespace be handled by different entities? Richard Shockey wrote: > In the classic E.164 world there is, sometimes, a marked preference for > knowing everything you can locally and demanding that that the response > to a query be done in 120ms. >From that I'd derive: Q2 (Richard): Do we need guaranteed response times for queries? Also from Richard: > you could do it in ENUM if Hadriel Kaplan's source URI draft were > adopted. Q3 (Richard): Will answers depend on who's asking the question? (can't remember who) Q4: Who will query for e2md data? User-owned devices like phones or softswitches/SBCs/SIP-proxies which are inside the SSP's network and are managed by the SSP? Also, in a mobile endpoint scenario, will the query be over the long latency link of a cell-phone? Q5: Do we absolutely want to piggyback on ENUM's NAPTR lookup? Q6: Even in a non-public scenario, will we expect live queries across administrative boundaries or will local databases/caches be synced up-front so that no actual query needs to be passed between SSPs? In other words, do we actually need the delegation/recursion feature of the DNS, or would we better be served by some sort of directory synchronization scheme superior to the AXFR/IXFR simpletons of the DNS? Or, would the next point after the e2md WG then be a drinks-like WG which then talks about how to provision these directories and how to distribute and synchronize them? ------------------- Personally, I think the approach outlined by Bernie's draft has merit. But we are all old DNS hands and I'd very much like to evaluate whether we have chosen DNS because of rational arguments, or just because it's our default solution for everything. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From lconroy@insensate.co.uk Sat Mar 20 14:15:56 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508413A688F for ; Sat, 20 Mar 2010 14:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXH3GDjq5uJH for ; Sat, 20 Mar 2010 14:15:55 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 381793A67B4 for ; Sat, 20 Mar 2010 14:15:55 -0700 (PDT) Received: from [127.0.0.1] (unknown [127.0.0.3]) by insensate.co.uk (Postfix) with ESMTP id 7412111875C; Sat, 20 Mar 2010 21:16:08 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Sat, 20 Mar 2010 21:16:08 +0000 Content-Transfer-Encoding: 7bit Message-Id: <3BF26E3C-C996-4215-8411-276151E473AA@insensate.co.uk> References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA0D89424859@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BA503F7.6020806@softarmor.com> To: Dean Willis , Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 21:15:56 -0000 Hi Folks, Spot on ... With the minor clarification that this is NOT anything to do with RFC2915 -- that was obsoleted years ago. It was replaced by RFCs 3401-3405. RFC2915 (and 2916) were considered too sloppy (or short :), so we ended up with the Bible written in High Martian that is RFC 340x. E2MD is going to be a new DDDS application (specified in keeping with the template in RFC3402). It uses the DNS as its database, with rules formatted as NAPTR resource records, both as specified in RFC3403 (which is the doc that deep sixed RFC2915). Re. just using the 'p' flag ... good point, but I'm not sure anyone knows what "application specific and outside the scope of this document" means. The text talks about the protocol part of the services field -- we don't have such a part any more, and it also says that DDDS processing stops when a record with this flag is processed, which is at least dodgy. Section 4.3 of RFC3404 (where that flag is "defined") needs a "review with menaces" anyway -- it goes on to reserve all alphabetical flags for "this specification", which is patent tosh. all the best, Lawrence On 20 Mar 2010, at 19:07, Ray.Bellis@nominet.org.uk wrote: >> As I understand it, ENUM is a DDDS service more properly called E2U, and >> Bernie's proposal defines a new DDDS service E2M which has similar >> properties to E2U, except that the strings returned are metadata instead >> of URIs used to initiate a session. This proposal also extends the NAPTR >> syntax of RFC 2915 to add a "t" flag for "text" to get around the "data >> isn't a URI" debate. For each named metadata type, it uses a subtype >> name that attaches to the E2M service name to indicate that metadata >> type (ex. E2M+CNAM). For each metadata element (for example, a CNAM) >> there is one record in the DNS. Additional elements require additional >> records. >> >> ... >> >> Does this more accurately match your read of Bernie's draft? > > Yes, exactly. > > Ray > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From bernie@ietf.hoeneisen.ch Sat Mar 20 15:24:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0FC93A6849 for ; Sat, 20 Mar 2010 15:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-1.657, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9C1QRCp4FVP for ; Sat, 20 Mar 2010 15:24:27 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 35BCB3A683D for ; Sat, 20 Mar 2010 15:24:26 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nt75z-0007dr-UW; Sat, 20 Mar 2010 23:24:40 +0100 Date: Sat, 20 Mar 2010 23:24:39 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Dean Willis In-Reply-To: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> Message-ID: References: <6EA90E2C-9087-436F-9D22-916DA666C3B8@softarmor.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] HTTP as an adjunct to ENUM lookups for metadata X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 22:24:29 -0000 Hi Dean et al. On Fri, 19 Mar 2010, Dean Willis wrote: > Current proposals as I understand them call for either: > > 1) encoding metadata into a "data" URI (which is considered pretty hokey by > the URI people, as the hunk of data is NOT universal, and while it may be a > resource, it's not an indicator and also isn't used to initiate a > communications session directly, making it inconsistent with the "u" flag in > the Naptr record). As you say this has not worked out > 2) creating a new Enumservice name, like "E2MD", This is _not_ about a new Enumservice, but about a new DDDS application. E2MD specififies a framework that allows to register E2MD services. Each E2MD service will go through Expert Review and Specification Required process (RFC 5226). Pretty much the same way as we go with Enumservices. > that can return a text string containing the metadata (the basic model > in draft-hoeneisen-e164-to-metadata-02). Currently, the expressible > range of metadata is unbounded by this draft; the same string holds ALL > the metadata elements, presumably in a syntactically delimited form > something like name-value pairs. Each E2MD service registration must set these boundaries. If a E2MD service registration tries to keep it unbounded, the expert is unlikely to accept the proposal (there will be guidance in the base spec about this). > In some use cases, there is arguably a need to privacy-protect some of > the values, so we might have to encrypt some of them. This raises key > management questions. Privacy also must be addressed with each E2MD service registration. > 3) Creating a new Enumservice for each type of metadata, and encoding the > metadata appropriately. AFAIk, we haven't talked about this one much yet If I understand you correctly, here you are talking about the E2MD service registration as described above. > 4) draft-hoeneisen-e164-to-metadata-02 also allows for the returned string to > be an absolute URI. We're not exactly sure what this URI has in it, yet. This is intentional to allow the 'indirection' case, where a URI is returned, and the actual metadata can be retrieved using this URI. In some cases this is the only way to go, in particular if the metadata returend is going to be large and/or if answers to queries are source dependend and/or if privacy issues can not be addressed by other means. cheers, Bernie From bernie@ietf.hoeneisen.ch Sun Mar 21 11:00:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0573A682E for ; Sun, 21 Mar 2010 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=-1.538, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6w-rmjB6XV8 for ; Sun, 21 Mar 2010 11:00:54 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 8276A3A6784 for ; Sun, 21 Mar 2010 11:00:54 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NtPSX-0004uN-Jc for e2md@ietf.org; Sun, 21 Mar 2010 19:01:09 +0100 Date: Sun, 21 Mar 2010 19:01:09 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Proposed charter finalized X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:00:55 -0000 Hi E2MD BoF participants, I have finalized the proposed charter and uploaded it to the meeting materials pages: https://datatracker.ietf.org/meeting/77/materials.html alternatively you can download it form http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt I have consolidated the charter by structuring it in more logical way, rearranging sections and paragraphes, removing redundant (doubled) text and using terms more consistently. These changes are generally editorial, i.e. I did not add or remove any relevant content since the last version. We are still open for feedback, preferrably _before_ the BoF rather than only during the BoF, as our BoF time is very limited. cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization From kcartwright@tnsi.com Mon Mar 22 11:59:59 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA83D3A67F9 for ; Mon, 22 Mar 2010 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.649 X-Spam-Level: * X-Spam-Status: No, score=1.649 tagged_above=-999 required=5 tests=[AWL=-2.815, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5znJ8uNeRcIP for ; Mon, 22 Mar 2010 11:59:58 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 2A8163A67A3 for ; Mon, 22 Mar 2010 11:59:54 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41696818; Mon, 22 Mar 2010 14:59:48 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 22 Mar 2010 14:59:48 -0400 From: "Cartwright, Kenneth" To: Bernie Hoeneisen , E.164 To MetaData BOF discussion list Date: Mon, 22 Mar 2010 14:59:46 -0400 Thread-Topic: [e2md] Proposed charter finalized Thread-Index: AcrJIIRpo3AZkNRqTgatMrFuU9QDBgAzS/uW Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D891E0B4F@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] Proposed charter finalized X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 18:59:59 -0000 A few questions and comments about draft-hoeneisen-e164-to-metadata-02: 0) This is a very nice document. 1) I don't recall seeing anything in the E2M draft about specifying E2M ser= vice names that are identical to E2U service names. I know that, technical= ly speaking, this is not an issue due to the fact that the E2M name space i= t separte from E2U. However, I think that in practice is may be good to ex= plicitly state whether or not this is allowed. I think it should not be al= lowed. Iow, we should not be allowed to create an E2M service type called = "SIP", or an E2M service called "EMAIL". Allowing this would create confus= ion about what it means to create an E2M 2) Should some guidance be added into the draft that more tighly specified = when an E2M service type should be created, as apposed to the two alternati= ves: (1) embedding URI parameters into E2U services, (2) creating a new E2U= service? At a minumum, this is something that needs to be on the top of t= he expert reviewer's checklist of considerations in evaluating the E2M serv= ice types. 3) Section 1.2 of the spec refers to the "send-n" service proposal, however= , "send-n" is not mentioned in the charter (while cnam and unused are). Is= there a reson for this? 4) Section 3.1. I'm not sure why the "Note:" is in there. This seems to b= e just one boudary conditions that can be specified in the abnf. And given= that you show this one in the examples, the "Note:" here seems un-necessar= y and a bit arpitrary. 5) Section 3.3 4th Paragraph: The statement "followed by one or more E2MD = services which indicate the class of functionality a given end point offer= s." seems perhaps to be a copy past from something that was talking about E= NUM. As I understand it, the data content of E2MD services do not necessar= ily speak to the class of functionality of the end points. They speak to a= ny number of characteristics of the end point (the calling name of the TN, = whether or not the TN is in use, etc, etc). 6) Section 4.1.1 Paragraph 3: The statement "The E2MD registration MAY be = specified to be always empty" I think seems to imply something that is not = intended, that an E2MD registration may be empty. This could be reworded t= o indicate that the abnf specification for and E2MD service registration ca= n be specificed to indicate that the replacement string is always empty. 7) Sectinon 6.4 - I'm not sure I understand what is meant by the sentance i= n this section. What exactly needs further consideration? Changes to sect= ions 11.4 and 11.8 in the ENUM service Guide as a result of the introductio= n of E2M? Thanks. Ken ________________________________________ From: e2md-bounces@ietf.org [e2md-bounces@ietf.org] On Behalf Of Bernie Hoe= neisen [bernie@ietf.hoeneisen.ch] Sent: Sunday, March 21, 2010 2:01 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Proposed charter finalized Hi E2MD BoF participants, I have finalized the proposed charter and uploaded it to the meeting materials pages: https://datatracker.ietf.org/meeting/77/materials.html alternatively you can download it form http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt I have consolidated the charter by structuring it in more logical way, rearranging sections and paragraphes, removing redundant (doubled) text and using terms more consistently. These changes are generally editorial, i.e. I did not add or remove any relevant content since the last version. We are still open for feedback, preferrably _before_ the BoF rather than only during the BoF, as our BoF time is very limited. cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Mon Mar 22 12:07:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2613A6880 for ; Mon, 22 Mar 2010 12:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEXz+9g8ZGwA for ; Mon, 22 Mar 2010 12:07:19 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id B21333A67F9 for ; Mon, 22 Mar 2010 12:07:18 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41697128; Mon, 22 Mar 2010 15:07:22 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.219]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 22 Mar 2010 15:07:22 -0400 From: "Cartwright, Kenneth" To: Bernie Hoeneisen , E.164 To MetaData BOF discussion list Date: Mon, 22 Mar 2010 15:07:21 -0400 Thread-Topic: [e2md] Proposed charter finalized Thread-Index: AcrJIIRpo3AZkNRqTgatMrFuU9QDBgAyVucq Message-ID: <754963199212404AB8E9CFCA6C3D0CDA0D891E0B4E@TNS-MAIL-NA.win2k.corp.tnsi.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] Proposed charter finalized X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 19:07:20 -0000 Just to add in another $.02 of support on E2MD before the BOF ... The Good -------------- 1) E2MD utilizes the hierarchical structure of the DDDS model to segregate= non-address URI information into its own name space hierarchy separate fro= m the E2U namespace. This has a price, but it keep the purpose of the E2U n= amespace more succinct and its use cases clearer. 2) E2MD leverages technologies that exist and are in very wide use in the t= arget industries (DNS, NAPTRs, ENUM Resolvers). 3) E2MD is relatively simple. 4) E2MD utilizes the nice meta-model of =93create the high-level structure = and leave the low-level structure up to the implementers=94 . This is the = DDDS model. 5) E2MD leverages the ENUM management structure and process for proposing, = specifying, reviewing, discovering, and archiving E2M services. 6) E2MD has a clear technical and procedural adoptin path into existing sys= tems that today query for and return TN data via ENUM. 7) E2MD charter explicitly leaves the data access controls, security needs = and policies primarily up to the operators, service authors, and service re= viewers, rather than attempting, in vain, to lock these in at a macro level= up front. 8) E2MD inherently aids the solution to the problem of "too many larger res= ource reords in the response to an ENUM query". There Are Always Tradeoffs to Live With (these are nits and carry overs fro= m the nature of ENUM and DDDS) ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -- 1) Questions will ocassionally arise about whether or not a given service s= hould be an E2M service or an E2U service, or a URI parameter embedded with= in an E2U URI. Unless I missed it, I do not recall seeing any guidance abo= ut these questions in the E2MD spec. But at least having E2M give us anoth= er tool in our arsenal to address this. 2) Not yet a standard way to do source identification in DNS. But that ca= n be solved going forward, outside of the direct E2MD problem space (H Kapl= an has a draft). And in the field this is already being done on a wide sca= le basis using non-standardized schemes, and nothing in the E2MD charter of= spec makes this somehow "illegal". And of courese there is always the "re= turn a URL pointing to the data and apply AAA there" (but that approach can= have trade-offs that can be too much to bear so will only be practical und= er some use cases). 3) Payload in DNS is relatively small. But that seems to be ok (and probab= ly even a good thing) for the use cases that we can think of. And for thos= e that it is not Ok, a URL can be returned that points the querier to the l= ocation of the data. 4) Only domain names can be lookup keys. But since we are talking about TN= s in the use cases envisioned so far, and we have ENUM's first well defined= rule, that=92s ok. After all it is called _E_2M. On the other hand, won'= t we want to, someday, lookup a calling name for somebody@somedomain.com? = But I think that's a problem for a different venue at a different time. Or= maybe there is work underway on that front that I am not aware of. I've a= lways thought it was interesting that we, a long time ago, decided to turn = TNs into domain names, just to be able to look up information about them. = :-) It's pretty funny when you think asbout it. ENUM and DDDS of course d= id not have to be constructed that way. But it was, and people wanted to u= se bind, and that's water long ago under the bridge. No need to respond to these minor trade-offs. I think they are just that, = minor tradeoffs. Ken ________________________________________ From: e2md-bounces@ietf.org [e2md-bounces@ietf.org] On Behalf Of Bernie Hoe= neisen [bernie@ietf.hoeneisen.ch] Sent: Sunday, March 21, 2010 2:01 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Proposed charter finalized Hi E2MD BoF participants, I have finalized the proposed charter and uploaded it to the meeting materials pages: https://datatracker.ietf.org/meeting/77/materials.html alternatively you can download it form http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt I have consolidated the charter by structuring it in more logical way, rearranging sections and paragraphes, removing redundant (doubled) text and using terms more consistently. These changes are generally editorial, i.e. I did not add or remove any relevant content since the last version. We are still open for feedback, preferrably _before_ the BoF rather than only during the BoF, as our BoF time is very limited. cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From HKaplan@acmepacket.com Mon Mar 22 12:37:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2673A6A01 for ; Mon, 22 Mar 2010 12:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keLUxe7DX-mF for ; Mon, 22 Mar 2010 12:37:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B95F63A69C7 for ; Mon, 22 Mar 2010 12:37:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 22 Mar 2010 15:37:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 22 Mar 2010 15:37:43 -0400 From: Hadriel Kaplan To: Jim Reid , Dean Willis Date: Mon, 22 Mar 2010 15:37:28 -0400 Thread-Topic: [e2md] privacy of NAPTRs Thread-Index: AcrG5KqRTlIprKOyTLWp5mcvhlIGzQDDOCIA Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD19C7@mail> References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> <4BA28545.1020901@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 19:37:31 -0000 Ohhh, nice. We were looking at submitting a draft on a very similar thing for a differe= nt purpose. One question on your draft: why is "x-crypto" an enumservice type, as oppos= ed to a sub-type? I.e., why is it 'E2U+X-crypto:data:8210' and not 'E2U+si= p:x-crypto:data:8210' or some such? I ask because: 1) I want to know that the URI is a sip one before I bother decrypting it,= so I don't have to try to decrypt ones I don't care about/don't support 2) We may make the crypto keys different for some service types, for examp= le a cnam might use a different one than sip(because it has a different set= of allowed viewers), and so it would produce decrypt failures if each reco= rd has to be decrypted to determine what type it is. -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Jim Reid > Sent: Thursday, March 18, 2010 5:47 PM >=20 > I think it could be. For the E2MD process, just define a suitable > NAPTR service type and a data URI and we're done. Or if this list > would be prepared to run with > http://tools.ietf.org/html/draft-timms-encrypt-naptr-01 > we're already done. :-) >=20 > The issues of managing keys and provisioning the encrypted NAPTRs is > of course left as an exercise for the reader. :-) From bernie@ietf.hoeneisen.ch Mon Mar 22 13:40:38 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F17C3A6A14 for ; Mon, 22 Mar 2010 13:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.362 X-Spam-Level: * X-Spam-Status: No, score=1.362 tagged_above=-999 required=5 tests=[AWL=-3.102, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoDgjuhKCKfU for ; Mon, 22 Mar 2010 13:40:37 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id DDDB23A68E0 for ; Mon, 22 Mar 2010 13:40:36 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NtoQd-0002JM-UQ; Mon, 22 Mar 2010 21:40:52 +0100 Date: Mon, 22 Mar 2010 21:40:51 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA0D891E0B4F@TNS-MAIL-NA.win2k.corp.tnsi.com> Message-ID: References: <754963199212404AB8E9CFCA6C3D0CDA0D891E0B4F@TNS-MAIL-NA.win2k.corp.tnsi.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Proposed charter finalized X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 20:40:38 -0000 Hi Ken Thanks for your comments on the early draft of a possible e2md solution (draft-hoeneisen-e164-to-metadata-02). We'll consider those once the E2MD WG is formed. cheers, Bernie On Mon, 22 Mar 2010, Cartwright, Kenneth wrote: > A few questions and comments about draft-hoeneisen-e164-to-metadata-02: > > 0) This is a very nice document. > > 1) I don't recall seeing anything in the E2M draft about specifying E2M > service names that are identical to E2U service names. I know that, > technically speaking, this is not an issue due to the fact that the E2M > name space it separte from E2U. However, I think that in practice is > may be good to explicitly state whether or not this is allowed. I think > it should not be allowed. Iow, we should not be allowed to create an > E2M service type called "SIP", or an E2M service called "EMAIL". > Allowing this would create confusion about what it means to create an > E2M > > 2) Should some guidance be added into the draft that more tighly > specified when an E2M service type should be created, as apposed to the > two alternatives: (1) embedding URI parameters into E2U services, (2) > creating a new E2U service? At a minumum, this is something that needs > to be on the top of the expert reviewer's checklist of considerations in > evaluating the E2M service types. > > 3) Section 1.2 of the spec refers to the "send-n" service proposal, > however, "send-n" is not mentioned in the charter (while cnam and unused > are). Is there a reson for this? > > 4) Section 3.1. I'm not sure why the "Note:" is in there. This seems > to be just one boudary conditions that can be specified in the abnf. > And given that you show this one in the examples, the "Note:" here seems > un-necessary and a bit arpitrary. > > 5) Section 3.3 4th Paragraph: The statement "followed by one or more > E2MD services which indicate the class of functionality a given end > point offers." seems perhaps to be a copy past from something that was > talking about ENUM. As I understand it, the data content of E2MD > services do not necessarily speak to the class of functionality of the > end points. They speak to any number of characteristics of the end > point (the calling name of the TN, whether or not the TN is in use, etc, > etc). > > 6) Section 4.1.1 Paragraph 3: The statement "The E2MD registration MAY > be specified to be always empty" I think seems to imply something that > is not intended, that an E2MD registration may be empty. This could be > reworded to indicate that the abnf specification for and E2MD service > registration can be specificed to indicate that the replacement string > is always empty. > > 7) Sectinon 6.4 - I'm not sure I understand what is meant by the > sentance in this section. What exactly needs further consideration? > Changes to sections 11.4 and 11.8 in the ENUM service Guide as a result > of the introduction of E2M? > > Thanks. > Ken > > ________________________________________ > From: e2md-bounces@ietf.org [e2md-bounces@ietf.org] On Behalf Of Bernie Hoeneisen [bernie@ietf.hoeneisen.ch] > Sent: Sunday, March 21, 2010 2:01 PM > To: E.164 To MetaData BOF discussion list > Subject: [e2md] Proposed charter finalized > > Hi E2MD BoF participants, > > I have finalized the proposed charter and uploaded it to the meeting > materials pages: > > https://datatracker.ietf.org/meeting/77/materials.html > > > alternatively you can download it form > > http://ucom.ch/ietf/e2md-bof/e2md-proposed-charter.txt > > > I have consolidated the charter by structuring it in more logical way, > rearranging sections and paragraphes, removing redundant (doubled) text > and using terms more consistently. > > These changes are generally editorial, i.e. I did not add or remove any > relevant content since the last version. > > We are still open for feedback, preferrably _before_ the BoF rather than > only during the BoF, as our BoF time is very limited. > > cheers, > Bernie > > -- > > http://ucom.ch/ > Tech Consulting for Internet Standardization > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > This e-mail message is for the sole use of the intended recipient(s)and may > contain confidential and privileged information of Transaction Network Services. > Any unauthorised review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > > From jim@rfc1035.com Mon Mar 22 14:15:36 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652593A69FC for ; Mon, 22 Mar 2010 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[AWL=-1.527, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9qPwvJcSKrk for ; Mon, 22 Mar 2010 14:15:35 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id CE1DF28C17C for ; Mon, 22 Mar 2010 14:10:21 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 57226154208B; Mon, 22 Mar 2010 21:10:37 +0000 (GMT) Message-Id: <6759017E-3ABA-4F42-BBC5-8527CAD9CF92@rfc1035.com> From: Jim Reid To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD19C7@mail> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 21:10:36 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> <4BA28545.1020901@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD19C7@mail> X-Mailer: Apple Mail (2.936) Cc: "e2md@ietf.org" Subject: Re: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 21:15:36 -0000 On 22 Mar 2010, at 19:37, Hadriel Kaplan wrote: > One question on your draft: why is "x-crypto" an enumservice type, > as opposed to a sub-type? Extra privacy. We did not want to disclose that an encrypted NAPTR contained a particular URI. We felt that the trade-off of doing extra, possibly unnecessary, decryptions was worth it. Your mileage may vary. The scheme used in .tel is to have a subdomain for each friend containing the encrypted NAPTR RRset the domain holder makes available to that friend. Although the names of these subdomains are not readily guessed, it was felt it would be bad if one friend could figure out if another friend got different (better) types of contact from the domain holder. If the URI was a subtype of x-crypto, you might find that I've provisioned an encrypted SIP URI for Dean under mumble.jim.tel but not for you, my best buddy, under foobar.jim.tel. That could be embarrassing for me. And you. And Dean. From jim@rfc1035.com Mon Mar 22 15:53:17 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E332128C1C5 for ; Mon, 22 Mar 2010 15:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.459 X-Spam-Level: X-Spam-Status: No, score=0.459 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w04ty6GOS0sI for ; Mon, 22 Mar 2010 15:53:17 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 3BFF328C1CA for ; Mon, 22 Mar 2010 15:53:12 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 309CB154208B; Mon, 22 Mar 2010 22:53:28 +0000 (GMT) Message-Id: <0E86C9EF-16B2-49C1-8BBD-FC159D66844D@rfc1035.com> From: Jim Reid To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD19C7@mail> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 22 Mar 2010 22:53:27 +0000 References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> <4BA28545.1020901@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD19C7@mail> X-Mailer: Apple Mail (2.936) Cc: "e2md@ietf.org" Subject: Re: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 22:53:18 -0000 On 22 Mar 2010, at 19:37, Hadriel Kaplan wrote: > 2) We may make the crypto keys different for some service types, > for example a cnam might use a different one than sip(because it has > a different set of allowed viewers), and so it would produce decrypt > failures if each record has to be decrypted to determine what type > it is. The scheme used in .tel provisions a public/private key pair for each owner-name. So how about extending the owner-name for provisioning service types? ie Something like: sip.telco1.foo.bar. NAPTR x-crypto:blah0 cnam.telco1.foo.bar NAPTR x-crypto:blah1 sip.telco2.foo.bar. NAPTR x-crypto:blah2 cnam.telco2.foo.bar NAPTR x-crypto:blah3 Add syntactic sugar to taste... Of course this means more key pairs to manage and handshake. But that might be an acceptable trade-off if you want to prevent multiple decrypts and need to avoid subtyping the x-crypto service type. BTW, subtyping eats into the encrypted payload. Which was another motivation for not doing that, particularly with more x- type qualifiers: for instance "E2U+voice:tel+x-lbl:Office+x-pager". From dean.willis@softarmor.com Mon Mar 22 19:14:51 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9093A69B2 for ; Mon, 22 Mar 2010 19:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.246 X-Spam-Level: * X-Spam-Status: No, score=1.246 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyJVUAJv4ymu for ; Mon, 22 Mar 2010 19:14:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 271633A6968 for ; Mon, 22 Mar 2010 19:14:48 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2N2F2N0005451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Mar 2010 21:15:04 -0500 Message-ID: <4BA82426.9010105@softarmor.com> Date: Mon, 22 Mar 2010 21:15:02 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jim Reid References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> <4BA28545.1020901@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD19C7@mail> <0E86C9EF-16B2-49C1-8BBD-FC159D66844D@rfc1035.com> In-Reply-To: <0E86C9EF-16B2-49C1-8BBD-FC159D66844D@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "e2md@ietf.org" Subject: Re: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 02:14:52 -0000 Jim Reid wrote: > On 22 Mar 2010, at 19:37, Hadriel Kaplan wrote: > >> 2) We may make the crypto keys different for some service types, >> for example a cnam might use a different one than sip(because it has a >> different set of allowed viewers), and so it would produce decrypt >> failures if each record has to be decrypted to determine what type it is. > > The scheme used in .tel provisions a public/private key pair for each > owner-name. So how about extending the owner-name for provisioning > service types? ie Something like: > > sip.telco1.foo.bar. NAPTR x-crypto:blah0 > cnam.telco1.foo.bar NAPTR x-crypto:blah1 > sip.telco2.foo.bar. NAPTR x-crypto:blah2 > cnam.telco2.foo.bar NAPTR x-crypto:blah3 > > Add syntactic sugar to taste... > > Of course this means more key pairs to manage and handshake. But that > might be an acceptable trade-off if you want to prevent multiple > decrypts and need to avoid subtyping the x-crypto service type. BTW, > subtyping eats into the encrypted payload. Which was another motivation > for not doing that, particularly with more x- type qualifiers: for > instance "E2U+voice:tel+x-lbl:Office+x-pager". > This sounds reasonable to me. One of the big concerns with E2MD is the payload size, and Bernie's approach of putting one type/subtype per NAPTR, while it requires more records, increases the payload per record. Your suggestion also allows differentiated access control for each data type. For example, someone might have the key for CNAM within a network, but not have the key for some other record type. -- Dean From HKaplan@acmepacket.com Mon Mar 22 19:20:01 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E34B53A672E for ; Mon, 22 Mar 2010 19:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.031 X-Spam-Level: *** X-Spam-Status: No, score=3.031 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDBTU5lf107t for ; Mon, 22 Mar 2010 19:20:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 069553A68DF for ; Mon, 22 Mar 2010 19:19:56 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 22 Mar 2010 22:20:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 22 Mar 2010 22:20:14 -0400 From: Hadriel Kaplan To: Jim Reid Date: Mon, 22 Mar 2010 22:20:09 -0400 Thread-Topic: [e2md] privacy of NAPTRs Thread-Index: AcrKEobqxbN58SngQNmhmA0cBiF4+QAFp/PQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1A4F@mail> References: <773A981B-0F0A-4B3C-87D4-49B34BAF402F@cisco.com> <27C46C43-3BD0-44BF-A319-9B71CACFDDF3@softarmor.com> <010f01cac6ae$bb16e750$3144b5f0$@us> <4BA24882.7000808@softarmor.com> <3ECA06D6-39B0-42F4-ADAB-DE825DCDD3EE@rfc1035.com> <4BA28545.1020901@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD19C7@mail> <0E86C9EF-16B2-49C1-8BBD-FC159D66844D@rfc1035.com> In-Reply-To: <0E86C9EF-16B2-49C1-8BBD-FC159D66844D@rfc1035.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] privacy of NAPTRs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 02:20:01 -0000 > -----Original Message----- > From: Jim Reid [mailto:jim@rfc1035.com] > Sent: Monday, March 22, 2010 6:53 PM >=20 > On 22 Mar 2010, at 19:37, Hadriel Kaplan wrote: >=20 > > 2) We may make the crypto keys different for some service types, > > for example a cnam might use a different one than sip(because it has > > a different set of allowed viewers), and so it would produce decrypt > > failures if each record has to be decrypted to determine what type > > it is. >=20 > The scheme used in .tel provisions a public/private key pair for each > owner-name. So how about extending the owner-name for provisioning > service types? ie Something like: >=20 > sip.telco1.foo.bar. NAPTR x-crypto:blah0 > cnam.telco1.foo.bar NAPTR x-crypto:blah1 > sip.telco2.foo.bar. NAPTR x-crypto:blah2 > cnam.telco2.foo.bar NAPTR x-crypto:blah3 We could do that, but it gets kinda fugly. We've got operators with NAPTR = separate NAPTR entries for voicemail/voicemsg, "normal" sip, h323, pstn, an= d cnam. We could have them separate those into separate roots per service = type, but then for a normal call we'd have to do multiple queries. And rig= ht now we let the operator define the service-types they want to follow/use= /try from the NAPTR responses, but we get the whole list back from the DNS/= ENUM server from that one query which is optimal in many ways. Like we can= fallback to a voicemail route if the primary sip/h323 don't pan out, witho= ut doing more queries. And for the operator, for the void/unused case, the= y'd have to have an unused entry for each root. No biggie though - your needs are such that you need to hide the service-ty= pe, which is what you need - it's just experimental and individual, so to e= ach his own there. :) > BTW, > subtyping eats into the encrypted payload. Which was another > motivation for not doing that, particularly with more x- type > qualifiers: for instance "E2U+voice:tel+x-lbl:Office+x-pager". Yes, we've been worried about the record size problem in general with encry= pting it. -hadriel From dean.willis@softarmor.com Mon Mar 22 23:37:51 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D893A69CA for ; Mon, 22 Mar 2010 23:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zg4vdPYdEQ0 for ; Mon, 22 Mar 2010 23:37:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 00A423A69A3 for ; Mon, 22 Mar 2010 23:37:50 -0700 (PDT) Received: from localhost.localdomain (mobile-032-169-054-106.mycingular.net [32.169.54.106] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2N6c2FP007159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Mar 2010 01:38:08 -0500 X-User-Agent: K-9 Mail for Android Content-Type: multipart/mixed; boundary="----MGCNMFPOJLS3SIE5ROP5PTC4PLASJU" MIME-Version: 1.0 From: Dean Willis Date: Mon, 22 Mar 2010 23:37:54 -0700 To: e2md@ietf.org Message-ID: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> Subject: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 06:37:51 -0000 ------MGCNMFPOJLS3SIE5ROP5PTC4PLASJU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBoYXZlIHJvdWdoZWQgb3V0IHNvbWUgb3BlbiBpc3N1ZXMgc2xpZGVzIGZvciB0aGUgZTJtZCBi b2YuIEkgYmVsaWV2ZSBsaXN0IGRpc2N1c3Npb24gaGFzIGdlbmVyYXRlZCBhIHJlYXNvbmFibGUg cHJvcG9zYWwgZm9yIGVhY2guIFBsZWFzZSByZXZpZXcgQVNBUC4KClRoYW5rcyAKCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMTBtYXIvc2xpZGVzL2UybWQtMy5wZGYKIAotLSAKRGVh biBXaWxsaXM= ------MGCNMFPOJLS3SIE5ROP5PTC4PLASJU-- From jim@rfc1035.com Tue Mar 23 03:52:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29523A6C45 for ; Tue, 23 Mar 2010 03:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0z7Ssj7hICt for ; Tue, 23 Mar 2010 03:52:54 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 1BF233A6B76 for ; Tue, 23 Mar 2010 03:39:31 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 5EE66154208B; Tue, 23 Mar 2010 10:39:48 +0000 (GMT) Message-Id: <80319B17-C801-4380-820A-272FED3B6A30@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Mar 2010 10:39:47 +0000 References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 10:52:54 -0000 On 23 Mar 2010, at 06:37, Dean Willis wrote: > I have roughed out some open issues slides for the e2md bof. I > believe list discussion has generated a reasonable proposal for > each. Please review ASAP. Dean, the slides look fine to me. Thanks. I'd quibble about the DNS payload concerns though. Just about every DNS implementation does EDNS0 these days. [It's needed for DNSSEC as well as being generally useful.] So there shouldn't be an issue here on DNS response size: just mandate EDNS0 with a minimum buffer size of 2KB or whatever. One thing to remember about EDNS0 is a lot of CPE middleware boxes are broken and drop or mangle these packets. Ray can give you chapter and verse about that. From dhc2@dcrocker.net Tue Mar 23 07:50:06 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC07A3A689D for ; Tue, 23 Mar 2010 07:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWC7QygOm0y3 for ; Tue, 23 Mar 2010 07:50:05 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 1CD173A6C00 for ; Tue, 23 Mar 2010 07:49:56 -0700 (PDT) Received: from [130.129.28.8] (dhcp-wireless-open-abg-28-8.meeting.ietf.org [130.129.28.8]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o2NEo7nn027934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 07:50:14 -0700 Message-ID: <4BA8D3D5.9050906@dcrocker.net> Date: Tue, 23 Mar 2010 07:44:37 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dean Willis References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> In-Reply-To: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10611/Tue Mar 23 05:01:31 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 23 Mar 2010 07:50:15 -0700 (PDT) Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 14:50:06 -0000 On 3/22/2010 11:37 PM, Dean Willis wrote: > I have roughed out some open issues slides for the e2md bof. I believe list discussion has generated a reasonable proposal for each. Please review ASAP. Folks, The security-related bullets look reasonable, but my guess is that they are missing what's needed. So, for example, saying 'encryption' always sounds plausible when referencing security, but it probably does not apply, here. Encryption means privacy, but I suspect that privacy (against wire-tapping) is not a major concern for this use. It is more likely that the necessary security function will be authorization -- hence, authentication and access control are the relevant mechanisms. Perhaps all such cases are satisfied by using a DNS that is on a controlled-access net. If not, then adding these mechanisms is non-trivial and probably worth pursuing generically, rather than waiting for a specific use case. I say that because the nature of the data that has been discussed on the list sounded like the type that will lead to a need for authorization and because Internet-scale authorization is a challenge. (I believe it's never been done.) If it is ever a requirement to provide it, it needs to be explored now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dean.willis@softarmor.com Tue Mar 23 09:56:00 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4393A6D3F for ; Tue, 23 Mar 2010 09:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q54yTsBgYAsC for ; Tue, 23 Mar 2010 09:55:58 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C859F3A68C8 for ; Tue, 23 Mar 2010 09:55:55 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NGu6uC012799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 11:56:08 -0500 Message-ID: <4BA8F2A5.3010609@softarmor.com> Date: Tue, 23 Mar 2010 11:56:05 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> In-Reply-To: <4BA8D3D5.9050906@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:56:00 -0000 Dave CROCKER wrote: > It is more likely that the necessary security function will be > authorization -- hence, authentication and access control are the > relevant mechanisms. True, although IF the data is encrypted, then "authorization for access" means "possession of the key". As you noted, I don't think we're worried about wire-tapping. I'm more worried about the fact that anybody who can query the DNS can see the records it contains, and if those records reveal information that should have remained private, then we have a problem. > > Perhaps all such cases are satisfied by using a DNS that is on a > controlled-access net. If not, then adding these mechanisms is > non-trivial and probably worth pursuing generically, rather than waiting > for a specific use case. Indeed. That is the biggest question facing the proposed working group. It's also related to the question of whether or not, in a given installation, some information MUST be access-controlled while other information MUST be access-open. If we have to do both at the same time, then we either have to have two independent installations, or we need to have an authentication/authorization model in the protocol. This feeds back directly on the proposed charter, which has text around AAA. > I say that because the nature of the data that has been discussed on the > list sounded like the type that will lead to a need for authorization > and because Internet-scale authorization is a challenge. (I believe > it's never been done.) This raises an excellent question of scaling. For a given installation, one might envision that some of the records need to be readable Internet-wide, while some other records might need to be restricted to a smaller audience. Is this smaller audience so much smaller that it makes the auth problem easier? For example, let's consider the fictitious and horribly contrived case of a domain that wishes to put client credit card numbers into the DNS associated with that client's phone number (and yes, I agree this is a bad idea), and also wants to put an non-confidential published link to each client's web site into the DNS. Anybody looking at the DNS might want to find the client's web site, but only people in the domain's financial services department need access to the credit card number. This seems to reduce the scaling problem for auth: if the credit card number is encrypted, then the key distribution problem is limited to the manageable task of giving the key to the financial services people. Or if we instead encode an HTTPS reference to the data in the NAPTR, the problem of managing credentials for accessing it is similarly restricted. So, is our problem really "internet scale authentication", or is it more on the scale of "the sort of routine authentication that Google/Schwab/Yahoo/UBS etc. do tens of billions of times every day?" > If it is ever a requirement to provide it, it needs to be explored now. Agreed. -- Dean From richard@shockey.us Tue Mar 23 10:00:26 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D7D3A6B94 for ; Tue, 23 Mar 2010 10:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziwtPQfflc6w for ; Tue, 23 Mar 2010 10:00:24 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 42B643A6993 for ; Tue, 23 Mar 2010 10:00:24 -0700 (PDT) Received: (qmail 6309 invoked by uid 0); 23 Mar 2010 16:00:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 23 Mar 2010 16:00:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=TaWm4Rbt4PgRmbs6tuLixL+8EIQidBdFi1t4nEEOiajCZqxqOJwuTXFi0jM8ImzX5vzTyN7T4tiQ2PasZaVoE0NVHuxF/T2TIir1ZI7tkHYcntuPJ7nEfUdCkjrk+dSH; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nu7T9-0006Ps-Vb; Tue, 23 Mar 2010 11:00:44 -0600 From: "Richard Shockey" To: , "'Dean Willis'" References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> In-Reply-To: <4BA8D3D5.9050906@dcrocker.net> Date: Tue, 23 Mar 2010 13:00:39 -0400 Message-ID: <012f01cacaaa$5e03aa30$1a0afe90$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrKmC11oPAWAhi7S8SA7JAdVXdy9gAES1Wg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:00:26 -0000 Dave IMHO 75% of the use cases for E2MD will be in controlled access networks. That is certainly they way it works today in commercial ENUM deployments outside of e164.arpa. Clearly there are issues where some data is applicable in the public tree and those use cases can be handled by some redirection to HTTP or other transport protocols if necessary. IMHO most of this security discussion is a Red Herring that the ENUM community settled years ago. LNP data has highly restricted access for instance, but its routinely used in private ENUM trees and the Internet hasn't crashed as a result. We need to offer tools people want to use and leave policy issues to the appropriate NRA. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dave CROCKER Sent: Tuesday, March 23, 2010 10:45 AM To: Dean Willis Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment On 3/22/2010 11:37 PM, Dean Willis wrote: > I have roughed out some open issues slides for the e2md bof. I believe list discussion has generated a reasonable proposal for each. Please review ASAP. Folks, The security-related bullets look reasonable, but my guess is that they are missing what's needed. So, for example, saying 'encryption' always sounds plausible when referencing security, but it probably does not apply, here. Encryption means privacy, but I suspect that privacy (against wire-tapping) is not a major concern for this use. It is more likely that the necessary security function will be authorization -- hence, authentication and access control are the relevant mechanisms. Perhaps all such cases are satisfied by using a DNS that is on a controlled-access net. If not, then adding these mechanisms is non-trivial and probably worth pursuing generically, rather than waiting for a specific use case. I say that because the nature of the data that has been discussed on the list sounded like the type that will lead to a need for authorization and because Internet-scale authorization is a challenge. (I believe it's never been done.) If it is ever a requirement to provide it, it needs to be explored now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Tue Mar 23 10:07:36 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457DD3A6CB3 for ; Tue, 23 Mar 2010 10:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3sUhparzdCD for ; Tue, 23 Mar 2010 10:07:31 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 7022A3A69AE for ; Tue, 23 Mar 2010 10:07:02 -0700 (PDT) Received: (qmail 1290 invoked by uid 0); 23 Mar 2010 16:07:21 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 23 Mar 2010 16:07:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=UZFGlaA1wxQ3b+hCOqz8zKpCOa1xOxNNfpbL0uRW1hESWiRIzZwAsUR5k7aIbQu9iVX9n0GTh/nZFniDQJXFtEQTFW3o74H0OGRyDJo3fkP4MGdTEE7ZUmphhnxGzwst; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nu7Za-0002ob-B6; Tue, 23 Mar 2010 11:07:22 -0600 From: "Richard Shockey" To: "'Jim Reid'" , "'Dean Willis'" References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <80319B17-C801-4380-820A-272FED3B6A30@rfc1035.com> In-Reply-To: <80319B17-C801-4380-820A-272FED3B6A30@rfc1035.com> Date: Tue, 23 Mar 2010 13:07:17 -0400 Message-ID: <013001cacaab$4b72e600$e258b200$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrKdwqGyV62cUIXRou6Ke2E46+IzQAM4HIA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:07:36 -0000 +1 this is a non issue. Also the discussion of whether DNS is appropriate here ..you are not discussing the dual nature of how people are thinking of actually using E2MD. I must say I know there is only an hour here a but as the ENUM co-chair I could but this BOF in some context but I'm not being permitted to present. I support the WG proposal but this is not a good way to begin. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jim Reid Sent: Tuesday, March 23, 2010 6:40 AM To: Dean Willis Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment On 23 Mar 2010, at 06:37, Dean Willis wrote: > I have roughed out some open issues slides for the e2md bof. I > believe list discussion has generated a reasonable proposal for > each. Please review ASAP. Dean, the slides look fine to me. Thanks. I'd quibble about the DNS payload concerns though. Just about every DNS implementation does EDNS0 these days. [It's needed for DNSSEC as well as being generally useful.] So there shouldn't be an issue here on DNS response size: just mandate EDNS0 with a minimum buffer size of 2KB or whatever. One thing to remember about EDNS0 is a lot of CPE middleware boxes are broken and drop or mangle these packets. Ray can give you chapter and verse about that. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From HKaplan@acmepacket.com Tue Mar 23 10:14:00 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C883A68C3 for ; Tue, 23 Mar 2010 10:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.081 X-Spam-Level: ** X-Spam-Status: No, score=2.081 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3JSDnFQhykb for ; Tue, 23 Mar 2010 10:13:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 43ACB3A6823 for ; Tue, 23 Mar 2010 10:13:59 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 23 Mar 2010 13:14:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 23 Mar 2010 13:14:17 -0400 From: Hadriel Kaplan To: "dcrocker@bbiw.net" , Dean Willis Date: Tue, 23 Mar 2010 13:14:15 -0400 Thread-Topic: [e2md] Issues slides , please comment Thread-Index: AcrKmC3gT2IokZHLQWyx67dCyliVNwAEvSAQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1B77@mail> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> In-Reply-To: <4BA8D3D5.9050906@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:14:00 -0000 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dave CROCKER > Sent: Tuesday, March 23, 2010 10:45 AM > To: Dean Willis >=20 > Encryption means privacy, but I suspect that privacy (against wire- > tapping) is > not a major concern for this use. >=20 > It is more likely that the necessary security function will be > authorization -- > hence, authentication and access control are the relevant mechanisms. If you don't have the key to decrypt, you can't access the (cleartext) data= and you're not authorized to do so. =20 =20 > Perhaps all such cases are satisfied by using a DNS that is on a > controlled-access net. If not, then adding these mechanisms is non- > trivial and > probably worth pursuing generically, rather than waiting for a specific > use case. Yes, I think a generic way would be better - then all drafts can just point= to that. =20 > I say that because the nature of the data that has been discussed on the > list > sounded like the type that will lead to a need for authorization and > because > Internet-scale authorization is a challenge. (I believe it's never been > done.) I think in practice this isn't really Internet-scale. It's really more lik= ely to be in private DNS servers - but certainly it may be in publicly acce= ssible/reachable DNS servers but still only need to be viewable/usable by a= small subset of clients, and that's where I think we do need to specify so= mething to cover. -hadriel From richard@shockey.us Tue Mar 23 10:15:02 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E1E23A68BB for ; Tue, 23 Mar 2010 10:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHcZXQYl4mbc for ; Tue, 23 Mar 2010 10:15:00 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id B4B373A68C3 for ; Tue, 23 Mar 2010 10:14:57 -0700 (PDT) Received: (qmail 31561 invoked by uid 0); 23 Mar 2010 16:15:16 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 23 Mar 2010 16:15:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=SYGBMV4a+tWdzDFpY605B17+2DsVi8C4BMNPdd2D9x8i6EfUDcjqu4sbbNCpGJBZBZ+BL6oDZNonFSvVT4O8AzrJYkPwLdg6QcvFcUT26GXk1F2JrS4oqDRBnd2ZgXv3; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nu7hF-00016l-1c; Tue, 23 Mar 2010 11:15:17 -0600 From: "Richard Shockey" To: "'Dean Willis'" , References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <4BA8F2A5.3010609@softarmor.com> In-Reply-To: <4BA8F2A5.3010609@softarmor.com> Date: Tue, 23 Mar 2010 13:15:12 -0400 Message-ID: <016201cacaac$66652210$332f6630$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcrKqcP+qrn/16Q9TCmJt+PEwdTHMgAAd8Vw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:15:02 -0000 > > Perhaps all such cases are satisfied by using a DNS that is on a > controlled-access net. If not, then adding these mechanisms is > non-trivial and probably worth pursuing generically, rather than waiting > for a specific use case. Indeed. That is the biggest question facing the proposed working group. It's also related to the question of whether or not, in a given installation, some information MUST be access-controlled while other information MUST be access-open. If we have to do both at the same time, then we either have to have two independent installations, or we need to have an authentication/authorization model in the protocol. This feeds back directly on the proposed charter, which has text around AAA. RS> This again is policy. We don't need to define AA ourselves only provide the recommendation that if there are restrictions on a particular class of data then you should use FOO if it is not a closed access network. This entire discussion is putting the cart before the horse this is a discussion best left to the WG. > I say that because the nature of the data that has been discussed on the > list sounded like the type that will lead to a need for authorization > and because Internet-scale authorization is a challenge. (I believe > it's never been done.) This raises an excellent question of scaling. For a given installation, one might envision that some of the records need to be readable Internet-wide, while some other records might need to be restricted to a smaller audience. Is this smaller audience so much smaller that it makes the auth problem easier? For example, let's consider the fictitious and horribly contrived case of a domain that wishes to put client credit card numbers into the DNS associated with that client's phone number (and yes, I agree this is a bad idea), and also wants to put an non-confidential published link to each client's web site into the DNS. Anybody looking at the DNS might want to find the client's web site, but only people in the domain's financial services department need access to the credit card number. This seems to reduce the scaling problem for auth: if the credit card number is encrypted, then the key distribution problem is limited to the manageable task of giving the key to the financial services people. Or if we instead encode an HTTPS reference to the data in the NAPTR, the problem of managing credentials for accessing it is similarly restricted. So, is our problem really "internet scale authentication", or is it more on the scale of "the sort of routine authentication that Google/Schwab/Yahoo/UBS etc. do tens of billions of times every day?" > If it is ever a requirement to provide it, it needs to be explored now. Agreed. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From HKaplan@acmepacket.com Tue Mar 23 10:15:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AA663A69ED for ; Tue, 23 Mar 2010 10:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.606 X-Spam-Level: * X-Spam-Status: No, score=1.606 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmJfXh4UPtwe for ; Tue, 23 Mar 2010 10:15:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 407713A68C3 for ; Tue, 23 Mar 2010 10:15:24 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 23 Mar 2010 13:15:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 23 Mar 2010 13:15:42 -0400 From: Hadriel Kaplan To: Richard Shockey , "dcrocker@bbiw.net" , 'Dean Willis' Date: Tue, 23 Mar 2010 13:15:42 -0400 Thread-Topic: [e2md] Issues slides , please comment Thread-Index: AcrKmC11oPAWAhi7S8SA7JAdVXdy9gAES1WgAADB4dA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> In-Reply-To: <012f01cacaaa$5e03aa30$1a0afe90$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:15:28 -0000 We won't get away with hand-waving it I think. We'll need a solution to ge= t past IESG, no? > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Tuesday, March 23, 2010 1:01 PM > To: dcrocker@bbiw.net; 'Dean Willis' > Cc: e2md@ietf.org > Subject: Re: [e2md] Issues slides , please comment >=20 > Dave IMHO 75% of the use cases for E2MD will be in controlled access > networks. That is certainly they way it works today in commercial ENUM > deployments outside of e164.arpa. Clearly there are issues where some dat= a > is applicable in the public tree and those use cases can be handled by > some > redirection to HTTP or other transport protocols if necessary. >=20 > IMHO most of this security discussion is a Red Herring that the ENUM > community settled years ago. LNP data has highly restricted access for > instance, but its routinely used in private ENUM trees and the Internet > hasn't crashed as a result. >=20 > We need to offer tools people want to use and leave policy issues to the > appropriate NRA. >=20 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dave > CROCKER > Sent: Tuesday, March 23, 2010 10:45 AM > To: Dean Willis > Cc: e2md@ietf.org > Subject: Re: [e2md] Issues slides , please comment >=20 >=20 >=20 > On 3/22/2010 11:37 PM, Dean Willis wrote: > > I have roughed out some open issues slides for the e2md bof. I believe > list discussion has generated a reasonable proposal for each. Please > review > ASAP. >=20 >=20 > Folks, >=20 > The security-related bullets look reasonable, but my guess is that they > are > missing what's needed. >=20 > So, for example, saying 'encryption' always sounds plausible when > referencing > security, but it probably does not apply, here. >=20 > Encryption means privacy, but I suspect that privacy (against wire- > tapping) > is > not a major concern for this use. >=20 > It is more likely that the necessary security function will be > authorization > -- > hence, authentication and access control are the relevant mechanisms. >=20 > Perhaps all such cases are satisfied by using a DNS that is on a > controlled-access net. If not, then adding these mechanisms is non- > trivial > and > probably worth pursuing generically, rather than waiting for a specific > use > case. >=20 > I say that because the nature of the data that has been discussed on the > list > sounded like the type that will lead to a need for authorization and > because >=20 > Internet-scale authorization is a challenge. (I believe it's never been > done.) >=20 > If it is ever a requirement to provide it, it needs to be explored now. >=20 > d/ > -- >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From dhc2@dcrocker.net Tue Mar 23 10:16:48 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9483A6C59 for ; Tue, 23 Mar 2010 10:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejE-wq1Zd5jd for ; Tue, 23 Mar 2010 10:16:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id F30383A6B07 for ; Tue, 23 Mar 2010 10:16:46 -0700 (PDT) Received: from [130.129.28.8] (dhcp-wireless-open-abg-28-8.meeting.ietf.org [130.129.28.8]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o2NHGxFF006017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 10:17:05 -0700 Message-ID: <4BA8F785.3090901@dcrocker.net> Date: Tue, 23 Mar 2010 10:16:53 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Richard Shockey References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <4BA8F2A5.3010609@softarmor.com> In-Reply-To: <4BA8F2A5.3010609@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10612/Tue Mar 23 07:14:06 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 23 Mar 2010 10:17:06 -0700 (PDT) Cc: e2md@ietf.org, dcrocker@bbiw.net Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:16:48 -0000 On 3/23/2010 9:56 AM, Dean Willis wrote: > Dave CROCKER wrote: > >> It is more likely that the necessary security function will be >> authorization -- hence, authentication and access control are the >> relevant mechanisms. > > True, although IF the data is encrypted, then "authorization for access" > means "possession of the key". Encryption requires a consumer-specific key. Each receiver of the data will need to get it tailored to their own key. This isn't a big deal with the TLS session-time approach, because TLS generates the recipient-specific key in real time. But it's not an 'authorization' capability. For this, the receiver-side key needs to be tied to their identity, in an X.509-cert style. Again, that's a big deal, with very little field experience in open Internet communities, I believe. However... On 3/23/2010 10:00 AM, Richard Shockey wrote: > Dave IMHO 75% of the use cases for E2MD will be in controlled access > networks. I hope you noted that I noted that alternative and made everything that followed contingent on needing open Internet, not private Internet. > IMHO most of this security discussion is a Red Herring that the ENUM > community settled years ago. How did it settle the matter for the other 25% that you did not cover? > We need to offer tools people want to use and leave policy issues to the > appropriate NRA. A design approach which relies on restricted use in a private network /IS/ a policy issue. There's nothing wrong with making it, but it needs to be understood for its considerable effect. If authorization and privacy are deemed out of scope, then that's what the slides should say. I posted my note based on some comments I had heard ealier and based on the content of the draft slides. All of this suggests that the topic is not nearly as 'settled' as your note implies. My own post sought to press for settling it. Having a working group consensus that says that all security-related issues are handled out of band certainly has precedent, although it needs careful justification to the IESG. But restricting use to private networks does sound as if it handles the matter, especially when the new use is based on existing practise. But don't dismiss the question, just because you know the answer. Make sure everyone else, including the IESG, knows and agrees with the answer. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Ray.Bellis@nominet.org.uk Tue Mar 23 10:22:32 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBCF3A6CA3 for ; Tue, 23 Mar 2010 10:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAwC0mKDJh14 for ; Tue, 23 Mar 2010 10:22:31 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 7F57F3A6C17 for ; Tue, 23 Mar 2010 10:22:30 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=gOGIeHgIa9S9wybB7zBWkI6y1TRtYFgQLz0SadUVxJPTHI29T/MEWE9N cFrDVu/uQuUmtaZPXqgT62WbgumAh2CP1rUBr4dqTRdE4F4vJSR94DA80 tZj6HD+fNdi7D3c; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269364970; x=1300900970; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Issues=20slides=20,=20please=20comment|Date:=20Tue, =2023=20Mar=202010=2009:22:47=20-0800|Message-ID:=20|To:=20dcrocker@bbiw.net|Cc:=20e2md@ietf.org, =0D=0A=09Richard=20Shockey=20 |MIME-Version:=201.0|In-Reply-To:=20<4BA8F785.3090901@dcr ocker.net>|References:=20<69fa754c-393d-4f05-a8d0-25d1956 87e1c@email.android.com>=09<4BA8D3D5.9050906@dcrocker.net >=0D=0A=09<4BA8F2A5.3010609@softarmor.com>=20<4BA8F785.30 90901@dcrocker.net>; bh=yTihwzvdC9i9rSajp7SOWyqmXhNKJndsfObOvLYkpag=; b=mCz5idGOd8HG18jhKDm+Fxs4Aq7Qb6kbk7JuXEJDAnc9gRxeqFc5GjdT BrF9FPQ4Z8/zlM6/uxX0BC4J9XTSv+Dc3Ij2Mt0D7JNmI5bXJ08lXNvml lXvyniPxlmEGrfr; X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="17287279" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 23 Mar 2010 17:22:49 +0000 In-Reply-To: <4BA8F785.3090901@dcrocker.net> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <4BA8F2A5.3010609@softarmor.com> <4BA8F785.3090901@dcrocker.net> To: dcrocker@bbiw.net MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 23 Mar 2010 09:22:47 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/03/2010 05:22:48 PM, Serialize complete at 23/03/2010 05:22:48 PM Content-Type: multipart/alternative; boundary="=_alternative 005F7831882576EF_=" Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:22:32 -0000 This is a multipart message in MIME format. --=_alternative 005F7831882576EF_= Content-Type: text/plain; charset="US-ASCII" Of the three documented use cases (i.e. the ones for which drafts exist), only Richard's existing CNAM draft from ENUM contains "personal" information. As far as I can see these data privacy issues were _not_ concerns when this draft was going through the ENUM group. Ray --=_alternative 005F7831882576EF_= Content-Type: text/html; charset="US-ASCII" Of the three documented use cases (i.e. the ones for which drafts exist), only Richard's existing CNAM draft from ENUM contains "personal" information.

As far as I can see these data privacy issues were _not_ concerns when this draft was going through the ENUM group.

Ray
--=_alternative 005F7831882576EF_=-- From HKaplan@acmepacket.com Tue Mar 23 10:26:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5A43A68A3 for ; Tue, 23 Mar 2010 10:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.448 X-Spam-Level: * X-Spam-Status: No, score=1.448 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IQFM3Hv7P8G for ; Tue, 23 Mar 2010 10:26:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 376FB3A6CD7 for ; Tue, 23 Mar 2010 10:26:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 23 Mar 2010 13:26:59 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 23 Mar 2010 13:26:58 -0400 From: Hadriel Kaplan To: Dean Willis , "dcrocker@bbiw.net" Date: Tue, 23 Mar 2010 13:26:57 -0400 Thread-Topic: [e2md] Issues slides , please comment Thread-Index: AcrKqch/vrdGaAnkSf2Zc58ad2mEYQAAvKXg Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1B7E@mail> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <4BA8F2A5.3010609@softarmor.com> In-Reply-To: <4BA8F2A5.3010609@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:26:50 -0000 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Tuesday, March 23, 2010 12:56 PM >=20 > This seems to reduce the scaling problem for auth: if the credit card > number is encrypted, then the key distribution problem is limited to the > manageable task of giving the key to the financial services people. Or > if we instead encode an HTTPS reference to the data in the NAPTR, the > problem of managing credentials for accessing it is similarly restricted. That just moves the problem around, doesn't it? Let's say we said "use HTT= PS redirection". So my PC resolves the E2MD entry, gets redirected to an H= TTPS server. This proves nothing about my PC's authorization to get what t= he HTTPS server provides - so the HTTPS server has to challenge my PC or do= something to verify my PC is what it claims to be, and is authorized to ac= cess data foobar. This requires my PC to have some shared secret with the = HTTPS server. Well, that's all we needed to exist to begin with for E2MD: = a shared secret. It's just that the shared secret is a key, not a user/pas= sword. ISTM the big advantage for a http method would be you get per-user = auth, and thus per-user revoke too, but the downside is we'd need to spec e= xactly how it works if we expect automated machines to be able to use it (w= hich for me is the use-case for E2MD: machines). -hadriel From Klaus.Nieminen@ficora.fi Tue Mar 23 10:31:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF803A6CD7 for ; Tue, 23 Mar 2010 10:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.528 X-Spam-Level: ** X-Spam-Status: No, score=2.528 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dVmytqNwEAt for ; Tue, 23 Mar 2010 10:31:32 -0700 (PDT) Received: from out2.ficora.fi (out2.ficora.fi [87.239.124.62]) by core3.amsl.com (Postfix) with ESMTP id 7D50D3A6A56 for ; Tue, 23 Mar 2010 10:31:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,296,1267394400"; d="scan'208,217";a="736631" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACAAE.B39907D7" Date: Tue, 23 Mar 2010 19:31:41 +0200 Message-ID: <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Issues slides , please comment Thread-Index: AcrKmC11oPAWAhi7S8SA7JAdVXdy9gAES1WgAAEVut8= References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com><4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> From: "Nieminen Klaus" To: "Richard Shockey" , , "Dean Willis" Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:31:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACAAE.B39907D7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi folks, =20 At least in Finland it's a regulatory requirement that operators = cooperate to maintain a free service that describes to which operator = the number belongs to. So at least we have it already available in the = Internet: http://www.siirretytnumerot.fi/ = (sry available only in Finnish) =20 regards, =20 - Klaus ________________________________ L=E4hett=E4j=E4: e2md-bounces@ietf.org puolesta: Richard Shockey L=E4hetetty: ti 23.3.2010 19:00 Vastaanottaja: dcrocker@bbiw.net; 'Dean Willis' Kopio: e2md@ietf.org Aihe: Re: [e2md] Issues slides , please comment Dave IMHO 75% of the use cases for E2MD will be in controlled access networks. That is certainly they way it works today in commercial ENUM deployments outside of e164.arpa. Clearly there are issues where some = data is applicable in the public tree and those use cases can be handled by = some redirection to HTTP or other transport protocols if necessary. IMHO most of this security discussion is a Red Herring that the ENUM community settled years ago. LNP data has highly restricted access for instance, but its routinely used in private ENUM trees and the Internet hasn't crashed as a result. We need to offer tools people want to use and leave policy issues to the appropriate NRA. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of = Dave CROCKER Sent: Tuesday, March 23, 2010 10:45 AM To: Dean Willis Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment On 3/22/2010 11:37 PM, Dean Willis wrote: > I have roughed out some open issues slides for the e2md bof. I believe list discussion has generated a reasonable proposal for each. Please = review ASAP. Folks, The security-related bullets look reasonable, but my guess is that they = are missing what's needed. So, for example, saying 'encryption' always sounds plausible when referencing security, but it probably does not apply, here. Encryption means privacy, but I suspect that privacy (against = wire-tapping) is not a major concern for this use. It is more likely that the necessary security function will be = authorization -- hence, authentication and access control are the relevant mechanisms. Perhaps all such cases are satisfied by using a DNS that is on a controlled-access net. If not, then adding these mechanisms is = non-trivial and probably worth pursuing generically, rather than waiting for a specific = use case. I say that because the nature of the data that has been discussed on the list sounded like the type that will lead to a need for authorization and = because Internet-scale authorization is a challenge. (I believe it's never been done.) If it is ever a requirement to provide it, it needs to be explored now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md ------_=_NextPart_001_01CACAAE.B39907D7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [e2md] Issues slides , please = comment=0A= =0A= =0A= =0A=
=0A=
Hi = folks,
=0A=
 
=0A=
At least in Finland it's a = regulatory requirement that operators cooperate to maintain a free = service that describes to which operator the number belongs to. = So at least we have it already = available in the Internet:
=0A=
http://www.siirretytnumerot.fi/ (sry available = only in Finnish)
=0A=
 
=0A=
regards,
=0A=
 
=0A=
- Klaus
=0A=

=0A=
=0A= L=E4hett=E4j=E4: = e2md-bounces@ietf.org puolesta: Richard Shockey
L=E4hetetty: = ti 23.3.2010 19:00
Vastaanottaja: dcrocker@bbiw.net; 'Dean = Willis'
Kopio: e2md@ietf.org
Aihe: Re: [e2md] Issues = slides , please comment

=0A=
=0A=

Dave IMHO 75% of the use cases for E2MD will be in = controlled access
networks. That is certainly they way it works today = in commercial ENUM
deployments outside of e164.arpa. Clearly there = are issues where some data
is applicable in the public tree and those = use cases can be handled by some
redirection to HTTP or other = transport protocols if necessary.

IMHO most of this security = discussion is a Red Herring that the ENUM
community settled years = ago. LNP data has highly restricted access for
instance,  but = its routinely used in private ENUM trees and the Internet
hasn't = crashed as a result.

We need to offer tools people want to use = and leave policy issues to the
appropriate NRA.

-----Original = Message-----
From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] = On Behalf Of Dave
CROCKER
Sent: Tuesday, March 23, 2010 10:45 = AM
To: Dean Willis
Cc: e2md@ietf.org
Subject: Re: [e2md] Issues = slides , please comment



On 3/22/2010 11:37 PM, Dean = Willis wrote:
> I have roughed out some open issues slides for the = e2md bof. I believe
list discussion has generated a reasonable = proposal for each. Please review
ASAP.


Folks,

The = security-related bullets look reasonable, but my guess is that they = are
missing what's needed.

So, for example, saying = 'encryption' always sounds plausible when
referencing
security, = but it probably does not apply, here.

Encryption means privacy, = but I suspect that privacy (against wire-tapping)
is
not a major = concern for this use.

It is more likely that the necessary = security function will be authorization
--
hence, authentication = and access control are the relevant mechanisms.

Perhaps all such = cases are satisfied by using a DNS that is on a
controlled-access = net.  If not, then adding these mechanisms is = non-trivial
and
probably worth pursuing generically, rather than = waiting for a specific use
case.

I say that because the nature = of the data that has been discussed on the
list
sounded like the = type that will lead to a need for authorization and = because

Internet-scale authorization is a challenge.  (I = believe it's never been
done.)

If it is ever a requirement to = provide it, it needs to be explored = now.

d/
--

   Dave Crocker
   = Brandenburg InternetWorking
   = bbiw.net
_______________________________________________
e2md = mailing list
e2md@ietf.org
https://www.ietf.org/= mailman/listinfo/e2md

________________________________________= _______
e2md mailing list
e2md@ietf.org
https://www.ietf.org/= mailman/listinfo/e2md

------_=_NextPart_001_01CACAAE.B39907D7-- From dean.willis@softarmor.com Tue Mar 23 10:38:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A5D3A69D2 for ; Tue, 23 Mar 2010 10:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFyMeUHu+B4b for ; Tue, 23 Mar 2010 10:38:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 075103A6C2D for ; Tue, 23 Mar 2010 10:38:01 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NHcCvL013444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 12:38:13 -0500 Message-ID: <4BA8FC82.9090405@softarmor.com> Date: Tue, 23 Mar 2010 12:38:10 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Hadriel Kaplan References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "e2md@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:38:03 -0000 Hadriel Kaplan wrote: > We won't get away with hand-waving it I think. We'll need a solution to get past IESG, no? > We ABSOLUTELY MUST agree to the scope of the problem that the working group is solving, and we have to show evidence that the problem is solvable by the WG, but we don't need to have a solution to the problem. This gives us a couple of options: 1) We have an all-or-nothing solution; if you have sensitive data in your tree, you MUST limit access to that entire tree as per the most sensitive data in the tree. 2) We have a problem where selective access controls are required for some subset of the tree, and where the scope of the selective access is relatively small and manageable by several obvious techniques, which the WG will evaluate and make recommendations on. 3) We have a problem where selective access controls are required for some subset of the tree, and the scope of that selective access is very large, effectively requiring something that looks like a general solution to the "Internet-scale authentication problem". I propose that we're closest to #2; we can't quite say "Just use a private DNS if you have sensitive data", but the access-control problem is not huge and can be handled using conventional web techniques. -- dean From richard@shockey.us Tue Mar 23 10:40:49 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A33D3A6C41 for ; Tue, 23 Mar 2010 10:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KQxPg6aZ57O for ; Tue, 23 Mar 2010 10:40:47 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id CBCEB3A686C for ; Tue, 23 Mar 2010 10:40:47 -0700 (PDT) Received: (qmail 1322 invoked by uid 0); 23 Mar 2010 17:41:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 23 Mar 2010 17:41:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:x-cr-hashedpuzzle:x-cr-puzzleid:X-Identified-User; b=de8lJO+ETuqQe65XvLtyll8hBqQmDPz/PMTMg17P2f7KLD89klOq/uWTt82FosICr+p4F2niYQ0/qxlDldBlJHzTiOoC5ymuU4AndNfXdT05Fk2PceFQGt20MfRO9Ayo; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nu86F-0006lQ-J9; Tue, 23 Mar 2010 11:41:07 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , , "'Dean Willis'" References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> Date: Tue, 23 Mar 2010 13:41:02 -0400 Message-ID: <000001cacab0$029674b0$07c35e10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKmC11oPAWAhi7S8SA7JAdVXdy9gAES1WgAADB4dAAAFz8cA== Content-Language: en-us x-cr-hashedpuzzle: DGbN FNrA KDGX KP3t S2g+ TLTc XJT6 bX+V fv5z g1Cl g2Sk g4r8 hkzu iHXb mWeN p7/1; 4; ZABjAHIAbwBjAGsAZQByAEAAYgBiAGkAdwAuAG4AZQB0ADsAZABlAGEAbgAuAHcAaQBsAGwAaQBzAEAAcwBvAGYAdABhAHIAbQBvAHIALgBjAG8AbQA7AGUAMgBtAGQAQABpAGUAdABmAC4AbwByAGcAOwBoAGsAYQBwAGwAYQBuAEAAYQBjAG0AZQBwAGEAYwBrAGUAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {4F74E466-C437-49D6-ABE9-AB6D35F3ADE1}; cgBpAGMAaABhAHIAZABAAHMAaABvAGMAawBlAHkALgB1AHMA; Tue, 23 Mar 2010 17:40:23 GMT; UgBFADoAIABbAGUAMgBtAGQAXQAgAEkAcwBzAHUAZQBzACAAcwBsAGkAZABlAHMAIAAsACAAcABsAGUAYQBzAGUAIABjAG8AbQBtAGUAbgB0AA== x-cr-puzzleid: {4F74E466-C437-49D6-ABE9-AB6D35F3ADE1} X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:40:49 -0000 That is a discussion for the WG not the BOF .. the issue will center on how the IANA registry is designed and what the recommendations contained in that registry are for a particular data object. In the open DNS either encryption or indirection MAY be warranted in closed network environments it MAY not. -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Tuesday, March 23, 2010 1:16 PM To: Richard Shockey; dcrocker@bbiw.net; 'Dean Willis' Cc: e2md@ietf.org Subject: RE: [e2md] Issues slides , please comment We won't get away with hand-waving it I think. We'll need a solution to get past IESG, no? > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Tuesday, March 23, 2010 1:01 PM > To: dcrocker@bbiw.net; 'Dean Willis' > Cc: e2md@ietf.org > Subject: Re: [e2md] Issues slides , please comment > > Dave IMHO 75% of the use cases for E2MD will be in controlled access > networks. That is certainly they way it works today in commercial ENUM > deployments outside of e164.arpa. Clearly there are issues where some data > is applicable in the public tree and those use cases can be handled by > some > redirection to HTTP or other transport protocols if necessary. > > IMHO most of this security discussion is a Red Herring that the ENUM > community settled years ago. LNP data has highly restricted access for > instance, but its routinely used in private ENUM trees and the Internet > hasn't crashed as a result. > > We need to offer tools people want to use and leave policy issues to the > appropriate NRA. > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dave > CROCKER > Sent: Tuesday, March 23, 2010 10:45 AM > To: Dean Willis > Cc: e2md@ietf.org > Subject: Re: [e2md] Issues slides , please comment > > > > On 3/22/2010 11:37 PM, Dean Willis wrote: > > I have roughed out some open issues slides for the e2md bof. I believe > list discussion has generated a reasonable proposal for each. Please > review > ASAP. > > > Folks, > > The security-related bullets look reasonable, but my guess is that they > are > missing what's needed. > > So, for example, saying 'encryption' always sounds plausible when > referencing > security, but it probably does not apply, here. > > Encryption means privacy, but I suspect that privacy (against wire- > tapping) > is > not a major concern for this use. > > It is more likely that the necessary security function will be > authorization > -- > hence, authentication and access control are the relevant mechanisms. > > Perhaps all such cases are satisfied by using a DNS that is on a > controlled-access net. If not, then adding these mechanisms is non- > trivial > and > probably worth pursuing generically, rather than waiting for a specific > use > case. > > I say that because the nature of the data that has been discussed on the > list > sounded like the type that will lead to a need for authorization and > because > > Internet-scale authorization is a challenge. (I believe it's never been > done.) > > If it is ever a requirement to provide it, it needs to be explored now. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From HKaplan@acmepacket.com Tue Mar 23 10:52:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704333A6C3B for ; Tue, 23 Mar 2010 10:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.369 X-Spam-Level: * X-Spam-Status: No, score=1.369 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJhsFodlspB1 for ; Tue, 23 Mar 2010 10:52:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B5B983A6CE5 for ; Tue, 23 Mar 2010 10:42:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 23 Mar 2010 13:43:00 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 23 Mar 2010 13:43:00 -0400 From: Hadriel Kaplan To: "Ray.Bellis@nominet.org.uk" , "dcrocker@bbiw.net" Date: Tue, 23 Mar 2010 13:42:58 -0400 Thread-Topic: [e2md] Issues slides , please comment Thread-Index: AcrKrYPllmRUtC8MSnqbiwIs16AnGwAAK/lg Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1B89@mail> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <4BA8F2A5.3010609@softarmor.com> <4BA8F785.3090901@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79CD1B89mail_" MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:52:54 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79CD1B89mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a use-case which requires it. I was writing up a draft for it this = morning, but maybe I should just explain it in email to see if it's somethi= ng you guys would puke all over or not, so I don't waste my time on a draft= . :) You may decide this isn't a valid use-case for E2MD, or DNS to begin = with. So here goes: Right now, 3 vendors (including my employer) have implemented a DDDS mechan= ism for storing SIP user credentials. By "SIP user credentials" I mean the= information needed to authenticate a SIP request through an MD5 digest-cha= llenge, namely the hash of user:realm:password, as defined in RFC 3261 and = 2617 as "H(A1)". The general purpose of this is it allows any SIP server w= hich can access the DNS entry for this, to successfully authenticate a SIP = Request claiming to come from that E.164. In our case in particular, we us= e it to challenge SIP REGISTER and INVITE requests at the edge of the SIP d= omain, as they come in from SIP UA's. For example, we get a REGISTER, chal= lenge it, and on the challenge-response we look up the claimed E.164-based = AoR and verify its challenge-response used the value in the DNS entry for t= he hash calculation. We store them in the clear right now, because the deployments which use the= m (claim) to have tight control over access to the DNS servers which have '= em. Obviously that's a tenuous position, and this is highly sensitive data= . We'd like an option to have the entry data encrypted, using a key which = all authorized SIP servers have. -hadriel ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray= .Bellis@nominet.org.uk Sent: Tuesday, March 23, 2010 1:23 PM To: dcrocker@bbiw.net Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment Of the three documented use cases (i.e. the ones for which drafts exist), o= nly Richard's existing CNAM draft from ENUM contains "personal" information= . As far as I can see these data privacy issues were _not_ concerns when this= draft was going through the ENUM group. Ray --_000_430FC6BDED356B4C8498F634416644A91A79CD1B89mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a use-case which requires it.&n= bsp; I was writing up a draft for it this morning, but maybe I should just expla= in it in email to see if it’s something you guys would puke all over or = not, so I don’t waste my time on a draft. J  You may deci= de this isn’t a valid use-case for E2MD, or DNS to begin with.

 

So here goes:=

Right now, 3 vendors (including my employer) have implemented a DDDS mechanism for storing SIP user credential= s.  By “SIP user credentials” I mean the information needed to authenticate a SIP request through an MD5 digest-challenge, namely the hash= of user:realm:password, as defined in RFC 3261 and 2617 as “H(A1)”.  The general purpose of this is it allows any SIP server which can access the DNS entry = for this, to successfully authenticate a SIP Request claiming to come from that E.164.  In our case in particular, we use it to challenge SIP REGISTER= and INVITE requests at the edge of the SIP domain, as they come in from SIP UA&= #8217;s.  For example, we get a REGISTER, challenge it, and on the challenge-response we look up the claimed E.164-based AoR and verify its challenge-response used the value in the DNS entry for the hash calculation= .

 

We store them in the clear right now, because the deployments which use them (claim) to have tight control over access to the DNS servers which have ‘em.  Obviously that’= s a tenuous position, and this is highly sensitive data.  We’d like an optio= n to have the entry data encrypted, using a key which all authorized SIP servers have.

 

-hadriel

 

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray.Bellis@nomine= t.org.uk
Sent: Tuesday, March 23, 201= 0 1:23 PM
To: dcrocker@bbiw.net
Cc: e2md@ietf.org
Subject: Re: [e2md] Issues s= lides , please comment

 

Of the three documented use cases (i.e. the ones for which drafts exist), only Richard's existing CNAM draft from ENUM contains "personal" information.

As= far as I can see these data privacy issues were _not_ concerns when this draft was g= oing through the ENUM group.

Ra= y

--_000_430FC6BDED356B4C8498F634416644A91A79CD1B89mail_-- From dean.willis@softarmor.com Tue Mar 23 10:59:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C96D3A6C40 for ; Tue, 23 Mar 2010 10:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq0olhs-Au5W for ; Tue, 23 Mar 2010 10:59:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 353313A6D3F for ; Tue, 23 Mar 2010 10:51:34 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NHphpJ013583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 12:51:45 -0500 Message-ID: <4BA8FFAE.7020206@softarmor.com> Date: Tue, 23 Mar 2010 12:51:42 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Richard Shockey References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> <000001cacab0$029674b0$07c35e10$@us> In-Reply-To: <000001cacab0$029674b0$07c35e10$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org, dcrocker@bbiw.net Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:59:20 -0000 Richard Shockey wrote: > That is a discussion for the WG not the BOF .. the issue will center on how > the IANA registry is designed and what the recommendations contained in that > registry are for a particular data object. In the open DNS either encryption > or indirection MAY be warranted in closed network environments it MAY not. But before we can have a WG, we have to know the scope of the WG. That means saying, in advance, exactly which problems the WG is going to solve. So for example, deciding in advance whether we are or are not going to solve the open-DNS-with-sensitive-data problem is something we MUST DO. We MUST NOT defer that decision to the WG, because without an answer to that question, the WG will not be formed. -- dean From richard@shockey.us Tue Mar 23 11:01:42 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F343A6CA2 for ; Tue, 23 Mar 2010 11:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtMgQJbYw+vV for ; Tue, 23 Mar 2010 11:01:36 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id AB2583A6D18 for ; Tue, 23 Mar 2010 11:00:00 -0700 (PDT) Received: (qmail 28950 invoked by uid 0); 23 Mar 2010 17:00:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 23 Mar 2010 17:00:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=NXyx/rognI+5uj8ARlK3hT1uvkehCjdJ0FgAQodxe0PWwWjg4h/f757rRNyBOiAh9prFxbX0kVpGAk0gwRpHqG3DS0PRP7GcPPGHsZFI0Bskc0LM3OYGvu9gbgjSyEf/; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nu8Op-0007ur-25; Tue, 23 Mar 2010 12:00:19 -0600 From: "Richard Shockey" To: "'Nieminen Klaus'" , , "'Dean Willis'" References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com><4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> In-Reply-To: <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> Date: Tue, 23 Mar 2010 14:00:13 -0400 Message-ID: <001a01cacab2$b0fb9e70$12f2db50$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CACA91.29E9FE70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKmC11oPAWAhi7S8SA7JAdVXdy9gAES1WgAAEVut8AAOljgA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:01:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01CACA91.29E9FE70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And that certainly represents one of the other 25% of the use cases. =20 =20 I don=92t know what the specific application is in Finland but in the US = ..it is the service that Law Enforcement uses to find the underlying operator = for a TN in order to know where to put the alligator clips. J =20 IMHO the largest economic impact of E2MD is TCAP/SS7-C7 avoidance in = closed SIP transit networks where PSTN interconnection data is needed. I want = to see that application preserved and not encumbered with irrelevant and encumbering requirements that would unquestionably be appropriate and necessary for use in the open DNS. =20 =20 Privacy and Security requirements are clearly driven by the type data exposed bound to network ( and its security) the data resides in. =20 From: Nieminen Klaus [mailto:Klaus.Nieminen@ficora.fi]=20 Sent: Tuesday, March 23, 2010 1:32 PM To: Richard Shockey; dcrocker@bbiw.net; Dean Willis Cc: e2md@ietf.org Subject: VS: [e2md] Issues slides , please comment =20 Hi folks, =20 At least in Finland it's a regulatory requirement that operators = cooperate to maintain a free service that describes to which operator the number belongs to. So at least we have it already available in the Internet: http://www.siirretytnumerot.fi/ (sry available only in Finnish) =20 regards, =20 - Klaus =20 _____ =20 L=E4hett=E4j=E4: e2md-bounces@ietf.org puolesta: Richard Shockey L=E4hetetty: ti 23.3.2010 19:00 Vastaanottaja: dcrocker@bbiw.net; 'Dean Willis' Kopio: e2md@ietf.org Aihe: Re: [e2md] Issues slides , please comment Dave IMHO 75% of the use cases for E2MD will be in controlled access networks. That is certainly they way it works today in commercial ENUM deployments outside of e164.arpa. Clearly there are issues where some = data is applicable in the public tree and those use cases can be handled by = some redirection to HTTP or other transport protocols if necessary. IMHO most of this security discussion is a Red Herring that the ENUM community settled years ago. LNP data has highly restricted access for instance, but its routinely used in private ENUM trees and the Internet hasn't crashed as a result. We need to offer tools people want to use and leave policy issues to the appropriate NRA. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of = Dave CROCKER Sent: Tuesday, March 23, 2010 10:45 AM To: Dean Willis Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment On 3/22/2010 11:37 PM, Dean Willis wrote: > I have roughed out some open issues slides for the e2md bof. I believe list discussion has generated a reasonable proposal for each. Please = review ASAP. Folks, The security-related bullets look reasonable, but my guess is that they = are missing what's needed. So, for example, saying 'encryption' always sounds plausible when referencing security, but it probably does not apply, here. Encryption means privacy, but I suspect that privacy (against = wire-tapping) is not a major concern for this use. It is more likely that the necessary security function will be = authorization -- hence, authentication and access control are the relevant mechanisms. Perhaps all such cases are satisfied by using a DNS that is on a controlled-access net. If not, then adding these mechanisms is = non-trivial and probably worth pursuing generically, rather than waiting for a specific = use case. I say that because the nature of the data that has been discussed on the list sounded like the type that will lead to a need for authorization and = because Internet-scale authorization is a challenge. (I believe it's never been done.) If it is ever a requirement to provide it, it needs to be explored now. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md ------=_NextPart_000_001B_01CACA91.29E9FE70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [e2md] Issues slides , please comment

And that certainly represents one of the other 25% of the = use cases.=A0

 

I don’t know what the specific application is in = Finland but in the US ..it is the service that Law Enforcement uses to find the underlying operator for a TN in order to know where to put the alligator = clips. J

 

IMHO the largest economic impact of E2MD is TCAP/SS7-C7 avoidance in closed SIP transit networks where PSTN interconnection data = is needed. =A0I want to see that application preserved and not encumbered = with irrelevant and encumbering requirements that would unquestionably be appropriate and necessary for use in the open DNS.=A0 =

 

Privacy and Security requirements are clearly driven by = the type data exposed bound to network ( and its security) =A0the data resides = in.

 

From:= Nieminen = Klaus [mailto:Klaus.Nieminen@ficora.fi]
Sent: Tuesday, March 23, 2010 1:32 PM
To: Richard Shockey; dcrocker@bbiw.net; Dean Willis
Cc: e2md@ietf.org
Subject: VS: [e2md] Issues slides , please = comment

 

Hi folks,

 

At least in Finland it's a regulatory requirement that operators cooperate = to maintain a free service that describes to which operator the number belongs to. So at least we have it already available in the = Internet:

http://www.siirretytnumerot.fi/ (sry = available only in Finnish)

 

regards,

 

- Klaus

 

L=E4hett=E4j=E4: e2md-bounces@ietf.org = puolesta: Richard Shockey
L=E4hetetty: ti 23.3.2010 19:00
Vastaanottaja: dcrocker@bbiw.net; 'Dean Willis'
Kopio: e2md@ietf.org
Aihe: Re: [e2md] Issues slides , please = comment

Dave = IMHO 75% of the use cases for E2MD will be in controlled access
networks. That is certainly they way it works today in commercial = ENUM
deployments outside of e164.arpa. Clearly there are issues where some = data
is applicable in the public tree and those use cases can be handled by = some
redirection to HTTP or other transport protocols if necessary.

IMHO most of this security discussion is a Red Herring that the ENUM
community settled years ago. LNP data has highly restricted access = for
instance,  but its routinely used in private ENUM trees and the = Internet
hasn't crashed as a result.

We need to offer tools people want to use and leave policy issues to = the
appropriate NRA.

-----Original Message-----
From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dave
CROCKER
Sent: Tuesday, March 23, 2010 10:45 AM
To: Dean Willis
Cc: e2md@ietf.org
Subject: Re: [e2md] Issues slides , please comment



On 3/22/2010 11:37 PM, Dean Willis wrote:
> I have roughed out some open issues slides for the e2md bof. I = believe
list discussion has generated a reasonable proposal for each. Please = review
ASAP.


Folks,

The security-related bullets look reasonable, but my guess is that they = are
missing what's needed.

So, for example, saying 'encryption' always sounds plausible when
referencing
security, but it probably does not apply, here.

Encryption means privacy, but I suspect that privacy (against = wire-tapping)
is
not a major concern for this use.

It is more likely that the necessary security function will be = authorization
--
hence, authentication and access control are the relevant = mechanisms.

Perhaps all such cases are satisfied by using a DNS that is on a
controlled-access net.  If not, then adding these mechanisms is non-trivial
and
probably worth pursuing generically, rather than waiting for a specific = use
case.

I say that because the nature of the data that has been discussed on = the
list
sounded like the type that will lead to a need for authorization and = because

Internet-scale authorization is a challenge.  (I believe it's never = been
done.)

If it is ever a requirement to provide it, it needs to be explored = now.

d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
e2md mailing list
e2md@ietf.org
https://www.ietf.org/= mailman/listinfo/e2md

_______________________________________________
e2md mailing list
e2md@ietf.org
https://www.ietf.org/= mailman/listinfo/e2md

------=_NextPart_000_001B_01CACA91.29E9FE70-- From bernie@ietf.hoeneisen.ch Tue Mar 23 11:04:37 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C2943A6C5D for ; Tue, 23 Mar 2010 11:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FCogRmU45Ug for ; Tue, 23 Mar 2010 11:04:36 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 0C5E93A6ADD for ; Tue, 23 Mar 2010 11:04:35 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nu8TE-00087L-R3 for e2md@ietf.org; Tue, 23 Mar 2010 19:04:52 +0100 Date: Tue, 23 Mar 2010 19:04:52 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Problem Statement & Use Cases slided, please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:04:37 -0000 Hi E2MD BOFers, The current revision of the problem statement and use case slides can be fetched from the tracker: http://www.ietf.org/proceedings/10mar/slides/e2md-2.pdf Please comment! cheers, Bernie From richard@shockey.us Tue Mar 23 11:07:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218B43A6CFF for ; Tue, 23 Mar 2010 11:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD2ZH5MptcI6 for ; Tue, 23 Mar 2010 11:07:27 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 24BBF3A6A22 for ; Tue, 23 Mar 2010 11:07:27 -0700 (PDT) Received: (qmail 30541 invoked by uid 0); 23 Mar 2010 18:07:46 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 23 Mar 2010 18:07:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Dl5v8yq3IBUPQxJVXMyLvnZ90WArocHW3Xr1dWqJkLsgl4T4rczgisgCvpJbT4cVBsjO22JDPMFCs7wyB/9bCF12Xu0RDtnpDZFnUl3TUPYLkIr9HnThzIVrOldBxo73; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nu8W3-0002qI-2h; Tue, 23 Mar 2010 12:07:47 -0600 From: "Richard Shockey" To: "'Dean Willis'" References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> <000001cacab0$029674b0$07c35e10$@us> <4BA8FFAE.7020206@softarmor.com> In-Reply-To: <4BA8FFAE.7020206@softarmor.com> Date: Tue, 23 Mar 2010 14:07:42 -0400 Message-ID: <000701cacab3$bbf283b0$33d78b10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKsYc2+DZSgRAsRvqPZgNUgm+XFAAAa9iQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: e2md@ietf.org, dcrocker@bbiw.net Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:07:29 -0000 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, March 23, 2010 1:52 PM To: Richard Shockey Cc: 'Hadriel Kaplan'; dcrocker@bbiw.net; e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment Richard Shockey wrote: > That is a discussion for the WG not the BOF .. the issue will center on how > the IANA registry is designed and what the recommendations contained in that > registry are for a particular data object. In the open DNS either encryption > or indirection MAY be warranted in closed network environments it MAY not. But before we can have a WG, we have to know the scope of the WG. That means saying, in advance, exactly which problems the WG is going to solve. So for example, deciding in advance whether we are or are not going to solve the open-DNS-with-sensitive-data problem is something we MUST DO. We MUST NOT defer that decision to the WG, because without an answer to that question, the WG will not be formed. RS> I never suggested we should not address the OPEN DNS with sensitive data issue. Only that issue is something the WG should do not the BOF. I do insist that the CLOSED DNS network issues not be ignored, excluded or encumbered with useless requirements that have not been needed in the field up to this time. There is a huge body of experience here that is being discounted. -- dean From bernie@ietf.hoeneisen.ch Tue Mar 23 11:16:17 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C30A33A6CB8 for ; Tue, 23 Mar 2010 11:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUSXrSZ8n8Cu for ; Tue, 23 Mar 2010 11:16:16 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id AB3923A6D49 for ; Tue, 23 Mar 2010 11:15:38 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1Nu8di-0008AR-VC; Tue, 23 Mar 2010 19:15:43 +0100 Date: Tue, 23 Mar 2010 19:15:42 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Richard Shockey In-Reply-To: <001a01cacab2$b0fb9e70$12f2db50$@us> Message-ID: References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com><4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> <001a01cacab2$b0fb9e70$12f2db50$@us> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="37663318-1854723921-1269368142=:28495" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: 'Nieminen Klaus' , "E.164 To MetaData BOF discussion list" , dcrocker@bbiw.net Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:16:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --37663318-1854723921-1269368142=:28495 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 23 Mar 2010, Richard Shockey wrote: >=20 > And that certainly represents one of the other 25% of the use cases.=C2= =A0 >=20 > I don=E2=80=99t know what the specific application is in Finland but in t= he US Well, there is slightly more than 25 % outside the U.S... ;-) However, as a conclusion we can declare, the (Global) Service Provider=20 Identifier, has multiple Use Cases in different environments. Thus, the=20 creation of an E2MD service for this is prooven to be useful by multiple=20 sources. cheers, Bernie > ..it is the service that Law Enforcement uses to find the underlying=20 > operator for a TN in order to know where to put the alligator clips. J >=20 > =C2=A0 >=20 > IMHO the largest economic impact of E2MD is TCAP/SS7-C7 avoidance in clos= ed SIP transit > networks where PSTN interconnection data is needed. =C2=A0I want to see t= hat application preserved > and not encumbered with irrelevant and encumbering requirements that woul= d unquestionably be > appropriate and necessary for use in the open DNS.=C2=A0 >=20 > =C2=A0 >=20 > Privacy and Security requirements are clearly driven by the type data exp= osed bound to network > ( and its security) =C2=A0the data resides in. >=20 > =C2=A0 >=20 > From: Nieminen Klaus [mailto:Klaus.Nieminen@ficora.fi] > Sent: Tuesday, March 23, 2010 1:32 PM > To: Richard Shockey; dcrocker@bbiw.net; Dean Willis > Cc: e2md@ietf.org > Subject: VS: [e2md] Issues slides , please comment >=20 > =C2=A0 >=20 > Hi folks, >=20 > =C2=A0 >=20 > At least in Finland it's a regulatory requirement that operators cooperat= e to maintain a free > service that describes to=C2=A0which operator the number belongs to. So a= t least we have it already > available in the Internet: >=20 > http://www.siirretytnumerot.fi/=C2=A0(sry available only in Finnish) >=20 > =C2=A0 >=20 > regards, >=20 > =C2=A0 >=20 > - Klaus >=20 > =C2=A0 >=20 >=20 > _________________________________________________________________________= _____________________ >=20 >=20 > L=C3=A4hett=C3=A4j=C3=A4: e2md-bounces@ietf.org puolesta: Richard Shockey > L=C3=A4hetetty: ti 23.3.2010 19:00 > Vastaanottaja: dcrocker@bbiw.net; 'Dean Willis' > Kopio: e2md@ietf.org > Aihe: Re: [e2md] Issues slides , please comment >=20 > Dave IMHO 75% of the use cases for E2MD will be in controlled access > networks. That is certainly they way it works today in commercial ENUM > deployments outside of e164.arpa. Clearly there are issues where some dat= a > is applicable in the public tree and those use cases can be handled by so= me > redirection to HTTP or other transport protocols if necessary. >=20 > IMHO most of this security discussion is a Red Herring that the ENUM > community settled years ago. LNP data has highly restricted access for > instance,=C2=A0 but its routinely used in private ENUM trees and the Inte= rnet > hasn't crashed as a result. >=20 > We need to offer tools people want to use and leave policy issues to the > appropriate NRA. >=20 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of D= ave > CROCKER > Sent: Tuesday, March 23, 2010 10:45 AM > To: Dean Willis > Cc: e2md@ietf.org > Subject: Re: [e2md] Issues slides , please comment >=20 >=20 >=20 > On 3/22/2010 11:37 PM, Dean Willis wrote: > > I have roughed out some open issues slides for the e2md bof. I believe > list discussion has generated a reasonable proposal for each. Please revi= ew > ASAP. >=20 >=20 > Folks, >=20 > The security-related bullets look reasonable, but my guess is that they a= re > missing what's needed. >=20 > So, for example, saying 'encryption' always sounds plausible when > referencing > security, but it probably does not apply, here. >=20 > Encryption means privacy, but I suspect that privacy (against wire-tappin= g) > is > not a major concern for this use. >=20 > It is more likely that the necessary security function will be authorizat= ion > -- > hence, authentication and access control are the relevant mechanisms. >=20 > Perhaps all such cases are satisfied by using a DNS that is on a > controlled-access net.=C2=A0 If not, then adding these mechanisms is non-= trivial > and > probably worth pursuing generically, rather than waiting for a specific u= se > case. >=20 > I say that because the nature of the data that has been discussed on the > list > sounded like the type that will lead to a need for authorization and beca= use >=20 > Internet-scale authorization is a challenge.=C2=A0 (I believe it's never = been > done.) >=20 > If it is ever a requirement to provide it, it needs to be explored now. >=20 > d/ > -- >=20 > =C2=A0=C2=A0 Dave Crocker > =C2=A0=C2=A0 Brandenburg InternetWorking > =C2=A0=C2=A0 bbiw.net > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 >=20 > --37663318-1854723921-1269368142=:28495-- From dean.willis@softarmor.com Tue Mar 23 11:24:48 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F203A6ADD for ; Tue, 23 Mar 2010 11:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.327 X-Spam-Level: X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5yZHABanNVF for ; Tue, 23 Mar 2010 11:24:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5515A3A684F for ; Tue, 23 Mar 2010 11:24:41 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NIOolV013954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 13:24:53 -0500 Message-ID: <4BA90771.5070906@softarmor.com> Date: Tue, 23 Mar 2010 13:24:49 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Richard Shockey References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> <000001cacab0$029674b0$07c35e10$@us> <4BA8FFAE.7020206@softarmor.com> <000701cacab3$bbf283b0$33d78b10$@us> In-Reply-To: <000701cacab3$bbf283b0$33d78b10$@us> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org, dcrocker@bbiw.net Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:24:48 -0000 Richard Shockey wrote: > RS> I never suggested we should not address the OPEN DNS with sensitive data > issue. Only that issue is something the WG should do not the BOF. > > I do insist that the CLOSED DNS network issues not be ignored, excluded or > encumbered with useless requirements that have not been needed in the field > up to this time. There is a huge body of experience here that is being > discounted. Ok, that sounds like we're coming to a consensus on the proposed WG scope. This may require a modification to the draft charter to allow for it. -- Dean From dhc2@dcrocker.net Tue Mar 23 11:27:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFFB3A6C62 for ; Tue, 23 Mar 2010 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgyzKmxdg8ne for ; Tue, 23 Mar 2010 11:27:31 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 079D83A6A2C for ; Tue, 23 Mar 2010 11:27:20 -0700 (PDT) Received: from [130.129.28.8] (dhcp-wireless-open-abg-28-8.meeting.ietf.org [130.129.28.8]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o2NIRXhO010609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 11:27:39 -0700 Message-ID: <4BA90810.5030705@dcrocker.net> Date: Tue, 23 Mar 2010 11:27:28 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Richard Shockey References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> <000001cacab0$029674b0$07c35e10$@us> <4BA8FFAE.7020206@softarmor.com> <000701cacab3$bbf283b0$33d78b10$@us> In-Reply-To: <000701cacab3$bbf283b0$33d78b10$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10612/Tue Mar 23 07:14:06 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 23 Mar 2010 11:27:39 -0700 (PDT) Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:27:33 -0000 > RS> I never suggested we should not address the OPEN DNS with sensitive data > issue. Only that issue is something the WG should do not the BOF. > > I do insist that the CLOSED DNS network issues not be ignored, excluded or > encumbered with useless requirements that have not been needed in the field > up to this time. There is a huge body of experience here that is being > discounted. There is the question of discussing fine-grained details, versus the question of basic problems and usage scope. The latter needs to be done /before/ chartering, so that the chartering is substantive and useful, such as giving the working group meaningful focus. One possibility is that the entire task of the working group is: The new wg will extend the set of responses that can be produced for an ENUM query [cite ENUM RFCs]. This inherits all of the settled ENUM OA&M and security decisions and merely specifies some additional RRs that might show up in a query. That's a perfectly fine charter semantic and scope, IMO, if it satisfies the needs of the effort. My impression is that it doesn't. There appears to be interest in discussing transfer mechanisms (DNS vs. other) and security issues (especially authorization or not). Such a discussion could reasonably start with the null hypothesis: All transfer and security issues for the new effort are the same as have been resolved for ENUM [cite RFCs]. This places the onus for changing scope or functions of the new effort on those claiming something different is needed. But this is a charter-time requirement, not a wg-time requirement. I don't mean that the transfer or security issues need to be settled, but that their basic requirement needs to be agreed to, so that the charter specifies the gist of what is need (that is different from ENUM). Otherwise, it will not be clear and settled as to the problems that are going to be worked on. Absent any of this, the charter needs to make an assertion of which aspects of ENUM provide the foundation for the new group (and what parts it doesn't). The charter already cites ENUM as the foundation. However it doesn't cite it with respect to specifying constraints and assumptions for the new effort. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Klaus.Nieminen@ficora.fi Tue Mar 23 11:31:26 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F5293A6C91 for ; Tue, 23 Mar 2010 11:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.528 X-Spam-Level: ** X-Spam-Status: No, score=2.528 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqnI2+SzRldA for ; Tue, 23 Mar 2010 11:31:23 -0700 (PDT) Received: from out2.ficora.fi (out2.ficora.fi [87.239.124.62]) by core3.amsl.com (Postfix) with ESMTP id A834E3A6CFB for ; Tue, 23 Mar 2010 11:31:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,296,1267394400"; d="scan'208,217";a="736806" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CACAB7.0ED29E22" Date: Tue, 23 Mar 2010 20:31:30 +0200 Message-ID: <07BC6C0D40216E44A34BE6701694FE8608628E2B@POSTI.laru.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] Issues slides , please comment Thread-Index: AcrKmC11oPAWAhi7S8SA7JAdVXdy9gAES1WgAAEVut8AAOljgAABNqjG References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com><4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> <001a01cacab2$b0fb9e70$12f2db50$@us> From: "Nieminen Klaus" To: "Richard Shockey" , , "Dean Willis" Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:31:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CACAB7.0ED29E22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I don't know what the specific application is in Finland but in the US = ..it is the service that=20 > Law Enforcement uses to find the underlying operator for a TN in order = to know where to=20 > put the alligator clips. J =20 The requirement was imposed to enable users to know the call tariff = before making the call. Anyway I think that the reason is not really = important. My point is that I don't see any real problems in publishing = that information. =20 - Klaus =20 ------_=_NextPart_001_01CACAB7.0ED29E22 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [e2md] Issues slides , please = comment=0A= =0A= =0A= =0A= =0A= =0A=
=0A=
> I don’t know what the = specific application is in Finland but in the US ..it is the service = that
=0A=
> Law Enforcement uses to find the = underlying operator for a TN in order to know where to
=0A=
> put the alligator clips. = J
=0A=
=0A=
=0A=
=0A=
=0A=

 

=0A=

The requirement was imposed to = enable users to know the call tariff before making the call. Anyway I = think that the reason is not really important. My = point is that I don't see any real problems in publishing that = information.

=0A=
 
=0A=
=0A=

- Klaus

=0A=
=0A=

 

------_=_NextPart_001_01CACAB7.0ED29E22-- From dean.willis@softarmor.com Tue Mar 23 13:16:37 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C7BD3A6A20 for ; Tue, 23 Mar 2010 13:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.713 X-Spam-Level: X-Spam-Status: No, score=0.713 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QPvYRYDTMkJ for ; Tue, 23 Mar 2010 13:16:36 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 98EAE3A69D6 for ; Tue, 23 Mar 2010 13:16:36 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NKGnlE014784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 15:16:51 -0500 Message-ID: <4BA921B0.1090700@softarmor.com> Date: Tue, 23 Mar 2010 15:16:48 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Nieminen Klaus References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com><4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> <001a01cacab2$b0fb9e70$12f2db50$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2B@POSTI.laru.local> In-Reply-To: <07BC6C0D40216E44A34BE6701694FE8608628E2B@POSTI.laru.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:16:37 -0000 Nieminen Klaus wrote: >> I don’t know what the specific application is in Finland but in the US > ..it is the service that >> Law Enforcement uses to find the underlying operator for a TN in order > to know where to >> put the alligator clips. J > > The requirement was imposed to enable users to know the call tariff > before making the call. Anyway I think that the reason is not really > important. My point is that I don't see any real problems in publishing > that information. > Well, service providers who make their living selling access to the US' number-porting database might feel differently. Or they might not, depending on how they see their business model evolving. -- dean From Ray.Bellis@nominet.org.uk Tue Mar 23 13:20:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C493A67E4 for ; Tue, 23 Mar 2010 13:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.168 X-Spam-Level: X-Spam-Status: No, score=-4.168 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOw-axZB-p5Z for ; Tue, 23 Mar 2010 13:20:48 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 3E0683A6784 for ; Tue, 23 Mar 2010 13:20:48 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=hatawyJ6Gy21LqRd0L3aBO/qPGYnH6Sp7bzbQ49w63UuhpkPtxiUDX3E FQBhustoaX9ZffqEZDlDHeU+vW98ufSvEoCFjngRliAFCNEp0Obwq6ryN We3MCrfgz/GRVJc; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269375668; x=1300911668; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Issues=20slides=20,=20please=20comment|Date:=20Tue, =2023=20Mar=202010=2012:21:05=20-0800|Message-ID:=20|To:=20Dean=20Willis=20|Cc:=20e2md@ietf.org|MIME-Version:=201.0 |In-Reply-To:=20<4BA921B0.1090700@softarmor.com> |References:=20<69fa754c-393d-4f05-a8d0-25d195687e1c@emai l.android.com><4BA8D3D5.9050906@dcrocker.net>=0D=0A=09<01 2f01cacaaa$5e03aa30$1a0afe90$@us>=09<07BC6C0D40216E44A34B E6701694FE8608628E2A@POSTI.laru.local>=0D=0A=09<001a01cac ab2$b0fb9e70$12f2db50$@us>=09<07BC6C0D40216E44A34BE670169 4FE8608628E2B@POSTI.laru.local>=20<4BA921B0.1090700@softa rmor.com>; bh=WCk2Kj1g9elvMoW6JRBFosvFcmX1VtWsttCmB0Wwu0M=; b=NxrWr/82HJp1sM9hKx4RImDmj50J5yEFabm+HYE5bag0QNKiOzvc0mUi 8/3T69ErBjCYRbg2vMqhrwnmWT9QC5L6ydfW5f/rmtmMBpPMb86JgsHDa rEiXMhZopZEiB4R; X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="22826100" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Mar 2010 20:21:06 +0000 In-Reply-To: <4BA921B0.1090700@softarmor.com> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com><4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> <001a01cacab2$b0fb9e70$12f2db50$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2B@POSTI.laru.local> <4BA921B0.1090700@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 23 Mar 2010 12:21:05 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/03/2010 08:21:06 PM, Serialize complete at 23/03/2010 08:21:06 PM Content-Type: multipart/alternative; boundary="=_alternative 006FCB2A882576EF_=" Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:20:50 -0000 This is a multipart message in MIME format. --=_alternative 006FCB2A882576EF_= Content-Type: text/plain; charset="US-ASCII" > Well, service providers who make their living selling access to the US' > number-porting database might feel differently. Or they might not, > depending on how they see their business model evolving. That's true, but their business models are none of IETF's business. However devising a standard means of describing that information is. Ray --=_alternative 006FCB2A882576EF_= Content-Type: text/html; charset="US-ASCII"
> Well, service providers who make their living selling access to the US'
> number-porting database might feel differently. Or they might not,
> depending on how they see their business model evolving.
That's true, but their business models are none of IETF's business.

However devising a standard means of describing that information is.

Ray
--=_alternative 006FCB2A882576EF_=-- From dean.willis@softarmor.com Tue Mar 23 13:22:48 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F203A6A1F for ; Tue, 23 Mar 2010 13:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnOH45nZksOJ for ; Tue, 23 Mar 2010 13:22:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AC7FE3A6946 for ; Tue, 23 Mar 2010 13:22:34 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NKMpEO014865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Mar 2010 15:22:53 -0500 Message-ID: <4BA9231A.1070506@softarmor.com> Date: Tue, 23 Mar 2010 15:22:50 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:22:48 -0000 I was asked this question today and did not havea good answer handy. E2MD is currently proposed as a framework. That is, we essentially have a single database table that holds records for each data type. One record might be a CNAM, the next might be an "unused" etc. The record type is a subkey and we can query on it, like E2M+cnam or E2M+gspid Why do we do this as opposed to having a separate table for each data type, perhaps E2CNAM and E2GSPID? It was put to me that some people see this as an end-run for getting stuff into the DNS that wouldn't be allowed if it were being reviewed at the top level, and that it would be much easier to get a working group for something like E2CNAM than it will be for our open-ended model. -- Dean From richard@shockey.us Tue Mar 23 13:35:05 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800D53A6A0C for ; Tue, 23 Mar 2010 13:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlMrmpmGgrgb for ; Tue, 23 Mar 2010 13:35:04 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 5A4F43A69F2 for ; Tue, 23 Mar 2010 13:35:04 -0700 (PDT) Received: (qmail 23801 invoked by uid 0); 23 Mar 2010 19:35:23 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 23 Mar 2010 19:35:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=D36QZiuQ7oy3nyGtQE+gNnIJnvAe1i8pJQQmCI/zmjmelV0QyMeneiaK4L8ANe3Oqh0LRVenxQ004V0uUdRDZhai5IIzd7uCFaI8UZntpfu3vlK2cCI9woZuEl9ax2u/; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuAou-0004UY-Di; Tue, 23 Mar 2010 14:35:24 -0600 From: "Richard Shockey" To: References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> <000001cacab0$029674b0$07c35e10$@us> <4BA8FFAE.7020206@softarmor.com> <000701cacab3$bbf283b0$33d78b10$@us> <4BA90810.5030705@dcrocker.net> In-Reply-To: <4BA90810.5030705@dcrocker.net> Date: Tue, 23 Mar 2010 16:35:19 -0400 Message-ID: <005001cacac8$5b8a7130$129f5390$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKtoW7tfQKZeXFRXi4Mtlj11Zt8gAEOk7w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:35:05 -0000 > > I do insist that the CLOSED DNS network issues not be ignored, excluded or > encumbered with useless requirements that have not been needed in the field > up to this time. There is a huge body of experience here that is being > discounted. There is the question of discussing fine-grained details, versus the question of basic problems and usage scope. The latter needs to be done /before/ chartering, so that the chartering is substantive and useful, such as giving the working group meaningful focus. One possibility is that the entire task of the working group is: The new wg will extend the set of responses that can be produced for an ENUM query [cite ENUM RFCs]. This inherits all of the settled ENUM OA&M and security decisions and merely specifies some additional RRs that might show up in a query. That's a perfectly fine charter semantic and scope, IMO, if it satisfies the needs of the effort. RS> Needless to say I would have been perfectly happy with this scope, with some extensions, caveats and registry considerations on the use of PII and NRA related data in public DNS trees and leave it to the WG to sort it out the mechanisms. **************** My impression is that it doesn't. There appears to be interest in discussing transfer mechanisms (DNS vs. other) and security issues (especially authorization or not). Such a discussion could reasonably start with the null hypothesis: All transfer and security issues for the new effort are the same as have been resolved for ENUM [cite RFCs]. This places the onus for changing scope or functions of the new effort on those claiming something different is needed. But this is a charter-time requirement, not a wg-time requirement. I don't mean that the transfer or security issues need to be settled, but that their basic requirement needs to be agreed to, so that the charter specifies the gist of what is need (that is different from ENUM). Otherwise, it will not be clear and settled as to the problems that are going to be worked on. Absent any of this, the charter needs to make an assertion of which aspects of ENUM provide the foundation for the new group (and what parts it doesn't). The charter already cites ENUM as the foundation. However it doesn't cite it with respect to specifying constraints and assumptions for the new effort. RS> We know what the problem is ..data about phone numbers that cannot be expressed as a URI. Wasn't that clear? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Ray.Bellis@nominet.org.uk Tue Mar 23 13:40:18 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D733A6B63 for ; Tue, 23 Mar 2010 13:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.818 X-Spam-Level: X-Spam-Status: No, score=-4.818 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvCbmadYr2+d for ; Tue, 23 Mar 2010 13:40:15 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id CA55B3A6B98 for ; Tue, 23 Mar 2010 13:40:14 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=wI91jBbahy8BrCDJI+w0IXG1fR5b5o6DVBp7vm/xw29RgXqy4kp0XJ4p SVGIGZVpU7/8FBNsLf/GMxrWxp35hGKoPUKXGwP9LHV/TX+UnLkMMhW+/ iVquROYP1SXFoIO; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269376834; x=1300912834; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Why=20do=20we=20have=20a=20framework=20instead=20of =20discrete=20services?|Date:=20Tue,=2023=20Mar=202010=20 12:40:30=20-0800|Message-ID:=20|To:=20De an=20Willis=20|Cc:=20"E.164=20 To=20MetaData=20BOF=20discussion=20list"=20|MIME-Version:=201.0|In-Reply-To:=20<4BA9231A.1070506@so ftarmor.com>|References:=20<4BA9231A.1070506@softarmor.co m>; bh=yhpGc16aBzPV+/B8UfXVicCtlExPbnMiLsfhAAbSt4M=; b=bymX/o8rpUYTGHmFw9NDAuVMgqrznH95YrRb0fpUN0/fblLdDa0MU2PG qhkuUY2wTIRtKWbGl5KoJbLBkbuGNfBp2LyaZiH+bmgqr0wT3r3kdbWik 6BEFLrB4ke6SUR6; X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="22826296" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Mar 2010 20:40:33 +0000 In-Reply-To: <4BA9231A.1070506@softarmor.com> References: <4BA9231A.1070506@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 23 Mar 2010 12:40:30 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/03/2010 08:40:33 PM, Serialize complete at 23/03/2010 08:40:33 PM Content-Type: multipart/alternative; boundary="=_alternative 0071924E882576EF_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:40:19 -0000 This is a multipart message in MIME format. --=_alternative 0071924E882576EF_= Content-Type: text/plain; charset="US-ASCII" > I was asked this question today and did not havea good answer handy. > > E2MD is currently proposed as a framework. That is, we essentially have > a single database table that holds records for each data type. One > record might be a CNAM, the next might be an "unused" etc. The record > type is a subkey and we can query on it, like E2M+cnam or E2M+gspid > > Why do we do this as opposed to having a separate table for each data > type, perhaps E2CNAM and E2GSPID? I have no great answer either, except that any argument made in favour of E2CNAM, E2SPID, etc, could equally apply to ENUM proper. In any event, using E2CNAM etc would require a new full DDDS application for each potential record type. By comparison setting up a framework which is 98% the same as ENUM's and then following the E2U service registration process should actually be much simpler in the long run. > It was put to me that some people see this as an end-run for getting > stuff into the DNS that wouldn't be allowed if it were being reviewed at > the top level, and that it would be much easier to get a working group > for something like E2CNAM than it will be for our open-ended model. The correct view (IMHO) on "getting stuff into the DNS" is that there is no problem using the DNS for anything - DNSEXT for example is concerned with protocol issues (RRs, etc) and _not_ with whether it's actually good policy to store any particular stuff in the DNS. In effect, there is no "end-run" because it's simply not the job of any part of the IETF to decide what is or is not "allowed" in the DNS. Ray --=_alternative 0071924E882576EF_= Content-Type: text/html; charset="US-ASCII"
> I was asked this question today and did not havea good answer handy.
>
> E2MD is currently proposed as a framework. That is, we essentially have
> a single database table that holds records for each data type. One
> record might be a CNAM, the next might be an "unused" etc. The record
> type is a subkey and we can query on it, like E2M+cnam or E2M+gspid
>
> Why do we do this as opposed to having a separate table for each data
> type, perhaps E2CNAM and E2GSPID?
I have no great answer either, except that any argument made in favour of E2CNAM, E2SPID, etc, could equally apply to ENUM proper.

In any event, using E2CNAM etc would require a new full DDDS application for each potential record type.  By comparison setting up a framework which is 98% the same as ENUM's and then following the E2U service registration process should actually be much simpler in the long run.  

> It was put to me that some people see this as an end-run for getting
> stuff into the DNS that wouldn't be allowed if it were being reviewed at
> the top level, and that it would be much easier to get a working group
> for something like E2CNAM than it will be for our open-ended model.
The correct view (IMHO) on "getting stuff into the DNS" is that there is no problem using the DNS for anything - DNSEXT for example is concerned with protocol issues (RRs, etc) and _not_ with whether it's actually good policy to store any particular stuff in the DNS.

In effect, there is no "end-run" because it's simply not the job of any part of the IETF to decide what is or is not "allowed" in the DNS.

Ray


--=_alternative 0071924E882576EF_=-- From HKaplan@acmepacket.com Tue Mar 23 13:41:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386993A6C26 for ; Tue, 23 Mar 2010 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[AWL=1.490, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS8ZfVWcoO1h for ; Tue, 23 Mar 2010 13:41:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 84D283A6C14 for ; Tue, 23 Mar 2010 13:41:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 23 Mar 2010 16:41:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 23 Mar 2010 16:41:47 -0400 From: Hadriel Kaplan To: "Ray.Bellis@nominet.org.uk" , Dean Willis Date: Tue, 23 Mar 2010 16:41:46 -0400 Thread-Topic: [e2md] Issues slides , please comment Thread-Index: AcrKxmHv6tHTFDZ+RQCGipB7tDwx8QAAo/tg Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1C18@mail> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com><4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2A@POSTI.laru.local> <001a01cacab2$b0fb9e70$12f2db50$@us> <07BC6C0D40216E44A34BE6701694FE8608628E2B@POSTI.laru.local> <4BA921B0.1090700@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79CD1C18mail_" MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:41:33 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79CD1C18mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the comment was in context of "would anyone ever want to keep the d= ata private"? To which the answer is probably, "yes". (although LNP routing/queries requires more than just knowing the spid, obv= iously) -hadriel ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray= .Bellis@nominet.org.uk Sent: Tuesday, March 23, 2010 4:21 PM To: Dean Willis Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment > Well, service providers who make their living selling access to the US' > number-porting database might feel differently. Or they might not, > depending on how they see their business model evolving. That's true, but their business models are none of IETF's business. However devising a standard means of describing that information is. Ray --_000_430FC6BDED356B4C8498F634416644A91A79CD1C18mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the comment was in context of = “would anyone ever want to keep the data private”?  To which the answer= is probably, “yes”.

(although LNP routing/queries requires more than just knowing the spid, obviously)

-hadriel

 

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray.Bellis@nomine= t.org.uk
Sent: Tuesday, March 23, 201= 0 4:21 PM
To: Dean Willis
Cc: e2md@ietf.org
Subject: Re: [e2md] Issues s= lides , please comment

 


> Well, service providers who make their = living selling access to the US'
> number-porting database might feel differently. Or they might not,
> depending on how they see their busines= s model evolving.

Th= at's true, but their business models are none of IETF's business. <= br>
Ho= wever devising a standard means of describing that information is.<= /tt>

Ra= y

--_000_430FC6BDED356B4C8498F634416644A91A79CD1C18mail_-- From HKaplan@acmepacket.com Tue Mar 23 13:42:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334D03A6C2E for ; Tue, 23 Mar 2010 13:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=1.241, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3BGmcrMB5pi for ; Tue, 23 Mar 2010 13:42:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3D7D53A6C26 for ; Tue, 23 Mar 2010 13:42:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 23 Mar 2010 16:42:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 23 Mar 2010 16:42:46 -0400 From: Hadriel Kaplan To: "Ray.Bellis@nominet.org.uk" , Dean Willis Date: Tue, 23 Mar 2010 16:42:45 -0400 Thread-Topic: [e2md] Why do we have a framework instead of discrete services? Thread-Index: AcrKyR76baagow37T7Cr7M8ekZweyAAADY1g Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1C19@mail> References: <4BA9231A.1070506@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79CD1C19mail_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:42:28 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79CD1C19mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Amen to that. ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray= .Bellis@nominet.org.uk Sent: Tuesday, March 23, 2010 4:41 PM To: Dean Willis The correct view (IMHO) on "getting stuff into the DNS" is that there is no= problem using the DNS for anything - DNSEXT for example is concerned with = protocol issues (RRs, etc) and _not_ with whether it's actually good policy= to store any particular stuff in the DNS. In effect, there is no "end-run" because it's simply not the job of any par= t of the IETF to decide what is or is not "allowed" in the DNS. Ray --_000_430FC6BDED356B4C8498F634416644A91A79CD1C19mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Amen to that.=

 

 

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray.Bellis@nomine= t.org.uk
Sent: Tuesday, March 23, 201= 0 4:41 PM
To: Dean Willis

The correct view (IMH= O) on "getting stuff into the DNS" is that there is no problem using th= e DNS for anything - DNSEXT for example is concerned with protocol issues (RR= s, etc) and _not_ with whether it's actually good policy to store any particul= ar stuff in the DNS.

In= effect, there is no "end-run" because it's simply not the job of any part= of the IETF to decide what is or is not "allowed" in the DNS.=

Ra= y

--_000_430FC6BDED356B4C8498F634416644A91A79CD1C19mail_-- From Ray.Bellis@nominet.org.uk Tue Mar 23 13:43:14 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB49D3A67F9 for ; Tue, 23 Mar 2010 13:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.035 X-Spam-Level: X-Spam-Status: No, score=-5.035 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usO4gvOK9j4O for ; Tue, 23 Mar 2010 13:43:13 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 618653A68DC for ; Tue, 23 Mar 2010 13:43:13 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=CvdhWdX/p0UwbqwBj4vkmRfjckWW5Rvot+UvFvIc1gRVETmQfEfUJ9Qa Us01UBZuLmfKOELA/Mx0j7buCmOZz2w5KcrK/8wczD/ioRYAlTTTb10wj cEumrZiFzjdyga+; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269377013; x=1300913013; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Issues=20slides=20,=20please=20comment|Date:=20Tue, =2023=20Mar=202010=2012:43:28=20-0800|Message-ID:=20|To:=20"Richard=20Shockey"=20|Cc:=20dcrocker@bbiw.net,=0D=0A=09e2md@ietf.org |MIME-Version:=201.0|In-Reply-To:=20<005001cacac8$5b8a713 0$129f5390$@us>|References:=20<69fa754c-393d-4f05-a8d0-25 d195687e1c@email.android.com>=09<4BA8D3D5.9050906@dcrocke r.net>=0D=0A=09<012f01cacaaa$5e03aa30$1a0afe90$@us>=09<43 0FC6BDED356B4C8498F634416644A91A79CD1B7A@mail>=0D=0A=09<0 00001cacab0$029674b0$07c35e10$@us>=09<4BA8FFAE.7020206@so ftarmor.com>=09<000701cacab3$bbf283b0$33d78b10$@us>=0D=0A =09<4BA90810.5030705@dcrocker.net>=20<005001cacac8$5b8a71 30$129f5390$@us>; bh=595RW7HK8wROLir3sZEGP2hi5wmJf2EAN6sV31jd9sk=; b=e/CFGhKFcBzs6Z3denZgCTU7qsW8M5p+Yzj6c2Bp4/aVwIybrm+rVS7Q kKhNUxY9CnH8sKS72V95sQVqMHik4bPc/KxxqvYcdc0AqMLjArVitKy0M ll0RexYsN4v2Nux; X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="22826343" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Mar 2010 20:43:32 +0000 In-Reply-To: <005001cacac8$5b8a7130$129f5390$@us> References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> <000001cacab0$029674b0$07c35e10$@us> <4BA8FFAE.7020206@softarmor.com> <000701cacab3$bbf283b0$33d78b10$@us> <4BA90810.5030705@dcrocker.net> <005001cacac8$5b8a7130$129f5390$@us> To: "Richard Shockey" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 23 Mar 2010 12:43:28 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/03/2010 08:43:32 PM, Serialize complete at 23/03/2010 08:43:32 PM Content-Type: multipart/alternative; boundary="=_alternative 0071D779882576EF_=" Cc: e2md@ietf.org, dcrocker@bbiw.net Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:43:15 -0000 This is a multipart message in MIME format. --=_alternative 0071D779882576EF_= Content-Type: text/plain; charset="US-ASCII" Rich wrote: > Needless to say I would have been perfectly happy with this scope, with > some extensions, caveats and registry considerations on the use of PII and > NRA related data in public DNS trees and leave it to the WG to sort it out > the mechanisms. +1 > We know what the problem is ..data about phone numbers that cannot be > expressed as a URI. Wasn't that clear? and another +1 Ray --=_alternative 0071D779882576EF_= Content-Type: text/html; charset="US-ASCII" Rich wrote:

> Needless to say I would have been perfectly happy with this scope, with
> some extensions, caveats and registry considerations on the use of PII and
> NRA related data in public DNS trees and leave it to the WG to sort it out
> the mechanisms.

+1

> We know what the problem is ..data about phone numbers that cannot be
> expressed as a URI. Wasn't that clear?

and another +1

Ray
--=_alternative 0071D779882576EF_=-- From dcrocker@bbiw.net Tue Mar 23 13:45:49 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128263A690F for ; Tue, 23 Mar 2010 13:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g11EKehWSzC2 for ; Tue, 23 Mar 2010 13:45:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 130B33A67F9 for ; Tue, 23 Mar 2010 13:45:48 -0700 (PDT) Received: from [130.129.40.94] (dhcp-wireless-open-a-40-94.meeting.ietf.org [130.129.40.94]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o2NKk20u018376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 13:46:07 -0700 Message-ID: <4BA92883.4000505@bbiw.net> Date: Tue, 23 Mar 2010 13:45:55 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Richard Shockey References: <69fa754c-393d-4f05-a8d0-25d195687e1c@email.android.com> <4BA8D3D5.9050906@dcrocker.net> <012f01cacaaa$5e03aa30$1a0afe90$@us> <430FC6BDED356B4C8498F634416644A91A79CD1B7A@mail> <000001cacab0$029674b0$07c35e10$@us> <4BA8FFAE.7020206@softarmor.com> <000701cacab3$bbf283b0$33d78b10$@us> <4BA90810.5030705@dcrocker.net> <005001cacac8$5b8a7130$129f5390$@us> In-Reply-To: <005001cacac8$5b8a7130$129f5390$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10613/Tue Mar 23 11:43:58 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 23 Mar 2010 13:46:07 -0700 (PDT) X-Mailman-Approved-At: Tue, 23 Mar 2010 13:49:18 -0700 Cc: e2md@ietf.org Subject: Re: [e2md] Issues slides , please comment X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:45:49 -0000 On 3/23/2010 1:35 PM, Richard Shockey wrote: > The charter already cites ENUM as the foundation. However it doesn't cite > it with respect to specifying constraints and assumptions for the new > effort. > > RS> We know what the problem is ..data about phone numbers that cannot be > expressed as a URI. Wasn't that clear? Oh yes, it definitely raises and resolves all relevant questions. That's why this thread is not happening. Richard, although the charter makes a statement about the kind of data responses it seeks to enable, it does not define scope, mechanism or security issues, although each of those is of fundamental importance to the effort. That's what prompted this thread. And that's why this thread is appropriate to have been raised. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dean.willis@softarmor.com Tue Mar 23 13:53:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DDB3A6965 for ; Tue, 23 Mar 2010 13:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvcqMAs2pv+b for ; Tue, 23 Mar 2010 13:53:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E10203A694F for ; Tue, 23 Mar 2010 13:53:48 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NKs66O015156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 23 Mar 2010 15:54:08 -0500 Message-ID: <4BA92A6B.2010309@softarmor.com> Date: Tue, 23 Mar 2010 15:54:03 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:53:50 -0000 since there isa major collision with the ISDN acronym Service Profile ID, aka SPID. This one tripped me up at first. see: http://en.wikipedia.org/wiki/SPID -- Dean From bernie@ietf.hoeneisen.ch Tue Mar 23 14:03:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1203F3A67F9 for ; Tue, 23 Mar 2010 14:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH5ZGe7JqNdn for ; Tue, 23 Mar 2010 14:03:27 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id BB6583A6850 for ; Tue, 23 Mar 2010 14:03:26 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NuBGJ-000125-Jn; Tue, 23 Mar 2010 22:03:43 +0100 Date: Tue, 23 Mar 2010 22:03:43 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Dean Willis In-Reply-To: <4BA9231A.1070506@softarmor.com> Message-ID: References: <4BA9231A.1070506@softarmor.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:03:28 -0000 Hi Dean In the following a non-exhausive list of arguments in favour of the framework approach for E2MD: - we have over 10 potential Use Cases on the table (see archives of this mailing list) - the framework model scales better - To call a BoF for every single E2MD services is too much overhead - Having a permanent WG to deal with new E2MD service proposals is not sensible either - E2MD services as AD sponsored has the potential to end up in a mess at least in the long run - Expert Review will catch the dangerous stuff, the expert will have clear guidelines - Prevent the IESG from unnecessairy load (as there will guidelines, a process and experts in place to support the IESG) - we can re-use 95 % of the work we did in ENUM (no big effort anymore) - IANA will be the central place to lookup what E2MD services exist (as opposed to the Table 2/3 issues we discussed in SIPCORE today) - more to come...? cheers, Bernie On Tue, 23 Mar 2010, Dean Willis wrote: > > I was asked this question today and did not havea good answer handy. > > E2MD is currently proposed as a framework. That is, we essentially have > a single database table that holds records for each data type. One > record might be a CNAM, the next might be an "unused" etc. The record > type is a subkey and we can query on it, like E2M+cnam or E2M+gspid > > Why do we do this as opposed to having a separate table for each data > type, perhaps E2CNAM and E2GSPID? > > It was put to me that some people see this as an end-run for getting > stuff into the DNS that wouldn't be allowed if it were being reviewed at > the top level, and that it would be much easier to get a working group > for something like E2CNAM than it will be for our open-ended model. > > -- > Dean > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From pp3129@att.com Tue Mar 23 14:09:18 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BFCB3A69C8 for ; Tue, 23 Mar 2010 14:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.869 X-Spam-Level: X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM4+B5kd4-lo for ; Tue, 23 Mar 2010 14:09:15 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id A0AEB3A684F for ; Tue, 23 Mar 2010 14:09:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1269378573!43214913!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 12670 invoked from network); 23 Mar 2010 21:09:34 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Mar 2010 21:09:34 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2NL9MUu024939 for ; Tue, 23 Mar 2010 17:09:22 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2NL9Ilb024888 for ; Tue, 23 Mar 2010 17:09:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Mar 2010 17:09:27 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <4BA92A6B.2010309@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] We need another acronym besides SPID for service provider ID Thread-Index: AcrKywRGVTVXRQwYRc+7X7TQDGRLTgAAavaQ References: <4BA92A6B.2010309@softarmor.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "Dean Willis" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:09:18 -0000 Two thoughts.=20 1. Do we really need to worry about this? As in the trademark issues, how likely is it that anyone will be confused given the different contexts. In recent ATIS PTSC contributions it's been SPID and, if anyone should be concerned, they should. 2. If it really is a problem, the i3 Forum has been using "SPN." (They like SP number for some reason). Cheers, Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, March 23, 2010 4:54 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] We need another acronym besides SPID for service provider ID since there isa major collision with the ISDN acronym Service Profile ID, aka SPID. This one tripped me up at first. see: http://en.wikipedia.org/wiki/SPID -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Tue Mar 23 14:15:49 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC77E3A6C8C for ; Tue, 23 Mar 2010 14:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjDGaCl2XHMo for ; Tue, 23 Mar 2010 14:15:49 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DE46A3A6C8F for ; Tue, 23 Mar 2010 14:15:39 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NLFlKM015356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 16:15:49 -0500 Message-ID: <4BA92F82.3090903@softarmor.com> Date: Tue, 23 Mar 2010 16:15:46 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Bernie Hoeneisen References: <4BA9231A.1070506@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:15:49 -0000 Bernie Hoeneisen wrote: > Hi Dean > > In the following a non-exhausive list of arguments in favour of the > framework approach for E2MD: > > - we have over 10 potential Use Cases on the table > (see archives of this mailing list) > > - the framework model scales better > > - To call a BoF for every single E2MD services is too much overhead > > - Having a permanent WG to deal with new E2MD service proposals > is not sensible either > > - E2MD services as AD sponsored has the potential to end up in > a mess at least in the long run > > - Expert Review will catch the dangerous stuff, the expert will have > clear guidelines > > - Prevent the IESG from unnecessairy load (as there will guidelines, > a process and experts in place to support the IESG) > > - we can re-use 95 % of the work we did in ENUM (no big effort anymore) > > - IANA will be the central place to lookup what E2MD services exist > (as opposed to the Table 2/3 issues we discussed in SIPCORE today) I'm afraid that almost all of those are seen as arguments by the AD who asked me the question for OPPOSING a framework approach, not creating one. Some people really don't want it to be so easy to create new metadata types, and see "having to BOF and form a working group" as a very reasonable threshold for initiating the work. And inheriting the badness of ENUM (along with its goodness) might not be a desirable goal. Arguments FOR a framework would seem to be more related to the structural similarity of the data, the commonality of access control across different data types, the probability that you would really want to do just ONE query and get back all the different metadata types, and things like that. In other words, structural reasons for a framework, not process/political ones. -- Dean From dean.willis@softarmor.com Tue Mar 23 14:20:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B09C3A690F for ; Tue, 23 Mar 2010 14:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ2a8hBDPjL6 for ; Tue, 23 Mar 2010 14:20:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0F4193A68DC for ; Tue, 23 Mar 2010 14:20:24 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NLKfU4015459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 16:20:42 -0500 Message-ID: <4BA930A7.9080002@softarmor.com> Date: Tue, 23 Mar 2010 16:20:39 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "PFAUTZ, PENN L (ATTCORP)" References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:20:30 -0000 PFAUTZ, PENN L (ATTCORP) wrote: > Two thoughts. > 1. Do we really need to worry about this? As in the trademark issues, > how likely is it that anyone will be confused given the different > contexts. In recent ATIS PTSC contributions it's been SPID and, if > anyone should be concerned, they should. Well, it confused me. Richard said we needed a SPID, so I googled SPID and got pointed at the ISDN reference, which I then recalled from my ISDN days. Now, I may be a crufty old bird, but I'm not the only one in the flock. > 2. If it really is a problem, the i3 Forum has been using "SPN." (They > like SP number for some reason). > I do like that better, actually. The Free Dictionary lists no major collisions in telecom/network outside of Microsoft's "Service Principal Name", which is a pretty similar functionality. -- dean From bernie@ietf.hoeneisen.ch Tue Mar 23 14:24:13 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C483A6C82 for ; Tue, 23 Mar 2010 14:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1MJzUlIaC27 for ; Tue, 23 Mar 2010 14:24:12 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 2F7D33A68E0 for ; Tue, 23 Mar 2010 14:24:10 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NuBaN-00018D-Rw; Tue, 23 Mar 2010 22:24:27 +0100 Date: Tue, 23 Mar 2010 22:24:27 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Dean Willis In-Reply-To: <4BA92F82.3090903@softarmor.com> Message-ID: References: <4BA9231A.1070506@softarmor.com> <4BA92F82.3090903@softarmor.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:24:13 -0000 On Tue, 23 Mar 2010, Dean Willis wrote: > I'm afraid that almost all of those are seen as arguments by the AD who > asked me the question for OPPOSING a framework approach, not creating > one. Some people really don't want it to be so easy to create new > metadata types, and see "having to BOF and form a working group" as a > very reasonable threshold for initiating the work. And inheriting the > badness of ENUM (along with its goodness) might not be a desirable goal. Question for clarification: Are we here in a Layer 7- or Layer 9+ discussion??? cheers, Bernie From dean.willis@softarmor.com Tue Mar 23 14:30:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B393A6B63 for ; Tue, 23 Mar 2010 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkPQFmswlsdX for ; Tue, 23 Mar 2010 14:30:02 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B21003A68E0 for ; Tue, 23 Mar 2010 14:30:01 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NLU9IN015548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 16:30:11 -0500 Message-ID: <4BA932DE.1090609@softarmor.com> Date: Tue, 23 Mar 2010 16:30:06 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Bernie Hoeneisen References: <4BA9231A.1070506@softarmor.com> <4BA92F82.3090903@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:30:04 -0000 Bernie Hoeneisen wrote: > > > On Tue, 23 Mar 2010, Dean Willis wrote: > >> I'm afraid that almost all of those are seen as arguments by the AD who >> asked me the question for OPPOSING a framework approach, not creating >> one. Some people really don't want it to be so easy to create new >> metadata types, and see "having to BOF and form a working group" as a >> very reasonable threshold for initiating the work. And inheriting the >> badness of ENUM (along with its goodness) might not be a desirable goal. > > Question for clarification: > Are we here in a Layer 7- or Layer 9+ discussion??? Certainly when one is talking about IETF policy and IESG preference, especially in the context of such a subjective topic as "The DNS", one is operating above ISO Layer 7. Framing one's arguments in favor of doing something in terms that align with those higher layers and are also supported at 7- is more likely to succeed than arguments that are conflicted at either end of the stack. -- dean -- Dean From Ray.Bellis@nominet.org.uk Tue Mar 23 14:38:42 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD57E3A6B0C for ; Tue, 23 Mar 2010 14:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.143 X-Spam-Level: X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7efhTQfGRgE for ; Tue, 23 Mar 2010 14:38:41 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 2AB033A6CA9 for ; Tue, 23 Mar 2010 14:38:40 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=RkryDxG0PEVo9IAirnP1uDuNILr785SzZAHIahHRbLdpr1XacUOuwMlI 3po11lv+gJjs+NF0igTSp8obOAo0gVFA94GZUxrdXDEMIJ80HGKRvdLhg TXwl7kkD6SyhzA7; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269380341; x=1300916341; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Why=20do=20we=20have=20a=20framework=20instead=20of =20discrete=20services?|Date:=20Tue,=2023=20Mar=202010=20 13:38:43=20-0800|Message-ID:=20|To:=20De an=20Willis=20|Cc:=20"E.164=20 To=20MetaData=20BOF=20discussion=20list"=20|MIME-Version:=201.0|In-Reply-To:=20<4BA932DE.1090609@so ftarmor.com>|References:=20<4BA9231A.1070506@softarmor.co m>=09=0D=0A=09<4BA92F82.3090903@softarmor.com>=09 =20<4BA932DE.1090609@softarmor.com>; bh=zrLDYVl65WL6CTh06J/o+qbn3lfCiGjIBPkXDW2FXDQ=; b=VC9ubaBU2YtRrcpi+oeEN2IfY4ajWkinIIyT9iUEKqWbvR5lN71Eoage siyA6yzqVDVThvmsaRAsvifM8PwBbQXIRgSXSyA27w6LJAgIvH3OCUQIM WPmjpa6w6oDR7E7; X-IronPort-AV: E=Sophos;i="4.51,297,1267401600"; d="scan'208";a="22827072" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 23 Mar 2010 21:38:44 +0000 In-Reply-To: <4BA932DE.1090609@softarmor.com> References: <4BA9231A.1070506@softarmor.com> <4BA92F82.3090903@softarmor.com> <4BA932DE.1090609@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 23 Mar 2010 13:38:43 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 23/03/2010 09:38:44 PM, Serialize complete at 23/03/2010 09:38:44 PM Content-Type: multipart/alternative; boundary="=_alternative 0076E6CE882576EF_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:38:42 -0000 This is a multipart message in MIME format. --=_alternative 0076E6CE882576EF_= Content-Type: text/plain; charset="US-ASCII" > Certainly when one is talking about IETF policy and IESG preference, > especially in the context of such a subjective topic as "The DNS", one > is operating above ISO Layer 7. Could perhaps these IESG and higher people who have these concerns come here and talk to us about them directly, ideally before the BOF? Ray --=_alternative 0076E6CE882576EF_= Content-Type: text/html; charset="US-ASCII"
> Certainly when one is talking about IETF policy and IESG preference,
> especially in the context of such a subjective topic as "The DNS", one
> is operating above ISO Layer 7.
Could perhaps these IESG and higher people who have these concerns come here and talk to us about them directly, ideally before the BOF?

Ray
--=_alternative 0076E6CE882576EF_=-- From dean.willis@softarmor.com Tue Mar 23 14:47:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0F93A6C45 for ; Tue, 23 Mar 2010 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.979 X-Spam-Level: X-Spam-Status: No, score=0.979 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znqb9UJIiXA0 for ; Tue, 23 Mar 2010 14:47:11 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 59ECA3A6CB3 for ; Tue, 23 Mar 2010 14:46:58 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2NLlFUS015729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 16:47:17 -0500 Message-ID: <4BA936E3.6030005@softarmor.com> Date: Tue, 23 Mar 2010 16:47:15 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: <4BA9231A.1070506@softarmor.com> <4BA92F82.3090903@softarmor.com> <4BA932DE.1090609@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:47:12 -0000 Ray.Bellis@nominet.org.uk wrote: > >> Certainly when one is talking about IETF policy and IESG preference, >> especially in the context of such a subjective topic as "The DNS", one >> is operating above ISO Layer 7. > > Could perhaps these IESG and higher people who have these concerns come > here and talk to us about them directly, ideally before the BOF? > Yes, that would be nice. I've taken to stalking them in their favorite habitats,: backs of rooms, hallways, wine bars, and dark alleys. -- dean From HKaplan@acmepacket.com Tue Mar 23 15:51:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5961D3A6B61 for ; Tue, 23 Mar 2010 15:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4SIvc4B7ktn for ; Tue, 23 Mar 2010 15:51:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6743E3A6A14 for ; Tue, 23 Mar 2010 15:51:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 23 Mar 2010 18:51:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 23 Mar 2010 18:51:46 -0400 From: Hadriel Kaplan To: Dean Willis , "PFAUTZ, PENN L (ATTCORP)" Date: Tue, 23 Mar 2010 18:51:44 -0400 Thread-Topic: [e2md] We need another acronym besides SPID for service provider ID Thread-Index: AcrKzsMw5vXBZ5B5Rv2NlvXCyRysrgAC/5GQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1C62@mail> References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> In-Reply-To: <4BA930A7.9080002@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 22:51:29 -0000 Oh great, that would be pronounced "SPiN". Everyone calls them "SPID" in the LNP and Enum market, afaict. -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Tuesday, March 23, 2010 5:21 PM > To: PFAUTZ, PENN L (ATTCORP) > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] We need another acronym besides SPID for service > provider ID >=20 > PFAUTZ, PENN L (ATTCORP) wrote: > > Two thoughts. > > 1. Do we really need to worry about this? As in the trademark issues, > > how likely is it that anyone will be confused given the different > > contexts. In recent ATIS PTSC contributions it's been SPID and, if > > anyone should be concerned, they should. >=20 > Well, it confused me. Richard said we needed a SPID, so I googled SPID > and got pointed at the ISDN reference, which I then recalled from my > ISDN days. Now, I may be a crufty old bird, but I'm not the only one in > the flock. >=20 > > 2. If it really is a problem, the i3 Forum has been using "SPN." (They > > like SP number for some reason). > > >=20 > I do like that better, actually. The Free Dictionary lists no major > collisions in telecom/network outside of Microsoft's "Service Principal > Name", which is a pretty similar functionality. >=20 > -- > dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From adam.uzelac@gmail.com Tue Mar 23 16:10:58 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A283A6B99 for ; Tue, 23 Mar 2010 16:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.132 X-Spam-Level: ** X-Spam-Status: No, score=2.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMs2INxpAO77 for ; Tue, 23 Mar 2010 16:10:57 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id D87713A6A60 for ; Tue, 23 Mar 2010 16:10:56 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so979351qwi.31 for ; Tue, 23 Mar 2010 16:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SUNTcys8tRjqRzoKlNo/3Bf5sEy5Xw3ooqhA90YHNoc=; b=GTlW6Ltxkz3991o1cLYqRvo7FADyX6YzlWH356GrHWbm1Cmrv/LJdTSawVWFh+cd7b QNDkH7keqmgRZujFhsn4V4qFZFO1uyp1VTuKSX1XYHOzV5iNCN5uXTaQn3YW7QQg+rpj YNmzf4B+Ws6Lt2WRYtpvUD2UxtO0FGsWV7pkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W1Kjk6ZtFLbUdTt2+vlfeNuehSrzA2okSpwx2I1avMd6JgANIrvQjfpVIEcMnFcObX ftQaMI1GwGWxZCoz6Ay3kGQ3wZ54UNXbmPY4nm/5nvG4ZnGm3Wg3mQq8mlqpnmSdUdCA wTm9LF1t5fn1lVlXoeBvvG1CpEumfKWD/fi30= MIME-Version: 1.0 Received: by 10.229.88.193 with SMTP id b1mr1594458qcm.27.1269385873286; Tue, 23 Mar 2010 16:11:13 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1C62@mail> References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1C62@mail> Date: Tue, 23 Mar 2010 16:11:13 -0700 Message-ID: <3d58c41e1003231611g4ac9e9c1p9708c1478741b3c@mail.gmail.com> From: Adam Uzelac To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0016363b797a0f664e04827feea8 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:10:59 -0000 --0016363b797a0f664e04827feea8 Content-Type: text/plain; charset=ISO-8859-1 As I sit here in mmusic and just read TCAP up on the SDP Negotiation slides, I really don't think anyone in the room starting thinking INAPTCAP. IMHO - I don't see the need for anything new here. Adam On Tue, Mar 23, 2010 at 3:51 PM, Hadriel Kaplan wrote: > > Oh great, that would be pronounced "SPiN". > Everyone calls them "SPID" in the LNP and Enum market, afaict. > > -hadriel > > > -----Original Message----- > > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > > Dean Willis > > Sent: Tuesday, March 23, 2010 5:21 PM > > To: PFAUTZ, PENN L (ATTCORP) > > Cc: E.164 To MetaData BOF discussion list > > Subject: Re: [e2md] We need another acronym besides SPID for service > > provider ID > > > > PFAUTZ, PENN L (ATTCORP) wrote: > > > Two thoughts. > > > 1. Do we really need to worry about this? As in the trademark issues, > > > how likely is it that anyone will be confused given the different > > > contexts. In recent ATIS PTSC contributions it's been SPID and, if > > > anyone should be concerned, they should. > > > > Well, it confused me. Richard said we needed a SPID, so I googled SPID > > and got pointed at the ISDN reference, which I then recalled from my > > ISDN days. Now, I may be a crufty old bird, but I'm not the only one in > > the flock. > > > > > 2. If it really is a problem, the i3 Forum has been using "SPN." (They > > > like SP number for some reason). > > > > > > > I do like that better, actually. The Free Dictionary lists no major > > collisions in telecom/network outside of Microsoft's "Service Principal > > Name", which is a pretty similar functionality. > > > > -- > > dean > > _______________________________________________ > > e2md mailing list > > e2md@ietf.org > > https://www.ietf.org/mailman/listinfo/e2md > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > --0016363b797a0f664e04827feea8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I sit here in mmusic and just read TCAP up on the SDP Negotiation=20 slides, I really don't think anyone in the room starting thinking=A0 INAP TCAP. = IMHO - I don't see the need for anything new here.

Adam

On Tue, Mar 23, 2010 at 3:51 PM, Had= riel Kaplan <HKaplan@acmepacket.com> wrote:

Oh great, that would be pronounced "SPiN".
Everyone calls them "SPID" in the LNP and Enum market, afaict.
-hadriel

> -----Original Message-----
> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of
> Dean Willis
> Sent: Tuesday, March 23, 2010 5:21 PM
> To: PFAUTZ, PENN L (ATTCORP)
> Cc: E.164 To MetaData BOF discussion list
> Subject: Re: [e2md] We need another acronym besides SPID for service > provider ID
>
> PFAUTZ, PENN L (ATTCORP) wrote= :
> > Two thoughts.
> > 1. Do we really need to worry about this? As in the trademark iss= ues,
> > how likely is it that anyone will be confused given the different=
> > contexts. In recent ATIS PTSC contributions it's been SPID an= d, if
> > anyone should be concerned, they should.
>
> Well, it confused me. Richard said we needed a SPID, so I googled SPID=
> and got pointed at the ISDN reference, which I then recalled from my > ISDN days. Now, I may be a crufty old bird, but I'm not the only o= ne in
> the flock.
>
> > 2. If it really is a problem, the i3 Forum has been using "S= PN." (They
> > like SP number for some reason).
> >
>
> I do like that better, actually. The Free Dictionary lists no major > collisions in telecom/network outside of Microsoft's "Service= Principal
> Name", which is a pretty similar functionality.
>
> --
> dean
> _______________________________________________
> e2md mailing list
> e2md@ietf.org
> https://www.ietf.org/mailman/listinfo/e2md
_______________________________________________
e2md mailing list
e2md@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/e2md

--0016363b797a0f664e04827feea8-- From richard@shockey.us Tue Mar 23 18:13:47 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928233A680D for ; Tue, 23 Mar 2010 18:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.174 X-Spam-Level: * X-Spam-Status: No, score=1.174 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG9HaS1zGy28 for ; Tue, 23 Mar 2010 18:13:46 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 5FC363A67AD for ; Tue, 23 Mar 2010 18:13:46 -0700 (PDT) Received: (qmail 2673 invoked by uid 0); 24 Mar 2010 01:14:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 24 Mar 2010 01:14:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=V6r6/G5Z0qBEZFVOta0TrKxohfy5v8qU/9IEt3oKgdLgJi3TSeeroPadLrjGksc1dZwlZ1QVTDnJZAacX9fcBboAwcBRjUZ/CPuYaSYRUcpDnMXGpeT8EDF5bWBWJleo; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuFAc-0003wv-Or; Tue, 23 Mar 2010 19:14:06 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'PFAUTZ, PENN L \(ATTCORP\)'" References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> In-Reply-To: <4BA930A7.9080002@softarmor.com> Date: Tue, 23 Mar 2010 21:14:02 -0400 Message-ID: <000c01cacaef$4ad66700$e0833500$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKzrfY3vyZ+ArbQ0yHlmcJB27t5AAIEqKA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 01:13:47 -0000 In the US its SPID but we would also have to reserve the ITU type currently under development as well Service Provider Network Identifier (SPN) -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, March 23, 2010 5:21 PM To: PFAUTZ, PENN L (ATTCORP) Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] We need another acronym besides SPID for service provider ID PFAUTZ, PENN L (ATTCORP) wrote: > Two thoughts. > 1. Do we really need to worry about this? As in the trademark issues, > how likely is it that anyone will be confused given the different > contexts. In recent ATIS PTSC contributions it's been SPID and, if > anyone should be concerned, they should. Well, it confused me. Richard said we needed a SPID, so I googled SPID and got pointed at the ISDN reference, which I then recalled from my ISDN days. Now, I may be a crufty old bird, but I'm not the only one in the flock. > 2. If it really is a problem, the i3 Forum has been using "SPN." (They > like SP number for some reason). > I do like that better, actually. The Free Dictionary lists no major collisions in telecom/network outside of Microsoft's "Service Principal Name", which is a pretty similar functionality. -- dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From trutkowski@netmagic.com Tue Mar 23 18:43:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0873A6A22 for ; Tue, 23 Mar 2010 18:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxH4J89uhlYC for ; Tue, 23 Mar 2010 18:43:31 -0700 (PDT) Received: from vms173019pub.verizon.net (vms173019pub.verizon.net [206.46.173.19]) by core3.amsl.com (Postfix) with ESMTP id 101133A6876 for ; Tue, 23 Mar 2010 18:43:30 -0700 (PDT) Received: from [192.168.0.173] ([unknown] [173.72.150.224]) by vms173019.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KZR00IPJJGFUB74@vms173019.mailsrvcs.net> for e2md@ietf.org; Tue, 23 Mar 2010 20:43:31 -0500 (CDT) Message-id: <4BA96E3F.6010406@netmagic.com> Date: Tue, 23 Mar 2010 21:43:27 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-version: 1.0 To: Richard Shockey References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us> In-reply-to: <000c01cacaef$4ad66700$e0833500$@us> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 01:43:31 -0000 On 3/23/2010 9:14 PM, Richard Shockey wrote: > In the US its SPID but we would also have to reserve the ITU type currently > under development as well Service Provider Network Identifier (SPN) > > What ITU-T type currently under development? The ITU-T's IdM group recommended that the IETF's Enterprise Numbers be used for a SPID, and that consideration be given to binding them to EVcerts. --tony From richard@shockey.us Tue Mar 23 18:58:59 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294CD3A67F0 for ; Tue, 23 Mar 2010 18:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.169 X-Spam-Level: * X-Spam-Status: No, score=1.169 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh6uh5LoKbKc for ; Tue, 23 Mar 2010 18:58:58 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 415DF3A63D3 for ; Tue, 23 Mar 2010 18:58:58 -0700 (PDT) Received: (qmail 26047 invoked by uid 0); 24 Mar 2010 01:59:18 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 24 Mar 2010 01:59:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=AdYvhwlwcVAlsTuJxx2rXNPm5PUoJF/eGgLBRImHI+Byo1jrINKPRVEkqNnYCrQ2cqh18jQpveZT5lQfPjgF4qVG2zjRD7Ew2zDJpi+AI5t66cMLNzm9MPq+DDT9uQiG; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuFsM-0007sX-LN; Tue, 23 Mar 2010 19:59:18 -0600 From: "Richard Shockey" To: References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us> <4BA96E3F.6010406@netmagic.com> In-Reply-To: <4BA96E3F.6010406@netmagic.com> Date: Tue, 23 Mar 2010 21:59:14 -0400 Message-ID: <000601cacaf5$9b3c0280$d1b40780$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrK825OptV8mgMiTISukrB0MCNLTAAAQPsQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 01:58:59 -0000 It's my understanding that SG2 has a separate task underway that Gary Richenaker is leading on the Global SPID. The IETF DRINKS WG received a formal liaison from ITU-T requesting that the DRINKS protocol accommodate such as identifier. It is my working assumption that E2MD should explicit accommodate this request as well. https://datatracker.ietf.org/liaison/518/ -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com] Sent: Tuesday, March 23, 2010 9:43 PM To: Richard Shockey Cc: 'Dean Willis'; 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] We need another acronym besides SPID for service provider ID On 3/23/2010 9:14 PM, Richard Shockey wrote: > In the US its SPID but we would also have to reserve the ITU type currently > under development as well Service Provider Network Identifier (SPN) > > What ITU-T type currently under development? The ITU-T's IdM group recommended that the IETF's Enterprise Numbers be used for a SPID, and that consideration be given to binding them to EVcerts. --tony From trutkowski@netmagic.com Tue Mar 23 19:08:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D223A6952 for ; Tue, 23 Mar 2010 19:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWEfWbnFYqBW for ; Tue, 23 Mar 2010 19:08:54 -0700 (PDT) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by core3.amsl.com (Postfix) with ESMTP id 8BB8C3A68D0 for ; Tue, 23 Mar 2010 19:08:49 -0700 (PDT) Received: from [192.168.0.173] ([unknown] [173.72.150.224]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KZR0066BKN2J2D2@vms173011.mailsrvcs.net> for e2md@ietf.org; Tue, 23 Mar 2010 21:09:07 -0500 (CDT) Message-id: <4BA9743E.7080607@netmagic.com> Date: Tue, 23 Mar 2010 22:09:02 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-version: 1.0 To: Richard Shockey References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us> <4BA96E3F.6010406@netmagic.com> <000601cacaf5$9b3c0280$d1b40780$@us> In-reply-to: <000601cacaf5$9b3c0280$d1b40780$@us> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 02:08:55 -0000 Hi Richard, > It's my understanding that SG2 has a separate task underway that Gary > Richenaker is leading on the Global SPID. The IETF DRINKS WG received a > formal liaison from ITU-T requesting that the DRINKS protocol accommodate > such as identifier. > Actually NeuStar made the proposal out of the blue. Gary as you know works for NeuStar. The proposal had many significant flaws and received no apparent support at the meeting (or anywhere else). Other ITU-T Study Groups had suggested that IETF Enterprise Numbers be used as they were the predominant SPID in use, but needed a better trust mechanism. A SG2 correspondence group was formed to further consider it, but thus far there has been no activity. I think you can consider the effort dead. --tony From lconroy@insensate.co.uk Wed Mar 24 02:41:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC5B3A6B1B for ; Wed, 24 Mar 2010 02:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUeGKiza3pIm for ; Wed, 24 Mar 2010 02:41:27 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id D3E853A6B05 for ; Wed, 24 Mar 2010 02:39:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [127.0.0.3]) by insensate.co.uk (Postfix) with ESMTP id 4A3F31195DF; Wed, 24 Mar 2010 09:40:01 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Wed, 24 Mar 2010 09:40:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BA9231A.1070506@softarmor.com> <4BA92F82.3090903@softarmor.com> To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 09:41:28 -0000 Hi folks, for what it's worth, I had thought that the goals were pretty = straightforward, the tools to use were pretty straightforward/obvious. I = had also thought that access to the current repositories for sensitive = data is very tightly access controlled (qua certain IAB members' = experience). The wide-ranging discussion on AAA seems to be entirely unrelated to the = ground. How does one expect IMS to work? In practice, it's a constrained access = approach. With the wide range of different extra data stuck to SIP messages, it = has to be. As Jim said, there *ARE* potential ways of dealing with sensitive data at scale without Web 2.0, as it doesn't change often and the number of unique accessors for this information is tightly limited. There is also tight network/server access control that is really likely to be in place=20= -- I sure don't see Hadriel's systems plugged into the Interweb = directly. However ... Inheriting ENUM's badness??? C'mon. Do we really have stalking horses discussing artistic opinion. Coooool. If some one has a point to make, then please can THEY make it, directly. I cannot see what is wrong with the framework Bernie has been working on for ages now, and have not heard of any direct statement on it. I'm still waiting. +1 for reuse of ENUM as far as possible. +1 for the framework approach, so everyone knows how to develop a new = case, +1 for a narrow approach to current use cases. +1 for flagging security concerns (or not, in some countries) [+1 for continuing the current flags for security we already have in = ENUM. these are clearly spelt out in Bernie's current work, so let's keep = them] -10 for having separate DDDS applications for each application. That sure isn't what S/NAPTR does either, and that just sailed through the IESG. all the best, Lawrence For the rest, we have=20 On 23 Mar 2010, at 21:24, Bernie Hoeneisen wrote: > On Tue, 23 Mar 2010, Dean Willis wrote: >=20 >> I'm afraid that almost all of those are seen as arguments by the AD = who >> asked me the question for OPPOSING a framework approach, not creating >> one. Some people really don't want it to be so easy to create new >> metadata types, and see "having to BOF and form a working group" as a >> very reasonable threshold for initiating the work. And inheriting the >> badness of ENUM (along with its goodness) might not be a desirable = goal. >=20 > Question for clarification: > Are we here in a Layer 7- or Layer 9+ discussion??? >=20 > cheers, > Bernie >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Wed Mar 24 09:18:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222A83A6BE4 for ; Wed, 24 Mar 2010 09:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.161 X-Spam-Level: * X-Spam-Status: No, score=1.161 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJcLEDsvmQQI for ; Wed, 24 Mar 2010 09:18:01 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 0CFBF3A6BDD for ; Wed, 24 Mar 2010 09:17:35 -0700 (PDT) Received: (qmail 16161 invoked by uid 0); 24 Mar 2010 16:17:55 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 24 Mar 2010 16:17:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=RxCWLU2arddbShym6OMkIQufKNXs0Wpp7dG14m8enCYViFaoOj8OfV20W3nqy/eys7kqi8HvPkm4zELYTFiscPecwYOC4KBFHk2EJ87F2+z7UhKDr2TVp3G72oGQYgLT; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuTHH-0001vK-7u; Wed, 24 Mar 2010 10:17:55 -0600 From: "Richard Shockey" To: References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us> <4BA96E3F.6010406@netmagic.com> <000601cacaf5$9b3c0280$d1b40780$@us> <4BA9743E.7080607@netmagic.com> In-Reply-To: <4BA9743E.7080607@netmagic.com> Date: Wed, 24 Mar 2010 12:17:51 -0400 Message-ID: <00a401cacb6d$8de10a90$a9a31fb0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrK9wQ4yMtkfsH8R0uUFAR2r6SXNQAdl3Ag Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:18:03 -0000 Well from our perspective either approach would work fine so long as the appropriate IETU SG's can provide us clarity when we get around to defining the field. Your help in this matter would be much appreciated. -----Original Message----- From: Tony Rutkowski [mailto:trutkowski@netmagic.com] Sent: Tuesday, March 23, 2010 10:09 PM To: Richard Shockey Cc: 'Dean Willis'; 'PFAUTZ, PENN L (ATTCORP)'; 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] We need another acronym besides SPID for service provider ID Hi Richard, > It's my understanding that SG2 has a separate task underway that Gary > Richenaker is leading on the Global SPID. The IETF DRINKS WG received a > formal liaison from ITU-T requesting that the DRINKS protocol accommodate > such as identifier. > Actually NeuStar made the proposal out of the blue. Gary as you know works for NeuStar. The proposal had many significant flaws and received no apparent support at the meeting (or anywhere else). Other ITU-T Study Groups had suggested that IETF Enterprise Numbers be used as they were the predominant SPID in use, but needed a better trust mechanism. A SG2 correspondence group was formed to further consider it, but thus far there has been no activity. I think you can consider the effort dead. --tony From richard@shockey.us Wed Mar 24 09:35:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA2F3A6838 for ; Wed, 24 Mar 2010 09:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.158 X-Spam-Level: * X-Spam-Status: No, score=1.158 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPQJwgo+Dmho for ; Wed, 24 Mar 2010 09:35:29 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 00A3B3A6920 for ; Wed, 24 Mar 2010 09:35:23 -0700 (PDT) Received: (qmail 1189 invoked by uid 0); 24 Mar 2010 15:35:43 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 24 Mar 2010 15:35:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=cNvlH+MWOqbmBXdk4A7+xy692bZSX6Q3emfHI7Qsx8ZG21eXC3BTv3VDZzi7q7Gy0cwiJSGfNnqDZvILG7mqH2efBw2jq7B7vcyv0VdgPSqdln6+eK6j8YChiJ0mPRGi; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuTYV-0002fT-L3; Wed, 24 Mar 2010 10:35:43 -0600 From: "Richard Shockey" To: "'Lawrence Conroy'" , "'Bernie Hoeneisen'" References: <4BA9231A.1070506@softarmor.com> <4BA92F82.3090903@softarmor.com> In-Reply-To: Date: Wed, 24 Mar 2010 12:35:40 -0400 Message-ID: <00c201cacb70$0ab3c650$201b52f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrLNjrhz/6YO8pwR3KPfGbKYNXd0gAOasfQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] Why do we have a framework instead of discrete services? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:35:30 -0000 Exactly ... these ancillary issues have only confused people making chartering more difficult. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Lawrence Conroy Sent: Wednesday, March 24, 2010 5:40 AM To: Bernie Hoeneisen Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Why do we have a framework instead of discrete services? Hi folks, for what it's worth, I had thought that the goals were pretty straightforward, the tools to use were pretty straightforward/obvious. I had also thought that access to the current repositories for sensitive data is very tightly access controlled (qua certain IAB members' experience). The wide-ranging discussion on AAA seems to be entirely unrelated to the ground. How does one expect IMS to work? In practice, it's a constrained access approach. With the wide range of different extra data stuck to SIP messages, it has to be. As Jim said, there *ARE* potential ways of dealing with sensitive data at scale without Web 2.0, as it doesn't change often and the number of unique accessors for this information is tightly limited. There is also tight network/server access control that is really likely to be in place -- I sure don't see Hadriel's systems plugged into the Interweb directly. However ... Inheriting ENUM's badness??? C'mon. Do we really have stalking horses discussing artistic opinion. Coooool. If some one has a point to make, then please can THEY make it, directly. I cannot see what is wrong with the framework Bernie has been working on for ages now, and have not heard of any direct statement on it. I'm still waiting. +1 for reuse of ENUM as far as possible. +1 for the framework approach, so everyone knows how to develop a new case, +1 for a narrow approach to current use cases. +1 for flagging security concerns (or not, in some countries) [+1 for continuing the current flags for security we already have in ENUM. these are clearly spelt out in Bernie's current work, so let's keep them] -10 for having separate DDDS applications for each application. That sure isn't what S/NAPTR does either, and that just sailed through the IESG. all the best, Lawrence For the rest, we have On 23 Mar 2010, at 21:24, Bernie Hoeneisen wrote: > On Tue, 23 Mar 2010, Dean Willis wrote: > >> I'm afraid that almost all of those are seen as arguments by the AD who >> asked me the question for OPPOSING a framework approach, not creating >> one. Some people really don't want it to be so easy to create new >> metadata types, and see "having to BOF and form a working group" as a >> very reasonable threshold for initiating the work. And inheriting the >> badness of ENUM (along with its goodness) might not be a desirable goal. > > Question for clarification: > Are we here in a Layer 7- or Layer 9+ discussion??? > > cheers, > Bernie > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Wed Mar 24 09:47:56 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1064D3A6C1C for ; Wed, 24 Mar 2010 09:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.919 X-Spam-Level: X-Spam-Status: No, score=0.919 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etIxo4zDKt8k for ; Wed, 24 Mar 2010 09:47:55 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4CC043A6C0F for ; Wed, 24 Mar 2010 09:47:55 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OGmEUP024056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Mar 2010 11:48:15 -0500 Message-ID: <4BAA4248.2050601@softarmor.com> Date: Wed, 24 Mar 2010 11:48:08 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:47:56 -0000 Ray, Bernie, Brian Rosen, and I sat down with Jon Peterson yesterday and talked about things. Here's a point he made that we may wish to consider. The usage scenario for CNAM is entirely different from that for our other current use cases. It's something that one generally queries when receiving a call, not when placing a call. The data returned has absolutely nothing to do with the routing/numbering topology. It's not "metadata" about the enum tree, it's "data" related to the phone number. Putting it in a NAPTR record is also pointless: not only is NAPTR a clumsy format for calling-names, one generally does NOT want or need the CNAM to come back in the other cases where one might query for all NAPTR records associated with a given E.164, so having it in a NAPTR simply creates extra network traffic and processor load while achieving no benefit. Consequently, one approach for CNAM would be to define another resource record type that would fit the problem space better. Would this be a viable approach? -- Dean From trutkowski@netmagic.com Wed Mar 24 09:49:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C855A3A6920 for ; Wed, 24 Mar 2010 09:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.007 X-Spam-Level: * X-Spam-Status: No, score=1.007 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBDU5I6ss1-2 for ; Wed, 24 Mar 2010 09:49:28 -0700 (PDT) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by core3.amsl.com (Postfix) with ESMTP id 8CAD23A6BCF for ; Wed, 24 Mar 2010 09:49:26 -0700 (PDT) Received: from [192.168.0.173] ([unknown] [173.72.150.224]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KZS00ECYPEINVCD@vms173011.mailsrvcs.net> for e2md@ietf.org; Wed, 24 Mar 2010 11:49:37 -0500 (CDT) Message-id: <4BAA429A.1010300@netmagic.com> Date: Wed, 24 Mar 2010 12:49:30 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-version: 1.0 To: Richard Shockey References: <4BA92A6B.2010309@softarmor.com> <35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com> <4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us> <4BA96E3F.6010406@netmagic.com> <000601cacaf5$9b3c0280$d1b40780$@us> <4BA9743E.7080607@netmagic.com> <00a401cacb6d$8de10a90$a9a31fb0$@us> In-reply-to: <00a401cacb6d$8de10a90$a9a31fb0$@us> Content-type: multipart/mixed; boundary=------------030508010804000907040106 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] We need another acronym besides SPID for service provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:49:29 -0000 This is a multi-part message in MIME format. --------------030508010804000907040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/24/2010 12:17 PM, Richard Shockey wrote: > Well from our perspective either approach would work fine so long as the > appropriate IETU SG's can provide us clarity when we get around to defining > the field. Your help in this matter would be much appreciated. > Sure. There are three Study Groups in play. That doesn't help on the political front. SG13 (Future Networks/NGNs) has specified a SPID requirement but not come up with anything definitive. SG17 (Security/IdM/OIDs) has settled on provider OIDs, including especially IANA's well known and very significantly used implementations under the name Enterprise Numbers. OIDs are IMHO the logical way to go because they have been used for this purpose for the past 25 years for all kinds of networks/apps which have grown dramatically in the past few years and there are no layer 7+ problems. At last count there were something close to 40k of them parceled out. Enterprise OIDs are also being bound to EVcerts to enhance the trust, and if the OID Resolver standard gets adopted next month, the trust would be further enhanced via an ENUM-like query process. So this is all very synergistic with e2md. You could query, for example, the Enterprise Number to get ancillary provider identifiers and information. SG2 is layer 8+ territory. The new proposed SPID seems like a non-starter for the reasons described in the attached slides. Bottom line: Use enterprise OIDs --tony --------------030508010804000907040106 Content-Type: application/pdf; name="NeuStar_SPN_proposal.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="NeuStar_SPN_proposal.pdf" JVBERi0xLjQNJeLjz9MNCjIwIDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDE0NDI0OS9PIDIy L0UgOTM0MTUvTiAzL1QgMTQzODAyL0ggWyA4MzYgMjYwXT4+DWVuZG9iag0gICAgICAgICAg ICAgICAgDQp4cmVmDQoyMCAyNw0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAxMDk2IDAw MDAwIG4NCjAwMDAwMDExNzYgMDAwMDAgbg0KMDAwMDAwMTMwNiAwMDAwMCBuDQowMDAwMDAx NDYwIDAwMDAwIG4NCjAwMDAwMDE4MjcgMDAwMDAgbg0KMDAwMDAwMjMxNyAwMDAwMCBuDQow MDAwMDAyMzUxIDAwMDAwIG4NCjAwMDAwMDI1NzIgMDAwMDAgbg0KMDAwMDAwMjgxOCAwMDAw MCBuDQowMDAwMDAyODk0IDAwMDAwIG4NCjAwMDAwMDQxNDcgMDAwMDAgbg0KMDAwMDAwNDI3 NiAwMDAwMCBuDQowMDAwMDA0NTcyIDAwMDAwIG4NCjAwMDAwMDQ4OTkgMDAwMDAgbg0KMDAw MDAwNTAzMyAwMDAwMCBuDQowMDAwMDA3NzAyIDAwMDAwIG4NCjAwMDAwMjU3NzQgMDAwMDAg bg0KMDAwMDAyNjAxOSAwMDAwMCBuDQowMDAwMDI2MjA4IDAwMDAwIG4NCjAwMDAwNTQ4Njgg MDAwMDAgbg0KMDAwMDA3MjA2NiAwMDAwMCBuDQowMDAwMDcyMzE3IDAwMDAwIG4NCjAwMDAw NzI1MDMgMDAwMDAgbg0KMDAwMDA3Mjc4OCAwMDAwMCBuDQowMDAwMDkzMTYzIDAwMDAwIG4N CjAwMDAwMDA4MzYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA0Ny9QcmV2IDE0Mzc5MS9S b290IDIxIDAgUi9JbmZvIDE5IDAgUi9JRFs8Q0VCRkEwNkFFNkYwMUFEODFENUU2RUQ0NDc3 MUQ5MkU+PEI1MjdDNDIwREQyQUFFNDM4MUFGQzZCRTBGQTYxNzk2Pl0+Pg0Kc3RhcnR4cmVm DQowDQolJUVPRg0KICAgICAgICAgICAgDQo0NiAwIG9iajw8L0xlbmd0aCAxNzMvRmlsdGVy L0ZsYXRlRGVjb2RlL0kgMTk2L0wgMTgwL1MgMTAzPj5zdHJlYW0NCnjaYmBgYAaiKQysDAw8 7xgEGRBAkIEFKMrCwLGyYe2GZcUODAz/L8AlWTSmTOb5cTrmh0ur0KTEuetqlEA6wjo6GkCy HB0dIArIg+oEAl4GJvkeIC0BxFJgESUGfoYDjA+4MmSAmvQOZDFocbYx1nAYCAXwNE16bM1w mdF8v5dEAu8EYQa757sabjGcYLaAWs/PwKTIBKRB2BqIhRmY9LcCaUYg/gYQYAB+nCoMDQpl bmRzdHJlYW0NZW5kb2JqDTIxIDAgb2JqPDwvTWV0YWRhdGEgMTggMCBSL1BhZ2VzIDE3IDAg Ui9UeXBlL0NhdGFsb2cvUGFnZUxhYmVscyAxNSAwIFI+Pg1lbmRvYmoNMjIgMCBvYmo8PC9D cm9wQm94WzAgMCA1OTUgODQyXS9QYXJlbnQgMTcgMCBSL0NvbnRlbnRzIDMwIDAgUi9Sb3Rh dGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4NDJdL1Jlc291cmNlcyAyMyAwIFIvVHlwZS9QYWdl Pj4NZW5kb2JqDTIzIDAgb2JqPDwvQ29sb3JTcGFjZTw8L0NzNiAyNiAwIFI+Pi9Gb250PDwv VFQyIDI0IDAgUi9UVDMgMzEgMCBSL1RUNCAyNSAwIFIvVFQ1IDM0IDAgUi9UVDYgMzMgMCBS Pj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAyOSAwIFI+Pj4+DWVuZG9i ag0yNCAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMjcgMCBSL0xh c3RDaGFyIDE1MC9XaWR0aHNbMjc4IDAgNTU2IDU1NiAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2Njcg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDM1MCA1NTZdL0Jhc2VGb250L0FyaWFsTVQvRmlyc3RDaGFyIDQ2 L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMjUgMCBvYmo8 PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDI4IDAgUi9MYXN0Q2hhciAxNTAv V2lkdGhzWzUwNyAwIDAgMCAzMDMgMzAzIDAgMCAyNTAgMCAyNTIgMzg2IDUwNyA1MDcgNTA3 IDUwNyAwIDUwNyAwIDAgMCA1MDcgMjY4IDAgMCAwIDAgMCAwIDU3OSA1NDQgNTMzIDYxNSAw IDAgNjMxIDAgMjUyIDAgMCAwIDg1NSA2NDYgMCA1MTcgMCA1NDMgNDU5IDQ4NyA2NDIgNTY3 IDAgMCAwIDAgMCAwIDAgMCAwIDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAzMDUgNDcxIDUyNSAy MjkgMjM5IDQ1NSAyMjkgNzk5IDUyNSA1MjcgNTI1IDUyNSAzNDkgMzkxIDMzNSA1MjUgNDUy IDcxNSA0MzMgNDUzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDI1MCAwIDAgMCA0OThdL0Jhc2VGb250L0tOQVBIQytDYWxpYnJpL0ZpcnN0Q2hh ciAzNi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTI2IDAg b2JqWy9JQ0NCYXNlZCAzNSAwIFJdDWVuZG9iag0yNyAwIG9iajw8L1N0ZW1WIDg4L0ZvbnRO YW1lL0FyaWFsTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDMy L0Rlc2NlbnQgLTIxMS9Gb250QkJveFstNjY1IC0zMjUgMjAwMCAxMDA2XS9Bc2NlbnQgOTA1 L0ZvbnRGYW1pbHkoQXJpYWwpL0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250 RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTI4IDAgb2JqPDwvU3RlbVYgODAv Rm9udE5hbWUvS05BUEhDK0NhbGlicmkvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRGaWxlMiAz OSAwIFIvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjUwL0ZvbnRCQm94Wy01 MDMgLTMwNyAxMjQwIDk2NF0vQXNjZW50IDc1MC9Gb250RmFtaWx5KENhbGlicmkpL0NhcEhl aWdodCA2MjUvWEhlaWdodCA0NjgvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAw Pj4NZW5kb2JqDTI5IDAgb2JqPDwvT1BNIDEvT1AgZmFsc2Uvb3AgZmFsc2UvVHlwZS9FeHRH U3RhdGUvU0EgZmFsc2UvU00gMC4wMj4+DWVuZG9iag0zMCAwIG9iajw8L0xlbmd0aCAxMTgz L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIicRXy24bNxTdz1dwySkihm8Oi6KLpkXQ Loy0niYLIwvFHjsqLI2jR4L+SL63d8h5kJwZSW7sFoIgQCTv49xzDy8/ZQytUGYlsQXSjFDG 0EIbopDhFG2rjBsi+5V19u47tMlevtppdL1DzH121/DP60uG7nbx7tDMbfZ7v+mnMntZlhyO lrcZRaxAC/hSpDXRyDBOBKMKleveD3Wfxs+CEkqpRuU1HCy/ZPgtuMrLv7JfyuyTT4VpHsQQ 5RJl2eYy5BCtprG3xjm3c0DFfkfW4+U581QSCcBISoRgiCuiNNKWiGbfO7DnoZMddLCPcrTw PxRxyYnqjnsIPWCyAQyXH6sWqtQhp5bo3iETjHD+KJfegHfpPLLG4xW+qA6X+xxKavBym78v f5vyLqQlxnbeBexmj/PuDYy9P2xzpojF9UO9W94794IYDctAnp8dNoy5vXhfN9BAcYxWwyql xq965BhRBTPhsj/8a/nnDLDaSMJUn1pD8Mck5o8PldTaF/L7kTtr5kgfU3bEy3j5OO17XgrC i+fhpTckTrGNEtPCQhsTP4At8WMkA23IPbNdyP8ds733ntnO+/Myu4NvzpS0jIjW1Dxe3xyx gtpwMxQ5brBTQSohiVDPH6QUvZuJPj8ZJXSbfv4oNdW9mzm5ORKlhp62rItSGD4ZZa9QPsqn V6gjERrKiLbNdR7gOPhcWNA0JmA6IMxamaruapP77Z1agCbIVtpjVQjSgPZn1u/By/S8NLbw azNHhQzFX7gwNof97mN1fx9PIULPT1R2YqQKBNkem6EcmlyiBW9CEco6YTWacNaphIJSwx2W /Damh6iv8BtQEE1kqCADFAIOnQSSmeCm5FBXZ/e2zhccoMTbxCYUUZ8ujpqtzfHK8PDWBiK7 ylRfYiuMGNFtPBZEl5jDq83rj5wVhOMqhzsMX+cFYbjOKV6vq83NMrewtF/VmyRnQ/j/CuNi yKDTttCSUGYSjYHGUswO0zHDRzSOlydoHGrLQOiiICIldCfPV3i93CzvAHvr6lBgAD9ngAje JygpuOrOqDSLKu37ebm5SXE6oxlixNtbernbre42LsiGNWmQEgaLc+jIR3TE9W3aH8VZpkJL bZCv7+sPIAAL8AO4Xr652L0YgcnoNFECrYbuEIVqtJqnQn25P9z8HcfLCcjcGfGGoKo2Xjf6 aFwfHpI44U4J9dkPHs7wlHEZusc8xVP1KZ+oyhX+2oAnicKvgJQG167cEu+3qw+HCVFQpDBn 2g5GE2FfpLTk+hEM95DoFsNqU31uhlcNQrtoftKaw3zEpgkViAPMDHB5+2ZlyLqXJKRukjFH j9pcShhe59ocM+0fWzymNL7wfxeFGcMDTwLbLEtCVbjqb4L9Kn0wSWvn7udY80bCFi/PPJja TR00zJJCPyE2wVNJzRloHknKzA6p3x4hp6p/m/jaBGHNn+KsD8tf1n5irD+39FYdvemM6Dxp Dgr82BHKHZuGAXZ0EPhTsATdwBMEFDWeM7uuqvxfJDD2LmRBZEiOEc2nj2nevGV1f8z6Oeku jkppM3fpx20z7o1oOe2NfwQYADXMSd4KDQplbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2JqPDwv U3VidHlwZS9UeXBlMC9EZXNjZW5kYW50Rm9udHNbMzggMCBSXS9CYXNlRm9udC9LTkFQRkMr Q2FsaWJyaS9Ub1VuaWNvZGUgMzIgMCBSL0VuY29kaW5nL0lkZW50aXR5LUgvVHlwZS9Gb250 Pj4NZW5kb2JqDTMyIDAgb2JqPDwvTGVuZ3RoIDIyNy9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0 cmVhbQ0KSIlUUL1uxiAM3HkKj606QEilLhFS9XXJ0B81aXc+cFKkBpBDhrx9gUapOmB0Z599 Nr/0T713CfgbBTNggsl5S7iGjQzCFWfnoZFgnUkHqtEsOgLP4mFfEy69nwJ0HePvObkm2uFm HNs7cQv8lSyS83Nm7uXHZ2aGLcZvXNAnEKAUWJwYvzzr+KIXBF6Ff+S4RwRZcXPMDhbXqA2S 9jNCJ4RoVf7aB6kAvf2fZ/JXdZ3MlyZ2VotHodgh6qRoMsrao6p0KRuersxGlA3XM1RbxZDz eF4qhlhml8d+BBgAGEptKgoNCmVuZHN0cmVhbQ1lbmRvYmoNMzMgMCBvYmo8PC9TdWJ0eXBl L1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDQ1IDAgUi9MYXN0Q2hhciAxMTgvV2lkdGhzWzUw NyA1MDcgNTA3IDAgMCAwIDUwNyAwIDAgNTA3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCA2NTkgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA1MDMgMCA0NzQgMCAyNDYgMCAwIDAgODEzIDUzNyA1MzggMCAwIDAgMCAzNDcg MCA0NzNdL0Jhc2VGb250L0tOQVBKRCtDYWxpYnJpLUJvbGQvRmlyc3RDaGFyIDQ4L0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMzQgMCBvYmo8PC9TdWJ0 eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250c1s0MiAwIFJdL0Jhc2VGb250L0tOQVBKQytDYWxp YnJpLUJvbGQvVG9Vbmljb2RlIDQzIDAgUi9FbmNvZGluZy9JZGVudGl0eS1IL1R5cGUvRm9u dD4+DWVuZG9iag0zNSAwIG9iajw8L0xlbmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9O IDMvQWx0ZXJuYXRlL0RldmljZVJHQj4+c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuA sAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbX jp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIR ADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM 9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4 X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1a VW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHBQn8f0TuF +q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+Hb74zn34 pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo26rFanUyu xIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68Br9gH sC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0 WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsY A7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEs qAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6B U+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelG BpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbg RQgjSAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZ EolkRfIiRZDSSTKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAo rpQwSjpFQWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh 2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVT mLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuX vYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMe aJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+ tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlpC9t62mbZNtt+YHvBdtbO 3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2hJ3GZhxtHZMcjY47 HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252Pev6zE3glu+2 ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7BXmqvrV6X vAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8tEUeULOoQ HRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhLSEnI eyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJ SCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdN xHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPq mapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3Z T3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8 XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIV A4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0 R7UcbaX2dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V5 9Yca2A3ahguNno1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2 yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osev Z7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvO DQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf +qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr 6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4 WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7F S8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/S wdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4Dbg veFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTv QO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+ S/7c/23//wIMAPeE8/sKDQplbmRzdHJlYW0NZW5kb2JqDTM2IDAgb2JqPDwvTGVuZ3RoIDE3 OTg3L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDUyODkyPj5zdHJlYW0NCkiJ1JZ5ONTf HsfPrBjGHmLUTJbI0ncGMbayVWRf0i31wzCMbSYmS/w0M9kqS4ts9YtGhaxFTfcilIpI8gvF T5QWbRRSWrjfUd3rPs/v9/TXvT33nOf7nOfz+Zzz+X6ec8779f0CBABAAnAACqyz9bDf8Clm Wh32dAKgkubisZoy+0TQDwDBE/b50qLZxJpjrT2wXQcAhkBnBYXPzDhJAEDqBkBMOSgsjp74 BBsNwIEwABBpwYF+AU815iwB6AqA168Jhh34SllbAFa9gm314HB2rLhEZTMAOtIAmDuEMWl+ QMH0MQDp07CdHu4XyyLZoHLh9fAaQIzwCw8M5CjsBKCdAwC6hRUZyAqtRs4BEOQDp4NzAMRC F45AJQoe5cFCUwmFeCpBWLFVKRtT3uMRIsginsoW2OWJRCDI4pAYFqMjiUIqYwDkh8XpYBFo BM8YiUAXeUBukO4iD4G/jEMA5gvdBfiDKMAEYSAQsOHHUtgh0qJkaPmVIsUuJlN6+55bI5R2 vtw/8NymvruIp7AK4qFlIR7yYxEKiUAipUALOGBuniZzx3KG9mp4HYT/V6UINFwTi6wDaWNR XmhxuRU2TFZcJCMomE3UomkTyVSqMdGJQYtkRjHpbKINM5KlT14GEb5OXvKfEWakH5vBjCCT oOXCOEpO6d9xdyaTTbTaxQ5mRjLYcdAyRTzVGCKTIcgYgttWRTwFIlMMyN/Mn1ARD7Fi8bYg MADFQ0gB2I9D8hAIUIZsbGE9NZt0VtEqzI3dAb3gl2Vo/PJh7qhjsWDuNz7RMsGNf4yf5UsJ vWMdEDdeEd3uOTD58ngKIaswiV57LXS3v1qfqvkDKcThsZzWJj16QUGwZn63qW6TxIUtmi3r n+EsTXJ0y7Sopa/s91qPJknVF4R5+VXwEk766sU4Ps+vCzArcCWQRdXlC8ueHdJRemqRR5P3 3YIJLFQ1dk99XzKRjbyu8nuTl13tPk6T6SvPbOeqLyW7w9nO1UqdOWJaJOB90JdhXL9JVsR8 8/y2T6foONEzPdzN3hMXzXYocGPQAzOXqzhH52pu7ekrUY70Mb/Z8Ea0eAVUi01uryXGyCUP I1HwxS/mlkLc0xCXD++mKgLNLYC4uRzpbd2sCUbkCTW3RPnzTpnzHScj//fnx/vBHUcJz/Do mHhzxlSuktHrSwj1ezEyUz6+lMIT4h2WmENpWe2mT0mTb7yP6F4o2tDmP/G5v9PMbGvZGk/G nHr42vbOsw8wCUPkDItCaVZI/ZysixKj+XO3zajMVqLLC//46rNL23SMNfQuB56U3a8hRSt+ 70mYJbX3LZlyr4iwoYh84Sl+eBIUhnebaXzrfqPxWSv0mUgWS1M9qq3s1KuKPP2WM4Kq2zZ9 bqjNezzQ/oa758U6lJbs/MG+N6JZiZdyr5Ub6z7e/bg0ZjS6CHSHrG3pWbN/xEq21ChEJWTQ 6OFdAvpxqR26bauBSYQTAe8vwPHTf+/1XLv+FsHrDGtQ1jT1yK7Ckp4imAq+EA/l+JUKOP1y mT9c531+62j+zhTVnwUDWPcmFLjBBKDAMCBTYNPoOwziFggKJ8HKIb08yHKQjNAQlcN5+0UF MyKC2PBrpCFJoVNETsQ9MCCcGRHwvTDcXxWmBpG+Fqa8OB4QSPRgBEXAWYmuNlY/pIIg7te+ 7bV21FLDCvLArIaRfUzzp+UnbtjtnLizfuxu+tVQR3f/6XzkVad79mGr1S0Dm7rUBOIbBXt2 Ddk1ns2SdL2moTNZ9AyvtvyOlfpH//zbS+1OH3FYnn+rdvWKqw56Ccz7S5aZpVOlqUON2tN0 Mz0EZX5u5cYzF8IQqcc//eM8bQ9v1qeIm5ScWTN5Kbv4tskZ12TFlanOQ9AMsJi+PmvBvZzy Ooxaom84U6dfjfvV/1As/XheFD6lerJ1ivh3F9kMWofufYrd0vF6hxwzVw+lLrpb3NnK1LbN loU817QIzDmjlnj1Rne6Rb5zp06iQUTSBuydE90OKciIFHCqOXXY4xsVPkLc95CcEAoaaAkI hxWFP2gYjAgK9f+BCilhjXIIxDwaA6HgAVIVOiTRCmj5TtWuaMDaVv12oNW5wM1Wv9iW9gYS F4al0GhYRimLpLPAmPjyqkQHzcmuBmc2f8tK9qpdtSlfyh2zY4HT85svlf5gXJPkJ0whba7f TO384NF5pbBxM/MNzbbMFozntBX0Ei6JFy7FZ/cPLKvU/nXi9ZmoiqwH1EyLvJAGk/CetGq1 L8PP+xhih9Ia5x6CesOp9wmz0rL6mJfaOUesQ7V2CkyyRkTw7duDbzVyrELppfWC+kzDm5Mo 6YTd73pGrIfj5x4+rJibGe7F17L6Do+6XDThJ+jdtRg0FPc3RhZyQ9T2zfjQsmq21lP7fdO9 kpQN3pnlFfEk+L8cqNUVnDzdUT5AvNgELU0myuNXNbhPW43sgEYPazFSW1iPpkrKuzjWkdGS MGNCYMa4f2OMn1Ss08IfEmqxjjAwZ36iqr8DxwCCYOIYwMCBqBBFaBoITYj9XyntWxz1F/Ef soY/iMu4faXF/tits6aGlWp/Cx0Mu0xaIchue1HVdL1X8wpF5kDDwHbdT2s2L1uiU5WFH5Iv jtBy3KOw1qoiY9259Wn4+9zsylxst7dttM+Lt58lH+1hFxt0sJ9MjPqdTEQJ7OZ7LWV7a27u wHfHTwrk8J99Q7SSd6ULKhuSxxTrDl5+p3DRf/trmWHTcdK2A9WcqKt2o0f3xfgee1YZ02Kc YSC/Wm7Qv71KucwlL6jyLpEK7RzJCFr/6DphGu/Ktlo9hlEPIYXa1xxuPU+9YX063EfJoTyr P3OvZSxuw71T55PUrj6ajKefc2A3alptOu4n7+sMtfGmusVZCeNeTjE9ol7R3G+s+QBx3y3s vaqUULGwCLHNiwQ7RVqXmeD2wXNT3hPF/pC9hhh9zbE/R5OQE6pqaCVIgfPnMrcVTliOtoD+ SX2Zh0O5vnH8nTGWQbKVrcYuId4Zwxg0iEH2IlQUxjaFmZhsjX0p2aWcHGRJKllCtnSGFiHL UT+FypJT2WXNVs7opFTOdf74LV2/P97reu9nuZ/nfe/7+dzPVw3EZmIylSIVXSkUsqqCAsHT Td59LYbyBJK7Avk4cbVVgexJcjxJoHgpaJvTE02e3gTqry1Jv4eog6qgypoNQiPlPjv08fHZ yKGT5zpPlO8O0CfaaFqRzF0yRMLQEI43fIbqBSOdIUHjm/woPqYpevzTwBZi4HOHhOwPLllp f0jvXDzw7OJHM9oReGnVlbHQ6V8QpIOLs5P97E+iWXBb+UTaa2/h9Vik7KzghsnvWJqrjT3e vdLnllaKFvXsPVpeROSWSB4fQsOfB3qQklj3N8kY7b2OkosczGq2laqpUe87XBLGVq20zTQc r7dyOznrIPO1Cy9971gF5eaZNE8VpKVqvXpkI4F7EYTWM5lraziVPlLemEbgNS8qSJ14RmvL zMo/3+Qve1qu9mHXshtDN02lYLLdRoBvc+37puArnCyCLxPE3xZnGeGGi7mkfDnq5KouH38Y r06nTTqdNhFrtNlLHftEG8afRxsLoruTF8XenbyeNsogFqkMIpWUUJ+uN8hPJgpcNcGQK/+V ve0AJf8qlAgPbSLZ1clTRMccL4I3N1FFgjoqu5RU0Jhd2nt0VdYGMvAg/uYjzJ08vYkEp38E 1HA1I6Ghy68wXAeXW3p/zChDohfrjYA/RRlY+z6W7cplTph4u3vpjhQ1Z+l1QCCqrWt3NBYz Nd+pht76r6TQJfSoa4SnYHxfpVFfZcS0Iiu0LtvbS8nIdrKi3yBge2Wy7/MVRMSWPbonWoN2 WHG3h5mqtS32zEWPaQADHT32C3yxhpdD1GeJmsP9UTRm02rKqSH213rD+W6THS4hLPNbmwJ4 bnu9ghstOiyNZWJTVT+OcDXYIxysO1ktwjrUDA1fHbijYCcYl8So3W07EsoqngLPZEQ6RZ8z QWiJZiclfMDr4ElKN/GYAuI1pwW09k2+u2rYfs6YKcHTAxZmwmrpyIL1gPoKpEDPd/Ialjv7 JN+7VkKWDfsD2wZw37CHNGiikVKFzjeMjK9JG76hpqVd//u/xR6KF5lg/x9hz5onykYEZfmB whsAiugfCmff2t7TphslT2tH+4cE7ZDWkpl+IprEkVJw1PzIzoWxOguDqwHveX5n410wnorc AngMhG2XxufJYVEvSamYQ+Pi++MtGGI18tIcVeaUG3i1y1VxvzRuunciRHraOQ/5ysY2fmH/ /n6bkXMJ6US4UVR7u7cRetOxfqpOnuzhMIsgvISA5P2zug8kBwSCiTt55/jq34nJhegekZ1Z uFLvgxMnLVxxjIjLdth0bRfi6usEXNBKcdxyyujkB1hRy97WQ5Qbi9M8wkLY1pyypzUzZeMN BVOWiCX1yYanMjo1tDSNAGf+lhIRAmuT5m4nlAC1pHJ3nZS+iZjARY8YsG4y8VtAcR5ju2ha C0jmcz3HC1v7u2R/j6mfI74+0wlEozGrdMLSzZ8gvn4A5z/x5gXGY6moYY/BCf6GVn2cee1i Pm+1HOo2t+n+hrAxnGLXXmSSdHmiY5+wWXj1XcP2IMb5iZO/RT+82lFIJDv77nAeLK+YiKhq Gb/+gfsy20GxnQptml2WMCHvW+6O7gYWz19O9tAuhT0M7g0ygmKSZ2szWCwRrnotXbXeNgoB 5ZKwMsvDx7YRVoKp6uMdMEljrA+F2fauTWckRu5kI8cwAgunen9Md/Pw7xvFxadknOA4KmPK 72CHyngcZiIrZuOKj+5RCOc0K1m4JRjrNi75K8/8I85nERwzod5eyvXn/bOb7ZhGGYsjFSvm kw+Ha4VbRyR7FAvL6TeT0rT7jg0GScUd/4s3oRBp+h+R2PiE/l/IL04mOH3DMEgoZgtkVVMB 6+i5IRwFvkzghcLYEayAOXAScAC0Aa1vpdkPum4DQCUbcyHvUs1uc8Vl2TNDOGLI+NgJL4s7 GnDGXSuV+8wjto1hEytyLNl6YsrVhNqXbuQ1VtzcJypEYiEGHmfIFtMdcytzp4pV6j4Jn47d /BvzWeW6kcAhsi3+UtLj5taXcbX9NJkW6mhjIarjdNUjwn3ldn5RmnePWmqpkFeG6JnOsjJu i5iZtLtOBqnSUml2ZzerPeRx8tW/3VYQpmpa7GDdAw4NYbcPRE11Y0MWeERjHIMJTLALU6lQ bYVTumeqV6BdTgsGPd0MlHOljB7szekvpO2p+pN8aVyiKtBtp28wPbiAqnytWW+++861qJ5B Z0zsjNiFtOZiH4t9qk89dUrE55ChsCI6pPKhEAgYcvonqrJvtCKciVGWgwEqyAhkhnSDvF/i LQ1BMjPQI0cftJoFn4MJZ0CyM7F+HgKFwOi7+WqxITnA9b1bQPGvE2FIeo69jzdgDjFM7LnF kmpWHEX7IG2aeAt0XDeFHWkJWmTKBEsDxgARIACeAAnwoj/OAAUQASwAP4BMt1zo7fb0N1fA L0sqWOJvyyvFj0xy8bQnu/qJfIc3WCgEEKG9qTwoAKjypgqeMW6dPl+cdk4ze5hD0Qo2ruKl u7x8s/DiRB84EHh2dmSG4dRsh83CLCU9mM2jtLtQgcEDRh5meDrHF7WrNvw8JrcNF25rxeHX 2CnQSfugGJ3xolQku0J3pCrw0lhRLa5+mKbT265VMz/EK3DWcPIcBN92VJE9OqgwJkc7tmHZ ZIVQkHSvBbnjgFeZXUUi7H3jJu9Cfd9CaGpwU2EiWlmq/o0je2YctNFdOKAw0FLp/hMeaske sfMX2/xNyN45hbIPxN76ez2zzYzPmrAyRUJlOb11FpN1tzkk85yKp/4RLt6X86sJBlZv5Hx9 MLc711o8IApsF+bNCoUKg6FQoa8xYkKGQtnpTSz/8xT9viJ9IzCYP6dopi3Ivz4T2b4YzBD6 ml96GJGb6aVWBQmi6IUWhVVUOvRDIkJXJDh6y+1jbeWPgmfwgrNFfaPz3zFrNUV6U+4Z/Ml6 tQZHcRzh3r076fSCQ2CiylXsOQ93BktCNhCCFRkduockFGxJJ+Jd8drTSUIQIMIJ4k1kFCNY gc0j4IAxDycBYguYEwROtjGE8HKCDcFJXE6q4keRCnaASoqinJBYl57ZPemkAio/sruz0/11 T09P90zvnT3/o9g7zn0fumznM683rhkRL5Ev+f5+4sJe0rLt07c+2fJCtvdTz6Ov7tvUEV6f 86+Lj0Yrv9r+z+WbPg+d9V57M3/Gi+/5N9cv+LbmLsk4v0ZunXTz4e3Lz45ZVnlz3tqrd8Z/ 5fa5js11X6vZ8bu/DM3e+4dXDn0Rf6bQUvrZ728qtxonTppdMfP42yc+fD7/6jOxC5ter1s4 t3j/UPvpS7kXF/15u750SXPbweCO00fa1j1VWpjbFnKNOdDz+fni77fIpw699mxoRqzp/Kq/ Pf5k045HWm8dTWF/fT82JG/1lXknD3+0sOtaW92BY1LLY38c5A11TbPd+uLo+HpbyPVAx+zg Asfc+erQ6gVHs7BAWHOljWADu227bSyA9KDRWy7DGhnsIA+2ybKM3wDrJyDHvdAZx4yl8bRN CRECXoCeeAr0gHQmdZfsISDtFlXnuG0QdoRXl9RdqLMFkq9KmIuHvhXvNbABtsBJ+BN+c9qQ 2g57YB/8HBh+2N6BD+D/ePUstc2HTMtxSIGhAPE78Rs9+7DF0NM+ZAtyQ62kD4k74jcHYDd7 tsQdPbGUbEgXY7PkK4jekr6M35GLOR8fz3m5HenBYsQ/Unf1HO7ZPyAGVVAL02A6zAANi10d 1GO5m4OR+Q7Mg/mwQHALUDYb343IzUKtCGpxuk/ru6JgPovlcxG04N2M9PdMjssWCn4RLMZ7 CZbXZbAcVsBK871YICtQskzwS7Ctgh9gZp6D1YJK9AbSBj+E5zFr7bAW1t2XW9dL6dAB6zHP L8CL96Q39OM24r0JNuN++BFshW3wY9wXL8POAehLAt8Bu2A37hku24rIbkFx6VtwDn4Bh+Aw HBOxjGDUjIgk4tIoYtiMMViBK2xL8tiI3+LeaK3CtfO16eZKlyC+OmlEixlHrtmGmoYVIw/c ysoBkdiIazDovhUZ3Fax/j40OSr3QxPx2JkUmZcFx6mB6L3obfAKnsC9+OZR5dSrSBvUbkEn 47t6dfcI/ifwU/gZ5mK/oBK9gexDej8cwLP9GrwOnXj30cmU0R+CgyJzDKLQBUfgKGbyGByH mMDvJ7sbfsTEu3qRbngD3sQd8jacwkpzGu8EcgKxkyZ6RmAGfxp+hTzXMrhzcB4r1K/hN3AR LsFZ5N4T7wvIXYYr8D58IGUh9Vv4DN9fwmXbVRgEk/Bz9wbGeSfMhJne0vpZM2dMn1arKlNr QtVVlU8/NeVbFZPLy0qDAb+vZJK3eOKTRd8sfGLCN8Z/vWB0ft5Ij3sEffihnGFDHIOzMtLT 7PjdFD/y8wI0qBHm0ZjVQ8vK8jlPwwiEkwCNEYSC/XUY0YQa6a/pRc3GAZpeQ9Pbqyk5SBEU 5eeRACXsXT8lMam2SkF6g5+qhN0Q9BRBWz2CyULG5cIRJJDT5CdM0kiABVua9IDmR3vRjHQf 9TWk5+dBND0DyQyk2EjaHJVGTpQEIY8MFEbxu5TFp2UWdyBczyqrlIDf6XKpAgOfsMVSfCxV 2CJzuM/QQaJ5p/T1MQfUabmZ9bQ+PF1hljAO0i0BXW9nQ3LZKOpno5ZdzcElN7A86g+wXIrG Kqp7J5CYze2gRL8N6Dy9cb0/EjaRFLfjNnCSL7E3TChP0IC+oYe4PpeL+9IR80IdMqy1SjF4 AnXOLvAW5KpM1rjkVELywFQuaU1Ieodr1MVTFdDMp6Uph7XWkfw8jL543PignDCLR6uLNPE+ 3KBTv9+IW43CvH4kvGFzrYHoYwWoH9ZwEXN4GKoUVkCb2TBaYiggQHgO5oQUMcQcxob5GGgR cxQrCPi5XySga37DQW6LVindMDb+cXQccR4ZC+NA5X6w4T5MiiegK/WN7CHNWY/7s5EoThfz qhg+lSoNKs8SdbBRH+N0LjGjGIVrG6CdUOYrT3XbiSI7LSrPFgIkiC9aUoQCB6ZLsDyjJUVE kZyQUMNZTA1O9bODjMXtK+MiCx/qK3O6VJdx3cclp+mTzc3sSbYcCPT6ZMxzT9cMbe7QKBJo 8Cc52M+ozXTQtHZ3P2UeC3NiHGHn6SxLiCxuPLmIyWhGQDyLOYRBJVFoA1Up7iFvpcLXxmMt 8lsRohVVtYrItrlLavpxhnyCwTFwoTjByD7cg8FcZyKtgi8VfC9bNkBcnhAT3U4rQjo3Tk2D QPAE4aJTPOXhjgnZ4/BoBrG60WCYEgcJ6uFYvLVOj3q9enNAayrkNmh5vU5DSpFT+FqtrHQu 41NlQ4VUUVOSn4e1pyRKpbVVUa+0NlSrdDvwV+7aGqVLlmSfVqJGR6BM6SYAXoHKHOUgZwhn uKVqZOxC39mNv6BbhdQqAMFHYhIIzJ7AJIjEZANzJDAZMauBeQXGL0xSThOGGMttgNTz9KxQ m3RN5YcLhmMq8ZGYRCcCk+nEqCSnZLJ02lDCMmgJx4s5XmzgKRxPxY0hDZcwOLwm6RrFOoUb SgGnZGxFCzdJYvF4jeJ613lDdeFWm46tVmFpuVj7be7JqFfKm4ZwKWuNhLkfMFXhY1Pd5REV t23CIKqUszS0kGZaQI2gGMO3Iw6KYG4wgWJ8KzKsVWVqLp9UmaOK7exgUEYLMe2GTZuHT1Sg 6tl0jDibeBTS3e28S0PfIKQYiBNZnEw1gpSaiZ5HKIoiGsFoWyESwq1u1NJ0p4E0YEm0ehpE S3eaQuDLsrgzstJZ2mg0iA+nM0bzI2lzp6qq4bzg2k0FnNvBMtAjT1IozQEYHRSVc1/waUdX ueovuZmqGFTTJVhZuNPCUiqKWZa7PIzF3xifgQidkBhs5zUiw7RxxkBT+cozMe4Wd00svp8u dSVd+XmUfxz4xgRnN25sUPWBAJuWm59nH4hmCVjX7Vl3H2DEy57V23OQBPCrgYoSgPG/Mn3P v+/c2ZN2nSPJ12CLdVAfJ10CsO4F+r+2FGf8Im/WWui0+iF813YdZdfhJWscnLxZrkEntoDZ B80WwTYL23Mm3mk5CJ22TJg2sFn/g/aw2bxAZCt0ytb4ZOxHYv8EtsexVWJ7GttyxB/E9oh1 839JL/fgLKozDr97zu5+Me2AiFzSRjSRQARaAgJmEBG5h3APl3AN10SQUEWCGabaWG5yCaM2 QgONIbRaQa6tF1ppBYdaEOs4tqDWab21FCxUtKJFQrbPObvfR0hwzIx/PPOe837nnG93z7vn 91vGlUtMlQfb3Ezmg55meVDPitp3S6o7XXb4b7J2pysQg+Ey+2sZFeJ/LLPddP4LvFm082mH 5JnI/Q2JaAVtE/0TbEo9vHTZ3lTcNZIeaye3NcTtKFms1a4RL8qtEd+x8TO5uql4U4MPDK4r NfqoFF8Jd67UwHz3Pulu0GWMLeNawnhDRBe4CfpH+Ro9mnk/lgWNKCVfKuvcKunnnJYa53SQ T0whDoWOMB7Gwj3kW0Bb97tSo/qKqL7BOn2EtUG9Z1mlTkTts1zbManxfdZ/JEEllNp2IWyX wq/ltyGsU6j/wH+Bu5f2Gdohg2wcJTkhwTn4PNGfJKl6UlAXRuqxXKrhZ1HcCCVRuxH6oqT5 feWWhuhXpZdexp41ZJ4MjEiy8ZhMbUC7K+QsftcQt4dU8v5MjhgJE+P92A9ksv83cEIYO8Nd B/Ohh8zUF2RaU1D3SIa/STKSjkmG+zTtzVG7TwNGNSDK+0sasLoBUf6y8VfxHwPqrb3s0m/u mRCvpWTEMiVDH5KeDbH32phKt0ew0x0QnHeOywrneLCQ2Jw4GW6ARZAPReRbQKU+ICvcdvKQ 81FwLGK2/jn5CDMGOqlUG3OdC5KqLkqlP8f812WMtHFrUGVjNvtxOaMa5fqE+K/avYuvM0O9 IpUhwXniQp0mY0Ko27TgYrzv7QphrUrnE8bvkjR1CEzcLx3cE5LmljQNnnVaLJf6frtpcJ0V sD6KK2EErI7aFfXRVZLu7ZOeDdH3cSZVS3ojbpJJETEbs2WRnilzdCm1ukMGqn/KAjXSxqFq nwxxDkp7tZE9OiULnNky0ykO3qK/wJnOeTaBsScsg+w85jifE7Okv/Oh3GjmqBVyvf5YuqgH 0LiVcr26RfqrcZxnJVBhVPtikkjtSTWhcY7rE10ANldbDUUNclUwzwnob4Kt8JTNz4UZuj3r nSM3GIpsfgs8oDvSz4H5iTXu19+m3xxa2NwO2KYeYf5PYYvNnYIPFB5DvQTPMvYgvI/nsO6j dix0c17DhxyH10K4lxEG7m05can6kY1LnC9kueoW9yvBauNBdB76ulx6hx6i7o9G00K/UPe4 0ebQL9TxmRCMtT7gMWkf13uecV6o4UFrOwfd1k/jTUIdRi/rFprot+Q/0VNf5GFvtEz3Rted j2ui0UJ1wWrMjQkt42yNdKvGfUYKQ93i3k4H46wevS8t4rqjV8n0hJaUhvqhp0iu1YN6Z7fH kzLnupcvq4y+WNbgtQz9eE+7U4+Pon1ZjHuCGgV1mDNgOL8Z7uA8KhVfdZcK1T04DUuhuT1X nuH+CokbqXUlI7Tm3YmfCQsk071GljB/Evs/VaeIdsfLwxH3Q2uvl4z3bpXx3Pc13jap8B6V OQa12u5lMs/J7HUv5cnGBO2p+0AWGux+jpCddj/vjljCHnUUXc87zvTv5D9ekVzP+KuIyA+O Nl4v4bc+FO1/CW+GvjGmL/k493y4z8anxr0X9xmyj3OhItxrL5Ux52CRLPY/ZY12tP8tzf22 xH4wS6a5M2VWLIn2Pfi7gPmf4t0obFsb/5Gt1iddG9GR/S6TZvX8UBevFA0uk4nuan5bLRvg scjjjDf+hXutMbC3jq2X0siTbIP5Ua0Y3xX3EVXUbBWeuyv3kRzWi7ueOfMY96UU+zfidwbR L5A23jJyJ+Efcpc+i3/pTjtA3wvkenc28Aai4Y7No//uAJ6Lqa1jnOuHIo4ZDQry8XltjE7U 13DW74snyHXzqL08PFUemhZq4CKja/o56g3cVtLaV9LSmycF7hB0LDPSqm7QyerPyoTnMDqT IslG66Kzua1+Q9LdOvKc3dRipXuz1dD+3l+k0qujP0ySvXHkXoK11HY51/Yy7aOS7eYF5402 s99t9ULuLYJafcKgNjvJarO8aNDPygqYbvk7tT1DzsBePUeWogUF1HEnU9Pwgqlvb6VsILfO 5OORPXoIOsdjlOusnpPFcCAe3RQ8XwrvQxR1G3HUu2jCbmeNrnV20f8W/e+pe9EQ0LX4SYj1 lcfqQ+68rpWDiXeuWFbAUrWYe1osk9VymQAlqh/naj/yw2QPFH3VONZ6HO6DUlji7pG73Nvw A7UyH25zDsla3VPWemiShzbFvgB0I9YnjP5O2W3g+7PM+4Xc7u2QEdyvMPd299eSQ74T7YlE 453yaf8GhtHPIxbzLDrT7qH/i1ZX8/7+nu/HasZV49PSJCfpZs6KWs73D6nxFnKdWyEF6ijn 8mmZBWOoj3T9JrGXPKB/hWfrxXnQi9puJkNhFyyCIrgB5sJdMBvGWgbwbMolRT/IOXgv5+EO 6aDv5Dqe5xnkSFdqI1fvl7Fcz2goh7kwC3pDkb3mauqnmnplTKPry2zy9WVd6fp4P4Y6/8ND 7JFctVPuUO9IhnqSGnlXpqDL3dX75N/Fp3wkY4hj1Osy0dkvMyD/m8xVVZLtnJNuaqz0UTnU 5TC5Vg1mzhjJUtmSriay1gjWbuq4vUGubikDvQJAS702Ufw+5MERGWkpkiHe87AV/iQdvftl EO1BaLvxc0OTRspQclNjR9ivWnS9VobDDOgM06P2JOAdYq/C38fDBFPP3inp4nrS0/+zzGPv Z6oz+L9aSTJ+w/gAo5n+XM7icTLFbS3DeOc2wQY4Ymkmu2PNnN7xmDxSNvnZfLsVSqazBj/w V6u73xDn9dAPJUiBVnBd1E+th81Fmmq4RZ8MTsKpKJ40OTS1FWyJa+YVqfgK0mW75eUrE/qq iMT3ZfAC7IV9IXxTJtqJ3NR6+pKlLwTvRLwNR00efelgNObSN01wEj66FMltaUSOjfHvgzcS rIviYBMjvVEmor15PPvsuAfUnwW/gwNRPBzlDl8Oubg/LAvOwi9hC2yF9eRboP1XQUXCD27n u2Y7/3cpFrqnv4Jy6gq8Vgk2RbHExNBHBp+Y2KS6OyiFXnt8k8HH4/yEM9XwQ64fz2S+6Yzn MN+tfDNmxPGXXILviFT1L1mvfbQ7V9arp2Ad/YH0p8h650k4Kp56jzx9t5jfSjg3S9Cct2x7 Mto7UZXJYM4G9/+kl3twF9UVx8/u3d8mMBQYCY4kLSiER9ApTAw4GsojQEETJBHC+xEeoTyD YAUqHVQCVEA7BgISLB2iTqEYmMH66AxVCgWLQJGpYGGYaacgMFQBFcfaKtl+zt1d+OVHQGf6 x2fu7t2793HuveecL3nUSPeMZHoD8RVv0Pdq+L0Uk2NeVbxpQZCM2aMQX5pRNrtWuqohFCcI gmToo4nibpOlERsUNMmypLqQJ5kzWL1UJcu4h1epz4BWVm9dgzFVZ6l+svEYNobaSyRAs9UX MebXIfV9Qq7uVaJxM+i/krI1rFXMRqco/D9cdzhv1Vpa1r8VzSNDx1I76BriMVPxHMnwHGeQ 9uZu07bY4khIaDOtt+MeUMxnciD+Hus16jebnTrX8P+0cdIrbZyWyUgf/2gQKDybiL7OP6S7 5bzkKvKVDFDcNGKC0kSKFGcTbTbZulxLVG8inIkRj8gdlj/J7ZbdnFHA/iXJYPtXzduck0xs oNwujiUzBUfcZHQMtQPrtrbg7rWw2qWvtLWaYBN6LJCsxBJbX4Q/nZ3oiDY7yJnfHnyYaE6s WMW5LUa3dCJXR5OmNcE3duUbftXvxv8f8S86xuoT9KjXx+rRFlZ74lu9AnwnOle1kPZL7J+e /qrUpbeWOl+1ziD6fAsyuLf4e/TRA9Znx745iThu+FnB4UQzGaswp8diP0//6enrwr71Wxrz 9Y7x3FX7Di6H8ST4J+uscL161WJF/JdvtdaoYDfrqGCcbjqWzlf1mPoU5jzEXJb8OB6lxheN D/R/0hsQnDfjJcucIwZUy1RvFrYdiN3WSTbj/tqtlTS0zhQ0TiZ+PMuuBx0ZUaM6jz2qS4Ux l0UshTx4GnvbNeock+iiJevqCfN0vyI2M6866AFlME31ZozapwEp67MatH2kV0MWXtvzVM6F +x/T6D6uIj4AOvVHimpYxcbZ3dLanhdFbbk3eBGdlKXj2b2Yx7in2YsBxLTt5ENvUDdTOqvu As/8zsbHMvTfeHdecMnvb+trzMtowH7S2byODylCb/WW0bYenYZPv8vGiG8YL4c+9axOIw+e LsVpaq8/kju1pe1xGYEmHGljc548Ac8kQ1yfTJtRCndjnFcUnDb7sPnL8kAc5+n7h2jKMtsv 3+wcjge7w5yB9jY3qD/COOXkARf1H/dg8Jh7UFp6efiAPPmFPZt55N5/YZ2aSxcx5yjniMYZ em08cgB3pWzwPmb9rNFfK2X+GsaeTFxXjarr5azyby+3b/BvRe3nBtjqNHnEfKt15mtb5wr6 Lgf/8QJnDL2pY0Z2V1ao7rW2TyEpF1L6aOnOk47x+iN+Aq00r2Ht7SLG6L5FzCJ+r6RuVMRo fyr7EpE8D0tog2t2iL9jR2UVNMWugbXBdYw9DzvC8+DuCP6q8N9K6AeLYYhd6yZxoD25u+bv PcxCybFo7pXDN7UrMVXb0se7to1+w2bOZzLMnsXjksO39d4U1ncKBvDPXumJHfPdS9LLtOGc 5kspZz7dXJKXIMMcksFWXy6UXO8DWz+MfGy+94pMM6tkuikmf1wqs9GdrdxccpZPgnrzntT6 uVLlVfGNvCyxRiq4U+nmIvnRUP4fy3mv5J0cydsZ5mfoxJYGHWOeJ79dK7PMBilNOyK16aXc wzFSi4ap89+X2rTp3EfyRcYZZHO+52R9nN/FxLlnYlxwWudm5/ceOjDKHRlD4r71m19K7jZZ NntVzO+LYH+Yj5JzPyVDnE/qjzLWo/z3A/vvxeAV1jGVccSOxXy9ReTD5H9mP3N/ljVE+WxS rhqOWxnlxIckGx/Q2YwOPjb3o3U9/MlzvF/FJzxFntCbvlfrWNRVSjPGKNV23Ic69rjO3ocy uah98W9tRAX9zvHKeQ55OirXMZeu0An6gcBDpphvaptFlCEb4U59Zr1doVT3MWIJ860FgS6Q 7fvscYTarQGp695vbVNr9z+kN1RxFh5MQmzJmYi4A9pEe/qzqHzc2lztBH5vuU8xhznDSqU9 Qwl7jmaEa6GPprZNZHtr9wnoi/2UzMV7kzaXQf/Rs16M/6ihPs7bB0XE70MbyeeXRsTvK68/ e4+jT74F/+S3w91dH/m3ML5wZ82L1/2fjQWQyJJy9YtQ6PWAfHxfv9DHWkr4tknamaPkEPda XRf6KfwDPu4Kdxh/yPv5YIv7H63j+wp83hSptljfF+y1/w0DfF2CGMgdn5roKaX4uQ5JhP7v l1INHbjTyy3q2/8VHHcLgq9suSrYh//rpz4Qv9LZW0AMKJXnY39n/VgJc1Yf9wH8Af+xS0bY OFItE2zJmhNpMhE71bDmMeRCY9i3Gu0bX95ZfZu1U/SPP5e4dEzK0tpgkyvYd5/clXgCWzdj z3bQdgY2viz3wKOs97g3JDhuPsSntAjOEGsne7fR5yGZSV5Q440ml+hD+7lSir2Wu6pnqtBH n0r3xAyZaO30U+x+iNzmt9yJrfjELpLhH2YN05Ni9Vb6eJ/4qvQhB5nJnSyXwsSfpdCfiq75 u9zpN8ceQ6XAdCMf0RjCPrqf8x/fvGJK+kh0k0piqKMakzxcVGe6XzPfWGduleLvoDNDrfma DFa9abVmpDOtxqxDh9TJbPesDPbu5vls+IzmHGRZiC5VXpCuzhSZRDnbG0Gbc5aB7sPS05YK /zpnOC8X+HaKnF7bLZd27kPyPfcdnn/Mt0rpYso5XxPRL/TnfEn9hahd3IZ+aFOsbfxqzvau YIv3NnveNNji/yo4671OHvgOd/8RyIRNxLcWlDnBXvY/36gPJUfwnyEWcx/cGZzF6XAK9kU5 Xwm5CrkEeWqZR47mfCqz/CdtfRzvZ5rFxPT/cl44v/iYHNOL3O/n5C4nkvKT6I7qndUzY2Pw vdzJE1JtFkgha5mFjQa4FfAaLJQCZ49kQ5raVNfurEFjbqOcInPs81mo5n0x8T6bmDsitLnJ 4jx+n5L1qb1NT2zenf7mBCecj6zdhT27h28VFrXpfVLgVsNvYD65mu7ThdDm9j/sDx1dA6vp m7virpB2zj4ZbvJkuBPIs9DVlkdkmeLWSDnMJp8YCOVeoQxQ3BL53B3BHIYDz2jQ8Fnr7uce wbU+tsnSFAphrTsJ20xgfqzLXUKM0nFayvpUvJENoa4/5c3olgrtteyYCvWZlDdAfQFlY6TO 42btCm4xj8bqO1HewP87j1v024HyBm4xv0LKxviu87iZnbMpb+AW83iYsjEazIOzNVmxufVG 7tFouZv35REHLFWcS86r2UN+v4eSdty/XXzbkIzXN/hSMa5s0DNuyabtNvLR2+SYYv2q+k+9 b3qOeXZOBkEI9xvQVw0Q+WaaonNsQHbEzeq/SCGu13k1Y6wgHNO+J/3vTWtIaj/kEG8q+Mgp xMdJ0D8uzTlp7o2oP6Cl2U5ur23GS9sEOa33krSw7drznEucJv5AAXmc7/1NSvxlkkHcXQAm 8p/5cam6xSzC52scraHdfvwx/ZkH0T/kGN4CoA+Nv5on21wvLldyflbWz7Wl5sU7ZSxatG1C eB5P7nyKduSvXm2w36utXwWTeW4P7/L8P9rLBk6nKo/j//vcl4chI8broJkJY7SLEK0orLeY mMyQ8TZMRrLEIC9DTDOSt1bZsYyIEcUsibVWLe3YFMmul12lrU2prEoZwi7muU+/c+/9Tc88 3mY/WzOf7+d8z73nnOfcc885938WhOSzwQCjAGuglBvXsTLkdisj+JaVYc8H6XBcC74NX8C8 fsouNnbZOSDL8d32HM/XgiVGiV1sHrZzQJaZahdeI78WoBzG9SZlrSKcs4rsYv8SOwdk+eur a2XzPsMu9n1g54As3/Br5teCJT4j2BtkmYlBy7xg51iV7emOn7NnWaY9yUy0D4KNRpxdrJ+0 88xa6Ed1e6axyi5EvruLNFCYSU696dYt9lQz3y4szd9qz3DzaCvJ3mgmydCblfVHyVB/VNDy b7en+w/bU/1D1DUvf9SeofLGfMzD8jHwfyhbpp6+DrGsSx8v7evhXDcSMYcTZTFYBPJC8otD 8orUEC9XeaxPzdcyOAfkgnTkxcsrhoGqvpb2Qc/PgOkgATwKRjFmvS7uOp2s4niQ4zH7Gvlq oCrI9u4pOoFM8IRzrviJUOfBnwLztZujZ+PMmY3zrku4T1dn13IyrjzlrPY3RzstFbXTwXSP jKvzwaraaftLpCNwT5AuBE1BMhhvFOJscwPUHuqQi+dXe+2PlgYv6PNA2HXs4yN/TKzHb055 9vzy7MPl2cfK8+0I38/hD4Tnr9oPo+zhZfZD5Bl/MOZQMU6ZeCLUQ+KJ0vihshsX4HwwjZi9 MQ4dJUJ97/WROO92Ql+34ju+H/HgOtwbAEZLtFlZIs2GiBW2yEb/3UjrOLHEcHwXIvl9MCZL C/MI4oflMsmY4LDJvChNFD4D7Y6SfkYa6lYR3R1/gHJ+P1LvW21FBw/opyTVbIT9Aag66EsN 1R8TfXRAvEKMdEnEXhdZygTJ1JPxW7W953lKWhjxoCPOlEOkrVVfOhh1pYM/UnR/E7RVQwaZ sXiG/TLQrIh+pUm+ftw9Z/ouSby+SvLNIrnXOSeex73t4Gvc744xy8Q+fgz3zyIdjO+FioPq SIRz5lRslQTEQBH6V4iZixzyjX1SR2Hmos2DyMdKTbSVb6SgXZQxt0uaGiv9qDQDA6zmMhjn 0/7qjKpw6qVLBX0n3k+yLAFLnb3+Thd9gRjoc1wpRZLg24M+pnjPs0US9CnoV2sZZvWTYebz eK7XpZd1m9S0ktCPrpJkPIk+41mMO9C39dgrTqGe2jOikJ6WAvOQdMH++JBRD9f2O8SjH7WM ZbinYR+bgv1ujWQ4sV2q1HP2AmBUlzZmV6mH8R+rX3YoMPtIjEJT7U5Fu0HUHSias2cWoG2U wxgUlO7rg4Mn8NudVfsKp042YtFn0Z95stpB7XUbXPTPMTdXhnAZ5aPwW7nu8xi1pI1+AJyS nuZckCoT9GMyAfNYs+qgD3NlDOZ5PfzGKLxjzUCkXwEw9W0GSLV+uJaEdCfIB8K/4EegkVEF ZyHgrM+S4CUtKAv1ATIXazBFby0pxlowWYvAvSu+idLF+Fb6ePH6cMTo8aibbI3Ae2wqMf5h mN89sA4bYOwuYO00kWi1Diusl5ZGu6Bt5EissVUGGUskBnVjVBtWrNwP1HidNFfKSb0E+40m O5GmG321942+8oYhOBuJtsuFHrzoryiFePZBaj2jrUzjkLQz02WS/o5URZ/yjOaSZtTGGh0o yUYlrLVOMk5vjPcVj/figbNZkcc+h8LgQoXxiaT6z0uE/4RE+ZdhTY5BX7EHmZWkofUy0n3S z38f1sN+ibUEcckOqVdhsLP271FlFer5zNESZ2LNGq2wV21Gmi3RViWsqd5S09wgefqR4B5/ V8zpFTLQ6oz9BeXVHLd2yFjzTbznZKmGdV6A3+2GZ1Lf/zhzgDxtNJM4/1kZaUbKKOtVzEWU 11eAvc659EO8l2fcd2w/qB10z5zaXrz/h2W4b0uwV8Rq2WYclcW+o5KrgG9FOl5dvxk4T/Zw 51CgFmeTs+cvDzknNiyb9/UP+Q7sCgbVGJtJ2he+WTKbZVUZ/OGLIJ+Cb0B0mfZuQPhfaX+6 uW3qu+GRbt5B3evhscbF6WOaU/4F8AiI87wM1zmLVHEIjfV2/EBoTBYSV41DfLLPBWWuE09g nLF6A3XBFNBH5IoNLuM9yPXTGxE4hLSFy5Xg1TjlNoJNXgoC0R6twxjmMdEDsy2QFsYsl5IC pONAAH4GnAOrPV7xfm+kl2/uofJpXp/PIh2L9DukmR5bkM9w7zk0d59BjZVTd6R3PxTMgMA0 pB+7BHq5lKx3cdp9yaXkM6SJHl65wExcP/5D/ZJFoG8Yi8FSj/4ez6Fujsd4j8seHKtpHos8 HvPIcim54hLY7rHeY5SHNy6l40FSQGOPBI/4MO4qS2j7zjh08+ju4SuLM7ZqvFeFUeBxvett w+CcWOXOiUAr9/fC6ztz1RcyZ8PaCexyKcHqLnnRJXC4LCWjFVjDeTgnvOsidbX3ZJ6KRcrQ XhpZk6WRswf+f/+ytaIes8M3e1vF2lpPSC4lh/IkJZsyizKT8gRlBmU6JYsyjTKVMoUymfI4 ZRJlIiWTMp4yjvIYZSxlDOVXlNGURymjKI9QRlIyKCMoD1PSKcMpwyhplKGUIZTBlEGUgZRU ygDKQ5T+lH6UFEoypS/lQUoSpQ+lN+UBSiKlF6Un5X5KD0p3SjdKV0oXyi8pnSmdKB0p91Hu pXSgtKfcQ2lH+QXlbkpbShvKXZTWlFaUlpQ7KS0ozSnNKD+n/IxyB6UpJYHShBJPaUxpRGlI uZ0SR4mlxFBuozSg1KfUo0RT6lLqUGpTalFqUmpQoijVKdUot1KqUiIpVSi3UCpTKlEiKBUp FSh+ikUxKQZFp/goGkU80YIUmxKglFCuUC5TLlH+S/kP5SLlAuU85TvKOcpZSjHlDOVbyjeU 05SvKV9RvqScovybcpLyBeVzymeUE5RPKZ9QjlM+pvyL8hHlQ8o/KR9QjlHep7xHOUr5B+Xv lCOUw5RDlIOUv1H+SjlAeZeyn/IOZR9lL+VtyluUPZQ3KX+h7KYUUf5MeYOyi7KT8ifK65TX KDsof6Rsp/yBso3ye8pWyhbKq5TNlFcomygbKb+jFFI2UNZTXqa8RFlHWUt5kbKGUkBZTVlF eYGykrKC8jxlOSWfsoyylPJbyhJKHuU3lMWU5yjPUhZRfk15hrKQsoAynzKPMpfyNGUO5SkK wx6NYY/GsEdj2KMx7Pme2voOa/JawACek6C1hJAEkzACfLRWrUWttlVTtSWCxoEyhKMMAQUE nGhIHEgAV+u9t2r3HnZY26YjHDusHdq9a/eyrXbvalu7B33D+5x/+++9F33z+84k8UF9ha49 QtceoWuP0LVH6NojdO0RuvYIXXuErj1C1x6ha4/QtUfo2iOC+kH3H6H7j9D9R+j+I3T/Ebr/ CN1/hO4/QvcfofuP0P1H6P4jdP8Ruv8I3X+E7j9C9x+h+4/Q/Ufo/iN0/xG6/wjdf4TuP0L3 H6H7j9D9R+j+I3T/Ebr/CN1/hO4/QtceoWuP0LVH6LYjdNsRuu0I3XaEbjtCtx2h247QbUfo tiMKdscf0JpV9tkGOrPKdoMNHK1X2eNBN0ddpFNlJ4EIRx1kHWkna1XWJLBGZRWA1WQVCXMt xFEbCXJypcrKBytIK1nOLcvIUrJEZU4Bi8ki0kKaSZPKnAwWctRIGkg9WUDmkzpSy3M1HM0j 1aSKVJIKMpfMIZKUkzIym5SSElJMisgsMpMUkhnKOx1MJ9OUdwaYSgLKWwimKO9MMJkUkHyu TeI5P8njubPJWWQid04g43n8TOIj48hYMoaXnUFO5y2nkdFkFC87lYzkuRFkOMklp5Bh5GQy lFcPIYN550lkEDmRV59AcnjOINkki2QSL8lQGUUgnaSpjGKQSjycdBMXJweSFOLkmoPYOZlM bCSJa1aSSI7n2gByHOmv0ktAP5VeChKIhZNmjgQx9SF6yV99W8SfHP1Bfie/ce1Xjn4hP5Of yI8qrRwcU2ll4AeOviffkaNcO8LRt+Qb8jXXviJfcvIL8jn5jHzKLZ9w9DFHH3H0IfmAHOba IfI+J98j75KD5B1ueZujt8ibKnUueEOlzgGvk9c4+Sp5hbxMXuKWA+RFTr5AnifPkWe55Rny NCefIk+SJ8jj5DHufJSjR8h+so9rD5OHOPkgeYDsJfeTPdx5H0f3knvI3WS38uQBpTzVoIfE yF3kTnIHuZ1EyW3Kg3+vxa285Rayi2s3k53kJnIjuYFcT3aQ63jZtbzlGnI1164iV5IryOU8 cBlHl5JLyMVcu4i3XEgu4Nr5ZDvZRraS87jzPxz9m/yLbCHnknOUewHYrNz1YBPZqNxNYANZ r9wSdCs3/jEWXco9FnSSCI938Nw60q7cjWAtj68hq8kqEiYh0sargzy+kqxQ7gbQysuWc+cy spQsIYvJIp5rIc18Z008vpA0cmcDqScLyHxSR2r5oWv4zuaRan7oKl5dyW9UQeby7c7hN5K8 pZyUkdmkVLn8oES54t+hWLniP95FyrURzFKuEWAmtxSSGcqFXiCmczSNTOVkQLk6wRTlOhdM Vq4uUKBc3SBfpQTAJOIneeRslYL/38VZHE1UzkowgYxXzviPxpnEp5xTwTjlrABjlbMKjOHa GeR05RwOTuPO0coZ/2CjlDP+d/NUMpLHR/A7DCe5vOwUMoyXnUyGkiFksHLG/5ROIoN454m8 8wRelsNbDJLNc1kkk3hJBklXjhqQphy1IFU56oCHuImLDCQpPODkAQcn7SSZ2EgSd1q5M5GT x5MB5DjSnzv7cWcCJy3ETAQx+Xvt9UY8f9kbjD/tjcYfeP4d+Q35FXO/YO5n5CfkR+QY5n9A vsfadxgfRY4g3yLfYP5r5CusfYnxF8jnyGfIp8nNxifJLcbHyEfIh8gHmDsMDyHvI+9h/C48 iLyDvI28ZVtivGkbbbwBX7ctNV6zDTFeRV7B88u2XOMl5ADyItZfwNzztmXGc3h+Fs/P4Plp 22LjKdsi40lbi/GErdl4HGcfw32PIo8g/t79eN2HPIw8lLTSeDApaDyQ1GbsTQoZ9yN7kPsw fy9yD9buxtpuzCmkB4khd1nXGnda2407rB3G7daIEbV2GrchtyK3ILuQm5Gd1hHGTfBG5Aac uR7usC4xrsPztXi+Brkaz1fhritx1xW463LMXYZcilyCXIxchFyIcxfgvvMTi4zticXGtsRm Y2viTuO8xF3GZstgY5PFZ2wUPmOD7Jbro92yS0ZkZzQirRFhjXgjhZF1kWjkYMSf0j+xQ7bL ddF2uVaulmuiq+Ve8zmmJvNm/0S5KhqWCWFXOBS2HAuLaFhMDotRYWE2hR3hnLAlKSSDsi0a lKZgSbA7GAsmTIgFDwfNpqBI3NO7f3fQmx2A/o6gzRFYKVvlimirXN60TC7GG1zka5Yt0WbZ 5GuUC6ONssFXLxf45ss6X42sjdbIeb4qWR2tkpW+CjkX++f4yqWMlssyX6mcHS2Vxb4iWYT5 Wb5COTNaKGf4psnp0Wlyqi8gp+DDmzIdmTmZFkf8DRRl4p2YvCJ/lNfvPew96k0weWPe/V5L ij3DyDAPs6eLguJ00Zrelb493WJPO5Bm9qcNGx6wpx5IPZR6JDVhoD912MiAyePw5Hgs7vhn 88wqD/SZN5mOHtP3WWd5Bg0J2N3C7jbc5imGW5ich51HnRb3PscBh9luF3Z7r93st2O7PdlI NsdfepMt/uTR4wJ2m2Ezx196bRaP34aZ+I1Dk0rKA3arYTXLPGux1ey35hUE/NYRowImi8gR wiQcwDIg/i6E2wjg7/Vuj+gn8P95T3lZbm7hngGm2YWxASXVMbElNrgs/uovrYr13xIzyarq ih4htlX2CHNBecxVWFrF8eatW035WYWxrLKK2I6sysJYNx788YdePJiyejym/Mrc2rZwW25u qBYvtW2h3L7fGIlwfJQbn4z/bgthHP8V7hubcv/xi9tAXRu+Qnoy9M+n/te/xH/7Dfz/f/WY 8CNaManXvMnUaN6IbEDWI91IF9KJRJAOZB3SjqxF1iCrkVVIGAkhbchKZAXSiixHliFLkSXI YmQR0oI0I03IQqQRaUDqkQXIfKQOqUVqkHlINVKFVCIVf7NX57FRlGEcx99n9uTotlvaCrUt 0xYKgmxLyw1SSgFFLGArGIVAFnaBDaVLdhf+MGKMiYgHiooKHqh4oogXl4B4IJ6AiniBVOuN gAqKyrHod4bVEENINCGE5J3NZ+Z53zl2pjvPr7gUozEKl6AOtbgYIzECw1GDizAMF2IoLsD5 GILBGIRqDEQVBqAS/XEe+qEv+qA3eqEneqA7uqEC5eiKMpQigC44F53RCeegIzqgBO3RDsUo QiFMtEUB8pGHs5GLNmiNs5CDbGShFTLhRwbS4UMaWqIFmqMZvPDADRecVX+ydsCAQKmQMCdH kcQRHMYhHMQf+B2/4QB+xS/Yj334GT/hR+zFHuzGD9iF7/EdvsU3+Bpf4Us04Qt8jkbsxGfY ge34FJ/gY3yED7ENH2Ar3sd7eBdbsBmb8A7exlt4E2/gdWzEa9iAV/EKXsZLWI8XsQ5rsQYv YDVWYSVWYDmex3N4Fs/gaSzDU1iKJ/EEluBxPIZH8QgexkNYjAfxAO7HItyHe3EP7sZCLMBd uBN3YD5ux224FfNwC27GXNyEG3EDrsccXIfZuFaFqq4W+l/of6H/hf4X+l/of6H/hf4X+l/o f6H/hf4X+l/of6H/hf4X+l/of4mBDBAyQMgAIQOEDBAyQMgAIQOEDBAyQMgAIQOEDBAyQMgA IQOEDBAyQMgAIQOEDBAyQMgAIQOEDBAyQMgAIQOEDBAyQMgAIQOE/hf6X+h/ofeF3hd6X+h9 ofeF3hd6X+h9ofeF3j/dOXyGL5ed7hs4w5fW48cpl1JH446tLp9yKI/qrWrUcDVmnUrjlc5R fWTFiuxBg7xdPOt5XQ1l8sJ7lUj1gHSnkbYqN7eyeFV391yHf+hq6bK80jOXKK9MNia3lCYb 92b2Lt0rpTubGpsy9m3x9y6taNrW1LVM/IV+W5bP8Hiy3MVFAaN7h5IeFRXl/Y3u3UqKi3yG PdetR8/+joryAsOR9fdMf8Mai2PrkcsdI5Ju46riytEVroLc9Kw0t8vIa53ZpV/7jLox7fsF 8j0Oj9vh8no69hxYNKx+cNF2jz8/Oyc/0+vNzM/Jzvd7kjtcvkP7Xb7D1c76w/Md7r5jK9s5 FjT3Gk63e3VB6zad+hYOHZ3eKsPZolWGP8fryfS37DhobHJ2dp51jbzs7GPXStYoUYNluRHg f3a68i1XnhZ7ncp68s08LM9XWFTCs1QUcudGINN/dFwmiyz2pjVzycEOBW1LSgrc/lxlLzJQ 0zRN0zRN0zRNO6PM0TRN0zRN0zRN0zRN0zRN0zRN0zRN0zRN0zRN0zRN0zRN07RTT/nUMtYO ZS0he23VHnWIkahjS7mMS9UO5ZN5qdpJvShVu6mXpmqPmiVrrKs4mzGTZ/RM1YbyGXWp2sF8 MFU7qWelajf1Qmqh5n6MFama+3G0UUuUqcpVGZ9eVDUqoiaqmIqqOCapBHPVVDE13V4HmYlQ NagAe6pUPR9T1TI3WU1hX9wehdmGOXom6xBHVnNePcdMYC7CERH7uDDbBGdZR5ocYbINcx1r b8Ketc42qa3vDTGaxjampjIX/eecE++d9J+exbqjBvta1t2YahSjiH0P1vfXUQXtUdz+zgZm S1N3ED3uCSYymsHehP2U1tGBJWZ5WVkvsyYyMRaNRyclzOpobHo0FkxEog0Bs6q+3qyNTJ6S iJu14Xg4NjMcCgwbXjVySHXn6mB9ZEIscrJRamNG4mY4kpgSjplBMxaeHIknwrFwyEzEgqHw tGBsqhm19hw3nHTi+zEjDSaXMUc1RBKcX5cIJsJxM9gQKuUCUfsLJkZnNCRikXA8oIap4fz8 I9UQ/qSd//UD19o/4wxmrB/kZEf+3336pT2FL62VN6ROepGYKkNtICcMtqXsVP55cg3ZInYq uRat3jWkMTg+vd8B1cZrx9Ta3VdusrYbixZccfhQ8sZmezwrGVo5ZefYXwIMAPbhOlAKDQpl bmRzdHJlYW0NZW5kb2JqDTM3IDAgb2JqPDwvU3RlbVYgODAvRm9udE5hbWUvS05BUEZDK0Nh bGlicmkvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRGaWxlMiAzNiAwIFIvRm9udFdlaWdodCA0 MDAvRmxhZ3MgNC9EZXNjZW50IC0yNTAvRm9udEJCb3hbLTUwMyAtMzA3IDEyNDAgOTY0XS9B c2NlbnQgNzUwL0ZvbnRGYW1pbHkoQ2FsaWJyaSkvQ2FwSGVpZ2h0IDYyNS9YSGVpZ2h0IDQ2 OC9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMzggMCBvYmo8 PC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9Gb250RGVzY3JpcHRvciAzNyAwIFIvQmFzZUZvbnQv S05BUEZDK0NhbGlicmkvV1szWzIyNl04ODJbMzA2XV0vQ0lEU3lzdGVtSW5mbzw8L1N1cHBs ZW1lbnQgMC9PcmRlcmluZyhJZGVudGl0eSkvUmVnaXN0cnkoQWRvYmUpPj4vRFcgMTAwMC9U eXBlL0ZvbnQ+Pg1lbmRvYmoNMzkgMCBvYmo8PC9MZW5ndGggMjg1NzUvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aDEgNjg4Njg+PnN0cmVhbQ0KSInUlns8VN0ax9eei/u4FzE0QpFLewYx buVa5H5Jp1QzhmHcZmJyibfM5Fa5dJFbvdGokGuppnMQoiIqeUPxitJFN4SUFGeP6hznj/fT X+f0OWt99md9nue31rOfvfZ6vnsDCAAgCRIAGlBsPR02zEZPaSCetwAop7p6riHNPOf3AoBn Iz4KLYzK2rM8hQ0gjBYA6EJaFJtQfaKlC9EfAIDF01mBYdPTzhIAqI0DIKoUGBpLt29+PwzA oTQAzKWDAqj+LzTnLAEk0YHEWxuEOHAVsrYA6CBrgEZQGDtGXKKiEbFhZL5jKJNGRevs/AzA rZOInRZGjWGp2aBzkPXlyHxCODUsQGo2bheAhEcAwDSxmJFs5DkAYrcKdFZEACukCjUHQGA8 El5aoCx0wQiUI5FRHiw05RCYqxwoJLo6eWPyRxwkjCrkKm9BXF4oCCKKw6JCWB1JNEoJC2Cq kJiOEISBuMYoCFPoCbvDuos8eJ5qAh6YL3RX4AciAROEggDARi5LQYfVFgXDyK8SLnI1mdQ7 8MoaUtz15mDfK5vazkLu0tUwFyMLc1GfC9EoCIWSAk3gkLl5qsx9y2na28H1MO5fmUIYJCcW UQfWFkJ7Y8TlVtgwWbERjMAgNkGLpk0gksnGBGcGLYIZyaSzCTbMCJY+URXGf5u85D8VZgSV zWCGE9Xg5QIdLaf4b92DyWQTrHazg5gRDHYsrKqAIxvDRCIMG8NI26qAI8FEkgHxu/kLMuJC KxZvC4QFaC4kBRC/GIoLQaAUVd/EemE24aKsVZATswN+zStN19z5ae64UxF/7ncewTLenXeC l0khhdy39o8dLY9q8+qbeHMyGZ9ZkEivuRGyx0+9R8X8sRR0dCS7pUGPnp8ftDKv01S3QeLy lpVN9i/FLE2ydUu1yCVvHfZbDydK1eaHelPLufGnKXrRTq/yLvmb5bvhiSIa8gWlL4/oKL6w yKXJU7ZgAwpUjD1SPhaPZaFuKv/R4G1XcyChwfStV5ZL5dfiPWFslyrFjmxRLTXgc5jCMK7d JCtsvnl+2+wZupjIuS7OZp+xK2Y7lnKiMX3T1yoTjs9V39nXU6wU4Wt+u25cpGgFXCOU1FZD iJZLGkShkYNfxCmBOWdhDg/ZTRUIw8mHOTkJ0ts6WWOMiFPq7nvlLzpnzLefjvjfvz/uT844 WvAOj4+IN6ZP5igavbsKaTyMlpn0pZAKTom3W2KPpGa2mb5Qmxj3OaZ7uXBDq9/Yl94OM7Ot pWu9GHMaYevaOs4/xsYPENMtCqRZwbVzsq6KjMYvnTbDMlsJrq/94qrOL2vVMdbUuxZwWvag phSt6KMXfkatrWfJpEd5uA1J+CtX4dPzwFCc+3T9e49b9S9b4C8EomiqynFtJeduFdTZ9wlD 6Evbpi4MtPqMBjjc8vC6cgmtJTt/uGdcJHPv1ZwbZca6z/Y8K4kejioEncHrmrrWHhyyki0x ClYO7jd68gCPeVZih2ndamAS7ozH+fHFeGl/dHuts7+D9z7H6pc1TTm2u6C4qxChAgXmop2+ UUFMv0zmT7d539/bG38wReVXwQCpexMS0hACkBAYEEmIafQDBrELBEWCCMmhvD2JcrCMwBCR E/OhRgYxwgPZyG2kYUmBU1hO2CPAP4wZ7v8jMbG/SkwdVvuWmNJi3T+A4MkIDEeiEtxsrH5K BX7sbz3ba+zIJYblxL4ZTSOH6MbZ5adu2e0au28/8iCtOcTJw28qD9Xs/NAhdI2GZUDDXXW+ +Eb+vt0DdvXnMyXdbmjqTBS+xKkvv2+l8dkv794yu7PHHJfn3alZs6LZUS+e+WiJqlkaWZo8 UK89RTfTg0jzc6s2nrscCqWcnP3HRdo+7oxvIScxKaN64mpW0T2Tc25JCqtSXAbgaWAxdXPG gnMt+V0ouVjfcPqSfpXYb35HYugncyNxyVUTLZOEv7vKptPadR+R7JaN1jpmm7l5Kt6lu8ee r0hp3WxZwHVLDcdeMGqK06j3oFvkuXTo7DUIT9wgdP9Up2MyKjwZnGlMGfT8ToXPMOcjLCeA giZGAhYTEkE+aFisMBr9/4EKKUGOchA0j8HCaGSAVQQOScxSjHyHyt0owNpW9b6vxSXf3Va/ yJY2DosLZCkMBimj5EWls8CYuLLKvY4rJ+7WubB5W1axV++uSf5a5pQVA5xf3X6j+CfjhiQv fhJlc/N2Sscnz47rBfWbmeM021JbMJrdmt+NvypesAyX1dunWqH929i7c5HlmY/JGRa5wXUm YV2pVepfB1/1MESPpNbPPQG1hpMf42ekZfWxb7Szj1mHaO3im2QOCePatgfdqU+wCqGX1PJr MwxvT6Cl4/d86BqyHoybe/KkfG56sBtXw+o5Oux6xYQXr/fAot9Q3M8YVcAJVj8w7UvLrN5a S+6lpHknKhl8MMst5Erwdh6q0eWfPtte1ke40gAvSyLI41bXeUxZDe2Ah49qMVKaWE8ni8vu JlhHREkijAlGGOPxnTFUqRjnhT8k9OI6wiKc+YVV/QM4BjCMEMcAAQ5MhkkC00Bgwuz/Smrf dfRf6D9lDa9fLP3e9SaHE3fOmxpWqP8tpD/0mtoKflbr68qGm90rr5NkDtX1bdedXbtZdYlO ZSZuQL4oXMtp39J1VuXp6y/Yp+IecbIqcoQ6fWyjfF+//yL5dB+7yKCd/XxsmHp6L5pvN99t KdtdfXsHrjNugi+H+0IJ1krancavqEsaUbh0+NqHpVf8tr+TGTQdVdt2qCohstlu+PiBaMqJ lxXRTcbpBvJr5Pr92iqVSl1zAyseEMjwrqH0QPunN/FTODe21ZoRrEawWohD9dGWi+Rb1mfD fBUdyzJ7M/ZbxohteHjmYqJ689OJOPoFR3b9SqtNJ6nyFBe4lTvZKc6KH/V2ju4S8Y7ifGfN J5jzYWHvVaQEFYsUoVDjooKdVFufEe/+yWtT7nOF3uD9hv+kvszDoVzfOP7OGMsg2cpWdhLi nTGMsQxikL0IFYWxTWEmM9mybyW7lJMzZEkqWUK2dIZOCVnO1E+hEjmVJWTN1nFGJ6VyrvPH b+n6/fFe13s/y/0873vfz+d+vsxKskMbo2mVE9ulYILg1vCNj7nB6gAxmDaoCWJy0DmqsSqe FApJQ1kZ7+ul5L0WQyU80VuZdIyw2qpM8iW6nsBTyMr61oxEU2I0gcZrSzLuIVqgBqi+ZoPQ WMVPDv39/Tdy6Oa7zhPlmwP0kTa6dkRrj2zxKBSE67WAqVbxaHdE2PimQIq/ZYaR4DSwhRD6 1CUl74NHLvV3uZ2L+59c+MOKdhheUXt5LHL6J1HigcXZyQHOR/Fs2K0C4vSGmzgjNlknO7hp +ju2tjpzn3cvjXnlVOMlfF8cqSol8Eqnjw+j4E9DfYhp7Pta5c32XEMqxg7ltjnK1tdr9R8q j+KoU91mGY0zWrmVnnuA9er55wG37cIKCi3apoqpmXovHzhIY5+FoYws5jqbT2aNVrVQ8fzW pcWZE09onTm5RedagxROKTbc71n2YuqlqRdP0h2EBDY3vG8Nv8zNJvw8RepNWa4ZdqSMRzaA q1Gx9tKx+8laDNpkMWgTs0abPcFjH2nD/ONoY0PwdiNTnL1J62mjBmIQaiBCVRX58XqD+Ggi wVUTjLj8X9nbDlDmr0Ip6qNPIHm6+YobWOPEcdYWGgjQQH2XqjoKvUt/t6H62kAmPtG/+Qhr N18/At7tHwE1UseMb+4JLIk2wBZU3B0zy5Z+gfEThT9GmtgHPFToKWBNmXijvXRbNjh/6VVI KLKzRzseg56a79ZEbf1XWuQS6q1njK9wcn+NWX9NzLQKO7Qxz4+sauY4WT1gErK9Jj3g6Ypo zJbdhsc7wnbY8dKjLDU7F/vm4sd0gMGuPucFgUTTSxFaswTdkYE4GqtlHeXkMOcro5Eir8ku jwi2+a2tIXy3yC/hZosuS2M5mEyNP0Z5mp1FXey72W2iujRNTV/uv63sJJyUxqzf6zgayS6V Ac9hRrjFn7UQ1ZPIS0v5gDPAEVVv4NDFhKtuCyj9GwJ3NDED3AlTwqcGbazENLMQxesB9QVI ob7vlHRsd/bLvPesgSybDoR2DmK/Yg9xyEInoxZVZBqbXE8dua6pp9/027/FHgqZhHf+j7Bn zRNlI4KyfUfhDQBFCIqEc26l93UaxinR6KigiLAdcnry048k0rgyio9YH965MNZoY3Il5D3f bxz8C+ZTsVsAn8Go7XK4QkUM8jkxE31wXGpfsg1Tok4h1VV9Tq2ZX79KA/tTy6Zfj0fITbsX Il46OCYv7Ns34DB6NiWLADeLo9P9zFCbjg4EGxQqHIqyCcNJC8ncPWN4T2ZQKJywk39OoOmd pGKE4WGFmYXLTf5YKeLCZdeYpDyXTVd3iV55lYINWylLWs54O/kBVtq+p+Mg5friNJ+YCKYj v/Jx/UzleHPxlK3oktZk82N5g3oaVSfEXbC9XBzP3qqr7YYUCi6v0W6UNbaQFLrgkwA2TqZ+ DSjuoxwXLBsAmSKepzgx+yCPvG8x9WPE1yc6gSgUepVOGIb5A8TXd+D8J948Q/sslTbvNjku 2NxhjLVuWCzir1NE3uK13NccNYZV6dmDSJOrSnXtF7OKrrtjSg9jnp848Uv8/StdJQSSe8AO 96Gq6omY2vbxax94L3EckNyp3KnbYwsT8bvp7eptYvP0+WQf7WLU/fAXYWZQdPpsQzabrain UXtPg5+DckiVDKzS9tDRbfiV8GCt8S6YjDnGn8LqeMehOxateKKFa0QUAw/2+yPLyyeo/y02 OSP7ONcReUtBFydk9sMoCwVJB09cfJ9yNLdV+cJN4USvcZmf+eYfcD+J4ZqJ9COrNZ0Lymtz YnnLXBarUj2ffihaL9o+Jt2nTEzRuI1I1e8/OhQmm3TsL95EQuQYf0R64xP6fyG/uFngjA3D IJHoLZBVTQWso+eGcBT6PIEfCuMUZQesgROAC6AP6H0tzb7TdRsAKt2cB3En2OoWT1KuMyuE K4GES5wg29zWgTPvWqnZax2zbQyTWp1vy9GXUKUpQl+6XthSfWOvhAiRjRB6jClP0nDMq9I7 WLLG8FH0dOLmX1jPqDWOhg6THHEX0x62dTxPahigybcHv20pQXadqn2Av6tGF5Sg+fVpZlaI kLMlTndXVvLaJMxQ77iZZMrJUp3ObNa8z+cWYHyrszhKw7LMxb4PHB7GbB+Mm+rFRCzwSSS4 huNZYOenMqH6yicNT9etQHvcFkz6epkoZyuYfTjbsp7JOQcbTwpQeSTUodtOXWe5dx5Z80q3 yVr79tW4viF3dOKM5HlqW5m/zV6Nx74G5VJziEhYKQNSRVAIBIw49QNV2VdaEc7CrMDFBBVm BnIiekH+z/GWgyBYmRiRYwxazYJPwYQzIThZ2D8NgUJgjN18sTgQXOD63i2g1JeJMAQjx94n m7BGmKb23WTLtCqLo32Qs0y9Cbqum8KJsAVtcuTD5QBzgADgAV+ACJAZjztAAcQBGyAQIDEs D0a7M+PNEwjMlQ2X/tvySgkkET18nUmegeLf4A0WCQHEaa9rDggBGvyZwqfNO6bPlVHP6uaN cKnYwcbVyYbLyzdKLkz0g4OhZ2ZHZ5hOznY5LMxSssI5fCp6S5SZfGCkEabHcwJxuxqiz6EL OrHRjnZcgS3dQt20Dyrx2c8qxPOqDUdrQy+OlTZgm0ZoBi/oevXzw/xCZ0wnz0JwnUdUOOPD ShLy9RObly1W8MVpv7YjduwnVzpVp8Let2zyKzEOKIFmhreWpKLUZJteu3LmJEFbvMVCSkJt Ve8+4gsu3y157kJnkAXJL79E4Z7kmyDyE8ec5NwJO0sEVIHbz2Ax3XCbSzrfyeTg36Ol+vN/ tkDDmszcrw0V9BbYS4XEgXQx/txIqBgYCRX5EiMWRCSUk9HE9j9P0W8r0lcCg/VTiuY4goLr M5Hjs8EKYaz5uYcZsZlRatURIJJRaJEYFdWD3yUidEWa60XVn6xXa3AT1xU+u5Js+QXCEOqJ ps0qF6kQy5gCpdR1sLAetnFIbcs0u+a1smxjKFCTFvOmDm6wWUPCo0AghEfaAk0MXBkKchIC JbzSkkBJ20zamUIydEpSw7TDMElpY/Xcuytb1gDTH93du3vOdx733HPunpVCG2aOnj2m3f/o 3SPXe75I6llsi1zb/s4Ua9616Lv2/R85LBcyexrWjogVi5e9/zh5cZ/UvO2Ttz7e8kK25xPX E6/u39QRWp/zr0tPRCoebftixabPguc8N9/Mm/ni+77NdQu/pzqLMy6sFVsm3358x4pzY5dX 3J7ffuPehK/cPd+xufar1Tt//9eh2fv++Mrhz2PPFJhKPv3DbflOw6TJc8pnnXj75EfP5914 Jnpx0+u1i+YVHRhqPXM599Liv+zQli1taj0U2HnmaOu6p0sKcluDjrEHez+7UPSjZvH04dee Dc6MNl5Y/fdvPNm48+std46l0L99EB3iXnN1/qkj1xZ13WytPXhcaB7zp0GeYNd0y53Pj02o swQdj3TMCSy0zVugDK1aeCwLG4Q5V9gIFrBadljGAQhf05+mK7BWBCuIgy2iKOI3wPwxiDEP dMawYmmsbFODkgQegN5YCvSCcDZ1t+iSQNjDu84JyyB8SKy7pO5GnS2QeFTAPHzpW/BcCxtg C5yCP+M3pxWpHbAX9sMvgeKH7V34EP6PR+8yywLINJ2AFBgKELsXu9W7H0cUI+1HtiA31Cz1 IzFb7HYSdrt3S8zWG03JhnRumyVeRfSO8GXsnljE+NgExottSA/mFv9M3d17pPdAUg4qoQam wwyYCSo2u1qow3Y3FzPzfZgPC2Ah5xaibA7eG5CbjVph1GJ0v9YPeMN8FtvnYmjGswnpHxoc ky3i/GJYgudSbK/LYQWshFXGfQlHVqJkOeeX4lgNP8bKPAdrOBV/6kgr/ASex6q1QTuseyi3 ro/SoAPWY51fgBcfSG8YwG3EcxNsxv3wU9gK2+Al3Bcvw64kdDvHd8Ju2IN7hsm2IrKHU0z6 FpyHX8FhOALHeS7DmDU9I/G8NPAcNmEOVuIKWxMi1vO3pC9bq3HtbG2asdKliK9JsGg28sg0 W1FT96LXgXlZlZSJjbgGne5fkc5t5evvRxOz8jA0no9dCZl5mXOMSkYfRG+DV/AN3Id3llVG vYq0Tu3hdCK+u093L+d/Bj+HX2AtDnAq/tSR/UgfgIP4br8Gr0Mnnv10IqU/D8MhXjkKEeiC o3AMK3kcTkCU4w+T3Q8/auBdfUg3vAFv4g55G05jpzmDZxw5idgpAz3LMZ0/A+8gz7R07jxc wA71G/gtXILLcA659/n9InJX4Cp8AB8KWUj9Dj7F+5dwxXIDBsFk/Ny9gXneBbNglqekbvas mTOm1yjytOpgVWXFd5+e+lT5lLLSkoDf5y2e7Cma9GThdwq+PfFbE76ZPzrPPdLlHEEefyxn 2BDb4KyM9DQrfjf5j3y3nwRUibpUanaR0tI8xpMQAqEEQKUSQoGBOlRSuZo0UNODmg1Jmh5d 09OnKdikQijMc0t+ItH3fESKCjWVMtIbfESR6C1OT+W02cWZLGQcDrSQ/DmNPokKquSngeZG za/60F8kI91LvPXpeW6IpGcgmYEUHUmaIsLISQInxJH+ggh+l7LYtNTk9IfqaEWl7PfZHQ6F Y+DlvmiKl6ZyX9JcFjN0SBH3aW191Aa1am5mHakLzZCpKYRGmsmvaW10SC4dRXx01PIbObjk euomPj/NJeisvKpvAoFanDYiaXcBgye3egYiIQNJcdruAiPZEvvShPI4DRgbRojrczhYLB1R D9QiQ1sqZZ2XoNbeBZ78XIWKKpOcjksemcYkLXFJn7lKHKxUftW4mhtzaEutlOfG7PPLiRfK JWpyqbXhRvYM1WvE59PzVi1Tjw8JT8hYqz8yJh/1QyouYi5LQ6VM80kTHUaKdQUEJFaDuUGZ mxhmdJiXgho2rGi+38fikvya6tMDZL5IpdwN42LXI+Ml+9FxMB4UFgcd7sWiuPyaXNdAH1Pt dbg/GyTZ7qAeBdOnELleYVUiNjrqOk7n4DNyK1xbknZcma081WmVZNFuUli1EJACeCPFhSiw Ybk4yypaXCjJgh3iajiLocGoAX6QMTm9pUxkYqbeUrtDcejHQ0KyGzFZnNSa4MuGQF9M+jwP DE3XZgGNkvz1voQABzi1GAEa3u4fp8hyYUyMFlZWztK4yOTENxcxEd1wiFUxR6JQIcmknigE 95CnQmZrY7nm9S0PkvLKGplX29gl1QM4XT5R5yg4UBxnRC/uwUCuPV5Wzpdwvo8tTRKXxcWS ZiXlQY05J4ZDkPANwkWnuMpCHROzx+OrGcDuRgIhItmkgBaKxlpqtYjHozX51cYC5oOU1Wkk KBfaeaxV8ir7cjZVNpQL5dXFeW7sPcURIrRXRjxCe7BG7rbhr9z2arlLFESvWqxERqBM7pYA PBwVGcpAxkiMYZ6qkLFyfXs3/oJu4VIzBzgfjgrAMWscEyAcFXXMFsdExMw65uEYO7BIOY2Y Ymy3fqmOlWel0qipCnu5YDiWEi+BCmQSUJFMighiSiZNJ/XFNIMUM7yI4UU6nsLwVNwYwnAB k8N6kqYS7FO4oWSwC/pWNDGXUjQWq5Yd79lvKQ7cajNw1Mg0LRd7v8U5BfVK2FARLqEt4RCL A6bJzDbVWRZWcNvGHaJKGU1DD2mGB9QIcBu2HdEojLXBAnL7FmRoi0KVXDapPFfh29lGoZQU YNl1nxYXmyhf0bLJWP5u4quQ7mxjjzSMDYKyjtiRxckUPUmpmRh5mKAorEqYbTOEg7jV9V6a bteRemyJZlc9H+l2QwhsWSZnRlY6TRuNDvFidMZo9kpanKmKogfPuTZDAee20QyMyJWQSsMA s4OiMhYLXm0YKlP9NXNTGYUqshQ7Cwuae0pFMc1yloWw+ev2GYiQiXFjK+sRGYaPszqaylae iXk3OaujsQNkmSPhyHMT9nFgGxPs3bixQdGSATo9N89tTUazOKxp1qz7G+j5smb1PRko+fGr gYoCgP6/Mn3vv+/d25vWw5DEY7DJPKifEy4DmPcB+V9Hij12iQ1zDXSafRC67+hBWQ9sN8fA zobpJnTi8BvPgDHCOGbjeM7AO02HoNOSCdOTh/k/6A+HxQOSaIZO0fxf0ss8OovqjMPv3Dsz X6Q9UESWtBFIICQCLYsQUgRE9hD2sIQ1rImsFWTJoYXGsskSjtIADTSG0GoFWVsXWmkFD7Ug 1uOxBWo9LSItDRQqWtEiIdPnzsz3ERI45hz/eM577/vde7+Zue/c32+8gcRU4nehAwyDofB9 8k0hxd7EuEKJqEJvl53KfNATfZ7QU8P2Y5JgT5I97hnWbn0HIjBIpn0pQwPcj2SancR/gTOV djbtgCwTub/+IQ2hSax/gU2pgpMku2uLvU6SIk2le3XsFGnPWk1r8Jo8FPJNP34q36gtzgTv Q4NtS5k+KXPvhD1DymCWvUQ6GnQBYwu4liA2D2kLD0CvMF+mhzHvRzKnBvnk82WDXSI9rctS Zl32sonxxAGQAqNgBMwnXx+a2N+SMtVDRPXwNugTrA3qA5816kLYvsq1nZIy12X9p2MUQ77f zoXdkvul/CaAdXL17/kvsA/SvkI7oK8fh0pGgHcNPov1x0qCHutVBpF6LJRS+GkYt8KisF0D fVMS3R7SpTr6LUnTK9iz6syUPiFxfjwlE6rR9A45H7ddgN1Jinl/xoUMgTHRfuR7Ms79G1gB jJ1sb4BZ0Emm6BsysTao+ZLsbpPkuFOSbL9Ae3vY7laNodUI8+7iaqytRpi/bfw9/EfvKmuv uPWbfSXAaSDJkVRJ1sekc3X8e61Jsd3J22v39q5bp2WVddqbR6xHHAfNYQFkQx75+lCsj8gq u6k8aV3yToVM0z8jH2LGQGuV4MdM64YkqJtS7E43/3UbQ/y40yvxYzr7cTtDa+S6Bbhv+XsX XWeyelOKA7zrxHk6UYYHULeJ3s1o39kXwFrF1seM3yeJ6hiYeFha2Rck0V5UO3jWiZFM6vu9 2sF1FsHGMK6GwbA2bBdVRZdIknNIOldHL+FMKpWkGjwgY0MifkyXBXqKTNf51Ooe6aP+KXPU ED8OUIekv3VUWqqt7NFFmWNNkynWXO8v9OdYkzjPRjP2gk9ffx5zrM+I7aWXdV5amDlqlTTT H0lbtRyNWy3NVBfppUZyni2CIqPaN+NEKsrV6Jo5rk90Dvi5ilLIq5YrgZmWR38b7ITn/fwM mKxbst41cv0gz8/vgOU6hX4GzIqtsUx/nX49qO/n9sAu9TTzfwI7/NxF+FDhMdTr8BJjj8I5 PIfvPipGQAfrbXzIaXg7gHsZbODeVhKXqh/6cbH1uaxUHaJ+xVtrPIjOQl9XStfAQ1T+wWha 4BcqnzHaHPiFSj4TvBG+D9gsLaN6zzPOCjTca+TPQbf1C3iTQIfRy8p5JroN+E/01BV5yhkm k5xhldejmmi0UN3wNaZFTMs4W0PdKrNflNxAt7i3y95IX4/OSf2o7ug1MimmJfmBfujxkunr QZWz2+FJmXPdyZY1Rl981uG1DD15TztSj5vQvvaMe5YaBXWcM2AQvxke4TzKF1d1lCLV0bsM S6Gef668yP3lErdS60oGa827Ez0T5kiqfa8sZv5Y9n+Cjhdtj5KnQpZBIydNRjkPySju+15n lxQ5m2S6Qa3197IOz8nsdZpyZGuMltS9J/MM/n4Olr3+fj4Wspg9ShFdxTtOcR/lP96UTMf4 q5DQDw4zXi/mt86Ldr+AM4FvjOhbPs6+Huyz8alR78V9BhziXCgK9tpJYMw1WCAL3U9Yoynt f0s9twmxJ0yVifYUmRqJoz0ff+cx/xO8G4Xt18Z/ZKfvk+4LSWG/C6RuFT/U1slHgwtkjL2W 39bKFtgcepxRxr9wr2UG9tby6yU/9CS7YFZYK8Z3RX1ECTVbgudux33UCerF3sicmYz7Qua6 LfA7fennSGNnBbly+IfM1lfxLx1pe+h7jjSzpwFvIBpu+Xn03+7NczG1dYpz/VjIKaNBXjY+ r7HRiaoazvo98ASZdha1l4WnykLTAg1cYHRNv0y9gd1QGrlKGjgzJcfuj46lhlrVAVr7+rM6 5jmMzsRLHaN14dncRL8rSXYlec5uarHYftDX0F7On6XYqaQ/UOo4I8m9Duup7UKu7Q3aJyXd zvKuG21mv5voedxbCLX6rEFtt+qo7fKaQb8kq2CSz9+p7clyBQ7q6bIULcihjlubmoZXTX07 q2ULuQ0mH43s0ZPQJhrDXBv1siyEI9Fox+P54nkfwqgbi6XOogn7rXW6wtpH/2v0v60eR0NA V+AnIdJDNleF3HVdIUdj79xcWQVL1ULuaaGMUytlNCxSPTlXe5IfKAcg727jWOsZWAL5sNg+ ILPt7viBCpkF3a1jsl53lvUOmuSgTZHPAd2IdAuiu1f2G/j+LHB+Lg87e2Qw9yvMfdj+lWSQ b017DNF4p2zav4aB9LOIc3kWbWh30v9Fq0t5f3/H92Mp40rxaYmSEfcgZ0UF5/t5ary+3G8X SY46ybl8WabCcOojSZ8hpsly/Us8WxrnQRq1XVcGwD5YAHnQHGbAbJgGI3x682wKJV4/wTn4 OOfhHmmlH+U6XuEZZEg7aiNTH5YRXM8wKIQZMBW6Qp5/zaXUTyn1ypga15da6+trf6fr4/0Y YP0PD3FAMtVeeUS9L8nqOWrkrIxHlzuqc+TP4lMuyXDicPWOjLEOy2TI/ipzVYmkW9ekgxoh 3VQGdTlQ7lP9mDNc2qt0SVJjWGswa9d23EEvUzeQPk4OoKVO4zB+B7LghAzxyZP+ziuwE/4o Kc4y6Uu7L9pu/NyAuCEygNyEyAn2qwJdr5BBMBnawKSwPRZ4h9ir4PdRMNrUs3NR2tqOdHb/ JDPZ+ynqCv6vQuKM3zA+wGimO4OzeKSMtxvJQN65bbAFTvjUlf2RulbXaKwzRLa56Xy75Uqq tQ4/8Fdfd78i1juBH4oRDw3h/rCfUAU/F2qqoYsu98rhYhjLTQ5NbQg7opp5R4ruQpLs9nnj zgS+KiT2fem9CgfhUADflLF2LDehir601ze890Peg5Mmj760Mhpz65vGK4dLtyK5HTXI8GP0 ++DdGBvC2M/EUG+UiWhvFs8+PeoB9afeb+FIGI+HueO3Qy7qDwu8q/AL2AE7YSP5+mj/PVAU 84O7+a7Zzf/dirn25btQSF2B0zDGtjAuMjHwkd7HJtaq7o5KrtMS32Rw8Tg/5kw1/IDrxzOZ bzrjOcx3K9+MyVHcxbfgOyJB/Us2ahftzpSN6nnYQL8P/fGy0XoOToqjPvg/6eUe3EV1xfGz e/e3CUwKjARHSAsK4ZHoFAYBR0MJBBA0QYIQ3o9ACOWNYHlUOogEqIB2DAQk2HSIOoViYAbr ozNUKRRaBIpMBQvDTDsFgaEKqDjWVsn2c+7uwi8/HjrTPz5zd+/evY9z7z3nfKnn3ZvFt/n4 zfnEnBP2eTSxd4S7VB7GN3jkUSPcM9LK64+veJO+18DvpJgc86riTQmCZMwehfiSQZlxrXRV QyhOEATJ0Ecjxd0myyI2KmiS5Ul1IU8zZ7B6qVKWcw+vUp8Jza3eugZjqs5S/WTjMWwKtZdI gGarL2LMr0Pq80Ou7lWicTPpv4KyBaxTzCanKPw/XHc4b9VaWta/Hc0jU8dSO+ga4jFT8RzJ 9BxngPbmbtO22OJISGgzrbfjHlDMZ3Ig/h7rNeo3m5061/D/tLHSM22slslIvn80CBSeTURv 5x/SxXJeuirylfRT3DRigtJIihSnhjY1tq6rJao3Ec6EiMflLssf5U7Lbs4oYP8hyWD718w7 nJNW2EC5UxxLqxQccZPRMdQOrNvagrvX1GqX3tLaaoIa9FggWYkltr4Ifzoz0R5tdpAzvz34 MNGEWLGac1uMbulAro4mTWuEb8zlG37V78z/H/EvOsbqE/Sol2/1aFOrPfGtXgG+E52rWkj7 JfZPTX9N6tJbSJ2vWmcAfb4Nmdxb/D366CHrs2PfnEQcN/ys4HAiQ8YozOnJ2M/Tf3r6+rBv /ZbGfL1jPOdq38HlMJ4E/2Sds12vXrVYEf/lWa01MtjNOmYzTmcdS+erekx9CnMeZC5LXhyP UuOLxgf6P+n1C86bcZJlzhEDqmSyNwPb9sdu6yWbcX/l1koaWqcMjdMKP55l14OOjKhWncce 1aXCmMsjlkE3eAZ72zXqHJPopCXr6gFzdb8iNjOvOugOpTBF9WaM2qcBKeuzGrRtpFdDFl7b 81TOhfsfc9N9XE18AHTqjxTVsIqNs7ulhT0vitpyb/ASOilLx7N7MZdxT7MX/Yhp28mH3qRu unRU3QWe+a2Nj6Xov3Hu3OCS39fWV5tX0IB9pKN5Ax9ShN7qJaNsPToNn36PjRHfMF4OfepZ nUIePFWK09RefyB3ak3b4zIcTTjCxuZu8hQ8mwxxfRJtRircjbFeUXDa7MPmr8hDcZyn7x+i KUttv3yzczge7A5zBtrb3KD+COOUkwdc1H/cg8GT7kFp5nXDB3STn9uz2Y3c+y+sU3PpIuYc 5RzROIOvjUcO4K6Sjd7HrJ81+uuk1F/L2JOI66pRdb2cVf7t6fYO/q2o/dwAW50mj5hntc48 betcQd/l4D9e5IyhN3XMyO7KStW91vYpJOVCSr6W7lxpH68/4sfQXPMa1t4mYrTuW8QM4vcq 6kZGjPInsy8RyfOwhDa4Zof4O3ZUVkNj7BpYG1zH2POwIzwP7o7grwr/rYI+sBgG2bXWiANt yd01f+9uFkqORXOvHL6pXYmp2pY+/mTb6Dds5nwmQ+1ZPC45fNvglbG+U9CPf/ZKD+yY516S nqYl5zRPSjjz6eaSvAyZ5pAMtPpyoXT1PrD1Q8nH5nmvyhSzWqaaYvLHZTIT3dnc7UrO8klQ b96TWr+rVHqVfCMvS6yV2dypdHOR/Ggw/4/hvFfwTo7k7QzzM3RiM4OOMS+Q366TGWajlKQd kdr0Eu7haKlFw9T570tt2lTuI/ki4wywOd/zsiHO72Li3DMxNjitc7Pzew8dGOWOjCFx3/rN LyF3mySbvUrm90WwP8xHybmXyiDnk/qjjPUE//3A/nsxeJV1TGYcsWMxX28R+TD5n9nP3J9j DVE+m5SrhuNWRDnxIcnGB3Q0o4KPzYNoXQ9/8jzvV/EJS8kTetH3Gh2LugrJYIwSbcd9qGOP 6+x9KJWL2hf/1kbMpt9ZXjnPIc9E5XrmkgsdoA8IPGqK+aa2WUQZsgnu1mfWmwsluo8RS5hv LQh0gmzfZ48j1G4NSF33fmubWrv/Ib2gkrPwSBJiS85ExF3QMtrTn0blfGtztRP4veQBxRzm DCsV9gwl7DmaFq6FPhrbNpHtrd3Hoy/2UzIX7y3aXAb9R896Mf6jmvo4bx8QEb8Pvkk+vywi fl91/dmbjz75FvyT3w53d0Pk38L4wp01L133fzYWQCJLytUvQqHXHfLwfX1CH2sZwrcaaWOO kkPcb3Vd6KfwD/i4K9xh/CHv54Mt7n+0ju8r8XllUmWxvi/Ya/8bCvi6BDGQOz450UNK8HPt kgj93y+kCtpxp1dY1Lf/KzjuFgRf2XJ1sA//10d9IH6lo7eAGFAiL8T+zvqxIcxZfdwH8Hv8 xy4ZbuNIlYy3JWtOpMkE7FTNmkeTC41m36q1b3x5R/Vt1k7RP/4c4tIxKU1riU2uYN99ck/i KWydwZ7toO00bHxZ7oMnWO9xb1Bw3HyIT2kanCHWTvLuoM9DMp28oNobRS6RT/s5UoK9Vriq ZyrRR59Kl8Q0mWDt9BPsfojc5jfcia34xE6S6R9mDVOTYvVW+nif+Krkk4NM506WS2Hiz1Lo T0bX/F3u9ptgj8FSYDqTj2gMYR/dz/mPb14xJX0kOksFMdRRjUkeLqoz3a+Zb6wzt0rxd9CZ odZ8XQaq3rRaM9KZVmPWoUPqZKZ7VgZ69/J8NnxGcw6wLESXKi9KrlMmEylnesNpc87S331M ethS4V/nDOflAt9OkdNruxXSxn1Uvue+y/PDfKuQTqac8zUB/UJ/zpfUX4jaxW3ohzbF2sav 4mzvCrZ477DnjYMt/i+Ds94b5IHvcvcfh1ZQQ3xrSpkT7GX/84z6UHIE/1liMffBncZZnAqn YF+U8w0hVyGXIE8t9cjRnE9lhv+0rY/j/XSzmJj+X84L5xcfk2N6kvv9jNzlRFJ+Et1RvbN6 ZmwMvp87eUKqzAIpZC0zsFE/dza8DgulwNkj2ZCmNtW1O2vRmNsoy2SWfT4LVbwvJt5nE3OH hzY3WZzH71OyPrW36YHNu9DfrOCE85G1u7Bn9/FttkVt+oAUuFXwa5hHrqb7dCG0uf0P+0N7 18Aa+uauuCuljbNPhpluMswJ5DnIteURWa641VIOM8kn+kO5Vyj9FHeIfO4OZw7DgGc0aPis dQ9yj+BaH9tkWQqFsM6diG3GMz/W5S4hRuk4zWRDKt6IhlDXl/JWdE6F9lq2T4X6VpQ3QH0B 5c1Incet2hXcZh43q+9AeQP/7zxu0287yhu4zfwKKW/Gd53HreycTXkDt5nHY5Q3o8E8OFuT FJtbb+IejZJ7eV8RccBSybnkvJo95Pd7KGnH/dvFt43JeL2DLxXjykY945Zs2m4jH71DjinW r6r/1Pum55hn52QQhHC/AX3VAJFvpig6xwZkR9yq/osU4nqdVwZjBeGY9j3pf29KQ1L7IYd4 S8FHlhEfJ0LfuDTnpIk3vP6AlmY7ub22GSetE+S03svS1LZry3NX4jTxBwrI43zvbzLEXy6Z xN0FYCL/mReXqlvMIny+xtFq2u3HH9OfeQT9Q47hLQD60PirebLN9eJyFednVf0cW2pevFPG oEVbJ4Tn/9FeLvA1HXkc/997HpdQUeIZVFJEdBdF6Sot1qukpIJKPBKppGopQT1CK01s16ur tSxRSpSWLFXWWu3Sja1X1a7HrlZXt1ptrbZaodhF7jn9zTnnl95cr+xn2+Tz/cx3zpmZO2fO zJz/DEXsfBzlEL/qBfZuvcCaA9LhsWAPfG5IPgcM0guwBkq5eR0zQ+40M+zdZoY1B6TDcc3e A5/LvHbaKtZ3WLkg2/Gd1rOerwaL9BKr2Dhs5YJsI9kqvE5+NUA5jOstyppFOGcVWcWBRVYu yA7UV9fK5v26Vez/wMoF2f7h182vBov8ut0HZBsJtmlctHLNytY0x89bM0zDmmgkWAfBej3W KtZOWQuNWuhHdetpfYVViHwPF2mgMBKdetPM26wpRr5VWJq/3Zru5tFWorXeSJRhtyobiJJh gSjbDGy1pgUOW1MCQ9U1L3/Umq7y+hzMw/KR8j+ULVNPW4NY1qWvl/bzcK7rCZjDCbIAzAcL Q/ILQvKK5BAvV3msT5+/lf0syAPpyIuXV6SBqv5W1kHPz4JpIB48DkYyZr0h7jqdpOJ4kOsx 8zr5aqAqyPHuKTqDLPCUc674kVDnwR8D441bo+XgzJmD865LuE9TZ9dyMrY85cwOt8Z3Rir6 ztjpHhnX5u2qvjPWF0hH4J4gnQeagSQwTi/E2eYmqD3UIQ/Pr/baHyy1L2qzQdh17OOZPyTm k7emPHt+efbh8uxj5fl2hO/n8IfC89fsh1HW8DL7IfKMPxhzqBinTDwR6iHxRGn8UNmNC3A+ mEqMPhiHThKhvvdaJs67ndHXzfiO70c8uAb3BoFREm1UlkijEWKFTbI+cC/SOk4sMRzfhUh+ H/RJ0tI4gvhhqUzUxztsMC5JU4VfR7sjZYCeirpVRHPHH6BcIIDU+1ab0fYB7bQkG42xPwBV B32pofpjoI8OiFeIni4J2OsiSxkvWVoSfqu29zy/lJZ6HOiEM+VQaWfWl456XekYiBQt0BRt 1ZDBRgyeYb+kGBXRr1TJ106450z/ZYnTVki+UST3O+fEC7i3FXyF+z0wZlnYx4/h/jmkQ/C9 UHFQHYlwzpyKzRKPGChC+xIxc5FDvr5P6iiMPLR5EPkYqYm28vX+aBdljK2SqsZKOyrNwSCz hQzB+XSgOqMqnHrpUkHbjveTJIvAYmevv9tFmys6+hxbSpHE+3ehj/2959kk8dpk9KuNpJkD JM14Ec/1pvQ275CaZiL60U0S9WfQZzyLfhf6thZ7xWnUU3tGFNIzUmAckq7YHx/R6+Hafoc4 9KOWvgT3fNjHJmO/WyUZTmyXLPWcvQDo1aWt0U3qYfzHaFccCoy+0lDhU+1OQbs26qaIz9kz C9A2ymEMCkr39SH2Sfx2F9W+wqmTg1j0efRntqx0UHvdOhftM8zN5SFcQfko/Fae+zx6LWmr HQCnpZcxCyTLeO2YjMc89pl10IdZMhrzvB5+YyTesU9HpF8BMPVvBEh9A3AtEel2kA+Ef/aH oLFeBWch4KzPEvuyz5Z52iCZhTXYX2sj/fXVYJIvAveu+idIV/0b6evF68MRo8ehbpI5Au+x mTQMpGF+98Q6bICxu4i101Si1TqssFZa6e1tS8+VGH2zDNYXSUPUbajaMGPkQaDG65SxXE5p JdhvfLIdabrez/e+3k/e0gVnI/HtcKHblwIVpRDPPlitZ7SVpR+S9ka6TNTekaro00K9haTq tbFGUyRJr4S11lnGak3wvuLwXjxwNivy2OdQaM9T6B9LcuCCRAROSlRgCdbkaPQVe5BRSRqZ ryLdJwMCD2A97JcYUxCXbJN6FYY4a/8+VVahns8YJbEG1qzeGnvVRqQ5Em1WwprqIzWNdbJQ O2LvCnTDnF4mKWYX7C8or+a4uU3GGG/jPSdJNazzAvxudzyT+v7HGoPkV3pziQ2ck0wjUkaa r2Muory2DOx1zqXH8V6ec9+x9bDvoHvm9O3F+39Uhvs32b0jVsoW/ags8B+VPAV8M9Jx6vqt wHmypzuHgrU4m5w9f2nIObFR2bx/YMh3YIdtqzE2En2f+2fITJZVZfCHL4J8Ar4G0WXauwnh f6X96e62qe2ER7p5B3Wvp8cqF6ePqU75l8BjINbzMtzgLFLFITTW2/Y9oTFZSFw1FvHJPheU uUE8gXHG6g3WBZNBX5GrFriC9yA3Tm9G8BDSli5X7Wtxyq0HG7wUBKM92oSR5jHBA7MtmBrG DJeSAqRjQRB+FpwHKz1e834v08u38FD5VK/P55COQfot0iyPTchnuPccWrjPoMbKqZvp3Q8F MyA4FelHLsHeLiVrXZx2X3Ep+RRpgodXLvg0rp/4vn7JfNAvjAVgscdAjxdQN9djnMcVD47V VI/5Hk94ZLuUXHUJbvVY6zHSwxuX0vEg/UETj3iPuDDuKUto+844dPfo4eEvizO2arxXhFHg caPr7cLgnFjhzolga/f3wus7c9UfMmfD2gnucCnB6i552SV4uCwloxRYwwtxTnjXRer63pPZ KhYpQwdpbE6Sxs4e+P/9y+aKWsNt/plbKtb29YLkUXIpz1ByKDMoT1OeokynTKNkU6ZSplAm UyZRnqRMpEygZFHGUcZSnqCMoYym/IIyivI4ZSTlMUomJYMygvIoJZ0ynJJGSaUMowylDKEM pqRQkimDKI9QBlIGUPpTkij9KA9TEil9KX0oD1ESKL0pvSgPUnpSelC6U7pRulJ+TulC6Uzp RHmAcj+lI6UD5T5Ke8rPKPdS2lHaUu6htKG0prSi3E1pSWlBaU75KeUnlLsozSjxlKaUOEoT SmNKI8qdlFhKDKUh5Q5KA0p9Sj1KNKUupQ6lNqUWpSalBiWKUp1SjXI7pSolklKFchulMqUS JYJSkVKBEqCYFIOiUzSKn+KjiCc+m2JRgpQSylXKFcplyn8p/6FcolykXKB8SzlPOUcpppyl fEP5mnKG8hXlS8oXlNOUf1NOUT6nfEb5lHKS8gnlY8oJykeUf1E+pByn/JPyAeUY5X3Ke5Sj lH9Q/k45QjlMOUQ5SPkb5a+UA5R3Kfsp71D2UfZS9lB2U3ZR3qb8hbKTUkT5M+Utyg7Kdsqf KG9S3qBso/yRspXyB8oWyu8pmymbKK9TNlJeo2ygrKf8jlJIWUdZS3mV8gplDWU15WXKKkoB ZSVlBeUlynLKMsqLlKWUfMoSymLKbymLKAspv6EsoLxAeZ4yn/JrynOUeZS5lDnfUVuf4U2W exjA808AsWmapCTpSNsXRUAsIKhABLSBQhiFDtoXOqBAW1p2IW0YpaFl4zkC7j1wIGoc6YMD cYB7i3uhgnsLKu7Rc6f39Xz16zmncOf3PrMJV4FbP5ynH7bqhy36YbN+2KQfdO0RXXtE1x7R tUd07RFde0TXHtG1R3TtEV17RNce0bVHdO0RXXtE1x7RtUd07RFdeySsH3T/Ed1/RPcf0f1H dP8R3X9E9x/R/Ud0/xHdf0T3H9H9R3T/Ed1/RPcf0f1HdP8R3X9E9x/R/Ud0/xHdf0T3H9H9 R3T/Ed1/RPcf0f1HdP8R3X9E9x/R/Ud07RFde0TXHtFtR3TbEd12RLcd0W1HdNsR3XZEtx3R bUfy9yQe0JpVzrkGOrPK8YL1HK1TOSNBO0dtZK3KSQZRjlrJGtJCVqvsMWCVys4HK8kKEuFa M0dNJMzJ5Sp7LFhGGslSbllCFpNFKms8WEgWkPmkgdSrrHFgHkd1pJbUkLlkDplNqnluFkcz SRWpJBWknMwg04lJykgpmUZKSDEpIoVkKplCCshk5Z8EJpGJyj8ZTCAh5S8A45V/ChhH8slY ro3huSDJ47lzyTlkNHeOIiN5/GwSICPIcDKMl51FzuQtZ5ChZAgvO50M5rlBZCDJJaeRAeRU 0p9X9yN9eecppA85mVefRHrznEFySDbJIn6SqTILQQZJV5lFII34OOklHk72IqnEzTUXcXIy hThIMtfsJImcyLWe5ATSQ2UUg+4qowR0IzZOWjkSYulCOsnfXVvkL47+JH+Q37n2G0e/kl/I z+QnlV4Gjqv0UvAjRz+Q78kxrh3l6DvyLfmGa1+Trzj5JfmCfE4+45ZPOfqEo485+oh8SI5w 7TD5gJPvk/fIIfIut7zD0dvkLZU2A7yp0qaDN8jrnHyNvEpeIS9zy0HyEidfJC+Q58lz3PIs eYaTT5OnyJPkCfI4dz7G0aPkANnPtUfIw5x8iDxI9pEHyF7uvJ+j+8i95B6yR/nygFK+KtBB 4uRuche5k9xBYuR25cO/13Ibb7mV7ObaLWQXuZncRG4kN5Cd5Hpedh1vuZZcw7WryVXkSnIF D1zO0WXkUnIJ1y7mLReRC7l2AdlBtpNt5Hzu/DdH/yLnka1kC9msvHPBJuWtARvJBuWtB+vJ OuU1Qbvy4h9jaVPe4WAtifJ4K8+tIS3KWwdW8/gqspKsIBHSTJp4dZjHl5NlylsLGnnZUu5c QhaTRWQhWcBz80kD31k9j88jddxZS2rIXDKHzCbV/NCz+M5mkip+6EpeXcFvVE5m8O1O5zcy eUsZKSXTSInyBEGx8iS+Q5HyJH68C5VnA5iqPIPAFG4pIJOVB71AJnE0kUzgZEh51oLxyrMF jFOeNpCvPO1grEoNgTEkSPLIuSoV/7/LORyNVu4KMIqMVO7Ej8bZJKDcE8AI5S4Hw5W7Egzj 2lnkTOUeCM7gzqHKnfhgQ5Q78XfzdDKYxwfxOwwkubzsNDKAl51K+pN+pK9yJ/6UTiF9eOfJ vPMkXtabtxgkh+eySRbxk0ySoVyzQLpyVYM05ZoNfMRLPKQXSeUBNw+4OOkkKcRBkrnTzp1J nDyR9CQnkB7c2Z07u3HSRqxEiCXY6awxEvnbWWv85awz/sTzH8jvyG+Y+xVzvyA/Iz8hxzH/ I/ID1r7H+BhyFPkO+Rbz3yBfY+0rjL9EvkA+Rz5LaTA+TZlvfIJ8jHyEfIi5I/Aw8gHyPsbv wUPIu8g7yNuORcZbjqHGm/ANx2LjdUc/4zXkVTy/4sg1XkYOIi9h/UXMveBYYjyP5+fw/Cye n3EsNJ52LDCecsw3nnQ0GE/g7OO47zHkUSTYeQCv+5FHkIeTlxsPJYeNB5ObjH3JzcYDyF7k fszfh9yLtXuwtgdzCulA4sjd9tXGXfYW4057q3GHPWrE7GuN25HbkFuR3cgtyC77IONmeBNy I87cAHfaFxnX4/k6PF+LXIPnq3HXVbjrStx1BeYuRy5DLkUuQS5GLsK5C3HfBUmFxo6kImN7 UoOxLWmXcX7SbmOTra+x0RYwNkjAWG+2m+ti7WabGTXXxqKmPSr2qD9aEF0TjUUPRYOpPZJa zRZzTazFXG2uNFfFVpr7rJst9dZNwdHmiljE7BbxRJojtuMRiUVkXESGRMRqibgivSO25GYz bDbFwqYlXBxuD8fD3UbFw0fCVktYkvZ2HtgT9ueEYLA17HCFlpuN5rJYo7m0fom5EG9wQaDB nB9rMOsDdea8WJ1ZG6gx5wbmmLMDs8zq2CxzZqDSrIpVmhWBcnMG9k8PlJlmrMwsDZSY02Il ZlGg0CzE/NRAgTklVmBODkw0J8UmmhMCIXM8Prwly5XVO8vmSryBwiy8E4tfxg7xB/1H/Mf8 3Sz+uP+A35bqzDQyrQOcGZJflCGNGW0ZOzJszvSD6dZg+oCBIWfawbTDaUfTuvUKpg0YHLL4 XL7ePps38dl8U8tCXeaNo0OHdX3Wqb4+/UJOrzi9htc63vCKxX3Efcxt8+53HXRZnU5xOjud 1qAT250pRoo18dKZYgumDB0RcjoMhzXx0umw+YIOzCRu7J9cXBZy2g271cyzF9mtQXtefiho HzQkZLFJbxGLuICtZ+JdiNcI4e/1Hp90F/x/3lFWmptbsLenZVpBvGdxVVy2xvuWJl6DJZXx HlvjFrOyqrxDZHtFh1jzy+KegpJKjjdt22YZm10Qzy4tj+/MriiIt+MhmHjoxIMlu8NnGVuR W90UacrNba7GS3VTc27Xb4wkkhjlJiYTv5uaMU78inSNLbn/+MVtYHYTvpr1ZPM/n/pf/5L/ 9hv4///qsOBHtHxMp3Wjpc66AVmPrEPakTZkLRJFWpE1SAuyGlmFrERWIBGkGWlCliPLkEZk KbIEWYwsQhYiC5D5SANSj8xD6pBapOY/1Nd9dFN3GQfw33PvTXKb3LzcvDW9TZomt0napjRt 07fQ0oRBhzBK1wIdg5aXwY7HbUfc8GUODtuZG+oUQUXcmOg2xgTEsb7ZDDZeJurmlDmsU5kw 68tEpVgmTi2k9XvTlKF/+d/Oes7n3l+Te3rye+7zfW4Ka2A1rIKV0APdsAKWw62wDG6BLlgK S2AxdEIH3AztsAjaYCHcBAtgPnwI5sGN0ApzYQ7cALMhBUlogVnQDE0wExLQCA1QD3VQC3Go gWqoghhUwgyogCiUQxmUQgTCEIISUCEIASgGPxSBD7xQCAoUgAfywQ0ucIID7CCDDaxgATNI YAIj5IEIBtCDDoTZkzjywAEBY+sIr9EEZOAqXIFx+Df8C/4J78I/4DL8Hd6BSzAGf4OLMAoX 4K/wF/gznIc/wdvwR/gD/B5+ByPwW3gLzsFZ+A28CWfg1/Ar+CW8Ab+AYfg5nIbX4WfwGpyC n8JP4FX4MbwCL8OP4IfwAzgJ34eX4AQch2NwFF6EF+AIHIbnIQ1D8D0YhAHohz7ohefgEDwL 34WD8B04APthH3wbnoG98DTsgafgSXgCvgXfhN3wDXgcdsFj8Ch8HXbC12AHfBW+Al+G7bAN vgRb4YvwBXgEPg+fg8/CFniYrZv9ACH/hPwT8k/IPyH/hPwT8k/IPyH/hPwT8k/IPyH/hPwT 8k/IPyH/hPzTPYAZQJgBhBlAmAGEGUCYAYQZQJgBhBlAmAGEGUCYAYQZQJgBhBlAmAGEGUCY AYQZQJgBhBlAmAGEGUCYAYQZQJgBhBlAmAGEGUCYAYQZQJgBhPwT8k/IPyH7hOwTsk/IPiH7 hOwTsk/IPiH7hOy/33P4A/5z6/v9AT7gP55VK5mOsYkN/GmdhfHMwBKsjS1iK15gZrS0m82k wUHX3LniDMNRtCvHitHwIiOak7IKnHlIUZLqUJ1+Ky/PT9OMgaRhK0Z5MnMucyqWOTdqT8RG KXZ25NyI7dIpORGLjwyPVFeRHJCznBbOYHDq1WAlVxcJ18fjNS1cXW1YDVq47Gu19Q0tfLym iOOd06+0cNrvxJ++upxvz+i5zWqyK64rUqxOs17HeT32Gc0h2+IVoeZKn4E36HmdaChtuCF4 012twTMG2edy++yiaPe5XT7ZkHlTZxl/R2e5Mke468oOXt/UnSzhHzWKnKDXp4s8BeVNgfld VodNMDlssls02GWpdG53ZovLq/0Nr8s19bcybSiLOjkubNY5WZCF2e7nWcnk+QHJRgvVdG4R Tk+ODZiwME0v8D/VWErRViGbdjRnj1L2mCqlkPZ2hYnaStRw6LJkkjxBn2o0k1uQmGSTuEPq MfU1lVclVbL7Ou1LdUtZMpm0JxKxWE+PnJ+QsZTjttEaOY6KR3umbje+rYfcbn225BE+wFt4 NRgO1zfQVJ3zDSofED4hki3k94ccecL6zNt38EaH6vWFrCRSn2AuiBQVlysWYSO9RS/Nchda BN4g5VHTxCt55jxBZyl0C30mi8jzotW0NbORoacOMiYQuquIRVkjezml+D02avPbrNrBjINH wqEYe/WnucpUqeJK4X1XCu+7XKYK7eIK7eIK7eIK7eIK7eKKw/jewyaPD2LNwnFUuh9X4jzW b82dzdnzu/1S9ny+36SdOVvK/ITpuIkzKZHL1dWGkjTl9dk6atNk6jUsYcnRZLZvExTrGckW rWY4OrXAy9FoYmqNojotghoIhuvk2vp4ANVzaf1cxFNtJaeqstbMjveWAvkb29fePX/i2fyy snwKf3zH2hp3dHZ5XXdr6URGaVy+oO/knM76gkWheXd2nBpvWjYnTBtmfbizpdzljwgPRvwV S+5rq1wyr9FurOv8KEexhXXeiR61qT1zduayZv9Eo7ehkxFbMzkmSLoipPi2fi9riuaqEs1V BecLWlVwvqhVJZqrSvQovkdamIdiLMDCVNHnWCwcoXJWx6qosjevC5EeHtVQbGr7tjdOVleF nBb9dbHUu3Ix1QLschZx2r61thIkTic6U6s2zt/86ra2xTtfv7/xjuU3Foo6XhBNoqWm/e72 rq3rGurWbl/RtqGj1mow6vkhm8ducZZFCpc8fWn3k1cPdbuKywstDsXu9DryIrFI65YTmza+ eP/scCysl4uQQK3LtqHL7MzPPpXyJQPk0DrHoXWOw4k9O+zYsMOD3TqOaJ3DlKnaKLnaKLmO UXIdo+RqoxzBd9s81Ebqs3QUpincq5vqkulaDE93RI820f6rJQzXNcC2rr1jz0xczN7+0L7z uzsGa9cf2HKod9OBexLcrn1X9nZO3ehb9px/7CODDy24Krc8cILhnq6YvCjcqytmSfZUyuf1 Wj3avjzavjxaIjxGSVvhk3rSnJwys2MRKo6kIqsjfMSau//W3B6tuftvzd1/a26P1jRXMxCr pVpPmowDwWAi1nKEjHgyGKmsL7HYmaaK3liXtmv0gDw11nPpGO7pOXktHtlU/E8P1DfIWkm0 HsmmRNZy817XCMK9gigZpMaVn1l+54FPJlvv239788a6iWFZFvIwWR43ue1G+8zu29ZV77yw p6tn/+j2BQ/e3qoYhZUOn0MMV4YXPXJ0/abjD831+ejTwRJHoSyKNq99wqGEfUGP1HNwbMeu 8efWKGqZEkQ1D06O0zJMahe7eSiZ355/KJ9nuSqxXJVYrhNYrhNYrkrsMDrBOHl8yEVtRltn duRSLHrt9oemH1Ny7jnlomWiM1DgCTrFPFcgvyDgFBXsVaczSKJwZnrFpj6VPorubWYHU7bV LR9r4cxVVfmxmLHS41HS/2ejare/qKRakoxahxi1DjFqHWLUOsSodb5R2wFmZqpA205JfYfJ k2+Oeaor9f7SDv/S6cdI0o4HSBx7m558eIrYrq3kxKxYPK49V67bsUr/YbxcY9u2rjjOS1IU ZT0p6kXJtCRLFmVTtmJJliK/RNmOnTi240caJ22VJXEfSYsmDdLMzfpE0hYdug0NWhQwVmzY UBRFhwVN3CRqA6z5kKLbPvVDi2JAMRQYhgwZAuzxYctauzuHurI9ZAP2hZeiRMP3d//n/P8H vQRchSSkTQzo6WArJI8GYxIRdNEXVYJxWWTX85zdr/r8bT47uz5BRF9MCcVkayZyNLYtGbKR ZQt5yR6OppTH3BHZsQnu4a9ft7ZYOR7aBBj3ysbzt7uSjnA68s0i93Zbl2K3yaq/QRacWWKG mBdXNbfbR2Gaq5uuTnP9C8L0UZg+E2ZbS09PDmHmQm68wA9zHgfewU9y+BMP07Z9vqXHrfFK +5xyj7CXaeBDeHexy+bNpgktwSSVSmmJQMD/X3i1ccF8KrWpI/5Zpz/sLIW1RMK/fjRWbWVZ VpSjoVDUK2bC86oWVSXSrxZzvSHCEvhGCcS84oQPkopdzWnsV+VnBna+MfnN361OhOW08u+m 21uCndG1XxeWDtWye36xh/0V+DgPJWdlsJt++y/uE9BjK9PJPHkxKVBqApWgQCUoUAkKlJqA SIKSishU1J/qcTjJlIp+rUKPucRIHdBhVgXBkQC/XfXPOVBwNCg2gDVh0V7yn3KCDsJvaarc J8byL598zSbHFSyurjDxd00fe2yq8/LAYi3z0x/PPDye5F47/ObxwfWeDZ3A1q3Byv1nFvc8 UnCt3UlPLNEd83bYcZEZY84bbZ4eqSTCf13CXZTMXZRwVyU8+VKdzV/txJTSWZEQBdxJFI1E 0UgUjUTRSIDmUmuPp07EK48bxDCCQ0DgcnwuSIsOIdQwdtyVOspUNWZo6+HuQhIItnE0fATl QIAUUloq1bQdu+BLtoXjPju/7O8e3jtwqgkLbEjurYZ3n5rREiP3l2OF7rTvCZe4vjY2q1Ty 598ZWxqJQtGJoAmQfG9hsZJY+90GxAta1MI5t+87MVp9eE+/z6UPzvSu/yGpci9OHQtahfWp +MAsVN/Et7e5JUuc2cXc/ICpQhh2Q7ytUkRViq5Ka69KUVXrbMbQc4bsI1M5Q4IMnEvmHJEQ vhvBhhbxePACr0TwOCIfsr3Y1VYjZq++vqrQ1ddYr7glMsU4eq4RjSmBpaUMuxQrkZJhd5Ap OJ/rRgvelaSSFBisE8flasTSuRCok86LFtP04AhuSxitdb3mue1BqeLJbJwPfrElFuLZ8M1Z pTHU9Aj/IyQJ3NLo8s9q1ROLA0E7GKHoys+enNxeG03m5o8dPzqfHzh2fq++OD0oCzzLCXar PTtW6y/OFsK5hUeOP7KQJ4/e9yOIkrH2UEcUphtrezrRVprNl2YGevPDe0/umXtuX7dbicp2 KSR7ITu1JlR120hHcWYwlx9aOAln5IZa/wKU3848eDVkYKKQkNr76ID/d+GjsUgQxlH5grdO 0qsqre0cWORfTTgf654bTULxTQ3Hm2EA4wH3BW9ziuuvN30T7pyixQIX7gURJgz+htwqiV// ZEOIR0SpVZYboxg66bvf3ubPgL/rzIqhHuomMazaGFZxDKUTQy+MoWpiOAlIjAFmzhgyXkBp TIBuOEA3HKAbDtANB+iGAx+yHswCq5gFUEI2+BMtqXnPfGRTN5gOqDA+0zclUiN3BQWJxuUt Lf/Mjufrpx9979kxMMZwqF0WMwund+0+PaebaOKyjfz+ux88PzJ85soyl2ji+OZv9750oDuz /+wiF9yaL9qhux0FKknmuKEmsbGlkySMaypM0jCPOElGIZkQUeq0SM0bbHuh5hO8Mbz4SAkp oVRHdD5k8TZSkLdckbykUQi4Q6ZWI7VaDcbODjMW8Gh2xeKWMJCDMdTKXuVdiqYG4iHJYeXW D4jEm25vjXttPDlFyDFOhNYVTTo5sQ1HSsJbYFzgL5lDp+hs+fojvoLPcejEDn4/9JoK91sm zxjMe0bMPRIdyY5wdluw4ICDK+DpF/DgCx7cDcx7/zBcjKa5GeJgUB9MP+1D/TQT9NOz7m8S 6K+zouGTgh8zBU+BHbheIAxk5kJPtatOIob703bS3s6rt3omh750TPNMls6SNTMy104erDVn hhv6wVo523C6HLT3g5CkBJilwPP7hM2ZKt9XaDQK+oQ3lWFttI4ARmuu4mmNhKOugfNzE6fm uoefeOfY04HemfLQ4V29DhEM3RoZ2fdQ4fDLe1Nv/XDsgZHogdnqiaGQwwEO7Li3Mt4x/lB1 6vHJjvHCbF9ETaiiR3Erajihypl7nt17I9hd6RxfGBkDuitA93PLSaYLk9RlkHZLvEhrokhr pEh54WeTV7FO/mlE/DpOXnoM507kr2NF6h5zHGVbDBvjbyn2xXnLtjqxXElNRsY9U2W4vWiZ NmsIEAbLG2lqk9lGFWn+u8sJFUbHL4BllQIBMy58nl96tabvGh/XRG/ED/FIsMqxkAJZKb17 5870kVcW0xf8hX1GbNjYoY09PTq8v6SQm6evvTAupfo7j0NF8TxUlGW76YtwWftj5/aEZ+bc e6d3nH1gyNs1kltfWVgcXHoKau5eIBbjfsP0Md+/2Gr6UWPG+IrOFn96H0O4RhuORhuORkcz jcKE9Ra+oNVZu+HMuohLuRk1Wpw7o8k6Yd+XJ7k/92K3tjl39mbqRLhoA2xrn+m3zcvGmHaj EakgRwhbhi9wI6FhRoKfdiDkxsVYi1UZ3L0/e/iNB/uqJ1cO6HNjfSGbwHqdbm3wnv7l5+JG bbC8r6I7MIr/XFIkp9Kheo2nVk+/+NH3Bjzh9pBLDnm1aDwdv3ph8dx+PaknRFnFOj0EXN60 PMakmDLzihGtDBB7pIzVWcbeXEZvL6M6yiiW8jVyh2GYbINalsLKUlhZWrFZCiuLgmqR4+P2 shbhXVCWlkuhSSh1ftU1bZlCOzLlVGmmrGZGL28dZraWIISrDVVxkKo2xtphtsS9aZVafX4I 2RMr9y39YDGdO3L+O3vOGVZfFDVle3v0mbEKKAgUVY0PGeOa0hTQ8vS+6XMXjzxx7YWJHaOs vZnK13aAdo48bYydfRC0NNqLtGpAawW6ms4UmAtGV7ZYKZ4ocjJWkxwDBLIcz2ASyiCtDGLM mP0NtHDn8pj+ls7qAOkyVluBp+LjqcbMz3ZzbTQ4HvnF45lPnudf5dnrPPmUJzzfmv0yNRm6 dcj1uIt12W61mgKr/Zvxagtu4jrD52gtrbSSLK1Wq4vX6GLdLMmSdcOyjC2tsLAsWcY43EzD xTEmndIBzKUEiNsE49Kh7UwvIdOhzQMvhc60DcW42IE+8JCH5oEM0wmZSdtk6ENnQhlmmsy0 QzJB7jm7Zx3Zpk099p7V7krW/53v/77vJ9p29JgiaqkPozLZ0GVicxqft4FW/EryqfhQlwQo TV0KOZ/OuQamRsXJSqeB1msoFUXru3YcFY9cPdbTe/Ty/oOvj8euUKdf6tudb0PDT8g7dGpH nG/h6WanxciZDHqng8ufWTxz4q2zm0rHfzHGzVyM1w5ksfcFlj5XnVefAr1gcs5mxg0oNZ5A VEtQ1EogciYQMiEj/2wuEQksLt0TLWYUIQPM465yS/BxYtBTMw9KmT1VQNVH305/IvdY+u3l ACgHPF6uW9OY2ZHMK+ou4dCkOo+cTUPzrrAQyHia39HqdWqL6R0tkiaHh9O+YjZjqXnFN3io 6tvoNyDHM3H2ZrVOr3OkR3smaLaF83u+eITNsQkdKN7j51pYes/e7+0IG00GTgCAAuvrr1EX qD+CPNgM9oF7Im+JlXGXlbWo5LLHzMFaOV1YXHqCISiQ/kLrg5v4VoEeQaei0WSBtRGhyZSg 0jSN2WOW8LojGtFJLE0LAp2ONWGMxQwGeQz/izGPGb1tLBIQ9WgNmBI01V39s2Hrxzw/3k09 7B2MeDZ+0F19/gPPCJAtsyA55uP3ZemPpu9icO0oXuCAwaKL5rtR9BtVDhh1hLHNJltBMKRB emazk7lI4VwW2WumSzrKnY1GJzQsLdtpXsWh0SnUTJFX1AXOdNbXmtrz6ubsfsFiL3Y96p96 Lp755pWjhy5NdJi9SU+yMxVw+zO7z9bCZTc0s2y9fmBPotxpP/B8crDTvnXf6ENP2KGbPTl0 IC9QJ3xu/87Ozae2dqyzWeIuX1zFqLx9uzbkp7YnA+KujDffnXY6ax1948HAno3DZ7bFdFpv /ZPdX/d0V9p3vejODj7d21NQaZ2xcDtf7F+XyGN+X0L5/TJy5hQ4PV/IwAhH+MspxOYIsTnC eA7bst2lx3Krx4qhx9qhl2RDj+8xQES3gCviROOqZiFW9Q84a5J8SmMqRLvwty/NeIV2spLl amh2rSfL+Y+nLmstsuc64pVEfrqEXjoRz2nFiss/rnzt5ZrXqfBZZRreW/KPbX/6A+VKo/8O VfpevPACVsrvLn0OR9WdgAde8MOFgm/Ed8RH2UiWW5HfOWl9sCrny7n+tuooaAW8jBRP3sWT u7wCKY9gusm4RfRO9yLMzzvNFQmf9x9HiRoSZ4muBIdgwWHbxWRELIT51QBwHRt6ovhvGQJq lpYLpmGiJxLOoT9U8dL9+mtwElXsBwlw/sZICgZIWEDrp/h7BxRhD+Ay9fiCamouagDkOUDq A0pdgBQKkPaJjNMJUnFcYxzVeKPdXbEiJ72ulroUVcqm00qelatFtarlWptIi62caVaUPeoS J8uemAOFfYrW0Rqf3dvpalZED2MQiW7YEDFNvrwtqmWMrMVoaTHTamtssEL9ei0cch9Moz7I gNdFQ6ELhpMwKVrgMIpH96TiksT+krh6g7RK9pe8rQqBNmAgGBhImxgIOAaCiQG3RostFgMY ErlFbG16dXuldYBV2sOSQ+2BwhZK95InpB4oLFimQQg+ozmgnFiRVdAQ2mzUtJZraxF8DpOm PruaH3Cb1uJsczjbeJ3RVL8FDxv1LbghKNqog5/WjWvb5Is/wZOMUUchU9UZHOb6rXqA5Yl2 wDzCjAfiQsE+Yj9ipwApv4EbhBLLHIFP5hnzgFQxIcAzWb6W2c61X418C/U9lHG2gH+IgsWM tQsrUtCsN8BayIGPU8/BgQYdWxY43MMc6WGOsFrSN5fLhk5drhSDZY7BMsfgD2UkmWMQvxe2 iCwc3pIPkY9tSNz/XJXIJUBCt+ETJLJmqJkbqqLwrRGNxWp+INZdidWcDfuPLUzJl7n3ZKVk c0QyJbUE+OR/SeZ/01Be1lA7IYv6niylnNbaUYrnjm/C3WP3crStoz+eO7GsrBpLq922zkzX flTp3lVKmGOjQ2X/zpMV95ca68ut0ti1V6hZFEwoSqfXvrR9pKWz2J4sRTgkvjXFg9AOpsBF 0STvID4QO1q9S8SFVu8mHhZdepz/ZVfC2UE2Kcmf0P0FYkzYlkQmVo04/RUFepwalp2JWJOC 9v9hT/xX2dMyiD8b/gp7WgEUAmgcuxOeBj9CCHEgBH4lthbCsN0CwywMGmHQAINaGKRhhIJh FXSRIcdFAHMR2XKR1O4igLlwWHd1MpCxOtDjVgyXFc8FVgt6yooxs95SMQAs3VkwgeEptE3O RQjnTFUfmhyvq4eBzNQ9BDJlVMRaRX5gQ3rC6NAZkmtJqqc+6jn+22NHfnm4K3f8N8fRmn1T yB8cqXyj5BUKB0cGD5Y88O+H3zo/tPE788fQWkXrdGVmIpfZNzNcnXkhl9k7g7C5VL9I3UfY REAfePX3SFS8XQxhCUNYwijqw5DqGSnE8FFccBQXHHXg21FcdhQjowM807Xe26ROoCnwZrAq VMwjOXRKCi8U5HD5XkOSkcZApebQMzgi952CAs3a5Jx4P73/p3vbS0XR30AWKy9Y6HBteDQ2 8f2d7W/y6R2iJ4+GwNKZ/vyubAt8ePIP58rmtoyvnle0sOkh4gxFIfacjuTDfG322rc2nZ3s 5cL9yfrPt471Tk5jJo0jtN4gaJ0XBQSXWx/FDRNlJBgwAJLIRW/Dz9BTaZk2aUKnNFHJNKFZ mgCaxqAxfKCi74u6m8zI8tVzLdVu5Pg3zMPY86Vobs8pkk8SzgrM1rPNVCNf7MujHhUMNhIn S72hw23mttLh6mAlhCFK7f/JvvaBTeWI1tLKW1tZ+kr/t0uFsayTz+woevsQdPV5BSl4N5zz mYbPXZ84cXu2zAY2hA8p0NX/tXVn78S0uGlmss8S6U/K6qS6ihBLg/3zU+th0ERIZSKlmxRy mQjrTJhcFiBy2OeRSQDMMtCCOBcQddFq0MR7KjxWHUnuJcOPLmfhxgHwWUIjkUijuqrS6LRa +zo/70ys7/GtlplAsSe3zuj1rzM0UZCasLlYnU6ntcZr2ae/Wys057pKIROlZRhds4AddXTp sepdVHEFvCsaOocKQyNDrwxdG1IXSYFFgkCRkAKtd3AsLhKxLpK8WFyEfxXd/pQ/ZRAwxQRM MQFLtID1XcCaI9yC/8YiIzI4FhlEKSqhl0H0eQXDNYPKEP8wyzxit7Dj7BRLZdksa+v9S1FQ h6u2j/9DebXGtnWW4e8737n6HNvnYvv4fo4v8SWO7aRO7Nxae5TQWF2aNKzrypqkncb6h5a1 oXQiY0OwIk1QQFx/dBISQir8QKiFtY24aVIl2FAqhqAXiU1ISJQ/0YSK6CoWh/c75yTtKv4g xf4utk++73mf932fx01GgHFdGwN/t6Cuq05JqniNs6LT7QdaGn9IX7pkGhmu8d6aDz8EPpCN Z643Fr+4b/Dg1GDEx/KyIFfaT472f3RHotiZO7C/UyzPr8znp8fLYYGAOvLxUrbZrfd3yuFS Z/7AxztFHJj6FMTbjIXylgH6M2En9FyzrzBcsrKVXU9OjhztDih6WFWCEVWLqUIkFjFyg8ni SMnO9k8+QWOR2XyPOc7+BI2jwz8vIy1X9TCverGoerGoeglZ9VhZpSRUTH91PTed8q+b00NU fQtu2V6jtGu4uOxYu7ZjaBB6HOsyzdHYAEdjO/vCnrbM5TTX2tI1c1xU7XLN/NizndRLQZ0T /eLnt4TaHVGRWD14p7XHzCdDIidx7NOprBqQ+L69y/uYgJ034ppwQ4BvsZICEy1u5O2eb2FJ 8klcIErv/W3oeK+RX4Im+GbHAiUgFymDipRBRZHqLKdIFVVHcuH7l91MszxULA8VGN93cpNO KCzWVrJaHkct6lUko9otylysC8KM+1lgxtEEDrG269U2pT5kWEd4/hEp7pSoZmt7g7wm6Kmw mdL4me86rV8IuR7FrE8P7lqZEkIWZK4ubSuCMwf2TR579Rkmu5WdG/+aXdrd99QB5vTWDsUn C5ppBfAZQH9bRblN6GZU6Foife+zcNqdpHHEu2fYG0MP5K8z6t6oweedFkxaoCo0XFRxicPZ EmzszOJ8FmfotJ3B+Qy2nV0b521cDOLPZnAGPFJH0sLTGRuyFlb/6EhAxYwddFc0Ehn6fAV+ mCl1M3K8K7sFEPB1UEWVBUc5VNw/TPWDizusKxWauAJ220MRP9QiDLNluH2VrGCGML011h8v pdOlWIDtXWc5LBqWmcoZEttjyX8Yn5FJmGlNIN9nJZ8ifPBjOSASVgz4yEFFlwh4QgbepI24 ojB/lxSRMKJM0R4Bj/EKoD2F3l1Fe6A87YSrgQvBM+VR3KJjXw0XMrhg44KFC2lcSOFiEpdY XCZ4fAJPjOOJKp4cwKodxjMq1WSqO3Z8QFfVhieoQW+bjh2FNhK6HXys63yPgtlWZ9VPqy+r rNrRI9Nqo9vXHf/GAB6gnw3QqqkakeljA2cGmCnYNR+XKMh/pkguXGu31wBJF++6Ww+Ro9K2 9ZoLNL+NMykKZAvyQuF/QP7QlHuF5Xr3iN8spa3+mEJ+xTA/Jf54OW0VYdW7z7HgLsxkVhfJ bYb5LSPpQHtLF5mbDL7BSEYmHk3RsAih4IOgMOckaWP5QYiCIUGSIULgVDfikgQR8kPhFRRx I7q1YkQfjVcZsmMvxKuOvryKhgAYDZhXp3WjRivGRA1HgY+XYTocxaZXGyJbWxEsUbb2U99K fzOJ8GgON2Us29Re0KjI8tBguZuTtVRX27YQY21Nx+DVXGgxhd3jb6UvEnJLRZE4mBYKzRYG VD1LZjgwRiIAPtktGkUrnQvL7K2brBzOJlN9GpZwtHdPxEbRTuVCPnbtD6xPsxKpPp2RevcH AobCEUEW8Cd752EgnGIE8BV8IWD4WcL7hN5FPAsDYeVQsLdIqweowBcBnzyaX0UJuOsIzfwE LidwlErAQhQXAs0AU5RwnLbk8TiOjVLgYtjqxnxG17eXnUV7PdPahtStuElLkzdD3Ku2jEIB mDPs3RE3DMqgSCQkMI0X+KEdcVtj+BcllfR+I6r5dDobkjiMyfu8lrWTeY3vva5qnBIK4DFW 95HD4WiAI2LQv1FjbhgyB31Ch5v0997Fy+ivKIF8l2QzidQ/rTndjBEEl7stY4u5eJkPmNqr nN+IGZrpw+xZOZqPx/Km/HVruFaNXRd8okMnbHwhYas8r9pUMf9i8x4+R77jeK/ERRS6yqxc 8aVz4ByD06i91l6jrRRa6KN2R3tkjc9JsZJll4Cr0ZJtlWLSo2ti2wMJWU4M2NkqHasbpYy7 kclUoSTFq5Tb34PznIAby8i8iHjI+svAR14iQEI4SuUNen3e6eKAewSfqO+arNHX8T312hS8 6DP6yWm8zL0AqEmA2h74pXv+/wc0rmA16tXodUFxklDCxstxW+d53ab/AffuEB/3axRG4kWV Q/X60KDpPRt7RuhHrD+UCscyOsszC6zfSIdBPLDcP/1BkRX8hp9f8QcleHLIj/Dmv/E6yzAv oSDSLiFBXsVJxKI6yBjn5Hwu4144Aw9mGcP4oG3oukHekIISxzQLuVyhLydpjro927uA73Jf QTmU7YQJLQeEClGiQsl9nIQt+Sxq1yGmTonEPCgf3YTMdLO3RigwLfcG+L2lhaWnORxIxfS4 oZDm/GjSGptvYElNRsykynDPvNk7dONm7xO/VzSZY3iRe+7tW++cPPmX2388xvI8pKZKT/Q5 ONEdOFEGNVaR7vZp3dN5dHydnkxHNNSy4yTcE1Z2uEekcduqKU19ZJgpFrxSHdHxneTo/iZR jLgeT/kxd3hxcZFl1KQZTmoic+w0Ezv5zq23n+NEnuFkTXkLX7h5A194U1J9cDqeXevNwvkO bsrkPHcXLaGhKzPzM6mZVHb+KhavHOzj2mON/dmrWLkE90P1tcZ6e62xrcfVa4+wqlXjHkjv 5pbybnlwhoW08KgCJ+d3Pv+DZyOYC8RCZkLlGHNwvlMNi6zol/yDs6fmvvat5qGTp08+1awd /upCCL4XDUdSQTaSfmyspgksoeVPHuwemdi9NJFoHTp15tShFj4x96XFUe42KHqWE/ziLd6I RMPZdCRlCKlc+vkjE7Nj5f7m3PITuz9zsMW/xYNZAqEq/o4EDVMN6NGgkVTFeDoer3+kODk3 WqoMzy1vbqIjgNMPubuYJxckhJKr6Cj4oiAzc5T6I4glHS8F0QzVOwz6L/tlH9vUdQXwc9/z t+NnPztxHDtOHo7j2HE+7CROcEzCI0mBUAIJISGkISM0BAIBQwZZCwPSaZtaYKJjwB9tBXSa 2JgYHxvQlHVbu1HQPtCkCVX7Y6qg3aYOlW3t2JCoIDv3+SUhXbYmFZs66T7r9+55N+9ex+fr nrMQK9yr2lmYV8JwS84K2kkISy8LCaSRgIHk60khT0IcKabnej7usrqYpLvw/Emn3pruxPog nVbD6RKt6lxU+iGHCQKkVCMgqQ6E4y1aEktqSYzjezRjYPUmjXDFstEkQQRk4E30zDPiilLT UhMHSk2HTyYbfjf1PezQUDCBqbjIM0JM37e25uNwTtuutBT05EOTpwo2281U8WabaL3CY1XG x9OkvqJEo1qb9mMa/mrpprPP7Ph2XzgycHZ4J45nBU94TlOkbUMNWnXtwtltNZgzub2H/3Gu Z8XJu8cP3VXGUz0vDLVVZTXvf23g678crvbXdw9+BX33NAB/TJsJJfAH2e/PIX4v8WeTPA/x u4k/i9CDLpOEFN3b6ekeob/UQtUdIUBVCyG1swqpCg2pPUZIVWhILR9CI5woCzkuushlpnez SCs6q1JcX6eOIFJHsCnPY/Ov0y2U4tuIK46LRHTYR8jcH+QtC9lGiP6cbjmqt2zu/WtKX0uv a+HL4fIPFPFNRbMQnqjhUq3JrDH9zhL1Ol2qdqvKV6NMVKrlYzqTRX+/S59m1umMFgMR7jky 8XzVmY2kUJNmd9mxKdHdMghGbQPtXPU2t8PuFo38bw+bNJacTNFlS9P9hNdoiEZv1n10wCi6 aSYbRG2/hD5dC4dkS6iShHNIyEvrYZmqNZOqVSZO6sVOJd06JaXu4oovlufjB+KqruOXuD1g TinHTKtfs5Wqc3ZckuLofCUXy526klZbfIQExzSUyjqlONAS92b4mpKBbqreB0qdO0k5tHTF FKSkGtUhdalOl2YsepDgT8Hz435MyLDqeZM17aMV/XF7dqy5oqanMZqGhZaG0xpciZUbE91f W1XiXPDV5DWu3GA1axfZsx1GvS3HmZ6TmWkhpq6DT60Jh5uqfb6gz2DPybA6bUKGP88V69rx WO3OA2cG3zLalbNpHeaEg6i/DqJ9FTpRZdlUZZ0kakClRGngRxW9RaneoiNcTDYtaQ0sWeLC vkumfVcAXwnQdkDG2YDMCx660kNXepSVHrrSo7qsBzV/QSlxMcDfO0/jW1BdU1C9XaCGc6AZ hISMjwnamCwuTRBRzWmikhnoZEJMiM7KEWKWTY2tRX+TJG1jqxMf1Qxhj5fejttSB4NSGCud yHVqKnrZM3Gezoj2eCptULOpyUKn1DJKfuAUk40nkPGZqYyYkcPzB2u3fXfjvK0d1VaDjhcs xlhrsqGut8EXbn26aSfaSq8zC8atdf2NBe6Kllh1z+IyE62g8ax2VLcl5c5nnyiWajsT9cnm YjK48kBfVYY3VxCwbvFnS/mSr7atrKpD9mF4ZDiyrHqfvLIq2FiZmxfM01o9TmumKDjQziXL ty+o6W+Jmzl9rHkj2nkt2vmIVsA4eUO2FFSRgkqa8wO8EicXU2FSpcYCjn89b0YFV13iRAii uoM4G6TWCApLy5Jle8r4Mi+NKS81s1cxs5ea2XuJKwfAXdQMfgH/DLIDpVesNrLY4XChuYrk tKLqO5KP+HzaohbXJIOtuk0NVhomtrdUO11edT1lslRQ0aiasNHYyT5mEqUKFdWqLIMWaWKq F+CPzB8+NzBnYHmlVafleINZbypc0L+wfktLSUHLF9trOgLZrlwvV2OwmrTp9gfevMZI8kQy To6v/2ayWsxyCWmi2y56REOW1y01rFtU+7m5uWnufM46SzJi6PmDDw5ruVjPXjxll6GmT2BE RaAOfiQ7QiWkUEtCGhLiSWGABEykgTqwRFXegGFmGYsw744oiUcbo/1RPhwlGGpFshEEQYIt QM/GG6pOb5ynOk3QeMKlCZrH7XT59gSpTMxP9CV4f4IkRriwLJTmk3z5Q0nSV94pbEU9G87p U0cnjQzM7jdp+4S5PbwqjnkLH8oe1rKiZzwoSzQP67kqVZaqUxp9xXjlRAss/kR6pGXnyS3h lnlF6UbM7QZzsGZZec++jiIudmj1wDdWFpRt+NZgy64uuUA846tbPXdeVyI7a3Zn3eP7uUvL Tx3btz5httntuW6nW9Ba7dbHd5/oyo0k+va3tr84ND/UtGnvy/OHzwxESpf2xhJrGvJp+UEv UjcZrnvm8L8A0FyeGu3RT4/u/f+M/kuPHsPvAEz2R4NZM0Fa52QsD6ZG+NVkrO9MH9sVBuPT YffPHEc7QPrm6ZHx0mScb0+PzN9/tsn68fRwX5nAMzIzsq9M4L03Qc7w1EiYx2f1/nt8wzMj 73QK/w2A/N9MpqB7egTb/3eEhqZPIdqw6NC/UnweoGQ3g8FgMBgz4EaK0i3I+QkizkdA3ydw dnpEsUaIvvPZptyEzGY8TMVRgMo0gKrFAPGKFNVHJzPHxmAwGAwGg8FgMBgMBoPBYDAYDAaD wWAwGAwGg8FgMBgMBoPBYDAY/z2AAwL0SgeeSlwO6DgTnUhNP4qL/4467ub3KGMb0sEP8O/z t/k/83/Bpw/UN/7Or5i0VAMi2MGlyAVIqTrfAI/hnb7bCd3QC+vh81N9M+GIldiIm+SQIGkm nWQV6ScDJEm2kyGyizxH9pH95HnyArlAXidvkCvk6ox/2xPquG2mK/8PLg0ZxnsXyKCFbPBD CIqgBG1QDjGIQzXMg3q0xAJohCXQDMugFZZDG7RDDzyJNlkLfbAOLdMPG2AjDMBmSMIWGERL bYPt8AV4Gg7CEckhZY2O4rf4IajuHhnfvU7dvelju6+ZYvdNyu5b1d2H4KmJ3fkv8+18iC/k a/jXlI939Gejvx69Pnpj9I+jd0EPBjCDDRzghZfhe3ARXoWfwp/gQ7gDo4QQnhiIQLLQi7wk QGSyiCzhfs69/W7Pu3WPMEimvvhPfEOA0+Pv9Y6v0cM9fBr778pItyrzIJDnVVmD8lFV1qF8 SpX1sItcotlAY6R7clWqTCCbe1GVORC4V1SZx/k3VVmD8k1V1qF8X5Xx/+Gz4CRIUIb2jcBs lJrQdk+iPyTRZkm05jacq0dpEO1I7z0404/SZvQKCb1hAD8S+kG/YvdtuIo+rcVxLb49hPde fLMe1w38k9yqZ2kgCKKJIJoqWNoNaQOXYCEWFoY0gaDIBbGUTW6SDCa7sruxECtbG0sre/+A CJZiJ/4RbW0UwbebCEFCQAsbq9mZefPFPR4HTBsxAUIijmE9qgKSgCBYRh+JfOHoZYj6ODew awhrwSyKu4xrZme7P7olbKRjr7ANgdE67jae38JLRc/FmRrRymQDM3VBB94IWR+vDOjkmtaq 1Q3alo41znQ91Y09MlZ5MTqh2mBAqfT63lHKju0xZ0lzp7bbqJfraiBtK/O8iSFxxOL7bEmR 5Z44z5Yz8lZlPFT2kEzITLnd2fuQaEIb2tPiUd/yyrMjpbMKGpg4oGNG2lthl/wJbZqQsBpk poFe5W8kSiNVRoiEjz4P+dvcvyVt0BuoTrGUJyjwPXRiAbaCZG7lIn8GPclHVVq8ul3feto/ KG6+5laXo0zdPZ8+BvtQujx5f/s4L7ws3cAtfP3RfAowACa8Q30KDQplbmRzdHJlYW0NZW5k b2JqDTQwIDAgb2JqPDwvTGVuZ3RoIDE3MTEzL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgx IDQ5Mzg4Pj5zdHJlYW0NCkiJ1JZ5NJRtH8evWTEa2wgxNNbIds8gxla2RPYlvSUPxja2mZgs Ucxk68nSIqGexlIhW0VN74PQSiR5oiJRWrQhJJV47lG9r/ec5zn99b6d97rOfa7z/f1+c92/ c93393MPQAAAloFkgALrrN3tbD30o5bBkU4A5DKc3XUpc4TfCQAQPeCYLy2GRdK1M7CDdT0A WMEgZnBE8SvLKgCUGgEQIgSHxwcdeDKrCcCuhwAgTEMC/QKeY+dtAWiB68GaEDiAz5JYDYBm N6xVQiJYcV3XxpNgPQ2AqX04g+YHJKpnAUiSgXVmhF8ckyiOcoF/nwvXkyL9IgINlfDxADSc AAA9xowKZN6YYOkAELIOgOXH4BrE4uSvQC4aXiXB4pALgzhywVih1Wkb0j7gEQLIIo7cZjjk gUQgyMKQEBajKYJCymIA5IfFaWIRaATHEIlAF7lDrpDWkgixRCGZCEwXpzPwB9GAAcJBIGDB lzl/QopLNkNL+qaYn3Nem/HZINLWBzubbefDbd5cxJFaDXHQEhAH+akIhUQgkaKgFewzNc0Q v2M+Q3sztA7C/6tTBBruiUnWhDSwKE+0MEHJisGMj6IHh7BI6jQNEplKNSQ50mlRjGhGEItk xYhi6pAVIOLX4uX/mWFE+bHojEiyIrSSn0cRZP6dd2MwWCSLHawQRhSdFQ8pSOOphhCZDEGG EDy2SOMpEJmiR/4mf0JHHITS0mNBYACKgxAFcByH5CAQoALZ1Mp8bjLpJKfOPRLnA70qqchS /WV2/rBDKW/+txKSeaJrydGSHF9K2B3LgPixqph2j/7J18fSiDnclKC6a2E7/ZX75E0fiSIO juZdbdYOKiwMUSvoNtZqXnZ+s1rr+hc4c6M8rQp1avkbuz2WIymiDYXhnn5VnMRiX+1Yh5cF 9QEmhS5EsqCKJLfixQFNmedm+TRJ382YQK68oVv6h7LxXOR1uT+aPW3q9iY3G7/xyHWq+VK2 M4LlVCvTmSekrgi89vvSDRs2SgiYblrY+vlEEE7wVA97k9f4BRMfKXYsun/mUk3y4fkzt5L6 ymSjvE1vNk4IlipBddjU9jpSLCF1CImCX/xSdjnEPgmxS+DTlEeg2YUQ+0iy2NZu5jg96riy 627Jc47ZCx3FUf/758f5wTuO4j/Dw6PCLVlTR2QM3l5EqNyPFZ/y9qVwjwt3mGMOZOS0Gz9X nJzwOqR1vsi2zX987l6nicmWijUe9HmViLXtnacfYRIHyVlmXDFmaMO8hLMMvWWu22pEfAvJ +ZV/Qu3pFW2ahqralwKLJX5VFaWVfvAgflRs71s+5VYVaUUR+MKRnn0WHI53nWl653aj6cVV aI5EFsqQP6wh69grjzz5LnkYVb91+uxgm9dYoN0NN48L9Sh1iYX9fROCObsvHrlWaaj1dOfT 8tiRmCLQHbq2tWfNr8MWEuUGoXKhAwaP7xLRT8tt0G1b9IwiHYl4fx6uJPOPXo+1628RPU8x BySM0w/t4Jb1FMFU8IU4KIevVMDpVIo/dFnw/q2j5TtT5H8WDGDfG1HgAROAAsOATIGlwXcY xC8SFN4ES0B6upMJkDhfCBJwXn7RIfTIYBZ8GzFIhB8UIAi4BQZEMCIDvjeG+7vGlCHFr43J Ls0HBJLc6cGR8K4kFyuLH1KBF7+rb1udDbVcv4rc/1HVwC625fPK4zdsto/fWT96N/NKmIOb /3QB8orjfbtwXRXzwOYuZZ7wBl7SjkGbptM5Ii7XVDUni17glVfesVD55F9we4XNyUP2Kwtu 1ekqXbHXTmQ8WK5gkkkVow42aUwHmWgjKAvzqzacOh+OSD/2+fdztCTOR+8idkpq9pnJi7ml t41OuaRKr0p3GoRmgNn09Y9m7Etpb8OpZTr6M/U6tbhd/gfigo7lR+PTaievTpH+6SyRRevQ ekCxWTHWYJ9n4uIu0xXkGn+6Or1tkzmX45IRiTlr0Jqg0uQWZFbg1Km5Wy8yxRZ753i3fRoy Mg2caEkfcv9GhU8Q+wNE4ENBFb0MwmEF4Q8aBiOAQv1/oEKU3yMBgVhAYyAUvEDy/IAIWgot 2SnfFQOYW2vf9V91KnS11im1pk1Awvy0KBoN2yhtiXUWGZNQWbPbXm2yq9GJVbJ5FWv1jrq0 L5UOuXHA8eXN1zIP6ddEShKnkFbXb6Z3zrp3XuY2bWJM0KwrrMFYXlthL/GiMHcFPvdev0K1 xq7xt6eiq3IeUbPN8kMbjSJ6MmqVvwy97KMLHchomn8MGvSnPiR+FJPQwbzWyDtkGaa+nWeU MyyAb98Wcqsp2SIsqLyB15Ctf3MSJZa4833PsOVQwvzjx1XzM0O9+Dpm38ER5wtGJYnad80G 9IX9DZFcdqjy3hlvWs6ZLQ3Ue76Znimyeu9N8os4y0p+2VenxSs+2VHZT7rQDK1IJUniVze6 TVsM+0AjB9Xp6a3MJ1NllV3JllExIjBjQmHGuH1jjJ9onOPiPyTUUh9hYM78RFd/B44eBMHE 0YOBA1EhCl/q8SXE+q+09i2P+pv8D1lTMoDLun251e7ordPG+tXK/wgbCL+kqMTLbXtV03y9 V+0yRXxfY/82rc9rNiks16zJwQ9KlkaqOyRJrbWoylp3dn0G/gE7t/oIttvLOsb71bs5kSdJ rFK9Dtaz8RG/4t0ons1Cr7lE75mbPvjuhEkeAT/nG6qeuiOTV92YOipdv//Se6kL/tveig8Z jylu3VebHH3FZuTw3ljfoy+qY1sNs/QkdQkD/u01shXO+cHVd0lUaPtwVvD6J9eJ03gXloXu KEYlVDHM7szBq+eoNyxPRnjL2Ffm3MveYx6Hs71/4lyK8pUnkwlBZ+1ZTWoWG4/5Sfo6QW2c qW5hZuKYp2Nsj6BnDPsba2Yh9vvFs5cX5TsWNiG2ZYlhpxTXZSe6znpszH8mfS90jz5GR230 r9HE54S8MloGkkr+a5tb8wtWos2gP6kv83go1zaOPzOGMWiyla0zdsZSZibboLEOQqYyRxKF sU1hpjHZsg7DKWtSTs4QWiQplRDJkCMkUq9CkeX1hglZUqic0UmpnM/54136vH88n89z3ct1 389zXff3un+GKGyuXq5O/GZfOp1qoKVFovlt8l+O4SYSxV+LeoC81KpFpVE8D5HogVrmDtxE 28RtQlkvL8m9hxihDFD6yzYKHK/5yWFwcPBqDr1oKzzRvzlAH2ljsovi4JMjF6sNgv9Lwtao mNMZEzW+JpQeTMi0kpwG1pEjn3qk5b/3yWP9E6k2//OTUx+21+yFXb95fowx/SuCsnv+9WS/ 0KNEftx6Cbl29g28Fb+K2y6YbcYr/pbKbQGvBqxFkTqJ8rTn+8qukEWVMsZHtGFPIwMo6QI7 m9Xttl7EaMYP57W4qty6ZdS351qsYKXOBkIc3mqxKiNvN7TwZE9I9a6ocwX2LVPFrCzTgXsu SrhnUdpW9rNtjYezOWVNLJK4w5XirIknNW25eUUnmsM0EjTZd7ve+fF01+gXT7a7SEmsZb9p jj4vzC/dk6b4oiTPDjdaIqISAq/VvHn2wN1UIy5tsrm0YS7TZmv42Efa8P442hDJ/l6BdHd/ 6kra6KKwaF0UWkcH8/F6g/5oYlBLJirm/H9lb6oo5T8LJSLAnEz19aLJWTjg5fAO9gZolIX+ Rh19bb2N5maW+ssDecQQf/ERDl60IDLJ628BNVrJS2rsCr0cZ4E7d71+zC5H6Tk2CAF7jLFx Cnmo0XUOmjbxYstCtUr4mYWhiEhMW9eWRKze1NtOQ+31/0hnLGi/9GXSpFP7Kuz6KpjTmwXA tflBgTp2rpPl/TYRP1VkhDxdRDDXmVkebI1S3SXaHkswbJvvnU0cMwYGO3rd5ySSbc/GGL0m m4z2H6mBEirph0eEhqxGi/wmO3xi+N+ub44QqwocgNnNeyyM5WKzDD5wRBrdER5OnQLE2A5D W9uBn6u13KRT0nnNu105DAHFTFguL9or8bg9wlQ+Pz3tPd4CT9G5itcrJhd6zWmbX5WoM8T2 CydNSScMErfLGmaji1cC6guQImmvNhk7qvUpv/GtAL2z7Y9sG8R9xR7KsL1x5k3tItv41Fus 0UuGpuYND/4t9tADqST3/wh7lj3RVyMo/3cUXgVQ5DAGTGh9e2+b5ZFNNe3aYTFRqkhT9elH 8unwzOJ9DnvV5sZqiTYXIt6IPRAUn9s2Fb8OCBiM/QmJL9DEYnooWXrO44o7U4k8ycYFLE/9 Wd1GcfMyA9yvTWvuHIxBTnsXoAdcXFPndu7sd+EcT8smw+yOtLcH2Wmv2d8fblGgsSeWGIVX klKuP2r5u/KgVDRZTXxWouGVgmaM5V6NmbnzDcE4RcrceU9mSr7HmsKNiAtDabioxZKUd5kv J99Drtzf2upMvzQ/LSYrg209U/r41kzpeGPxlCNiwWiy8bG6xa0alnGEt+T9a3IkgWaTLV4Y qfBrFVtqVaztFaROBSShaiePfQ0o4f2CpwhsQLlI5Cle1inMJ/9bTP0Y8fWJTihtbb0lOmG5 5g8QX9+B8+9480wvYOFKo5nNQcnGVmucA3u+SLxSE1MlStjZGDuG29y1FZ2OLDvm2Se7Pa6y zrY9ivftxKHbiXcvdFwmU71DVL2Hy8onmDfvj198L3pWcLeCmlabSZcjRCbohr+nvw3xac9k b83p2LvRz6PswHoZr9k5/I4IX6v7XewgF62IMmVIqeOe/RtIi9HhRuMdEOVt2GA61LXOpTNe T/NQE3wUgYWFB33I9gsI63uJS83MOQjfp06Q9HDD5DyMtddQcPHFJ/ZqxQlvvzZ3QzrZb1z5 N7G394SfMOEzjKBA3YYTYfktbnwveUviN5e/zdgTZxrnxMwIKJHVtG6hsMz79g9HqaQc+JM3 DBCS+0eUVj+h/xfyS5gPxt0wBMTQWwda0lTACnquCkepzxPEwRAhhADgABwCPABzwPRrafad rlsFUBnbRNB14durRFLy3KEgeBIVnzwRSKw2hvFuXKzY4cDcMIY9Vn7GUbA3qcxQpn3hUkFT +dUd8jIUfnLkAZ58Bcsxv1L/cIUKy0dx08lrb0OP6tZyIkeorvjT6Q9bWntS2P016vfDXzZd xnQk3LxHqtdtl5SvCeo1zLouE5gj/0tnaakoMWmGVedlk4VUYbkdXWt4V8wrxLqqrTjWgFDi 4dSLGhnB/jR4ZKobGzMnJp/kGU3ig5ycygKbax22/KVyEdzlNWfT281DP36dN0CoJfsZ0j3c elKCJSKvD96QcInv95OYiiGTBoct1YVHeoe99ZJnFE6yWkqCiTsMHtMsrinOohmQK1xIFYFB IFRMwg9UZV9pRRgfrwacByzNC+TGdKPEP8cbCUJDebiR4w5ayoJPwYTxoIX4BD4NAYMg3N18 sQTRcNTK3nUoxS8TIWhujo350Qi7E30CDqw34hN4f1rcs5lRiPJcMUUI7Ygi5qpHI4FtABkg ATSAAgRyH2+ADsgBRCAUoHItH267O/fNFwjNU4lW+svySg+lUnxo7lTfULlv8AZhgABBj+GY kORHrBTpWRsb1uiT7I6WHCsPNbP6bhMOhDhr33SidubdIimP0weE3lE8o5rpXX/UlIlwOcU5 3K3Mw2mjvqiuc7ZhWzoNuE3pZFjOj0bq6BY0e7GLwqSd2fsNcgROibtLug7NvDZpaJW7Z2L+ 4MPUhtu+eyNN4RetCCDSkK7q0BNKPKGGicsER2BtU3qQe6slqm3tjjfKyWZPDdaUXmwZI2ac S6uXiEoYk4k++OYBnF1mOqxPGGyp8Pit1ywoPEsWeqewvOKilr9lZy90TVJZ6KDzHv97nMmR Vl1OpbX3REjjO6PTZQ1impdE9PuPzl+Q9Ia69yfGgfbt3lpln8cAy6IYYJkvMeJDM8BC3Cb+ /3mKfluRvhIY0E8pmuuKklyZiYKfDSiIu+bnHl70Wm6p1UejMNxCi8Fu1nX+LhGvG2Rl2jNH dojxJ9rM5BukqHjIUL5h1lKKmJo9gv/BerWHR1Fd8XNnd7Ob3QQWyiOwFWa57H6kSQgvJWBK ttkHCQHJi3YmYrubBw3WtnzwIZTySD8aQhdoxSgUWoOKiCjI3aBlg5FGxNrykragVKg8BDVK WlpACpZsz70zu3mA/aNfZ2Z37vn9zjn33HPunNndcHDZ6axtIZI7pM/8d0YvLn/wh3TV9A7r +tKsoSt8NTefOr/12EZH4LUr35xAHZFl7OHHjOvL6m9Mf/jguEMzbAvWdty/3LiKLR4y9KOk vPwtZ1e+/tNT92z7mintW+5HDkxsXPJB674Xh344f/+hJ1fNnL/5wtOf90u/9u7YN5Zv3Ci1 Ny1c9DjsXbonkHfoxrbmU0nuoiNvfm96cWPrjWdc207+oHCeb92OFe99esl+ZFjasxUnFlan LFi0wOtKb0k7e271zb2uaWOTY8dHbD/96rAmdiszp9U2pP6FpuZX1JnlD9Q/cfXM4fPXcm7n zD7cOv3A6YdC9bUvrWpt/+7WvTuWHDDtmDTw5t6spZXYIIzTpFYwgcW0yTQegAzT7objsE8C C0h9zZKBvwOM50GKeWBnDCuWzMs2o0yW8ZGFzlgSdAI5aG6S3DKQLaLrtJn64E3m3cXchDqN 0HX8BM9fw0vwKuzD19ch+DNcJVYIQj38Fj6ET+Gf8AW+jM1kIPkqSYf/29G50vR9SDW0QRIM BojdirV37oi14/br0w1pRGmw0d2FxPrHOnpjnY2d0c5jSTawC1u7dBjRK6QjdkvK43LsPi5L DXwsLK6Ymzp3d27pEc48bHELYTE2vCXwY1gGy2EFrIRV0ACr4WeYixU4XgNrYR38HH4Bj8F6 eBwa4Ql4EjbARvglbILN8CvM41PQBFt0jstNeG4QLGeehedhB+zE+1Z4DrbBdngB5Rcx+zvh ZcQ0RJN3IfI0PIPo84hyLY7txpNBBJphD7yCNdPkuBSFNvgN7MV7C1bzNWiF12E/1rENK3tA YByJy1+uqX2/CQfhLfgdvA2/hz/gzjgMR+AoHIN3/ifmrQTCpePwR/gT7rUTcBLehffgL3Aa PoCzcA4u4K67fAd/CjXeR52/6lrnUesStKNmB2pqeprOGcF+IjycQNtzcJFY4DqR4AuI4YhX b4Oo0CZRR149Xp3nRJ55PXajzCu0PVGbXZjjXVhPLvHxZr0aL6NuBDMYz9/ds3ZMr46W71bU 4bngzFE9F2/rleB+9idsDwuuWdgdSHjtyqi2wpPdsnOmWw4vwUciM1r2NLYre1zjIurwLHMf PXN7AW217HNbjne34dz7KLdjd7iMmeb3z0QlPoOPE+OPdb4D/gZ/h+vi+wr8A/vJVbiG8ueI XEHpTrQ3cgPPf8FNuIUV/Dfc7ibd7sXcxtYXw25FiEQM0Nk16kLFx0hMJAl7moUkEytJIamk D+lL7Ij0ZGwJpt8dTMpduGSB9CdfIQOwXw4maWQocWDfvIcMI8OJk4zoxg1JMDIylIwkLp0b JCyHJGyHo8bgbrrpZAxZhN8ZZDTJxvFYMoHcSyaSSYhkoTwO5cnIjRH3fCjGfxCPwC3TJ9IR 9D8Au0rEE/jOtx+a/WCFqswqLystKZ75wIzpRdMKC6YG/D5v/jc8eVO+nnv/5Ek5E++7N3t0 VuYot2skHTE8bUA/e99UmzXZgj8RxP+ZTD8NBGXmDjKjmxYUZHGZhhAIdQOCTEYo0FOHyUGh JvfU9KDmnF6aHk3Tk9AkdjkXcrMyZT+V2VEflaOkokTB8TofVWXWIcYzxNjoFkIqCk4nWsj+ tFqfzEhQ9rPAo7Vhf9CH/iI2q5d6a6xZmRCx2nBowxEbRedFyKgpRAykUf7JEXwFp/JpmcHl D1Wz4hLF73M4narAwCt8sSQvMwtf8lweM6yRI5lt4bVRO1QGM1KqaXVotsIMITQKG/zhcAPr l8HSqY+lL7mYhkuuYZnU52cZFJ0VlSYmIMzkslM5fB0weNpxuScS0pEkl/068CFfYiJNyMfH gLFhhLg+p5PHsibqgUoUWF2JoskyVDqawZOdoTIpyJm2ODNwFmfq4kzCPEidvFT+oH49WpvG 6irlrEzMvrhceCEvM4M7WFlVy++hmjD1+bS8lSvM48OBJ6Sv1R8Zk436oSAuYi5PQ4nCsuk8 NoDmawoIyLwGc8sUYaKbsQFeBsEq3Ypl+308LtkfDvq0ALkvWqK0wPjYucgE2bFnPEwAlcfB BnmxKG5/WKmew4YHHdW4P+fIisPJPCqmT6VKjcqrRO0s/RxO5xQzCitcWy/tuDJfudllkRXJ YVB5tRCQA/hF83ORsGO5hMgrmp8rK8QBcTWcRdfgox5+UDC4vAWcMnBTb4HDqTq147+E5NBj MrmYpZsvOwKJmLR5vjQ0TZsHlC77a3zdAuzh1KQHqHu7e5wSz4U+MVpYeDkL4pTBhU8uYhK6 ERCvYprMoFhWaA1VKe4hT7HC18ZzLepbVEaLSioUUW19l5T3kDQ+R5MYOJGOC5IX92AgwxEv q5CnCjkhFvSiC+O0HLbQorIwd051hyDjE4SLTnIXhtbk9J+Aj2YAuxsNhKhslwPhUDRWVxmO eDzhef5g7WTugxZWh2mZkusQsZYqyxxL+FT9oYgUlednZWLvyY9Qsrok4iGryyqUFvwtK68u V5olInmD+WpkJHJKC/4D8AhU4igHuSBzgXsqRcEi9B0tHoA6wRoFIOSqKAGBWeIYgaqopGH2 OCYhZtQwj8D4gUVKq8UUY7v1y9W8PEvV2nBQ5Q8XDMJS4kUYoVOASXRKhEhJKcxKa/KZjeZz PI/jeRqexHEzbgx8F2JyeE8KByn2KdxQCjiIthUN3KUcjcXKFedRR4fqxK02Gz8VCkvOwN5v ck1Dvan8E0R4KqurCvE4YJbCbc2uwioVt23cIaoUsmT0kKx7QI2AsOHbEY2qsDZYQGFfhwKr U5mawSdV5qpiO9sZFNDJWHbNp8nNJ8pWw/3pOPFs4qNgdTXwWzLGBmWKhjhQxMlULUnmFIy8 iiJVFZQx20aoKsOtrvVSq0NDarAlGt014mN16CTwZRlctlQrSx6NDvHiY9to/kiaXGZV1YIX UoOugHPbmQ0jcndLpW6A2UGqkMeCVwOGylXf4G5KolBKF2Nn4UELT2akWaqrMITNX7O3IUJz 4sYW3iNsuo+DGmrmK0/BvBtc5dHYdvqj/5BeJrBRHWcc/+/MvLfGGGwijvjkRiiYM2CwIRw+ sLEx5rCLMQ3BmJsYXA5TLpOkxBA3hoYQoAVqkioIpKCQKBC1ETTQJhxVDpWUs6UqIYGkTYtI IYU4fv3PvLfLZr0VlrrST9/MtzOzb2e++f7f6xry6ZvaXYuDDkwk/pqBjWl14Y5D0/v0TY0K 97Yx7rq6qDaRJ7j7FdUmaOkEQ52viE3w/T5677eX7tW2+of2hH5ipWp7v+f7CFAX+S7aQuzB zlmNWot6NQJFkbBao96QjFiNvI56MirEjiCFpISs8Pz18jXOice4ZsTQr8lCnOiGetHNKaPt RZtN8sgEMp08RX83kqJOc9w+SLHPeV3N5LMSOcuwVP7Ia1ejg6pBvd3EtXMi0JUswMQHstSF 60xUmfwtYq1j+2m2XRZqK0/xv7t0Jt2D/TuICcVKx/MtRb2Djv7R6BOOmo+uqjfiwpFn8ahH irYqF9EtxdriXNWoYaiVf0BZJNQLqCVPq33opZFbOHYLeni2i0cyGUBGef5aWcp5u1EagVrD cQwWcagVcc5M2s60xWQMmULmkDX0P0w6qiUctwAQC5yXlcW5RDQanpVt3LaMQarqgFo7j9+f jMAOcgklD+Sai92Psfwd1yXqCn09aV3KtJVLkOXhI3awvwaJJMqzieo1bGgxQ5Bo16FPOEpx 3z9A62ZswUiPjsZ+jdwwhkbwGexHXVQBauQ05HkMD2nn+deRKOTZbV04tkC9T+pJAcYrP/Jb gtiEePsE4lu1Qrz6MKS9JIynw/D89pEwToXh+b83vhDxUS+FrP3l/e+sjh45iPfPQDzjPDEc 81+bU6MKnAZV7tz1fYNFvm+cH9Mm0FaQoaSaVJJl9EeRGiWxSGVgsWjtXPaolOe55x56DBkk lhk7SiShvSxHjf2M/q3vUWHsPWe7sYU8jwdR5mIfM2cXWKdAXECNi3OLdqociHEujkOLQN/6 xEVVYb1ox/Hvo5O4QbQ9h0QrjhryesuwRqOTv470bhl8zlVhzIjgM8jT6GjdQfdw5EHmpjO8 G+H0Q46HNLYYc3lXS+SrmCh+izRxG2UiG8NoM8RJZPg+RpLYzVz0Lcp8q1Hk2+BcFO+yXc1c 8CTH3iW3kW7m6TmgzcAI3z3O4xzxKmMvEV3EAbKPe5fB3DeP+WwD2atVu7GJfCrmN/NdlWk8 D+Y+ucv4dpLZYb7tZI6vkf3NZCvZbvyLyHw5if1YUkk2Gf9zpFJ2Zj+XLDa+l8lq2Z79JNLD +PaTBtHA5/kV2W98V8kVwRpDnCCHOfZT1hsdSI75njVNY6yPoxjLMPaq9n+XpRGVmEs7U9Qa WyIE5onUQL3iLNU1CJ+pXjWgj1tDNO3RmubWC02rtTa79ULTi6wNikwd8C4SAnovb6LQ1XAn Vs/Rui1PIF9rsKuXTYXa2tw7rad2NVZS58dZS5u+Duqi1sKHmOfbomtQy5hbg7p1ByWubrF2 iXMmGz1KQbuA7sgXMTWoJbtd/ZCrMcHoQUjutt7hMzCvWxewWP2NYzW/YU7VPM57OhmT5VE+ N3dOHmDOJuJLjOZ9rjH8kPXIFiiRj1UEIt9ZR5JNXrnGtZk/5HuM9Q7UhRRkB3PCK+iiRmK2 mo6xcgzveQ8IVYHlHstIb2snMkk246uVdR3V1jHWgEQ8Z85SyX+bs04TPbAuyBDemzgUa8x5 LsVmc54rPFbxjGYhOqRmHG8fQIa8jJHWUH7n4dWDE3StF6i3rChE+x9BtDlnnqs/NaSOi3bP WdepgdpLlSPK8Bnzwhn3rFlr1lt+jtuMQn9frrHQ1LMxdgV9laSIe1OEIn8R2zsxmvoQY8WS BM7XcZGETSY2unpk8LyPGA0O1EMpPMuBvHv56hC/8/BqnCm6flEx9GnKIU287PZqkvNkhxcr uu4K1BHn0EnD807g85t4YXzUqp+RQZhksy6yt5t1HrbO08Zz/ud4XP6T9csmMyZf1SGZ45O5 j7Cz+LtPcgz1n3sGE1u3mdfPedzUGuRUqv3MV1rvQjTc+oz13UJkqOWMveWo0tbTwGqta3od DWuY9nYaHrIOu3Fsl3laNY6MNfqzKlhzaJ1JQSutdcHcfJdnNg+ZOner9Rw/nt/dwAA7kWtN ZH8lY/JN97fkep73U8i3bbYbWSdVOne1NqsxaCdf4X/zYKy+pBG78DnZpZGHsYxM0aholPJ8 PiIvyBmolCXI4bl1MjE9BHtFd6yz3sBa+hYZv2d5RrO9Os9Yz5cojnO94zgQsIyraWRHwMoq CDmK2vSBr0o2+jayn8T+Y6wBhmtko3Nb4x+Jn4RC313+z23BO1fD56hBufg59pCp1KQ0skBM QyWpECuxlcz5X+OkrpsbMZOUkx+oU5jMM5vKdgpJ912htj6DVRbzv1UNRI0B/ANItmvtg/il hrlygfU7DLIuMkcc5Z438l3lCEbQ34XtcbSTVSnGs32AZLOv2xWMiw5sJ8u/oq9soP7+h3e4 AcXEsocgPWoGc0UjkvyjGMtDkcC4nCCusF67xXE3kcX8nyK/4DtqJvX7GPqr0ShkO5drppNt pJSUkAQykxSTSeQxkskYLhUHufd7MUk+y/fXs7zHdXhCfohS+QR6yk+Yn/7MPNnAOrqBe9GA iWQK0c87i+SQXDJM0+z5slv8fD0iPZ/sz5iwkCzewkhxiPXIV+gu3kSWuMYabg/6sT+C7TRx nnHzsalVCnwnUUhy/5+51PX+nNtTVGGAWM55K6h1CzFQrMYjopxr/hQpYjHjvKXjLjj9ZCqG WRvJNpLl2TKyldyj3mj2YLj1d3IDw20/a7g3kM12tlWFVOtPjIcapFtrMdb/Fc+kEYPJUFJM upEpXnuSjjEyl+SQEh3bpL/1Bd8R09HNfov3cDxj0Ie2vFNNut7QdYDWTDuT+WAeyUEa79xW spEc0dhvo9p+2xcVsNFrsNXuhXVqLnr7LrHWIWx7OJfJlfv9luLb79ZDQaywfjM8TdXkyuvO DXKU/MUFY6mpqWRTUDMjYKfQbotAOp7X2J0i49ZVLvffL50z5Beefc/z0TqnyamAL0RfBig/ 98vvHCEXXZBPfUnSGnP/nca5Rf5I/uW2kcd3kIgE3g2sfs2YoW3o+4B5n53L+xuoAf9LepkH eVFccfz9pnt+v90FOWQFQSAUN3IZAbkNLKesLrLlBgoXxJVwLYLlEl1IhIhki2ARDqtQiARM mYi44AGIiZZcGjBGSTAxARNUJMYExUJAgQUmn9czA7/9sZBU5Y9P9UxPTx+vu9/7vmHBZ7Ar Kj+L6o7BVxFfal2aPhSzJFgHj0QlyEDiQVOYd0EPHkBHHiC2hmUvrfMfrRlbKQsUf1HNpGvJ i+dOz9xlztUOmUQO5nSyfxMaZws+dRdQqmbSnE5jl+atdiZzjEi+fBHTQK41OVJuGnLPSqXc 2wrLef8hd2yylCde4N2X9t4JSt7tKr7p96fQzCfC0lzFt4X4mxfwjeUyQ/u0T/HPW+RXlVLf GyfXoTHPKtyF2iHEfTA7sLNSuzqaQyiJoDrE/EDx1hMTQ55QEu/Sfr3Mr8Y8cot5Ms20Do54 y7A941KfCw1cvqXkRmNqnqX5k4vH8NOwTuT83wE1fu5MyPkOIec2KtG4ufT/COU1oO9iVoXQ 5lxEdjoX2jGW2kHXEI+ZiU1Irk0khmlv8X86rnLBXmH9HsUckz3x9zhfo36teVEWxP+niqUf SAbfSe5DA+yrVjcg8aG0cPxTWitySroqXkpaOrKlp5JYjc8E6lo5sqW3YrKJpZC4S/o7CqWe Y5ckHdskSzHtiM9piATLyZfENoloGBx2NJFa1UgEQTo6RmwjtYU/hnOvuctj2LGbfNt+QO7T TOqSB2l9X/zpncSv22lbZCqD9/0y4sZvOLeTyFumSH07kdyiKT5zCN/Ur07j/+b8Sx5j9qJX yUfJ3RrrnXO5J77Vfg/fSZ5rjpCrHZOhxP6CrIOyOKu3LE524L6Sn6SOwO3cW/w9+dEg57cj 35xOHBOS3YP3/A7035j5TZCy2M8zhmS9Gfat31K59Plp6Bfs/uCLMJ4E77DOIq/l+UrGKua/ vvqvfTjYxjrKGae3jqXz1XzMb8W/vYnJn0u3OB5lxhcXI/YTD4cGB9Ba9W1O8Bzasq9dIbX8 8VLXbpcm5rNgmbdLDHnXSLuaus2Scushj7wAeZ5fi/4zYMw5EfPhZviRqQzX6OZ4kWu0ZF3E xWAutlkcY0ocPWACTNJ8M8b5zXQy15cX5aEPV8flpJmw9+nUuI+vEpcgNUA6KprDOtpHZyVm KZr1sFxt78GmjOezBvt7xj3JXvQjZ6skx/oXdculg+Zd9q6gyrzs4mM++d8Ib2FwKjnD5WVz zV/wLQ+TzxxGc/COXhvu6vugIb7g3BEjbFPJNV3QVX/GxrOkLXbqn5pNXx7a6bu0Ja6TE97t 4nUUg6uRQp9FOiHZDQ0wKzhIznsdY+fFcd48S9ysFZRqv/rNzeF4sD3UDMEnoTY4v5dxytAB R/UfNOYs76/YIJ+7zzj0cT3lKO5vvv0WffZhzrHmuKAnovHQAN7TxKuzrH8vd2e15CfXMHZJ 8LHLUXW9c7j7VejcCeIraj+TxV58xR4ukx6q5U0bNHUzWWn2y0q7iVhDvunGzA/tG+e9zvaZ XNRCynAtiZON4/VHTLb5+C2eWXuPiKm6bxGlxO/7qbs3oiSpmjYifR6ODDvE9dhRKYOrsOsZ Z4OLGC31LIQEB5Vof2+LyrFuD95CX4H/NVoezAbyQUV1VxdJOLt2QW/omL8N1rk2+g2befUZ Q8/2cWninQ4etwuZW2fW2J9/TuBj7iGnOSrtTAHndCVn52v2pKkstB3RZW/LANuBOayRxv5I Vz8QPVZi9+GzV6BdxgTvcbfG0DbXK5cK7yx+z5eK5FKZb3fzDV2WbIkGe5V/26CPZrr9L2Bf fdVI9uNQn5nT6K8l3INFnIVF9P1jGZhlpCJrCfdwE/01wnfslYrUFO4fetGrFwyz6y9qu2pE 2tMvDg7ZJ5mb4rMnkXakf4n71m9J+rdrYTcMC94M9Wiwmvnc5tU7/xJj3cd/2e7/NsEq1jHV VgbfuHkzX/oI9V+S3Ig1xHo2TauG46Iv3be35Q4PVabrN93kRttLmtOX2B68L0G7TeV5g45F m3eC42YNsaYb+d8NspYx1tpnZSJt9rp19mKckHL6HWuX8ZwBfXaALnA7NIehZgzfQttUpJGt Jeu9GYp0H2OYryLQHponh7MnEc5u6WSu+xxzAN3/iOLoLAyK6GRmBt+4Z7VJGjXuL3ZSkouk o2KttFWchl8idd05WkJOwFroI0fbxLZ3di8KnmQ+onPwu+qe024p/3DWsUuBzaFuHjpDeSMq Yx2vzytCklsi3o/KWN/r8z7avAsb8PPPX5lUO2h/Zbi7Dznfdis5kPo+7qxZGPm/u53PG6X4 rbmT0yQP+tiR0BN/XiS17XjajHAMN3+Sq81H1IX+5SHnM0qlnmOEzMbvzUUHNjC9pIFnafOc 83mzI/BrwW7n36bALeSIO+AZGew/IXn4uWaO/a4M/d9amQ0Nzb/pV8HnJY4GO72hwVFXrgk2 4v96QVv7ItpmgxTagTIr9nfOj22WOsxHY+UQjUdmI6B5YLgriQV+Z873SebUEx92B7YZx9hP B8/jy5uafqL6JD/+J7mZuHRO8lN3Sr7fkn1ISiN/DfGqhD07IXPs67Tvxrn8Ukbbcfix8dAO n/JgcIBYO4qzk2Ne5b6VcFZKsOcEzhA2x3bTvHsZ7xD35Yy08LfIrXYWfa2T0bQfbBdxvn4i BX57yUq+LoXm19TFsfMDlz92hwpTxBmvwIfOpO0ntHkcn5vNuerLOZ/BWS2WPthxIP77avKQ CvRjjv0+JX34T8v97PO1Lh9sxDw1z2zHvY/zzK3c//+WZy6Ocs3TcqvLNzXXjPJMl2Nuk5vI MYd5JzljnXg+KWP12dsNr0gX7wfs54PwpFybmCMjve3YajptTrt2vb3Bcr33KaXCv4kz6JQq vn3AWrXdL6Wx9wx1X/E8l3P5N+lp/og/3ildXX9CfVXULm7zBfaM2iR/xrn9UOrgf/JNZ6mT KpNcv5A85DVJmUnorv7wOXSG+0B1U2eZyL7dlOROetM5+6ulAXuXsIfQhNwZd+Y3Sr63jli4 hbtUyvkaJmVJ9ALxI473ZcTlW8z0YCeasqHtQowulCH2FbTLPv6ZBvVlBHc3vKP1ZZT3gJTq fda7YPcQ6x+VAd4/pAAb9fJmwEfY6EHpnviDNE3sCKrUprp2zlpu4iUpxB7FiVPE387kXq/x vEmKveH42OmhzU0nfF4nypbEDWxvttJfH/RVjtT2GnBWR3O/bpCB3hEp9A7DDtbfR7p7P4ff wS/Qvg2ZU1Vo88SCYL/aP/E1OWht2Mw410kL71fSKPEGmn8Q56OelEIjmKb5oOKtxHYrZbw5 K4NhEva6UfFG8W0KTAaeOavhs9b1RvvBhT7Wy/wMmsNj0DDxAPPTdT3LXHScerIiEzu6OtQN orwcXTOhvZZtMqG+CeUlUJ9HWROZ87hcu7wrzKOm+raUl/D/zuMK/baivIQrzC+fsib+13lc zs6tKS/hCvMooKyJavPgXJX8h/YyAa+iuuL4eTN3ZkKIQDHAByYxYMAAfuy7EGxYAqElYTVA aCkIsoMxhRYh8ImmFQxIDKtsFlBArPJUxAgoW2MxISJLQIQKSHBhEcFQyMtM/3fOffDyqBg/ Jfl+3/+euevMPe/ccyV6G+QLy5DvISeB/aziI5dVNEr6q74Td7Ez0Hnw09a0GnWkWCIRjzgl El2jJdLHXWK4jVWdDkncuLoVMVTGSOnHedTJcwy+H4D2XHnkfC4Ng4hR3PbccVyuohyIv/39 IBxzOTyfawcSHkTQONpMnIHAGEPJoiMliYGIc35tijtKU7u7VH0TcnvZZhyFGTuQi+cjJ2mJ dvEoJyKPycGZmEMdETuriyJqYO7F2dyBhok45zt53rs5EGsT42WcadmI+fIczcM4FxGPP0HO kIC7T2XnuPij85r4Ej5bhHMPebKb67F2Qr4XJULtllLdvHgP1tSfWhj9UU6ntsir3BxWHHNy xDG7N2gALsBeCR0EmoHzsJMB6pBP3MTtk6LaXFD2zT7mWuQca50cc62dApqBC8oepOzz+jk7 V3xjp4PxAeVxKD8Ohhphdq5Z1U4HE4w8e3+QnQ97NEg1wvC9b9WNR11BkJ1v7sI9a5eda+21 08F4a4ZdEGTna/XsXL2+nQ4maCfsgnJ2Pbf+cTBUq+cMAbOMMfZJsw3maGPHq/KToCvKL4E/ iHi8U6w93Fhgp4PlxgLnAdgEIkQs8kFgpDmGGWcvAIONK/ZhI832KXuIccM+BHszmGakUU/V djpIRl0hnl9Geaay91tdqafV1TFCqtnTQbKVbxdaXe3LKM9U9n6Ri7ztLoM8NkHRLaB8EzEY Plwxhv6Mtm575PmVtUQnE8wG42GHKlsyBoQrhoFL4CnQQtWN9uesP0ocPeYygtJ/ghBQKehZ P/CELCMuJN0t5H3wbmCGgZp3BvfTTDAI/Pb/lCfJu+uviZkIBt0Z5Gr1tWrOXJAGnoJdJ8Ce DKqAqmAq6ipBV4N4MEq2R6494E7IGOpSQJXdWHuXVZzCvL8i5iKw+s5UJOZXJA7fFsfS7IRy cSzN7l6Rs6Mi8bwi8TA499CXBeUZgblFQD5xM39AnqC1oBWeS7cw/o5zfi5Vlee9/jfE+UmU ZdXBvfY4xYmrqHsLLEfsb4z8YDi+2aeoT4EmcF6hl+CcV+cDzvW6pgH7Y/q9mOeSZXaiKIlW D+UNyD1kvpFCoe73H4qx0c5Kgqqz2mzlHNTPUTejCyVLZB+spbL+LcUZbdGnLecrfkQS8ok/ IX75wXi402WZI9T75FG0GE11xQSKNZ+jjiZRQ9GGGlrVKNQKx1gNsMf3Uph+mQYYXRE7tiA2 W3gH3CN1k6rpr1KGGYe7l7wnyrvnw6AWxs1CmxyUf6AM4yp0NnIemQdFUiW9EP2A0DB3MeJq HHJa0yXDMKimy1lqJqqh31QKF6nQlQBtjFNUVX4r/QrdAxLMljiDLGoN+khkP32sU4azqRHy ogyXgJivz3RK9X24S/r5ihpoRzCvV72PTdH661hXL+plPky9jCepEdo1MptRuPkoxhqKcZ7F O4xFrj8Ra7uO2FUbviNjRl3HgZ9kmvWoub6IEkU71MWBMOTlG+g+5HqZRnvUz8OzAyrHQ64u Y4EbDwZTAyMJ+eNIvEsLkIr2pyhagliWaRyl5uIR9N1IuhsziwHamS9CVVw35junEZt7Y1+T JbIP1qLrc3B/eRPtJDLWFTF6MWLREarlB+P11utiriL5Plj3EPiPALWpneEDs/BetSjRbEW6 OdnNQ1NEJt5hEc7DbKyLiEKAX7U3ANQzAM+qQLeBpYD8f87noD7qYiT6MVqq2851vO9YfJvH PO9SrN6FYsVe4KVi3efc0F6gDvi9JeN7Jbm/sS3wpSo0zHwa+ziboq1U+Pd9+B0upYfMSNxp plN1+TsMuYh4O8MpFe9jf09RT3EDYz6IeTGG2Zram3WplfEXKjZWyHmon+WhbdCBoq+nSPSl HYJwNyLPdsZfdkqs39Ac+EVnzJOFdXQWr8B/U9DPoipY019Fe/hMY8enp1JrfT+Zog/O0Q7w Nf/9Cmj9g9jojJSIL6i7dRW/xdPONWuJc8bKpoFmZ/wuW+NZLDVEvIm21uP38D3O7Ck0VZyl miH7sO/vUbJsKxExyCV20gPwvQyxEGtKwnfSKMLMhc+PQtw6R1P0685BjNMD/tHDTIXfo70e Tz3N3fjdl2CfF2P8EfCLvtTcIvjG8/C1ozRRTKY6IdPQ5kGcLbsZ16/z3HtpIb7HEN5ju4+n EO81iNZ58rD/07BvYU6v0NX0tjhM2dphmi1B2QudLJ//FES+HuxDZbX83uTG/GUB98SY8rY2 MOAc2M7f2Uj27MFdcIS/rWyD8yMKwx0CJ7Vn8BuJCRrzRwj+u7meCWyLGihHsO2SDRIU2Qrs vz7Gbf4M6IzvdwP652CMHHsiWGDkODVwXxWgBt9dQXCup7gt31LoBc55BnEoMJ8IyBvwnaeB JDCYKbWxB/gpl2J/Sz9ju9QXoA6DYjlKy5iy9bCbMGWhjG8GyED9Gca3SbERbFDzS1opWioS FFMU3cCwIGR7fHXfHOhENd9lxWKwlOdwmQzWqPU1BROYsn7c3h3nCjipGAVGghOKJvweci3u WJJxCll+AnTnb+q7AM6pNQPfegXGLVsFEEV9pTy3S7wiI2B+yXzQLwh4lG+Jwv/sA/QdqRiu KFb0UYxQzAIzA56PZXxfM2UfKuYoHlUMYXy7g0gDHRUeRW/FvYoqikSm7B3oAf4WvhLo7xT+ PW/K+AoU/u/rVSxS+7tOEfh8IVilaBeE//ka5XsJPK9vbRAb1H5tVASNI33F9ZdVt/qUGYp7 GF8XCX7Dw3EvCFVEea5RmsxFyjGJaptbqLYbA3/ZP22upG/VrnujIu/fqv3XG9UYcs0b9RCk hOUHlqtcd4Wt71kus3zHconlIre8wHKeH37L8g3L1yxfsZxjKWY5y/KlN6oS5Axbp1lOeSOr Q77wRtaG/Mcb2RRykuUEy+csx7nJZ2wdYznKUsRyhOUwyyGWgyyfshxg+YSlkGU/L6KAJZ/l Y5Z9PO2/ueVHLHks/2LZy7KHZTfLLpadLB+yfMBj7mDZzg+3sbzPksvyHstWlndZtrC8w/I2 y1ssXpbN3ogWkDdZ3vBGtIT8k+V1lk0sr7Fs9EY0h2xgWc/9XmV5hWUdy1qWNSz/4O4vs6xm WcWykmUFy3Ie+iWWZdx9KcsSlsUsi1gWcr8clhdZslkWsLzAMp9lHg+dxd2fZ5nL8j9y6zwu irqB4/j8Zrhhd1lcFgFhVTwjF1RQEZP1WldRDmGUQ8Fb1HRxl/FG8CrrUbGy0wwzO7cCRitM Uyuzw0wrs8M8KrsjrOzyou/yfT1/+m/PH8+++Ox75ze//c3uzKDcSe4gG/iG28ltZD1ZR9aS NXp8GlhNakkNWUWqyUqygiwny8hSsoQsJhqpIl7iIYtIJXHrcelgIVlAbiXzyTwyl1SQOWQ2 mUVmkhlkOplGppJyUkamkMmklJSQYj12ICgik8hEopJCUkAmkHySR3JJDhlPxpFsMpaMIS4y mjjJKDKSjCDDyTDiIFlkKLmFDCGZZDDJ0DtmgEFkIBlA0kka6U/6kb4ktR1F6B3t2ErhoJ30 ITeTZHIT6U16kZ6kB+mux2SCbiRJj/Hf0F31mMGgCwc7ExtJJAmkE4kncSSWdCQxxEqieQQL j9CBg1HETCKJiRiJgUSQcBJGQrlmCAnmYBAJJAFEITIRRGpHtJHr5Bq5Sq6Qy+Rv8hf5s/2w 4o/2byR+5+Al8hv5lfxCLpJW8jNpIT+RH8kP5HvyHfmWx/tGtyaBr8kF3YobTHxFvtStg8AX 5LxuHQHO6daR4Cw5Qz7XraPAad3qBJ+RT8knXPpjcoqLfcTFTpIPyQdc7H2+7wQ5Tt4jx8i7 5Cjf9w6Xfpu8xQ//JjnC472hW4eDw3zD6zzQa/zUr3KxQ+QgOUBeIfvJPvIyl97LpZu59Etc +kXyAtnDA+0mOmniYRtJA3meSz9HniU+8gx5Wo/Gv7viKT16GHiSPKFHjweP69E5YJcenQse 06MngJ16tAM8yik7OKWeUx7hlO3c9zBnbuPWQ5z5IHmAb7if3KdH54F7+fat5B5yNz/SXZy5 hTPryGY9Oh9s4syN5D/kTt1SBO7QLcVgg26ZDG7XLVPAbbplLFivW0rBOu5by5lrOGW1owFe NI2ytRpdtvMRObbX0KvoEDoYPtGmoybUiBrQ8+g59CzyoWfQ0+gp9CR6Aj2OdqHH0E70KNqB 6tEjYRW2h9CD6AF0P7oP3Yu2onvQ3egutCW0wlaHNqNNaCMaFipflS9LEyWbfAVWSDZRo3fw /zqu0qP8t1YV8epm/63lIYtIJXGThWQBuZXMJ/PIEJKpR/oZTDLIIDKQDCDpJI30J/10k/8+ 7UtSSRQxk0hiIkZi0HFRmkUECSdhJJSEkGDd4L/UQY5S+DNqQT+hH9EP6HtcznPoLDqDPken 0WfoU1yWT9DH6AB6Be1H+9DLaDsuxcOoWdTyTC/Xzf5bfhlPzlKyhCwmGhlBhvM8DCMOkkWG klv4laOJhXTws1dRFFl32HYdUGRpDzqMFEXiZ1lBCnjVJ/CT5ZM8kktyyHgyjmSTsWQMcZHR xElGkZGkK+nCD9+Z2EgiSSCdSDyJI7GkI79mDLE6tsFr6Cq6gi6jv3GB/0J/oj/Q7+gS+g1X 9Vf0C/oWfYO+RhfQV+hL9AWu7jH0LjqK3kFvo7fQm+gIegMdRq+jZvQSrviL6AW0B+1G2/xX X77Gc1xNVpK5uhl/CokKMoenZTaZRWaSGWQ6mUamknJSRqaQyaSUlJBiUkQmkYlEJYUkhdh5 qvuQm0kyuYn0Jr1IT9KDdOe16UaSSCAJIAqRieBvpOTYCdvQdfQdTuwp9BE6iT5EH6D30Ql0 HL2HE70XrVe629YpdttaYbetcdWqq321ao2rWl3lq1bDqzOrs6uV8Op4sKLaV326Omila7m6 wrdcDVhuWS6HLXMtUZf6lqjhS0TEYpemFmoXtEuaYtEKtZlalbZVO4mB4F3aHu2wpjS3HXJE aYMynbXaFk22YL8sacLkH+6ihRudVS6P6vV51ABPmkfOvOQR5z1CTvWIPM9Uj4xZuz3dejn9 s9M91jhnpCfV4/Aoi1xutdLnVnPdbneNu9590B1Y465zyw14JTvcoQbnQtcC9dwCIe2X26RI dEhu05Uw9z75uiSkVvm6o03MxwmYhxMx1z5HrfDNUWfbZ6qzfDPVGfbp6jT7VLXcPkUt801R J9tL1FJfiVpsL1InYf5Ee6Gq+grVAnu+OsGXr+bac9QcjI+3Z6vjfNnqWLtLHeNzqXkuMdru VEcpA2z4H0RKxE9lYm3ixcSA8KkJlQlyZcL5hIsJSmWni53kmnhhiquJq4tTTHiS+RRri62L rY9tiA00tb9QIiqjaqPkSnOtWU41O8wnzOfNAZJ5h1k21ZnqTQ0mJddUbmo1tZkCGkyiwXjQ eNyo5BrLjW6jYjL6t5VIh9He12ky2AyO0SkGZUiKIcuQa1DqDMJhsPdzOgzdejqzInIjyiOU +gjhiOjR29ka1hYmO8KwozW0LVRuCxWSIjoLIYlIoIT4r5GItjlxP+62ikCBPy2aCguSk7Ob g9smZDeG5JU2ig2N3Qv8z478ksagDY2SWlJa1CTE5uImIY8obLRk55dwe/2mTdLwhOzGhIKi xh0JxdmNtXjh8L9owwspockqDS9OLvNqXm9VsjcZT6jMi5EqDT/tCDxDrcq/p8orYUryDR7+ GV4/Wvskr1auYQ3swLC3fdi/VdY+5UZr/KuPG36Tf+Mh/pcH//9+dCwvkwIl6bpXOR1olBQp WMqQxks5UuF+ySC2SzHSYHF0z8iRIX2CD2BTljqLo1KIJMR2R4cA2RAfn5WUHrRRyTePyQre KBdKWdfOnjmCp2NRGSnHRMqZllMtkdeOmDNSWk629E0V5i7m9ixGOTg4KCipq11O79ljQP/+ /YbK6Wk9kroa5faxtAEDhyr9+yXKiuW/I0Nl/7ZQTl/9h53yeW0iiOL42002SaNJlCKpMW3H trHF0vSHUCqtQhoVaWgtKUVP6jY7aYemu2V2WynonyB4Ej3oxVMvHkWwXoQeBPGuN/Ui6Enw 0hLwzbhIlSIKenu7fOZ935s3M29/8C5Fzjd7zI3j43PDltFfyHa2JhKRzo5U4RTLVKa7R/ty VjQRi1iJeO/oZPf8jamu18m23nx7b1sSbXsebfOFld75YqV3L0fP7W6ZH09fOdsT20gdMK2W xIO+jiM9w/kzlVQmZaWPZXP5eOJwOnnyot28nytkk8lsIZcvqL0KzXHQlzFBEARBEARBEARB EARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEATxM5CGxzhGQF2OHpWOww56Bny/ RoyroY5Aq3En1FHUj0IdQ/0k1HG4ZbxUu0RbMJI3L4TahLS5EOoInDBXQx1FfTfUMdRbqA3U WI/5PtRYT+QCbAKDERjCewzVNAiogQQPfKQOAcbKqCSs6tHGiEDlQhFnStDAm0EVY4uwhHO+ 9jhajtnrODqYWcZ1DcxZwJjADKHzONoAV6lMhhkMLcd91Gygo2o1Q63OddBbQSthGWPejzX7 z9b/6llURa7eS1XDYB49oWtQ58+hsrXn6zNdjA6GFXh7nqCG3hrOBvopVXZxk40MDY2xaVGT nu/VA1b25Kon7UB4bpGVGg1WFYtLgc+q3OdynTvFykxpdqrcX7YbYkGKgUmv4fxZKNRM+IyL YIlLZjPJF4UfcMkdFkjb4Su2XGaemtnj1vcvjwmX4TZs3hUBrp8L7ID7zHadQdzA0wfUvDU3 kIL7RajADP4NszCFb7j/l+9d1V91DSPq+/wucwAm8R028P3+yyz6w//jH44dBTtUpstgcAie Y08x0Q7CdYCDNaOEfcjQHcx6+PTdh/Kba5mJr3A0oVvas083Xym73XVP7r5t3m75HN9GV/U0 3fO+CTAAHR6UuQoNCmVuZHN0cmVhbQ1lbmRvYmoNNDEgMCBvYmo8PC9TdGVtViAxMjQvRm9u dE5hbWUvS05BUEpDK0NhbGlicmktQm9sZC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udEZpbGUy IDQwIDAgUi9Gb250V2VpZ2h0IDcwMC9GbGFncyA0L0Rlc2NlbnQgLTI1MC9Gb250QkJveFst NTE5IC0zMDYgMTI0MCA5NzFdL0FzY2VudCA3NTAvRm9udEZhbWlseShDYWxpYnJpKS9DYXBI ZWlnaHQgNjI1L1hIZWlnaHQgNDY4L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUg MD4+DWVuZG9iag00MiAwIG9iajw8L1N1YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNjcmlw dG9yIDQxIDAgUi9CYXNlRm9udC9LTkFQSkMrQ2FsaWJyaS1Cb2xkL1dbM1syMjZdXS9DSURT eXN0ZW1JbmZvPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShB ZG9iZSk+Pi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag00MyAwIG9iajw8L0xlbmd0aCAy MTYvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJVFC7bsMwDNz1FRxbdJDiNpthoEgX D32gdrIrEu0IqCmBlgf/fSXBSZCBJHjk4Y6Uh/ajJRdB/rA3HUYYHFnG2S9sEM44OoJdBdaZ uHUlm0kHkIncrXPEqaXBQ10L+ZuGc+QVnvp+/6KeQX6zRXY0JuStOp4S0i0h/OGEFEFB04DF QcjDpw5fekKQhXgH+zUgVKXfbdre4hy0QdY0ItRKqdfmWpDs4/zKOg/molnct99VI9L2hmde vunmwyzMyWI5vBjJFhzh7TfBh6yWQ/wLMADawWp3Cg0KZW5kc3RyZWFtDWVuZG9iag00NCAw IG9iajw8L0xlbmd0aCAyMDI5MC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSA1NDkwND4+ c3RyZWFtDQpIidSWeThUbR/H71kxGtuoxKixFdnODGKs2RLZl/SWPMMwjGVmYrJEMZOtJ0uL FPU0lgrZKtX0PgitRMITFYnS0x5CUonnjOp9vX88V3+9b9d739e57uv3/d7nPr9zn/P7nAMQ AAApkAxQgGbn5ejgbRi1CFbeAKCU4ealT5kh/E4AgMiFNRo9MoCj+FK9CICOZACQ++gxXJK+ o5Ej7N8FACvO4IREFr2yqQRA9SEAEoSQiHiGFdlhDICdMwAQpkKDA4KeYWcdAOhdC6+3JhQW 8FlyqwHQhucA9dBIblzH9dEkAHTkATB3imDTAxDI3TgA9k/CcWZkQByHKItyh88nwfNJrIDI YBO+VCIAXRAA6BEOO5oL3wfcumREPicqmHNzjKsHQCgNgMXHYA0x30UjUIqGR3kw35TCIb5S CFZiddr6tA94hBiykK+0CZa8kQgEWRKSwGK0pVBIRQyAArA4bSwCjeAbIxHoQi/IA9JZoBCL lycTgfl8dwOBIBqwQQQIBlz4sBR1SGXBYmh5WorlOTerjM9GLAd/7HS2o7+gcVMhf8lqiI+W g/jIT4UoJAKJlAbNYK+5eYZsl+UU/c3gWgj/r0wRaDgnDlkb0sKifNCSBFVbNic+ihkSyiVp 0rVIZCrVmOTCpEexo9kMLsmWHcXRIy+HiF8nL/5Phx0VwGWyWWQVaIXIRxEU/u17stlckvV2 big7ismNh5YvxVONITIZgowhuG1eiqdAZIoB+Vv4EzLiI1QXbgsCA1B8hDSAdRySj0CAcmRD M+eZ2birkqbgcJw/9Kq4PEvjl+nZQ84lwtnfikmWiR7FR4tzaJTwLpug+JHKmFbvvvHXx9KI OYIURu318B2Bar3K5o+kEQde5F1r1GUUFISuzO801WlcdGHTyuZ1z3GWJnk65ZrUsjeOu22G U6TrCiJ8Air5iUU03Vjnl/nng8wK3IlkcXV5Qfnz/doKzyyO0OVpmzDBAmVjz/QPpaO5yBtK fzT62NfuSW40feOd61r9pXRHJNe1RqE9T0JTBfjuozGN6zbIiZlvnNvy+QQDJ36qm7fRd/Si mf8SXiy6b+pydfKh2TO3k3pLFaP8zG/Vj4mXqEK12NTWWlIsIXUQiYJf/BJeGcQ7CfGK4d1U RqB5BRDvcLLMlk7OKDPquJrHLvlzLtlzbUVR//vnx//BO44SPcNDLySbsiYOKxi9vYRQvx8r O+FHowiOS7ZZYvZn5LSaPlMZH/M9qHOh0KElcHTmXruZ2ebyNd7MWfVIq9b2048wiQPkLAuB DCesblbOTYHZNNNpOyy7meT2KjCh5vSyFm1jDd3LwUVyv2pI00s+eBM/qrT2Lp7wrGTZUsS+ 8JdO/xkSgfeYanjnebPh+TVohkSWyFA+pKXo0qOMPPkueQh1fsvk2YEW35Fgx5ue3hfPozTl 5vb1jonn7Lp0+HqFsc7THU/LYodjCkFnmFVz95pfh6zlyozClML6jR7fJaKfltmjWzYbmLBc iPhAIa44848eb6t1t4k+pzj9cqbpB7cLSrsLYSrQID7K+SsVcHoVsg/d5/x+a2v6zhTlnwUD uO5NKHCDCUCBYUCmwKHRdxjEzxMUXgRLQPp4kQmQrCgQJ+B8A6JDmawQLnwZGUhKJIoRxDyD gyLZrKDvieH+LjE1SOVrYooL/aBgkhczhAWvSnK3tf4hFYTxO3u31tpTywwryX0fNYwcY5s+ rzh+037baNe6F3czr4Y7ewZO5iOvutx3jNBXtwxu7FATSq4XJm0fsG84nSPlfl1De7zwOV5t RZe1+qfA/DvL7E8edFqRf7tWX/Wqk24i+8Hi5WaZVBnqQIPWJMNMF0GZm121/tSFCET6sc+/ n6Mn8T/6FfJSUrPPjF/KLbljcso9demqdNcBaApYTN74aMG7nPY2glqqZzh1Xq8GtzNwfxzj 2JFofFrN+LUJ0j/d5LLobToPKPbLRuqc8szcvRQ6GB7xp6vSWzZaCvjuGSzMWaPmBPUGT4ZF vmu79i4DVooDtut4p1MakpUGTjSlD3p9o8IniPcBIoigoIFeBOGw4vAHDYMRQ6H+P1AhLcqR gEDMoTEQCh4gZZEghV6Clm9X7ogBnC017/quuRZ42OmV2NHHIEmRLY1Gw2WUtqB05hmTUFG9 y2nleEe9K7d40yru6u21aV8qnHPjgMvLW68VHjKvSxUnTiBtb9xKb5/2ar8iaNjIHqPblduB kbyWgh7iJUnBMnzuvb7lVVo7R9+eiq7MeUTNtjgSVm8S2Z1Ro/Zl8GUvU2J/RsPsY1BnOPEh 8aOMnB7mtVbeQZtwzW1Ck5whMXzr1tDbDcnW4YyyOmFdtuGtcZRM4o733UM2gwmzjx9Xzk4N 9uBrOb0Hht0umhQn6t616DeUDDRGCnhhanum/Og5ZzbXUe/RMn1SFA3emx0p5C8q/mVvrY6w 6GRbRR/pYiO0LJUkj19d7zlpPeQPDR/QZKY3c55MlFZ0JNtExUjBjAmDGeP5jTEB0nEu839I qIV1hIE58xOr+jtwDCAIJo4BDByIClFEoYEohLj/ldS++ai/8X/ImuJ+XNadK82OR2+fNjWs UvtHeH/EZRVVYW7Lq+rGGz0rr1Bk99b3bdX5vGbj8sXa1Tn4AfkSlqZz0hIr68qstWfXZeAf 8HKrDmM7fe1i/F69m5F6ksQtMWjj/jk6HFC0CyW0n+uxlOs5c8sf35kwLiTgZ2hhmqnbM4VV 9akvlp7fd/n9kouBW9/KDpqOqGzZW5McfdV++NCeWNrR51WxzcZZBvL6hP7A1mrFcrcjIVV3 SVRo21BWyLonN4iTeHeutf4LjHqYSrjjmQPXzlFv2pyM9FNwqsi5l73bMg7ncP/EuRS1q0/G ExhnnbgNK603HAuQp7lCLfyJTklO4oiPS2y3uE8M7xtrpiHe+/m9V5YWVSxchNimBQU7obI2 O9Fj2nvDX9SXeTyUaxvHnxljGSRb1hr7Lp6ZxjLIEoMQlTmSKIzBCDMx2bKO7ZQ1KeUMoUWS UgmRDDlCIvXKUmR5vWEasqRQOaOTUjmf88e79Hn/eD6f57qX676f57ru73X/To+IdvnEotk1 FEfXRtMyJzbJwcRAkei1j7nZ8gAp2FZQH8Tk6eRpJWzxplDIepqa+ABfDb+VGGrgSX6a5IPE 5VZNcgDJ4zCeEqhpas9KNA1WE2i5siTrHmIA6oG6KzYITVD/7DA4OHgth4SAVZ4o3x2gT7Qx 3kOy98qVjkVD+P4lam1QwuiOiZpYF0oJtsuyEJsBNhAjn7mnF3zwyqf9U1ll4ZeuMx931u6H 37x9kUmdOY0g7V14MzXI+ySJy1BEVLqDfgtrwaXougdunfmaq7Vqh//rIUtBZa0kmYAXB8qv EQXlMyfG0PBnkf6kDO7dLao22y+j1BNG81tdFO/cMRjYdyOWp0pro10c1mKpOjN/L2fRqb6Q mj1RFwptW6dLaNkmQw+c5Q2fR6EtbOfam47kMMqbaXhh+2sl2ZNdte15+cUnW8LUEtXp93ve +7L11uqWTHU4i4uup79tib7IzyXRly73sjTfxnC8VEAxhK9O/fb5g/fTDFi0yWHRJn6FNtvD mZ9ow/7zaIMj+hECKW5+5NW00QYxSG0QqaWF+nS9QX4yUeCyCcZc/K/sTQlU+LNQIvxNiWRv QoC0mT1WGmtvq4cEzXQ3a+midTabbjPXXRnIJoT4i4+wJwQEEfGEvwXUeBU7vqkn9GqcmeGF mw1Mm1z5F5ggBPwpysox5LFazwXO9MmXWxdrFMPPLY5ERKLae7YmYXSm33Xro0X+kUFdRL/y jg+QSBuotBmojJ/Zwg2tKwgK1LJxmaoYtIrYVJkZ8mwJEb9hm/mhtiilPYIdsXb67Qv9c0lM I2C4s99tXjTF+nyMwRui8fjg0VpOuyrKkTHeEYvxYt+pTq8YrnciLRFC1YFDcJsF90VmHiZb 7yNDoMkN4e7YzY2L7dS3th76pUbTVSI1g92014VB5ZbLguexIwlJJ2wRJjIFGekfsGZYktZ1 rE4JsYgwjza9LlqvjxnkT56WSBzG7ZTSz0GWrAbUVyBFBrzWMHJQGVB4610JeW89GNk+bPgN e0ijtkZZt9HF1glpd2jjV/RNTBsf/VvsoQSS8W7/EfaseKKsRVCuHyi8BqCIYVQ4r0hHf7v5 UY3aDnRYTJSSsonqzBOZDL6skgP2+1XmmXU4q0sRb4Ue8QjP75hO2AD4D8duUsYWqmNQfaRs HacJud1pOLYUo0Kah+6cdpOwabme4enmdfcOxSjPeBYih5xd0uZ37x50ZpxIzyHCbY52dATZ oNf5DIabFarti8VFYeXFFRqOmf+uMCweTVQRnhNtfC2rHmO+X212/mJjsKEcaf6iR3xqgfu6 os2ISyPphlFLpanvs15NfYBde7i9zYlyZWFGSEoS03au7Omd2bKJppJpB8SiwVTTU1WzO7U0 owhPsYc3pPHcLcZbCSjx8BuVW+sULW1lxc/4J4N1U8e/BRS/D88ZOzqgUCzwDCvlGOZV8D2m fo74+kwnEI3WWaYThmX+BPH1Azj/jjfPdfwXrzVtszok1tRmaWhPXygWrlJHVQva7W6KZRpu 6dmOzFAuP+4xILUzrqreuiOK/d3k4btJ9y91XiWSPUOUPEfLKybjbz+cuPxB8DzPXlkVzXbj HgeYZNAtPw8/K9yzvqn+2rOx96NfRNlAdTLf0HO5HBDeFg976EHOmhHlCrAyh30+G/FL0eEG E50whR2YYAqnS71zd4KO+uFmvnEEBh4e9DHH1z9s4JVhWlbuIb4DqnZi7q6o3Mextmqyzt7Y pH7NOP6dN+ZvSaT4Tij8JvTuAX9XPN8sNShQu/FkWEGrK8cr9tKELRXvMvfFmcQ5xmf6l0qp W7aSaKYDPqNRiqkH/+QNFaLM+iPya5/Q/wv5xc8BZ20YBqHqbIAsaypgFT3XhKP4lwnCUBgv ghuwBw4D7oApYPKtNPtB160BqMwdAsj68J3VAqn5bpwQvmQyNmUyEFdjBGffvFS5yz5+IxNz vOKcA09/crm+ZMfilcLmiuu7ZCRJXMTIg2wFsuZM3zK/cNlK8ydxMynr73Ie065jRI6RXbBn Mx63tvWl0gdrVR+Gv2q+iupMvP0A36DdISZTG9Svn31TMjBX5tfusjJBXPIsrZ5gla2sSHM9 tl7/vhAhxLK6vSRWz67U3bEfHBvDbBo+Ot2LiZkXkkn2iMZzwE5NZ0NNNY+Y/1q1BO0hzFv1 97JRTtxk9+dtzXmu7BZuOSVKE5DRhW5MvMLx+ylU5Yhxo/3WmqKj/aOeOimzsqdoraXBuF16 TwPMbsjNIamwayxIFUMhEDAm8Seqsm+0IpyDXY2PDSrBDuTF9ILCX+KtDEFysrEixxq0nAWf gwlnQ/JycH8eAoXAWLv5avEg+cDVvRtAua8TYUhWjjF9A+z2Jnn5HxQx4OD+cFbYo4VaBHqs msKLdABxearRysAOgAjggQCABASyHk+AAkgDOCAUILMsL1a7G+vNGwjNV4yW/8vySgklk7wC 3MjeodLf4Q1GhQA87qMxISlPaKkSc1ZWtPGunM7WXAt3lW0NvcYMGG7Otvlk3ez7JXw+YwAI vSd3TinLs+GYSTzC+QzjSK8CG6Od/LKm3smKbu445DqtlWm+MB6ppV3YQqAXh0k40X30crnP CLuJuYzMvjFubJN+YGz66OP0xrve+yNN+C5b2EHwI9pKI12kBLvaeMMsaATGOrVPeX+NaI21 zYkmaamc6eHassutTFzmhfQG0ahEpmT0obeP+OjlJqO6dsOtle6/9W8LCs+W4rxXVFF5WdPP vLufc11yeeiw0z6/B4ypsTZtRpWl52RI03uDs+WNQupXBHQHjy1cEvPkdBtMioMc2Lu92jaf CpUCqVDJrzHiQFKhvKwmrv95in5fkb4RGJyfUzTPBRRbnYk8XwxOCGvNLz3syPWsUquLBFGs QovCbNF2+oP1ag+Porri587uZje7CSzII7AVZrnsfqRJCC8lxBTW7IOE8MiLdiZiu5sHDdZW PvgQPsoj/WgIXcCKUSi0BgURUZC7QUuCkUbE2vKSVlAqVB6CGiUtLSAFS7bn3pndPMD+0a8z szv3/H7nnHvuOXfO7N6xEfdkb9owvbat6B7L6inXtmQ/4S53PNajZ/Et8mDu+73WH1x6OmNb iOQM6jXvvZGLSh96jK6c2m5dV5wxeLmv6uaz57ce2+AIvHHlu+OoI7KUPfKkcV1J7Y2pjxwc c2iabf6a9geWGVeyRYMGf5owKXfz2RVv/vzUvdu+bUr5nvvRA+PrF3/csu/lwZ/M23/omZUz 5m268NxXfVKvfTD6rWUbNkhtDQsWPgV7l+wJTDp0Y1vjqQR3wZG3fzS1sL7lxvOubSd/kj/X t3bH8g+/uGQ/MiRlS9mJBZVJ8xfO97pSm1POnlt1c69ryujE6PFh20+/PqSB3UrParENqn2p ofE1dUbp9Nqnr545fP5a1u2sWYdbph44/XCotvqVlS1tP9y6d8fiA6YdE/rf3JuxpBwbhHGK 1AImsJg2msYCkCHa3XAc9klgAam3WTLwd4DxPEhRD+yMYsUSedmmlcgyPrLQEU2ADiAHzQ2S WwayWXSdVlMvvMm8u5gbUKceOo+f4fkbeAVeh334+joE78NVYoUg1MLv4BP4Av4JX+PL2Ez6 k2+RVPi/HR0rTD+GZEMrJMBAgOitaFvHjmgbbr9eXZB6lAYa3Z1ItG+0vSfWUd/R1HEswQZ2 YWuXDiN6hbRHb0mTuBy9n8tSHR8Liyvmho7dHZu7hTMXW9wCWIQNbzH8FJbCMlgOK2Al1MEq +AXmYjmOV8MaWAtPwC/hSVgHT0E9PA3PwHrYAL+CjbAJfo15fBYaYLPOcbkBz/WC5cwWeBF2 wE68b4UXYBtsh5dQfhmzvxNeRUxDNHkXIs/B84i+iCjX4thuPBlEoBH2wGtYM02OSU3QCr+F vXhvxmq+AS3wJuzHOrZiZQ8IjCMx+Zs1te+34SC8A7+Hd+EP8EfcGYfhCByFY/De/8S8E0e4 dBz+BH/GvXYCTsIH8CH8BU7Dx3AWzsEF3HWX7+BPocZHqPNXXes8al2CNtRsR01NT9M5I9jP hYcTaHsOLhILXCcSfA1RHPHqrRcV2ijqyKvHq/OCyDOvx26UeYW2x2uzC3O8C+vJJT7epFfj VdSNYAZj+bt71o7p1dHy3YI6PBecOarn4l29EtzP/rjtYcE1CrsDca+dGdVWeLJLds50yeEl +FRkRsuexnZmj2tcRB2eZe6je24voK2WfW7L8a42nPsI5TbsDpcx0/z+pajEl/BZfPyZzrfD 3+DvcF18X4F/YD+5CtdQ/gqRKyjdifZEbuD5L7gJt7CC/4bbXaTbPZjb2Pqi2K0IkYgBOjpH naj4GImJJGBPs5BEYiVJJJn0Ir2JHZHujC3O9LmDSboLlyiQvuQe0g/75UCSQgYTB/bNe8kQ MpQ4ybAu3KA4IyNDyXDi0rkBwnJQ3HYoagzsoptKRpGF+J1GRpJMHI8m48h9ZDyZgEgGymNQ zkZulLjnQiH+g3gUbpk+l46g/37YVSKewA++//Csh8pUZWZpSXFR4Yzp06YWTMnPmxzw+7y5 D3omTfxOzgPZE7LG339f5siM9BFu13A6bGhKvz723sk2a6IFfyKI/zPpfhoIyswdZEY3zcvL 4DINIRDqAgSZjFCguw6Tg0JN7q7pQc3ZPTQ9mqYnrknscg7kZKTLfiqzoz4qN5GyIgXHa31U lVm7GE8TY6NbCMkoOJ1oIftTqn0yI0HZzwKPV4f9QR/6i9isXuqtsmakQ8Rqw6ENR2wEnRsh IyYSMZBG+LMj+ApO5tMyg8sfqmSFRYrf53A6VYGBV/hiCV5mFr7kOTxmWC1H0lvDa5rsUB5M S6qklaFZCjOE0Chs8IfDdaxPGkulPpa6+GIKLrmKpVOfn6VRdFZQHJ+AMJPLTuXwdcDgafvl 7khIRxJc9uvAh3yJ8TQhHxsDxoYR4vqcTh7L6iYPlKPAaooUTZah3NEInsw0lUlBzrTGmP4z OVMTY+LmQerkpfIH9evx6hRWUy5npGP2xeXCC3mZGdzB8opqfg9VhanPp+WtVGEeHw48IX2t /sioTNQPBXERc3gaihSWSeeyfjRXU0BA5jWYU6IIE92M9fMyCFboVizT7+Nxyf5w0KcFyH3R IqUZxkbPRcbJjj1jYRyoPA42wItFcfvDSuVsNjToqMT9OVtWHE7mUTF9KlWqVF4lamep53A6 p5hRWOHaemjHlPnKzS6LrEgOg8qrhYAcwC+am4OEHcslRF7R3BxZIQ6IqeEsugYfdfODgsHl zeOUgZt68xxO1akd/yUkhx6TycUsXXzZEYjHpM3zjaFp2jygVNlf5esSYDenJj1A3dvd45R4 LvSJ0cLCy5kXowwufHIRk9CNgHgVU2QGhbJCq6hKcQ95ChW+Np5rUd+CElpQVKaIauu7pLSb pPFZmsTAiXRMkLy4BwNpjlhZhTxZyHExrwedH6PlsIUWlIS5c6o7BBmfIFx0gjs/tDqr7zh8 NAPY3WggRGW7HAiHmqI15eGIxxOe6w9WZ3MfNL8yTEuUHIeItVhZ6ljMp+oLBaSgNDcjHXtP boSSVUURD1lVUqY0429ZeVWp0igRyRvMVSPDkVOa8R+AR6ASRznIBZkL3FMxChah72j2ANQI 1igAIVc0ERCYJYYRqGiSNMwewyTEjBrmERg/sEgp1ZhibLd+uZKXZ4laHQ6q/OGCAVhKvAgj dCIwiU6MECkhiVlpVS6z0VyOT+L4JA1P4LgZNwa+CzE5vCeFgxT7FG4oBRxE24oG7lJuikZL FedRR7vqxK02Cz9lCktMw95vck1Bvcn8E0R4MqupCPE4YKbCbc2u/AoVt23MIarks0T0kKh7 QI2AsOHbEY0qsDZYQGFfgwKrUZmaxidV5qhiO9sZ5NFsLLvm0+TmE2Wq4b50jHg28VGwuur4 LRFjgxJFQxwo4mSqliRzEkZeQZGqCMqYbSNUlOBW13qp1aEhVdgSje4q8bE6dBL4sgwuW7KV JY5Eh3jxsW0kfyRNLrOqasELqU5XwLntzIYRubukUjfA7CCVz2PBqw5D5apvcTdFTVBMF2Fn 4UELT2akWbLrP6SXCWxUxxnH/zsz7+1iDJiIIz45DAgFcwYMNoTDBwaDMYddjGkI5j5icDlM DdgkKTHEjaEhBGiBmqQKBSkoJAqkbQQNNAlHlUMi5WypSkggaVOhpJBCHL/+Z97bZbNshKWu 9NM38+3M7NuZb77/98aWMfm781vSkzokODmgc0RLb413XK9f//NY7rvsXvQ757epVV3CPr3T UrU46MBE4u8Z2JhWF+k4OL1X77RApLeVcdfVBVpFn+DuV6BVyNIJhjpfEZvgeydmz7cX79S2 +Jf2hH/aSNX6bs/3IaAu8F20mdgDnTMatRb1ahgKo2G1RL0hGW008hrqyYgwO4wUkGKy0vPX y1c4Jx5j7yGWfk024kRX1IuuTiltD9ocMoZMINPJE/R3JSnqFMfthRR7nVfVTD4rkbMMy+RP vHYl2qsa1NtNXDs3Cl3IQky8L8tcuM5ElcXfIlY120+y7bJIW3mS/92lE0kN9W8hNhwrA882 F/UWOvhHolckagG6qJ6Ii0SewcMeKdqqPMQ0F2uzc0WjhqBW/hml0VDPoZY8qfaih0Zu5tjN 6ObZzh7JpB8Z4flrZQnn7UJJFGoNxzBQxKFWxDkzaTvRFpFRZAqZS9bQ/yDpoJZy3EJALHRe VBbnEtFoeFq2ctsyFmmqPWrtMfz+RBS2k4sovi9XXew+jOXvuC5Rl+nrTutSqq1cimwPH7FD /TVIJAHPJqpXsL7ZDEKiXYdekSjFfX8fLe9hM4Z7dDD2a+RFMDiKz2A/7KLGoUZOwxiPoWHt Mf5qEsAYu7ULx45T75F6Mg7jlR/5zUFsRLx9HPEtWiBefRDWXhrBkxF4fvtwBCcj8PzfG1+A +MALYWt/cfc7q4NHLuL9MxDPOE+MxPzXe6lR45wGVebc9n2Dxb5vnJ/SJtDOJoNJJSkny+kP kBolsVhlYolo6VzyKJfnuOceegwZIJYbO0IkoZ0sQ439lP6t7zHb2DvONmMLeB73o9TFPmrO LrjOOHEeNS7OV7RTZX+MdXEcWgT71scuqgLrRFuOfw8dxXWi7VkkWnHUkFebhzUSHf11pGfz 4HNWRTAjis8gT6GDdQupkcgDzE2neTci6YNcD2lsEebxrhbLlzFR/BHp4iZKRQ6G0GaKE8j0 fYQksYu56FuU+laj0LfeuSDeZruSueBxjr1NbiLDzNNzQJuJYb47nMc54mXGXiI6i/1kL/cu k7lvPvPZerJHq3ZjE/lELLjHd0Wm8zyY++RO49tB5kT4tpG5vkb2N5EtZJvxLyYL5CT225By stH4nyHlshP7eWSJ8b1IVst27CeRbsa3jzSIBj7Pb8g+47tCLgvWGOI4OcSxn7DeaE9yzfes aRrb+DiKsQxjr2j/d9kaUY55tDNFrbHFQmC+SAvWK84yXYPwmepVA3q5NUTTbq1pbr3QtFpr s1svND3P2qDQ1AFvIyGo9/IGClwNd9roOVq35XHkaw129bKpQFube6f11K7EKur8WGtZ09ch XdRa+ADzfGt0CWkZc2tIt26h2NUt1i5xzmSjRyloG9Qd+TymhrRkl6sfcjUmGD0Iy93WW3wG 5nXrPJaof3Cs5g/MqZpHeU8nY7I8wufmzsn9zNlEfIGRvM81hh+zHtkMJfJRRSDynWqSbPLK Va7N/CHfZay3py6kICeUE15CZzUcc9R0jJajeM+7QajZWOGxnPS0diCL5DC+WljXUGkdZQ1I xDPmLJX8jznrdNEN1SEG8d7EoUhjznMZNpnzXOlRxTOahZiwmnG8vR+Z8hKGW4P5nYdXD07Q tV6w3rICiPE/hBhzzjxXf1pYHRfjnrOuU4O1lypDwPAp88Jp96xZa9Zbfo7bhAJ/b66xyNSz sfZs+spJIfemEIX+QrZ3YCT1IdZqQxI4X8dFEjaa2OjikcnzPmw0OFgPpfAs+/Pu5auD/M7D q3Gm6PpFxdKnKYM08bLLq0nOke1erOi6K1hHnEVHDc87gc9v4oXxUat+QQZgks26yN5m1nnQ Okcbz/mf4VH5b9YvG82YfFWHZI5P5j7CzubvPs4x1H/uGUxs3WReP+txQ2uQU672MV9pvQvT cOtT1neLkKlWMPZWoEJbTwMrta7pdTSsYdrZ6XjAOuTGsV3qadVYMtroT1Wo5tA6k4IWWutC ufk2z2w+snTuVus4fjy/u45+diLXmsj+Ksbk6+5vyXU87yeQb9tsN7JOKndua21Wo9BWvsT/ 5sFYfUEjduIzslMjD2E5maJRMSjh+XxInpMzUC6Lkctz62hiehD2iFRUW69hLX2Ljd+zPKM5 Xp1nrOdLFMe43jHsD1rG1TSyPWhlBYQcQW1631chG30b2E9i/xHWAEM1stG5qfEPx8/Coe82 /+fW0J2r4XPUoEz8ErvJVGpSOlkopqGczBarsIXM/aFxUtfNjZhJysiP1ElM5plNZTuFZPgu U1ufQpXF/G9VAoFRgL8fyXGtfQC/1jBXLrT+hAHWBeaII9zzRr6rHMYw+juzPZZ2sirBeLb3 kxz2dXs246I928ny7+gtG6i//+UdbkARsexByAjMYK5oRJJ/BGN5MBIYlxPEZdZrX3HcDWQz /6fIz/mOmkX9Poq+aiQK2M7jmhlkKykhxSSBzCRFZBJ5hGQxhkvEAe79HkyST/P99QzvcR0e kx+gRD6G7vJj5qe/Mk82sI5u4F40YCKZQvTzziK5JI8M0dzzfDnNfr5u0Z5P9mVMWEgWb2C4 OMh65EukiteRLa6yhtuNPuwPYztdnGPcfGRqlXG+Eyggef/PXOp6X87tLirQT6zgvJXUukXo L1bjIVHGNX+OFLGEcd7cceedPjINQ6wNZCvJ9mwp2ULuUG80uzHU+ie5jqG2nzXca8hhO8eq QJr1F8ZDDTKstRjt/5Jn0oiBZDApIl3JFK89SccYmUdySbGObdLX+pzviBnoar/BezieMehD a96pJl1v6DpAa6adxXwwn+QinXduC9lADmvsN1Fpv+kLBG3MGmyxe6BazUNP30XWOoRtD+cS uXy331x8+9x6KIQV0b8HT1M1efKac50cIX9zwWhqahrZGNLMKNgptFujkIFnNXbH6Lh1lcvd 90vnNPmVZ9/1fLTOKXIy6AvTl37Kz/3yO4fJBRf8j/ByD+6quOL4+d3d+/slASGRCAKBMihC FIIVEAhgeQmRKEjGFEYDYrS8guAYqoFWKEgzFIdGcAaFSsGOrYgBX6C2OAKiRWuVFltbsPVJ rS2KIw8FAtx+zt57yS8/g/3jM3vv3r37OLt7zveMIb4UaIxpzGmCw7AXvgifpYQcpFni3MAv +gaTtUzPB1w+O5X7G2vA0cGnsCsqP43qvoTDEV9oXZo+FFMXbIB7oxJkGPGgABae1YP70ZH7 ia1hOUDr/Puax9bLEsVf1jzpWrLx3OmZO8e52ilTycGcTvavRONsxafuAkrVTJrTaezSvNXO YY4RyecaMW3kQpMjNaYt96xKarznYSXvP+aOTZOaxFO8+9LDO0rJu13DN/3+CJr5aFia8/i2 FH/zFL6xRmZrn/YR/nmd/Kpe8rxJ0hGNeUrhLrQMIe6D2YmdlZZN0RxCSQRNIeYHireRmBjy kJJ4i/YbZXETFpJbLJSZ5uLgoLcC2zMu9fnQxuVbSn40puZZmj+5eAw/D+tEzvwTUOOnT4ac KQw5vVmJxs2n/3spLwB9F7MmhDanI7LTOduOsdQOuoZ4zExsQvJtIjFae4v/03GVs/YK619T zJfyWvw9zteoX2+eliXx/6kKGQySwfeSe9EAe5vUDU28L10c/5aLFTkuvRUvJV0d2dJfSazF ZwJ1FzmyZaBisomlkLhZhjjKJNexS5KO7ZKlmO7E5zREgpXkS2I7RLQNDjg6SIsmJIIgHR0j tpHawp/Iudfc5QHs2Ee+a98l9+kkrcmDtH4Q/vQm4tf1tC039cE7fjVx43ec26nkLdMlz95G blGAz7yab+pXZ/J/Z/4ljzF70Kvko+Ru7fXOudwT32p/gO8kzzUHydW+lFHE/rFZ78nyrIGy PFnIfSU/SR2E67m3+HvyoxHOb0e+OZ04JiT7Bm/7hfTfnvlNkerYzzOGZL0a9q3fUvn0+Uno F+y+4PMwngRvss5yr+uZesaq4L9B+q9dFGxnHTWMM1DH0vlqPuZfxL8DicmfSZ84HmXGFxcj 9hEPRwX70Vp5Nid4Am05yK6SFv5kaW13SAfzabDC2yWGvGucXUvdFkm59ZBHnoU8z29B/xkw 5vyIxXAV/MTUh2t0c2zkAi1ZF3ExWIBtlseYSkc/mAJTNd+McX4zncz1DY/y0EVNcTlpJux9 Os3u4zbiEqSGymWK5rCOHtFZibkfzXpAzre3YlPG81mD/SPjHmMvBpOz1ZNj/Ye6lVKoeZe9 OWgwz7n4WEr+N8ZbGhxPznZ52QLzN3zLIvKZA2gO3tFrJa6+GA3xOeeOGGELJN8Uoav+io3n yiXYaUhqHn15aKfv05a4Tk54i4vXUQxuQgp9FumEZB80wNzgPXLejow9PI7z5nHiZougSvvV b24OR4IdoWYIPg61wZk9jFONDjik/6Ax53p/xwal3H3GoY9LKcdzf0vtd+izmDnHmuOsnojG QwN4jxKvTrH+PdydtVKaXMfYlcGHLkfV9c7n7jegc6eIr6j9TBZ7cZg9XCH9VMubbmjqTrLa 7JPV9lliDfmmG7M0tG+c9zrbZ9KohZQSLYmT7eP1R0yzpfgtnll7v4gZum8RVcTvO6m7PaIy qZo2In0ejgw7xPXYUamG87DrSWeDRoyWehZCgveUaH+vi8ob3R68jr4C/yu0PJhN5IOK6q4i STi7FqE3dMzfBxtcG/2Gzbw8xtCzfUQ6eCeCB+1S5taLNQ7hn6P4mFvJaQ5JdzOWc7qas/MV e1IgS+1l6LI3ZKgtZA7rpL0/ztUPQ49V2r347FVol4nB29ytibTN92qk1juF3/OlNnm/LLa7 +YYuS3ZFg23j327oozlu/8eyr75qJPthqM/MCfRXHfdgGWdhGX3/VIZlGanNquMePkt/7fAd e6Q2NZ37h170coPRdmOjtmtCpD39iuAj+zBzU3z2JNKO9C9x3/otSf92PeyG0cGroR4N1jKf 67zcM88w1h38l+3+7xasYR0zbH3wtZs386WPUP8lyY1YQ6xn07RqOC760n17Q27wUGW6ftNH rrADpDN9ie3Hex3abQbPm3Qs2rwZHDHriDV9yP8ul/WMsd4+LrfRZo9b5wDGCamh3xvtCp4z oM9CKILroTOMMhP5FtqmNo1sLVnvVVCu+xjDfBWBHtA5WcKeRDi7pZO57tPMAXT/IyqiszAi oqeZE3ztntUmaTS7v9hJSS6TyxRr5RLFafg6ae3OUR05AWuhjxxtE9ve2b08eJj5iM7B7617 Trv7+Yezjl3G2hzqFqIzlFeiMtbx+rwqJLk14p2ojPW9Pu+lzVuwCT//5LeT6g49vh3u7j3O t11LDqS+jztrlkb+7xbn88Yr/sXcyZkyHIrtOOiPPy+XlnYybcY4Ssxf5HzzAXWhf7nH+Ywq yXWMkXn4vQXowDZmgLTxLG2ecD5vXgR+Ldjt/Nt0uIYccSc8JiP9h2Q4fq6TY58rQ/+3XuZB W/Nf+lXweYlDwcveqOCQK9cFm/F/A+AS+zTaZpOU2WEyN/Z3zo9tkVbMR2Pl1RqPzGZA80CJ K4kFfi/O9zHm1B8fdgO2mcTYjwZP4ssLzGBRfVIa/5PcQlw6LaWpm6TU78o+JKWdv454Vcme HZX59iXa9+FcfiET7CT82GTojk+5O9hPrB3P2ckx27hvlZyVSuw5hTOEzbHdTO92xvuI+3JS uvhb5Vo7l742yATaj7TLOF8/k7F+D8lKviRl5rfUxbHzXZc/9oVaU84Zr8WHzqHtx7R5EJ+b zbkaxDmfzVmtkGLsOAz/fT55SC36Mcf+kJI+/EflTvb5QpcPtmOemmd2597Heebz3P//l2cu j3LNE3Ktyzc114zyTJdjbpcryTFHe8c4Yz15PiY36rO3G16QIu9H7Ofd8LBcmJgv47wd2GoW bU64dgO9kXKp9wmlwr+Jk+iUBr69y1q13a+lvfcYdYd5XsC5/If0N3/GH78svV1/Qn1D1C5u 8zn2jNokf8G5fV9a4X9KTS9plaqWfL+MPORFSZmp6K4h8Bn0gjtAdVMvuY19uzLJnfRmcfbX Shv2LmE/QhNyZ9yZ3yyl3gZi4VbuUhXna7RUJ9ELxI843lcTl68xs4KX0ZRtbRExukyuti+g Xfbyz0zIkzHc3fCO5sl47y6p0vusd8G+Rqy/T4Z6/5Kx2GiANxs+wEZ3S9/En6QgsTNoUJvq 2jlr+YlnpAx7VCSOE397kXu9yPOzUuGV4GNnhTY3PfF5PSm7EjewvXme/orRVznS0mvDWZ3A /bpchnkHpcw7ADtZf7H09X4Jf4BfoX3bMqeG0OaJJcE+tX/iK3LQlrCFcTpKF+830i7xCpp/ BOcjV6qgHczUfFDxVmO71TLZnJKRMBV7XaF44/k2HaYBz5zV8FnrBqL94GwfG2VxBp3hAWib uIv56boeZy46Tq6sysROaAp1IyjPRe9MaK9lt0yo70D5DagfTtkcmfM4V7v/0V4u4FUUVxw/ d3d2N4QIFAN8YBJ5hBjAj/dbCDY8AqEl4WmA0FIQ5A3GFFqEwFc0rVhQYkRAXhZQQKxyVcQI KK/GYkJEHgERKiDBBw8RDIXc7PY/e+bCzQ3E9FOS7/f95+zMzszOnHvmTHwF87jd8xhoOX7u PCrotxG0HBXMry/0dlR2Hnda52hoOSqYRz/o7SgzD/jVKIneHvnCMuR7yElgP6342GUVjZX+ qu/EXewMdCH8tB2tRh0plkjEw06xRNdoifRxl2huY9WkQxI3rm5FDJUxUvpxLnX1HIPvB6A9 UxY5nkuTIKIV5Z47jstVlAPxt78fhGMsh8dz7UDCgwjqR5uDMxAY4ylZdKEkMQRxzq8tcEdp YfeSqm9Cbi/bTKQwYwdy8TzkJG3QLh7lROQx2TgTs6kLYmdNUUgx5l6czZ1ppIhzvpfnvZsD sTY3XsGZloWYL8/RXPRzEfH4U+QMCbj7VHWOi987r4uv4LOFOPeQJ7u5HmtX5HtRItRuI9XN i/dgToOotTEI5XTqgLzKzWHFMSdbHLP7gRhwAfZK6FDQEpyHnQxQh3ziJu47KarNBWXffMdc i5xjrZNtrrVTQEtwQdlDlX1eP2fniG/tdDApoDwR5cfACCPMzjGr2+lgspFr7w+y82CPA6lG GNb7Vt0k1OUH2XnmLtyzdtk51l47HUyyZtv5QXae1tDO0Rvb6WCydsLOL2M3dOsfAyO0hs5w MNcYb58022OM9na8Kj8BeqD8MvidiMc3xdqjjEV2OlhuLHIawSYQIWKRDwIjzTHMOHsRGGZc sQ8babZP2cONG/Yh2JvBTCON+qi2s0Ay6grw/DLKc5S93+pBfawejhFSw54Fkq08u8DqYV9G eY6y94sc5G13GeSxCYqeAeWbiGHw4cox4v9o67ZHnl9VS3QywTwwCXaosiXjQbhiJLgEngSt Vd04f856R+LoUZfRlP4ThIAqQc8GgsdlGXEh6W4h74N3AzMM1K4Y3E8zwVDw69uUp8q76y+J mQiGVgxytcZaDedZkAaehF0vwJ4GqoHqYAbqqkBXg3gwVrZHrj24ImQMdcmnqm6svcsqTmHc XxBzMVhdMZWJ+ZWJw+XiWJqdUCaOpdm9KnN2VCaeVyYeBuce+rKgPCMwtwjIJ27mD8gTtNa0 wnPpFsbfcM4/S9Xlea//FXF+Ki2w6uFee5zixFXUvQ2WI/Y3Q34wCmv2GepToAmcV+jFOOfV +YBzvYFpwP6EfisWuiwwu1KURGuI8gbkHjLfSKFQd/1HoG+0s5Kg6qw22zoH9XPU0+hOyRL5 DuZSVf+O4owOeKcD5yt+RBLyiT8gfvlBf7jTLTBHq+/JpfpiHDUQkynWfIa6mERNRHtqYtWg UCscfcVgj++lMP0yDTZ6IHZsQWy28A24R+om1dBfowwzDncveU+Ud8+HQB30uwBtslH+kTKM q9B5yHlkHhRJVfQCvAeEhrGLEFfjkNOaLhmGQbVdzlJLUQPvzaBwkQpdCdDGOEXV5VrpV+ge kGC2wRlkUTvQXyLf0yc4pTibmiIvynAJiPn6HKdE34e7pJ+vKUY7gnG96ntsqq+/gXn1pb7m Q9TXeIKaol1TsyWFm4+grxHo52l8wwTk+lMwt+uIXXXhOzJmNHAc+Emm2ZBa6YspUXREXRwI Q16+ge5DrpdpdEL9Qjw7oHI85OoyFrjxYBjFGEnIH8fgW1qDVLQ/RfUliGWZxlFqJR7GuxtJ d2NmEUA78wWoiuvGc85pxOZ+2NdkiXwHc9H1+bi/vIV2EhnrChm9CLHoCNXxg/766Q0wVqH8 Hsx7OPxHgLrU0fCBufiuOpRotiXdnObmoSkiE9+wGOdhFuZFRCHAr9qbAOoZjGfVoNvAUkD+ P+cL0Bh10RL9GC3Vbec6vncC1uZRz3sUq3enWLEXeKlI9zk3tOepM35vyVivJPc3tgW+VI1G mn/BPs6j+lYq/Ps+/A6X0oNmJO40s6im/B2GXES8ne2UiA+wv6eoj7iBPh/AuOjDbEedzAbU 1vgTFRkr5Dg00PLQNugQMcBTKAbQDkG4G5FnO+MvO8XWr2g+/KIbxlmAeXQTr8J/U/CeRdUw pz+LTvCZZo5PT6V2+n4yRX+co53ha/77FdAGBbHRGSMRX1Iv6yp+i6eda9YS54yVRUPMbvhd tsOzWGqCeFPfWo/fww84s6fTDHGWaofsw76/T8myrUREI5fYSY3gexniRcwpCeukUYSZA58f i7h1jqbr152D6Kc3/KO3mQq/R3s9nvqYu/G7L8Y+v4T+R8MvBlAri+Abf4evHaUpYhrVC5mJ Ng/gbNnNuH6d695LC7Aew3mP7f6eAnzXUFrnycX+z8S+hTl9Q1fTO+IwZWmHaZ4EZS90mnz+ UxD5erMPldbxe5Mb85cF3BOjy9rakIBzYDuvs5Hs2YO74Gh/W9kG50cUujsETmpP4TcSHdTn HQj+uzmfyWyLWihHsO2SBRIUWQrsvz7ebf4U6Ib1uwH9YzBGtj0FLDKynVq4rwpQi++uIDjX U5TLtxR6vnOeQRwKzCcC8gas80yQBIYxJTb2AD/lEuxvyedsl/gC1GFQLENJKVO6HnZzpjSU 8c0GGag/w/g2KTaCDWp8SVtFG0WCYrqiJxgZhGyPVffNh05R411WvASW8hgu08AaNb8WYDJT OpDbu/1cAScVY8EYcELRnL9DzsXtSzJRIcuPg168pr4L4JyaM/CtV6Df0lUAUdRXwmO7xCsy AsaXPAcGBgGP8i1R+J99iHfHKEYpihT9FaMVc8GcgOcTGN83TOlHivmKRxTDGd/uINJAF4VH 0U9xr6KaIpEpfRd6gNfCVwz9jcK/5y0YX77Cv75exWK1v+sUgc9fBKsUHYPwP1+jfC+Bx/Wt DWKD2q+NiqB+pK+4/rLq1julhuIextddgt/wKNwLQhVRnmuUJnORMkyluuYWquvGwJ/3T5ur 6Fu1696oyPu3av/1RjWDXPNGPQgpZvmR5SrXXWHrB5bLLN+zXGK5yC0vsJznh9+xfMvyDcvX LOdYiljOsnzljaoCOcPWaZZT3siakC+9kXUh//FGtoCcZDnB8gXLcW7yOVvHWI6yFLIcYTnM cojlIMtnLAdYPmUpYNnPk8hnyWP5hGUfD/tvbvkxSy7Lv1j2suxh2c2yi2Uny0csH3KfO1i2 88NtLB+w5LC8z7KV5T2WLSzvsrzD8jaLl2WzN6I15C2WN70RbSD/ZHmDZRPL6ywbvRGtIBtY 1vN7r7G8yrKOZS3LGpZ/8OuvsKxmWcWykmUFy3Lu+mWWZfz6UpYl/yO3zuOarh84jn8PbtjG cBsCjnkfkQMPVMRkXnOKcghf5VDwFjUdbnw9UASvslLxtjLDzM5VwFcrTFMrs8NMK7PDPCq7 I6zs8lrv8f7bf/v98duD157b9/v5fr7b9/NFITvIdrKNx20lW8hmsolsJLVkA6dez8PXkQfI /eQ+spYH3EvuIWvIarKKrNQS+oIVpIZUk+WkiiwjS0klWUIWk0VkIVFJBfESD1lAyolbi08F 88k8cjeZS+aQ2aSMzCIzyQwynUwjU8kUMpmUkhIyiUwkxaSIFGpx/UEBmUDGE4XkkzwyjuSS HJJNsshYMoZkktFkFHGRkcRJRpDhZBgZSoYQB8kgg8ldZBBJJwNJmtY2DQwg/Uk/kkr6kj6k N+lFUlqRRa2tHe+SudFOepI7SRK5g/Qg3Uk30pV00WLTQWfSSYsN3NAdtdiBoAM3tic2kkis pB1JIPEkjrQlscRCzDyDiWdow40xxEiiiYHoiY5EkUgSQcI5ZxgJ5cYQEkyCiEwkIhKhFdFP bpGb5Aa5Tq6Rf8jf5K/W04p/tn4j8Q9uvEp+J7+RX8kV0kJ+Ic3kZ/IT+ZH8QL4n3/F832qW TuAbclmz4AYTvyZfaZYB4EtySbMMAxc1y3BwgZwnX2iWEeCcZnGCz8ln5FNO/Qk5y8k+5mRn yEfkQ072AY87TU6R98lJ8h45wePe5dTvkLf54d8ix3m+NzXLUHCMB7zBE73OT/0aJztKjpDD 5FVyiBwkr3DqA5y6iVO/zKlfIi+S/TzRPqKRRp62gdSTFzj18+Q54iPPkmc0M/7dFZ/WzEPA U+RJzTwWPKGZs8BezZwNHtfM48AezewAj3HIbg6p45BHOWQX9z3CkTv57mGOfIg8yAN2kO2a OQds4+FbyRaymR9pE0du5MhaskEz54L1HLmOPEDu10wF4D7NVAjWaqaJ4F7NNAnco5lGgzWa qRis5r5VHLmSQ1Y46uEVwwhbi95luxSVZXsdvYaOoiOR420aakQNqB69gJ5HzyEfehY9g55G T6En0RNoL3oc7UGPod2oDj0aUWZ7GD2EHkQ70Ha0DW1FW9BmtAltDC+z1aINaD1ah4aESzek a8J4wSZdh2WCTazW2gR+HZdrMYFbq4J4NWPg1vKQBaScuMl8Mo/cTeaSOWQQSdeiAwwkaWQA 6U/6kVTSl/QhvTVD4D7tRVJIDDGSaGIgeqLTsChNYhSJJBEknISRUE0XWOoQRzH8BTWjn9FP 6Ef0A5bzIrqAzqMv0Dn0OfoMy/Ip+gQdRq+iQ+ggegXtwlI8gprEGl7pSs0YuOWX8OIsJovI QqKSYWQor8MQ4iAZZDC5i1/ZTEykTYADsixLmsO297AsCfvRMSTLAj/LUpLHVR/HT5ZLckg2 ySJjyRiSSUaTUcRFRhInGUGGk46kAz98e2IjicRK2pEEEk/iSFt+zVhiceyEN9ENdB1dQ/9g gf9Gf6E/0R/oKvodq/ob+hV9h75F36DL6Gv0FfoSq3sSvYdOoHfRO+ht9BY6jt5Ex9AbqAm9 jBV/Cb2I9qN9aGdg9aWbvMZVZBmZrRnxp5BYRmbxsswkM8h0Mo1MJVPIZFJKSsgkMpEUkyJS SArIBDKeKCSfJBM7L3VPcidJIneQHqQ76Ua6ki5cm86kEwkmQUQmEhH5Gyk49kA/uoW+x4U9 iz5GZ9BH6EP0ATqNTqH3caEPoDVyF9tq2W5bJdptK101ygpfjVLtqlKW+6qUyKr0qswqObIq ASyt8lWdqwpZ5qpUlvoqlaBKU6UUscS1SFnsW6RELhKjFrpUJV+9rF5VZZOar05XK9St6hls CN2r7lePqXKT/6gjRh2Q7qxRN6qSCfslQRUNgc0d1Ei9s8LlUbw+jxLk6euR0q96xEseUUrx iDmeyR4Jo/Z5Ond3BkaneizxzmhPisfhkRe43Eq5z61ku93uaned+4g7uNpd65bq8UpyuMN1 zvmuecrFeaJwSPIL0eio5NfkCPdB6ZYgCi3SLYdfnIsLMAcXYrZ9llLmm6XMtE9XZvimK9Ps U5Up9slKqX2SUuKbpEy0FynFviKl0F6gTMD48fZ8RfHlK3n2XGWcL1fJtmcpWdg+1p6pjPFl KqPtLmWUz6XkuMSRdqcyQu5nw/8gQiJ+yhNrEq8kBkVOtpZbpXLrJesVq1ze7ko7qTpBNMRX x9fGywY8SXyKs8XVxtXF1ccFG1pfyFHlMTUxUrmxxiilGB3G08ZLxiDBuNsoGWoNdYZ6g5xt KDW0GPyGoHqDWK8/oj+ll7P1pXq3XjboA+/laIfe3stp0Nl0jpHJOnlQsi5Dl62Ta3WiQ2fv 7XToOndzZkRlR5VGyXVRoiOqaw9nS4Q/QnJEYEdLuD9c8oeLgiy2F0VBjAZyWGCNRLPNiftx n0UMFvGnRWN+XlJSZlOof1xmQ1hOcYO4tqFLXuDZkVvUELK2QVCKigsaRXFDYaMoDctvMGXm FvH9mvXrhaHWzAZrXkHDbmthZkMNXjgCL/x4IVgbLcLQwqQSr+r1ViR5k/CESrzYUqHipxUR z1CtCOyp8AoYknSbR2CEN4DaOsirlqqYAzuw2du6OfCupHXI7eb4Tx+3/Sb/xUP8X578//vR trRECBaEW175XLBekIVQIU0YK2QJ+YcEnbhLiBUGiif2Dx8e1jP0MN5KQnvxhBAmiOIuR5sg SZeQkNEpNWSdnGsclRG6TsoXMm5eOH8cTydj0pJPisnnm882R988bkxLbj7T3CtFNHYwtmbS S6GhISGdOtql1G5d+/Xp03uw9C/vZR7bRHbH8Xlz2PF4POPxeDy+4vga28nERxzHiXPYg0NC 7NhJwMkWNjiBaFtUUJejsEAoSCu1W7otoApV6v5RLeWPVu3+AZtwGMqW1VKVoi7VaouoVhVS V9o/QKqltkKVYHHSNx6bowfbY9V/5s17M573e5/v73JPIuDz0mh9LZHsTWPdcReKmZsraVSZ A+z3jyaxkZofPegZKHURQBKFNq6lBWtzGcRuNzNe9CVDdgJv0WBEizaYzPpm9ue9vyGtQWdr 0ErCsdUJx9p7BP3wLwT96RfwtZ9eQe+mNqb9moMGPUroWn4QcvH+LufQuIExELRDsDu1LSxN doxtrb1hFwWSFES7U1S+JdYGYM4/tvoQrxAmZAg5rySdmY0XggwZYRhzBU0suSJxOJxDXH0b 2iurf5JNTAAttIciXsqo3FF6DQObkotB0uZdb5uJKA2KrJlGrBl7sZrJmFKpKptKSSy8kTIg eqsaN1bjUbab7e6KOZY+h292xTaJCmKFcRAEAkGfxcKzTehsQpHGhQqcCxO6AwG4oMrA4xWj Q+R2+bqlkG3l585+AcVxvSPi90XsZG/oWCDR7uceWaRQwAQwjHJG/N6Ijdws+K16WszE0XLy 8MDYiUJtljTqNRq9kcS/HY0aXD3BlaBUKk2FRr8/gs6TRoogKCMJvS6/eg+7gP0OkZAEIFTK yxzn6aygw0tSAq+ge2TSg3Vynaij8xquFHXBAIoIbsTRwhS+BUdP4WdxaKIzWlm9u8yAojLK bvhO9JNA3vpXhDbSKIvROisFijorfEH3QHYW68xqknRrfq5czVQlCXp1efdcWarOlUG0Gr9T hQtQCVn3/90bqgbMGp/H7EKVyKkrYqY1TwcKH0zWw0mLXWj31z52DJTXZF/KxRgd1YKheIuh /8W92f3LBwbSr/xk+643vxS7j83Ox9ZFbSh4GOlMldd4OYHTmjw2S5uFoa0CO7h4+fD+q98Y ze47NefeftA/VIrCbOFYOYmdxn6LpGHGmAeoqow8ycS0WJ8v352/lsfa8iD/8Q0KwNNRN0rA VQLWEij9+SYPBB4gvJFHGZ7f0oc9GBzrcHdmr2RRJAuyN/vyzCwwYrPvy+5J1XUhh0y1XDal MlXou9G5crkMp+Xb9cEkpBQdZp7eWZ8Hn735k70Hs+9nUTwLmOfuP/fEgmcMUC2oy6KEUD2C AkGNhjdbBMGF8U/lsV4YSDDBKVdFK4vgiVuAmvzg24qgXCIQDNJYY4adthi/bOESW781LU3w FNcd+aiwf73Uv/fMvj0/3BZlPbE2KZqUfB29C0c3dBQ9wMHyK+9M5cQ+0TS1LtAncgNjmWV7 G6f54ubURMyMbYlFrEOeiYMliacNfkuriLZg4vDcYHbfC3G/vKnHM9gbF4TJ6MDWoG8hN3Fo JkzqOlcejE3ZpFTb2klrR2/thXAMJTif22WMJ4RAFIExumP1IThGTCA84kFGVE+4iljQq4gT 4dEtCAlb1UPnZZsxRxQg0MxtiBSoZcFx6Z88a2YmNQ81nJqDeL0KPYgNLFKtMVGMtVLNkUtP zwwMzUwPekmGJAh4wRZJRkkwDAlihf6+XGEgBTP2kdWHGh3MJlPIW6qdb49yFXR+2eWKk3Bc mkoHfwYtjiPG1bvn9AwoGCuguDSe91cacz+cy7S8Jp8eDfflwgVbQbW7nl0VX5FgwMLDpW5V ldKXqh/xf/rYszQi8EajZZ+z0ODFJ5P1/K0WU16jo5wxMRBr1bO+HjG8OQnJ+RVyrDfpj2zu aYIk7e1t7g6BzJ+c6t04EmdDxfHx4KbFcfdjsCgbzve0jg7XzvzrFexrzbttU1OCNChK6SA3 uO31IqJqgH0INYgjrzY06OAU6C5EDxVAXEZY2Zb1oGhUMFENbLJeDuc7bP7cY0YmlZCk1Ebj Y9D/yS8/g+yzIHnsQ8rZ5Re7nBTnTwViC/+I7I3S7OGi9zEoUFvzPCwQx1YYO2Or93Ac0uCQ ILK7GTtmdB+CIC54JRFbw1lsFWCXdUzeZ1VmvgpwLsmEWiuaTteIqH/3F/Wk9WyTRdQxKNlI rS84PrhYObT/7N6+ocWLhw6c/WrfSo2PlzJ900mHpWs6nZpO2sG9PVeO5rNHKq/seeeb+TVH Kq9md26ItE/uXAfHcPvETqi5sPpH9Dj+NtKPnFTPeJFlDQPtiC+sRJ1gCDdDIlwBbcu+sVZD c8EAF5aEsa4KWLckaxvWQ+Nv1o/cXYv/Is6qpfgSEv5vPqJ6Aa6KXk8xEEX342LKqyUW5nZW zcnKHD2uN/mivc7xl8e8Ozizouh2favqHe8pGpu5a5EBs9vGajV6DbHYGeVgMgpMHtgAbkR7 W0MCeR22PwQB25/rpBBq7Y2ulHM5rU6r5f2QlgVGyDL2S6QTmVFpLRk9bRX06xdk3uPWeHwV tCxTMuL2hHIevT2nr7s19Gpgi9qtd+DRTCm78Y4dDhDLxb97qaG6FtCY2vo9UV/ghF6u0X0v A4zAV+4TbHA42TMcYImV+xot0Du7xPZ4K4X/WqP5FWZwRgNi1E5ibxI0a6EffcTyFE5QvBEL mt20BoLACR1L1XbbbOgJitUROMko9WIa9nQfEH4kgYwhn6gnvAQbvXcvMmgRyQMpU0HfOkc5 nVTPZfRVBFn9g0wrTyAZhAIMRvU3de2vgPRyLEYEGikj0HwQqICMrOM2ra27/toKkKHrzz9x faWlUvwHVvZbsK+CM9hdd8XKkuM8NIDBPq8d4B8fuEUzzHAIGod0Nc2eoN6mqcCbkadtRB72 weDen+588bWFtEgz0sShMwcCxWyEaSFQrIUmqUAyF1u/a9QNLKnhic6F72zqWFkxhbJRZzIR 463RddHISMQKzi78+OBIe/Hl10/PFn506rtfkXW0yWDknOa2doE0GKnBbUcLtNNsSL50fFd3 scdBmmz0jhPTPm+6pOiUgjrdJkSYmyTkelOn8Oq7FxQ1wsB8Gf0eVOeWTKrq/I398o+J4oji +Jvd+7V3xx0HeBzKjwE84Di4O6ACp0SPHxKDvyiIsSriye3BBuR076CtqU1j0x8xNbHGxEaN aepfamJNrPZabWwabdKmJiY2TdM/mv7bVoltak00SN8uewKGWjViTJ3bfHbfvJmdmX3z7ruz dh7oOXSZYR5udzFY81LBmpcka3ANO90u9LrViLmTpAsjtlaLmBoyRcJ6lH2uuhKhDBxDoEQw Ey6LcEr/SoeP1XGPsmfEzXP3TIqnm6J4Ov6H6u1n3nzrZNRTs/3Mrrc+jpbdvWWeU1BRX7Ro ZWWG09/2QmlDZX6mkXvv0O1TmzacuHX44B31emzjnv5luOry8e27zwx4c6pXRF7HjN0PwJ/S Z4Mv9Y0YShM8RCgjplJCMkhA+WoQMH6hAOHBk+T2nc53WRzJ8Z/PoNORmYHfcCGhuMNjTycW Pb7PvJNfdPhQ1UvGLhO/9/LFmrHLVYGebi90E3zQeSGXp4x4cJwpQykjPEx/Ss52T/TT3T3x hixMBawGBc0wsX2tc2tbC4eqF6cMFpswVmuyod6h9ceV7DyHgTPZrMSpt7tKC0r8LtNVwW7R R3JLs83m7NLcvFKXhW+LW/SO8hJXgdNm+kSn5wlvtAp3rlpcpRi7dRi785h/i0mGFjubroLo vERYSIQgsYSSWi6GiDPJjZ6tceMBwc+5UbCM/zaRlhZMG0t5kkhnHfVBSoMzpZAUSqtxGnyd 6UE1g4JJ8tJkVLzVym4Mkwj3c4qhiob3+uVg0I+ioWQqYHIRJeiZ02aHs7LzT3LkCTHRRpu+ MHV1i/kFmoJo2W3Qvg05o7FQWaDzenO6eczlpFmCIT0n65fmDp9jjmdx+aINS31pQppJzxvM Oc1bRkLigUiVa8Vu+QC5a3ZYDQN5nrkWU3ZFcaHfXTznRmu8p31+4aKKnHx3gTXXX5RdkO1w uYtdNRt2LluyY8+J7YesOZ7x8ZTGcwb+W1C0pAnLF3AtA9AEP6a0pEXT/BaSV5Xk3j8NNhsk Ue4nBWVRknv1U3dIjU4oScpOU2qsTQWwNknKQ0J5p0utdqnJbFw7qcGayF+/qKzYVIlvwa4x eW6EzLgek52HBKX3dPQ99BATY0zReZ2m86q4KEJeZzBM0Rvd9B1WLX8hvXL1ztM7vF2tVU4z L6QJ1ool7VVrEsuKON+uNX1713sWyse3rX8n3Oi2373jCiwL+FsqnZmeJv/CPu6r1cc+2rc1 ZM3ImlM2v7DMabRl2Bqib7fleWuj+zaGj77cVL4q9u6R6oG9a+cXNnRULXhxwdxiSP1IA+N+ uA8ZDMZsoqv/f2BoeQxGZxeTDCC88e+Yo08fy/5nE2uCwWAwGAwGY2Zsuc8G9s0A6YcBMtbd R/8kmX8zGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDMbsARwQUH5ZwCsW lw8Gzqw4Jtyz+eOv8df5Uc3+Uz3ffOiblz7KSCQfaUe6tfIwGSE779UeRL58lP6ek58OtuHZ BemYGyaohloIwioQoQ8kGIIYJGBkfBxbBKbVbE3V8OeVY/wWfAa/wl/ERGykhLQ9MLH4/5yT DU7eaxe5d48RbmMp1XM12aTZPGSSvZqtQ/uoZhvQPqvZRthJvlGyXycofXKtmk0glzuu2RzY uK81m4cS7nvN1qF9W7MNUMJTzcb58K1wDChGLYBHPVorMTa9IGN04kgUY0ShGS0Zo6ycw+iR 0BoCH9Y0wiAeFDrQ1wf9WBdXSyJeRWw9gucItmzG+waxzRb0SdhCUtuJeE3gXUpLii0oXidW J45+US1F0JtQx41gaSteZRhAX+zePTPXRh/pWaiaK1SbDYUuLEnqHJTxO9EKq6W4OuYQev3a DGJTnqAXS8NYm1CfUmntO0arA4F6ulLqlWPxWDRBm2PytpgcTkixIR9tHBykHVJffyJOO8S4 KI+IEd/yVY3tbS3e5vCgtEWWKptig5GHc2k2leJUlBL9okzDVBb7pHhClMUITcjhiLg1LA/Q mFIzpRideXpUGqLYDe0akhJ4f2cinBDjNDwU8WMHMXWA3tjwUEKWxLjvqWTRcvz3NkI7tEEL eO/LqQ41c4bRo+TAg1pWQhOOPIg9PslWz22Gg/oSthcRigr8BWoKh1c/bAaw9pJG1B6iKpj+ SPKV61fEHnvDTcgxqZJ27vfXvlOul4o+kO/8NLZHuGa8hEUh9bb/R4ABAC24JhQKDQplbmRz dHJlYW0NZW5kb2JqDTQ1IDAgb2JqPDwvU3RlbVYgMTI0L0ZvbnROYW1lL0tOQVBKRCtDYWxp YnJpLUJvbGQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRGaWxlMiA0NCAwIFIvRm9udFdlaWdo dCA3MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjUwL0ZvbnRCQm94Wy01MTkgLTMwNiAxMjQwIDk3 MV0vQXNjZW50IDc1MC9Gb250RmFtaWx5KENhbGlicmkpL0NhcEhlaWdodCA2MjUvWEhlaWdo dCA0NjgvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTEgMCBv Ymo8PC9Dcm9wQm94WzAgMCA1OTUgODQyXS9QYXJlbnQgMTcgMCBSL0NvbnRlbnRzIDMgMCBS L1JvdGF0ZSA5MC9NZWRpYUJveFswIDAgNTk1IDg0Ml0vUmVzb3VyY2VzIDIgMCBSL1R5cGUv UGFnZT4+DWVuZG9iag0yIDAgb2JqPDwvQ29sb3JTcGFjZTw8L0NzNiAyNiAwIFI+Pi9Gb250 PDwvVFQyIDI0IDAgUi9UVDMgMzEgMCBSL1RUNCAyNSAwIFIvVFQ3IDEzIDAgUi9UVDggMTQg MCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAyOSAwIFI+Pj4+DWVu ZG9iag0zIDAgb2JqPDwvTGVuZ3RoIDI1NTIvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CkiJ3FfbjhvHEX3nV/AhDz0BOJq+dwNBAMsJhORBkLO0/SD5gSKHq7G55IrkaqEPsb83Vd09 ZF94GTprJAgWEnc5Pd3VVafOOfV5RMfdeGRFbc1Y0bqhdDxRupZjzZrxth0xXYvDk4fRj38e r0evvt2p8Xw3pu5nN4dv3tzR8f0uXR1vsxx9d1j0ejp6NZ0KeHW6HDVjrsYT+NeMjajVmEpR N7qR4+nD4ZzG/eA5k6ZuGnw4hxenzyMy/dRW059xP+73o7WksHj6N1wwH/0FlvO/+hX9iTVj VIc1uB3Fhe/J2/bpbl9RWmsyq5rakG01YdTWijzCnxL+pLqmZOOePW527aL6afrP6Ghdc2H4 mcPN8XDOo8MVLiT3q83H2SrcRPulDG4yZLvkLsLfZddC8BSeki/dvFK1IG0f7GF3beSpzf8+ HX32oKCKRdVMUJHgJaDiiIbkaY6CzzHiqKG1hUXCncRtU2uGC3+E/TxMTAETCiDDN1ndcI8T KJAP/LsrL7EGChnAdUTSe7LdVLLmkKsF5C3Pk1H8hqJOjmUg63b/vNn+kpaV1/xk3tPtZFTT ECQEt64soHPfLTtfzmOtBqWzyIeUthYhiS4aAHmaybJLw5saIokz6ZqIfCB3795+qKoER4zZ c+ySQqwAUvo4R5KPkPURMlk3bDzxHxCn4bUCPmlEzWh8xV+rhA5gb21pSQf/wna30DcUkPH5 qYP2l66P8O9d1vq8loyZq7zDXWT9QdqFM1utUgZraiuuM5gUEd5CyI8QowKAbDyQ3e9lpKbh N+zvImUu0s0yD9RwNoBseZncdQukRMn+GQBtCfZIHiU3p+np5NaTYz4D9wGuyRdgakq6eVvm gJ3twRPFek8wTAPMP0FG3a4Wz5DfbE9Rw/rwwpCSGeNyut8UOZVcX45twqArFHAMbGSlZf2e lPd01gL5M4Dpvfs0pINPaAOy2/dPtkVKGq2unIs5Yepl7oD5aJK9PMbu232u58zo653F+jVk /6nttvkelkt+sTb9676dAkr324pRANJsCfWnZAlSmmaNDYRpvDvV+iA6E0cxT+5Tkn01UfCB JcLP3F6AYjN7QyKedt36Pk0Eq6mg8mIi+qKAB8qKKrRVw/HtOcN1ugQEPmeXAZfF6QAaOtxG 5uHI5hAN1yx/kzeFwyOL7r4r0AXcfzKMSL4aEDzYmAMUARkMkzg2EEDmVA5SmQkRgxdRiNz7 XogSk/D08LE9ym5/qNXnvFcqp4Vmpo/PuK+wqL+Tqf/AG12WaaZoLtOXFBrPETx00PS5mnCO AlKgS2l1zrQd0QUeMupLbhL2VI49OSqIY08J7Ol+UUCexg0JEwHI7r/sV2FXC7Iu5EFJeyNT HNRytnJzCXXmg5LtegYBWDwZBIB0Xypw+pwcZe6Ya+ZzzUKuDcQNVRdNZol+KxIOuYkD8VPK D92sIGct2QCm1/FmTqXIP6bf55txbVLZONnY/YFkWjCU0foiQxkbxRHEcnoHtEteFwg6bnbp Zv2OsQF5/QTeC+W2xQKBfDwVTG5pc904UcnLGnTr/NZaigH6mPCh9YG+aR07w+BTUWyjWWkK lBkQ5wmodIVXlFwM8IqKxXuJo69FEdkkA9ohSDfBDE5mYr13mxyDig1x36eyObt3ZYcRoTCc wCZaDkATjxSUhiBPuashPiBBpjdXP29y9FDgfH6ygSP9A9YA5cdZTDutgAbk0IjqnFikpMMb kJrwdqwVCQsk0hfOsxbF2Z/HuIIr3XSgez0IimMK6BTKo6QEcr0DGpWgRjQYLgbnNTEEyBt8 G8JXTQLO8P4H8ifa/PIKPZxC2/ahctvEN+JKRJKcinmi86WYJ4/Piblf1BeIGqzNH1Ih2Ods unGC8G8feDvCUAgx1NSH+BJFvRIWyBwQTx9WCe2XCQvIpZa9oPbIQmClFujKJuBkmhAqjAS/ I85zGwswH721WgxJmlQ1tUjk8MLXQmSBMTKRffmEagR8CPnNbWk00Gv8CGOAdTJuSTduKfBv j4XkW8pOKumL349zesBxRCYHLrnlwtziaOar5X1s0KOv6GMl2lTnS7c9Lb0EpgTMD1z6Qz1J Au2dM/zZBnAE/y960NhYvAUjTfbdZj1bla5CDJhPU1fhVfatG3+69X0aJ9RADZgA+jtH89S7 1ayQ7SFXTtPH/ZW/WTx0625XQf38AIHIYBRtKowR8BVFy4q94gadNCtAc1Zd9zGZcZW9UM5h bGFks640fOzdsYzM5u5M55bxzEU5OcEwd5tz/E+804RB7RUMIjhcSeiMzN2/bZ+A2aGlKGSs wXGsmjAgFgETIIwwJyY/JvmtltIXfv+pLUYkaQf4yD4Xkc35voIOV6S+q48GJTCB4CwyGYk9 SZ1LYU/Sx7k9yXlAeh6QgQcMkPCYNiLjgV8LHkB6OsKJBj5/B24b/da5oYAOSZSMDbcMLbJt HWVS8hkJFD6fwmeHyuEf48kPTlAE6ZevwUjC13v3mJLDEHCOCQUMXYbdRoXHDJBv2+2+W2b6 DB6uMQPQFk8ahwlmDo1psPcZtOPD46qbredt2Y5CXp83MwpwmSXP3f5TDmjT8AHTax8ujGyr vKUt17khOd1ZHj6BjWaPcL850CCMvR9X5S0pdNGNDKv8zqtZpckzUJ0k+RyIqn9LdSLdm60X xejGKb8pRMplgnBF7t0ncwgXZAX/M0wIAtk6IHMwSgh7JGgUBYYop8hz+d1A37igl+0TSmo0 pgDpWIjCDLNOggPZiHJOsYHhnjcuToGEbCFcuA3WYIF/KSjIBMWnw6sZ/FLBDdtiVBNgh86M ailNFlyYPj4zqoVFfQ4gBf87Gbhs2wRcDGAZk9V1yxao+pt74GoOmHESz0nebazmhl63Ri8m 8fle2aib6K02qYyE0TbeDKaNsJmfSZNpyWh9kZyMjckpeAz0Rg2ZLSus4hJoqsyXGnDHhEa8 aMyeFt1+l2uGMDdk3wXqCX1T+NJG0hvEIcr9on04UlwAIdKPslqOATXUQqb6bf+PkBcmkUeI E9vynJvBifZGzQ0p2D19rATsvMMMSDLfdh+LA0DurBowQyWhs2CXuvWyohadWDXhODQ8uKkK XYQkMFsVZ2kjbpghrsBNDKhe0gc53CJ1srxmB24GdwpErSny9ZGdC16UaP0EfKtrbj0vgqkR 1h/TdXgEr6VmcXrJMpx8EAYJgnHGg6eSVOpO8vic7vhFnr2d9oINAa1nIlWec+wfbnnGqvby cfa1TLAAbH6wnX3NCyoaM8C2x+71lKnJ5ptw+VBYBkPb7yusv3I35MoMhZ7HGh3c4W6PamxA oiH9OEJOGPTKSwaseU317QFrcyhtZJRP9Zw4SXI3hn/B5oSIeKOgv4PVWMZ3GPAuYjuk313G OSTStmGbfwswAD31M0kKDQplbmRzdHJlYW0NZW5kb2JqDTQgMCBvYmo8PC9MZW5ndGggMTc1 NDAvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgNDg1NjQ+PnN0cmVhbQ0KSInUlnk8VF8f x8+sGI11squRJbJ0ZxBjK2uRfUlPVAyGsc3EZImfzGT9FVok1C9bQtaixu+HkBYiyS8qEqWi jUKiheeO6nk8r9fv9+qv5+n1nPO6r/P6fL/nnPt9nXs/73sBAgCwAsQDFNhk4WK92WQROwRH ugCQTXFwWU+eH+cWAyDnCse8fCJYxD/ium/Aug4ADIHG9A8peGlWAYBCOwAC4v7B0bSSsWYB AKIDAEA4Bvh5+z5NXRgAoCkWXr8hAA7gy6RnAFj3ENZKASGsKJLwI2EA1GFpTA1m+HgDgn48 APvqYX0mxDuKKf0YxYbXe8ITiKHeIX4N0o+uAVAPawxghvkxd7ctjgAQ4AuAKBKeg1jqvBHI hsMjASw12SCII+uPFViXtCXpAx7Bh8znyG6HQ65IBIIkCAlgMepCKKQMBkDeWJw6FoFGcPSQ CHS+C+QEaSyLyBWuipcDRkvdAVBBOGCAYOAHWPBlwuuQwrLN0IShVFzNHOH3JD3pu6nBTzxQ fnZW4/kciXUQBy0GcZAf81FIBBIpDFrBQSOjFNE7JrM+r4c3Qfh/VYpAwzUxSeqQGhblhhYU X2POYEaH0f0DWERVHzUiiULRI9rRfcIY4Qwai2jOCGNqkVZBcl8nr/zPDCPMm0VnhJIUoNW8 PEpc6t95ZwaDRTTdywpghNFZ0dAqSTxFDyKRIEgPgtsOSTwZIpG1Sd/kT6iIg1iz/FgQGIDi IIQBHMchOQgEKEM2tTKfG07Zy6rmnYjaBb0sLEtT3j23cNy2iLvwWyHRJNap8GRhhhc56I6Z b/RERUSH68DUq1NJchl5CbTaa0H7qIr98kaPhBFHx7OuNmvScnMDVHJ6DDSaV1zcrtJqNYYz 0c/SKFOllL62PmA2miDckBvs5l3BiS3w0oy0fZFT52uY6yhH4lci5JWNHVGXem6c7UPw2o7x y5PXc07+UDKZibwu+2ezm2VtanyzwWvXTPuqLyX7Qlj21VJdWQKqCsD9sBddr2GrGJ/RtkWP T2doOP6zvext7pOXDHdJsCPRA7OXq+KPL9Tc2t9fIhPmaXSz8S1/0RqoFpvYUUuMFE8cRqLg F7+IXQqxiyF2IXya8gg0Oxdin4gX8ehhTtLDTis6xREu2KUvdhaE/e+fH+cH7ziK9wyPjwu2 pE2fkNJ9U49Quh8pOu3pRc47LdhpgjmSktFh8Fxh6q37MY2L+ZvbqZOf73UZGu4o2+BKX1AK 2djRde4RJnaIlGacJ8IMbFgQc5Cit3zuMR8V3UF0eEmNqT4n3a6up6x52a9A7FdlYZ+iD65y 8wod/SunnStCzcl8XziSc8/8g/FOs03vnG80jV2FPhNJAinyx9Vk7PrkkcXv4kdQdR4z54fa 3Sf8rG84u16qQ6mKLR7uf8ufEVd/4lq5nsbTfU9LI0cj8kFP4MbW3g2/jpiKleoGygYO6j6+ K4d+WmqJbt+hrR9qJ4encnGFh/7sc91odUvO7SxzUMwg+djevJLefJgKXhAHZfuVCjitctGH jouev3W2fGeK/M+CAex7fTLcYAKQYRiQyLDU/Q6D6CWCwptgxZFuLiRxSJQn+MVx7t7hAfRQ fxZ8GxFIiBfkE+dz9vMNYYT6fi8M93eFKUIKXwuTWZ739SO60P1D4V2JjuamP6QCN/qX/p21 lpRSnQrSwLyyrnVky6fVp29Y7pm8YzV+91BbkK0zdSYH2WZ33zp4vZKJX3O3IldwC3f/3iHL pnMZQo7XlNWn8sfwiqvvmCp9pObclrYsPmazOudW7fo1bTaasYwHK1cZHqKIUIaa1GZohpoI 8uLC2i1nLwYjkk99+uOCz37OvGc+OyExvWaqPrPotv5Zx0TJtcn2Q9AsMJ65Pm/Mvpz0JphS oqUzW6dVjfuFeiSKdio7HJ9UPXV1mvi7g1iaT6fGA7Kl9ESDTZaho4tUN80p+lxlcvs2kzyO Y0oo5rxua4xSkzPNOMe+Sz1OOzRhM/bO6R6bJGRoEjjTkjzs8o0KHyH2B0icBwVl9AoIh+WH P2gYDB8K9f+BCmFejeIIxCIaA6HgAZLnBYTQEmhCl3x3BGB6VL8buGqf62ShVWTh8xYS5KWF 0WjYRknLrLPEmJjyqjgblanuRntW4fa1rHV7a5O+lNtmRgG7FzdfST2kXxMqjJ1Gml+/mdw1 59J1Ja9pG+Otj0WZBZjIas/tk6sXzJPGZ94bWFWp9svkm7PhFRmPKOnG2YGN+iG9KdWKX4Zf 9NMFjqQ0LTwGDTrTH2LnRcS0MK/Uso6ZBanu4epnjPDhO3YG3GqKNw2ilTZwG9J1bk6hRGL3 ve8dMRuOWXj8uGJhdrgPX8vsPzrqcEm/MFbzrvGgjiBVD5nHDlRMnfX0yajZ0UC553XILUFG +71hdj5nReHug7Ua3ILizvIB4qVmSDqRSMCva3SeMR3ZBY0eVaUntzKfTJeUd8ebhUUIwYwJ hBnj/I0x3sJRdkt/SKjlPsLAnPmJrv4OHG0IgomjDQMHokBkntTmSYj1XyntWx71N/kfsqZw EJd2+0qr9clb5wx0KhX/ETQYfFlhDTez/WVV8/U+lStk0YONAzs1Pm3YtmqlelUGfohQFKpq u19io2lF2qbzVin4B+zMyhPYHneLCM+X7z4LPdnPKtLuZD2bHPUuiENxLRf7TMT6am7uwvfE THHF8Z+9AlUT9x7iVjYmjkvWHb78XuISdecb0WGDCQWPg9Xx4W2Wo8dTI71OjlVGtuqlaRPW iw9SO6pkyhyy/SvvEinQnpE0f6sn1+Vm8I4s0/XjGKVAhSDrmqNXL1BumBWHeErZlGfcSz9g EoXbfP/MhQTFtidTMbTzNqwmFdOtp7wJXvZQO2e6R5AZO+FmF9nL7xbB/saaOYj9funs5YV5 joVNiG1ZZthphU3psU5zrluzn0neCzygg9FSGf9rNPE4Ia+IloIk4v/a5ha8CavRxpAh9E/q yzwcyvWN4++MdWxZRtbsNFkyMw1jkCXGniUTKgpjG2E0xhqGsSVrcijHnlAS2bLkoNPJkhKl osjSImuWynLKb3RSknOdP35L1++P97re+1nu53nf+34+9/PF5KJzlaL3uJHJ3qqKiniSx27P 9RjuxhM9Fb2PE9ZaFb1JRCdfPNlHUceSlmi7aU1wg/UlafcQdbgqXGXdhoOj5b849Pf338qh M2mDJ/KmA/SZNlrWREvXbLEIFIjjFZ+xeunEk3DKNHsg2d8sXZ9/HuAlhD51TM7/6JqX+QK2 a/ng4/OfzJuOQirrCqeo8+dEiIeW380Osz2IY9bYzifW3VyN1WeWsbeGGKe+Ze6s3+/1dsSA G6YUJ056fqymjMAtlTr9BgV5GupFTGE50CFrYngZKR89ltdpJ3PjhvrQkYoI1nolYbNIrP5q Q2reIaZLaQMBjdaUi0WmnXOlmRnaI3dspTSeUVD6pu+72k5mTdS0Z+KhlmWlGTOPm7py80p+ 6QiSi5Fvbu3704Ouv0mldLbbVoBvW/OHjrBCTmbBgWTJ1+V5Jhrj5VwyARwt8nUFx1uT1Gm0 yaLRJmqdNobBU59pw/DzaIMjeDr7kB08vTfSRhmOQSjDEUpKyM/XG8RnEwlfM+Hhhf+Vve2E S/9VKEW8dAjebs4kMV1LrBjW0lQVAddVUVBSQaEVdPbpqawPpOMR+ZuPsHQm+RHwzv8IqPF6 BnxbX+DVSF2Ni5W3pkyypZ5j/EQgj5BGNgE9cn0XmZJnXu9daZQJvrDyMiQU2dW3Nw6Dnlt8 ooba/jCFuoKadIsiCSYN1ZoM1UbN72EBt+T7+SiZ2M1eHzYK2VGbGvB0VSSKd5/eiXuUndbc 3RFmal3Lg+/jpjSB0d5BhyW+BOOCcPV3BK3x4dgmJrN68sk3bC/1x0s8Zntdw5kXt3eE8DT4 jEBMlh1XpnIxGaqfJrjaHEQcbZ6w4CJ61YyNRw42KtoLJqYw6PTbTVBZJNMhuQwI57izpiLa 4vkpyR+xulii0jUsupRwyXkJpXON76YaZpgzfk4wZhRnLqqWhSjdCKhvQAolvd2tabVrSPqD Wy3oT+Ph0K5Rje/YQxwz1UyvQ5UYRyfdyBy/oqatc/v+v8Ueso833uE/wp51T+StCMr8A4W3 ABQhiAph29492KUXu7upGxUUTtkJ05adfyCewpFeeszy6K6lqRacUXHIB577rNCl/XPRvIDX aMQOGLZIHoMcIGagD09LHkjC0SVoFmU6qbxXboPq1KhqnGtn//1EOGzepQgxYmuXtHTgwLDt xNnkLALEJLa7288Exe4+HKxbJHckAkfBSglI3zqt94f0qEAYYRf0Pd/ttxLy4XpH5RaWCm/7 a0gSlwqdohLzHdkvKYgUv0zWoKyWJ/6ZPjn7kb7sruG9w+Qry/M8okKYexeqHt1YqJpuK52z EllRn217JKt7oylTM8SF/26FGJ6lQ2uvM1IguKJ2b4uMgamEwHmveHjL7JnvAcXpznrerBmQ LuF6ihW1CXLN34ypnyO+vtAJjkKh1+iEoZk/QXz9AM5/4s0ztNdKWds+oxP8bfcMNCybl0ug 9fLIBm6zA20RUxp7+gwRKbCaM05DouaR9TeNuykMizO+v8W1FvdeJXi7BOx0Gau5PhNVd3f6 8kfuAtZDErsUu7T6rOiF/Ko9nTyNcE8HZgebciJaw55TTMDo1HfN2cxWIm76d/ua/WwVQ2qk 6ausjrgL41fDgtWne+ml92P8yUx2N22fRKPlfds5xkUwkGC/T1keXkFDkxpJ6dknOI7JmvE7 2iOzeyJM5SRs3bBxg4qRnOYVS9WCCR7T0r/yLN7hfBzFsUD181G+/UtQfqc94yRDefSe64up RyK1I22iUr3KReUNOomZOkPuYxSZxON/8YYKgtH+iNTWJ/T/Qn5xMkJoG6YHUdG8oDVNBWyg 55ZwFPg6AQqmZxNhASwBX8AR0AG0v5dmP+i6LQCVup8LcTPYvIErMc+BCcQR741NmPHBNWpC GBRWay0so4SnMGeuX7BiHYyvURPqXrlS1H79moW4EJGZEHqcLl9Cb8qjyjNYolbvQeR8wrbf mE4rt0yEvvG2w+ak9HTeG0hsHm6SvRs82X4V2RtTdwd/S7mbX7zJb1Ato1LIJ1v81JOqKm5c /ELmTWejDJhMpv3pbWqtPM4BBg1dpRGqZuWONoPwN28wO0Zj5/ox4Us84vFOYXhG+rS5DLCO 4km9U/Wr4D7nJaPBfjry2UoGL7bOrGcwh2CDWb5MLnEVsHDMFcY/0pC1L7VuW+5tvBQ7OOaC TliQSMvsLPfHWag+IulWSL5HUOnLaJAqAYNA8PCYn6jKvtOKEEYGOQ46sCADkBveD4d+jTcM hGCio0WONmgtC74EE0KHYGNk+TIEDKKn7eabxYrggG/s5YVLfptIj6Dl2EhZrG/hc8zZwqTm 4sMz7lzzpw13wJ02TGFDWMFxubJhMGA/QADwAAkgAj60xwUgA2IADggEvGmWK63dgfbmBgTm yYRJ/W15JQd6E11JDt5ugWKb8EZPBQERahZRd+Qbc1riJnL35Zs8k5t8LFEThrJoumJTXZha qoLNMQkSHnp92WkZzevg8ul4kpt5sSnpGnvqmO+7JMPshddlNnYvejiroQoVmg/HloEzE35D Wp5qh6qcbQ7GZmCYodHyBu1U5ZWRBmizJwXEqi1TsWSuVaCuZiEUkHssxHYaG3j5/luuUA77 qV9jDCKj5U0Zj9wyV56w/lCsJ1Y5V+VLYXoJ01pU8Ir+XavwklVYuF1/TgEINivw8EGadXal nz182IpiI3RKF7hfqSBVTbIsEI4MXvKUfUFHx3n6nEThAE9rU8c507jHadBZrqmP7GZ4jlrZ Zz2jULqcCX/cZFEeFSwKp4KFvsWIEUEFs9GamP/nKbq5In0nMJi+pGiuHZx/YyayfjWYQLQ1 v/YwILbRSq0KAo6kFVokBkWrrZsTMXG+TjtF2O4BZXag45Vixisl6cz5TcxaS5H77oRtbj1j /2K9+qObqq/4fS9JkyYtBETsITvywpcEatJ2BxAZVgjNj7ZUoE0LvFdRk6YprQ4PHspPRTsQ Cq8w3ToZsI2fCooyv4ExUofyYzimwkCOU49Dh8omm8DOAHcOHNfsfr/vJU16cGd/LH33vXs/ 937v937vve+mOTFKXtDwlzGhGZ+8taHHPXrMphVnDrS/2T5jlvejnX+95+YXNzq/emjhkbN/ jPU8Ujliysl1L5iv71hfX3l08Xc2jJxXKjgHvHPp40crZ974x/Mff3p8+YSrybDNenWMeczT 10bFIiuXfPLNjQ0HPe9PEZcVFx84OXzRHSPXbhzW9fKaxvO7St/3+UK9o87YZ9tX7dyX3742 vG7853d+Jl67eLrNN/TUiFl0T9Ge3w8c9veWx4tWB7qOf373wbnGu6bM3lK57aWGFXlbz218 +8UnFl+KO3unHr1+x33j9k4vP7Q/eUEJ/yt+1+0KBL58hdQuHEaUAwXlVy623/hiV8WSVTu8 X507FFYvfEALcUAYPcJzYAKLaZNpLIBwp/Y0nIHVIlhAHGgSRdFoFY2fgZjywasprFg+K9u0 ekkCAaA3lQe9IBw3bxHdCGzlU+cN0yB8SGy6mLegTTdkf2rhEXzpO/BvNayHbjgMf8LvnJXI bYJtsAteBopfbG/Dh/B//PQuNc2DAsNByIPbAFI3U5d7dyElTQOykG6UbjNKfUjKnrrSD7vS 252y9ybzBoOVry0UzyJ6Tfh36qY4mcmp8UwWO5EfyFf807yl97Xe3TnhTIX7cdzNhFkwGxSY AdORaqEOx+KD8DAOvxg0QxzH4lwcgm2Yr0fh+zAPHkNqwQE5Hx7HEbkAh+ZCWIR8u45o8hIc o8tguf58Ap5Efinel3HuKXgaM/+DzHNF5tmHrIRVSM/gfTV0whpYi092z8VyJRW6YB3W84fw bIZ/9pYo45+D55F+BD/Gqv8E+Y1Y+83wM/g5R7thA/yUS1thB+o35NgyXZ/9L2ALWm2D7Wi5 E7tndz9bZrkVDsEb2FO/gzex2w4jdwx6kD8Gf4bzcAG+hIvwN8EjjBcq4Spch9OY/RbMOsv5 fH5vw/vcTMYXY27TmX0KM5abh0W6TsvnCp6ntG4xWnZiNVZkrVF5ndK+mHXaV3a+2JnYifow 7YTdGaTv3LmrNLvsnOVmcDNHcrX9M5vNb/9WzU54EekFvLM69JfS3Ev4hjPaA6/Aq8hp9z45 ze2FX8JrOAsSsB8OwK/hICQz8q9Q6tPv40ja5tb46/Ab3gWH4Qiv/2/hOMcOI9ejaw/rmtc5 fwxO4BR6F07CKXgLe+cEp3fhD9gf78FZnFrn4FO9gz7gHUQED5yB94xu+Mg0QDAZjsAxcTos QflDcRNWAkwXYIAv9PBDD855oFGRZzbUh+tqZ0yfdn/N1OqqylAw4K+Y4ps86b7yeyd+b8I9 4+8uKy3xjna7RpIRw4uGDLIPLLRZ8y34dcn/t/cGSSgiUXeEGt2kqqqEySSKQDQLiFAJoVCu DZUi3EzKtfShZUs/S59m6ctYCnapHMpLvFKQSPRUgEhJobFORn59gCgSvcz5aZw3urlQiILT iSukYFFrQKJCRArS0KJWNRgJoL+Ezeon/ri1xAsJqw1ZG3J0NJmfEEZPEjgjjg5OTODXUSHb lhpcwWgzra2TgwGH06lwDPzcF83zUzP3JbWxmKFLSniPqOuSdmiKeAqaSXN0jkwNUVykGoKq 2kkHeWgxCdDiZReK8Mhx6iWBIPUQdFYTzmwgUJPLTiT1a8DgyeVLuUhUR/Jc9q+BseyImTSh Ps0DxoYR4vmcThZLV9IHTSjQjjpZkyVocuwDX5lHoWKEaY6kNbfPZJqOtCazPEKcrFTBiH4t ai2iHU1SiRezzy8XXqiXqMEdaYq1smc0rpJAQMtbg0x9AWR8Uf2swcR3y9A+GsFDtLE01Mm0 jMynQ0iFZoCAxGrQVi/zJfoyOsRPIRLTV9GyYIDFJQXVSEALkPkidXIPjE2dT4yTHPvHwjhQ WBx0qB+L4g6qcnMLHR5xNGN/tkiyw0l9CqZPIXJcYVUidlp8Hrdz8h35KjxbP+u0MTu52WWR ZNFhUFi1EJBCeCMV5aiwY7m4yCpaUS7JggPSZriLbsG4HD8oGFz+KqYysKX+KodTcWqf/xKS Q4/J5KKWLF92BDIxaft8a2iaNQuoWArGA1kB5jg16QHq3m4dp8hyoW+MKyysnFVplcGFby5i IrrhEKtikUShVpJJnCgEe8hXK7OzsVzz+tbUk5q6RplXW++ShhxJ00/QJApOVKcF0Y89GPI4 0mXlciWXM2JVP3V1Wi2pFlJTrzLnRHcIEr5BeOg8d3W0a8LgcfhqhnC6kVCUSHYppEaTqY4m NeHzqfODkdaJzAepblZJvVzu4LGG5eWOZWyrwVAj1DRUlHhx9lQkiLCmLuET1tQ3yj12/Od2 TYO8TxREf6RCSYxEndwjAfg4KjKUgUyQmMA8hVGwcHtHjw+gg2uNHOByLCkAxyxpTIBYUtQw exoTETNqmI9j7INFKmrFFOO4DUrNrDxPKq1qRGEvFwzFUuIlUIFMAiqSSQlBzCugVhKvoDZS wfDJDJ+s4XkMN2NjCEMFTA6bSWqE4JzChpLBIWitaGAupWQq1SA7TzkuK05stTlIjTLN9+Ds N7mmol0lowjClbQjFmVxwEyZrTW7qmMKtm3aIZpU03z0kK97QIsQX8PaERfFsDZYQL6+AwXa oVDFwzaV2xTeznYKVWQill3zaXKzjcoUdTAZw99NfBWsrk72yMfYoF7WEAeKuJmiJclcgJHH CKpiEQmzbYRYPba6NkutDg2J40g0uuOcrA5dCexYBpet0ErzS9EhXoy3lbJX0uQyK4oWPJc6 dQPc205tGJE7K5X6AswOqqpZLHh1YqjM9ChzU5eEMFmCk4UFzT2ZUU0LXdVRHP7aehsiZEJ6 sYXNCJvu47iGmtnJCzDvBldDMrWbLHVmfUq8hH05sMYERw82Nihqf4A+4CnxWvqjhRxWVUvh rRdo+bIUZp4IAvslqf2OtG67Oe6mzTrEAsLm7B9MA6uNA/ok4TSAcXvqnf+V8hypdkbGRmgw lsKCW1C78RLInFIwmZHhIshIY/WnH+lepAakaTqm0V4Imwrgsf5k/AbCjEw+aBeNEBb/w3i5 R+d0pWH8OXvvcxIGdUnVPR1U1KWUVrUSoRZpQjTRuE2niTBCVEziFrrcImEYK+2qy2iblREM Q12GTlEaDMNaMmi1M2hrWtWiqPtI4xLfnmefcxLpx1r1x2+9e+9v387Z77ef5yj9BGN9xudJ e9Kf9CPZbG/MWKgWsl++/oisUq05nsjXuIZhuB8z0UIlY4hznHO3fgBcy47E+F+kF1oZnCsY r5pzreZItBNYHsKyR6SJ8s9QHvonRquyfhYrSX0/LrabY9HDov6IPSHhOBGMitCfca7dpJsf 48louVuf+xk39LaHZKv9W73AoBRi5TqkPwg1Ev1cshFlkLO47iy09+PjJJy0I61ID789XiYg Rs3G6/cxme2GQgy1LiLGuqh7MTZhfIlEkIFkAMliex3GfNUYMaK73kRmyRLEGMS3iHc568er eEIeRbzjoI+a+gDSuOa7GPaL7ECsgfMMl3u51l70ViswTP7AskdvN0ZDeOir5HJlfShmyaH6 FuNEMlPNwfQgJjygzUVewhKnGVYHIw/pr+QMzCV1/FidNJDp+lpVVFMkBvHCA9pcnGroYGA5 Siahn093El1RD+mDfs4h9LOvebhjM8lo8gwS5Oc854dAZOkoJ09Hhe7SUWqdDndyWd7JcmQQ LwfhtzuTg5gfhN9e2T+bVOMavarMnXtvLnXaw66uo0LCWW6KF4OR+/TOYNge7dIG8dYxRFvH tOEmSSCNyTiSSJLJPNOHX7rRzN9W1gXdrQK5ku/ZI9qbB+1FE3e+LdYd9BR3Ee0k+Wvdo60b 8/V1NzZG/yA63tcWyfMlTh7LTfVNDySKXYj20BeIlk1RzUNfJ9cq6vYqD9VVt7Wu6UZiI7LE PrIRqaIYbdRZZKlJD4ddD1khfZHlfPlwcJ+ZJMGPBnNOr5M0kl6lPVO+jWn2R3grGJmtj8jF eJRYfjSEySdh+8CN45ElU5Ejp+A34gu8L45imeiJ1W55OdZYe3Qpy38VX2GZNRwrrAx9XixF kZWMItUPReIEOca+xzGZvG9dZb0jcq3v8TF/2yPm4J/yCj4R05As5uIt0RXTRRIgJpHFRrXv hgLl58Sg+9vcPaYQt618GRkV1FZI0i3NOn2BXEHWuO0jyTDZkvOVsq0PGeW2F5EZMoL1WDKm co7psgbrj5A6btt6sla8zfHvkCK37Tz5TtBjiL1kC/vuIafoOVz3UT6APG2V0IccI5948Fni DWKSNuNPipn6NuNFq0z/IJ6u9CtLjQeRr1Bf86hjrocI7Dea5vmFwFb6hfGeXwjsMB7B9QFL 9KEKvec7hqfh2nHHULvlOn3D1+Gd8mxgAWOSE8Y1qacOsJu6XsNOCJT6mjjVaKG4YzRGf+pp WeAz9251dStQojZjmKdbgZ3UpiRXj07p7RW6I/+AX3laorupKawbDXlV33R1IRe5MjewkrG2 zTdl7nV7CAo4Z121WSdRAxJdnmeev6DLmNdTVEf2W4UOBnEAz/DejXaZgh6qJ8aKThgpOumv yRuiU+CKuVPkh7yr+nPNpdQUQZ8m0bnyThgLW9XV/+bYvjz/BNmQ72kgJvmkk2p2N973XRDH 555sr+V/ayEGGcR89yyryxvuWXcRNq4L23qOOKKl3swc3G9pfck9z3gMdc8zk2dgmMwzitDp VbxjkjOad8+/IOl7BlTg+8H+xutV+q3v9UbnNjnu+cYQec/HqVveORuvWuG9VFdquGEb9tqL vbO2m9DflpLx2OVcR1JIM5Z/xHKnAX1tDzIczVQqMkOqca4sfYc+t0hdx3J6Rri5cZn6Z3xS GM/TEMF8mKWzq/ihdvYU/SNjLTWfv/n4Hmeg8S/yAPOBqE56rZsvk31PUkDGuF4jxvVdFT6i kF6P/0zVgR6yupcv6k3EqXSezW2857RAnNOb9RS8Yedyb+fIafqwqxjudOBcvBP4W44agdk8 DzgW1+3ENY2O9+JvJreOcq5YejjCe89oUKJ61r13X6yq4U6cLqXPlv6dazTyZV8DM11N20o9 I+pRXcx1iu10OOo56lhrX6vCSRtXx9KMDrkegxpjdM7pQq/k3s3Uns+Zbyu5Ju9uFePf7/9A qunjpPJbJA6D7SSMlB8jTS6gTuXTm+9jzh/UZ1RfxBttVhEYJcfx2XyYq6sMooD3cQH1rwAZ cgtuk+YkWn6D78QwFJBB8nf4mlrQkXm8xOS0aIkM5nmcPQexzO+LZCbRZCHP6DyZTcrJEjOG 3u8dsRXTyFTyJ7JINaQPbMjvnoZ4l8yTjXSWOKnfk3/DOVluhcp6OCROYq+YgJdImiynJpWj UUh3rCI7KqIs18lsP839rCHbRQYmiQx9QkxEWzFR7xd5SBN5+rTogXGiB7U9ju1xrGdgHvtd Zr/u7PcF+01lvzLO9RP5LxlJeqtN2K2iUMRyDllk7UOZfBZlNjXJpjaFlBHqRkikG8OcDSgx 8Pvzkv0XHLPXYwGfF9znFfV39GV7O85TnzGcd1YYywf5W5n5XmU5je+iK8tx8n9oKZehidxF T7uMz76MeV0DY0Pb897ge3C+Zc7W0VotxqviIJIlvwvkRf2NGsg7+rj+UnXBDPkB/wddmF9d eL/V4t1YCynkcVVL3yCHySXWx5Bs8hTrt/gfSBH5GCpzmEcTUFeu5/0xmnm4Da+5d6PJj2K0 5n56k4GkNmlMwvyYQPJIC9Kc+xvD/eV7+0NN6tMj8jhC/f1N9ffXmevH39sfv1lroQFp6u9v tbc/PCl/je3WTebGJuSJDcihl8gVqzGHuXKAurxTnKJPOUkuYD/jfnEEH1rF+JT8nmMtjg0T m/QhsUGXiBP6oFitD7NfbY61xSlq70lyATXZVlMc0eUc95hVrLeJQn53laKjGKDPilhqSxxz po8+KRKh6F1qiMH6jIhnPhUyR0rxgRiA0SKW7zKO/qkPvWEi5rLfm2IwRol4ZIrNgTOyng7Y KSSdPObHp/Rd+xVSgmSXUYi3t5EV5DBG2NOpQytIG/0f+rnU0P5ItXMwIuQwz6zcJYV0JpEk 9v+kl3twFdUdx3+7Z+/eBAKiYCzBkAJOCA8BEVCQ8FAEgggBUkgES0VAXtpGCwq26Kg4mvoY FW2NZaxDBSpqYWqR8ggPHVoIg7QaKFArrfISAipSYyH39PPb3XtzG7Wl0z8+c/bu3j2P3zn7 +32/MAKGwQRoDyaNUbFj0tWLyXD/XXmEvS92a20598er3lAdoDXTnyYveSV2k5ctc/jmKuE5 2B7QXH4db+70S7ZNRpGDr5YX8ZYFTgVaZz85dfr/izM60kPnTVRTlW+bo/YcHIPPQqQ/NfVi yEvWzK/loW+gvTwTsE2WfB3U202Qp22Dv7Tr4WlYC3uje8ehNuK43kurLz3Mn+wBWAH7oFrv U1/yIaPB06AF29g3o/bj4N6DX6EoaJP+YH2Ksqgdqm1Ubw5o6023bxP7qyMNeP6EtR/sJ7AW XoUq2MD9C6n9mdAy1IMBQ6APFEFY+w98A4vkx0qsmTzciNu0NQsV6iXteZ27LdSVv0pft1za wSz1s/RTEvGA9zBzC5nDXt6Lx+tITbtKfazX3xYm8ec1gLfMg3aKP68B/MY494isQ0dXmxuo UysC1pohUmMmylZnmbzlVEs/9yDeaKL8wbtdNpi5sh6q8VlbonYz9fgucsg69NYm00FOedfL IbcevVsl+/Egj6BF/6F40917IpopZovTArqZLKcD3AAudFavAQWOdZrClZAPQ0TOfq64r0hO xM9gB97lkrR7IffhBe+TduayxFH3KXzBdGew+4r9JSw1nRI1cNhkJfaaLPuhqaTtmDhOzfse DDaV6N9K1SPWMO8FyfnDOxFdFMa9kP7eIE93oX3ZfcVpqZhKZyQsFEn8POKaiH4K83sMqhhr OHtezXUR/8+AfFN57pCprG/GHP7JHLp4aDTPkS90NvQ9CO5k3Dpnl5OFDzxIvDJ4fwg8ophP 5f7oeZPI1xVwv9islsvCeDl+fJJdE58k78cnOR1o18Hb3HvJ3y3v+rudGL9Xw4cwyPlAquAv zhGpgdNSJ9vgIzcu++ALN5M9zmS8JbITPubebjjJvWo4ZjJlJ3zsTJZqOOaMpZ+xctp5Sz6A emeTPA2r0Ol/Mx2dTNo/Ag7RtjMbnZ5eDuc2h3qcbT8j11/AdYsQ9EmOtCI+p4lPC9qztN9y JtvlrPko62+psfC2UTfU46h36GYT6j/wDAPxc+PxI63IuwXeTvLaDrnOvGYLY1novwqZ5xZT D4cwboEU+yvluVgBz8i/6PW70Pbj8Tuj8DGXqG/Fb4xXP0Ntmqo5OMi1m+xR+oxBEdoiP2ON lGbkSKl/qZTGhklp/Lf4o4vwMNQFfFS/ILcnc3gaydrht7E/1LkF8yto8FU6RrJvfRYvIIe/ J01iBWHf6XWHcQ6pb0t5ssi3JcfSvtS3xS6iD/QOaziUfL9xHWKNvXl2DzGdYG7GIxy2Y8nR +7yb7Fn66uo9a3dS13qqP2ReOlYB73QL5oTfDKH2dMMrnGBvAsjvYbuxoVbaW+Hy4Po15qbr Pxf6yxD7OLzneolsXZvGJsS+yLxKYZC52Y6DIvWlSTQ+IfYMnGy8vsCrto98bcgYr9QuC7xr Y9j7EGJw2PaOtbfH4TfwUWofK6hpFbIlnicHFPW6SuqshFzPfAearbard6XcypgDYq0YezI1 +O/U0nmSTQzi6F2t34UBvaRQPVpQu3uQz8vJ+R3Q1d3tl2YpmmIw2vwNu4b/DfRO6v/wE7mS S90oV8gLJaYT53SFNDG3EPcZ4senMt5m/F488IFjqC0TghqeK3NS9TqC+t87qSf8TOkeec5r Gbt1Ug+YDXazek/tN3o+MPlOUlswxjr1qcl3qB0DldQ49EF7jbcsOJuddc7J9xt0RzTeYmnp Tua7/JUUuo/Kpf505qZrKrFzWXuvYL2L5QX0y1qdl6J9uVXWmjXS1Nwp2/AFWa61nzmn+d1J mno/lQr1pcRvcyr2uXZqKvahdrozassbNJNljra5XuveaF1Pi0EE31Gu/YGzp74+hDOwVAaE 2CnE5gwscfYkboAefgl7E5HWx0yY0jgW3KtTwnhSE6vs525V4gRxyGwM56EkPBeJg7BH5wTa 9/zUPjxl95qn5Efo/CcVc7fdHaA6rROaVmPbKXGGd2a5r9tlwX9Uu+k5+tTmcB778+wXPMv3 hnN298MQ3tnKWkvEcU+iiVtz7q8hrjeiVzmzfPtFZqU051uZ6d1N3F/nfp30Rbu19abJ5aZC Bpti29N7QGabWhlL3p6NnnPNdhnqfxd9Nt/2Vw0XW49ea8K7R/AeA6WtmWjrzBTaMurEavI6 Os4sR6/NRK/NFt88I/0gO/5nGZmxiBx4U+B3Sv3lMjQ+g+8KbemcsKE+jHRgOkn9GZtkf6Jz C+a3XXoldaaZbWvju+j7O+Q8nvnXoTXvkGxvvgxtrF0ZZx9rGpZ6V9cAqbGYL/lhmPecDDcb 8aTPs4bo/TRdG767UFrwrIzatQFt18eU2Wnsf7Hn2Xr6amtqbQ3aeKI7wK6i1ulYl/FOR/Mi nvScreObiJv+EuebuB3t94KOQw0sCrG3sFcz2ZeRIeT0sN2VpsOHm/sT9VyPMMXMWWOjc09h F8G9zomEq2smZhH2NuZ7o3vQ7oM2cInvs8cRGrcQuxwWf2XdW+ljaxi3iCvMEbuAs+B+Bc5E iBVTljjtLbJLYAo8kYp5rbSGZ/22skwxO+3+gIXRGQrJYS2P0ZcE/1koMzRerCPbPZh4PprP FbruYI26b3rWi8k7bxKLwgZN/59I1/vfhDdXyv8b/r7z4CFpl1FFHluJj3iQ642Bt0h6jJTX 8EZH9E+hz/LwHudF6v93Q6bkZVzXcA/vmOrL+0jyYk1CqK15aeP927j/6xxMDdokzO2DQPOT b16I8n0v6skqdKPWv3PS27ws3cklBp1pvHwZFdWUoBZ6ZTLaLJF7zG6ZFeXRIGeT0+sUt6dM 05zvHrEg+Vx3xd9pfp8boTk4FtSckVznyajYzTAa+sgIcvr+NL4g13d1n6C/J+T75OoC8yrz zLXvM6erQqSPW2H7keubwgj6Ps75u9YrkvvI74dia22tWWwPmTFyV1BnhfxM/YUvVePBOshh vVmBFqyhjzbUftbpXcW4FeSTpeiZ1nJ9UKMXc+Z5x59AHd4lY+LdiF8t2uMdKY8tgM+t5vQ7 vJnUvVN8A6fIgbkyWTF77O9iF9hHA21xkbQP6m0vGcxYfflOr9WYE8PDbke7irUWup9Iq9hM cuHVMiDQAuwZOmCst0LGofeacXZ7o3Fa8KwseL6CMXdQB3bIRPqb6vWVBeQrN/Z7uRzN8B73 n/Sby+NmtD1luhOHIs7FbjR7DeeBuXmdeZ8+Yt3lMe9i8ukZGYfvKGMf1/2L9rKB7vG64/j3 ufc+z0OT5rSRnhlHHUYksaJovMxbvQQ1mmQRb6HBvHRelqSUqZEymoyqZWrCvCRESAVJrdbJ EDNDHRQZZXpMJWXV2py/zNRy971PEpWIsFNyzuf87r3P/f/ye+5z7+9+f2STHIAPxSaPVN5z RXIE9lkb8SfrI3RmDigUI3BQTUGBnI5dZA/5SOQjU5zhszPYK4ZwrYOwR/VBsdiCpeSUsdKH 90Qxfkc2iN/jfZIhZmAjWcyxDGssfiJ+g0wVy7FzWCNKsE0MwhzanV67GG9YnzHGK9jH5ws4 b69YgIPiJURw/ySLCBSI+by7x2GXeAXh1lj9D6tUX+H8AM5ryH12gnOeFMXUA+PgUm+lOC9z b69lnlxLLXVKO04GoNIg1JqyX8pGZTeFr+ymnE+dcUwLaoXn5H69Qirk0550hiGR3/GWaKtv cT8u5Zq4HmbP9+Qeeo71Vz9+72voZpXp487PeQ4ivHPkMJbrchY1jL/uYLSJLKQe6cJ9O5v7 rKDirBot5p1RfYrtNp7GGqZPi3Z6jppFXdOOd0oxPuAabfDIx3azllYhtVchvsNvkW3WykrD BCsHBVzfDK9djHYWtaT1BmvGZtjC87mO7BUl+j9c5018v0yz3jIcK0QbTLWm6Itc9+X0lcRv tpTPPibnuaaDRAfMFMvIRpJELV+Cw+Is1pJ1/N0V659YQ2KFJIuwgWtxVCxEqrUfWbI9siyN q2QuWWwdxU3rqBUg0nGLfCZvYwhpqgbwjA7AFyLKmiFiARFDorgvW5SdFTFlX4tY0omxEvpI JCkiB/OqMULkWH5iNPZYoxhfG8wXs7nnzf95Csuro4ZUhWO9aO9H6+pwvrHNq8PxBrT3wPGe tDVRPY77zetZSxw1jQfT3sO3jaMWv9+jvYda4htAWxMPG8f91rkZ7T3UEscg2pqoEgf31xgD 64iv1UrrCWons+cGkhdIssev8AsRw/qr0Dvvr8qVZUU8fzv5bMXdqB56IVkjBXVxC+SSLNkM cXyW4wbiPNkozujrIoP8lczWGWxfsD6xAioIMYhUq2MFMwzAf39rkKFW/So0swI8Qq2OFbTx qBz3WX5VaIYbHi0A6Q9Y2go03OM31GpLnr9jfVhP4ipsf2qIMDEXYeY+Vq1Yy7TSZZWWddM6 FVt2kLaHzEUU52SrkQi3l/FezMRcb15T5snO+t+8f2LldO1TL2KyOo02vC8jeO8Gq0A93dy9 ngbyrD5mtIecyXxt7tF0fU0VsJ3J79EfkeX6R7c0PtQqam/WBJ6u9Sw1cjxiZHyZJeOpd00N sATD5UXqs1Le/7eYr895er2PytCHSRKJq2gb0si0u/o1cd/fOF3ukETi7uqnkWmmLS/rYrVd jyeJbGvahSSV7W3kS3VbX7YP6fH2n3WiHa9zqQGFvV+/SVLY38LnOeQqx6O9ufv1aJJQ01wn D9FOnr7s/kyPJgnuMzqXY4LtN0kK+1uE0p+LI3ocSRATTR8W2wtICvvv8XkOuUp6k5l2F/2l o/RbJJHf26XNJqkcP26e8XsLWaJz7UD9Ltmstupd7A8nm7lPmpKBdiR91KOPp+ljh863I+mn Hv08TT87dB6fFxEfx/0fNNcphb9Tynr3Q/2Wu1MnusN1Psdc9rPZT2U/jzVV1OPG0wC1QK3Q /SFpSRr/PxidXztl14z+YXvQN2O6PmFfjzTnrFYC9UmPwZj+bbDTEPu4kD6983FgJzwYmUwN WAusgfo+SuxLD8a6+iD0U8RXbfx5jv2IJKh0xNcGc2hfjzlY6OXcR2/rMYdfpQ2m1SoPgY8S J/TBPEzOv5OHK3P2KyZHV83DD5XH3uY9MU4fIkkkjhyuII1M89oHmM8PMJ//Wo9332GuC2WO P8B8voT5fAnzeZje4jaAv9uA+fA88+E5zpmj8znmsp/Nfir7eZX6o1J3yJWWW0VnVOqLu3UF tYT5nWzBOf5Wa2qCJqwPepOBpJfdFJGqB4Yx/0fLBITxno9yNmjNOleqZcyRQ7lOhtvIsIMQ bechyg2nZvhuua7gvbCe7CEjVYI+bO/AGpWK3SrJI8p+HxMMvJ+inYncD0M5FqC30l+UB+e5 Lm3FN3Ia6mnyMvtHqBOI+Y2JhdiMNdqDmqYSNQbPqo7of4ckjOV7RDr1MVQm8L5lTKqF/pjv 19N5kXTGp6oTPnUu6a1uQ8bij6l8r/X038uLqxFrv08wlVrlpijSX8m16O68pG/IMYzBh67y A3QzqN4YokYx759Bd/tfrEn7UvMYHeTHM7Aa75BOMl//hfVmjCzGaLnXo6vKRg+D5/MY+010 gepAP91Yf3KO/Spcs1aMoz+JcuryHjqBcFOjkrDyWFjfFui9JlYyycv1jcuRi7RPLuMZXIYg 8gx9BokidLNjeHcU6ZOM6ZCcoY97vlvx/VdhtdyN1U4DXeD0YxzDWA++yZjN3deSsaUyV1xG fy9nBKGDPIJ+9nb9BfNjgDyPCHkQfUiECmbMG5jn/o6+zgDqtEyuv9F2w5Ds5YY5mCSv6LPq GBpRz600qLqcf4D3JjF5zJ5Jv/SnhlB/vE6f6Z72W+k05/+pzOtxehH/d0/1A3zf4P0mmd9m EhwTq4fJdavKkZfwLL9FGAknwfTXm+/R157PdwrSV+R1as8jpATB9utoyv0wT07APLtQb3b8 6Ws51/dlvsMUtFXTGBeAOqTSim2E1hrMsUjaApJOUPmn/0aaqwAYWpJ68rYeZWkslkORwjOY Jdsji2uXxXfexWc+8RqeVF9hQble5xnLheLv/JwY7rUQhLgDEeO8gBi3MULsGxisQtDRnMM6 mxBCzb5VzUNvlY9Z6l19hL8NNT6cJphMptozUWKvRom8jYauhQLariraOq2ieV6hSykj/1hO ZVuXunWRruKw2ZxnnrFodVx/bo/B2/IQ4hnTFNUaP1b19R+o29srP32BOWSiDNbnWMNsImsN Isb6aQUxHjn4oUFdwGuuD0+4FxHkroB0JyOJZzTK9mNOzaY9COV2p047rHc5wB61E/vqhJef fTPXYN7PHo/ZNngu2+n99jbaZL3P8eNZHaN325tZg5zAaLfP/0iv7+imygaO4/cmbZGkoU2b lFHIZYosGTLKKJTVAoVSxi17lU42gTAKKWWpoAwRirYiQ6ZBhYchgixlORAcDClLARUUlCXQ Zvi7/V3e95z3HM77h4fzPZ/c5z7Pzc3NbUL4/6KQDlKSNl/7ew3ZIg0PPoD3Gf/fDL4CbwfO hai47/IC14L7S4VGn7SizF3MicZr3YwwH9c023i89Hfp6aCBksr32N9LPoV7oaZkk4/j/U+V 1hm2+2+Y1kgXg85Iy/A3OFcLjwWcoI3/v/B7sgZuoNXwPsVvwgJ8lhfICfiMr6DXt3RMf2xI ka7r3wODjfvlJto1Dk42WPC5P0qfm4A5i3Go6qirXjvsU1H5ZyvtQiswdxrKxSuMQdb/nE+8 XA/jNY2HcT+HyZK2XVqB7DB2gVrr8BgZXNJt4zA5EfNdaAZqrj9+WqEWfodMR/n4LbIav0Ma onzc521RyrP+r/es/2/pn0GlPev/E7jOjbVrLi/0zYYDJMlrR7UlqeQOrPbfbW8UUlAswp+6 F9fQa0XdkBm1RngJPm37MfMvQMeQDSVh7Br210HQXxXuQ49QT7QEY2loDRqNNmH+JeZ3oGzM qaqPXda7gF7GeA7ONx+Pb+IxPpG8eL+8UzCG5y+ZiXBsL97HkgS0CK1Hr6EijK/FGhzbi/fA ex3hvfHjuvi7o0loA/bPQ/u5pvQ58UJ9eegAwrF8ZzDmRrsx5wR8gnX9kfaahiN8OvpWotPY dw82YN5M7BuEcO6+FIRz8waQtgb7/emSVNwMxxyMlqMefE3FTeFWdFXfh2MXt8P8sqgLikb9 0EJ0BJXj9feHo0T92GMQPl78Hfle+Ify+X0n8bgDwnXz49j+AqTo+/Fe+XE+Poz5ziPtdZ1F uGZefCt4z+Fcjun3Do7jfYjHN6AF9UY5+n0zEWu0ewLvhz9Pvw5PG6vXQs/NvOOYb4dekd56 vaN6N/Sejqf/T0uZF++rV7vXkplvI7qFDqI7PLYfX3m+67xu3mK0Q3cnxhP08Lp8Q1jp/aKV ynyxWvgbXlj6O0FPPht4bDwSGIz2Py2oTSA2ZGogFp+BO//lP2l7WeMeQ45wtFX2GKaTacJh BlPJFOFoBVxkMqdMEo7WwCkcbcBEMoGMF45YMI6M5YIxZLSo0h6MItmiSgeQJap0BJkkg6ST NDKSC1K5YAQZzn3DyFBRuTMYQgaTQWQgGUD6k34khaikL+lNepFk0pMkicqdQA9udSeJpBvp SrqQBBJPOpNOIror6Ciiu4EOpD2JE9GJoB1pK6K7g1jShrQmrUgf0pLHjCEteLDmpBlpymO+ RJpwXWPSiDQkL5IGPFh9Lq/HdXW5rw55gdTmzOdJLS6oSWpwXXXOrEaqEoU4SBVRKQlUJtGi Uk9QiVQkFbivPInioJ3YSCT3RRArB8O5FUbKcdBCQomZmEhZUTEZPCcq9gJlSAgJJkGcYuSW gchEKkUOED/xlS6QvdwqIcXkCXlMHpG/RYU+4CF5ICr0BffJPXKX/MUpf5I7HLxN/iC/k1uc cpP8Rn7lvl/IDXKdXOOUn8lPHLxKrpDL5JIonwIukiJRvh+4QH7k4HlyjoNnyRnyA/meU77j 1rfcOk1OcfAbcpJ8Tb4iX3LmF+QEB4+TY+QoOSKi8Lkkfy6i2oHPyGERNQgcIgfJAbKffEr2 kb1c9wnZw8GPyW6yi+wkO4gg27luG8/lI259SD7glK3EQ94nW8hmrtvEBRs5uIGsJ++RdWQt WUNWk3eFPRWsIu8I+0hQKOxpoEDY08Hbwp4B3iIrST5ZQZaTN8kyYR8B3uAxl/KYS3jMxWQR D/06F7xGFnLmAk55VdhV8AoP9jIPNp/M48y5PMocLp9N8sgskkvcZCaZQXKEHZ/J8nQ+wzQe eiqZwmdw8Vwmk0l8PieXTyQTyHgyjowlY8hovpRRfL5skiXszUEmyRC2OSBd2LR7N03YZoGR wqatS+XgCGGLA8M5OIyDQ4UtFwwRtrlgsLDNB4NEJL6E5YEi0gEGkP4i0gT6kRQRia95WRWR +H6X+5I+pLeIxNe83EtE4otdTiY9RYR21kkiIh70IN05mEi6cbAr6UISRAS+N+V4TunMwU6k o7AmgA7Cqv1RthfW/iBOWAeAdsI6ELQlscKq3a1tSGvSirQU1nogRljrgxbC2hI0J82EVXui pnyil0gTYdWuYGPSSFi1C9mQvMhzaUDq85Tq8ZTqkjo8pRdIbZ7E86QWqUlqcEF1zqzGU6rK k1D4fA5ShTMrk2gur0QqkgqcWZ5E8QTtxMbzjOQTRRAr14WTMFKOWDgllFtmET4EmET4UFBW hA8Dz5EyJIQEc2YQZxo5aCAykeICMIB5fuhDXlSCijH2BAsf4/Ej9Dd6iB6EpSr30b2wkcrd sDTlL/QnuoNuY/wP9Dv23cL2TfQb+hX9gvEb6DoeX4M/o58w7yq2r6DL6BK6iIrQhXKZyo/l spTz6Bw6i85g7Af4PfoOfYvt0/AU+gadRF+jr9CX6At0wjJaOW4Zoxyz1FWOwiOW+srnGPsM jw9bxipxgUOWUcpBS7ZywJKl7MeeTy2NlX1oL/okdKKyJ9SpfBw6SdkdOlnZhXaiHdgWcDvm bEMfoQ/RB2gr8qD30RZzrrLZnKNsMk9XNsIN5pnKerNbeQ/j69BatAatRu+iVegdVIgKzA2U t9Fbpk3KStMGJR+uQMvRm2iZKUt5wzRHWWoqVJaYVimLTauVRRh/Hc031lLmGWOUuXKMMkfN U2d78tRZqlvN9bhVs1s2u6Pdie4Zbo+7yB0XEWKaqeaoMzw56nR1qjrNM1Xda1ggZRhejWuj TvG41CCXzTXZZXzgkj0uuZNLbuSSDZIr3FXVZQydrDrVSR6nKjmTnXnObc6g1tucV50GySmb 9gQO7XBGO+Jh3EynJTx+ojpeneAZr47LGKuOwglmx2SqWZ5MNSMmTU33pKkjY1LVEf+wVzax bRRRHH+za3sdO9l1PmzHcYqnCS0NJs5Hk8b9jFOnpqmb72zJB03qxptk1dSOvJteAMEFqRKU cuDQE+qFQxUJOUKVyocEFy5AlVslKqWUM4qoEFxa0vB2Y1CFqqocKkB6s/7N+783b2bfeNfj +Bl1Jn5anV45rb4an1SnVibVifi4+grmn4qPqerKmDoaH1ZHVobVwfiAOoDx/nhaPbmSVk/E j6t9K8fVl+Mp9RhuHup99bxe9FkFDNRjJRBmR1vDifDd8L2wA8LF8FdhsUqpi9QJTUqIJQdD LB96M3Q5JCq1a7VCorbppZQSXAv+EPw56KhOBJtiKQj4Ajwg+q29BfrHUrbt7t22bZ32XvsD jbtTip8p/ohfOBbxM6i8W3mvUvR/6VvzCYrCFGVLERIKpityRBasbksWE3JbV0qpiFQIVrdV IQYSFRixVnyhfGgspXgjXkHt9g56hYS3O5lKeJtbUyAyzhgwHxrRbVXB/JEU/q4/CTAnw//z 1bHRaDR9Q9oaSRfdQ1NFdrG4a9TqE8OTRdfFIqiTU+OrjL03scqE5FixJj08ue2/fekSHN2R Lu4YHS9e3TGRLr6FImGJLRSwYzUARyei08ayEY2a09hNG2bU/qDHli0vagWtj2Gib13Ltg/R J7btNDQzBjbzz6D55Fn/28b+7QL+4612ZhoAnAAPDfG2UwYRJDgIKpyCwevNgeaA+1CPh21A H0gsCwJw9i64gbFsosoh7OpyicPhisqlYTbcKwlj0L1+Z/30nfWbaG+ylvWNWxu+zVsbVfv3 t7S0tbLKnZU2NbIgSS5XY0NM6Orat2/v3vYjQmdHTGhskJHdnR1HhK4j4t725wQ7dTvTjmKy FRVv/z4lDm66hNcix3IDzwuRsFxT7mTcGQm6Dw/GqpWdnXv2JFoiksclON0ud9OB3obe6QN1 D6+Lklfy8ECgTnY6pHJ3GQ9Vh2THw5RTvv+LU36QdCw++EBs65gf2ee84nELDpfri3Bw18HU zlCUVyvVvnLZWR2ocknVVd7dh09svuMO1gUlj0cq93nKamsD7jKPq9y3GQe7sSGCIAiCIAiC IAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAjiaQAZPsZeBKtl7d7SEtxH j8F2a2fTJS2Cn71f0g7UH5W0C/VnJS3BG2zNWsVRhpF64WRJCyALCyUtwovChZJ2oL5a0i7U 36BmqLEe4deSxnrEcbgGHNqhFa84qn7QYRYKkAcDmQMTY0lUBViy+wxGdFQ5iOFIDyzixWEE Y/OwgGOG7WloNcy+gH0WM5M4bxFzzmJMxwzdztPQmjjLyuSYwdFquI41atpRazZHbd03i955 tAU4h7H8X3MePzr3j/ZiVZSz17Kq4aCip9s1WPcfRZWxPcO+Zw6jLaUK8o/sYBa9ZRw17V1a 2bFrvL21Nc779dlC3sjPmTyZLyzlCxlTz+divGdxkY/o8wumwUc0Qytc0LKx9EDP0FAymsws 6mcLenOfiWL26YMlj+sG13RzQSvwDC9o87phagUty81CJqudzxTO8bw18og79/giuZ7juAxX c7qJ80fNjKkZPJPLtuACefsGs/nlnFnQNSMGaRjAd2IIryRE//bUR+xnu4wR6yk9KbMZ+uxv fNF+fs8ik975Z/jOWyeWssA4+OBHPGMEtC1wBqBsgw3gucTsE8354Y3vGz+9PKMc+g1CbvuI +/yn17+z7NcNV5bud2x+66lx16NrnXH2GfiHAAMAcwOJegoNCmVuZHN0cmVhbQ1lbmRvYmoN NSAwIG9iajw8L1N0ZW1WIDc4Ljg3OC9Gb250TmFtZS9LTkFQUEMrQ2FsaWJyaS1JdGFsaWMv Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRGaWxlMiA0IDAgUi9Gb250V2VpZ2h0IDQwMC9GbGFn cyA2OC9EZXNjZW50IC0yNTAvRm9udEJCb3hbLTcyNSAtMjc2IDEyNjAgMTAxNF0vQXNjZW50 IDc1MC9Gb250RmFtaWx5KENhbGlicmkpL0NhcEhlaWdodCA2MjUvWEhlaWdodCA0NjgvVHlw ZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAtMTU+Pg1lbmRvYmoNNiAwIG9iajw8L1N1 YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNjcmlwdG9yIDUgMCBSL0Jhc2VGb250L0tOQVBQ QytDYWxpYnJpLUl0YWxpYy9XWzNbMjI2XV0vQ0lEU3lzdGVtSW5mbzw8L1N1cHBsZW1lbnQg MC9PcmRlcmluZyhJZGVudGl0eSkvUmVnaXN0cnkoQWRvYmUpPj4vRFcgMTAwMC9UeXBlL0Zv bnQ+Pg1lbmRvYmoNNyAwIG9iajw8L0xlbmd0aCAyMTcvRmlsdGVyL0ZsYXRlRGVjb2RlPj5z dHJlYW0NCkiJVFC7bsMwDNz1FRxbdJDiFshiGCjSxUMfqJ3sikQ7AmpKoOXBf19JcBJkIAke ebgj5aH9aMlFkD/sTYcRBkeWcfYLG4Qzjo5gV4F1Jm5dyWbSAWQid+sccWpp8FDXQv6m4Rx5 hae+37+oZ5DfbJEdjQl5q46nhHRLCH84IUVQ0DRgcRDy8KnDl54QZCHewX4NCFXpd5u2tzgH bZA1jQi1Uuq1uRYk+zi/ss6DuWgW9+131Yi0veGZl2+6+TALc7JYDi9GsgVHePtN8CGr5RD/ AgwA3ftqewoNCmVuZHN0cmVhbQ1lbmRvYmoNOCAwIG9iajw8L0xlbmd0aCAyMTA4Ny9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSA1NDY5Nj4+c3RyZWFtDQpIidSWeThUbR/H79kso7En y9DYiiydGcTYylpkX9IblTG2sc3EZIlHZh7rU2iR0IKRkLWU6XkQ0kKW5EHFI0qLNgqJEu8Z 1ft6/3iu/nrfrve+r3Pd1+/7Ped3ftd9zu9zDkAAAIRBAkABb0tXm62mS3zDsPIGALlUR9eN pPlxbjEAeCaseVNDKQz83rUaAHRFA4C8So1kEv6I774N+30AYCT9GQGhha/MKwBQHAdAUCIg JMb/NelMPQAxqQBI2QX6UXyfpi0OAtDPgPNtCoQFXJnMDAAbFuBYJTCUGU0UeSQCgAYBABOf EDqVgjAcqgMgE85vci6UEs2QeYxiwdc7wecTwiihflVKLaEA9MAxBjDoEcwlOBscQzyfEe7H 2Nu6NApAYCIAYkhYQyxP3grkIuBVEiwPuWCILRfAJ7gheVvyRxyCH1nAltsJS25IBIIoBAny YTSEUUhZDIAofFgNPgQawdZHItAFrpAzpLlCwXMUEvDAeHk6Ah8QAeggBPgBJnyY8iakuCIZ WnI4DVszJ/l7sr5MX1rIE0+Un731eAFbagPERotDbOSnAhQSgUSKgBZwyNg4Veye6Sz1zcgW CPevShFouCYGUQNS50O5o4UklCzojJhwWkAgk6BGVScQyWR9gj2NGk6PoPszCRb0cIY2UQHC fz159X869HAKk0YPIypCa3k+SkL6374Lnc4kmO1nBtLDacwYSGENjqwPEYkQpA/BY9caHAki knSI38KfUBEbobRyWxAYgGIjRACsY5FsBAKUIRtbGM+Nphzk1PJPRu+BXnHK0lX3zi2esCvi Lp7hEEzjnDmnOJnepOB75r4xExWR7W6DU69PJ+Mz8xP9a28GH/BRHpA3fiSCODaefaNJyz8v L3Bdbo+hZtOqKzvXtVi/wJoaZGuWqZFL39j8aj6WKFKfF+JOqWDHFXprRdm9zL3sa5TnhCcK qEjml704qiH93CSHKum9E+OXL6/vkvKxZDILeUvuzyZ3q9q0hCbDN25ZDlVfSg6EMh2qpTuz BdUUgccRb5p+/XZxfuMdS56fz/ljBc73snZ4TNYZ7ZFiRaEHZ69VJZxYrOk6OFAiG+5lfKfh nUCRElTLl9ReS4iSSBpBouAXv4hVCrGKIRYH3k15BJqVB7FOJoh69jAmaeFnlZ3jJS/ZZyx1 FIb/758f+wfvOIr3DE+MCzWnT5+U1nt7FaHyIEps2sublH9WqMMUczQ1s93wueLUO4/jmlcK trb5TC7c7zQy2lW2yY22qBK6ub3zwiNM3DAx3SRflBFUvyjuKE1rXuixGBPbRXB85RNbfUGm TUNfVeuaX6H4b6oi1KKPbvh5xfaB1dMuFWEWJP4v7DVzzwJCcM6zje9dbje+uAEtEIiCqfIn 1GXt++WRxe8TRlGXPWcuDrd5TPjZ3HZxq7uMUhNfOjLwTiAz/urJm+X6mk8PPC2NGossAD1B m1t6N/02aiZeqhckFzSk97gPj35aaoVu26VjEGaPx/lwsZzDf/a7bbbuwrufZwyJG6Yc359f 0lsAU8EbYqPsvlIBq10u9pfTkteZjubvTJH/WTCA+96ABA+YACQYBkQSHOp9h0HMMkHhJHwS SHdXogQkxgsEJLAelIhAWlgAE76NKCTME/kl+F38fEPpYb7fC8P+XWHKkOLXwmRX+r5+BFda QBicleBkYfZDKnBjfhnYXWtFLtWtIA7Oq+rZRDV/Xnv2ttW+yXvW432HW4PtXHxmcpGt9g9s QjaqmPo1dStzhbZxD+4ftmq8kCnsdFNVY6rgBU557T0zlU8+uXdlrIqP267N7ardqNRqqxVH f7hawegwWZQ83Kg+42+khSAtLa7fdv5KCCLl9Oc/LlEPsue9CliJSRk1U1eziu4anHdKWrM+ xWEYmgUmM7fmTVjXkt+GkEu0dWcva1djf/E5Gu1/OicCl1w9dWOa8LujeDq1Q/MhyUpmot42 28jJVbrb3znmQmVK2w7TfLZTahjmol5LrEqji79JrkOnRrxOWOJWvntne2yTkWHJ4Fxzyojr Nyp8glgfIQkeFFTRqyAsnwD8QcNg+FGo/w9UiPBqlEAgltAYCAUvkDxPEEZLoSU75bsjAcOz +v3gDYc8Z0vtIkvqO0iIZ4ug0XAbJa9onWXGxJZXxduum+pucGBydq5nbthfm/yl3C4rGti/ vPNa+i/aTWFO3DTS4tadlM45187r+Y076O+olmWWYCK7La8ff1UoXwaXdX9QoVL9l8m35yMq Mh+RM0xyghoMQntTq5W/jLwcoAkeTW1cfAzqdac/xs2LimtjXqtnHzcPVtvHNcgc5ce17w7s akwwC/YvrefWZ+jemUKJxh340DtqPhK7+PhxxeLsSD+uljFwbMyxzoATp9VnMqQr5KOPzGcF KafNelEza3bVk+97H3ZPlNX5YJRTwF7F2XuoVpNbWNxRPkioa4JkkgiSuA0NLjNmo3ugsWNq tJQWxpPpkvLuBPPwSGGYMUEwY1y+MYYiEm2//IeEWtlHGJgzP7GrvwNHB4Jg4ujAwIHIEIkX 6vBCiPlfKe2bj/ob/4es4Qxh0+9eb7E51XXBULdS+R/BQyHXFJW4WW2vqppu9a+7ThI71DC4 W/Pzph0KqzWqMnHDkkVhanYHpTabVaRvuWidinvIyqo8ydfjYRnp9er9gvCTg8winQ7ms8kx SmE8imu11G8q3l9zZw+uJ3aKK4Fb8A5SS9p/mFvZkDS+5vKRax+k6nx2vxUbMZxQ9DxUnRDR ajV2Ii3K+9SLyqgW/XQdyY0SQz7tVbJljjkBlX0EMrRvND3A+skt/AzOiWm2cRyjEqQYbFNz 7MYl8m3z4lAvadvyzPsZv5pGY7c+OHcpUbn1yVSs/0VbZuM6s+2nKZLeDlAbe7pHiBE34W4f 1SvgHsn6xpo5iPVhee/lRXgdCzchX/OKhp1W3JIR5zzntj3n2T+pL/NwKNc3jr8zxjK2LCNr dpqs70zDGGONkZClmaSiMAajmGmMNQwzKClKDuXYK9pEtkQOOp2olFSSiiz1S9bQYqmc0WlR Odf547d0/f54r+u9n+V+nve97+dzP1/pzgAOhldPc3BpNC1wYoUaTAZcHrv0MbdeGKAEMwXx IC4fm2+QuNqfyaQb6+uTGTv1Aj/HUI9MC9Sn76AutOrTGTSfEDIzWN+KyE00PW4TaPt5Se49 xAQ0Bo0+2yA0UeeTw7CwsKUcUhiLPDG/O0AfaWOxiUb0y1XmYCCi/5K2NykZfhDHGhOJYIY5 Za6VmQKkqDGPvA8WvvcryH6KXDW7sfPoB+eGbfCKi0Wj7KkjirTNs68n+oTvJguYLZdWbm+s IqwV0PTcBLdPfynQWrs+6GW/rQTSIFmF8WR7dSlVQj197AUG/igmiJYmuOG6lsO602idxMGC Vg/NS5dMereWc4RqDRSc4glr5+vSCzbzn8roDq/fxDpR7Ng6WZKdZdl/w13d7DELs9bxTVvL 7pzh6mvZZASxtCRrvLOhLb/gzC/XI7X36DQ2d73byfOwwahkot1dVnpZ49vrsUViAnLdB9We lxU4mA2ViWuGizbpXDy+oznVhEubHC5tEj7TZl3U6Efa8P482pCogZRgplcgfTFtDEEcyhBE GRigP15vUB9NNLhggnFF/5W9rQQ1/iqUikFWVLo/haFsTSQoE4iOxijQ2kjXwAiD1bVaY2P0 eSCPpOLffASRwgilkin/CKihWl5yS1fEuXhrsxMVV0YdctWf4EIV4ffRdm7hd7S7TvAfHH9u OlevGXVs7ll0DLqtyzQZh52cfoDHLL+Xxp7DjPgnMORSe2scemsSplYLQpsKQ4MNHDwmLvTZ Ra+oSQ9/NK+YILXGZtct1spNEu0cJ3zbbM+b5FFzYKCjx2tG+oD98TiT11SLob6kBn6nWubu F8LP1g6d2TnR4RcnML38erRkXXA/3GHWe240H5dl/GFYvMVL0dvtgSCJ04G3t+/fWK/vKZeS xmv10GOYLaiWCc/nRVGSDzsqWqoUph18T7Am0AzOE7Al1FOUGYzVeenLeFyf2P5JuT0DJGcl fA6qZDGgvgIphvFSz9x1Va/GW/8ayDv7vpi2AbNv2EMbdDTPvIg5Y5+Yeil76Cze0urq7X+L PcxgOtnrP8Kez56YSxFU4AcKLwEoaiQbLry8vafNJkmvoR0TGcdaibTUmrqrkiaaWbKduG3V zGgTye5k9FvJ20KImfWTiVJA0ABnBZJQrINDd9OysFvG1DakkngOmBdn+xi9MWxBWFUbmx25 JvL7rjjklG8xqt/dI3Vmw4Y+9+HDB3OocIek9vZQB4xIQF+UdbH2Vg6JRVCX1biyz+YPjQHZ WOoqxBvpqy9VdeJstmm/mim6GmamRpsp8klIKfQWOaWrePLZQTPWfFnKu8yRifew0pvrbm1h np2dklSSx906Vnn/0qvKsZaSSVfFOZOJlvta1pcass2jfWVuliuTBa9bmFLQslHlNaZNmraO qrJHg/aDTROHvgWUWIDQUadGQOOM+COCklukX+H3mPo54usTnUAMBrtAJxzX/Ani6wdw/hNv HmOD5kpb1tjtkmm5ZWtGbJw9g6jVQddJOG1o4Yyare5ah0pDVh/y6VVyjq+9bN/O4p0eD/kt uflkxzkq3Td8pe9g9YXxhIs3x06/lzgutFl1lX6bRZcrTD60KtAn0I70qHuipyGP0xz7hOUA xaa/bswVcFX0X3uzqzHUXT+6WgNW6bo1QIE8HxtlMtYB01iPC2Pye1x2f5CI1Qm5JjqkiINH hX7I2RkU2TtilpqZu0t0u5aTjLcnOvcOx1Fb1d2fkNyjHy/mXD5TJXdg55jGr5LTN8Q6E0Rf sUODDa/+ElnY6sk3wluWuPrCdPrWeMt4t4T0oDIlHdtWWrZVb8AgSzNlx1+8YUOQ3D+ivvQJ /b+QX2J8cO6GYRA2VgqyoKmARfRcEo6yXyYgoDBhRUGACIQA3oAVYPmtNPtB1y0BqPT14qjL Uc514ikFXvwQ0f10woHxYFK9OZxXd77GhZigMIo7dOGYq1DP/mq8fPvc2eJrF867qMjTBKgx O3gKVW1Gd1YGRqnW2NyNnzqw7Df+fYZNwzEv6B6EvLQ7rbe6Uxr7GrRuRo1cO4fu2HPxBvmK YbuMSkNoDz6rQj44V2Xvg8pKCdL+V9mXKXZZSM1sz33L8M2SlHDburYSjrFTmbdbD/jiBW7F QNLkQ1zcjKTKfp9YMh8sYzILaqW/22Zv7Ty0izJj1/OQh3m4gjdIuDXnMdIrynZCOltcxQiq sOcs3x8Z6JpnFleJpvWnknoGfbEHXqlmZLeWhZFcjO8zrMvV3qDYsFIupM5AIRAwbs9PVGXf aEU4H6+2KA9UjhfIj3sIIr7EGwlB8fNwI8cdtJAFn4IJ50EJ8wl+GgKFwLi7+WoJoUTBxb1S oNrXiTAUN8f6S5NCip7gDhelNp7cMh4gPrVv3QrQZ9EUYZQrSMrXikUC6wEqQAYYAA0I5j6+ ABNQBkhABEDnWn7cdi/umz8QUaAZq/635ZUZQaf5Mbzo/hHK3+ENxoYAHLxLwg2d+rym5OH8 NYUOj7VHOlWrYzEuDWfdqorSS4wIeQ6RCr3PT/vMYqW8fD/sSPV3PunIOC+SPhjyOnVd7qvn pW4eT++IVSF0y83vDc4Ch4ZDey0C8ZsrKW4bk7JwAohEHdtrbMO5/jpEYyALImSpWT7jbHHc BO8iH56/Pdp9jBBx+vZL8RhRz9Ff99jGJ+o48m294mw4vOntSRvlisnKEBb/M6TFtG5Q4u8W RadcY+M8HuYdhyAnZO/dzdiUWxHqCfa5stzk91oDtyt01asYxOMK8VEzgVpPeXjE9h1RLeqW bG64fsQxuTMDMSE++l7EiSxao/X4zgCCJ284jDRSXMCGKoFsqPzXGPGh2FBhbpPA/zxFv69I 3wgM/k8pmu8ByizORKEvBj+Eu+aXHl7UMm6pNUKBaG6hReMw3Nr6fSKmTP3JerVHR1Fe8Tuz u9nNbkIWRMxhPTLLxy7EzaOHlxQjLNlHEiKQFzATQXezWUiw9OAhPBVJQQhMoFpTKVDLU0FR 67dQysaiPIqlIhSkVj0WLCpFWoEeAXsOnDbb+30zu9nNwZ7+0c18M/f+7uO737137ma7Jjx/ 78w/Lv/m/IlLJZsvjXK9eKPXzGItcmZOS17z2cvHh8rz6/86PDjl/LsbutzDhm9acWZ/6zut U6YVfrLz0gO3v7zV/vWjCw6f/VOka0754Akn171kvrljfV35kUX3bhgyt1hw9jlx5dPHy6fe +scLn352bNmY6/Fam/X6cPPw5TeGRkIrF5//160NBzwfThCXFhTsPzlo4T1D1m4c2PHqmoYL u4o/9HqD3UPP2KfbV+3cm926tnbd6C/u+1y8cfl0i3fAqcHT6J78Pb/PG/j3WU/kr/Z3HPti 1IHZxvsnTN9Svu2V+hVZW89tfO/lJxddiTq7Jx65ec9DI9+YXHpwX/yiUvvP6P13K+D/6jVS vWAgUfbnlF673Hrry11li1ftKPz63MFa9eJHNBcHhNEjPAcmsJg2mUYACPdpT8MZWC2CBcQ8 kyiKRqto/BzEhBdeT2DFslnZJtVJEggA3Yks6AbhmHmL6EZgK586b5v64kNi08W8BXU6If1T DXPwpW/Dv9WwHjrhEPwZv3NWIrUJtsEueBUofrG9Bx/D//HTvcQ0F3IMByAL7gJI3E5c7d6F K27qk4Z0IneXUepBEvbEtV7Yte7OhL07ntUPrNw2VzyL6A3h34nb4njGJ0YzXmxHOo9bfGPe 0v1m9+6McCbCwzjupsI0mA4KTIHJuKqhBsfiTHgMh18EmiCKY3E2DsEWzNfj8AOYCz/ENQsH 5Dx4AkfkfByaC2Ah0q06ovGLcYwuhWX680l4CukleF/KqadhOWb+R6nnitSzB1kJq3A9g/fV 0A5rYC0+2T0Ty+RU6IB1WM8fw7Mp+tk7oox+Dl7A9RN4Hqv+U6Q3Yu03w8/hRY52wgb4Gee2 wg6Ub8jQZbIe/V/AFtTaBttRcyd2z+5eukxzKxyEt7GnfgfvYLcdQuoodCF9FP4CF+AifAWX 4W+CRxgtlMN1uAmnMfuzMOss5/P4vQXvs1MZX4S5TWb2acxYZh4W6jItnyt4npKyRajZjtVY kWaj8jolfTHtpK/0fLEzsRP1YNoJO1NIz7kzrTS99JxlZnAzRzKlvTObTm//TslOeBnXS3hn dejNJalX8A1naw+8Bq8jpd17+CT1BvwS3sRZEIN9sB9+DQcgnuJ/hVyPfC9Hkjp3xt+C3/Au OASHef1/C8c4dgipLl16SJe8xemjcByn0PtwEk7Bu9g7x/l6H/6A/fEBnMWpdQ4+0zvoI95B RPDAGfjA6IZPTH0Ek+EwHBUnw2LkPxY3YSXAdBH6eIOPPTpzxiMNijy1vq62pnrK5EkPV02s rCgPBvy+sgne8eMeKn1w7PfHPDB6VElxUeEwt2sIGTwov39fe16uzZptwa9L/r99YYAEQxJ1 h6jRTSoqihhPwgiE04AQlRAKZupQKcTVpExNL2rO6qXp1TS9KU3BLpVCaVGhFCASPeUnUlxo qJGRXu8nikSvcnoSp41uzuQi43SihRTIb/ZLVAhJARpc2KwGQn70F7NZfcQXtRYVQsxqQ9KG FB1G5sWEYeMETojDAmNj+HWUy7alBlcg3ESra+SA3+F0KhwDH/dFs3zUzH1JLSxm6JBihYfV dXE7NIY8OU2kKTxDpoYwGqmGgKq2074eWkD8tGDpxXw8cpQWEn+Aegg6q6pNbSBQk8tOJPVb wODJ1SuZSFhHslz2b4GR7IipNKE8SQPGhhHi+ZxOFktH3AuNyNC2GlnjJWh07AVviUehYohJ Dicld09lkrakJGUeIk5WqkBIvxY259O2RqmoELPPLxdeKJeowR1qjDSzZziqEr9fy1u9TL1+ JLxh/ayB2PdKUD8cwkO0sDTUyLSEzKP9SZmmgIDEatBSJ3MT3Yz291EIRXQrWhLws7ikgBry awEyX6RG7oIRiQuxkZJj3wgYCQqLgw7wYVHcAVVumkUHhRxN2J+zJNnhpF4F06cQOaqwKhE7 LbiA2zn5jtwKz9ZLO6nMTm52WSRZdBgUVi0EpCDeSFkpCuxYLs6yipaVSrLggKQa7qJrMCrD DzIGl6+CiQzM1FfhcCpO7fNfQnLoMZlc1JLmy45AKiZtn+8MTdNmARVIgag/LcAMpyY9QN3b neMUWS70jdHCwspZkRQZXPjmIiaiGw6xKuZLFKolmUSJQrCHvNUyOxvLNa9vVR2pqmmQebX1 LqnP4DT5GI2j4ERxkhF92INBjyNZVs6Xcz7FVvQSVybFkmohVXUqc050hyDhG4SHznJXhjvG 9BuJr2YQpxsJholkl4JqOJ5oa1RjXq86LxBqHst8kMomldTJpQ4ea628zLGUbdUPqoSq+rKi Qpw9ZTEirKmJeYU1dQ1ylx3/uV1TL+8VBdEXKlNiQ1Amd0kAXo6KDGUgYyTGME+1yFi4vqPL C9DGpUYOcD4SF4BjliQmQCQuapg9iYmIGTXMyzH2wSLlN2OKcdwGpCZWnqeUZjWksJcLBmAp 8RKoQMYBFcm4mCBm5VAriZZRGylj+HiGj9fwLIabsTGEAQImh80kNURwTmFDyeAQtFY0MJdS PJGol52nHFcVJ7baDFwNMs324Ow3uSaiXjlbIYTLaVskzOKAqTKzNbsqIwq2bdIhqlTSbPSQ rXtAjSC3Ye2IRhGsDRaQ27chQ9sUqnjYpnKLwtvZTqGCjMWyaz5NbrZRiaL2I8P5u4mvgtXV zh7ZGBvUyRriQBY3U7QkmXMw8ghBUSQkYbaNEKnDVtdmqdWhIVEciUZ3lC+rQxcCO5bBZcu1 0uxidIgXo23F7JU0ucyKogXPuXZdAfe2UxtG5E5LpW6A2UFRJYsFr3YMlakeYW5q4lBLFuNk YUFzT2YU01xXZRiHv2ZvQ4SMSRpb2Iyw6T6OaaiZnTwH825w1ccTu8kSZ9qnqJCwLwfWmODo wsYGRe0N0Ec8RYWW3mguh1XVkntnAy1fltzUE0FgvyS135HWbbdH3rZZ+1tA2Jz+gymv0tin hxNOAxi3J078ryvLkWhly9gA9cZimH+H1Wq8AjJfCRjPluEyyLhG6E8frgdx/Yfxco+u6crj +Pfsvc8JBvVI1TsdVNSjVNtUSyRqkSZyNUnjNZ3GoyNExSQeCV0oEoax0q56jLZZmQTDUI+h U5QGw7CWDFrtLLQ1bapFUe+RxiOy57vPOYnMZa3647N+e//uPnvve/fv7u/3JJOAn/PYgCS7 LiYEoyqQZLCjMVkoJAmlH2Nswvgc6UIGkniSzXwLxgK1iOPy9MdklerA54l8lWsYRvkxA21V CoY6xzl3h/vAtexemPiL9EV7g3MZE1UbrtUGiXYC20PZ9uhlovwzlIf+mdGq7p/BStLEj0vs Nlj8oKg/Yk9IGE4Eo8L155xrN+npxwAZK3frs//Hdb3tAdlq/1YvNCiFWLkOafdDjUa8SzYi DXIW152FLn58lISRzqQ9ifbzAZmAGDUHr99DFvOGAgyzLiDGuqD7MrZkfJGEk0EkiWQy35Ax T7VAjOitN5FZsgQxBvEdAi5n/HgFj8mjCDgO+qtp9yGVa76HEb/IDsQaOM8ouZdr7UU/tQIj 5I9se/RzYxSEh75CLlX3h2GWHKZvMk4mb6q5mBHEpPvkXORFLHVaY3Uw8pD+Ws7EPNLQj3VI U5mmr9ZEtUJiEM/fJ+fi1EZXA9uRMhnxPr1JVFU/pD/inUOIt696uM9mkLHkaSTIL3jOD4DI 1JFOro6stUtHqnU6zMlheyfbvYJ4KQg/72QFsSAIP189PpvU5hp9a8ydc3cudcrDrqMjQ8LY boUXgpH79M5gmI9y6YiAdQxR1jFtuEESSAsygSSSFDLfjOGbbhTrt711XvesQq7k7+wR5c2D LqKlO98W6zb6iDuIcpL9te7SyY15+pobW2BgEN3uyfXi+RInl+1W+oYHEsUuRHno80TLVqjt oa+Rq1V9e5WH6qE7WVd1c7ERmWIf2YiRohgd1RlkqikPht0YmSEDkOl89WBwnxkkwY8Gc06v k1SSViOfId/BdPtjvB2MzNZH5BI8TCw/GkLl47B94MaJyJQjMVtOxW/El/hAHEWh6IPVbns5 1lh7dBnbfxVfo9AahRVWuj4nlqHISkGRikeROEGOcexxZJEPrCvsd0OO9QM+4Wd7xFz8U17G p2I6UsQ8vC16YIZIBsQUssSo9p1aQMVZMfjenLvH4cTNVRSSMUG5ApJmafbpC+QKssbNjyYj ZDvOV8ZcfzLGzReRmTKc/VgyrnqOGbIu+w+Rhm5uPVkr3uHz75IiN3eOfC/oMcResoVj95CT 9Byu+6hIIk9aJfQhx8inHvwuAYOYos3zpeJNfYvxglWufxRPVvuVZcaDyJepr7nUMddDVO43 mub5hcqt9AsTPb9QucN4BNcHLNWHqvSevzE8DdeO+wy1W67T130d3inPVC5kTHZCuSb11AF2 U9fr2gmVZb4mTjNaKG4bjdGfeVpW+bl7t7q6VVmiNmOEp1uVO6lNya4endTbq3RH/gG/8rRE 91RT2Tca8oq+4epCDnJkTuVKxgY2fylzr9tDkc85G6nNOpkakOjyHOv8eV3Oup6qunHcKnQ1 iAN4mvdulMtURKs+GC+6Y7Torr8hb4julZfNnSI/4l01kGsuo6YI+jSJp6rvhPGwVSP9bz47 gOefIJvxdxqEKT5ppLbdk/d9BOL4vbPstfxvLcJgg1jgnmUded096whh45qwrWeJI9rpzazB /ZbWF93zDGCYe54ZPANDFs8oXKfV8I7JzljePf+CpO9JqsL3gwON16v2Wz/ojc4tctzzjSHy ro9TN71zNl61ynupHtRwwzbstZd4Z223pL8tIxOxy7mG5JDWbP+E5U5T+tpoMgqt1UhkhNTm XJn6Nn1ukbqG5fSMcGvjEvXP+KRQnqchnPUwS2fX8EOd7an6J8b6agE/8/E9ziDjX+QB1gNR 3fVat16yfE+ST8a5XiPG9V1VPqKAXo//TNWVHrKOVy/qLcSpNJ7NLbzvtEWc04/94XjDzuHe zpJT9GFXMMrpyrl4J/Cz2eo1zOF5wLG4bneuaXS8Lz8ztXWUc8XSwxHee0aDEtUz7r37Qk0N d+J0GX229O9co5Ev+RqY4WraVuoZUQ/rYq5TbKfBUc9Sxzr4WhVGOro6lmp0yPUY1Bijc04E vZJ7N1N7vmC9reSavLtVjH+//wMjzRhnJN9F4jDETsZo+QlS5ULqVB69+T7W/EF9Wg1AwGiz CscYOYHfzYe1usog8nkf51P/8pEut+AWaUOi5Lf4XoxAPhksf4dvqAXdWMdLTU2LdkhnncfZ cxHL+r5A3iSaLOIZnSNzSAVZap6h93tXbMV0Mo38iSxWzegDm/G9pxneI/Nlc50pSvX78m84 KyusWrIxDolS7BWT8CJJlRXUpAo0D+mNVWRHVZQVOoX5U9zPGrJdpGOKSNcnxGR0EpP1fpGL VJGrT4loTBDR1PY45uPYT8d8jrvEcb057kuOm8Zx5ZzrZ/IfMpr0U5uwW0WiiO3ZZLG1D+Xy GZTb1CSb2hRSTqgbIb3cGOpsQImB758X7b/gmL0eC/l9wX1eVn/HAOY7c54mjGG8s0LZPsjP ys37Ktup/C16sB0n/4t2shAt5S562kJ+90LWdV2Mr9WF9wZ/B+c71mxDrdUSvCIOIkXyvUBe 0N+qQbyjj+uvVARmyg/5P4hgfUXwfqvPu7E+hpNHVX19nRwmF9kfR7LJE+zf5H9guMjDMDmb dTQJjeR63h9jWYfb8Kp7N5r6KEYH7qcfGUQakBYk1I8JJJe0JW24v3HcX563P9SjPj0kj6OW v79p/v6e4vqBu/vjO2t9NCWt/P2t9vaHx+Wvsd26wdrYhFyxAbPpJXLEasxlrRygLu8UJ+lT Ssl57GfcL47gI6sYn5Hf81mLz4aKTfqQ2KBLxAl9UKzWhzmuAZ+1xUlqbyk5j3rM1RNHdAWf e8Qq1ttEAd+7ytBNJOkzIpbaEsea6a9LRSIUvUtdMUSfFgHWUwFrpAwfiiSMFbH8LePon/rT GyZiHse9JYZgjAggQ2yuPC0b60p7OEkjj/jxCX3HfpmUIMVlDAL2NrKCHMZr9gzq0P9IL/fo KqorDu+ZM3duAgERaCzBkAKuEBRRERAw4SWvAELAFBLBUhBQQG2jBRVbtCouTRWXirTGsqil AvVVWLVIeYSHLloJRVoBC9RKK08hoCI1VnJPvz0z9+Y2aktX//jWmTtz5zz2ObP37/dzuNju Qs9Nzhglk2M/lBvjf2DPzgZMgiuhEIphOAyF8dABTBqjYsekixeTYf7b8jB7X+LW2gruj1O9 oTpAa6Y/TZ7zSu1GL1tu4ZurgkXwZkBz+VW8udMn2TYZRQ7uJUvwlgVOJVpnHzl1+v+LMzrS Q+dMVFOVb5ij9iwcg49DpJCa+jXIS9bML+XBr6CDPBWwVRZ/GdTbjZCnbYO/tOvgSVgD70T3 jkNtxHG9l1ZfLjd/svthBeyFGr1PfcmHjAZPgxZsa1+L2g+Cew98geKgTfqDdSnKo3aItlG9 2a+tN92+Qex7RRrw3AlrP9gPYQ28BNWwnvvnU/szoVWoBwMGQU8ohrD27/8K5ssPlFgzeagR N2lr5inUS9pzOnebqSt/ld5uhbSHmepn6ac04n7vIeYWcgt7eQ8erxM17Sr1sV6hLUriz2kA b5kH7RV/TgP4jevcI7IWHV1jRlCnVgSsMYNkt5kgW5xl8rpTI33cA3ijCfJ771ZZb2bLOqjB Z22O2k3U4zvIIWvRWxtNRznlDZZDbj16t1r24UEeRov+Q/Gmu3dFNFPMZqcFdDVZTkcYAS5c rF4DChzrNIUrIR8GiXz+ieK+IDkRP4FteJcL0u6F3IsXvFfam4sSR90n8AXTnQHuC/YXsNR0 TuyGwyYr8Y7Jsu+bKtpOiePUvG/DAFOF/q1SPWIN856bnD+8FXGJwrjn09+r5OlLaJ93X3Ba KabKGQnzRBI/jbg6oo/C/B6FasYaxp7XcF3M/zMg31SdPWSq6psxh38yh0s8NJrnyKc6G/ru D7czbp2zw8nCBx4gXhm8PwgeVsxHcl/0vEnk6wq4X2JWyUVhvBw/PtGujk+Ud+MTnY60a+EN 7j3n75S3/Z1OjN+r4H3o77wn1fAX54jshtNSJ1vhoBuXvfCpm8keZzLeYtkOH3BvJ5zkXg0c M5myHT5wJkkNHHPG0s9YOe28Lu9BvbNRnoSV6PS/mU5OJu0fAYdo25sNTjcvh3ObQz3Oth+T 68/jukUI+iRHWhOf08SnBe3ntF93JtnlrPko62+lsfC2UjfU46h36GoT6j/wDP3wc+PwI63J uwXedvLaNrnGvGyLYlnov0qZ45ZQDwcxboGU+C/KolgBz8i/6PU70Pbj8Duj8DEXqG/Fb4xT P0Ntmqo5OMi1G+1R+oxBMdoiP2O1lGXkSJl/oZTFhkpZ/Df4o5Z4GOoCPqpPkNuTOTyNZO3w 29rv6dyC+RU0+CodI9m3PosXkMN3SZNYQdh3et1hnEPq21KeLPJtybG0L/VtsZb0gd5hDYeS 7zeuQ6yxB8/uIqbjzQ14hMN2LDl6r3e9/Zy+unhP2+3UtW7qD5mXjlXAO12DOeE3Q6g9XfEK J9ibAPJ72G5oqJX2Rrg0uH6Zuen6z4b+MsQ+BrtcL5Gta9PYhNglzKsM+psb7HVQrL40icYn xJ6Bk43XF3jVDpGvDRnjldllgXdtDHsfQgwO2x6xDvY4/BoOpvaxkppWKZvjebJfUa+rpM5K yGDm289ssV28K+VGxuwba83Yk6jBf6eWzpFsYhBH72r9LgroLkXq0YLafTn5vIKc3xFdfZn9 zCxFUwxAm79qV/O/ft5J/R9+IldyqRsVCnmh1HTmnK6QJmYycb9Z/PhUxtuE34sHPnAMtWV8 UMNz5ZZUvY6g/vdI6gk/Uy6LPOdAxm6T1ANmvd2k3lP7jZ73S76T1BaMsVZ9avIdakc/JTUO fdBe7S0LzubFOufk+w26IxpvobRyJ/Fd/lKK3EfkQn86c9M1ldrZrL17sN6F8iz6ZY3OS9G+ 3GprzWppam6XrfiCLNfaj53T/O4sTb0fS6X6UuK3KRX7XDs1FftQO90etRUNmskyR9tcr3Vv tK6nxSCC7yjXftfZU18fwhlYKn1D7BRicwYWO3sSI+Byv5S9iUjrYwZMaRwL7tUpYTypidX2 E7c6cYI4ZDaG81AanovEAdijcwLt++7UPjxh3zFPyPfR+Y8r5k67M0B1Wmc0rca2c+IM78x0 X7HLgv+odtNz9JHN4TwW8uxnPMv3hnF298Eg3tnCWkvFcU+iidtw7q8mrteiVzmzfPvF5kVp zrcyw7uTuL/C/TrpjXZr502TS02lDDAltpt3v8wytTKWvD0LPeeaN2WI/y302d22UDVcbB16 rQnvHsF79JN2ZoKtM1Noy6kTq8jr6DizHL02A702S3zzlPSB7PifZWTGfHLg9YHfKfOXy5D4 zXxXaEvnhA31YaQD00nqz9hE+yOdWzC/N6V7UmeaWbY2voO+v0nO45l/DVrzNsn27pYhjbUr 4+xlTUNT7+oaIDUW8yU/DPUWyTCzAU/6DGuI3k/TteG786QFz8qpXevRdj1NuZ3G/pd4nq2n r3am1u5GG09w+9qV1Dod6yLe6WSW4EnP2jq+ibgplDjfxK1ov2d1HGpgcYidzF7NYF9GhpDT w3ZHmg4fZu5L1HM93JQwZ42Nzj2FnQ/3OCcSrq6ZmEXYm5jvte4BuxfawgW+zx5HaNxC7HJY +IV1b6GPLWHcIq4wR+xczoL7BTgTIVZMeeK0N98uhimwIBXzWmkDT/vtZJlittt9AfOiMxSS w1oepS8J/jNPbtZ4sY5s90DimWg+V+i6gzXqvulZLyHvvEYsiho0/X8iXe9/Fd5sqfhv+HvP gQelfUY1eexFfMQDXG8IvEXSY6S8hjc6ojCFPsvDe5wTqf/fCZmSl3FNwz28Y6ov76DkxZqE UFvz0sb7t3H/1zmY3WiTMLf3B81Pvnk2yvfdqScr0Y1a/85KD/O8XEYuMehM4+XLqKimBLXQ K5fRZrHcZXbKzCiPBjmbnF6nuN1kmuZ894gFyee6C/5O8/vsCM3BsaDmjOQ6T0bFboDR0FOG k9P3pfEpub6Lu4D+Fsh3yNUF5iXmmWvfZU5XhUhPt9L2Idc3heH0fZzzN9ArlnvJ74dia2yt WWgPmTFyR1BnhfxM/YXPVOPBWshhvVmBFtxNH22p/azTu4pxK8knS9EzbWRwUKMXcuZ5xx9P Hd4hY+JdiV8t2uMtqYjNhU+s5vTbvBnUvVN8A6fIgbkySTF77G9j59lHAm3RUjoE9ba7DGCs 3nynAzXmxPCw28muZK1F7ofSOjaDXNhL+gZagD1DB4z1Vsh16L1mnN0eaJwWPCsPnq9gzG3U gW0ygf6mer1lLvnKjf1OLkUz7OL+435zecyMtqfMv2gvG+gerzuOf5977/M8NGlOG3FmHHUY kcSKovEyb/USUqNJGiGEBvPSeVmSUqaGMpqMqmVqwrwkREgFSa3WykrMDHXQklGmx1RSVq3N +TNTy933PklUIsJO+Z/zOb9773Of3//33Jff/d42HIdIrotj1OzFXA+MTYXxffqw22Cxqs98 eg0v8t4Rz3n8gGySA/C+2OSRxnOuWA7HXmsj/mR9hC7MAUViOA6oySiU07CL7CYfiQJkiVN8 dgp7xBCOdRB2q74oEVuwlJwwVvrwjijB78kG8Qe8SzLFdGwki9mWaY3BT8VvkaXi2HYGa0Qp tolBmE270yuX4DXrc8Z4CXv5fAH77RELcEA8jwiun7kiAoViPs/usdglXkK4NUb/w7quL7F/ APs14jr7hH0eFyXUA2PhUm+lOi9wba9lnlxLLXVCO04moNIh1JqyX8nGZTeEr+yGnE+dcVQL aoWn5T69QioU0B534pHMebwp2umbXI9LOSauh1nzvbiGnub9qz/n+wq6W2X6mPML7oMIbx85 jOWqnEkN4687Gm0ii6hHunLdzuI6K6zYq0aLeXtUn2C5raex4vVJ0V7PVjOpa9rzTCnBexyj DR4F2G7G0iqi9irC9zgXOWasrHSMt3JRyPHN9MolaG9RS1qv8c7YHFu4P9eRPaJU/4fjvInf l2XGW4ZjhWiLKdZkfZ7jvpy+UjhnS/nsY3KWYzpIdMQMsYxsJCnU8qU4JE5jLVnH9y5Z/8Qa EickWYQNHIsjYiHSrH3Ilh2QbWlcJnPIYusIblhHrACRgZvkc3kLQ0gzNYB7dAC+FNHWdBEH iFgSzXXZsuy0iC37RsSRzoyV0EcySRW5mFeN4SLX8hOjsNsayfjaYr6YxTVv/ucJLK+OGlIV tvWmvRdtqsP+xraoDtsb0t4F23vR1kT1OO7Vr1ctcdTUHkx7F981jlr8/oD2LmqJbwBtTTxo HPca5+a0d1FLHINoa6JKHFxfow28R3yjVlqPUTuZNTeQPEvmevwavxSxvH8Vefv9ZbmyrJj7 byefrbgT1VMvJGukoC5uiTySLZsjgc9y3UCcJRvFKX1VZJK/klk6k+Vz1qdWQAUhBpFmdapg ugH47+8MMtRqUIXmVoBHqNWpgrYele0+y68KzXHNoyUg/QFLW4GGu/yGWu3IM7etD+tJQoWN pIYIE3MQZs5j1Zp3mda6rNLy3rROxZUdoO0p8xDNPjlqBMLtZTwXszDH69eMebKL/jfPnzg5 TfvUc5ikTqItz8sInrvBKlBPM2evp4E8q48a7SFnMF+bczRDX1GFLGdxPiIRVa5/dCvjQ62i 9uadwNO1nqVGTkSsTCyzZCL1rrkDLMEweZ767DrP/5vM12c8vd5XZepDJIUkVJQN6WTqHfWa uOc7TtfbpJCEO+rpZKopy4u6RG3X40gyy5p2IUljeRv5St3SF+2Depz9Z51sJ+o8akBh79Ov k1TWt/B5LrnM9hiv7z49iiTV1NfJR4yTry+6P9ejSJJbX+exTbD8OkllfYtQ+gtxWI8lSWKC qcNieQFJZf0dPs8ll0kfMsPuqr9ylH6DJHO+Xdocksb2Y+YZ51vIUp1nB+q3yWa1Ve9ifRjZ zHXSjAy0o+ijHn08SR87dIEdRT/16OdJ+tmh8/m8mPjY7n+/vs51+DvXed99X7/h7tTJ7jBd wDaX9RzW01jP550q+lHjaYBaoFbo8YC0Ik3+H4zOr52yK0b/sDzo2zbdgLCuR5h9ViuB+rjH YEz7LtjpiHtUSJ/e+Siwk+6PnEsNWAu8A/V7mNgX7o91+X7oJ4ivWvszbHuRJKkMJNYGc2g/ j9lY6OXch2/rMYdfpg2m1SofgQ8TJ/T+PEjOv52HK3P2SyZHV83DD5TH3uQ5MVYfJCkkgRyq IJ1M9cr7mc/3M5//Ro9z32KuC2WO3898voT5fAnzeZje4jaEv9uQ+fAs8+EZ9pmtC9jmsp7D ehrr+ZX6o1J3yJWWW0VnVOqLO3UFtYR5T7ZkH3+rDTVBU94P+pCBpLfdDFGqJ+KZ/2NkEsJ4 zkc7G7TmPVeqZcyRQzlOhlvItIMQY+cj2g2nZvh+ua7gubCe7CYjVJI+ZO/AGpWGD1WKR7T9 LsYbeD7FOBO4HoayLUBvpb9oD/ZzXdqKOXIa6anyIuuHqROIecfEQmzGGuNBTVOJGo2nVCdE 3iYFY/gdUU4DDJVJPG8Zk2qpP+b39XKeI13wmeqMz5wLeqvbiLH4Ywq/az399/biasy736eY Qq1yQxTrr+Va9HCe19fkaMbgQzf5HrobVB8MUSOZ90+hh/0v3kn7UfMYHeTHPbAab5HOskD/ hffNWFmCUXKPRzeVg54Gz+dR1pvqQtWRfrrz/sk+9stwzVgxjkgS7dTlOfQJws0dlYSVx8L7 baHeY2IlE71c36QcuUj75DLuwWUIIvXpM0gUo7sdy7OjWB9nTAfldH3M892a378Kq+WHWO00 1IVOf8YRz/vg64zZnH2tGFsac8VFRHo5Iwgd5WH0t7frL5kfA+RZRMgD6EsiVDBj3sA893f0 cwZQp2Vx/I22i8dcLzfMxkR5SZ9WR9GYem6lQdVl//08N4nJY/YM+qU/NYT641X6zPC030qn Bf+nMq8n6EX8717qR/ihwXtnLudmIhwTq4fJdavKkRfwFOcijISTYPrrw+/oZ8/nNwXpS/Iq tedhUopg+1U043qYJ8djnl2kNzv+9LWc4/sCv2Ey2qmpjAtAHVJpxTZCaw1mWxRtIckgqPzp v5EWKgCGVqSevKVHWhqL5VCkcg9myw7I5thl85t38ZlPvILH1ddYUK7XucfyoPienxPLtRaC EHcgYp1nEes2QYh9DYNVCDqZfVhnE0Ko2beqeeijCjBTva0P891Q48Npiklkij0DpfZqlMpb aORaKKTtpmKskyqG+xX6OmXkH8upLOvrbl1kqARsNvuZeyxGHdNf2KPxpjyIRMY0WbXBT1QD /QF1ewflp88xh0yQwfoM7zCbyFqDiLV+VkGsRy5+bFDn8Irrw2PueQS5KyDdSUjhHo22/ZhT c2gPQLk9qNMO6V0OsFvtxN464eV73/Q1mO+zx+F/pNd3dBTVAsfxmd0kyG6WZJPdJBDYoYo0 6Z1AaAkQCKFMaKEFAqHDwlJCFkJTQSkiRRORItVFgUsxglRpFgRRioSmgAoKShNItvib/Ib3 znnncN4fnpzv+ezcuXd2drZls4MlvC/rB44Gb4M5gSMhZrxX0wMHgrfgN8hZaXCJ9vy/KKSN lKzN196vIVukQcEH8Dzj/83ga/Bu4EKIitddTuBGcG8pz+iTlpe4jzmxeKybEebjmo4wnij+ XXomqK+k8jn2d5NP47VQWbLJJ/D8p0vrDDv8t0xrpMtB56SleA/O0cJtAcdr4/8v/J6shBfQ aviQ4jdhLj7Lc+VEfMbH6PUsHtNvG1Klm/r3QJpxv1xPu8bBKQYLPvdH6nMTMWcRDlURddRr hX0qin6x0m60HHOnohl4hE2Q9T/nkyDXwHhl42G8nsNkSdsuLld2GDtArXW4jQwu6a5xoJyE +S40HTXSbz8vTwu/Q6ahFfgtshq/Q2qjFXidt0SpL/pf70X/b+mfQcW96P8JXOe62jWXF/hm wT6S5LWjqpJUdA9W+O+2NwopKA7hre7FNfRaUSdkRs0RHoJP237K/PPRcWRDyRi7gf3VEPSX h/vQE9QVLcbYULQGjUKbMP8K8zvQCMwpr49d1buEXsN4Fs53BW7fxm18InnxfHknYwz3X5SN cGwvnseiRLQQrUdvogKMr8UaHNuL58B7E+G58eO6+DujiWgD9s9F+7mm+D7xQH056ADCsXzn MOZGezDnJHyGdb2R9pgGIXw6+laiM9j3ANZi3uHY1w/h3H2pCOfmDSBtDfb7MySpsCGOmYaW oS58TIUN4FZ0Xd+HYxe2wvySqAOKRb3QAnQUleL194ejJP3YoxE+Xvxt+Vz4B/D+fadwuw3C dfPj2P5cpOj78Vz5cT4+jPkuIu1xnUe4Zl58K3gv4FyO668dHMf7GLdvQQvqjrL0180ErNFe E3g+/Dn6dXjeGL3Gem7mHct8O/UK9NbrHdO7pfd8PON/WsK8eF692msthfk2ojvoILrHY/vx lee7yevmLUQ7dXdhPFEPj8vXnxW/XrTSmS9OC+/hBcW/E/Tk84GnxqOBNLT/eUEtAnEhUwJx +Azc9S//pB0ljfmGLOFoqeQbppGpwmEGU8hk4WgGXGQSp0wUjubAKRwtwAQynowTjjgwlozh gtFklCjXGowkI0S5NiBTlGsLhpNhJIMMJUO4IJ0LBpNB3DeQDBBl24P+JI30I31JH9Kb9CKp RCU9SXfSjaSQriRZlG0HunCrM0kinUhH0oEkkgTSnrQTsR1BWxHbCbQhrUm8iE0CrUhLEdsZ xJEWpDlpRnqQpjxmE9KYB2tEGpIGPGZ9Uo/r6pI6pDZ5ldTiwWpyeQ2uq8591cgrpCpnvkyq cEFlUonrKnJmBVKeKMRByokyyaAsiRVluoIypDSJ4b5oEsVBO7GRSO6LIFYOhnMrjJTioIWE EjMxkZKidAp4SZTuBkqQEBJMgjjFyC0DkYlUjBwgfuIrXiB7uVVECskz8pQ8IX+LmB7gMXkk YnqCh+QBuU/+4pQ/yT0O3iV/kN/JHU65TX4jv3LfL+QWuUlucMrP5CcOXifXyFVyRUSngsuk QET3ApfIjxy8SC5w8Dw5R34g33PKWW59x60z5DQHvyWnyDfka/IVZ35JTnLwBDlOjpGjIgqf S/IXIqoVOEIOi6h+4BA5SA6Q/eRzso/s5brPSD4HPyV7yG6yi+wkguzguu08l23c+oR8zClb iYd8RLaQzVy3iQs2cnADWU8+JOvIWrKGrCYfCHs6WEXeF/YhIE/Yh4JcYc8A7wn7MPAuWUlW kOVkGXmHLBX2weBtHnMJj7mYx1xEFvLQb3HBm2QBZ87nlDeEXQWv82Cv8WDzyFzOnMOjzOby WSSHzCQziJtkk+kkS9jxmSxP4z1M5aGnkMm8BxfPZRKZyPtzcvkEMp6MI2PJGDKajOJDGcn7 G0Eyhb0RGE6GCdtskCFs2mt3qLDNBEOETVuXzsHBwhYPBnFwIAcHCNsM0F/Y5oA0YZsH+olI fAnLfUWkA/QhvUWkCfQiqSISX/OyKiLx/S73JD1IdxGJr3m5m4jEF7ucQrqKCO2sk0VEAuhC OnMwiXTiYEfSgSSKCHxvygmc0p6D7UhbYU0EbYRVe1O2FtbeIF5Y+4BWwtoXtCRxwqq9WluQ 5qQZaSqsNUATYa0JGgtrU9CINBRW7Y4a8I7qk3rCql3BuqSOsGoXsjZ5ledSi9TkKdXgKVUn 1XhKr5CqPImXSRVSmVTigoqcWYGnVJ4nofD+HKQcZ5YlsVxehpQmMZwZTaJ4gnZi43lG8o4i iJXrwkkYKUUsnBLKLbMI7w9MInwAKCnCB4KXSAkSQoI5M4gzjRw0EJlI8QEYwDw/9CEvKkKF GHuGhU9x+wn6Gz1Gj8LSlYfoQdgQ5X7YUOUv9Ce6h+5i/A/0O/bdwfZt9Bv6Ff2C8VvoJm7f gD+jnzDvOravoavoCrqMCtClUsOVH0tlKhfRBXQencPYD/B7dBZ9h+0z8DT6Fp1C36Cv0Vfo S3TSMko5YRmtHLdUV47Bo5aayhcYO4Lbhy1jlPjAIctI5aBlhHLAkqnsx57PLXWVfWgv+ix0 gpIf6lQ+DZ2o7AmdpOxGu9BObAu4A3O2o23oE/Qx2oo86CO0xTxD2WzOUjaZpykb4QZztrLe 7FY+xPg6tBatQavRB2gVeh/loVxzLeU99K5pk7LStEFZAZejZegdtNSUqbxtmq0sMeUpi02r lEWm1cpCjL+F5hmrKHONTZQ5chNltpqjzvLkqDNVtzrD41bNbtnsjnUnuae7Pe4Cd3xEiClb zVKne7LUaeoUdapnirrXMF8aZngjvoU62eNSg1w21ySX8ZFL9rjkdi65jks2SK5wV3mXMXSS 6lQnepyq5Exx5ji3O4Oab3dedxokp2zKDxza6Yx1JMD4bKclPGGCOk4d7xmn/kN9mcW2cZxx fPZeXnuR3OV9iBIlkZIokhIPiRRXEkWLpC7aXF225EuRatmWY0tGC7ip/dAkRn20Plr0IUEP BEVbtYCMJK3RFm0f9JIAgVPU8EMA54DhtxINCjS1k0jqLCkZiVqkbl/aDrlz8ZvFzG/+3/eB S/MnlUW4wWOJBeVLqwvKfGJOeWZ1TjmaOKIcThxSDiZmlNnVGeVAYlrZvzqtTCUmlQloP54o K8pqWdmXKCl7V0vKaGJEGYHzw4miMrRaVAqJQSW/OqjsSeSUAXh44OAcHgfGqRsYccCdADvS 126X7e/bP7TjwL5m/70dE1ib24Y2s1akf9SKnLKet37TirGWOxZUtjS35FjpjvSe9GcJN8pS c1sOiJzoETGzejZxuJyrtplsrQ13Vs86LPr8OdaMsGa3GR1wmxHAv89/yGPm33F3OJRlEZbd YlGZheYs42ZQtdpiMJkJx3OswW1A1WrLgImyAc6ob2zUj5VzrM6tQ5WMblSHyrpMf07Wtbbn AIZ4EAQgHGwwWt0FYnbnoF+/KiIEAvP5rfK+YLB4m9raW1yjx/avIRfXGvaptVyaXiMvrgFl ev/kLQS5OnULQfvLa6Ziabo2fv7KFdDnLK45902ufd85VVy7ADuy2tmCHeC8JYK+qeDs8tnl YHBlFlazyyvB6heOkLPqKKhOqt/lFThWP2erYxD8wlIzg83BZVhWdiZXvnjV/21B/tsb+B8v loOzAAACgM1l7B2CARigQDdQwDgYfb1VbBXpVK8WqYA8oJA5gAIPchnQAEHmZAFHG+IkVrIb +GdLSClLoWWQuf/u/Zl3778F27eQ0P3KvQq3ca8iJJOhULgd4b189TExKEWRpK+uDY3HY7Fo NNKDdna0ob46Bj7+zo4eNN6DRSMutGpas6zOQmN1Fnvn0/3Y6AaJnnMPLI3Uo247Y9ITiIdw S3R6tM3IejubmuSQm9KSKEGTdHNXti4722XbfB2jdJTWI4o2hsApPa3xWI1WBt/MEczHfyGY T/rxE5/cxMIdC3tjxHe1NIqT5G/sUkN3zmsNeoyskdMzhFEUSMoo6PzpwsYlWrJJlFZL6Tmt xmIRaY2W1HMbCQiqtFXBPsDeBH5I88qv0PPoBTAZVKOAMvmqxkm74N+c1/yN/m4a/tH5JWD9 iBHzh2+jLlkyAk13o9NPYt584LGtEHskM8PYUFPQksnYhiuZSkaQkkiocvfg7Mz9SpSPchU+ mQzDyCs+xcJw+1TDDnoG2waLRyOitA2Xovx+eBG42eRC1YuJYy14fcBk4+BrDdmZM91jx3ok c6i4eHlq6nzEiPubTHYOR/4YOpmNTfSH3TCQxoLxU4cKgpVncEqn+alnSA4kDqykE1dvXj7V P5jZzzEYraf+NDAQLR8/s9TiG0j60ieuTwJILQ2pvU2cBq2gD7z0eWqyoOOdLrfHF08kHUmH kOQFoPJytPHaZKIOp6KPGwsOgdfhjJRjhlKPZGpYPbt6dPXkmUqV291KiFehPfcis14rAlKl Z3v6t0CIUJk41GpjVZ3+OFLTK4UxGFXt4tS2oClKFCFHHHtbDBeOX5qYvhAR0MamgANHtKjG 7LVaXAKOjBEMy5LcwMxSIjWeajDRP9c6422xZw8VeW/oRLajnI14efTrqWs3Lh3vzcqTPMOx RILW0zgOq80lWyIeFnzFTMDTmR3c02LPpZp7Tt6Y+NFAX/vYwukzAAFDkOw49gboBC/uUqPD AXgVpLOp429NbgIhtB+FCp6PmoCVs6JazGr6WG7YZrBxF0DVBSsZ2IENVOF6MqTCc/y7S2sI UVWANbWpkKDgRLOJIWtBAFcxYuMUY9QzrnCxSz6ab3cZpqd6Z3oDHK3BNQZLavRA+AffM0dG znzncFOht9NJYSOC3ys6612dyomlBf/CoqfZwzJ6r89lrXcaX/lh+tqNbxyXDaLXJoCal+JJ 4iRoAZndXGSttzVTB3/Q1MVVPDZzXQvWmIOTGhqQTPtjR6Frt4epAoHRrsYlGqlqTMVjfeql /+Cf+DYJVDJuawzZcVCx5p+tWH3AbOMI1FP1z+6J7gYzJbYXFy9NBod6OszziNbksVrcAoFu 3oNu2qlkwx6uL/9ZJ/2xt5hpdncM5Avurm9du3S8z+htsyKblIEiCFhtHBkYDO9dPL3Udngh tXh9ApIbhnp6Gca3NpDaTe4XgUicxIHmNsrIGh+vd2Emky90GzXIZuAjfxuPB1w8r4/8IVDQ vye7nrgXDGMhXkiGKqqTwlZKwsgmVX3T+BSrdhTlI8nPqQmlPhvnIL8Of9UvVQvsZfni3ZuL FHH0lDxfbNdoNDhtoPXp8lxk6oWpFmts/MsvHSmfLdb9ZKzQOzcc5+ePXVF86EOYdQLeHvvc olE0GvRah9Om0UtGfdO+r5Z7v339hfmeQF8pHs20Dj2TsLWmALKV3ryBhYmvwLx6dZf3CS7e /WvkIcwSPPJQ9uVTg3K+W86LYl7uxkFA/2Bkjyv1oNtdLwwOxh7I9aM7B1+HatlYz0Ba6xLM ryGVAiT2JBsY//XSJ3FsJ1TViOE+H6Yyg+lpxw9rqcC445jR7fwsiSIWRjGS1pKU2eGXgukW l45/Q2fASY2Ood5c5bvKSwOtSQrHMRxaUZSBNXOBdNCpf+WCVgeTs96g/ZqVSymn+sX2ZjdJ kkQc582SCeZm2hYvJ6dZXmeRzJz205+Vz5UaGZLQa3GjaoBhGDToxiIGgZYsoqB7bu+5sUZC oycJAeqzDxJX828KlMBruzzbEO1IpdKlMacj7UjvUZ3br2sGjo4UcOBEPO8upaN4vfy4vdCk +asgSEOP6oelD2TiCT9VnaAS3HZaNatEQ+uV9e2cwiNRoXYFdf/xG+HNEP/0CmKxv7NfZrFR XWccP+cuc9fZ98Wz2R57Zrwz4/EajzF4GZvYYMCGsASDCyQGY6AsaqF5gCLaKkkDUirUh0YU VV1IaaBpKFHVIKcPVSihSnmolDRSJNQ0cqNEXQKJx/3uzJ2xZwjBtA+l6rmj39xv7j3Xvud/ vu0stmyXGHp2P//48MmwXsIsJxkEuaxtXWfjSGdYNAYlQ/eG3c39Ozo82URxVylf29Xg00Mf FcpkiZqhQ4OVAbto1mtsNodZsrpstqpltY8dCpT3d1Q0jBxc3gKVadfShcW9YXhiarI62rvE 2z5xSskYHXN38IdsLTKjMHqicEUuhX0WL1TzsaQk+rxeiy/MlDn1r+Cel9lkWZ9TTZPvrJgx ZtS++daMUsNB4l/cZ6zi4Vm9ch2l+iufTN9njZ6ItyRkoliNyQ1WuZlK/5MSLQGH02dkqYuQ PaFIg4mZN8DFRdEe8njKnYLgLP+0npeUCizx9DEuW4s5BLX2kbk79EXoYmJ31ZQIYwbvpBk6 GjFbwvDxJU1Rb8SsreuzeE1s1BfmnGXdzgFtdhod+YIyPe26tqQh62HgYA3K/DMKJK33fToT 5hoOY1smHyrzr8C0KkS+c1EN+qLRmT6MtSLPW0tdHr9FZNLvbqVEa8ABImgoLGW7Fp+RwWfx C7zFVepwBMw8/T3ZZU//LN1qcnKClmfBCwT8cVqbUQjEme9WPvs9PixoORp6cdBK8YqPQCsr 6inSymBFUlJEolViWEM3m51TZv0VKZSpS3ffhLkmimZ2a34xcy2X8vLO3NrNvxnKvg99AfJG C/pK0fuE6l0ud4jR0UiPLbReV269nWxMlbt1jEtfH+L90T7/gLBAeYhrZd2g64HV+o2yZJkm /f5PqeuVWyFzY2NcrVl0kfdy6ppd4LkpmJk/66eTHBtrj09u7jcOzU/951gwl1isbj2Dg/pl m6bau9Y3OaibpcvKZn+XU4Kq8rXY2vvbnzy1Nr0779rHYfVoJah/EoROPtw1CrH8KFT/G6CS HdWi0UKdLkNf5UsKyGFwUGbaUaakV0ku+bs5FX5vQTM9o25hZhRRxLtvL6hN85U71yxmchxD 3/A0jx58fuPjJ0cj7paRjLUu8qK1frCpbWxFc7nJVv9oU/sWxaL2pc48c3RTomb0qZWpM09/ bVOidvSp9Q1DCW+0b2zyy00NQ03eaGpsz35EzX2SPk2/CXOLQE/4XHHlCMQbZW1cG3do7Y7s 9iNqlxvjAYarux1K2bUOP2Ny95kGmxez/YBAzuw8Fv8HFqhSscA/FjrD52w8Mim+OvVIzLaG EiCb2aEXxLNUpm0Ed9B1Qds4sD3pOQ8JvyK/6YjDdi6gp461fPv0Nyc6Tf6oKz2UixTmL5Dn wS9+HOjvjMRGDg5Ge2OeNsjz57qXN6x+Yu+ebCRRH4OOS9BEcWddaTSWmDyoxCO/gh1JQ7I6 ZfIYK0sqNPZgnz0fy9kIqp3O57rLSL7P8OKO5h4BY7fBm8E8tDxvtnstwXVre4yDhTlfjZWA vSO1ssJY6rVrNPR3GbvX7zZxIte64+nh9OTdIfL98EBzkOUEjUbJJcLcDPUBKNCNzhcq8Cqk kFlo+WLQIUdtrfBBpfpY0r38eqWfrWOTLM2K15Mp/+1KFDFEKJmO1L6TdH/+TsqYrQ/N0AMq 3Z/iUGX/yd8q3JlREGxMvmoUNiPxWGZ3QqmKfqCR9IIcqOuqqVpW44gPbRyMJ7Y/t752uKtO y3OUhhNFTg4mVrUnBmPO2OCGwXhs8/GVoZ62KkmiJ8SA32Z2WJzRhLcyHgm3Dnd0Hx6p19nc Mm+UeZvS4Ll9bnd1WyASj0aah5NLp4ZrZJNNEhWlp+Y+pF5nzqPl6BtFvhZurIomokt5oVPo TAjRaF3CnrCjuqW9ic42vuo9IRpo7NV/kgzkYw0kmGm41tzcgWuvKaKamtWAnZ42nMhu58yL eDrniaX0vfcj+Y6aynfUmR6cep3SiJJOuDXOaKJ17soSG88L0CtzvD9Sa29a1eSmWJYePyLJ GtmsPRrFkiVTnVkcvaUX6VOC1WYzimnRGjMuqRVEQdJrfV4Hx+kkjWPJika5xO/X4Ttas67c b7vJyQLDCDJ30wY6fhWq31n6VVSP1hZn9QA+8ZLJVnmF8iGE/PjTpJS0VfcFte4+td0wKZKB Bm/NGN7OuKFQfFstbJA5shJU0KFQ3oHMVpBAVYE+q2HKN06dGOJMTr/NF7IK+DjGvMnncvmN GjzBto6t7q+gJehQHF4jR5+DPmDXn97+w1ZJ5iiG14n0GsnIaXUQlJxWmHXJmnU/eGn6QKbr YAWY5zNzd9irMM9+dKx4ntX4R5e8QbOp7gr+DLqAVnz8kqnFFFx6hdLDxKvwbNKUDPb0xftq 2sy0s6KvsN3KSZDfi6laGO79RLEqcRrnjEJ51IamQCn2KkuHHtt1tJezuoNWV6lV6ErfYA2u Co+n0ilvBtHMAZcLGjfczeA1jGjy2iH78zjF1mxYu8JPydagy+EzsPQ5yc4XSEidnp2EgGYy co4IRo2sF7JyOgSB+jOvVcSV+Vk3z/f+9LXfbsmJmz3wEIFA+H+H+vqDQ7+LEPOPxaGpK4Tb tDj4Nx9uxLEHRxr495EPzaPl742u5t7oxQfDsGoe4+pCTL9aHBbNQ8pfEbINEAgEAoFAIBAI BAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoHwYCAKYaQcFkQrFuVFGkpU LmQv/28fmMJ6bMAu7MWVeAh+bwQm8CR8H8BH8Ek4fws/i8/A+df4tf/22z50B4O+A99B5AeL QlvQVrQNjaMvoe1oJ3oSTaDdaBLtQXvRPrQfHZybg7Fb0NgXjDkAY15A59HL6DK6it5Hf8MY 05jHOuyENSrBIZxapNvRCM199IUjdOjF7Dg4tuWeQRy6A79y/6MBb1JtGlnxs6rNgH1OtTVg /1K1OXQEX1eihBGUv0kNqDZGHuqCalNIR72h2jSKUH9UbQZFaEa1NWDXqDa8Dz2KfggKN6A6 +DSBtQKU2wqKTYJmk6DkfrjWBdZe0FH53gJXdoK1G9XAnU7QeALOq+DadrQD7u3L/BqH8ziM PgDf22BkFzw3AWPG4NpOGLEzM24czvvhKWWkH0b44TyeWTtlvcYzv7bB1X+RW8UsDQUx+CoI rUsdXASH4Fr6XhEHB5fXTqXYoaWj6PnetT18vSt3qZM/xElwEv+B0NlB9E84i6OLIJiLFYoU 0UEXp+RLcskXEsIh1w2THZF0NFlgLu9vFnv7P+olMDKcK7AB0SOkmUOo3yVNMvJc05A1njGw cx2khCbkRe4yREdXsFWr7cCeTp31to/QsG5snURtTQRJnkNHD4booaO8cicqi1rtepI0Kg2Z 6yOnq00kJf2+cYZAe1Aah8qBBKcG2qNyKgN0MlMj6Y7BBs8c7C8mCdoApYGe0UjvuyhReZAm iymB5QKpnRh0WvnoT3apJdqiTtEJ5ap82qwO78+ELGETvoqsiiZPNWeOvxH5b3c+XKzysABi VTzQjVkiGYtDIUpPhTbdogJftOXz6/3L24uD8u6zWC/yiZs+nt4HebN5Nn7Zfr1bWStuECx9 /BLeBBgASoAeXwoNCmVuZHN0cmVhbQ1lbmRvYmoNOSAwIG9iajw8L1N0ZW1WIDc4Ljg3OC9G b250TmFtZS9LTkJBQUMrQ2FsaWJyaS1JdGFsaWMvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRG aWxlMiA4IDAgUi9Gb250V2VpZ2h0IDQwMC9GbGFncyA5Ni9EZXNjZW50IC0yNTAvRm9udEJC b3hbLTcyNSAtMjc2IDEyNjAgMTAxNF0vQXNjZW50IDc1MC9Gb250RmFtaWx5KENhbGlicmkp L0NhcEhlaWdodCA2MjUvWEhlaWdodCA0NjgvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNB bmdsZSAtMTU+Pg1lbmRvYmoNMTAgMCBvYmo8PC9Dcm9wQm94WzAgMCA1OTUgODQyXS9QYXJl bnQgMTcgMCBSL0NvbnRlbnRzIDEyIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDU5NSA4 NDJdL1Jlc291cmNlcyAxMSAwIFIvVHlwZS9QYWdlPj4NZW5kb2JqDTExIDAgb2JqPDwvQ29s b3JTcGFjZTw8L0NzNiAyNiAwIFI+Pi9Gb250PDwvVFQyIDI0IDAgUi9UVDMgMzEgMCBSL1RU NCAyNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDI5IDAgUj4+ Pj4NZW5kb2JqDTEyIDAgb2JqPDwvTGVuZ3RoIDI5NzgvRmlsdGVyL0ZsYXRlRGVjb2RlPj5z dHJlYW0NCkiJ7FfLjtvIFd33V2hJBhDNerMAI4uxg8ABMpiBNZhFkAVbTXdrIlFtsduOf2OA yffm1INUFSmKlNuaJEBswLT4uHWf55z78YYsNosbzTNdLCTJckIWS6kysVA0XxyqG6oy3j3Z 3fz8h0V98+pNIxfrZkHs32aNO39+Txb3Tfx2aObDzY/dS9+tbl6tVhyfrj7c5AvOzNlLd8kX Bc04X1BBM6FzsVjtuuNy+9ccl2d5ntPFao3PV59vkjf7el0d6iZd/WJMM2eaZUoxgU9Wb817 65vX+Ir90b3THp9Rqql/p7P6t+SQ0jwp0zzjyaap7tK/r/4SWIaLgshJy4xo987SmBbSvJnc fom9zDOtqDpl60+rm4+uPETSIK9RfaLK+foc6xI97dfjfB0IExlFIajIBHOFCBP0ffX8/ikl JCt8mg7pktIio8n7FOGS5Ifve0kTGaF6OmlxOZg77YdDSiSM7h/3Tbm1ho/ZwSdj3RsnbpCe +PHp/NA2P8SesnQX/CxIpuB2zjNKfH5sgX9Lo5BIxgRhQR+0GXz7/LjdrFOTsjJVGUuQTpPI quklDgfgz3S3KXo8hXDiTqn+mS4JM22MK0W1Glzx8wmXIhPd7RpXHJTc9w5nWV4oMn04p2GI yh3+iLLxTCb7T5u76jCwzBkabHqIvOWkft7dVodNfR8PEAdeKG9nwrlj+pNm/VDtSm/pWGNT YFNdmrOswG2e96r7r351qQhscxf36gGBU1PLFOXHv334YJyx6ciDcioZlFOhXhtbP2LKKVFG U07Z3aztVZ8s5vyDjxEl99v9LeYuyjvik3OMMdaf5+Q9wCGyRTJJZ9iibOhaVMguTkLkSUwd i9NPS7lF4Zgtm07Kuy/D/OVz3GzPnlk6f4jvQvOQCpjAnNLupInGI0ecFOi7/e222p2Ytwsz LOzJm6bPWHIajaIcdJj39FAC8IpjzMf6X95LwtlcPx/stImkqlMNCOsbpwDsr+r6b9NaueP9 bbn+R7/pRTHDVNxNzGeyMROPtCWHvUVw4RFcDIYezy48pMOxd3dIaWGoafM0nAVyAYhZq9pZ /WtZl/epdd4MWpHsbOHkoHDoZD4n1907gWIom+YZbWFQsDSCRCWQiANizUdCCMSFVmPSK9Yd A3ERP54QX0fi4TRTCyNMFAlUl8eQp8NzYzKnTkyQvhxBHRrv9nfVthlQYSx3qJT4+mvkDhmH /Bkamha0P0pOVwhUNpCDYWMKns+Q/ZHhwjr5UDZ9J5mW0xoltuUCrvd9U7ng00KqU3o2eYWn jg8fjJDSmJel6ei1uZh5WWqn7CQ64lNKAX79HgfqazGdjUg8Xke/hcCyubMjPwYs+Gi+4gyn 3s0HOzkdXF9oUx6nY1wnFoDHi2XiC1VQWCnR7qtABTCgXcXuwdhYJUyDEOgMC4MkMcwLtbHZ 1wMYnEW+NILZgCGrAUOyOcQQmiP0zPxdzF7O2NNDNTAm5tAJG5J3U/ajpBmRX6MDvgWGf3u+ O2M/gALpdGV/P8WmdJEOcPjYL3WeFZdqoWsvRYEKwJgDGxwtk4XOUEyay4wbOv8ZtD9G5ywX UHlDPuchkalkn2KLBYIvzbrYYS0LB7NLXP28u60Om/re5A+zW4zNpVWuiOHHNgomeaBIYi0T yZyhloke97VMLJXaJEGU6t8jSzZCWB7aoxTpYc7euLT7en/B+5kUR39P1GfcOZZjESLXc44R NPYgmf3OcEbGRB+DhCWR5jsn944aP3m7r5o+XuZzoIfSPvRASD0NSSGfIcpERJQeJ5t1aslw 2wdHOEim19qeTnJMc7/d35bb7ZdRlYAcZfjPBTIhNK/zweLI53BPrPW9lHTdCSy3MNlHwmk9 Hkh7Unjx8WHv8bcvERH15crCSXHks88PekbNryIEbLDEB/vZBJvbYJdmKpOtuSZ39leR/Jry YpBYvEbmi4VgbUK/VuYco+0s7oHjBrSOY2esO0OWOAes9nbT4mvLH0JAoQYsyABJPCtCSAq7 XuG9GNWTd6ufBqzkrWrglfJWBcUWJ8+bte93+EapFyqrX9PCLELOeQSURz2hPA6s3qdL07Lf +dcUOabHq9GyvjO+4lnEwq3krktsME5Q+x0UPotpvvZrSPK4LWtnX+v2K+i4u92mNvodAhMC hkLFoxoalxKa3ih6c2ufGv1ox5j5SGWW66jGXhytzSpAnCjkSW3Q1PlKw7RoFWyawm4SWDEL s2nic+qlKu0FOCZpw/JiSQykQyQ6Yj0yEB3x4xHR4V9y0IovsUOh6U1DxDx5ApR9H50G5RO6 KeBi+aLGdx6xUY8KhCoCj17neBLLg9YlPzTOpcHUnNYHl8zPKf3ivqfmTD2qX17uIEVzC3/A mdE94yFHk1/VQ64ypgL9F+HGGccUTlbXdExBt4XabxSyxp1kDMvSuHh+uZOM2waUF6pn9zHH SfSa3nEK/a372r7F7DOOCX1lxySLm86V9qt5YzwUIbVBRnm1UIRicZuep6xxTyVOxaLXtZJD CuvzNfyWjHTzewF7nvEfiZAqQvxruK1UN9GT7H3ST0Vox0wnZOaS5ZngECFICrbVViR42C6b 5hmdB1RxlVVJPZCyPMv5nIWB/X8NufoacvGiEKksbZp16S75ghP0KZo35z2t9VsanW5SQkIF 7dHtDQ5iOLkq0wIw9uTatUrzTqiEW2wuOJmOEmzthHjZrzAvcr9QjZS3oMN14LE67Mq6qsGw 3A9S2NeCzljSGA8Nu7bZ7ev94377JXaSAzjVdJBE06B3qHf1AHiy6by3V1TSrphI5ZO9odFU Br4wpkVibkncat/Z21cwvIMQpaIzmoufyF15OKSUuBNJAu4vTHV3I8kUWF1mjDMwK4hd6yNI 4ChyEiQonR5t0bZNpFTCPHCueK99jjBuJkHJBQGF2H0FkWJoAFujKN6bJObUu/0+oCDXLZEO EKZ23AoBG3GJ4WW4B2Fjq4iLnV8SKoHWTa2D3Sva2uKFbrC1xY9Htjb/UpsFYZe2/54k9FfG 3ulC2tMDMJvCMceBybvd476pmrhhMIAFn8EpBQ05xXP3PQKRRm4QRFoDj6khVoyRkYFboEYf G1V+yZBGWd3Udi6NXNh8MqKyz97AeCJnoJwKIaAId6ZwHAUj07ZiKPZJea7L9bp6TKWtvkWt 8nbb91ZkKOQF3rpcqCMhmq7af7Is2M8DGnS6olGWvwacRQTO/IXgvMTGk2tJnHojR8VBA8dM W320DrHk2V9xuDZutc933uH2d228xIgPZMLSjwmuNDfHvA1VQYCZhdWTHWbqDC1ZQMzORAuH ZSFaXKYtAkxgE2doem77+0aBaJkV4gh7R24rLbdxz22Bjj9pB+qgW79e5+jzk86C8YxY8s4S pApYfYm7zkDgLmVRp1PL+syvS0bKPth+4a7z0cvmrpmHWUFpgSOmKvDyoHCR+rhx5r6Z6iqF 5eTzLF8ZAxdN+soYxl11vgropLk02R5jDIQ0yTpAN5wLPW/m15KIaXmbbcuaKtnc4xUUSNkt 1t3yr7/6+FyaO2bPAN1IlGtO0FyDodhU13H0OO8KRCGToLsuCZoHQ2Jipk5N//J8t1lvyq0H mLOeCgHYZJ0JD4S2UKPFerHfQrJesfxwP+4/A58cqtq1jxgJ08zKuaQgEhbsXePd9uIAJGik 0KfQKVbekz6j0cnkcLzcXQFmCljB65Gnh2pOi8gCQlRf30lwBBODCU7erX6a46WCNtBiauQU ipMfcQZyorjISfe918OrWX6x/Fz2BJYHPrKDROvJcAeJHo/tIKEsMDsI47+nqADxFYKd2lBP sHjscste1uX/OCNDb1KpAhU+SoVxFC2vuSj+J2gtDqAdaxvAdSgKsC3a3XA2G6CAebRajCAw 1Heh+KK/innowwJWoCLB0UPMifPRAogr6DfEjzPfCqNhFQLsD+JL90oabn2ycAlcvU//LV1g nGk4wZIEQIABAIEkyEsKDQplbmRzdHJlYW0NZW5kb2JqDTEzIDAgb2JqPDwvU3VidHlwZS9U eXBlMC9EZXNjZW5kYW50Rm9udHNbNiAwIFJdL0Jhc2VGb250L0tOQVBQQytDYWxpYnJpLUl0 YWxpYy9Ub1VuaWNvZGUgNyAwIFIvRW5jb2RpbmcvSWRlbnRpdHktSC9UeXBlL0ZvbnQ+Pg1l bmRvYmoNMTQgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDkgMCBS L0xhc3RDaGFyIDExOS9XaWR0aHNbNTE0IDUxNCA0MTYgNTE0IDQ3OCAzMDUgNTE0IDAgMjI5 IDAgNDU1IDIyOSAwIDUxNCA1MTMgNTE0IDAgMzQzIDM4OSAzMzUgMCA0NDYgNzE1XS9CYXNl Rm9udC9LTkJBQUMrQ2FsaWJyaS1JdGFsaWMvRmlyc3RDaGFyIDk3L0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNMTUgMCBvYmo8PC9OdW1zWzAgMTYgMCBS XT4+DWVuZG9iag0xNiAwIG9iajw8L1MvRD4+DWVuZG9iag0xNyAwIG9iajw8L0NvdW50IDMv VHlwZS9QYWdlcy9LaWRzWzIyIDAgUiAxIDAgUiAxMCAwIFJdPj4NZW5kb2JqDTE4IDAgb2Jq PDwvU3VidHlwZS9YTUwvTGVuZ3RoIDM1NjIvVHlwZS9NZXRhZGF0YT4+c3RyZWFtDQo8P3hw YWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4 bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4KICAg PHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1z eW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAg ICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIj4KICAgICAg ICAgPHBkZjpQcm9kdWNlcj5BY3JvYmF0IERpc3RpbGxlciA3LjAuNSAoV2luZG93cyk8L3Bk ZjpQcm9kdWNlcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3Jp cHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcD0iaHR0cDovL25zLmFk b2JlLmNvbS94YXAvMS4wLyI+CiAgICAgICAgIDx4YXA6Q3JlYXRlRGF0ZT4yMDA5LTExLTA5 VDExOjE1OjQ0LTA1OjAwPC94YXA6Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhhcDpDcmVhdG9y VG9vbD5QU2NyaXB0NS5kbGwgVmVyc2lvbiA1LjI8L3hhcDpDcmVhdG9yVG9vbD4KICAgICAg ICAgPHhhcDpNb2RpZnlEYXRlPjIwMDktMTEtMDlUMTE6MTU6NDQtMDU6MDA8L3hhcDpNb2Rp ZnlEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9k Yy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8 L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4K ICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5NaWNyb3NvZnQg UG93ZXJQb2ludCAtIE5ldVN0YXJfU1BOX3Byb3Bvc2FsLnBwdHg8L3JkZjpsaT4KICAgICAg ICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICAgICA8ZGM6Y3Jl YXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+dHJ1 dGtvd3NraTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwvZGM6 Y3JlYXRvcj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcE1NPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvbW0vIj4KICAgICAgICAgPHhhcE1NOkRvY3VtZW50SUQ+dXVpZDo3 MjEzZTMzZi1iODhhLTQ2YzUtYjFhZC00MGE3OGJmOTAwYmY8L3hhcE1NOkRvY3VtZW50SUQ+ CiAgICAgICAgIDx4YXBNTTpJbnN0YW5jZUlEPnV1aWQ6OGZlOTFhYWUtOTg3Ni00ZGZhLWI5 ZjUtZDMwZGZkN2IwNjJlPC94YXBNTTpJbnN0YW5jZUlEPgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRz dHJlYW0NZW5kb2JqDTE5IDAgb2JqPDwvQ3JlYXRpb25EYXRlKEQ6MjAwOTExMDkxMTE1NDQt MDUnMDAnKS9BdXRob3IodHJ1dGtvd3NraSkvQ3JlYXRvcihQU2NyaXB0NS5kbGwgVmVyc2lv biA1LjIpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDcuMC41IFwoV2luZG93c1wpKS9N b2REYXRlKEQ6MjAwOTExMDkxMTE1NDQtMDUnMDAnKS9UaXRsZShNaWNyb3NvZnQgUG93ZXJQ b2ludCAtIE5ldVN0YXJfU1BOX3Byb3Bvc2FsLnBwdHgpPj4NZW5kb2JqDXhyZWYNCjAgMjAN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA5MzQxNSAwMDAwMCBuDQowMDAwMDkzNTQyIDAw MDAwIG4NCjAwMDAwOTM2OTUgMDAwMDAgbg0KMDAwMDA5NjMxNiAwMDAwMCBuDQowMDAwMTEz OTQwIDAwMDAwIG4NCjAwMDAxMTQxOTggMDAwMDAgbg0KMDAwMDExNDM4NCAwMDAwMCBuDQow MDAwMTE0NjY5IDAwMDAwIG4NCjAwMDAxMzU4NDAgMDAwMDAgbg0KMDAwMDEzNjA5OCAwMDAw MCBuDQowMDAwMTM2MjI4IDAwMDAwIG4NCjAwMDAxMzYzNjAgMDAwMDAgbg0KMDAwMDEzOTQw OCAwMDAwMCBuDQowMDAwMTM5NTQyIDAwMDAwIG4NCjAwMDAxMzk3ODIgMDAwMDAgbg0KMDAw MDEzOTgxNyAwMDAwMCBuDQowMDAwMTM5ODQxIDAwMDAwIG4NCjAwMDAxMzk5MDYgMDAwMDAg bg0KMDAwMDE0MzU0NSAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDIwPj4NCnN0YXJ0eHJl Zg0KMTE2DQolJUVPRg0K --------------030508010804000907040106-- From dean.willis@softarmor.com Wed Mar 24 09:54:05 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F163A6BBD for ; Wed, 24 Mar 2010 09:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.933 X-Spam-Level: X-Spam-Status: No, score=0.933 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ugg-SAnw+6w for ; Wed, 24 Mar 2010 09:54:04 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2B42B3A6800 for ; Wed, 24 Mar 2010 09:54:04 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OGsMSI024132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Mar 2010 11:54:24 -0500 Message-ID: <4BAA43BD.4090505@softarmor.com> Date: Wed, 24 Mar 2010 11:54:21 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:54:05 -0000 While explaining his concerns yesterday, Jon mentioned that one of the worries about "unused" is that it might contribute to "site finder" activity. As I understand it, a "helpful" service provider might, after handling a query that returns "unused", decide to return to the user an alternate target, perhaps to a competitor or something. We see this behavior a lot when looking for web sites. The worry is that if the operator KNOWS the number is "unused" that they'll feel even more justified in returning something else. However, Ray noted in our followup discussion that "unused" also provides a regulatory point. Since this is real "carrier provisioned" data, local regulators could reasonably forbid altering it ala "site finder" and mandate that the "unused" record be returned to the querying node. This might well slant the discussion for "unused" towards having it standardized in the IETF. Opinions, please.... -- Dean From philippe.fouquart@orange-ftgroup.com Wed Mar 24 09:58:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAC63A6C97 for ; Wed, 24 Mar 2010 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.482 X-Spam-Level: X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLJxvg9Yw+z4 for ; Wed, 24 Mar 2010 09:58:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by core3.amsl.com (Postfix) with ESMTP id BD9DC3A6C5E for ; Wed, 24 Mar 2010 09:58:28 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A64C2104CF3 for ; Wed, 24 Mar 2010 17:58:47 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 750F24C026 for ; Wed, 24 Mar 2010 17:58:47 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 17:58:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 17:58:45 +0100 Message-ID: <27882_1269449927_4BAA44C7_27882_7866_1_B2A6809D68602941A1341092939DFCE1D84FD7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4BA9743E.7080607@netmagic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] We need another acronym besides SPID forservice provider ID Thread-Index: AcrK9wM1ep0tW2dsR5e7660cSWyF+AAdu3Pg References: <4BA92A6B.2010309@softarmor.com><35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com><4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us><4BA96E3F.6010406@netmagic.com> <000601cacaf5$9b3c0280$d1b40780$@us> <4BA9743E.7080607@netmagic.com> From: To: X-OriginalArrivalTime: 24 Mar 2010 16:58:45.0286 (UTC) FILETIME=[43CFF460:01CACB73] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.24.153322 Subject: Re: [e2md] We need another acronym besides SPID forservice provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:58:30 -0000 > The proposal had many significant flaws and received=20 > no apparent support at the meeting.=20 FWIW I don't think this is an accurate reflection of the SPN=20 discussion that SG2/Q1 had at the last meeting. It was more=20 a problem of people having different use cases in mind, so=20 the participants were more comfortable working on requirements=20 and use cases for such an identification scheme first,=20 rather than defining assignment criteria point blank.=20 Without prejudging the outcome of that discussion. Regards, Philippe Fouquart SG2/Q1 Ass. Rapporteur -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Wednesday, March 24, 2010 3:09 AM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] We need another acronym besides SPID forservice provider ID Hi Richard, > It's my understanding that SG2 has a separate task underway that Gary=20 > Richenaker is leading on the Global SPID. The IETF DRINKS WG received=20 > a formal liaison from ITU-T requesting that the DRINKS protocol=20 > accommodate such as identifier. >=20=20=20=20 Actually NeuStar made the proposal out of the blue. Gary as you know works for NeuStar. The proposal had many significant flaws and received no apparent support at the meeting (or anywhere else). Other ITU-T Study Groups had suggested that IETF Enterprise Numbers be used as they were the predominant SPID in use, but needed a better trust mechanism. A SG2 correspondence group was formed to further consider it, but thus far there has been no activity. I think you can consider the effort dead. --tony _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From richard@shockey.us Wed Mar 24 10:06:59 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7E23A6C97 for ; Wed, 24 Mar 2010 10:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.156 X-Spam-Level: * X-Spam-Status: No, score=1.156 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFYDiYQ7ZWeo for ; Wed, 24 Mar 2010 10:06:58 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 4FF993A6872 for ; Wed, 24 Mar 2010 10:06:58 -0700 (PDT) Received: (qmail 5483 invoked by uid 0); 24 Mar 2010 17:07:19 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 24 Mar 2010 17:07:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=PEo/We+NwOl8D69sr6N2zRBJCS2xiDauq5djOCps22tkDAeMqv9k8OpN4KUVXZDtr6z+cLWujb7RoSz66eRGzzsGpcOySBO38ShLs7ts+s3kWuD2TEYptmtcUFi0zr7l; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuU34-0002HZ-PO; Wed, 24 Mar 2010 11:07:18 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'E.164 To MetaData BOF discussion list'" References: <4BAA4248.2050601@softarmor.com> In-Reply-To: <4BAA4248.2050601@softarmor.com> Date: Wed, 24 Mar 2010 13:07:15 -0400 Message-ID: <00e801cacb74$7448bf90$5cda3eb0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrLcc3rOVGX/xjLSpiLxqe/UuSh0wAAqFCw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:06:59 -0000 Short answer NO. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, March 24, 2010 12:48 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] alt structure suggested for CNAM Ray, Bernie, Brian Rosen, and I sat down with Jon Peterson yesterday and talked about things. Here's a point he made that we may wish to consider. The usage scenario for CNAM is entirely different from that for our other current use cases. It's something that one generally queries when receiving a call, not when placing a call. The data returned has absolutely nothing to do with the routing/numbering topology. It's not "metadata" about the enum tree, it's "data" related to the phone number. Putting it in a NAPTR record is also pointless: not only is NAPTR a clumsy format for calling-names, one generally does NOT want or need the CNAM to come back in the other cases where one might query for all NAPTR records associated with a given E.164, so having it in a NAPTR simply creates extra network traffic and processor load while achieving no benefit. Consequently, one approach for CNAM would be to define another resource record type that would fit the problem space better. Would this be a viable approach? -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From lconroy@insensate.co.uk Wed Mar 24 10:10:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871D13A68FE for ; Wed, 24 Mar 2010 10:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ufj+9CtM86wN for ; Wed, 24 Mar 2010 10:10:18 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 363A93A6C13 for ; Wed, 24 Mar 2010 10:10:14 -0700 (PDT) Received: from [127.0.0.1] (unknown [127.0.0.3]) by insensate.co.uk (Postfix) with ESMTP id 057721198FF; Wed, 24 Mar 2010 17:10:33 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Lawrence Conroy In-Reply-To: <4BAA43BD.4090505@softarmor.com> Date: Wed, 24 Mar 2010 17:10:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BAA43BD.4090505@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:10:20 -0000 Hi Dean, folks, Um .. when we originally did Unused n=E9e Void, the plan was to provide = a hint that there was no one home, so don't even try. This is the = internet equivalent of a tri-tone. That hasn't changed. Now, it is possible for a comms service provider to send folk off to = another destination if it gets back the reason code equivalent to = tri-tone, but I had not realised that this was a problem in the real = world. You could say exactly the same about getting back 486 busy in the SIP, = or only an H.323 URL from ENUM. Thus I still don't understand the problem. What are we going to do -- set the protocol police on such a wonky = carrier that randomly re-directs calls? atb, Lawrence On 24 Mar 2010, at 16:54, Dean Willis wrote: >=20 > While explaining his concerns yesterday, Jon mentioned that one of the > worries about "unused" is that it might contribute to "site finder" > activity. As I understand it, a "helpful" service provider might, = after > handling a query that returns "unused", decide to return to the user = an > alternate target, perhaps to a competitor or something. We see this > behavior a lot when looking for web sites. >=20 > The worry is that if the operator KNOWS the number is "unused" that > they'll feel even more justified in returning something else. >=20 > However, Ray noted in our followup discussion that "unused" also > provides a regulatory point. Since this is real "carrier provisioned" > data, local regulators could reasonably forbid altering it ala "site > finder" and mandate that the "unused" record be returned to the = querying > node. >=20 > This might well slant the discussion for "unused" towards having it > standardized in the IETF. >=20 > Opinions, please.... >=20 > -- > Dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Wed Mar 24 10:12:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9933A3A68EB for ; Wed, 24 Mar 2010 10:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.154 X-Spam-Level: * X-Spam-Status: No, score=1.154 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpR28PMh8CCV for ; Wed, 24 Mar 2010 10:12:10 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 7D2263A6882 for ; Wed, 24 Mar 2010 10:12:10 -0700 (PDT) Received: (qmail 12258 invoked by uid 0); 24 Mar 2010 16:12:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 24 Mar 2010 16:12:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=U3vXKjZBYT1HtP8S3eMHzzj0uwp0PSki8DikKTXwk1lfj2vf9yAGh7aibAgkdh8Swl1VpDedzsddeQO0+87maRkFyaUD3Pj6hGqNJ5fOLSir7wlk4fam1ssHJ6P+D8th; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuU87-0004wy-2C; Wed, 24 Mar 2010 11:12:31 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'E.164 To MetaData BOF discussion list'" References: <4BAA43BD.4090505@softarmor.com> In-Reply-To: <4BAA43BD.4090505@softarmor.com> Date: Wed, 24 Mar 2010 13:12:27 -0400 Message-ID: <00e901cacb75$2e689b20$8b39d160$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrLcqncGcmGg1yDQICzaBfpNGSM9QAAkFrg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:12:12 -0000 IT certainly depends on whether the usage is in closed networks or the Open DNS but the determination of that IMHO is more governed by NRA considerations. In closed environments this is a very straight forward use case. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, March 24, 2010 12:54 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Regulatory advantage of "unused" While explaining his concerns yesterday, Jon mentioned that one of the worries about "unused" is that it might contribute to "site finder" activity. As I understand it, a "helpful" service provider might, after handling a query that returns "unused", decide to return to the user an alternate target, perhaps to a competitor or something. We see this behavior a lot when looking for web sites. The worry is that if the operator KNOWS the number is "unused" that they'll feel even more justified in returning something else. However, Ray noted in our followup discussion that "unused" also provides a regulatory point. Since this is real "carrier provisioned" data, local regulators could reasonably forbid altering it ala "site finder" and mandate that the "unused" record be returned to the querying node. This might well slant the discussion for "unused" towards having it standardized in the IETF. Opinions, please.... -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From jim@rfc1035.com Wed Mar 24 10:16:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0F23A6A75 for ; Wed, 24 Mar 2010 10:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5UVSClLTsLK for ; Wed, 24 Mar 2010 10:16:11 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 93AC83A6C36 for ; Wed, 24 Mar 2010 10:16:11 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 22036154208B; Wed, 24 Mar 2010 17:16:30 +0000 (GMT) Message-Id: From: Jim Reid To: Dean Willis In-Reply-To: <4BAA43BD.4090505@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 17:16:29 +0000 References: <4BAA43BD.4090505@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:16:12 -0000 On 24 Mar 2010, at 16:54, Dean Willis wrote: > The worry is that if the operator KNOWS the number is "unused" that > they'll feel even more justified in returning something else. Dean, I don't understand what point you're trying to make here. If an operator is minded to do Bad/Evil Things by making the DNS tell lies, they don't need the unused servicetype for that. The Sitefinder fiasco that you alluded to arose from improper use of wildcarding. No NAPTRs were harmed in that incident. And lots of ISPs are doing on-the-fly NXDOMAIN rewriting to redirect customers to a landing page: there was even an I-D about that. IMO it's the IETF's job to document good and bad practices here and then leave it up to regulators to figure out how to enforce good behaviour and punish those who misbehave. From dean.willis@softarmor.com Wed Mar 24 10:18:41 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079563A6D41 for ; Wed, 24 Mar 2010 10:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+kQdZhZoAkY for ; Wed, 24 Mar 2010 10:18:39 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9D5553A6D51 for ; Wed, 24 Mar 2010 10:17:45 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OHI4Ln024445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 12:18:05 -0500 Message-ID: <4BAA494B.5000004@softarmor.com> Date: Wed, 24 Mar 2010 12:18:03 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Lawrence Conroy References: <4BAA43BD.4090505@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:18:41 -0000 Lawrence Conroy wrote: > What are we going to do -- set the protocol police on such a wonky carrier that randomly re-directs calls? Well, the suggestion from Ray, as I understand it, is that "unused" actually makes it easier to set the protocol police (the national regulator) on the wonky carrier, because failing to return an existing "unused" record is far more evidently wonky than is returning a helpfully-synthesized response to a query that produced no result. So, it's one thing for a carrier to guess that you misdialed and helpfully point you in the right direction if your query got no result, and something else entirely for that same carrier to divert you when your target appears to be legitimate but "unused". Please check out the history: http://en.wikipedia.org/wiki/Site_Finder -- Dean From Ray.Bellis@nominet.org.uk Wed Mar 24 10:18:43 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358CA3A6D45 for ; Wed, 24 Mar 2010 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.507 X-Spam-Level: X-Spam-Status: No, score=-4.507 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNAYfq-a+zMS for ; Wed, 24 Mar 2010 10:18:41 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 931603A6D53 for ; Wed, 24 Mar 2010 10:17:46 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=RME/9x5M+UJ+LcHmT9ODiJL5ICaBRFFO2+5jojYC5djGjjgonx/n6pKq tj3wLgi2aKnZfOmZloC03m21Fvv3HWsq9Txsan3WAXkP/yzeqedA6Jgve rh512I6p5IrZ812; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269451087; x=1300987087; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Regulatory=20advantage=20of=20"unused"|Date:=20Wed, =2024=20Mar=202010=2009:18:04=20-0800|Message-ID:=20|To:=20Dean=20Willis=20|Cc:=20"E.164=20To=20MetaData=20BOF=20discussion=20l ist"=20|MIME-Version:=201.0|In-Reply-To: =20<4BAA43BD.4090505@softarmor.com>|References:=20<4BAA43 BD.4090505@softarmor.com>; bh=EIWmsRsJKF8Dstip4SnVWKj/5fjE1+qFNEUQIPBTc+U=; b=tckL2pIVldP+kB9F0DwFg2wbQhYpTMOhj81c7ExYlvH+D+6Jaa/W7C2Y VMuFTdiMoacPYpg3c2qiZYlaZ17Bg4FC1RnUp5GYPWZ/+peMoONJqdnwc Bg/AbLu5h0mu9En; X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="22853177" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 24 Mar 2010 17:18:06 +0000 In-Reply-To: <4BAA43BD.4090505@softarmor.com> References: <4BAA43BD.4090505@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 24 Mar 2010 09:18:04 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 24/03/2010 05:18:05 PM, Serialize complete at 24/03/2010 05:18:05 PM Content-Type: multipart/alternative; boundary="=_alternative 005F09E8882576F0_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:18:43 -0000 This is a multipart message in MIME format. --=_alternative 005F09E8882576F0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > However, Ray noted in our followup discussion that "unused" also > provides a regulatory point. Since this is real "carrier provisioned" > data, local regulators could reasonably forbid altering it ala "site > finder" and mandate that the "unused" record be returned to the querying > node. In any event, I simply can't see Jon's hypothetical misuse of "unused"=20 being permitted under any regulatory r=E9gime - OFCOM I'm sure would throw = a=20 complete wobbly if BT tried to trap all your NUs and redirect you to some=20 "helpful" DQ service instead. The likes of Sitefinder and other "wildcard" redirect services only exist=20 because there's no equivalent regulation in the internet. Ray --=_alternative 005F09E8882576F0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
> However, Ray noted in our followup discussion that "unused" also
> provides a regulatory point. Since this is real "carrier provisio= ned"
> data, local regulators could reasonably forbid altering it ala "s= ite
> finder" and mandate that the "unused" record be returned to the querying
> node.
In any event, I simply can't see Jon's hypothetical misuse of "unused" being permitted under any regulatory r=E9gime - OFCOM I'm sure would throw a complete wobbly if BT tried to trap all your NUs and redirect you to some "helpful" DQ service instead.

The likes of Sitefinder and other "wildcard&quo= t; redirect services only exist because there's no equivalent regulation in the internet.

Ray
--=_alternative 005F09E8882576F0_=-- From dean.willis@softarmor.com Wed Mar 24 10:24:23 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1A93A6D6A for ; Wed, 24 Mar 2010 10:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bruuBV3NPZ+a for ; Wed, 24 Mar 2010 10:24:22 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E01953A6D6D for ; Wed, 24 Mar 2010 10:23:09 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OHNRFl024502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 12:23:29 -0500 Message-ID: <4BAA4A8F.5090808@softarmor.com> Date: Wed, 24 Mar 2010 12:23:27 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Jim Reid References: <4BAA43BD.4090505@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:24:23 -0000 Jim Reid wrote: > > Dean, I don't understand what point you're trying to make here. It's Jon's and Ray's points I'm trying to relate. > If an > operator is minded to do Bad/Evil Things by making the DNS tell lies, > they don't need the unused servicetype for that. The Sitefinder fiasco > that you alluded to arose from improper use of wildcarding. No NAPTRs > were harmed in that incident. And lots of ISPs are doing on-the-fly > NXDOMAIN rewriting to redirect customers to a landing page: there was > even an I-D about that. In practice, Sitefinder type things don't really require a wildcard; instead they rely on a namerserver that synthesizes records on the fly when it doesn't find a real record to report. They're aren't really trying to be "evil", but to be helpful. The people running these things think of them as value-added services. The question is: are these name servers more likely to synthesize a potentially misleading result when a query returns "unused" or when it returns no records? Or does it make no difference at all in either case? > IMO it's the IETF's job to document good and bad practices here and then > leave it up to regulators to figure out how to enforce good behaviour > and punish those who misbehave. Giving the regulators an easy way to tell right from wrong might be helpful. -- dean From dean.willis@softarmor.com Wed Mar 24 10:25:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EBAD3A6D4C for ; Wed, 24 Mar 2010 10:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93FFa3SuWxVU for ; Wed, 24 Mar 2010 10:25:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7FDB03A6BB4 for ; Wed, 24 Mar 2010 10:25:31 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OHPna1024523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 12:25:51 -0500 Message-ID: <4BAA4B1D.5030303@softarmor.com> Date: Wed, 24 Mar 2010 12:25:49 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: <4BAA43BD.4090505@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:25:54 -0000 Ray.Bellis@nominet.org.uk wrote: > In any event, I simply can't see Jon's hypothetical misuse of "unused" > being permitted under any regulatory régime - OFCOM I'm sure would throw > a complete wobbly if BT tried to trap all your NUs and redirect you to > some "helpful" DQ service instead. I've stayed in any number of hotels where the local ISP redirected failed HTTP URLs towards "local interest" alternatives based in keyword matches. Do we want them doing this with phone numbers? -- Dean From HKaplan@acmepacket.com Wed Mar 24 10:31:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5606A3A69D9 for ; Wed, 24 Mar 2010 10:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sp22o9HiPxqk for ; Wed, 24 Mar 2010 10:31:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4EAD23A69B8 for ; Wed, 24 Mar 2010 10:31:32 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 24 Mar 2010 13:31:52 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 13:31:51 -0400 From: Hadriel Kaplan To: Jim Reid , Dean Willis Date: Wed, 24 Mar 2010 13:31:50 -0400 Thread-Topic: [e2md] Regulatory advantage of "unused" Thread-Index: AcrLdcJLZxbH6O0hQtqtRyzK7MR30AAAPYYQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1E1C@mail> References: <4BAA43BD.4090505@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:31:33 -0000 Not that I agree with him (I don't), but I think the concern is that if I p= ut in an unused entry for 12345 in the public DNS, then evil-provider *know= s* it can redirect it to advertisement, or a 411 service, or whatever. Bec= ause it knows the number hasn't been handed out (or no longer is) to a real= user. Whereas if there's no key/record at all, then all it knows is it's = not in that database, but may be a real number in the PSTN or whatever. Maybe. I dunno, I think it's a bogus concern as well. -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Jim Reid > Sent: Wednesday, March 24, 2010 1:16 PM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Regulatory advantage of "unused" >=20 > On 24 Mar 2010, at 16:54, Dean Willis wrote: >=20 > > The worry is that if the operator KNOWS the number is "unused" that >=20 > > they'll feel even more justified in returning something else. >=20 > Dean, I don't understand what point you're trying to make here. If an > operator is minded to do Bad/Evil Things by making the DNS tell lies, > they don't need the unused servicetype for that. The Sitefinder fiasco > that you alluded to arose from improper use of wildcarding. No NAPTRs > were harmed in that incident. And lots of ISPs are doing on-the-fly > NXDOMAIN rewriting to redirect customers to a landing page: there was > even an I-D about that. >=20 > IMO it's the IETF's job to document good and bad practices here and > then leave it up to regulators to figure out how to enforce good > behaviour and punish those who misbehave. > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Wed Mar 24 10:35:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E213A6B89 for ; Wed, 24 Mar 2010 10:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.906 X-Spam-Level: X-Spam-Status: No, score=0.906 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erdGznMUaiBo for ; Wed, 24 Mar 2010 10:35:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E448B3A684A for ; Wed, 24 Mar 2010 10:35:02 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OHZL44024657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Mar 2010 12:35:23 -0500 Message-ID: <4BAA4D59.5070006@softarmor.com> Date: Wed, 24 Mar 2010 12:35:21 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] what is E.164 metadata? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:35:03 -0000 We seem to have two conflicting definitions: 1) Metadata is any data about a phone number, when that data is not a URI used to establish a session with the phone number. 2) Metadata is data about the ENUM tree, such as hints as to how much further one might have to traverse the tree before reaching a leaf node, or that indicates a leaf node has been found and that no service pointers are associated with that node. This leads to the question: Is CNAM metadata, or something else? -- Dean From dean.willis@softarmor.com Wed Mar 24 10:39:08 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA4123A6C3F for ; Wed, 24 Mar 2010 10:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.824 X-Spam-Level: X-Spam-Status: No, score=0.824 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FESatrVJit9K for ; Wed, 24 Mar 2010 10:39:08 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6E3BF3A694D for ; Wed, 24 Mar 2010 10:39:06 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OHdOGV024704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Mar 2010 12:39:26 -0500 Message-ID: <4BAA4E4B.5010401@softarmor.com> Date: Wed, 24 Mar 2010 12:39:23 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" References: <4BAA43BD.4090505@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1E1C@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1E1C@mail> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:39:08 -0000 Hadriel Kaplan wrote: > Not that I agree with him (I don't), but I think the concern is that > if I put in an unused entry for 12345 in the public DNS, then > evil-provider *knows* it can redirect it to advertisement, or a 411 > service, or whatever. Because it knows the number hasn't been handed > out (or no longer is) to a real user. Whereas if there's no > key/record at all, then all it knows is it's not in that database, > but may be a real number in the PSTN or whatever. Yes, I think that's it. I should add: Hadriel was around for the talk with Jon too. But he conned me into sitting in the lumpy chair, so I forgot about him... -- Dean From pp3129@att.com Wed Mar 24 10:39:58 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894823A6BA3 for ; Wed, 24 Mar 2010 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.169 X-Spam-Level: X-Spam-Status: No, score=-104.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enUHhettj2w9 for ; Wed, 24 Mar 2010 10:39:55 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 6623C3A694D for ; Wed, 24 Mar 2010 10:39:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-2.tower-161.messagelabs.com!1269452413!19196639!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 26976 invoked from network); 24 Mar 2010 17:40:14 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Mar 2010 17:40:14 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2OHe241000470 for ; Wed, 24 Mar 2010 13:40:02 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2OHdtF2000357 for ; Wed, 24 Mar 2010 13:39:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 13:40:05 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B039FA159@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <4BAA4D59.5070006@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [e2md] what is E.164 metadata? Thread-Index: AcrLeGrl3WScK3gXRRSLCJxNRq9JHwAAIeag References: <4BAA4D59.5070006@softarmor.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "Dean Willis" , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] what is E.164 metadata? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:39:58 -0000 I'd say CNAM is metadata - the user data associated with number Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, March 24, 2010 1:35 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] what is E.164 metadata? We seem to have two conflicting definitions: 1) Metadata is any data about a phone number, when that data is not a URI used to establish a session with the phone number. 2) Metadata is data about the ENUM tree, such as hints as to how much further one might have to traverse the tree before reaching a leaf node, or that indicates a leaf node has been found and that no service pointers are associated with that node. This leads to the question: Is CNAM metadata, or something else? -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Wed Mar 24 10:58:52 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F36CF3A6AF3 for ; Wed, 24 Mar 2010 10:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXV+-0bRjJmo for ; Wed, 24 Mar 2010 10:58:51 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2FA233A6CCC for ; Wed, 24 Mar 2010 10:58:51 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OHx9Q5024899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Mar 2010 12:59:11 -0500 Message-ID: <4BAA52ED.3050808@softarmor.com> Date: Wed, 24 Mar 2010 12:59:09 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] revised open issues slides X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:58:52 -0000 I've touched up the open issues slides to focus the security discussion around access authentication and authorization instead of "on the wire" privacy. I also added a slide on the "Is NAPTR our only RR" question, proposing that the WG will study the question and respond appropriately. http://www.ietf.org/proceedings/10mar/slides/e2md-3.pdf -- dean From richard@shockey.us Wed Mar 24 11:10:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EC93A6DA8 for ; Wed, 24 Mar 2010 11:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.152 X-Spam-Level: * X-Spam-Status: No, score=1.152 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsRswnWyuHk0 for ; Wed, 24 Mar 2010 11:10:04 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 734AA3A6D69 for ; Wed, 24 Mar 2010 11:09:45 -0700 (PDT) Received: (qmail 13004 invoked by uid 0); 24 Mar 2010 18:10:05 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 24 Mar 2010 18:10:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=nX5tQM9avGebsmftiwcdiwb5mqYkAbFG56HUSoASSMi0Jf+11nMLy2s2xdD8tpFZ5agI2l2ZFwmqYFUvCH94GPfed+1PxiYBEoWHtB5AfiEnAmvRpA1oJAytYnTGRpXN; Received: from dhcp-wireless-open-abg-28-77.meeting.ietf.org ([130.129.28.77] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NuV1p-0006v4-HK; Wed, 24 Mar 2010 12:10:05 -0600 From: "Richard Shockey" To: , References: <4BA92A6B.2010309@softarmor.com><35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com><4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us><4BA96E3F.6010406@netmagic.com> <000601cacaf5$9b3c0280$d1b40780$@us> <4BA9743E.7080607@netmagic.com> <27882_1269449927_4BAA44C7_27882_7866_1_B2A6809D68602941A1341092939DFCE1D84FD7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <27882_1269449927_4BAA44C7_27882_7866_1_B2A6809D68602941A1341092939DFCE1D84FD7@ftrdmel0.rd.francetelecom.fr> Date: Wed, 24 Mar 2010 14:10:01 -0400 Message-ID: <012301cacb7d$396c4d70$ac44e850$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrK9wM1ep0tW2dsR5e7660cSWyF+AAdu3PgAAO3LNA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 130.129.28.77 authed with richard@shockey.us} Subject: Re: [e2md] We need another acronym besides SPID forservice provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:10:12 -0000 As I Mentioned to Tony earlier the sooner we have clarity from the ITU on this issue the better. This class of data is under VERY VERY active discussions in the IETF not just in E2MD but also in DRINKS where a discussion of how to provision this class of data was under active discussion this morning. IMHO there is very very strong interest in deploying some form of SPN. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of philippe.fouquart@orange-ftgroup.com Sent: Wednesday, March 24, 2010 12:59 PM To: e2md@ietf.org Subject: Re: [e2md] We need another acronym besides SPID forservice provider ID > The proposal had many significant flaws and received > no apparent support at the meeting. FWIW I don't think this is an accurate reflection of the SPN discussion that SG2/Q1 had at the last meeting. It was more a problem of people having different use cases in mind, so the participants were more comfortable working on requirements and use cases for such an identification scheme first, rather than defining assignment criteria point blank. Without prejudging the outcome of that discussion. Regards, Philippe Fouquart SG2/Q1 Ass. Rapporteur -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Wednesday, March 24, 2010 3:09 AM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] We need another acronym besides SPID forservice provider ID Hi Richard, > It's my understanding that SG2 has a separate task underway that Gary > Richenaker is leading on the Global SPID. The IETF DRINKS WG received > a formal liaison from ITU-T requesting that the DRINKS protocol > accommodate such as identifier. > Actually NeuStar made the proposal out of the blue. Gary as you know works for NeuStar. The proposal had many significant flaws and received no apparent support at the meeting (or anywhere else). Other ITU-T Study Groups had suggested that IETF Enterprise Numbers be used as they were the predominant SPID in use, but needed a better trust mechanism. A SG2 correspondence group was formed to further consider it, but thus far there has been no activity. I think you can consider the effort dead. --tony _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From trutkowski@netmagic.com Wed Mar 24 11:22:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B7E3A6C3B for ; Wed, 24 Mar 2010 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21TdHAnlrNju for ; Wed, 24 Mar 2010 11:22:28 -0700 (PDT) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by core3.amsl.com (Postfix) with ESMTP id AF1F23A6DA9 for ; Wed, 24 Mar 2010 11:22:25 -0700 (PDT) Received: from [192.168.0.173] ([unknown] [173.72.150.224]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KZS00D8OTPKSKJ1@vms173007.mailsrvcs.net> for e2md@ietf.org; Wed, 24 Mar 2010 13:22:33 -0500 (CDT) Message-id: <4BAA5868.7090204@netmagic.com> Date: Wed, 24 Mar 2010 14:22:32 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-version: 1.0 To: Richard Shockey References: <4BA92A6B.2010309@softarmor.com><35FE871E2B085542A35726420E29DA6B039F9E08@gaalpa1msgusr7a.ugd.att.com><4BA930A7.9080002@softarmor.com> <000c01cacaef$4ad66700$e0833500$@us><4BA96E3F.6010406@netmagic.com> <000601cacaf5$9b3c0280$d1b40780$@us> <4BA9743E.7080607@netmagic.com> <27882_1269449927_4BAA44C7_27882_7866_1_B2A6809D68602941A1341092939DFCE1D84FD7@ftrdmel0.rd.francetelecom.fr> <012301cacb7d$396c4d70$ac44e850$@us> In-reply-to: <012301cacb7d$396c4d70$ac44e850$@us> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] We need another acronym besides SPID forservice provider ID X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:22:29 -0000 On 3/24/2010 2:10 PM, Richard Shockey wrote: > discussion this morning. IMHO there is very very strong interest in > deploying some form of SPN. > Given the large number of VoIP, SNMP, PKI and other standards that use Enterprise IDs today - 40,000 of them worldwide - can't one argue it has been deployed?! It seems the industry and standards bodies have collectively decided this with their feet. What number do you have to reach to declare deployment? :-) Even if hypothetically some study group in ITU-T or or somewhere else decided on using some new SPN, how many years would that take, and who would use it? --tony From dean.willis@softarmor.com Wed Mar 24 11:24:16 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C283A6DBD for ; Wed, 24 Mar 2010 11:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqxOoW8vXczY for ; Wed, 24 Mar 2010 11:24:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 23F8C3A6C3B for ; Wed, 24 Mar 2010 11:24:02 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OIOJlj025234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Mar 2010 13:24:20 -0500 Message-ID: <4BAA58CD.1030402@softarmor.com> Date: Wed, 24 Mar 2010 13:24:13 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] Notes and Jabber Scribes for Today X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:24:16 -0000 Would anybody like to volunteer as a note taker or Jabber-room watcher-and-bringer-to-mic person for today's meeting? Please? -- Dean From jay@nzrs.net.nz Wed Mar 24 12:13:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284C63A697F for ; Wed, 24 Mar 2010 12:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDvMkgAqs0vs for ; Wed, 24 Mar 2010 12:13:23 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id D77E73A67FC for ; Wed, 24 Mar 2010 12:13:22 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 6DB302DB364; Thu, 25 Mar 2010 08:13:42 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omxFGPXIL7dy; Thu, 25 Mar 2010 08:13:42 +1300 (NZDT) Received: from [192.168.5.23] (koruout.airnz.co.nz [162.112.38.5]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 0257A2DB268; Thu, 25 Mar 2010 08:13:41 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <4BAA4A8F.5090808@softarmor.com> Date: Thu, 25 Mar 2010 08:13:41 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <8230D63C-FB2F-43BA-A8AA-2009C50B699B@nzrs.net.nz> References: <4BAA43BD.4090505@softarmor.com> <4BAA4A8F.5090808@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:13:24 -0000 Dean On 25/03/2010, at 6:23 AM, Dean Willis wrote: > Jim Reid wrote: >>=20 >> Dean, I don't understand what point you're trying to make here.=20 >=20 > It's Jon's and Ray's points I'm trying to relate. >=20 >> If an >> operator is minded to do Bad/Evil Things by making the DNS tell lies, >> they don't need the unused servicetype for that. The Sitefinder = fiasco >> that you alluded to arose from improper use of wildcarding. No NAPTRs >> were harmed in that incident. And lots of ISPs are doing on-the-fly >> NXDOMAIN rewriting to redirect customers to a landing page: there was >> even an I-D about that. >=20 > In practice, Sitefinder type things don't really require a wildcard; > instead they rely on a namerserver that synthesizes records on the fly > when it doesn't find a real record to report. They're aren't really > trying to be "evil", but to be helpful. The people running these = things > think of them as value-added services. >=20 > The question is: are these name servers more likely to synthesize a > potentially misleading result when a query returns "unused" or when it > returns no records? Or does it make no difference at all in either = case? This is complete FUD. There is no problem here, move on. Jay >=20 >=20 >> IMO it's the IETF's job to document good and bad practices here and = then >> leave it up to regulators to figure out how to enforce good behaviour >> and punish those who misbehave. >=20 > Giving the regulators an easy way to tell right from wrong might be = helpful. >=20 > -- > dean >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From jim@rfc1035.com Wed Mar 24 12:30:58 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33ECA3A6C4F for ; Wed, 24 Mar 2010 12:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.991 X-Spam-Level: X-Spam-Status: No, score=0.991 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDecT+i-X4zB for ; Wed, 24 Mar 2010 12:30:57 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id A58023A6C2B for ; Wed, 24 Mar 2010 12:30:56 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 817A3154208B; Wed, 24 Mar 2010 19:31:15 +0000 (GMT) Message-Id: <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BAA4248.2050601@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 19:31:15 +0000 References: <4BAA4248.2050601@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:30:58 -0000 On 24 Mar 2010, at 16:48, Dean Willis wrote: > Putting it in a NAPTR record is also pointless: not only is NAPTR a > clumsy format for calling-names, one generally does NOT want or need > the > CNAM to come back in the other cases where one might query for all > NAPTR > records associated with a given E.164, so having it in a NAPTR simply > creates extra network traffic and processor load while achieving no > benefit. Maybe, maybe not. If the application is going to do a NAPTR lookup, the response might as well include a CNAM NAPTR (if such a beast exists). The network overhead of an additional RR and the extra CPU cycles to chomp through a list of N+1 instead of N NAPTRs is unlikely to matter. This would certainly be cheaper than having to make a second DNS query for some other RRtype. > Consequently, one approach for CNAM would be to define another > resource > record type that would fit the problem space better. Maybe. Getting a CNAM RRtype would be a whole lot less painful than getting CNAM as a NAPTR subtype/URI. From jim@rfc1035.com Wed Mar 24 12:56:05 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67953A6B7C for ; Wed, 24 Mar 2010 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NimQ2Y1mbCTU for ; Wed, 24 Mar 2010 12:56:05 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id C4E0D3A6358 for ; Wed, 24 Mar 2010 12:56:04 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 0A2DE154208B; Wed, 24 Mar 2010 19:56:24 +0000 (GMT) Message-Id: <0E22982D-613B-4A03-8B8A-790A6D579DF8@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BAA4A8F.5090808@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 19:56:23 +0000 References: <4BAA43BD.4090505@softarmor.com> <4BAA4A8F.5090808@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Regulatory advantage of "unused" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:56:05 -0000 On 24 Mar 2010, at 17:23, Dean Willis wrote: > It's Jon's and Ray's points I'm trying to relate. It doesn't matter whose points you're channelling Dean. I still don't understand them or why they might be relevant. Just about anything on the interweb can be used for Bad Things, so why the unused/void servicetype gets singled out in this way is beyond me. I don't hear the Protocol Police cracking down on SMTP or SIP (to randomly pick two protocols) because they can be exploited by naughty people for unpleasant things. > Giving the regulators an easy way to tell right from wrong might be > helpful. I agree. A "DNS redirection considered harmful" RFC would be a useful part of that advice. From dean.willis@softarmor.com Wed Mar 24 13:18:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F143A6A5C for ; Wed, 24 Mar 2010 13:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnx-BecKZlTm for ; Wed, 24 Mar 2010 13:18:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 96CC13A6891 for ; Wed, 24 Mar 2010 13:18:17 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OKIZB1026265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 15:18:37 -0500 Message-ID: <4BAA739B.2000609@softarmor.com> Date: Wed, 24 Mar 2010 15:18:35 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Jim Reid References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com> In-Reply-To: <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:18:19 -0000 Jim Reid wrote: > On 24 Mar 2010, at 16:48, Dean Willis wrote: > >> Putting it in a NAPTR record is also pointless: not only is NAPTR a >> clumsy format for calling-names, one generally does NOT want or need the >> CNAM to come back in the other cases where one might query for all NAPTR >> records associated with a given E.164, so having it in a NAPTR simply >> creates extra network traffic and processor load while achieving no >> benefit. > > Maybe, maybe not. If the application is going to do a NAPTR lookup, the > response might as well include a CNAM NAPTR (if such a beast exists). > The network overhead of an additional RR and the extra CPU cycles to > chomp through a list of N+1 instead of N NAPTRs is unlikely to matter. > This would certainly be cheaper than having to make a second DNS query > for some other RRtype. True, if doing a NAPTR dio, the extra overhead of getting back CNAM is pretty small. But the "called" party isn't likely to a NATR lookup for anything but the CNAM, and if we put CNAM in NAPTR, it's going to get the whole set of records back, most (all but CNAM?) of which it does not need. > >> Consequently, one approach for CNAM would be to define another resource >> record type that would fit the problem space better. > > Maybe. Getting a CNAM RRtype would be a whole lot less painful than > getting CNAM as a NAPTR subtype/URI. > What are the deployment implications? How hard is it to access a new RR with most of the current libraries? What about impacts on name servers and DNS proxies? -- Dean From dean.willis@softarmor.com Wed Mar 24 13:27:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369283A6C2C for ; Wed, 24 Mar 2010 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.814 X-Spam-Level: X-Spam-Status: No, score=0.814 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaFdD14A0seK for ; Wed, 24 Mar 2010 13:27:53 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E3C833A6C3D for ; Wed, 24 Mar 2010 13:27:52 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OKSBVH026362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 24 Mar 2010 15:28:13 -0500 Message-ID: <4BAA75DA.20708@softarmor.com> Date: Wed, 24 Mar 2010 15:28:10 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] Another alt for CNAM: SRV style "_CNAM_" X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:27:54 -0000 I had lunch with Hadriel, Bob Penfield, and Jonathan Lennox. We were discussing query models for CNAM and its interaction with NAPTR, and Bob made a suggestion that I thought worth sharing. SRV records use the service type as an element of the name, so that one can be very selective about queries for services. How about something like: _CNAM_.0.9.1.9.9.1.5.2.7.9.1.e164.arpa pointing to some type of RR for the calling name? This has the advantage of specialist RR for returning "just what is wanted", but lets us reuse an existing RR, maybe even a NAPTR. Or a TXT ;-). Keep in mind that CNAM queries against a phone prefix seem to be meaningless; one really needs a terminal ENUM name before one asks for a CNAM lookup. -- Dean From jim@rfc1035.com Wed Mar 24 13:35:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB813A6D88 for ; Wed, 24 Mar 2010 13:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phUH8SnhTOfi for ; Wed, 24 Mar 2010 13:35:29 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 60E8A3A6D81 for ; Wed, 24 Mar 2010 13:35:21 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 4A5AC154208B; Wed, 24 Mar 2010 20:35:40 +0000 (GMT) Message-Id: From: Jim Reid To: Dean Willis In-Reply-To: <4BAA739B.2000609@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 20:35:39 +0000 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com> <4BAA739B.2000609@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] impact of a new RRtype X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:35:30 -0000 On 24 Mar 2010, at 20:18, Dean Willis wrote: >> Maybe. Getting a CNAM RRtype would be a whole lot less painful than >> getting CNAM as a NAPTR subtype/URI. > > What are the deployment implications? Define deployment. Is this something that goes on behind closed doors amongst consenting adults or is it something will or could be visible on the public internet? > How hard is it to access a new RR with most of the current libraries? How long is a piece of string? Presumably the only libraries that need to know about this new RRtype will be those that are used specifically for looking it up. The rest should support RFC3597 (unknown RRtypes) and just do the Right Thing: treat the RDATA as an opaque blob of data and leave it alone. There will of course be libraries and servers who don't support RFC3597. I'm not sure if these matter or not for this particular case. > What about impacts on name servers and DNS proxies? Depends. Decent implementations will support RFC3597. Stupid ones won't. Proxies, firewalls and middleware may well barf on RRtypes they don't understand. They will no doubt barf on anything other than A, CNAME, MX and NS record lookups. From jay@nzrs.net.nz Wed Mar 24 13:37:07 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA3C3A6BAF for ; Wed, 24 Mar 2010 13:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1wZ-+jUxtcB for ; Wed, 24 Mar 2010 13:37:07 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 2D57E3A6D6C for ; Wed, 24 Mar 2010 13:36:49 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id C17A42DB62C; Thu, 25 Mar 2010 09:37:08 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plKSd25sBpdN; Thu, 25 Mar 2010 09:37:08 +1300 (NZDT) Received: from [192.168.5.23] (koruout.airnz.co.nz [162.112.38.5]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 3A0162DB175; Thu, 25 Mar 2010 09:37:08 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-121--901950428 From: Jay Daley In-Reply-To: <4BAA4D59.5070006@softarmor.com> Date: Thu, 25 Mar 2010 09:37:05 +1300 Message-Id: <6D65F240-3533-4B3B-8A89-AA2616EAF67B@nzrs.net.nz> References: <4BAA4D59.5070006@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] what is E.164 metadata? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:37:07 -0000 --Apple-Mail-121--901950428 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Are being deliberately awkward? On 25/03/2010, at 6:35 AM, Dean Willis wrote: > We seem to have two conflicting definitions: No we don't. We have multiple uses for metadata >=20 > 1) Metadata is any data about a phone number, when that data is not a > URI used to establish a session with the phone number. That does not exclude CNAM in any way shape or form. Any connection = requires decisions made by both parties - who to connect to and whether = to accept the connection. CNAM comes into the latter, but I can see = various hypothetical other metadata that would also come into the latter - an indicator that the calling number is used by automated systems not = people - a signature from an agency that guarantees the originator is not a = marketing caller. Jay >=20 >=20 > 2) Metadata is data about the ENUM tree, such as hints as to how much > further one might have to traverse the tree before reaching a leaf = node, > or that indicates a leaf node has been found and that no service > pointers are associated with that node. >=20 >=20 > This leads to the question: Is CNAM metadata, or something else? >=20 > -- > Dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 --Apple-Mail-121--901950428 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
We = seem to have two conflicting = definitions:

No we don't. =  We have multiple uses for metadata


1) Metadata is any data about a phone number, = when that data is not a
URI used to establish a session with the = phone number.

That does not = exclude CNAM in any way shape or form.  Any connection requires = decisions made by both parties - who to connect to and whether to accept = the connection.  CNAM comes into the latter, but I can see various = hypothetical other metadata that would also come into the = latter
- an indicator that the calling number is used by = automated systems not people
- a signature from an agency that = guarantees the originator is not a marketing = caller.

Jay



2) Metadata is data about the ENUM = tree, such as hints as to how much
further one might have to traverse = the tree before reaching a leaf node,
or that indicates a leaf node = has been found and that no service
pointers are associated with that = node.


This leads to the question: Is CNAM metadata, or = something = else?

--
Dean
_______________________________________________=
e2md mailing list
e2md@ietf.org
https://www.ietf.org/m= ailman/listinfo/e2md


-- 
Jay = Daley
Chief Executive
.nz Registry Services (New = Zealand Domain Name Registry Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840

= --Apple-Mail-121--901950428-- From Ray.Bellis@nominet.org.uk Wed Mar 24 13:42:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530853A6D30 for ; Wed, 24 Mar 2010 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.176 X-Spam-Level: X-Spam-Status: No, score=-5.176 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOsmb+7Qq3wA for ; Wed, 24 Mar 2010 13:42:54 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 389FB3A69EB for ; Wed, 24 Mar 2010 13:42:54 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=AkK36Eu0ZKamxfQlijGSBwIk89RfQ9TgCLX4oeWEPqiaUvBuFaqMizor yS2Egz7TQcIAnQV26r355KD5J2LIF8tid6q0o50Sc3tdKcQDjcLxWk7kY ptCLapUWWW6dM3i; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269463395; x=1300999395; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20impact=20of=20a=20new=20RRtype|Date:=20Wed,=2024=20Ma r=202010=2012:43:13=20-0800|Message-ID:=20|To:=20Jim=20Reid=20|Cc:=20"E.164=20To =20MetaData=20BOF=20discussion=20list"=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20<4BAA4248.205 0601@softarmor.com>=09<02098184-D7B9-4CFB-B522-B3F16D8EF6 C2@rfc1035.com>=0D=0A=09<4BAA739B.2000609@softarmor.com> =20; bh=0oLBgYVn/BKhswh2zqxf62Jyf2guOhvwsERxLtmEPiU=; b=HttpsD1l10qx6ou/NdLN8/EeyFN8Y9ApvWw5+IktG5xd9f3viYmwA7uw GIRSeGg8EHADecOaDJEZZNyFFBN5xDZawYQ/LDVW7cAxTVVNmDhy0M/oT rdWvzYN7g9DZPyf; X-IronPort-AV: E=Sophos;i="4.51,302,1267401600"; d="scan'208";a="17319907" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 24 Mar 2010 20:43:14 +0000 In-Reply-To: References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com> <4BAA739B.2000609@softarmor.com> To: Jim Reid MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 24 Mar 2010 12:43:13 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 24/03/2010 08:43:14 PM, Serialize complete at 24/03/2010 08:43:14 PM Content-Type: multipart/alternative; boundary="=_alternative 0071D1E4882576F0_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] impact of a new RRtype X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:42:55 -0000 This is a multipart message in MIME format. --=_alternative 0071D1E4882576F0_= Content-Type: text/plain; charset="US-ASCII" > Proxies, firewalls and middleware may well barf on RRtypes they > don't understand. They will no doubt barf on anything other than A, > CNAME, MX and NS record lookups. That assertion isn't actually backed up by my own research into DNS proxies - we didn't find any issues with unknown RRtypes at all. Ray --=_alternative 0071D1E4882576F0_= Content-Type: text/html; charset="US-ASCII"
> Proxies, firewalls and middleware may well barf on RRtypes they  
> don't understand. They will no doubt barf on anything other than A,  
> CNAME, MX and NS record lookups.
That assertion isn't actually backed up by my own research into DNS proxies - we didn't find any issues with unknown RRtypes at all.

Ray
--=_alternative 0071D1E4882576F0_=-- From dean.willis@softarmor.com Wed Mar 24 13:44:43 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA683A69EB for ; Wed, 24 Mar 2010 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.825 X-Spam-Level: X-Spam-Status: No, score=0.825 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV-XP0h3I3ic for ; Wed, 24 Mar 2010 13:44:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 595E13A6D84 for ; Wed, 24 Mar 2010 13:44:36 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OKismq026548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 15:44:56 -0500 Message-ID: <4BAA79C5.7050408@softarmor.com> Date: Wed, 24 Mar 2010 15:44:53 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Jay Daley References: <4BAA4D59.5070006@softarmor.com> <6D65F240-3533-4B3B-8A89-AA2616EAF67B@nzrs.net.nz> In-Reply-To: <6D65F240-3533-4B3B-8A89-AA2616EAF67B@nzrs.net.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] what is E.164 metadata? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:44:43 -0000 Jay Daley wrote: >> 1) Metadata is any data about a phone number, when that data is not a >> URI used to establish a session with the phone number. > > That does not exclude CNAM in any way shape or form. Any connection > requires decisions made by both parties - who to connect to and whether > to accept the connection. CNAM comes into the latter, but I can see > various hypothetical other metadata that would also come into the latter > - an indicator that the calling number is used by automated systems not > people > - a signature from an agency that guarantees the originator is not a > marketing caller. Yes, def 1 includes CNAM as metadata. Def 2 doesn't. How about CPC and OLI? Are those things metadata that is of interest to the called party and not the calling party? -- Dean From dean.willis@softarmor.com Wed Mar 24 13:49:39 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9AB3A6DC9 for ; Wed, 24 Mar 2010 13:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAumUt90M32d for ; Wed, 24 Mar 2010 13:49:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5346E3A6DC7 for ; Wed, 24 Mar 2010 13:49:38 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OKnuLF026587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 15:49:58 -0500 Message-ID: <4BAA7AEF.9080807@softarmor.com> Date: Wed, 24 Mar 2010 15:49:51 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Ray.Bellis@nominet.org.uk References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com> <4BAA739B.2000609@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] impact of a new RRtype X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 20:49:39 -0000 Ray.Bellis@nominet.org.uk wrote: > >> Proxies, firewalls and middleware may well barf on RRtypes they >> don't understand. They will no doubt barf on anything other than A, >> CNAME, MX and NS record lookups. > > That assertion isn't actually backed up by my own research into DNS > proxies - we didn't find any issues with unknown RRtypes at all. I know my own proxies will also pass at least TXT and PTR, and AFAIK, the Linksys devices up to last year (have no knowledge of newer ones) were open to unknown RRs. But right offhand, I don't know how to write an app that queries for a new RR. Of course, I still use gethostbyname()... -- dean From kcartwright@tnsi.com Wed Mar 24 14:20:21 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2243A6DE4 for ; Wed, 24 Mar 2010 14:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrXnQiAJqP3Y for ; Wed, 24 Mar 2010 14:20:20 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 208183A6BE0 for ; Wed, 24 Mar 2010 14:20:20 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41782927; Wed, 24 Mar 2010 17:20:32 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 24 Mar 2010 17:20:32 -0400 From: "Cartwright, Kenneth" To: Dean Willis , Jim Reid Date: Wed, 24 Mar 2010 17:20:32 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrLjzkLg5vzRi89SvK6qQWNd9B6ugAB0VK5 Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> In-Reply-To: <4BAA739B.2000609@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:20:21 -0000 As is the case with the SS7 networks, which use a TCAP message to lookup th= e CNAM, CNAM ENUM queries to lookup CNAM data are not sent to the same ENUM= server that are used to lookup the other NAPTRs that are stored in ENUM, i= f any. This is because "usually" carriers are charged per dip into the CNA= M data. So comingling it with other data that would result in CNAM data be= ing returned in cases where it is not needed is something that is not usual= ly done. So this email chain seems to be mostly a red herring. As with several of t= he other email chains about E2MD and its potential use cases which make err= oneous assumptions about where E2MD data will/does live, exactly who will a= nd who will be able to query it, and under what circumstances they will que= ry it. Today, in production, CNAM data is already being looked up using TCAP, ENUM= , and SIP. The goal here is to get the structure of the ENUM response that= contains the ENUM data oficcially standardized. Ken ________________________________________ From: e2md-bounces@ietf.org [e2md-bounces@ietf.org] On Behalf Of Dean Willi= s [dean.willis@softarmor.com] Sent: Wednesday, March 24, 2010 4:18 PM To: Jim Reid Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] alt structure suggested for CNAM Jim Reid wrote: > On 24 Mar 2010, at 16:48, Dean Willis wrote: > >> Putting it in a NAPTR record is also pointless: not only is NAPTR a >> clumsy format for calling-names, one generally does NOT want or need the >> CNAM to come back in the other cases where one might query for all NAPTR >> records associated with a given E.164, so having it in a NAPTR simply >> creates extra network traffic and processor load while achieving no >> benefit. > > Maybe, maybe not. If the application is going to do a NAPTR lookup, the > response might as well include a CNAM NAPTR (if such a beast exists). > The network overhead of an additional RR and the extra CPU cycles to > chomp through a list of N+1 instead of N NAPTRs is unlikely to matter. > This would certainly be cheaper than having to make a second DNS query > for some other RRtype. True, if doing a NAPTR dio, the extra overhead of getting back CNAM is pretty small. But the "called" party isn't likely to a NATR lookup for anything but the CNAM, and if we put CNAM in NAPTR, it's going to get the whole set of records back, most (all but CNAM?) of which it does not need. > >> Consequently, one approach for CNAM would be to define another resource >> record type that would fit the problem space better. > > Maybe. Getting a CNAM RRtype would be a whole lot less painful than > getting CNAM as a NAPTR subtype/URI. > What are the deployment implications? How hard is it to access a new RR with most of the current libraries? What about impacts on name servers and DNS proxies? -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jim@rfc1035.com Wed Mar 24 14:21:46 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EADB13A6BE0 for ; Wed, 24 Mar 2010 14:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tArS8P5UFabC for ; Wed, 24 Mar 2010 14:21:45 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id E495A3A6D1C for ; Wed, 24 Mar 2010 14:21:44 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id B0371154208B; Wed, 24 Mar 2010 21:22:03 +0000 (GMT) Message-Id: From: Jim Reid To: Dean Willis In-Reply-To: <4BAA7AEF.9080807@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 21:22:03 +0000 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com> <4BAA739B.2000609@softarmor.com> <4BAA7AEF.9080807@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: [e2md] coding for DNS queries X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:21:46 -0000 On 24 Mar 2010, at 20:49, Dean Willis wrote: > Of course, I still use gethostbyname()... Real programmers (TM) use res_mkquery() and friends... :-) gethostbyname() doesn't always use the DNS. From pkyzivat@cisco.com Wed Mar 24 14:25:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33CF3A6A7C for ; Wed, 24 Mar 2010 14:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.475 X-Spam-Level: X-Spam-Status: No, score=-5.475 tagged_above=-999 required=5 tests=[AWL=2.505, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMVUW2+Goi4R for ; Wed, 24 Mar 2010 14:25:42 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DF68E3A67E4 for ; Wed, 24 Mar 2010 14:25:42 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAogqkurRN+K/2dsb2JhbACbG3OnR5kPhH4E X-IronPort-AV: E=Sophos;i="4.51,303,1267401600"; d="scan'208";a="311414469" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2010 21:26:04 +0000 Received: from [10.21.124.241] (sjc-vpn6-1265.cisco.com [10.21.124.241]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2OLQ3Bw023840; Wed, 24 Mar 2010 21:26:03 GMT Message-ID: <4BAA836A.2050502@cisco.com> Date: Wed, 24 Mar 2010 17:26:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <4BAA4D59.5070006@softarmor.com> <6D65F240-3533-4B3B-8A89-AA2616EAF67B@nzrs.net.nz> <4BAA79C5.7050408@softarmor.com> In-Reply-To: <4BAA79C5.7050408@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] what is E.164 metadata? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:25:44 -0000 Dean Willis wrote: > How about CPC and OLI? Are those things metadata that is of interest to > the called party and not the calling party? I don't know what the expectations are here. Based on the investigation I did of defined values for these things referenced in the uui stuff, there are some that are pertinent to the calling user, some to the called user, and some that are dynamic properties of a call, not of either the caller or callee. So I imagine *some* might be metadata of phone numbers. For instance determining the caller is from a prison is analogous to getting cnam data. OTOH, most of those things have to do with AoRs or devices, regardless of whether they are associated with phone numbers or not. So mechanisms that only work for phone numbers may be dubious. Thanks, Paul From HKaplan@acmepacket.com Wed Mar 24 14:43:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DEB3A69F2 for ; Wed, 24 Mar 2010 14:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.848 X-Spam-Level: X-Spam-Status: No, score=0.848 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64pqUhMYmH3J for ; Wed, 24 Mar 2010 14:43:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A2F2B3A69EB for ; Wed, 24 Mar 2010 14:43:53 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 24 Mar 2010 17:44:13 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 17:44:13 -0400 From: Hadriel Kaplan To: "Cartwright, Kenneth" , Dean Willis , Jim Reid Date: Wed, 24 Mar 2010 17:44:12 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrLjzkLg5vzRi89SvK6qQWNd9B6ugAB0VK5AADBRBA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:43:54 -0000 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Cartwright, Kenneth > Sent: Wednesday, March 24, 2010 5:21 PM >=20 > As is the case with the SS7 networks, which use a TCAP message to lookup > the CNAM, CNAM ENUM queries to lookup CNAM data are not sent to the same > ENUM server that are used to lookup the other NAPTRs that are stored in > ENUM, if any. This is because "usually" carriers are charged per dip int= o > the CNAM data. So comingling it with other data that would result in CNA= M > data being returned in cases where it is not needed is something that is > not usually done. Yes you're right of course, but I think to get this standardized here we'll= need to consider (or accommodate) a model where it's: 1) in public DNS 2) in a single DNS server along with any/all other NAPTRs for the same num= ber Don't get me wrong though - I would *rather* just use draft-ietf-enum-cnam-= 08.txt as is without any changes. I think our choices are: 1) Use a new DNS service (e.g., "E2CNAM") 2) Use a new type in a new framework (e.g., "E2MD+cnam") 3) Use a new RR type, not NAPTR (e.g., "CNAMR") 4) Define a specific root (e.g., "5.5.5.1.cnam.e164.arpa") 5) Define a specific query key extension (e.g., "_cnam.5.5.5.1.e164.arpa") Personally I like #5 of the choices. -hadriel From dean.willis@softarmor.com Wed Mar 24 14:48:45 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01C763A69EB for ; Wed, 24 Mar 2010 14:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2igakdLNvBj for ; Wed, 24 Mar 2010 14:48:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3A1C53A685A for ; Wed, 24 Mar 2010 14:48:44 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2OLn3kf027321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 16:49:04 -0500 Message-ID: <4BAA88CE.3030904@softarmor.com> Date: Wed, 24 Mar 2010 16:49:02 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:48:45 -0000 Cartwright, Kenneth wrote: > As is the case with the SS7 networks, which use a TCAP message to > lookup the CNAM, CNAM ENUM queries to lookup CNAM data are not sent > to the same ENUM server that are used to lookup the other NAPTRs that > are stored in ENUM, if any. This is because "usually" carriers are > charged per dip into the CNAM data. So comingling it with other data > that would result in CNAM data being returned in cases where it is > not needed is something that is not usually done. Hold on a sec: You're telling me that I should select which NAPTR records come back by picking different DNS roots (via different servers, as access points into different DNS splits)for different queries, and the question of "how do I know which root to query" is entirely settled by provisioning? In other words, if I want E2M+CNAM I might query server X, and for E2M+UNUSED I might query server Y, and I just have to know in advance which server to query? -- Dean From Ray.Bellis@nominet.org.uk Wed Mar 24 14:53:07 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7B93A69EB for ; Wed, 24 Mar 2010 14:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.212 X-Spam-Level: X-Spam-Status: No, score=-5.212 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEiF2TZqKLS0 for ; Wed, 24 Mar 2010 14:53:06 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id C84FE3A6B96 for ; Wed, 24 Mar 2010 14:53:05 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=4mWBT3hq0yI5V1AJvRHWiX8Xma9IAmj5IbCeYpmh2Xc8M65Mh468fvK0 yGKmm72FxQJUC1sDdRBJF3XhYVn2+iMHU+N8rzNeJtyq+ARIuo8Rk/7Tf 6XgXhUk0tBnTOWD; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269467607; x=1301003607; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20alt=20structure=20suggested=20for=20CNAM|Date:=20Wed, =2024=20Mar=202010=2013:53:25=20-0800|Message-ID:=20|To:=20Hadriel=20Kaplan=20|Cc:=20"E.164=20To=20MetaData=20BOF=20discussion=20l ist"=20|MIME-Version:=201.0|In-Reply-To: =20<430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> |References:=20<4BAA4248.2050601@softarmor.com>=09<020981 84-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>,=0D=0A=09<4BA A739B.2000609@softarmor.com>=09<754963199212404AB8E9CFCA6 C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com>=20<430 FC6BDED356B4C8498F634416644A91A79CD1EBD@mail>; bh=CWkuz6vvn77KP2MEHmzFIhNRzKyiwbFy8S1xXkckyZA=; b=E6tAWT3GB8olfkS2kcO9fDfcXhpRRDkmJ16PJtX5ms+/RcROtJnez/SK VyQux6iUR89poAqD4vQZGmHxoWZ59KzX9cpcIQNr0Hw7jHKsYRk6ZL94N dQnarbTfGekYtf6; X-IronPort-AV: E=Sophos;i="4.51,303,1267401600"; d="scan'208";a="22857234" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 24 Mar 2010 21:53:25 +0000 In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 24 Mar 2010 13:53:25 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 24/03/2010 09:53:25 PM, Serialize complete at 24/03/2010 09:53:25 PM Content-Type: multipart/alternative; boundary="=_alternative 00783ED2882576F0_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:53:07 -0000 This is a multipart message in MIME format. --=_alternative 00783ED2882576F0_= Content-Type: text/plain; charset="US-ASCII" > I think our choices are: > 1) Use a new DNS service (e.g., "E2CNAM") > 2) Use a new type in a new framework (e.g., "E2MD+cnam") > 3) Use a new RR type, not NAPTR (e.g., "CNAMR") > 4) Define a specific root (e.g., "5.5.5.1.cnam.e164.arpa") > 5) Define a specific query key extension (e.g., "_cnam.5.5.5.1.e164.arpa") You missed one: 6) use E2U+cnam, as defined in the current draft. > Personally I like #5 of the choices. FWIW, my preference (in decreasing order) for CNAM in particular would be: 2 - E2M as originally envisioned (before the layer 9+ crap got in the way) 6 - leave the draft as is 3 - OK, but only if the CNAM query is standalone and independent of other NAPTRs 1 - too heavy in spec requirements, IMHO 5 - requires additional lookups 4 - requires a whole new tree, bleugh For unused and send-n some of this doesn't apply, but #4 and #5 really need to be off the table ASAP. Ray --=_alternative 00783ED2882576F0_= Content-Type: text/html; charset="US-ASCII"
> I think our choices are:
>    1) Use a new DNS service (e.g., "E2CNAM")
>    2) Use a new type in a new framework (e.g., "E2MD+cnam")
>    3) Use a new RR type, not NAPTR (e.g., "CNAMR")
>    4) Define a specific root (e.g., "5.5.5.1.cnam.e164.arpa")
>    5) Define a specific query key extension (e.g., "_cnam.5.5.5.1.e164.arpa")

You missed one:

     6) use E2U+cnam, as defined in the current draft.

> Personally I like #5 of the choices.
FWIW, my preference (in decreasing order) for CNAM in particular would be:

  2 - E2M as originally envisioned (before the layer 9+ crap got in the way)
  6 - leave the draft as is
  3 - OK, but only if the CNAM query is standalone and independent of other NAPTRs
  1 - too heavy in spec requirements, IMHO
  5 - requires additional lookups
  4 - requires a whole new tree, bleugh

For unused and send-n some of this doesn't apply, but #4 and #5 really need to be off the table ASAP.

Ray

--=_alternative 00783ED2882576F0_=-- From mmaharishi@tnsi.com Wed Mar 24 15:00:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0103A6BD6 for ; Wed, 24 Mar 2010 15:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.545 X-Spam-Level: * X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9Yjgusyb4id for ; Wed, 24 Mar 2010 15:00:54 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 845E13A69F2 for ; Wed, 24 Mar 2010 15:00:54 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41783750; Wed, 24 Mar 2010 18:01:07 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 24 Mar 2010 18:01:07 -0400 From: "Maharishi, Manjul" To: Dean Willis , "Cartwright, Kenneth" Date: Wed, 24 Mar 2010 18:01:05 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrLm9XlW5CxBcmGScSTCHHYVnl8BQAAQZTA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6911E603@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> In-Reply-To: <4BAA88CE.3030904@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:00:55 -0000 Yes, indeed - the same registry (or dns root) may or may not hold *all* pos= sible pieces of data. However, a registry provider may offer a service wher= e it does all of this in the background for you and returns the required in= formation back. On the question of "requiring" multiple dips to get different pieces of inf= ormation - e.g.: portability info, service provider/authoritative carrier/S= PID info, and CNAM info - there are different use cases and possibly differ= ent points-in-call for each of these, and as there are financial terms invo= lved - the originator of the query will most likely have to pay for these s= ervices. Accordingly, the originator of a call may not want to pay for CNAM= dip - that is presently done by the terminating entity. Manjul -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dea= n Willis Sent: Wednesday, March 24, 2010 5:49 PM To: Cartwright, Kenneth Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] alt structure suggested for CNAM Cartwright, Kenneth wrote: > As is the case with the SS7 networks, which use a TCAP message to > lookup the CNAM, CNAM ENUM queries to lookup CNAM data are not sent to > the same ENUM server that are used to lookup the other NAPTRs that are > stored in ENUM, if any. This is because "usually" carriers are > charged per dip into the CNAM data. So comingling it with other data > that would result in CNAM data being returned in cases where it is not > needed is something that is not usually done. Hold on a sec: You're telling me that I should select which NAPTR records come back by pic= king different DNS roots (via different servers, as access points into diff= erent DNS splits)for different queries, and the question of "how do I know = which root to query" is entirely settled by provisioning? In other words, if I want E2M+CNAM I might query server X, and for E2M+UNUSED I might query server Y, and I just have to know in advance which server to query? -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From HKaplan@acmepacket.com Wed Mar 24 15:01:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1713A6BD6 for ; Wed, 24 Mar 2010 15:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.166 X-Spam-Level: * X-Spam-Status: No, score=1.166 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIt7SaT-cTWY for ; Wed, 24 Mar 2010 15:01:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0AD073A6C7B for ; Wed, 24 Mar 2010 15:01:07 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 24 Mar 2010 18:01:27 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 18:01:27 -0400 From: Hadriel Kaplan To: Dean Willis , "Cartwright, Kenneth" Date: Wed, 24 Mar 2010 18:01:26 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrLm95b8jmuLQUbRA2LUUFy+yD8JgAAGs+g Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> In-Reply-To: <4BAA88CE.3030904@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:01:12 -0000 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Wednesday, March 24, 2010 5:49 PM > To: Cartwright, Kenneth >=20 > Hold on a sec: >=20 > You're telling me that I should select which NAPTR records come back by > picking different DNS roots (via different servers, as access points > into different DNS splits)for different queries, and the question of > "how do I know which root to query" is entirely settled by provisioning? >=20 > In other words, if I want E2M+CNAM I might query server X, and for > E2M+UNUSED I might query server Y, and I just have to know in advance > which server to query? Yes, today that's often exactly what happens. You query server X for CNAM,= which is a separate ENUM/DNS server than Y which you query for destination= /target route resolution, which is where "unused" resides. In fact, it's n= ot uncommon that you also dip another DNS server Z for number portability r= esolution, too. It's not always the case - some ENUM vendors consolidate the separate datab= ases into one ENUM interface, so you query one server for all purposes. Bu= t in the back-end behind-the-scenes that ENUM query makes the server end up= doing dips into separate databases for you, or you're given a different ro= ot name depending purposes of the query, and they use that to know what you= want. (some ENUM server vendors present a DNS protocol interface for queri= es, but store their data in a very different format/structure from DNS) -hadriel BTW, for the "unusued" case, it CANNOT be a separate RR or domain name pref= ix or anything - because by definition you have to get it back when you do = a "normal" enum NAPTR query. From HKaplan@acmepacket.com Wed Mar 24 15:04:17 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A153A67FA for ; Wed, 24 Mar 2010 15:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goJQ42ceM0zG for ; Wed, 24 Mar 2010 15:04:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5908E3A67EF for ; Wed, 24 Mar 2010 15:04:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 24 Mar 2010 18:04:33 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 24 Mar 2010 18:04:33 -0400 From: Hadriel Kaplan To: "Ray.Bellis@nominet.org.uk" Date: Wed, 24 Mar 2010 18:04:32 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrLnG9cr4NMG3dpTRGrOh2E/rgQHQAAVFwQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79CD1EC3mail_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:04:17 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79CD1EC3mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why does #5 require "additional" lookups? The lookup you do for target/des= tination is already a different key anyway - it requires a separate lookup = every time regardless (unless people use source-uri draft, I guess :)). -hadriel ________________________________ From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk] Sent: Wednesday, March 24, 2010 5:53 PM To: Hadriel Kaplan Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] alt structure suggested for CNAM > I think our choices are: > 1) Use a new DNS service (e.g., "E2CNAM") > 2) Use a new type in a new framework (e.g., "E2MD+cnam") > 3) Use a new RR type, not NAPTR (e.g., "CNAMR") > 4) Define a specific root (e.g., "5.5.5.1.cnam.e164.arpa") > 5) Define a specific query key extension (e.g., "_cnam.5.5.5.1.e164.ar= pa") You missed one: 6) use E2U+cnam, as defined in the current draft. > Personally I like #5 of the choices. FWIW, my preference (in decreasing order) for CNAM in particular would be: 2 - E2M as originally envisioned (before the layer 9+ crap got in the way= ) 6 - leave the draft as is 3 - OK, but only if the CNAM query is standalone and independent of other= NAPTRs 1 - too heavy in spec requirements, IMHO 5 - requires additional lookups 4 - requires a whole new tree, bleugh For unused and send-n some of this doesn't apply, but #4 and #5 really need= to be off the table ASAP. Ray --_000_430FC6BDED356B4C8498F634416644A91A79CD1EC3mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Why does #5 require “additional&= #8221; lookups?  The lookup you do for target/destination is already a differ= ent key anyway – it requires a separate lookup every time regardless (unl= ess people use source-uri draft, I guess J).

 

-hadriel

 

From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]
Sent: Wednesday, March 24, 2= 010 5:53 PM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] alt stru= cture suggested for CNAM

 


> I think our choices are: >    1) Use a new DNS service (= e.g., "E2CNAM")
>    2) Use a new type in a new framework (e.g., "E2MD+cnam")
>    3) Use a new RR type, not = NAPTR (e.g., "CNAMR")
>    4) Define a specific root = (e.g., "5.5.5.1.cnam.e164.arpa")
>    5) Define a specific query= key extension (e.g., "_cnam.5.5.5.1.e164.arpa")

Yo= u missed one:

&n= bsp;    6) use E2U+cnam, as defined in the current draft.

> Personally I like #5 of the choices.

FW= IW, my preference (in decreasing order) for CNAM in particular would be:

&n= bsp; 2 - E2M as originally envisioned (before the layer 9+ crap got in the way)
&n= bsp; 6 - leave the draft as is
&n= bsp; 3 - OK, but only if the CNAM query is standalone and independent of other NAPTR= s
&n= bsp; 1 - too heavy in spec requirements, IMHO
&n= bsp; 5 - requires additional lookups
&n= bsp; 4 - requires a whole new tree, bleugh

Fo= r unused and send-n some of this doesn't apply, but #4 and #5 really need to be off = the table ASAP.

Ra= y

--_000_430FC6BDED356B4C8498F634416644A91A79CD1EC3mail_-- From Ray.Bellis@nominet.org.uk Wed Mar 24 15:53:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E1E3A6E11 for ; Wed, 24 Mar 2010 15:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.241 X-Spam-Level: X-Spam-Status: No, score=-5.241 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg4PXwySOUfa for ; Wed, 24 Mar 2010 15:53:16 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 8B89D3A6E0C for ; Wed, 24 Mar 2010 15:53:16 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=KIhtNWCzS4dHqgJCVLmF87SlMFGGzrrgiSDvu6eUwhsNM+ceMXD/mq6A 4SbawKUGvKWU9/5/8oPPUuytPkSepz16ksfyMq7dIMTnRuGA2Oo9FfOJa E9o01AyQD3GMPme; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269471218; x=1301007218; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20RE:=20[e2md ]=20alt=20structure=20suggested=20for=20CNAM|Date:=20Wed, =2024=20Mar=202010=2014:53:32=20-0800|Message-ID:=20|To:=20Hadriel=20Kaplan=20|Cc:=20E.164=20To=20MetaData=20BOF=20discussion=20li st=20|MIME-Version:=201.0|In-Reply-To:=20< 430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> |References:=20<4BAA4248.2050601@softarmor.com>=09<020981 84-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>,=0D=0A=09<4BA A739B.2000609@softarmor.com>=09<754963199212404AB8E9CFCA6 C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com>=20<430 FC6BDED356B4C8498F634416644A91A79CD1EBD@mail>=20=20<430FC6BDED356B4C8498F634416644A91A79CD1EC3@ma il>; bh=6n9o5iqlXkk/oQ3q+dALQJbLxzB6I7f3McnpVaLYi0c=; b=ZSqv8/5dSEFHRNYvntK138+/LOkmeh7MPv7Q9+cQ9k+8MEF2DUKPw0Cc cxDwbKLLO6XFMtODYqYFIxi3Ux1DeMyJbdzpsAc308GCrecu19jkjemFz 2yQw7h0F+1WMGbD; X-IronPort-AV: E=Sophos;i="4.51,304,1267401600"; d="scan'208";a="17321014" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 24 Mar 2010 22:53:33 +0000 In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> <430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 24 Mar 2010 14:53:32 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 24/03/2010 10:53:32 PM, Serialize complete at 24/03/2010 10:53:32 PM Content-Type: multipart/alternative; boundary="=_alternative 007DC038882576F0_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:53:19 -0000 This is a multipart message in MIME format. --=_alternative 007DC038882576F0_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > Why does #5 require ?additional? lookups? The lookup you do for=20 > target/destination is already a different key anyway ? it requires a > separate lookup every time regardless (unless people use source-uri=20 > draft, I guess J). Yes, good point - I was forgetting that CNAM is looked up by the target=20 end, and not the caller. Ray --=_alternative 007DC038882576F0_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable > Why does #5 require “additional” lookup= s?  The lookup you do for
> target/destination is already a different key anyway – it requir= es a
> separate lookup every time regardless (unless people use source-uri
> draft, I guess J).

Yes, good point - I was forgetting that CNAM is look= ed up by the target end, and not the caller.

Ray
--=_alternative 007DC038882576F0_=-- From Ray.Bellis@nominet.org.uk Wed Mar 24 15:54:21 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3093A688F for ; Wed, 24 Mar 2010 15:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oit-nw7Z2Y-u for ; Wed, 24 Mar 2010 15:54:21 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id B79B73A6841 for ; Wed, 24 Mar 2010 15:54:20 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=u79sWrvqfBbIuxw879O3P+LG1g5m/LjmNhAhisOFIYnblc1R0jMWT68T wPvECskHyK7Dtc2U52XWO35/f1nYhkpygWM01219thWIef6880MR0BMU2 u0V5LN7B1VNGbXi; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269471282; x=1301007282; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20alt=20structure=20suggested=20for=20CNAM|Date:=20Wed, =2024=20Mar=202010=2014:54:39=20-0800|Message-ID:=20|To:=20Hadriel=20Kaplan=20|Cc:=20"E.164=20To=20MetaData=20BOF=20discussion=20l ist"=20|MIME-Version:=201.0|In-Reply-To: =20<430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> |References:=20<4BAA4248.2050601@softarmor.com>=09<020981 84-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>,=0D=0A=09<4BA A739B.2000609@softarmor.com>=09<754963199212404AB8E9CFCA6 C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com>=0D=0A =09<4BAA88CE.3030904@softarmor.com>=20<430FC6BDED356B4C84 98F634416644A91A79CD1EC2@mail>; bh=8yOPRQ8fViqgN+WwJu547f6Jp2HhCc1OC2QSHfY5/OI=; b=duc/GbjJsOtjiBMvxu/KmhE7GFHRIzKa4rXUJOJDRzl0tAOnxALgx4Cj 7e83Y58+EIFV6HoTyGUWLKmoSBvrItBZeXeQMvb4Mg8n3MOLnzeTfV0jt FEsxheiCkyJkqIF; X-IronPort-AV: E=Sophos;i="4.51,304,1267401600"; d="scan'208";a="17321021" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 24 Mar 2010 22:54:41 +0000 In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Wed, 24 Mar 2010 14:54:39 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 24/03/2010 10:54:41 PM, Serialize complete at 24/03/2010 10:54:41 PM Content-Type: multipart/alternative; boundary="=_alternative 007DDA1C882576F0_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:54:21 -0000 This is a multipart message in MIME format. --=_alternative 007DDA1C882576F0_= Content-Type: text/plain; charset="US-ASCII" > -hadriel > BTW, for the "unusued" case, it CANNOT be a separate RR or domain > name prefix or anything - because by definition you have to get it > back when you do a "normal" enum NAPTR query. Likewise for Send-N. The only alternative (and it's not a pretty one) is to require DNS "Additional Section Processing". Ray --=_alternative 007DDA1C882576F0_= Content-Type: text/html; charset="US-ASCII"
> -hadriel
> BTW, for the "unusued" case, it CANNOT be a separate RR or domain
> name prefix or anything - because by definition you have to get it
> back when you do a "normal" enum NAPTR query.
Likewise for Send-N.

The only alternative (and it's not a pretty one) is to require DNS "Additional Section Processing".

Ray
--=_alternative 007DDA1C882576F0_=-- From lconroy@insensate.co.uk Wed Mar 24 15:55:35 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA083A688F for ; Wed, 24 Mar 2010 15:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbaAruqglSoN for ; Wed, 24 Mar 2010 15:55:34 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 0E3D33A6841 for ; Wed, 24 Mar 2010 15:55:34 -0700 (PDT) Received: from [127.0.0.1] (unknown [127.0.0.3]) by insensate.co.uk (Postfix) with ESMTP id F0D06119BD8; Wed, 24 Mar 2010 22:55:53 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Wed, 24 Mar 2010 22:55:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> <430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:55:35 -0000 Actually, CNAM is only one thing that may be useful when I get an = incoming call. I can think of a whole bunch of other things of interest, as Hadriel = already suggested. Those things are going to be NAPTRs. Thus I WILL be looking for NAPTRs. On 24 Mar 2010, at 22:53, Ray.Bellis@nominet.org.uk wrote: >> Why does #5 require ?additional? lookups? The lookup you do for=20 >> target/destination is already a different key anyway ? it requires a >> separate lookup every time regardless (unless people use source-uri=20= >> draft, I guess J). >=20 > Yes, good point - I was forgetting that CNAM is looked up by the = target=20 > end, and not the caller. >=20 > Ray > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From john.elwell@siemens-enterprise.com Wed Mar 24 16:24:52 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CFC3A6830 for ; Wed, 24 Mar 2010 16:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.106 X-Spam-Level: * X-Spam-Status: No, score=1.106 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26QD2Qo-RsuH for ; Wed, 24 Mar 2010 16:24:51 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 822F53A6810 for ; Wed, 24 Mar 2010 16:19:13 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1334792 for e2md@ietf.org; Thu, 25 Mar 2010 00:19:30 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B92251EB82BF for ; Thu, 25 Mar 2010 00:19:30 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 25 Mar 2010 00:19:31 +0100 From: "Elwell, John" To: "e2md@ietf.org" Date: Thu, 25 Mar 2010 00:19:28 +0100 Thread-Topic: E2MD rough notes Thread-Index: AcrLqHOY9O8ylWaURV+VzfBpfYkphw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [e2md] E2MD rough notes X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 23:24:52 -0000 05 Admin and Agenda Bash 15 Problem Statement and Use Cases Dean: We are here to decide if we want to form a WG. IETF says that we must write spec as if it were for the public Internet. Cullen: Not exactly - want to know what it is and how it would work. John Klensin: If not intended for public Internet, should find a different = name. Intro: Bernie H=F6neisen "unused" use case "send-n" use case (Ray Bellis) "cnam" use case (Richard Shockey) "Global Service Provider Identifier" use case Jon: Clarification - URI identifies a resource, not necessarily for establi= shing a communication session. Richard Shockey. Pointed out that DRINKS had discussion on provisioning of = the Service Provider Identifier. Jon: What is metadata. These 3 use cases are all rather different - is ther= e really anything in common? Bernie: ???? Missed his answer Jon: What's metadata? Bernie: Information about a phone number. John Klensin: We have a lot of other information that we do not store in DN= S. Fine to link to phone number, but storing in DNS is a big step, and stor= ing with record types that lead to a potential for contradictions, will lea= d to potential for DNS abuse. So why is it important enough to put in DNS, = and why is this unique c.f other types of metadata. Bernie: DNS is a good way of distributing responsibility. Ray: Addressing JP's comment. Disagrees that send-n and unused are very dif= ferent - similar to ENUM. Dean: I had asked John's question on mailing list, and sense of mailing lis= t was that we already have the phone number keyed structure from ENUM, and = we need the same hierarchical and caching characteristics, so 90% functiona= lity of DNS. Peter Koch?: Agreed that CNAM is rather different. For send-n, doesn't beli= eve ugliness is removed by using E2MD rather than ENUM. No difference what = the string in NAPTR is. Killing whole ENUM stuff and doing roll-over not ba= sed on NAPTR may be better. Olaf Kolkman: ENUM tree matches well with hierarchy, but wondered that putt= ing metadata in system, what form of query/search systems do you need. If y= ou need to search for metadata with specific number, might be better to hav= e a service just for that. Might be good idea to look for different tools f= or this problems. Dean: Should be a slide addressing this later. Dean: Debated on list and felt DNS was a good match for use cases, but woul= d need to provide guidance on evaluating future use cases. John Klensin: When ENUM work, we mapped to DNS for a reason, but assumption= that numbers were well matched to DNS would be wrong. Richard Shockey: Counter argument is that ENUM does work well, and is deplo= yed in a number of trees. Would work for other types of data is that it is = a good hammer, so let's try it. Jon Peterson: Kept running into security properties, and these were found t= o be even closer. Richard Shockey: Many successful deployments in private environments. Andrew Sullivan: Problem is that there a tiny part of DNS that is not a goo= d fit, but if that is an important part, should reconsider. 10 Issues from List: Dean Willis DNS record size. Cullen: Even though present use cases are all small, will there be future = bigger ones? Dean: Guidance will be given on suitability. Is size-constrained. Richard: Not necessarily size-constrained. Cullen: What is a good idea for putting in here and what is not? How can we= scope this so someone can approve it. Spencer Dawkins: Are you suggesting ??? Dean: Yes. Is everything a NAPTR Jon: Goes beyond just CNAM not being like the others. Why do you need NAPTR= , if have to do some kludge. Patrick Faltstrom: Number of problems with NAPTR record with ENUM, so perha= ps shouldn't use it for this, in same we should not have for ENUM. Need to = see what record types match and perhaps using correct choice, rather than j= ust following EN@UM Jon: Would one record type necessarily fit all cases? Dean: So look at cases separately. Jon: So why do you need a framework then? Spencer: What you said then sounded scarier than everything being one NAPTR= or one container. Dean: Yes, that is one approach, or could have different filter criteria. S= RV records might give a clue to another possibility. Jabber: Question concerning size of response. Dean: With many use cases you might have a very large response. Dave Crocker: Discussion is on low level implementation choices. Need to do= lots of different things, but without very specific use cases as goals, so= how can you select. Also mentioned possibility of txt records. Dean: We do have 4 specific use cases, with I-Ds on 3. Someone: 10 more have been proposed to list. Jon: What do they have in common. Dean: indexed by phone call etc. Jon: Disagree. Cullen: What would be the registration procedure. If ENUM were 1st come 1st= served, we would not be having this BoF. Dean: Current draft charter suggests expert review. Richard Shockey: Tried to follow ENUM as closely as possible. David Schwarz: Is this something to help me make routing decision? CNAM has= nothing to do with routing. Who thinks there is something worth looking it? A lot of people raised hand= s. Who thinks DNS is a suitable basis? Dave Crocker: Don't understand the sequence of questions. Don't have specif= ic set of problems, so no basis for deciding that DNS is right basis. Dean: Let's back-up and look at CNAM Who agrees DNS is suitable for CNAM: 10 for, 3 against. Who agrees ENUM is suitable for CNAM: - not taken. Richard is this a problem, is this a problem that we in IETF can solve, are= there people who would like to fix problems. We are debating solutions bef= ore we establish a charter. Christer: Assumes SIP is main usage, so can't we do CNAM with SIP OPTIONS? Dean: Could do by SIP event package. Gonzalo: Should ask if ???? Dean: Who thinks problem space has be clarified that we understand scope, s= ome do, some don't. Dean: Are there people who want to solve problem: a fairly large number. Gonzalo: We didn't discuss charter, and we should have asked question wheth= er we want to propos WG based on that charter. John Klensin: Should ask who thinks proposed charter it not ready to go. Dean: Asked that question. More thought it was not ready to go than thought= it was ready to go. 10 Discussion of Open Issues: Open 10 Charter: Bernie 10 Next Actions and Conclusions (chairs/ADs)= From jim@rfc1035.com Wed Mar 24 16:25:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293783A68E7 for ; Wed, 24 Mar 2010 16:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=0.928, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1Ir1CJ2Rpcq for ; Wed, 24 Mar 2010 16:25:31 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 0FACA3A6A4F for ; Wed, 24 Mar 2010 16:20:26 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 4D9DC154208B; Wed, 24 Mar 2010 23:20:45 +0000 (GMT) Message-Id: From: Jim Reid To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 24 Mar 2010 23:20:44 +0000 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: [e2md] what to do about CNAMs X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 23:25:35 -0000 On 24 Mar 2010, at 22:54, Ray.Bellis@nominet.org.uk wrote: > The only alternative (and it's not a pretty one) is to require DNS > "Additional Section Processing". This is not a viable option Ray. Though you already know this. Tinkering with Additional Section Processing semantics will mean changes to all DNS servers and resolvers. [Read "not going to happen"...] IMO it's unlikely anything which requires new Additional Section Processing would emerge unscathed from the DNS WGs or make it out alive from the DNS Directorate this side of the next Ice Age. To get back to Hadriel's list, my preferences would be (in decreasing order): a) Use a new type in a new framework (e.g., "E2MD+cnam") b) Use E2U+cnam, as defined in the current draft c) Use a new RR type, not NAPTR (e.g., "CNAMR") d) Define a specific query key extension (e.g., "_cnam. 5.5.5.1.e164.arpa") e) Define a specific root (e.g., "5.5.5.1.cnam.e164.arpa") f) Use a new DNS service (e.g., "E2CNAM") c) and d) are more or less equal because they both require an additional lookup. d) is slightly worse because it means using an additional owner-name which could make provisioning clumsier. e) and f) are non-starters and not worth pursuing. From lendl@nic.at Thu Mar 25 00:30:06 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F70C3A6C41 for ; Thu, 25 Mar 2010 00:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkALfoeHZOa6 for ; Thu, 25 Mar 2010 00:30:05 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 2BA1A3A67B0 for ; Thu, 25 Mar 2010 00:30:01 -0700 (PDT) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id B4A014C2F1; Thu, 25 Mar 2010 08:30:20 +0100 (CET) Message-ID: <4BAB110B.2090207@nic.at> Date: Thu, 25 Mar 2010 08:30:19 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Lawrence Conroy References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> <430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 07:30:06 -0000 On 24.03.2010 23:55, Lawrence Conroy wrote: > Actually, CNAM is only one thing that may be useful when I get an incoming call. Not at all. Imagine you're getting a SIP call over the public Internet and it claims to be from a certain E.164 number. If we ever want to build something that allows the receiving party to validate that claim, a lookup into ENUM / E2MD to query for data associated with that number (public key for SIP identity, some SPF-like info,...) will be really helpful. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From Ray.Bellis@nominet.org.uk Thu Mar 25 07:13:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666C43A695C for ; Thu, 25 Mar 2010 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.116 X-Spam-Level: X-Spam-Status: No, score=-5.116 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WORdyPReIu7R for ; Thu, 25 Mar 2010 07:13:21 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 0762F3A6A8F for ; Thu, 25 Mar 2010 07:12:57 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=aPjbl+xahIGlCB+pCv/1AVfncybci8DwcZ7SlRWA72dvRFKEprdKUM33 yT9l8PxZEBPnDxU8JH3fgnoY9RPldUzlhJ4tZvPJ/q2BgWCFxPHy2TL9l j23x9uqAcXdS4yn; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269526400; x=1301062400; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20alt=20structure=20suggested=20for=20CNAM|Date:=20Thu, =2025=20Mar=202010=2006:13:16=20-0800|Message-ID:=20|To:=20Otmar=20Lendl=20|Cc:=20" E.164=20To=20MetaData=20BOF=20discussion=20list"=20,=0D=0A=09Lawrence=20Conroy=20|MIME-Version:=201.0|In-Reply-To:=20<4BAB110B.2090 207@nic.at>|References:=20<4BAA4248.2050601@softarmor.com >=09<02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, =0D=0A=09<4BAA739B.2000609@softarmor.com>=09<754963199212 404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tns i.com>=0D=0A=09<430FC6BDED356B4C8498F634416644A91A79CD1EB D@mail>=09=0D=0A=09<430FC6BDED356B4C8498 F634416644A91A79CD1EC3@mail>=09=20=20<4BAB1 10B.2090207@nic.at>; bh=tHTSrcVgELufbyVBp9JRQ1Ypv5U3DZY8gwzz/VRa3cc=; b=UNCINFS3ZTMvBFmRQ+jxFsR+6Kergbn2mVfNN594C77WYmBcl+4KqDPI cGUZuAfGmj5tq5LYSJbCddDom/jRBl8Af7Ag2yVge+92+SihWFbN/8W37 K4XaYONQukjr4OJ; X-IronPort-AV: E=Sophos;i="4.51,307,1267401600"; d="scan'208";a="22872631" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 25 Mar 2010 14:13:19 +0000 In-Reply-To: <4BAB110B.2090207@nic.at> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> <430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> <4BAB110B.2090207@nic.at> To: Otmar Lendl MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Thu, 25 Mar 2010 06:13:16 -0800 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 25/03/2010 02:13:19 PM, Serialize complete at 25/03/2010 02:13:19 PM Content-Type: multipart/alternative; boundary="=_alternative 004E1EDD882576F1_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 14:13:24 -0000 This is a multipart message in MIME format. --=_alternative 004E1EDD882576F1_= Content-Type: text/plain; charset="US-ASCII" >> Actually, CNAM is only one thing that may be useful when I get an incoming call. > Not at all. Otmar, I think you mis-parsed Lawrence's e-mail. I did too on first reading. He did not mean it's the _only_ thing, he meant it was just _one of many_. > Imagine you're getting a SIP call over the public Internet and it claims to > be from a certain E.164 number. > > If we ever want to build something that allows the receiving party to > validate that claim, a lookup into ENUM / E2MD to query for data associated > with that number (public key for SIP identity, some SPF-like info,...) will > be really helpful. That's pretty much what Lawrence was saying too. Ray --=_alternative 004E1EDD882576F1_= Content-Type: text/html; charset="US-ASCII" >>  Actually, CNAM is only one thing that may be useful when I get an incoming call.
> Not at all.

Otmar, I think you mis-parsed Lawrence's e-mail.  I did too on first reading.

He did not mean it's the _only_ thing, he meant it was just _one of many_.

> Imagine you're getting a SIP call over the public Internet and it claims to
> be from a certain E.164 number.
>
> If we ever want to build something that allows the receiving party to
> validate that claim, a lookup into ENUM / E2MD to query for data associated
> with that number (public key for SIP identity, some SPF-like info,...) will
> be really helpful.
That's pretty much what Lawrence was saying too.

Ray
--=_alternative 004E1EDD882576F1_=-- From lconroy@insensate.co.uk Thu Mar 25 07:28:32 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C493A3A6B31 for ; Thu, 25 Mar 2010 07:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.327 X-Spam-Level: X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkABCvCf9Fsf for ; Thu, 25 Mar 2010 07:28:30 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 3F7973A68DE for ; Thu, 25 Mar 2010 07:27:38 -0700 (PDT) Received: from [127.0.0.1] (unknown [127.0.0.3]) by insensate.co.uk (Postfix) with ESMTP id 74E71119F2F; Thu, 25 Mar 2010 14:27:58 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: Date: Thu, 25 Mar 2010 14:27:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2A626B72-9FDD-4932-B181-9197D0738450@insensate.co.uk> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <430FC6BDED356B4C8498F634416644A91A79CD1EBD@mail> <430FC6BDED356B4C8498F634416644A91A79CD1EC3@mail> <4BAB110B.2090207@nic.at> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" , Otmar Lendl Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 14:28:32 -0000 Hi Ray, Otmar, folks, Amen to that. Of course, "many" is gated by a reasonable RRSet size at = this owner :). Obviously (i) we're wildly agreeing, and (ii) English is self-evidently = not my first language. all the best, Lawrence On 25 Mar 2010, at 14:13, Ray.Bellis@nominet.org.uk wrote: > Otmar, I think you mis-parsed Lawrence's e-mail. I did too on first=20= > reading. > He did not mean it's the _only_ thing, he meant it was just _one of = many_. From dean.willis@softarmor.com Thu Mar 25 13:50:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5273A6C3B for ; Thu, 25 Mar 2010 13:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.842 X-Spam-Level: X-Spam-Status: No, score=0.842 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyaleaK2Kqoz for ; Thu, 25 Mar 2010 13:50:31 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 98A883A69D9 for ; Thu, 25 Mar 2010 13:50:31 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2PKopPK005404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Mar 2010 15:50:53 -0500 Message-ID: <4BABCCAA.2000502@softarmor.com> Date: Thu, 25 Mar 2010 15:50:50 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" , john-ietf@jck.com, jon.peterson@neustar.biz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 20:50:33 -0000 The ID draft-ietf-enum-cnam-08 describes an approach for associating display names (aka "calling names") with phone numbers in the e164.arpa tree using ENUM-style NAPTR records. For reasons discussed in yesterday's BOF, this approach is seen by many as a not-quite-right approach. If ENUM is used for phone-number-to-URI mapping, then the same structure is very attractive for distributing the display names associated with those phone numbers. It's really too close a match to justify building some sort of external directory structure. But NAPTR as used in draft-ietf-enum-cnam-08 isn't quite the right approach for processing a display name. Alternatives include 1) using a new RR type, and 2) re-using an existing type. RFC 5507 gives us guidance on extension methods, and generally recommends a new Resource Record type. But it's worth looking at reuse of an existing RR type. The closest existing type is obviously TXT, which has its problems but is worth looking at for this application. What would be wrong with, for cases in which the calling name does NOT require authorized access, putting it in the e164.arpa tree with an _displayname prefix and a TXT record? Example: _displayname.0.9.1.9.9.1.5.2.7.9.1.e14.arpa. IN TXT "Dean Willis" YES, I KNOW RFC 5507 and the DNS community frown on text records. But let's go through the logic here, please ... The _displayname key lets us know "what the TXT means", which is the eternal problem with TXT records. It also makes a query for the display name very easy: if you get a phone call and need to ask for the display name associated with the source phone number, form a DNS query by inverting the phone number, adding the "_displayname" prefix and appending the 'e164.arpa" domain, and make a TXT query. The value of the TXT record is the display name string; there is no need to parse it. Let's talk through the rationale in RFC 5507 against both _prefix and TXT usages. 1) _prefix approaches do not work well with wildcards. This doesn't appear to be a problem for "calling name", as the use case requires a terminal fully-specified phone number for looking up the calling name. 2) TXT records have no inherent format or semantic, and attempts to dictate parsing rules are just silly. That doesn't seem to be a problem for the "calling name" use case; all we want is a human-readable display string. It has no inherent semantics, is not parsed by the application, and one can't "break" the intended application by putting something unexpected into the TXT record value. 3) Having the data in a TXT record, as opposed to a new RR type, makes it a lot easier for standard tools like "dig" and "nslookup" to display the data. And since the data has no semantic encoding -- it's just a display string -- the result from "dig" is perfectly human-readable. Comparison of this approach to a new RR If we have a use case for wild-carded display names, then a new RR would obviously become a better choice. The standardization effort for _displayname and TXT seems to be lesser. However, there's no registry for _prefix usages. There is an ID for creating a registry of _prefixes for SRV records: draft-gudmundsson-dns-srv-iana-registry-04 Doing this approach cleanly for displayname arguably requires creating a registry for _prefix names on TXT records, which is arguably as hard as defining a new RR type would be, and probably politically more difficult. On the other hand, the number of RR extension types available is not unlimited. Is it worth defining a new type that's probably only useful in the e164.arpa tree? -- Dean Willis -- dean From jay@nzrs.net.nz Thu Mar 25 13:59:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7503A6950 for ; Thu, 25 Mar 2010 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3kOIvCodN6B for ; Thu, 25 Mar 2010 13:59:18 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 3F1DC3A6A92 for ; Thu, 25 Mar 2010 13:59:15 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 6BC752DBA7C; Fri, 26 Mar 2010 09:59:36 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-YnqtHafLQ0; Fri, 26 Mar 2010 09:59:36 +1300 (NZDT) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A4E382DB004; Fri, 26 Mar 2010 09:59:35 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <4BABCCAA.2000502@softarmor.com> Date: Fri, 26 Mar 2010 09:59:34 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <833B9ADC-0622-43EF-A28C-3A800B7258B8@nzrs.net.nz> References: <4BABCCAA.2000502@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: john-ietf@jck.com, "E.164 To MetaData BOF discussion list" , jon.peterson@neustar.biz Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 20:59:19 -0000 On 26/03/2010, at 9:50 AM, Dean Willis wrote: >=20 > The ID draft-ietf-enum-cnam-08 describes an approach for associating > display names (aka "calling names") with phone numbers in the = e164.arpa > tree using ENUM-style NAPTR records. For reasons discussed in > yesterday's BOF, this approach is seen by many as a not-quite-right > approach. >=20 > If ENUM is used for phone-number-to-URI mapping, then the same = structure > is very attractive for distributing the display names associated with > those phone numbers. It's really too close a match to justify building > some sort of external directory structure. >=20 > But NAPTR as used in draft-ietf-enum-cnam-08 isn't quite the right > approach for processing a display name. >=20 > Alternatives include 1) using a new RR type, and 2) re-using an = existing > type. >=20 > RFC 5507 gives us guidance on extension methods, and generally > recommends a new Resource Record type. But it's worth looking at reuse > of an existing RR type. The closest existing type is obviously TXT, > which has its problems but is worth looking at for this application. >=20 > What would be wrong with, for cases in which the calling name does NOT > require authorized access, putting it in the e164.arpa tree with an > _displayname prefix and a TXT record? Because, as has been explained about a bazillion times, we want a = *single lookup for NAPTR records under the e164 domain* (whether of = caller or receiver), to then provide all the URIs and metadata for a = single processing step. Jay >=20 >=20 > Example: >=20 > _displayname.0.9.1.9.9.1.5.2.7.9.1.e14.arpa. IN TXT "Dean Willis" >=20 >=20 > YES, I KNOW RFC 5507 and the DNS community frown on text records. But > let's go through the logic here, please ... >=20 >=20 > The _displayname key lets us know "what the TXT means", which is the > eternal problem with TXT records. It also makes a query for the = display > name very easy: if you get a phone call and need to ask for the = display > name associated with the source phone number, form a DNS query by > inverting the phone number, adding the "_displayname" prefix and > appending the 'e164.arpa" domain, and make a TXT query. The value of = the > TXT record is the display name string; there is no need to parse it. >=20 >=20 > Let's talk through the rationale in RFC 5507 against both _prefix and > TXT usages. >=20 > 1) _prefix approaches do not work well with wildcards. This doesn't > appear to be a problem for "calling name", as the use case requires a > terminal fully-specified phone number for looking up the calling name. >=20 > 2) TXT records have no inherent format or semantic, and attempts to > dictate parsing rules are just silly. That doesn't seem to be a = problem > for the "calling name" use case; all we want is a human-readable = display > string. It has no inherent semantics, is not parsed by the = application, > and one can't "break" the intended application by putting something > unexpected into the TXT record value. >=20 > 3) Having the data in a TXT record, as opposed to a new RR type, makes > it a lot easier for standard tools like "dig" and "nslookup" to = display > the data. And since the data has no semantic encoding -- it's just a > display string -- the result from "dig" is perfectly human-readable. >=20 >=20 > Comparison of this approach to a new RR >=20 > If we have a use case for wild-carded display names, then a new RR = would > obviously become a better choice. >=20 > The standardization effort for _displayname and TXT seems to be = lesser. > However, there's no registry for _prefix usages. There is an ID for > creating a registry of _prefixes for SRV records: >=20 > draft-gudmundsson-dns-srv-iana-registry-04 >=20 > Doing this approach cleanly for displayname arguably requires creating = a > registry for _prefix names on TXT records, which is arguably as hard = as > defining a new RR type would be, and probably politically more = difficult. >=20 > On the other hand, the number of RR extension types available is not > unlimited. Is it worth defining a new type that's probably only useful > in the e164.arpa tree? >=20 >=20 > -- > Dean Willis >=20 >=20 >=20 > -- > dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From lconroy@insensate.co.uk Thu Mar 25 14:10:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5FD3A6942 for ; Thu, 25 Mar 2010 14:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.713 X-Spam-Level: X-Spam-Status: No, score=0.713 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgraXg5hrC7Y for ; Thu, 25 Mar 2010 14:10:00 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id AEA563A6358 for ; Thu, 25 Mar 2010 14:09:59 -0700 (PDT) Received: from [127.0.0.1] (unknown [127.0.0.3]) by insensate.co.uk (Postfix) with ESMTP id 9467711A15D; Thu, 25 Mar 2010 21:10:21 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <4BABCCAA.2000502@softarmor.com> Date: Thu, 25 Mar 2010 21:10:21 +0000 Content-Transfer-Encoding: 7bit Message-Id: <8DA22B6B-C22B-4266-BD00-1B4926C1982C@insensate.co.uk> References: <4BABCCAA.2000502@softarmor.com> To: Dean Willis , Jim Reid X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" , jon.peterson@neustar.biz Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:10:03 -0000 Hi Dean, At the risk of causing Richard to have a conniption, if you *really* want a new TXT-like RR type, there is one already. Type 56 -- NINFO. Jim will know whether something that describes Zone Status could be stretched to cover the person who owns it, but ... However, did you not see the comments that there are other things to look at in this case? all the best, Lawrence On 25 Mar 2010, at 20:50, Dean Willis wrote: > The ID draft-ietf-enum-cnam-08 describes an approach for associating > display names (aka "calling names") with phone numbers in the e164.arpa > tree using ENUM-style NAPTR records. For reasons discussed in > yesterday's BOF, this approach is seen by many as a not-quite-right > approach. > > If ENUM is used for phone-number-to-URI mapping, then the same structure > is very attractive for distributing the display names associated with > those phone numbers. It's really too close a match to justify building > some sort of external directory structure. > > But NAPTR as used in draft-ietf-enum-cnam-08 isn't quite the right > approach for processing a display name. > > Alternatives include 1) using a new RR type, and 2) re-using an existing > type. > > RFC 5507 gives us guidance on extension methods, and generally > recommends a new Resource Record type. But it's worth looking at reuse > of an existing RR type. The closest existing type is obviously TXT, > which has its problems but is worth looking at for this application. > > What would be wrong with, for cases in which the calling name does NOT > require authorized access, putting it in the e164.arpa tree with an > _displayname prefix and a TXT record? > > > Example: > > _displayname.0.9.1.9.9.1.5.2.7.9.1.e14.arpa. IN TXT "Dean Willis" > > > YES, I KNOW RFC 5507 and the DNS community frown on text records. But > let's go through the logic here, please ... > > > The _displayname key lets us know "what the TXT means", which is the > eternal problem with TXT records. It also makes a query for the display > name very easy: if you get a phone call and need to ask for the display > name associated with the source phone number, form a DNS query by > inverting the phone number, adding the "_displayname" prefix and > appending the 'e164.arpa" domain, and make a TXT query. The value of the > TXT record is the display name string; there is no need to parse it. > > > Let's talk through the rationale in RFC 5507 against both _prefix and > TXT usages. > > 1) _prefix approaches do not work well with wildcards. This doesn't > appear to be a problem for "calling name", as the use case requires a > terminal fully-specified phone number for looking up the calling name. > > 2) TXT records have no inherent format or semantic, and attempts to > dictate parsing rules are just silly. That doesn't seem to be a problem > for the "calling name" use case; all we want is a human-readable display > string. It has no inherent semantics, is not parsed by the application, > and one can't "break" the intended application by putting something > unexpected into the TXT record value. > > 3) Having the data in a TXT record, as opposed to a new RR type, makes > it a lot easier for standard tools like "dig" and "nslookup" to display > the data. And since the data has no semantic encoding -- it's just a > display string -- the result from "dig" is perfectly human-readable. > > > Comparison of this approach to a new RR > > If we have a use case for wild-carded display names, then a new RR would > obviously become a better choice. > > The standardization effort for _displayname and TXT seems to be lesser. > However, there's no registry for _prefix usages. There is an ID for > creating a registry of _prefixes for SRV records: > > draft-gudmundsson-dns-srv-iana-registry-04 > > Doing this approach cleanly for displayname arguably requires creating a > registry for _prefix names on TXT records, which is arguably as hard as > defining a new RR type would be, and probably politically more difficult. > > On the other hand, the number of RR extension types available is not > unlimited. Is it worth defining a new type that's probably only useful > in the e164.arpa tree? > > > -- > Dean Willis > > > > -- > dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Thu Mar 25 14:13:02 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76C63A67A3 for ; Thu, 25 Mar 2010 14:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.85 X-Spam-Level: X-Spam-Status: No, score=0.85 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KAvQfgmVtvC for ; Thu, 25 Mar 2010 14:13:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 836553A6358 for ; Thu, 25 Mar 2010 14:12:57 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2PLDHaI005683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Mar 2010 16:13:19 -0500 Message-ID: <4BABD1ED.1000208@softarmor.com> Date: Thu, 25 Mar 2010 16:13:17 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Jay Daley References: <4BABCCAA.2000502@softarmor.com> <833B9ADC-0622-43EF-A28C-3A800B7258B8@nzrs.net.nz> In-Reply-To: <833B9ADC-0622-43EF-A28C-3A800B7258B8@nzrs.net.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:13:02 -0000 Jay Daley wrote: > Because, as has been explained about a bazillion times, we want a > *single lookup for NAPTR records under the e164 domain* (whether of > caller or receiver), to then provide all the URIs and metadata for a > single processing step. As has been asked about a bazillion times: Why do you want the display name to come back along with all the NAPTR records in one RR set? We have two use case families: 1) Things one queries when setting up a call. The display name is not needed when setting up call, and just wastes space in the response. 2) Things queried when one gets a call. So far, that set is small: just the display name. All of the other cruft in the NAPTR records is un-needed at this point, and just wastes space in the response. We were asked many times yesterday: The display name is never, ever used in routing the call. Why does it belong in the NAPTR set? Do you have a better answer to that question than "because NAPTR is the hammer I have handy?" If so, please clue me in! -- Dean From jim@rfc1035.com Thu Mar 25 14:16:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C76A3A6958 for ; Thu, 25 Mar 2010 14:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.627 X-Spam-Level: X-Spam-Status: No, score=0.627 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jkIQK-URlJ1 for ; Thu, 25 Mar 2010 14:16:17 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 570B03A6358 for ; Thu, 25 Mar 2010 14:16:17 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id AD4A8154208B; Thu, 25 Mar 2010 21:16:37 +0000 (GMT) Message-Id: <18014E6D-835A-4E29-8EAE-156DD59A12AE@rfc1035.com> From: Jim Reid To: Dean Willis In-Reply-To: <4BABCCAA.2000502@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 25 Mar 2010 21:16:37 +0000 References: <4BABCCAA.2000502@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: john-ietf@jck.com, "E.164 To MetaData BOF discussion list" , jon.peterson@neustar.biz Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:16:19 -0000 On 25 Mar 2010, at 20:50, Dean Willis wrote: > What would be wrong with, for cases in which the calling name does NOT > require authorized access, putting it in the e164.arpa tree with an > _displayname prefix and a TXT record? Because there's no way of knowing what other TXT records might exist at that node and which, if any, of them contain the information that's of interest. TXT records get used for all sorts of crap: version control info, contact details for the DNS administrator, anti-spam things, etc, etc. This was why I got a typecode for NINFO, which is really a TXT record disguised as a simple presence indicator. A discrete typecode was needed to isolate that presumably useful info from whatever garbage people were shoving into TXT records. Another reason for not adding another RRtype and/or QNAME is to avoid having to make another DNS lookup. If a single query can return everything of interest.... I thought we'd been over this already. > There is an ID for creating a registry of _prefixes for SRV records That's because those prefixes denote things like application- and transport-level protocols. The underscores are syntactic sugar so the names of SRV records can't be confused with hostnames. From dean.willis@softarmor.com Thu Mar 25 14:17:38 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379F73A69B0 for ; Thu, 25 Mar 2010 14:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypyh4oluKN4e for ; Thu, 25 Mar 2010 14:17:31 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1A9523A6A38 for ; Thu, 25 Mar 2010 14:17:01 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2PLHKxD005759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Mar 2010 16:17:22 -0500 Message-ID: <4BABD2E0.2070909@softarmor.com> Date: Thu, 25 Mar 2010 16:17:20 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Lawrence Conroy References: <4BABCCAA.2000502@softarmor.com> <8DA22B6B-C22B-4266-BD00-1B4926C1982C@insensate.co.uk> In-Reply-To: <8DA22B6B-C22B-4266-BD00-1B4926C1982C@insensate.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" , jon.peterson@neustar.biz Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:17:39 -0000 Lawrence Conroy wrote: > Hi Dean, > At the risk of causing Richard to have a conniption, if you *really* > want a new TXT-like RR type, there is one already. Type 56 -- NINFO. okay, that's interesting. > However, did you not see the comments that there are other things to > look at in this case? Okay, but that still leaves us with "the set of things to look up when placing a call" and "the set of things to look up when answering a call". Is there any commonality, or are these really completely disjoint spaces? Because they currently appear to be disjoint, and that's a large part of why some people are pushing back. Other people have other reasons, of course. -- Dean From HKaplan@acmepacket.com Thu Mar 25 14:19:06 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5F03A6358 for ; Thu, 25 Mar 2010 14:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.825 X-Spam-Level: X-Spam-Status: No, score=0.825 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBOd0JGbC2Bt for ; Thu, 25 Mar 2010 14:19:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 96DD43A6BFE for ; Thu, 25 Mar 2010 14:18:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 25 Mar 2010 17:19:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 25 Mar 2010 17:19:15 -0400 From: Hadriel Kaplan To: Jay Daley , Dean Willis Date: Thu, 25 Mar 2010 17:19:12 -0400 Thread-Topic: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? Thread-Index: AcrMXi6mzuXNQbdURuiHNoXh8Nh1hgAASo/A Message-ID: <430FC6BDED356B4C8498F634416644A91A79E923EB@mail> References: <4BABCCAA.2000502@softarmor.com> <833B9ADC-0622-43EF-A28C-3A800B7258B8@nzrs.net.nz> In-Reply-To: <833B9ADC-0622-43EF-A28C-3A800B7258B8@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "john-ietf@jck.com" , "E.164 To MetaData BOF discussion list" , "jon.peterson@neustar.biz" Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:19:06 -0000 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Jay Daley > Sent: Thursday, March 25, 2010 5:00 PM > To: Dean Willis >=20 > Because, as has been explained about a bazillion times, we want a *single > lookup for NAPTR records under the e164 domain* (whether of caller or > receiver), to then provide all the URIs and metadata for a single > processing step. That's not really possible with cnam, if you really mean one step. When yo= u look up the cnam, the key you're using for the lookup is the calling numb= er, but when you do a lookup for every other service type defined so far, t= he key being used is the called number. =20 In that context, it's actually more efficient to only get back the cnam ent= ry when doing the calling-party query, instead of getting all of that numbe= r's other NAPTRs. Unless you mean in the context of doing any/all source calling number looku= ps, because you have other reasons to do calling-party lookups, for either = some anti-source-spoofing security check or for some as-yet-to-be-defined r= easons. I suppose we could just say use a "_src" name prefix, so it would = be "_src.5.5.5.2.1.2.1.e164.arpa", and it would have a E2CNAM or E2M+cname = entry plus possibly other entries. -hadriel From dean.willis@softarmor.com Thu Mar 25 14:28:36 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116AE3A6CD9 for ; Thu, 25 Mar 2010 14:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.864 X-Spam-Level: X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz8VwYLmhoLC for ; Thu, 25 Mar 2010 14:28:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C4E4D3A6B97 for ; Thu, 25 Mar 2010 14:28:34 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2PLSsYc005890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Mar 2010 16:28:56 -0500 Message-ID: <4BABD596.6090402@softarmor.com> Date: Thu, 25 Mar 2010 16:28:54 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Jim Reid References: <4BABCCAA.2000502@softarmor.com> <18014E6D-835A-4E29-8EAE-156DD59A12AE@rfc1035.com> In-Reply-To: <18014E6D-835A-4E29-8EAE-156DD59A12AE@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: john-ietf@jck.com, "E.164 To MetaData BOF discussion list" , jon.peterson@neustar.biz Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:28:36 -0000 Jim Reid wrote: > On 25 Mar 2010, at 20:50, Dean Willis wrote: > >> What would be wrong with, for cases in which the calling name does NOT >> require authorized access, putting it in the e164.arpa tree with an >> _displayname prefix and a TXT record? > > Because there's no way of knowing what other TXT records might exist at > that node and which, if any, of them contain the information that's of > interest. TXT records get used for all sorts of crap: version control > info, contact details for the DNS administrator, anti-spam things, etc, > etc. This was why I got a typecode for NINFO, which is really a TXT > record disguised as a simple presence indicator. A discrete typecode was > needed to isolate that presumably useful info from whatever garbage > people were shoving into TXT records. The "_displayname" prefix gives us a unique node, does it not? > > Another reason for not adding another RRtype and/or QNAME is to avoid > having to make another DNS lookup. If a single query can return > everything of interest.... I thought we'd been over this already. If "everything of interest" becomes a set of 50 records or so (and we had a least one guy say he had use cases for 50 different bits of metadata) then we havea real oroblem with that approach, right? > >> There is an ID for creating a registry of _prefixes for SRV records > > That's because those prefixes denote things like application- and > transport-level protocols. The underscores are syntactic sugar so the > names of SRV records can't be confused with hostnames. > Yes, and the same applies to the _ in the example I proposed. -- Dean From HKaplan@acmepacket.com Thu Mar 25 15:07:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF31B3A6BE1 for ; Thu, 25 Mar 2010 15:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.839 X-Spam-Level: X-Spam-Status: No, score=0.839 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ2VrHeVn+LC for ; Thu, 25 Mar 2010 15:07:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DF9C73A6803 for ; Thu, 25 Mar 2010 15:07:09 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 25 Mar 2010 18:07:31 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 25 Mar 2010 18:07:31 -0400 From: Hadriel Kaplan To: Dean Willis , Lawrence Conroy Date: Thu, 25 Mar 2010 18:07:29 -0400 Thread-Topic: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? Thread-Index: AcrMYMaeL55d3OTETJ+QxqjhyQhc/wAAIQvA Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92403@mail> References: <4BABCCAA.2000502@softarmor.com> <8DA22B6B-C22B-4266-BD00-1B4926C1982C@insensate.co.uk> <4BABD2E0.2070909@softarmor.com> In-Reply-To: <4BABD2E0.2070909@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" , "jon.peterson@neustar.biz" Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 22:07:13 -0000 There are a couple of rally good reasons to keep cnam a "different" lookup = from destination/called-party lookups: 1) From a performance and message size perspective, it's better to only ge= t back what you want - and cnam is one of the rare cases where it's the onl= y thing you want back for that query key. 2) For some "ENUM Servers", the DNS query makes them do a TCAP query/dip b= ehind-the-scenes. Cnam lookups are not free, so you really want the ENUM s= erver to know you want a cnam result when you do a DNS query. There are only so many ways to make the query be explicit: ask for a specif= ic RR type, which requires a new RR for cnam, or ask with a different key. = (or ask a different server or port I guess) -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Thursday, March 25, 2010 5:17 PM > To: Lawrence Conroy > Cc: E.164 To MetaData BOF discussion list; jon.peterson@neustar.biz > Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT > records? >=20 > Lawrence Conroy wrote: > > Hi Dean, > > At the risk of causing Richard to have a conniption, if you *really* > > want a new TXT-like RR type, there is one already. Type 56 -- NINFO. >=20 > okay, that's interesting. >=20 > > However, did you not see the comments that there are other things to > > look at in this case? >=20 > Okay, but that still leaves us with "the set of things to look up when > placing a call" and "the set of things to look up when answering a call". >=20 > Is there any commonality, or are these really completely disjoint > spaces? Because they currently appear to be disjoint, and that's a large > part of why some people are pushing back. Other people have other > reasons, of course. >=20 > -- > Dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From lendl@nic.at Thu Mar 25 23:31:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97DB3A69F9 for ; Thu, 25 Mar 2010 23:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1DLEdAH+xCn for ; Thu, 25 Mar 2010 23:31:03 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 319A93A69F1 for ; Thu, 25 Mar 2010 23:31:02 -0700 (PDT) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id BFB604C301 for ; Fri, 26 Mar 2010 07:31:23 +0100 (CET) Message-ID: <4BAC54BB.2020207@nic.at> Date: Fri, 26 Mar 2010 07:31:23 +0100 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: e2md@ietf.org References: <4BABCCAA.2000502@softarmor.com> In-Reply-To: <4BABCCAA.2000502@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 06:31:04 -0000 Dean, On 25.03.2010 21:50, Dean Willis wrote: > > 1) _prefix approaches do not work well with wildcards. This doesn't > appear to be a problem for "calling name", as the use case requires a > terminal fully-specified phone number for looking up the calling name. Yes, the calling number is always a specific string of digits. In Germany and Austria with their open dialing plans the carrier only knows to which customer the base number is associated with. The carrier does not know which extension do exist and what length they are. So unless the carrier delegates the ENUM space to the customer, the carrier has to work with wildcards for cnam in these cases. Prefixes just do not work with open numbering plans. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From kcartwright@tnsi.com Fri Mar 26 08:11:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32103A6B14 for ; Fri, 26 Mar 2010 08:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOJ5vibRPdhv for ; Fri, 26 Mar 2010 08:11:19 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id F3BB53A6B1A for ; Fri, 26 Mar 2010 08:10:40 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41870197; Fri, 26 Mar 2010 11:10:53 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Mar 2010 11:10:53 -0400 From: "Cartwright, Kenneth" To: Hadriel Kaplan , Dean Willis Date: Fri, 26 Mar 2010 11:10:51 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrLm95b8jmuLQUbRA2LUUFy+yD8JgAAGs+gAFZhSLA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 15:11:21 -0000 Exactly. And there are of course extremely good reasons why one must usual= ly ultimately go to different "resolution" server(s) to lookup data like CN= AM. First and foremost, the calling name data is usually collected and con= solidated and managed and offered up by a separate company or organization = whose business it is to do that. Ken -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Wednesday, March 24, 2010 6:01 PM To: Dean Willis; Cartwright, Kenneth Cc: E.164 To MetaData BOF discussion list Subject: RE: [e2md] alt structure suggested for CNAM > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Wednesday, March 24, 2010 5:49 PM > To: Cartwright, Kenneth > > Hold on a sec: > > You're telling me that I should select which NAPTR records come back by > picking different DNS roots (via different servers, as access points > into different DNS splits)for different queries, and the question of > "how do I know which root to query" is entirely settled by provisioning? > > In other words, if I want E2M+CNAM I might query server X, and for > E2M+UNUSED I might query server Y, and I just have to know in advance > which server to query? Yes, today that's often exactly what happens. You query server X for CNAM,= which is a separate ENUM/DNS server than Y which you query for destination= /target route resolution, which is where "unused" resides. In fact, it's n= ot uncommon that you also dip another DNS server Z for number portability r= esolution, too. It's not always the case - some ENUM vendors consolidate the separate datab= ases into one ENUM interface, so you query one server for all purposes. Bu= t in the back-end behind-the-scenes that ENUM query makes the server end up= doing dips into separate databases for you, or you're given a different ro= ot name depending purposes of the query, and they use that to know what you= want. (some ENUM server vendors present a DNS protocol interface for queri= es, but store their data in a very different format/structure from DNS) -hadriel BTW, for the "unusued" case, it CANNOT be a separate RR or domain name pref= ix or anything - because by definition you have to get it back when you do = a "normal" enum NAPTR query. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Fri Mar 26 09:21:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6418C3A6BB4 for ; Fri, 26 Mar 2010 09:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.876 X-Spam-Level: X-Spam-Status: No, score=0.876 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKMjevJrQMRZ for ; Fri, 26 Mar 2010 09:21:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4F32D3A6B7F for ; Fri, 26 Mar 2010 09:17:27 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2QGHmZt013694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Mar 2010 11:17:50 -0500 Message-ID: <4BACDE2B.5090707@softarmor.com> Date: Fri, 26 Mar 2010 11:17:47 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Otmar Lendl References: <4BABCCAA.2000502@softarmor.com> <4BAC54BB.2020207@nic.at> In-Reply-To: <4BAC54BB.2020207@nic.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: e2md@ietf.org Subject: Re: [e2md] alt-CNAM: What's wrong with _displayname prefixed TXT records? X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:21:04 -0000 Otmar Lendl wrote: > Dean, > > On 25.03.2010 21:50, Dean Willis wrote: >> 1) _prefix approaches do not work well with wildcards. This doesn't >> appear to be a problem for "calling name", as the use case requires a >> terminal fully-specified phone number for looking up the calling name. > > Yes, the calling number is always a specific string of digits. > > In Germany and Austria with their open dialing plans the carrier only knows > to which customer the base number is associated with. The carrier does not > know which extension do exist and what length they are. > > So unless the carrier delegates the ENUM space to the customer, the carrier > has to work with wildcards for cnam in these cases. > > Prefixes just do not work with open numbering plans. Okay, that wraps that approach up. That leaves "some other resource record" -- either a new one, or some other existing record that doesn't normally appear alongside a phone number in the tree so we "knoww" it's for calling name, or that has a subtype field inside it like NAPTR. Assuming we don't use NAPTR because we want the calling-name queries to happen independently of the routing queries, how about NINFO? -- Dean From dean.willis@softarmor.com Fri Mar 26 09:30:15 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F6F3A6C86 for ; Fri, 26 Mar 2010 09:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.882 X-Spam-Level: X-Spam-Status: No, score=0.882 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp61VHGZJInW for ; Fri, 26 Mar 2010 09:30:15 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C80A23A6B62 for ; Fri, 26 Mar 2010 09:25:02 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2QGPLO4013787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Mar 2010 11:25:23 -0500 Message-ID: <4BACDFEF.20307@softarmor.com> Date: Fri, 26 Mar 2010 11:25:19 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:30:15 -0000 Cartwright, Kenneth wrote: > Exactly. And there are of course extremely good reasons why one must > usually ultimately go to different "resolution" server(s) to lookup > data like CNAM. First and foremost, the calling name data is usually > collected and consolidated and managed and offered up by a separate > company or organization whose business it is to do that. So how do you find out what server to query? Is there something like an indirection record in the DNS, or is it just a matter of configuring your systems to query against different roots for different sorts of information? I'm pretty sure it's the latter, but I'm fishing for some kind of reason why we're using "the DNS" instead of having an entirely independent protocol and operations framework that just sort of works like the DNS. If we were doing the latter, I'm pretty sure we would not get so much micromanagement from the appointed guardians of the DNS. This might make our lives a whole lot easier. -- Dean From kcartwright@tnsi.com Fri Mar 26 11:00:41 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E633A6B6A for ; Fri, 26 Mar 2010 11:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.948 X-Spam-Level: ** X-Spam-Status: No, score=2.948 tagged_above=-999 required=5 tests=[AWL=-1.517, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DotNfETfymee for ; Fri, 26 Mar 2010 11:00:40 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id D34173A6B5B for ; Fri, 26 Mar 2010 11:00:39 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41876824; Fri, 26 Mar 2010 14:00:52 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Mar 2010 14:00:52 -0400 From: "Cartwright, Kenneth" To: Dean Willis Date: Fri, 26 Mar 2010 14:00:50 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrNAPtu8EwRiV6TQ2unsgzBAuUCRwABC09A Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> In-Reply-To: <4BACDFEF.20307@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: E.164, list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:00:41 -0000 Different organizations use different CNAM data providers. So they configu= re their systems to access the CNAM data source that they have decided/agre= ed/contracted/paid to use (if any). However, it would of course be good if= that data could be looked up and structured in a standard form, which is t= he goal of the CNAM proposal. You're exactly right. And because many of t= hose organizations already use ENUM for other VoIP related lookups, having = the technology for the CNAM lookup be very similar to ENUM is a no brainer.= (And to draw an analogy, in the "legacy" SS7 world TCAP, which is used fo= r SS7 call routing, is also used to lookup CNAM data, using an SS7 message = that is sent specifically to lookup CNAM data. Iow, they did not invent som= e completely different query/response protocol outside of TCAP just to look= up CNAM data. That would have been overkill.). The CNAM proposal is necessary and is not really about "The DNS" imo. And = the notion that these proposals are about "The DNS" got much of the BOF dis= cussions way off track imo. From my point of view, these proposals are abo= ut using DNS related technologies (DDDS, domain names, NAPTR RRs) to lookup= data about TNs. Organizations already lookup CNAM data using E2U today an= d would like to do it in a standardized way. And, believe me, the organiza= tions that serve up CNAM data today know how to "keep it safe". And while = it would definitely be useful to have further technical tools in the standa= rd toolkit around E2U/DDDS/E2M to allow it to be "kept safe" in a more stan= dard or elegant fashion, ***that is a broader subject and should definitely= be handled as a separate discussion track***. The "unused" proposal would also be a very useful tool to have in the toolk= it. The improvements that I would like to see added into the technology toolkit= around E2U/E2M/DDDS are: 1) The ability to, in the resolution request, to specify which serviceType-= SubType pairs the querier is interested in. This is useful for more than o= ne reason (allowing a specific querier to vary the content of their respons= e per query, without requiring them to use a different root domain). Right= now this is done via other means, some of which Hadriel has described. Bu= t, again, ***this item is a broader subject and should definitely be handle= d as a separate discussion track***. 2) The ability to determine the "source" of the query in a standardized man= ner. Hadriel has a proposal out there on a way to do this. But, again, **= *this is a broader subject and should definitely be handled as a separate d= iscussion track***. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, March 26, 2010 12:25 PM To: Cartwright, Kenneth Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list Subject: Re: [e2md] alt structure suggested for CNAM Cartwright, Kenneth wrote: > Exactly. And there are of course extremely good reasons why one must > usually ultimately go to different "resolution" server(s) to lookup > data like CNAM. First and foremost, the calling name data is usually > collected and consolidated and managed and offered up by a separate > company or organization whose business it is to do that. So how do you find out what server to query? Is there something like an indirection record in the DNS, or is it just a matter of configuring your systems to query against different roots for different sorts of information? I'm pretty sure it's the latter, but I'm fishing for some kind of reason why we're using "the DNS" instead of having an entirely independent protocol and operations framework that just sort of works like the DNS. If we were doing the latter, I'm pretty sure we would not get so much micromanagement from the appointed guardians of the DNS. This might make our lives a whole lot easier. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From mmaharishi@tnsi.com Fri Mar 26 11:00:42 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06213A6B5B for ; Fri, 26 Mar 2010 11:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.338 X-Spam-Level: * X-Spam-Status: No, score=1.338 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BJo0t2hT8tn for ; Fri, 26 Mar 2010 11:00:41 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id F0A673A6B5E for ; Fri, 26 Mar 2010 11:00:40 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.41876831; Fri, 26 Mar 2010 14:01:01 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Fri, 26 Mar 2010 14:01:01 -0400 From: "Maharishi, Manjul" To: Dean Willis , "Cartwright, Kenneth" Date: Fri, 26 Mar 2010 14:01:00 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrNAbJveZvb46AaTMa85GPYq1yjFgACqi1g Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> In-Reply-To: <4BACDFEF.20307@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 18:00:42 -0000 >> So how do you find out what server to query? Is there something like an = indirection record in the DNS, or is it just a matter of configuring your s= ystems to query against different roots for different sorts of information? >> I'm pretty sure it's the latter,.... Yes, indeed, it is the latter. That is not to say that the same server CANN= OT provide you with more than just the CNAM service. However, it should not= be a requirement for the same server to provide *all* possible kinds of da= ta. Like I mentioned in one of my posts earlier this week, it could be upto= the ENUM server vendor to decide which of the data it supports, and accord= ingly advise its querying nodes. You can have multiple different trees and = servers each of which could be supporting different sets of data. Manjul -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dea= n Willis Sent: Friday, March 26, 2010 12:25 PM To: Cartwright, Kenneth Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] alt structure suggested for CNAM Cartwright, Kenneth wrote: > Exactly. And there are of course extremely good reasons why one must > usually ultimately go to different "resolution" server(s) to lookup > data like CNAM. First and foremost, the calling name data is usually > collected and consolidated and managed and offered up by a separate > company or organization whose business it is to do that. So how do you find out what server to query? Is there something like an ind= irection record in the DNS, or is it just a matter of configuring your syst= ems to query against different roots for different sorts of information? I'm pretty sure it's the latter, but I'm fishing for some kind of reason wh= y we're using "the DNS" instead of having an entirely independent protocol = and operations framework that just sort of works like the DNS. If we were doing the latter, I'm pretty sure we would not get so much micro= management from the appointed guardians of the DNS. This might make our liv= es a whole lot easier. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Fri Mar 26 13:38:21 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F093A6B9B for ; Fri, 26 Mar 2010 13:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8z8sUNxN1vG for ; Fri, 26 Mar 2010 13:38:19 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 63F203A68C2 for ; Fri, 26 Mar 2010 13:38:19 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2QKcbSQ015745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Mar 2010 15:38:39 -0500 Message-ID: <4BAD1B4D.7020102@softarmor.com> Date: Fri, 26 Mar 2010 15:38:37 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" , Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [e2md] Draft minutes for E2MD BOF X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 20:38:22 -0000 Draft Minutes for E2MD at IETF 77 based on notes by John Elwell Jabber session scribed by Patrik Falstrom edited by Bernie Höneisen, Dean Willis Meeting started approximately 10 minute late due to delay in room exit by prior group and equipment problems. Both chair's personal computers kernel-paniced on connecting to the projector, and an attendees' machine was pressed into service. Subsequently, the cord fell out of the main microphone. Chairs verbally reviewed "Note Well" and agenda, but did not present related slides due to equipment delay. Chair declared that the question for today's meeting was whether we should form a working group to solve the problems that will be discussed today using the general approach of a new DDDS based on ENUM. Chair noted prior guidance from the IESG is that such a specification would need to be written as if it were to be used on the public Internet, even though use in private networks is more common. AD Cullen Jennings declared that this was not necessarily the case, and the group should first decide what it wants to do. John Klensin suggested that if the work result is not intended for the public Internet then it should be renamed, because a name like E2MD implies a parallel to ENUM, which really was intended for the public Internet during its conceptualization phase. The chairs stated that the basic idea is similar to ENUM, but instead of mapping the E.164 number to a URI that identifies the resource labeled by the E.164 number, we are mapping the E.164 number to information about that phone number. Topic: Problem Statement and Use Cases led by Bernie Höneisen Slides presented reviewed several use cases under discussion: * "unused" use case introduced by Bernie * "send-n" use case introduced by Ray Bellis * "cnam" use case introduced by Richard Shockey * "Global Service Provider Identifier" use case introduced by Bernie Noted that the ENUM working group agreed a draft on the CNAM use case, and that the DRINKS working group earlier this week had discussed mechanisms for provisioning a global service provider identifier. Jon Peterson asked: What is metadata? These 3 use cases are all rather different - is there really anything in common? Debate ensued, with the one commonality noted that all the data in question has in common that it is keyed by the E.164 number and might be needed either when starting or accepting a session using that E.164 number as its target or source. Bernie noted that ENUM had different kinds and classes of ENUM services, and had provided a classification mechanism as part of the IANA registration document. Ray Bellis responded, discussing the relationships between the send-n and unused cases with ENUM. Both send-n and unused are helpful in resolving ENUM lookups and need to be done in conjunction with the ENUM lookup, literally at the same time. John Klensin challenged the assumption that the DNS is a good place to keep this data, noting that we have a lot of other information that mighte be keyed by the phone number but that we do not store in the DNS. Further, storing data in the DNS with record types that lead to a potential for contradictions or unclear semantics gives a potential for abuse of the DNS. We will need to be able to say why each piece of metadata is important enough to put it into the DNS, Bernie noted that the DNS is a good way of distributing the responsibility, and that the delegation structures and relationships of the metadata in question are identical to those of ENUM. Dean reported that John's question had already been discussed on the mailing list, and the sense of mailing list was that we already have the phone number keyed structure from ENUM and we need the same hierarchical and caching characteristics, so any new protocol would need 90% functionality of DNS making it not worth inventing something new. Peter Koch noted that CNAM is rather different from the other use cases. For send-n, he doesn't believe that the problems with the proposal are removed by using E2MD rather than ENUM -- that it makes no difference what the string in NAPTR is. He suggested that killing the whole dependency on ENUM stuff and doing a roll-over not based on NAPTR may be a better approach. Olaf Kolkman agreed that the ENUM tree matches well with hierarchy, but wondered what form of query/search systems might be needed. For example, if we need to search for metadata with a specific number, it might be better to have a service just for that. He suggested that it might be good idea to look for different tools for this problems. Dean noted that this had come up in on-list discussion, and that the later discussion would touch on using E2MD to find a URI for a metadata service. Dean noted that the existing use cases had been debated on the list and that the list felt that DNS was a good match for these use cases, but that we would need to provide guidance on evaluating future use cases as. John Klensin noted that when we did the ENUM work, we mapped phone numbers to DNS for a a specific reason, but assumption that numbers were well matched to DNS would be wrong. The inverse ordering model creates a vast number of DNS hierarchy levels and is not particularly optimal. Richard Shockey responded that ENUM does work well, and is deployed in a number of trees. Practical experience shows that it would work equally well for other types of data. Jon Peterson noted that ENUM kept running into security properties, and the constraints in E2MD may prove to be even more restrictive. Richard Shockey noted that there are many successful ENUM deployments in private environments, and that this resolves most of the security issues. Andrew Sullivan suggested that the problem is that there a tiny part of DNS that is not a good fit, but if that is an important part, then we should reconsider using DNS as the basis for E2MD. Topic: Issues from List led by Dean Willis Issue: DNS record size. List discussion agrees that the E2MD space in DNS is size constrained, and that each use case will have to be analyzed for suityability and unsuitable use casews rejected. further, the group agrees that they will have to produce guidance documents for future reviewers of use cases. Cullen challenged the group to scope this so it would be approvable, apparently asking for the review guidelines to be finalized before the work is done. He proposed a use case of putting a ring-tone into the DNS, and asked how we would evaluate it. Discussion ensued, with some participants maintaining that this is a valid use case, others suggesting that this was a bad idea and that it would perhaps be reasonable to insert a URI that indicates a ring tone. Lawrence Conroy noted (via remote) that an upper bound on size is probably 250 bytes. Issue: Is everything a NAPTR? Jon Peterson observed that this goes beyond just CNAM not being like the others. Why should we use NAPTR, if we have to do some kludge on the data just to make it fit into a NAPTR record Patrick Falstrom noted that there had been a number of problems with NAPTR record with ENUM, so perhaps we shouldn't use it for this, in the same way we should not have for ENUM. Need to see what record types match and perhaps use a better choice, rather than just following ENUM. Jon noted that it is improbable that one RR type would fit all use cases, and that we would therefore have to look at each use case separately. This suggests that we do not need an overall framework for metadata, but should charter work for individual metadata use cases. Discussion moved onto response filtering and aggregation. Spencer suggested that having a profusion of reseource record types might be even scarier than everything being one NAPTR or one container. Dean noted that multiple RR types might be one approach, and that various other filtering techniques might be applied. For example, the underscore prefixing used with SRV records might give a clue to another possibility. Question: How large are the responses. Dean responded that with many use cases feeding into a NAPTR RR-set we might have very large responses. Dave Crocker observed that our current discussion is about low level implementation choices. We need to or might do lots of different things, but without very specific use cases as goals, we have no way to select an approach. He also berated the group for not having considered underscore prefixes as used in SRV records. Dean noted that we do have 4 specific use cases under discussion, with I-Ds on 3. Bernie stated that about 10 more have been proposed to the list. Jon asked what these use cases have in common? Dean responded that the information is indexed by the phone number and used when eitehr settinh up or answering a call, to which Jon disagreed without further explanation being recorded. David Schwartz noted that the common factor is not "has to do with call routing", since the CNAM proposal clearly doesn't. Issue: Registration Procedure Current document suggests Specification Required (with Expert Review procedures TBD) Cullen supposed that if ENUM were 1st come 1st served, we would not be having this BoF (we would have just done it in ENUM, with the implication that this would have been a Bad Thing). Richard Shockey noted that the proposed process follows ENUM as closely as possible, as the ENUM process has been shown to work. Conclusion: Polls of the Room Poll: Who thinks there is something worth looking it? A lot of people raised hands. Poll: Who thinks DNS is a suitable basis? Dave Crocker declared that since we don't have specific set of problems there is no rationale for deciding whether DNS is the right basis. Chair responded by moving to discussion of specifcuse cases. Poll: Who agrees DNS is suitable for CNAM: 10 for, 3 against. Poll: (asked by Richard) We are debating solutions before we establish a charter.Is this a problem that we in IETF can solve, are there people who would like to fix problems? Response was mixed. Christer asked that if we assumes SIP is the main usage, can we solve CNAM with SIP OPTIONS? Dean responded that it is doable with a SIP event package, and that this approach had been previously suggested. Gonzalo suggested following up with questions from the "How to have a successful BOF" list such as "should a WG with the following charter be formed?" Poll: Who thinks the problem space has been clarified by the current drafts and proposed charter such that we understand the proposed scope? Mixed response. Poll: Are there people who want to solve problem: a fairly large number. Poll: Who has read the proposed charter? A large percentage responded. Poll: Who thinks the proposed charter is close to being usable? Response generally favored the negative. Poll: Who thinks the proposed charter is too vague or proposes an untenable approach? Response generally disagreed that the charter was adequate. Gonzalo observed that we didn't really discuss the charter in this room, and we should have asked the question whether we want to propose a WG based on that charter. The chairs, who thought they had just asked that question, merely nodded in response. John Klensin suggested that we should ask who thinks proposed charter it not ready to go. The chair responded that the question had already been asked, and that more people thought it was not ready to go than thought it was ready to go. Chair's conclusion: The problem scope appears to be clearly defined, but the general solution model of defining an open-ended framework is problematic due to concerns about review and approval, and concerns about the general applicability of the ENUM process to encompass the larger metadata problem. Consequently, the proposed charter defines too large a scope. An approach that scales back to solving specific metadata issues one at a time may be more sustainable. Alternately, a solution that strongly revises (or replaces) ENUM might be better tolerated by the community. From dean.willis@softarmor.com Fri Mar 26 13:59:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843953A6A70 for ; Fri, 26 Mar 2010 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.869 X-Spam-Level: X-Spam-Status: No, score=0.869 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnYRekROT2sd for ; Fri, 26 Mar 2010 13:59:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A2E2E3A68B3 for ; Fri, 26 Mar 2010 13:59:16 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2QKxc5s015914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 26 Mar 2010 15:59:40 -0500 Message-ID: <4BAD2039.3030502@softarmor.com> Date: Fri, 26 Mar 2010 15:59:37 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "E.164 To MetaData BOF discussion list" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 20:59:19 -0000 One of the most divisive points for our recent BOF was along the relationship between E2MD, ENUM, and the DNS. Many in our community have asserted that what we're doing has nothing to do with the DNS other than the fact that it shares some protocol machinery, and that therefore the people who consider themselves guardians of the DNS shouldn't be worried about it. In the other camp, people assert that we have no way to extend the protocol machinery of ENUM without actually extending the protocol machinery of the DNS, and that extensions to the protocol machinery of 22the DNS have to be very carefully considered because experience shows that they WILL be used outside of their original conceptual model, meaning that anything we add for E2MD is very likely to show up somewhere in the Internet's core name resolution service, therefore we need to be very careful as to how we extend it. Much of this goes back to the original argument for ENUM, and yes, I was there for the first BOF on the topic. ENUM was originally intended as a way to make telephone numbers accessible ON THE INTERNET. It had NOTHING AT ALL to do with routing telephone calls in private networks, and everything to do with two end-user nodes on the Internet finding each other in order to talk. Consequently, a certain awkwardness in the join between E.164 and DNS was acceptable to the community. It just "had to be that way" to kludge the two together, as we couldn't find a better alternative at the time. Surely nobody thinks that treating every digit of a phone number as a subdomain of the digit before it is optimal. It works, it has good expressive properties, but it really isn't an efficient database tolopogy. But we use it precisely because it works with the DNS, and the DNS is where we need this sort of name-locator resolver on today's Internet. But now we're talking about what are for all practical purposes non-internet usages of the DNS protocol as a high-speed data retrieval mechanism for data keyed by phone numbers. We do not consult "the DNS" and let its resolution function find the right place to ask. Rather, we know a priori exactly which server to ask a given question, and we use the DNS query protocol as a high-speed access to that server's database. we have different servers to ask different questions; one for ENUM, another for CNAM, another for egress routes within our own domains, etc, We blithely ignore much of the operational guidance of the DNS, because it really doesn't apply to our case. Folks, please understand that it is not just John, Alan, and Jon that are blocking us. The greater body of the IETF, if they understood what we are proposing, would reject it out-of-hand. This doesn't mean that what we want to do is bad or not needed; it just means that doing it inside the DNS in the IETF is not a politically tenable approach. If we want to get this specified in the IETF, then I believe we're going to have to find a different approach. -- Dean From HKaplan@acmepacket.com Fri Mar 26 20:15:49 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251FD3A6C61 for ; Fri, 26 Mar 2010 20:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X+XpfjPFa-H for ; Fri, 26 Mar 2010 20:15:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 18F063A67A2 for ; Fri, 26 Mar 2010 20:15:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 26 Mar 2010 23:16:12 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 26 Mar 2010 23:16:06 -0400 From: Hadriel Kaplan To: Dean Willis , "Cartwright, Kenneth" Date: Fri, 26 Mar 2010 23:16:04 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrNAP3OI0VmjOUSQEGn2gdDO486oAAWh2ag Message-ID: <430FC6BDED356B4C8498F634416644A91A79E9269B@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> In-Reply-To: <4BACDFEF.20307@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 03:15:49 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, March 26, 2010 12:25 PM >=20 > So how do you find out what server to query? Is there something like an > indirection record in the DNS, or is it just a matter of configuring > your systems to query against different roots for different sorts of > information? It's provisioned. This stuff isn't stored in "The Internet DNS". -hadriel From eburger@standardstrack.com Sun Mar 28 09:08:46 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22953A67CF for ; Sun, 28 Mar 2010 09:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.641 X-Spam-Level: X-Spam-Status: No, score=0.641 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2cIMl4PTXUo for ; Sun, 28 Mar 2010 09:08:45 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 81FD23A63EB for ; Sun, 28 Mar 2010 09:08:39 -0700 (PDT) Received: from dhcp-wireless-open-abg-27-148.meeting.ietf.org ([130.129.27.148]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Nvv2s-00041p-7L; Sun, 28 Mar 2010 09:09:02 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Eric Burger In-Reply-To: <4BAD2039.3030502@softarmor.com> Date: Sun, 28 Mar 2010 09:09:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 16:08:46 -0000 I hope the logical conclusion from the argument below is NOT that since = many of these use cases could be used on the Internet but will be used = in private networks, the people that want to do this work decide to do = it outside of the IETF. That would be a bad outcome. On Mar 26, 2010, at 1:59 PM, Dean Willis wrote: >=20 > One of the most divisive points for our recent BOF was along the > relationship between E2MD, ENUM, and the DNS. >=20 > Many in our community have asserted that what we're doing has nothing = to > do with the DNS other than the fact that it shares some protocol > machinery, and that therefore the people who consider themselves > guardians of the DNS shouldn't be worried about it. >=20 > In the other camp, people assert that we have no way to extend the > protocol machinery of ENUM without actually extending the protocol > machinery of the DNS, and that extensions to the protocol machinery of > 22the DNS have to be very carefully considered because experience = shows > that they WILL be used outside of their original conceptual model, > meaning that anything we add for E2MD is very likely to show up > somewhere in the Internet's core name resolution service, therefore we > need to be very careful as to how we extend it. >=20 > Much of this goes back to the original argument for ENUM, and yes, I = was > there for the first BOF on the topic. ENUM was originally intended as = a > way to make telephone numbers accessible ON THE INTERNET. It had = NOTHING > AT ALL to do with routing telephone calls in private networks, and > everything to do with two end-user nodes on the Internet finding each > other in order to talk. >=20 > Consequently, a certain awkwardness in the join between E.164 and DNS > was acceptable to the community. It just "had to be that way" to = kludge > the two together, as we couldn't find a better alternative at the = time. > Surely nobody thinks that treating every digit of a phone number as a > subdomain of the digit before it is optimal. It works, it has good > expressive properties, but it really isn't an efficient database > tolopogy. But we use it precisely because it works with the DNS, and = the > DNS is where we need this sort of name-locator resolver on today's = Internet. >=20 >=20 > But now we're talking about what are for all practical purposes > non-internet usages of the DNS protocol as a high-speed data retrieval > mechanism for data keyed by phone numbers. We do not consult "the DNS" > and let its resolution function find the right place to ask. Rather, = we > know a priori exactly which server to ask a given question, and we use > the DNS query protocol as a high-speed access to that server's = database. > we have different servers to ask different questions; one for ENUM, > another for CNAM, another for egress routes within our own domains, = etc, > We blithely ignore much of the operational guidance of the DNS, = because > it really doesn't apply to our case. >=20 >=20 > Folks, please understand that it is not just John, Alan, and Jon that > are blocking us. The greater body of the IETF, if they understood what > we are proposing, would reject it out-of-hand. This doesn't mean that > what we want to do is bad or not needed; it just means that doing it > inside the DNS in the IETF is not a politically tenable approach. If = we > want to get this specified in the IETF, then I believe we're going to > have to find a different approach. >=20 > -- > Dean > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From HKaplan@acmepacket.com Sun Mar 28 09:50:57 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C8A3A68DF for ; Sun, 28 Mar 2010 09:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.282 X-Spam-Level: X-Spam-Status: No, score=0.282 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5sAIR92woPM for ; Sun, 28 Mar 2010 09:50:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BC7BE3A67AB for ; Sun, 28 Mar 2010 09:50:56 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 28 Mar 2010 12:51:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 28 Mar 2010 12:51:19 -0400 From: Hadriel Kaplan To: Eric Burger , Dean Willis Date: Sun, 28 Mar 2010 12:51:20 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrOkRMJyM8wwYmeQ2SRbnh+K5RzwgABKKbQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> In-Reply-To: <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 16:50:57 -0000 No, I would agree that would be bad - instead, a few of us have been talkin= g about possibly offering a Plan-B to the IETF: a separate database for ENU= M. Same protocol on the wire, but for a different port number than 53, and onl= y for E.164 to Foo resolution, not domain names. Whether there'd be a glob= al root or not is debatable, but we'd split out from The DNS. That way we could have unused, send-N, cnam, source-uri, and anything else = we actually need for ENUM but that the IETF is concerned about adding to Th= e DNS. -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Eric Burger > Sent: Sunday, March 28, 2010 12:09 PM > To: Dean Willis >=20 > I hope the logical conclusion from the argument below is NOT that since > many of these use cases could be used on the Internet but will be used in > private networks, the people that want to do this work decide to do it > outside of the IETF. >=20 > That would be a bad outcome. >=20 From Ray.Bellis@nominet.org.uk Sun Mar 28 10:37:43 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 142C73A65A6 for ; Sun, 28 Mar 2010 10:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.143 X-Spam-Level: X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARxnD9CMW0Ak for ; Sun, 28 Mar 2010 10:37:41 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 3D7083A6765 for ; Sun, 28 Mar 2010 10:37:40 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=Xh8TEbOKjp7qu3gKF+OUONSBWblsIa5FbUcYQ7Ojp9PdEex4B7ppcspo o+6ODRrcdTeHpD6P9lILYWSgrF6hMTkVGCqk337zH8znVka5dqKVQoodE qSOBJhC74ggwbzd; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269797888; x=1301333888; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20E2MD,=20ENUM,=20and=20the=20DNS:=20why=20our=20approa ch=20is=20stalling|Date:=20Sun,=2028=20Mar=202010=2018:38 :04=20+0100|Message-ID:=20|To:=20Hadriel =20Kaplan=20|Cc:=20"E.164=20To=20 MetaData=20BOF=20discussion=20list"=20 |MIME-Version:=201.0|In-Reply-To:=20<430FC6BDED356B4C8498 F634416644A91A79E926F2@mail>|References:=20<4BAA4248.2050 601@softarmor.com>=09<02098184-D7B9-4CFB-B522-B3F16D8EF6C 2@rfc1035.com>,=0D=0A=09<4BAA739B.2000609@softarmor.com> =09<754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-N A.win2k.corp.tnsi.com>=0D=0A=09<4BAA88CE.3030904@softarmo r.com>=09<430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail >=0D=0A=09<754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS -MAIL-NA.win2k.corp.tnsi.com>=0D=0A=09<4BACDFEF.20307@sof tarmor.com>=09<754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5 @TNS-MAIL-NA.win2k.corp.tnsi.com>=0D=0A=09<4BAD2039.30305 02@softarmor.com>=09<9AA6E358-4BEE-4A64-BA33-A94840AAEFB2 @standardstrack.com>=20<430FC6BDED356B4C8498F634416644A91 A79E926F2@mail>; bh=0E/8wyqC1Xx/8G584ac6LxFhQDPdN/odcTMN8tB9GzE=; b=emscNlP/l4JdI1L2yT6YDjjXdJLi8dbUQyT+hYvhyTXcpQUrSAcq4Sgx E31WQcfEj8EsVZL0ZcehfbikacI8WDpL7cMKDg/9kBDWPIPGsI6aSSh97 u3LUdbYB0kWwWl2; X-IronPort-AV: E=Sophos;i="4.51,323,1267401600"; d="scan'208";a="22950898" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 28 Mar 2010 18:38:06 +0100 In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Sun, 28 Mar 2010 18:38:04 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 28/03/2010 06:38:05 PM, Serialize complete at 28/03/2010 06:38:05 PM Content-Type: multipart/alternative; boundary="=_alternative 0060DEC6802576F4_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 17:37:43 -0000 This is a multipart message in MIME format. --=_alternative 0060DEC6802576F4_= Content-Type: text/plain; charset="US-ASCII" > No, I would agree that would be bad - instead, a few of us have been > talking about possibly offering a Plan-B to the IETF: a separate > database for ENUM. > Same protocol on the wire, but for a different port number than 53, > and only for E.164 to Foo resolution, not domain names. Whether > there'd be a global root or not is debatable, but we'd split out from The DNS. > > That way we could have unused, send-N, cnam, source-uri, and > anything else we actually need for ENUM but that the IETF is > concerned about adding to The DNS. Ultimately as a DNS head I simply canott support this - the idea of what _would_ in effect be an alternate DNS root is anathema to me. Ray --=_alternative 0060DEC6802576F4_= Content-Type: text/html; charset="US-ASCII"
> No, I would agree that would be bad - instead, a few of us have been
> talking about possibly offering a Plan-B to the IETF: a separate
> database for ENUM.
> Same protocol on the wire, but for a different port number than 53,
> and only for E.164 to Foo resolution, not domain names.  Whether
> there'd be a global root or not is debatable, but we'd split out from The DNS.
>
> That way we could have unused, send-N, cnam, source-uri, and
> anything else we actually need for ENUM but that the IETF is
> concerned about adding to The DNS.
Ultimately as a DNS head I simply canott support this - the idea of what _would_ in effect be an alternate DNS root is anathema to me.

Ray
--=_alternative 0060DEC6802576F4_=-- From Ray.Bellis@nominet.org.uk Sun Mar 28 10:40:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BA33A67E9 for ; Sun, 28 Mar 2010 10:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.167 X-Spam-Level: X-Spam-Status: No, score=-5.167 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngjSPjqWo7LK for ; Sun, 28 Mar 2010 10:40:27 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 7C9A63A65A6 for ; Sun, 28 Mar 2010 10:40:27 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=V2EZATHMotC98LVfygtNKtDNMV5c1bIxsR5Q93IYxDDFFvZCdqnVK6Ko 5k9iKvDshswdju76qixIoN7mqBkLir7CDl0BzwLf+nzFNh6HpBprsHNX4 mbBisFGZ1XvgTO5; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269798054; x=1301334054; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20E2MD,=20ENUM,=20and=20the=20DNS:=20why=20our=20approa ch=20is=20stalling|Date:=20Sun,=2028=20Mar=202010=2018:40 :52=20+0100|Message-ID:=20|To:=20"E.164 =20To=20MetaData=20BOF=20discussion=20list"=20|MIME-Version:=201.0|In-Reply-To:=20 |References:=20<4BAA4248.2050601@softarmor.com>=09<020981 84-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>,=0D=0A=09<4BA A739B.2000609@softarmor.com>=09<754963199212404AB8E9CFCA6 C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com>=0D=0A =09<4BAA88CE.3030904@softarmor.com>=09<430FC6BDED356B4C84 98F634416644A91A79CD1EC2@mail>=0D=0A=09<754963199212404AB 8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com >=0D=0A=09<4BACDFEF.20307@softarmor.com>=09<7549631992124 04AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi .com>=0D=0A=09<4BAD2039.3030502@softarmor.com>=09<9AA6E35 8-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com>=0D=0A =09<430FC6BDED356B4C8498F634416644A91A79E926F2@mail>=20; bh=slABs+Dap+/DGH6UA7aTM2qJgAZ7II9XVRJtzgvqTtE=; b=iDWHHf+eB1ThbUqXSAQhRKW/CCNYPt/Km7sAsrK5RLPW69W14tdfaMtp 4KTSOAu6r1NHohfbgt5sCTI6KqoKgEirGN8urtNDdn+KlLkhy46wcSh4y SVsIBwwOHXzc9b1; X-IronPort-AV: E=Sophos;i="4.51,323,1267401600"; d="scan'208";a="22950986" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 28 Mar 2010 18:40:53 +0100 In-Reply-To: References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> To: "E.164 To MetaData BOF discussion list" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Sun, 28 Mar 2010 18:40:52 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 28/03/2010 06:40:52 PM, Serialize complete at 28/03/2010 06:40:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0061204C802576F4_=" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 17:40:29 -0000 This is a multipart message in MIME format. --=_alternative 0061204C802576F4_= Content-Type: text/plain; charset="US-ASCII" > canott Wow, jetlag does weird things :( Ray --=_alternative 0061204C802576F4_= Content-Type: text/html; charset="US-ASCII" > canott

Wow, jetlag does weird things :(

Ray
--=_alternative 0061204C802576F4_=-- From HKaplan@acmepacket.com Sun Mar 28 10:44:10 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6BB3A68B2 for ; Sun, 28 Mar 2010 10:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiK0fYuMkfN7 for ; Sun, 28 Mar 2010 10:44:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id DC7E33A67E9 for ; Sun, 28 Mar 2010 10:44:06 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sun, 28 Mar 2010 13:44:32 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 28 Mar 2010 13:44:32 -0400 From: Hadriel Kaplan To: "Ray.Bellis@nominet.org.uk" Date: Sun, 28 Mar 2010 13:44:32 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrOnW3iJXy1h20kTwOGx7mzg427dAAAELJw Message-ID: <430FC6BDED356B4C8498F634416644A91A79E926F4@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79E926F4mail_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 17:44:11 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79E926F4mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think it's an alternate root for DNS. It happens to use the protoc= ol mechanics/syntax of DNS, but it's not used for Domain Name resolution - = just E.164 number resolution. -hadriel ________________________________ From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk] Sent: Sunday, March 28, 2010 1:38 PM To: Hadriel Kaplan Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > No, I would agree that would be bad - instead, a few of us have been > talking about possibly offering a Plan-B to the IETF: a separate > database for ENUM. > Same protocol on the wire, but for a different port number than 53, > and only for E.164 to Foo resolution, not domain names. Whether > there'd be a global root or not is debatable, but we'd split out from The= DNS. > > That way we could have unused, send-N, cnam, source-uri, and > anything else we actually need for ENUM but that the IETF is > concerned about adding to The DNS. Ultimately as a DNS head I simply canott support this - the idea of what _w= ould_ in effect be an alternate DNS root is anathema to me. Ray --_000_430FC6BDED356B4C8498F634416644A91A79E926F4mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I don’t think it’s an alternate root for DNS.  It happens to use the protocol mechanics/synt= ax of DNS, but it’s not used for Domain Name resolution - just E.164 num= ber resolution.

 

-hadriel

 

From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]
Sent: Sunday, March 28, 2010= 1:38 PM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 


> No, I would agree that would be bad - instead, a few of us have been
> talking about possibly offering a Plan-= B to the IETF: a separate
> database for ENUM.
> Same protocol on the wire, but for a different port number than 53,
> and only for E.164 to Foo resolution, n= ot domain names.  Whether
> there'd be a global root or not is deba= table, but we'd split out from The DNS.
>
> That way we could have unused, send-N, = cnam, source-uri, and
> anything else we actually need for ENUM= but that the IETF is
> concerned about adding to The DNS.

Ul= timately as a DNS head I simply canott support this - the idea of what _would_ in ef= fect be an alternate DNS root is anathema to me.

Ra= y

--_000_430FC6BDED356B4C8498F634416644A91A79E926F4mail_-- From lconroy@insensate.co.uk Sun Mar 28 12:44:46 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06AE3A6800 for ; Sun, 28 Mar 2010 12:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkHm3P0XV6JX for ; Sun, 28 Mar 2010 12:44:46 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 441F93A6956 for ; Sun, 28 Mar 2010 12:44:32 -0700 (PDT) Received: from [127.0.0.1] (unknown [127.0.0.3]) by insensate.co.uk (Postfix) with ESMTP id 2147511ABF2; Sun, 28 Mar 2010 20:44:58 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> Date: Sun, 28 Mar 2010 20:44:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 19:44:46 -0000 Hi Eric, folks, Wasn't that the intent? I don't have any other logical interpretation I can put on this thread. The alternatives of being forced to use other ports, or doing anything like that, is absurd, and evil (i.e. bad and wrong). ENUM works quite nicely on the DNS on port 53, despite the surreal and/or doom laden air. But it doesn't gain traction in the IETF. As Dean says, it takes a people to make a pope (or three). We are not the people, ergo ... all the best, Lawrence On 28 Mar 2010, at 17:09, Eric Burger wrote: > I hope the logical conclusion from the argument below is NOT that = since many of these use cases could be used on the Internet but will be = used in private networks, the people that want to do this work decide to = do it outside of the IETF. >=20 > That would be a bad outcome. >=20 > On Mar 26, 2010, at 1:59 PM, Dean Willis wrote: >=20 >>=20 >> One of the most divisive points for our recent BOF was along the >> relationship between E2MD, ENUM, and the DNS. >>=20 >> Many in our community have asserted that what we're doing has nothing = to >> do with the DNS other than the fact that it shares some protocol >> machinery, and that therefore the people who consider themselves >> guardians of the DNS shouldn't be worried about it. >>=20 >> In the other camp, people assert that we have no way to extend the >> protocol machinery of ENUM without actually extending the protocol >> machinery of the DNS, and that extensions to the protocol machinery = of >> 22the DNS have to be very carefully considered because experience = shows >> that they WILL be used outside of their original conceptual model, >> meaning that anything we add for E2MD is very likely to show up >> somewhere in the Internet's core name resolution service, therefore = we >> need to be very careful as to how we extend it. >>=20 >> Much of this goes back to the original argument for ENUM, and yes, I = was >> there for the first BOF on the topic. ENUM was originally intended as = a >> way to make telephone numbers accessible ON THE INTERNET. It had = NOTHING >> AT ALL to do with routing telephone calls in private networks, and >> everything to do with two end-user nodes on the Internet finding each >> other in order to talk. >>=20 >> Consequently, a certain awkwardness in the join between E.164 and DNS >> was acceptable to the community. It just "had to be that way" to = kludge >> the two together, as we couldn't find a better alternative at the = time. >> Surely nobody thinks that treating every digit of a phone number as a >> subdomain of the digit before it is optimal. It works, it has good >> expressive properties, but it really isn't an efficient database >> tolopogy. But we use it precisely because it works with the DNS, and = the >> DNS is where we need this sort of name-locator resolver on today's = Internet. >>=20 >>=20 >> But now we're talking about what are for all practical purposes >> non-internet usages of the DNS protocol as a high-speed data = retrieval >> mechanism for data keyed by phone numbers. We do not consult "the = DNS" >> and let its resolution function find the right place to ask. Rather, = we >> know a priori exactly which server to ask a given question, and we = use >> the DNS query protocol as a high-speed access to that server's = database. >> we have different servers to ask different questions; one for ENUM, >> another for CNAM, another for egress routes within our own domains, = etc, >> We blithely ignore much of the operational guidance of the DNS, = because >> it really doesn't apply to our case. >>=20 >>=20 >> Folks, please understand that it is not just John, Alan, and Jon that >> are blocking us. The greater body of the IETF, if they understood = what >> we are proposing, would reject it out-of-hand. This doesn't mean that >> what we want to do is bad or not needed; it just means that doing it >> inside the DNS in the IETF is not a politically tenable approach. If = we >> want to get this specified in the IETF, then I believe we're going to >> have to find a different approach. >>=20 >> -- >> Dean >> _______________________________________________ >> e2md mailing list >> e2md@ietf.org >> https://www.ietf.org/mailman/listinfo/e2md >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From dean.willis@softarmor.com Sun Mar 28 23:18:18 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26263A68D7 for ; Sun, 28 Mar 2010 23:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEkqNxcv4oUT for ; Sun, 28 Mar 2010 23:18:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A2D983A681B for ; Sun, 28 Mar 2010 23:18:17 -0700 (PDT) Received: from [192.168.2.101] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2T6Ig6d001085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Mar 2010 01:18:44 -0500 Message-ID: <4BB04669.3070500@softarmor.com> Date: Mon, 29 Mar 2010 01:19:21 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Conroy References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 06:18:19 -0000 Lawrence Conroy wrote: > Hi Eric, folks, > Wasn't that the intent? > I don't have any other logical interpretation I can put on this thread. > > The alternatives of being forced to use other ports, or doing > anything like that, is absurd, and evil (i.e. bad and wrong). > ENUM works quite nicely on the DNS on port 53, despite the surreal > and/or doom laden air. But it doesn't gain traction in the IETF. > I suspect that part of the problem is that ENUM isn't REALLY in "the DNS". Some IETFers probably feel like they bent over backsards to put phone numbers into the scope of the Internet, and then the phone oeprators went and did these private ENUM things (which might use DNS technology but aren't "the DNS"), thereby making a walled-garden even more walled. Why should we do funky things to a core Internet technology in order to facilitate the priavte non-Internet use of somebody who has already proven not to be working on the best interest of the Internet? That said, there are people in the IETF who are interested in providing a high-speed distributed hierarchical database for phone-numbers and related data. However, those people just don't constitue a large enough chunk of the DNS leadership to be able to make changes to the DNS. But a closely-related technology that uses lessons learns fom the DNS but that is itself not the DNS would probably make the metadata problem more attractive to the IETF DNS pundits. -- Dean From jay@nzrs.net.nz Mon Mar 29 01:02:05 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8367D3A62C1 for ; Mon, 29 Mar 2010 01:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjkIPc2xhoU5 for ; Mon, 29 Mar 2010 01:02:04 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A84733A6784 for ; Mon, 29 Mar 2010 01:02:03 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 8A27E2DA368; Mon, 29 Mar 2010 21:02:29 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jME8IBT9I2BA; Mon, 29 Mar 2010 21:02:29 +1300 (NZDT) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 33A372DA34B; Mon, 29 Mar 2010 21:02:28 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-243--515229054 From: Jay Daley In-Reply-To: <4BB04669.3070500@softarmor.com> Date: Mon, 29 Mar 2010 21:02:26 +1300 Message-Id: <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 08:02:05 -0000 --Apple-Mail-243--515229054 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29/03/2010, at 7:19 PM, Dean Willis wrote: > I suspect that part of the problem is that ENUM isn't REALLY in "the = DNS". Some IETFers probably feel like they bent over backsards to put = phone numbers into the scope of the Internet, and then the phone = oeprators went and did these private ENUM things (which might use DNS = technology but aren't "the DNS"), thereby making a walled-garden even = more walled. Why should we do funky things to a core Internet technology = in order to facilitate the priavte non-Internet use of somebody who has = already proven not to be working on the best interest of the Internet? >=20 > That said, there are people in the IETF who are interested in = providing a high-speed distributed hierarchical database for = phone-numbers and related data. However, those people just don't = constitue a large enough chunk of the DNS leadership to be able to make = changes to the DNS. But a closely-related technology that uses lessons = learns fom the DNS but that is itself not the DNS would probably make = the metadata problem more attractive to the IETF DNS pundits. I finally understand where you are coming from! There is so much to = pick up on in your post that this is quite a long response, apologies in = advance for that. 1. ENUM did not originate with carriers trying to pollute the Internet = and the IETF did not bend over backwards to put phone numbers onto the = Internet. Quite the opposite. There was a lot of opposition to ENUM = from ITU types as they saw it as a cunning IETF plot to take over = telephony. =20 There are many public ENUM trees (at the country code level), it is hard = to see what is really more in the DNS than that. The success of ENUM in = a private context is surprising given the original hostility to ENUM = from some carriers, but is not an indication that this is a private = protocol. Carriers are not working against the best interests of the Internet, = they are just trying to bring their experience, their values and their = way of working to the Internet. You might disagree with those but = nobody holds the keys to the Internet, that is the whole point. 2. You are confusing 'the DNS' with 'the IANA root'. You are right to = describe the use of ENUM in private networks as a walled garden but for = the wrong reasons. It is not the private use of an Internet protocol = you should be blaming as that happens everywhere in other contexts. For = example EPP is only ever used within a contractual framework. There is = no such thing as a public EPP server. What is 'walled' about private = ENUM is the data in those trees. What I want from e2md and many others I suspect also want, is to get = that data out into the open. Probably not in the e164.arpa tree but = certainly the public DNS.=20 3. I don't mean to be rude but I don't think you understand DNS at all. = For a start we are not taking about making changes to the DNS at all = because NAPTR already exists. All we are talking about it a standard = data representation within NAPTR. To suggest creating a technology that = is similar to DNS but is not DNS is both impractical as it means an = extraordinary volume of work and unnecessary because DNS and ENUM = already exists. >=20 It appears to me from your statements above that all the various = objections, rat holes, mis-respresentations and distractions that you = have raised on this list are entirely of a political layer-9 origin and = in no way technical. Ironic since it the IETF way that you claim to be = defending. regards Jay >=20 > -- > Dean >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 --Apple-Mail-243--515229054 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = suspect that part of the problem is that ENUM isn't REALLY in "the DNS". = Some IETFers probably feel like they bent over backsards to put phone = numbers into the scope of the Internet, and then the phone oeprators = went and did these private ENUM things (which might use DNS technology = but aren't "the DNS"), thereby making a walled-garden even more walled. = Why should we do funky things to a core Internet technology in order to = facilitate the priavte non-Internet use of somebody who has already = proven not to be working on the best interest of the = Internet?

That said, there = are people in the IETF who are interested in providing a high-speed = distributed hierarchical database for phone-numbers and related data. =  However, those people just don't constitue a large enough chunk of = the DNS leadership to be able to make changes to the DNS. But a =  closely-related technology that uses lessons learns fom the DNS = but that is itself not the DNS would probably make the metadata problem = more attractive to the IETF DNS = pundits.

I finally = understand where you are coming from!  There is so much to pick up = on in your post that this is quite a long response, apologies in advance = for that.

1.  ENUM did not originate with = carriers trying to pollute the Internet and the IETF did not bend over = backwards to put phone numbers onto the Internet.  Quite the = opposite.  There was a lot of opposition to ENUM from ITU types as = they saw it as a cunning IETF plot to take over telephony. =   

There are many public ENUM trees = (at the country code level), it is hard to see what is really more in = the DNS than that.  The success of ENUM in a private context is = surprising given the original hostility to ENUM from some carriers, but = is not an indication that this is a private = protocol.

Carriers are not working against = the best interests of the Internet, they are just trying to bring their = experience, their values and their way of working to the Internet. =  You might disagree with those but nobody holds the keys to the = Internet, that is the whole point.

2. =  You are confusing 'the DNS' with 'the IANA root'.   You are = right to describe the use of ENUM in private networks as a walled = garden but for the wrong reasons.   It is not the private use = of an Internet protocol you should be blaming as that happens everywhere = in other contexts.  For example EPP is only ever used within a = contractual framework.  There is no such thing as a public EPP = server.  What is 'walled' about private ENUM is the data in those = trees.

What I want from e2md and many others I = suspect also want, is to get that data out into the open.  Probably = not in the e164.arpa tree but certainly the public = DNS. 

3.  I don't mean to be rude but = I don't think you understand DNS at all.  For a start we are not = taking about making changes to the DNS at all because NAPTR already = exists.   All we are talking about it a standard data = representation within NAPTR.  To suggest creating a technology that = is similar to DNS but is not DNS is both impractical as it means an = extraordinary volume of work and unnecessary because DNS and ENUM = already exists.

It appears to me = from your statements above that all the various objections, rat holes, = mis-respresentations and distractions that you have raised on this list = are entirely of a political layer-9 origin and in no way technical. =  Ironic since it the IETF way that you claim to be = defending.

regards
Jay


--
Dean


_____________________________= __________________
e2md mailing list
e2md@ietf.org
https://www.ietf.org/ma= ilman/listinfo/e2md


-- 
Jay = Daley
Chief Executive
.nz Registry Services (New = Zealand Domain Name Registry Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840

= --Apple-Mail-243--515229054-- From lendl@nic.at Mon Mar 29 04:36:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3E43A6A2D for ; Mon, 29 Mar 2010 04:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.3 X-Spam-Level: * X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUr4aaH5Kazc for ; Mon, 29 Mar 2010 04:36:02 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 2FB313A68A9 for ; Mon, 29 Mar 2010 04:36:02 -0700 (PDT) Received: from [10.10.0.242] (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 174664CCCE for ; Mon, 29 Mar 2010 13:36:27 +0200 (CEST) Message-ID: <4BB090B8.5050804@nic.at> Date: Mon, 29 Mar 2010 13:36:24 +0200 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: e2md@ietf.org References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 11:36:03 -0000 On 26.03.2010 19:00, Cartwright, Kenneth wrote: > > The improvements that I would like to see added into the technology > toolkit around E2U/E2M/DDDS are: > 1) The ability to, in the resolution request, to specify which > serviceType-SubType pairs the querier is interested in. This is useful > for more than one reason (allowing a specific querier to vary the > content of their response per query, without requiring them to use a > different root domain). Right now this is done via other means, some of > which Hadriel has described. But, again, ***this item is a broader > subject and should definitely be handled as a separate discussion > track***. Unless we tinker with the guts of the DNS architecture, we're limited to the Query-Name, Query-Type and Query-Class triplet. While it's in theory possible to add some magic to certain values of Types or Class, I doubt this is the right path. Then there is the atomicity of RRset to consider. > 2) The ability to determine the "source" of the query in a standardized > manner. Hadriel has a proposal out there on a way to do this. But, > again, ***this is a broader subject and should definitely be handled as > a separate discussion track***. Again, this requirement contradicts one of the core design principles of the DNS architecture. Yes, Hadrian's draft provides an idea on how one could retrofit the DNS to accommodate this wish, but that's a very ugly hack. IMHO we need a requirements document to determine whether the DNS path is the right one. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From jim@rfc1035.com Mon Mar 29 05:28:31 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1B93A6A56 for ; Mon, 29 Mar 2010 05:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[AWL=0.859, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg9I6zQpsGkO for ; Mon, 29 Mar 2010 05:28:25 -0700 (PDT) Received: from hutch.rfc1035.com (router.rfc1035.com [195.54.233.65]) by core3.amsl.com (Postfix) with ESMTP id 678CD3A6891 for ; Mon, 29 Mar 2010 05:28:17 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id B6E85154283D; Mon, 29 Mar 2010 13:28:41 +0100 (BST) Message-Id: <4865EDCE-B063-47C4-A456-9984D0FDB8A4@rfc1035.com> From: Jim Reid To: Otmar Lendl In-Reply-To: <4BB090B8.5050804@nic.at> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 13:28:41 +0100 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB090B8.5050804@nic.at> X-Mailer: Apple Mail (2.936) Cc: e2md@ietf.org Subject: [e2md] CNAM requirements document X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:28:31 -0000 On 29 Mar 2010, at 12:36, Otmar Lendl wrote: > IMHO we need a requirements document to determine whether the DNS > path is > the right one. Amen! And if DNS is not the right path to take, the requirements/use case(s) document should explain why. From Ray.Bellis@nominet.org.uk Mon Mar 29 05:59:36 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FC33A6A1A for ; Mon, 29 Mar 2010 05:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.187 X-Spam-Level: X-Spam-Status: No, score=-5.187 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRf79F8KkA5H for ; Mon, 29 Mar 2010 05:59:35 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by core3.amsl.com (Postfix) with ESMTP id 7FF793A67C0 for ; Mon, 29 Mar 2010 05:59:34 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=bg//3a2qC6qaOLyN9SnLUP3xVYVquo5xalPx1+4f87cSDvgULSrnG98m 7HL2hVyOJHfwdU1GUX6ZOh7aj4Zr8E5S16p/kEHCGnoVjP1EKV/z4hDKm onBCNN1U7mnTOK9; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269867603; x=1301403603; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20E2MD,=20ENUM,=20and=20the=20DNS:=20why=20our=20approa ch=20is=20stalling|Date:=20Mon,=2029=20Mar=202010=2014:00 :01=20+0100|Message-ID:=20|To:=20Jay=20D aley=20|Cc:=20"E.164=20To=20MetaData=20B OF=20discussion=20list"=20|MIME-Version: =201.0|In-Reply-To:=20<1C8477AA-1FB6-4064-B0AB-018049FDD2 4A@nzrs.net.nz>|References:=20<4BAA4248.2050601@softarmor .com>=09<02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com >,=0D=0A=09<4BAA739B.2000609@softarmor.com>=09<7549631992 12404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.t nsi.com>=0D=0A=09<4BAA88CE.3030904@softarmor.com>=09<430F C6BDED356B4C8498F634416644A91A79CD1EC2@mail>=0D=0A=09<754 963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k .corp.tnsi.com>=0D=0A=09<4BACDFEF.20307@softarmor.com>=09 <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.w in2k.corp.tnsi.com>=0D=0A=09<4BAD2039.3030502@softarmor.c om>=09<9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrac k.com>=0D=0A=09=09<4BB04669.3070500@softarmor.com>=20<1C8477 AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz>; bh=t4t98Pv0coV5+PAU1YoM0v/RSoMMfPsQLsWcPa+bhjU=; b=JBwc68H03YYlRL9brkKMfjuDB5WbU4mumvf1gu61JnmJRowDoLLChx/J xSCIRvQAybdcUCQIEqd3sL3UVaI/xx5f7b3iZUXsxDX+myNo7VAe89LPI j0nckjnzKh9o2bL; X-IronPort-AV: E=Sophos;i="4.51,328,1267401600"; d="scan'208";a="22978198" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx3.nominet.org.uk with ESMTP; 29 Mar 2010 14:00:01 +0100 In-Reply-To: <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> To: Jay Daley MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Mon, 29 Mar 2010 14:00:01 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 29/03/2010 02:00:01 PM, Serialize complete at 29/03/2010 02:00:01 PM Content-Type: multipart/alternative; boundary="=_alternative 004769D4802576F5_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:59:36 -0000 This is a multipart message in MIME format. --=_alternative 004769D4802576F5_= Content-Type: text/plain; charset="US-ASCII" > It appears to me from your statements above that all the various > objections, rat holes, mis-respresentations and distractions that > you have raised on this list are entirely of a political layer-9 > origin and in no way technical. I'm 100% convinced that you are correct, and mutterings around the meeting last week back that up. We have some defined use cases, and some undefined ones, all of which fit to a varying degree to the ENUM model and hence within DNS, whether that be public or walled-garden or somewhere in between. Despite the misleading statements made by some, there is no protocol _or_ deployment police for the DNS. The concern of the IESG and IAB should be to ensure interoperability and scalability, and to facilitate standardisation efforts thereto. It should _not_ be for certain members to apparently try to actively _prevent_ the effort simply because some purists simply "don't like" the technology. As yet there has been _no_ sound technical justification against doing this work. All we're hearing is FUD, and even then it's third hand. I do agree that NAPTR is slightly limiting because within DDDS we are unable to query on service type. Well, frankly, that's tough. It's old news. It's how the IETF defined it, and it's pretty much all we've got. However that does not justify blocking future work just because it happens to specify NAPTRs. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 --=_alternative 004769D4802576F5_= Content-Type: text/html; charset="US-ASCII"  
> It appears to me from your statements above that all the various
> objections, rat holes, mis-respresentations and distractions that
> you have raised on this list are entirely of a political layer-9
> origin and in no way technical.

I'm 100% convinced that you are correct, and mutterings around the meeting last week back that up.

We have some defined use cases, and some undefined ones, all of which fit to a varying degree to the ENUM model and hence within DNS, whether that be public or walled-garden or somewhere in between.

Despite the misleading statements made by some, there is no protocol _or_ deployment police for the DNS.  The concern of the IESG and IAB should be to ensure interoperability and scalability, and to facilitate standardisation efforts thereto.  It should _not_ be for certain members to apparently try to actively _prevent_ the effort simply because some purists simply "don't like" the technology.  As yet there has been _no_ sound technical justification against doing this work.  All we're hearing is FUD, and even then it's third hand.

I do agree that NAPTR is slightly limiting because within DDDS we are unable to query on service type.  Well, frankly, that's tough.  It's old news.  It's how the IETF defined it, and it's pretty much all we've got.  However that does not justify blocking future work just because it happens to specify NAPTRs.

kind regards,

Ray

--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211
 --=_alternative 004769D4802576F5_=-- From kcartwright@tnsi.com Mon Mar 29 08:12:48 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427713A6A7D for ; Mon, 29 Mar 2010 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.787 X-Spam-Level: * X-Spam-Status: No, score=1.787 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYsCOLzieowM for ; Mon, 29 Mar 2010 08:12:39 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 1F3823A67A5 for ; Mon, 29 Mar 2010 08:12:38 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42007320; Mon, 29 Mar 2010 11:12:57 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 11:12:57 -0400 From: "Cartwright, Kenneth" To: Hadriel Kaplan , "Ray.Bellis@nominet.org.uk" Date: Mon, 29 Mar 2010 11:12:56 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrOnW3iJXy1h20kTwOGx7mzg427dAAAELJwAC0lo3A= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529B59@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> <430FC6BDED356B4C8498F634416644A91A79E926F4@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E926F4@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B59TNSMAILNAwin2_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:12:48 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B59TNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's also the way I see it. Ken ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Sunday, March 28, 2010 1:45 PM To: Ray.Bellis@nominet.org.uk Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling I don't think it's an alternate root for DNS. It happens to use the protoc= ol mechanics/syntax of DNS, but it's not used for Domain Name resolution - = just E.164 number resolution. -hadriel ________________________________ From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk] Sent: Sunday, March 28, 2010 1:38 PM To: Hadriel Kaplan Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > No, I would agree that would be bad - instead, a few of us have been > talking about possibly offering a Plan-B to the IETF: a separate > database for ENUM. > Same protocol on the wire, but for a different port number than 53, > and only for E.164 to Foo resolution, not domain names. Whether > there'd be a global root or not is debatable, but we'd split out from The= DNS. > > That way we could have unused, send-N, cnam, source-uri, and > anything else we actually need for ENUM but that the IETF is > concerned about adding to The DNS. Ultimately as a DNS head I simply canott support this - the idea of what _w= ould_ in effect be an alternate DNS root is anathema to me. Ray ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B59TNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s also the way I see it.

 

Ken

 

From: e2md= -bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: Sunday, March 28, 2010= 1:45 PM
To: Ray.Bellis@nominet.org.uk
Cc: E.164 To MetaData BOF di= scussion list
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 

 

I don’t think it’s an alte= rnate root for DNS.  It happens to use the protocol mechanics/syntax o= f DNS, but it’s not used for Domain Name resolution - just E.164 number resolution.

 

-hadriel

 

From: Ray.Bellis@nominet.org.uk [mai= lto:Ray.Bellis@nominet.org.uk]
Sent: Sunday, March 28, 2010= 1:38 PM
To: Hadriel Kaplan
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 


> No, I would agree that would be bad - i= nstead, a few of us have been
> talking about possibly offering a Plan-= B to the IETF: a separate
> database for ENUM.
> Same protocol on the wire, but for a di= fferent port number than 53,
> and only for E.164 to Foo resolution, n= ot domain names.  Whether
> there'd be a global root or not is deba= table, but we'd split out from The DNS.
>
> That way we could have unused, send-N, = cnam, source-uri, and
> anything else we actually need for ENUM= but that the IETF is
> concerned about adding to The DNS.

= Ultimately as a DNS head I simply canott support this - the idea of what _w= ould_ in effect be an alternate DNS root is anathema to me.

= Ray


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B59TNSMAILNAwin2_-- From kcartwright@tnsi.com Mon Mar 29 08:25:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7803A6A94 for ; Mon, 29 Mar 2010 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.623 X-Spam-Level: * X-Spam-Status: No, score=1.623 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIfSXZCtf7f1 for ; Mon, 29 Mar 2010 08:25:45 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 96CA13A6A1E for ; Mon, 29 Mar 2010 08:25:13 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42007869; Mon, 29 Mar 2010 11:25:37 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 11:25:37 -0400 From: "Cartwright, Kenneth" To: Jay Daley , Dean Willis Date: Mon, 29 Mar 2010 11:25:36 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPFjQmih1xBni2QkmaHRbaaGVJiQAPTTEw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529B8B@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> In-Reply-To: <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B8BTNSMAILNAwin2_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:25:54 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B8BTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd tend to agree with most of what Jay has said below. The only exception being that my goal of supporting E2U and E2M is not to "= get this data out in the open" (and I'm not entirely sure what you mean by = that), but is instead to enable existing use cases in a more standardized, = and more fully baked manner. Getting data "out in the open" is a more of a policy decision that the IETF= does not really play a role in. But creating technical standards for enab= ling use cases in a more standardized and fully baked fashion is definitely= the role of the IETF. Ken ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay= Daley Sent: Monday, March 29, 2010 4:02 AM To: Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling On 29/03/2010, at 7:19 PM, Dean Willis wrote: I suspect that part of the problem is that ENUM isn't REALLY in "the DNS". = Some IETFers probably feel like they bent over backsards to put phone numbe= rs into the scope of the Internet, and then the phone oeprators went and di= d these private ENUM things (which might use DNS technology but aren't "the= DNS"), thereby making a walled-garden even more walled. Why should we do f= unky things to a core Internet technology in order to facilitate the priavt= e non-Internet use of somebody who has already proven not to be working on = the best interest of the Internet? That said, there are people in the IETF who are interested in providing a h= igh-speed distributed hierarchical database for phone-numbers and related d= ata. However, those people just don't constitue a large enough chunk of th= e DNS leadership to be able to make changes to the DNS. But a closely-rela= ted technology that uses lessons learns fom the DNS but that is itself not = the DNS would probably make the metadata problem more attractive to the IET= F DNS pundits. I finally understand where you are coming from! There is so much to pick u= p on in your post that this is quite a long response, apologies in advance = for that. 1. ENUM did not originate with carriers trying to pollute the Internet and= the IETF did not bend over backwards to put phone numbers onto the Interne= t. Quite the opposite. There was a lot of opposition to ENUM from ITU typ= es as they saw it as a cunning IETF plot to take over telephony. There are many public ENUM trees (at the country code level), it is hard to= see what is really more in the DNS than that. The success of ENUM in a pr= ivate context is surprising given the original hostility to ENUM from some = carriers, but is not an indication that this is a private protocol. Carriers are not working against the best interests of the Internet, they a= re just trying to bring their experience, their values and their way of wor= king to the Internet. You might disagree with those but nobody holds the k= eys to the Internet, that is the whole point. 2. You are confusing 'the DNS' with 'the IANA root'. You are right to de= scribe the use of ENUM in private networks as a walled garden but for the w= rong reasons. It is not the private use of an Internet protocol you shoul= d be blaming as that happens everywhere in other contexts. For example EPP= is only ever used within a contractual framework. There is no such thing = as a public EPP server. What is 'walled' about private ENUM is the data in= those trees. What I want from e2md and many others I suspect also want, is to get that d= ata out into the open. Probably not in the e164.arpa tree but certainly th= e public DNS. 3. I don't mean to be rude but I don't think you understand DNS at all. F= or a start we are not taking about making changes to the DNS at all because= NAPTR already exists. All we are talking about it a standard data repres= entation within NAPTR. To suggest creating a technology that is similar to= DNS but is not DNS is both impractical as it means an extraordinary volume= of work and unnecessary because DNS and ENUM already exists. It appears to me from your statements above that all the various objections= , rat holes, mis-respresentations and distractions that you have raised on = this list are entirely of a political layer-9 origin and in no way technica= l. Ironic since it the IETF way that you claim to be defending. regards Jay -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B8BTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529B8BTNSMAILNAwin2_-- From kcartwright@tnsi.com Mon Mar 29 08:35:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA5E3A6ABF for ; Mon, 29 Mar 2010 08:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.524 X-Spam-Level: * X-Spam-Status: No, score=1.524 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RCi3m1mNMvu for ; Mon, 29 Mar 2010 08:35:34 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id D813F3A6405 for ; Mon, 29 Mar 2010 08:35:33 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42008237; Mon, 29 Mar 2010 11:35:59 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 11:35:59 -0400 From: "Cartwright, Kenneth" To: Otmar Lendl , "e2md@ietf.org" Date: Mon, 29 Mar 2010 11:35:58 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrPNBuPXr7P60x8RqmXItBmhf0tJQAIB60g Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529BAA@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB090B8.5050804@nic.at> In-Reply-To: <4BB090B8.5050804@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:35:35 -0000 I agree that we need a requirements document. Source identification and di= ffering responses based on the source is already being done today on a very= large scale basis, using non-standard schemes. But I'm fully aware that s= ome of the DNS purists feel that this is anathema to DNS. I see both sides= of this, the principled/theoretical points of view and the practical more = immediate term points of view. We have these needs *today* and are solving= these problems *today*. As you probably know, if you have applications in the field you typically n= eed two tracks that you are working, the near term track based on the immed= iate practical needs, *and* the mid to long term track based on a more eleg= ant and broader set of principles and theories. I have to understand appre= ciate both. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Otm= ar Lendl Sent: Monday, March 29, 2010 7:36 AM To: e2md@ietf.org Subject: Re: [e2md] alt structure suggested for CNAM On 26.03.2010 19:00, Cartwright, Kenneth wrote: > > The improvements that I would like to see added into the technology > toolkit around E2U/E2M/DDDS are: > 1) The ability to, in the resolution request, to specify which > serviceType-SubType pairs the querier is interested in. This is useful > for more than one reason (allowing a specific querier to vary the > content of their response per query, without requiring them to use a > different root domain). Right now this is done via other means, some of > which Hadriel has described. But, again, ***this item is a broader > subject and should definitely be handled as a separate discussion > track***. Unless we tinker with the guts of the DNS architecture, we're limited to the Query-Name, Query-Type and Query-Class triplet. While it's in theory possible to add some magic to certain values of Types or Class, I doubt this is the right path. Then there is the atomicity of RRset to consider. > 2) The ability to determine the "source" of the query in a standardized > manner. Hadriel has a proposal out there on a way to do this. But, > again, ***this is a broader subject and should definitely be handled as > a separate discussion track***. Again, this requirement contradicts one of the core design principles of the DNS architecture. Yes, Hadrian's draft provides an idea on how one could retrofit the DNS to accommodate this wish, but that's a very ugly hack. IMHO we need a requirements document to determine whether the DNS path is the right one. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Mon Mar 29 08:38:25 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60CC3A6AB6 for ; Mon, 29 Mar 2010 08:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.366 X-Spam-Level: * X-Spam-Status: No, score=1.366 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVB2xAc7Vp-U for ; Mon, 29 Mar 2010 08:38:18 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 78E273A6AB9 for ; Mon, 29 Mar 2010 08:38:13 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42008363; Mon, 29 Mar 2010 11:38:39 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 11:38:39 -0400 From: "Cartwright, Kenneth" To: "Ray.Bellis@nominet.org.uk" , Jay Daley Date: Mon, 29 Mar 2010 11:38:38 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPP8eWUtucqJTrSUmMUw4aEouApwAFfEkQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529BAF@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA1F69529BAFTNSMAILNAwin2_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:38:26 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529BAFTNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with this Ray's points below. (Is "agreeing" adding value? :), I t= hink so.) Ken ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray= .Bellis@nominet.org.uk Sent: Monday, March 29, 2010 9:00 AM To: Jay Daley Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > It appears to me from your statements above that all the various > objections, rat holes, mis-respresentations and distractions that > you have raised on this list are entirely of a political layer-9 > origin and in no way technical. I'm 100% convinced that you are correct, and mutterings around the meeting = last week back that up. We have some defined use cases, and some undefined ones, all of which fit t= o a varying degree to the ENUM model and hence within DNS, whether that be = public or walled-garden or somewhere in between. Despite the misleading statements made by some, there is no protocol _or_ d= eployment police for the DNS. The concern of the IESG and IAB should be to= ensure interoperability and scalability, and to facilitate standardisation= efforts thereto. It should _not_ be for certain members to apparently try= to actively _prevent_ the effort simply because some purists simply "don't= like" the technology. As yet there has been _no_ sound technical justific= ation against doing this work. All we're hearing is FUD, and even then it'= s third hand. I do agree that NAPTR is slightly limiting because within DDDS we are unabl= e to query on service type. Well, frankly, that's tough. It's old news. = It's how the IETF defined it, and it's pretty much all we've got. However = that does not justify blocking future work just because it happens to speci= fy NAPTRs. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: ray@nominet.org.uk, t: +44 1865 332211 ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529BAFTNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with this Ray’s points b= elow. (Is “agreeing” adding value?  J, = I think so.)

 

Ken

 

From: e2md= -bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ray.Bellis@nomine= t.org.uk
Sent: Monday, March 29, 2010= 9:00 AM
To: Jay Daley
Cc: E.164 To MetaData BOF di= scussion list
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 

 
> It appears to me from your statements a= bove that all the various
> objections, rat holes, mis-respresentat= ions and distractions that
> you have raised on this list are entire= ly of a political layer-9
> origin and in no way technical.<= /tt>

= I'm 100% convinced that you are correct, and mutterings around the meeting = last week back that up.

= We have some defined use cases, and some undefined ones, all of which fit t= o a varying degree to the ENUM model and hence within DNS, whether that be = public or walled-garden or somewhere in between.

= Despite the misleading statements made by some, there is no protocol _or_ d= eployment police for the DNS.  The concern of the IESG and IAB should = be to ensure interoperability and scalability, and to facilitate standardisation efforts thereto.  It should _not_ b= e for certain members to apparently try to actively _prevent_ the effort si= mply because some purists simply "don't like" the technology. &nb= sp;As yet there has been _no_ sound technical justification against doing this work.  All we're hearing is FUD, and even then it'= s third hand.

= I do agree that NAPTR is slightly limiting because within DDDS we are unabl= e to query on service type.  Well, frankly, that's tough.  It's o= ld news.  It's how the IETF defined it, and it's pretty much all we've got.  However that does not justify blocking fu= ture work just because it happens to specify NAPTRs.

= kind regards,

= Ray

= --
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nomi= net
e: ray@nominet.org.uk, t: +44 1865 33221= 1


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529BAFTNSMAILNAwin2_-- From pkyzivat@cisco.com Mon Mar 29 08:47:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2778D3A6891 for ; Mon, 29 Mar 2010 08:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoLRkIGzy8Rj for ; Mon, 29 Mar 2010 08:47:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D25E83A6A79 for ; Mon, 29 Mar 2010 08:46:59 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJNosEtAZnwN/2dsb2JhbACbKnGnaphpglmCKAQ X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="97193838" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2010 15:47:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2TFlRYc029289; Mon, 29 Mar 2010 15:47:27 GMT Message-ID: <4BB0CB8D.4050302@cisco.com> Date: Mon, 29 Mar 2010 11:47:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: E.164@core3.amsl.com, list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:47:04 -0000 I've been keeping out of this, but I just can't any longer... Cartwright, Kenneth wrote: > Different organizations use different CNAM data providers. So they configure their systems to access the CNAM data source that they have decided/agreed/contracted/paid to use (if any). However, it would of course be good if that data could be looked up and structured in a standard form, which is the goal of the CNAM proposal. You're exactly right. And because many of those organizations already use ENUM for other VoIP related lookups, having the technology for the CNAM lookup be very similar to ENUM is a no brainer. (And to draw an analogy, in the "legacy" SS7 world TCAP, which is used for SS7 call routing, is also used to lookup CNAM data, using an SS7 message that is sent specifically to lookup CNAM data. Iow, they did not invent some completely different query/response protocol outside of TCAP just to lookup CNAM data. That would have been overkill.). The above approach seems to be to be entirely contrary to the philosophy behind DNS. At the very least, the server(s) that are authoritative for a given DNS name should be independent of who is asking. I guess that can still be honored by using a distinct ENUM root for the lookup. But then, what is the *meaning* of looking up CNAM for a particular phone number against two different ENUM roots? Are those to be considered two different phone number namespaces, each with its own CNAM, that might potentially differ from the others? I presume not. Apparently what you are saying is that CNAM retrieved from A.B.C.Root1 means the same as from A.B.C.Root2 except that there is different access and different billing for making the query. Is that right? Suppose that were applied to other aspects of DNS, like A records. I think much of the world would (rightfully) go ballistic if that were proposed. Thanks, Paul > The CNAM proposal is necessary and is not really about "The DNS" imo. And the notion that these proposals are about "The DNS" got much of the BOF discussions way off track imo. From my point of view, these proposals are about using DNS related technologies (DDDS, domain names, NAPTR RRs) to lookup data about TNs. Organizations already lookup CNAM data using E2U today and would like to do it in a standardized way. And, believe me, the organizations that serve up CNAM data today know how to "keep it safe". And while it would definitely be useful to have further technical tools in the standard toolkit around E2U/DDDS/E2M to allow it to be "kept safe" in a more standard or elegant fashion, ***that is a broader subject and should definitely be handled as a separate discussion track***. > > The "unused" proposal would also be a very useful tool to have in the toolkit. > > The improvements that I would like to see added into the technology toolkit around E2U/E2M/DDDS are: > 1) The ability to, in the resolution request, to specify which serviceType-SubType pairs the querier is interested in. This is useful for more than one reason (allowing a specific querier to vary the content of their response per query, without requiring them to use a different root domain). Right now this is done via other means, some of which Hadriel has described. But, again, ***this item is a broader subject and should definitely be handled as a separate discussion track***. > 2) The ability to determine the "source" of the query in a standardized manner. Hadriel has a proposal out there on a way to do this. But, again, ***this is a broader subject and should definitely be handled as a separate discussion track***. > > Ken > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, March 26, 2010 12:25 PM > To: Cartwright, Kenneth > Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list > Subject: Re: [e2md] alt structure suggested for CNAM > > Cartwright, Kenneth wrote: >> Exactly. And there are of course extremely good reasons why one must >> usually ultimately go to different "resolution" server(s) to lookup >> data like CNAM. First and foremost, the calling name data is usually >> collected and consolidated and managed and offered up by a separate >> company or organization whose business it is to do that. > > So how do you find out what server to query? Is there something like an > indirection record in the DNS, or is it just a matter of configuring > your systems to query against different roots for different sorts of > information? > > I'm pretty sure it's the latter, but I'm fishing for some kind of reason > why we're using "the DNS" instead of having an entirely independent > protocol and operations framework that just sort of works like the DNS. > If we were doing the latter, I'm pretty sure we would not get so much > micromanagement from the appointed guardians of the DNS. This might make > our lives a whole lot easier. > > -- > Dean > > This e-mail message is for the sole use of the intended recipient(s)and may > contain confidential and privileged information of Transaction Network Services. > Any unauthorised review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From kcartwright@tnsi.com Mon Mar 29 08:48:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FC03A6A75 for ; Mon, 29 Mar 2010 08:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[AWL=1.568, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99fi6jB+G4fJ for ; Mon, 29 Mar 2010 08:48:03 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 931D93A6891 for ; Mon, 29 Mar 2010 08:48:03 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42008783; Mon, 29 Mar 2010 11:48:17 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 11:48:17 -0400 From: "Cartwright, Kenneth" To: Jim Reid , Otmar Lendl Date: Mon, 29 Mar 2010 11:48:16 -0400 Thread-Topic: [e2md] CNAM requirements document Thread-Index: AcrPO3BgHsevLLhkRPaWuZ816XXaZQAG2pvA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529BC4@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB090B8.5050804@nic.at> <4865EDCE-B063-47C4-A456-9984D0FDB8A4@rfc1035.com> In-Reply-To: <4865EDCE-B063-47C4-A456-9984D0FDB8A4@rfc1035.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] CNAM requirements document X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:48:04 -0000 I agree that we need a CNAM "requirements" document. However, I think what= we are talking about should not be just about CNAM. If you were to solve = CNAM in isolation you would do it one way, but if you were to solve it with= in the VoIP/Telecom/Internet ecosystem you would solve it another. Imo, the framework approach, of which DDDS is one, is the correct way to go= . Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jim= Reid Sent: Monday, March 29, 2010 8:29 AM To: Otmar Lendl Cc: e2md@ietf.org Subject: [e2md] CNAM requirements document On 29 Mar 2010, at 12:36, Otmar Lendl wrote: > IMHO we need a requirements document to determine whether the DNS > path is > the right one. Amen! And if DNS is not the right path to take, the requirements/use case(s) document should explain why. _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Mon Mar 29 08:58:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C143A6AA0 for ; Mon, 29 Mar 2010 08:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.569 X-Spam-Level: * X-Spam-Status: No, score=1.569 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMoRdBheOSkf for ; Mon, 29 Mar 2010 08:58:27 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 0DB8D3A6A8E for ; Mon, 29 Mar 2010 08:58:26 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42009107; Mon, 29 Mar 2010 11:58:48 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 11:58:48 -0400 From: "Cartwright, Kenneth" To: Paul Kyzivat Date: Mon, 29 Mar 2010 11:58:46 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrPVyRbB6wXnZxNQXq4o+3tTZr0qgAAERvw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> In-Reply-To: <4BB0CB8D.4050302@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164@core3.amsl.com" , list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:58:28 -0000 I understand your point of view. And CNAM data could theoretically work th= e way you are suggesting (and maybe one day it will). However, that is not= the current business/policy model that underlies much of the CNAM usage sc= enarios. Trying to impose the public domain name lookup business/policy mo= del on all data that could be queried using some of the DNS technologies is= probably not a good stance. I think the technology should not get in the = way of either business model, and the IETF's role, in my opinion, is not to= impose one or the other. Your vision is more purist, which is great and e= legant, but is not the only one and is not necessitated by the technologies= that underlie DNS. Furthermore, there is a lot of meta-data around the public DNS's domain nam= es and domain name data bases that is also only provided to those that eith= er pay for it or have the legal authority to have access to it. Ken -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, March 29, 2010 11:47 AM To: Cartwright, Kenneth Cc: Dean Willis; E.164@core3.amsl.com; list Subject: Re: [e2md] alt structure suggested for CNAM I've been keeping out of this, but I just can't any longer... Cartwright, Kenneth wrote: > Different organizations use different CNAM data providers. So they confi= gure their systems to access the CNAM data source that they have decided/ag= reed/contracted/paid to use (if any). However, it would of course be good = if that data could be looked up and structured in a standard form, which is= the goal of the CNAM proposal. You're exactly right. And because many of= those organizations already use ENUM for other VoIP related lookups, havin= g the technology for the CNAM lookup be very similar to ENUM is a no braine= r. (And to draw an analogy, in the "legacy" SS7 world TCAP, which is used = for SS7 call routing, is also used to lookup CNAM data, using an SS7 messag= e that is sent specifically to lookup CNAM data. Iow, they did not invent s= ome completely different query/response protocol outside of TCAP just to lo= okup CNAM data. That would have been overkill.). The above approach seems to be to be entirely contrary to the philosophy behind DNS. At the very least, the server(s) that are authoritative for a given DNS name should be independent of who is asking. I guess that can still be honored by using a distinct ENUM root for the lookup. But then, what is the *meaning* of looking up CNAM for a particular phone number against two different ENUM roots? Are those to be considered two different phone number namespaces, each with its own CNAM, that might potentially differ from the others? I presume not. Apparently what you are saying is that CNAM retrieved from A.B.C.Root1 means the same as from A.B.C.Root2 except that there is different access and different billing for making the query. Is that right? Suppose that were applied to other aspects of DNS, like A records. I think much of the world would (rightfully) go ballistic if that were proposed. Thanks, Paul > The CNAM proposal is necessary and is not really about "The DNS" imo. An= d the notion that these proposals are about "The DNS" got much of the BOF d= iscussions way off track imo. From my point of view, these proposals are a= bout using DNS related technologies (DDDS, domain names, NAPTR RRs) to look= up data about TNs. Organizations already lookup CNAM data using E2U today = and would like to do it in a standardized way. And, believe me, the organi= zations that serve up CNAM data today know how to "keep it safe". And whil= e it would definitely be useful to have further technical tools in the stan= dard toolkit around E2U/DDDS/E2M to allow it to be "kept safe" in a more st= andard or elegant fashion, ***that is a broader subject and should definite= ly be handled as a separate discussion track***. > > The "unused" proposal would also be a very useful tool to have in the too= lkit. > > The improvements that I would like to see added into the technology toolk= it around E2U/E2M/DDDS are: > 1) The ability to, in the resolution request, to specify which serviceTyp= e-SubType pairs the querier is interested in. This is useful for more than= one reason (allowing a specific querier to vary the content of their respo= nse per query, without requiring them to use a different root domain). Rig= ht now this is done via other means, some of which Hadriel has described. = But, again, ***this item is a broader subject and should definitely be hand= led as a separate discussion track***. > 2) The ability to determine the "source" of the query in a standardized m= anner. Hadriel has a proposal out there on a way to do this. But, again, = ***this is a broader subject and should definitely be handled as a separate= discussion track***. > > Ken > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, March 26, 2010 12:25 PM > To: Cartwright, Kenneth > Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list > Subject: Re: [e2md] alt structure suggested for CNAM > > Cartwright, Kenneth wrote: >> Exactly. And there are of course extremely good reasons why one must >> usually ultimately go to different "resolution" server(s) to lookup >> data like CNAM. First and foremost, the calling name data is usually >> collected and consolidated and managed and offered up by a separate >> company or organization whose business it is to do that. > > So how do you find out what server to query? Is there something like an > indirection record in the DNS, or is it just a matter of configuring > your systems to query against different roots for different sorts of > information? > > I'm pretty sure it's the latter, but I'm fishing for some kind of reason > why we're using "the DNS" instead of having an entirely independent > protocol and operations framework that just sort of works like the DNS. > If we were doing the latter, I'm pretty sure we would not get so much > micromanagement from the appointed guardians of the DNS. This might make > our lives a whole lot easier. > > -- > Dean > > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From pkyzivat@cisco.com Mon Mar 29 09:15:49 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A703A6A7E for ; Mon, 29 Mar 2010 09:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.836 X-Spam-Level: X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq8iD3VCmNaM for ; Mon, 29 Mar 2010 09:15:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AB4063A6A92 for ; Mon, 29 Mar 2010 09:15:27 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJdvsEtAZnwM/2dsb2JhbACbJXGnO5hQglmCKAQ X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="97064182" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2010 16:15:53 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2TGFr8O008335; Mon, 29 Mar 2010 16:15:53 GMT Message-ID: <4BB0D237.7050700@cisco.com> Date: Mon, 29 Mar 2010 12:15:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "E.164@core3.amsl.com" , list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:15:49 -0000 Cartwright, Kenneth wrote: > I understand your point of view. And CNAM data could theoretically work the way you are suggesting (and maybe one day it will). However, that is not the current business/policy model that underlies much of the CNAM usage scenarios. Trying to impose the public domain name lookup business/policy model on all data that could be queried using some of the DNS technologies is probably not a good stance. I think the technology should not get in the way of either business model, and the IETF's role, in my opinion, is not to impose one or the other. Your vision is more purist, which is great and elegant, but is not the only one and is not necessitated by the technologies that underlie DNS. > > Furthermore, there is a lot of meta-data around the public DNS's domain names and domain name data bases that is also only provided to those that either pay for it or have the legal authority to have access to it. And how is the "meta-data around the public DNS's domain names and domain name data bases that is also only provided to those that either pay for it or have the legal authority to have access to it" accessed today? Presumably not via DNS queries. So maybe it would be appropriate to look at how that is dealt with to find a corresponding approach for e2md. Thanks, Paul > Ken > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 29, 2010 11:47 AM > To: Cartwright, Kenneth > Cc: Dean Willis; E.164@core3.amsl.com; list > Subject: Re: [e2md] alt structure suggested for CNAM > > I've been keeping out of this, but I just can't any longer... > > Cartwright, Kenneth wrote: >> Different organizations use different CNAM data providers. So they configure their systems to access the CNAM data source that they have decided/agreed/contracted/paid to use (if any). However, it would of course be good if that data could be looked up and structured in a standard form, which is the goal of the CNAM proposal. You're exactly right. And because many of those organizations already use ENUM for other VoIP related lookups, having the technology for the CNAM lookup be very similar to ENUM is a no brainer. (And to draw an analogy, in the "legacy" SS7 world TCAP, which is used for SS7 call routing, is also used to lookup CNAM data, using an SS7 message that is sent specifically to lookup CNAM data. Iow, they did not invent some completely different query/response protocol outside of TCAP just to lookup CNAM data. That would have been overkill.). > > The above approach seems to be to be entirely contrary to the philosophy > behind DNS. > > At the very least, the server(s) that are authoritative for a given DNS > name should be independent of who is asking. > > I guess that can still be honored by using a distinct ENUM root for the > lookup. But then, what is the *meaning* of looking up CNAM for a > particular phone number against two different ENUM roots? Are those to > be considered two different phone number namespaces, each with its own > CNAM, that might potentially differ from the others? I presume not. > > Apparently what you are saying is that CNAM retrieved from A.B.C.Root1 > means the same as from A.B.C.Root2 except that there is different access > and different billing for making the query. Is that right? > > Suppose that were applied to other aspects of DNS, like A records. I > think much of the world would (rightfully) go ballistic if that were > proposed. > > Thanks, > Paul > >> The CNAM proposal is necessary and is not really about "The DNS" imo. And the notion that these proposals are about "The DNS" got much of the BOF discussions way off track imo. From my point of view, these proposals are about using DNS related technologies (DDDS, domain names, NAPTR RRs) to lookup data about TNs. Organizations already lookup CNAM data using E2U today and would like to do it in a standardized way. And, believe me, the organizations that serve up CNAM data today know how to "keep it safe". And while it would definitely be useful to have further technical tools in the standard toolkit around E2U/DDDS/E2M to allow it to be "kept safe" in a more standard or elegant fashion, ***that is a broader subject and should definitely be handled as a separate discussion track***. >> >> The "unused" proposal would also be a very useful tool to have in the toolkit. >> >> The improvements that I would like to see added into the technology toolkit around E2U/E2M/DDDS are: >> 1) The ability to, in the resolution request, to specify which serviceType-SubType pairs the querier is interested in. This is useful for more than one reason (allowing a specific querier to vary the content of their response per query, without requiring them to use a different root domain). Right now this is done via other means, some of which Hadriel has described. But, again, ***this item is a broader subject and should definitely be handled as a separate discussion track***. >> 2) The ability to determine the "source" of the query in a standardized manner. Hadriel has a proposal out there on a way to do this. But, again, ***this is a broader subject and should definitely be handled as a separate discussion track***. >> >> Ken >> >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Friday, March 26, 2010 12:25 PM >> To: Cartwright, Kenneth >> Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] alt structure suggested for CNAM >> >> Cartwright, Kenneth wrote: >>> Exactly. And there are of course extremely good reasons why one must >>> usually ultimately go to different "resolution" server(s) to lookup >>> data like CNAM. First and foremost, the calling name data is usually >>> collected and consolidated and managed and offered up by a separate >>> company or organization whose business it is to do that. >> So how do you find out what server to query? Is there something like an >> indirection record in the DNS, or is it just a matter of configuring >> your systems to query against different roots for different sorts of >> information? >> >> I'm pretty sure it's the latter, but I'm fishing for some kind of reason >> why we're using "the DNS" instead of having an entirely independent >> protocol and operations framework that just sort of works like the DNS. >> If we were doing the latter, I'm pretty sure we would not get so much >> micromanagement from the appointed guardians of the DNS. This might make >> our lives a whole lot easier. >> >> -- >> Dean >> >> This e-mail message is for the sole use of the intended recipient(s)and may >> contain confidential and privileged information of Transaction Network Services. >> Any unauthorised review, use, disclosure or distribution is prohibited. If you >> are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. >> >> _______________________________________________ >> e2md mailing list >> e2md@ietf.org >> https://www.ietf.org/mailman/listinfo/e2md >> > > This e-mail message is for the sole use of the intended recipient(s)and may > contain confidential and privileged information of Transaction Network Services. > Any unauthorised review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > > From richard@shockey.us Mon Mar 29 09:46:48 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28CA3A6AD9 for ; Mon, 29 Mar 2010 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVUcxI4+xhBf for ; Mon, 29 Mar 2010 09:46:46 -0700 (PDT) Received: from outbound-mail-359.bluehost.com (outbound-mail-359.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id AA79D3A6AF0 for ; Mon, 29 Mar 2010 09:46:43 -0700 (PDT) Received: (qmail 27614 invoked by uid 0); 29 Mar 2010 16:47:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 29 Mar 2010 16:47:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=PljiQ6rXVZmFkbPIzQiZpKHwJ6tR7gdFt3x5kvm6JoDXfYnNMveQ/YJbQTthYCwtwCyAF5QIczhyFD1dcgaomD7m7K5HFJtLL5GGbYr3I1mXjGbC5nTsqwRZa4ymCKuC; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NwI7F-0007UX-D3; Mon, 29 Mar 2010 10:47:05 -0600 From: "Richard Shockey" To: "'Dean Willis'" , "'Lawrence Conroy'" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> In-Reply-To: <4BB04669.3070500@softarmor.com> Date: Mon, 29 Mar 2010 12:47:01 -0400 Message-ID: <00ec01cacf5f$75147c40$5f3d74c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrPB7HoRX8igEafT0uub8C9dBBKFwAVsMTw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:46:48 -0000 Well obviously I agree with the earlier remarks from Hadriel and Eric Berger. What some folks in the room IMHO did not seem to understand is that the E2MD work is necessary to make SIP work better. This is not a DNS issue at all .. the use of 3761 technology is simply the hammer and a very very good one at that. It works its gobally deployed in various forms. As SIP has fully deployed it is necessary to create more rational and more cost effective ways of accessing what is traditionally PSTN data objects. This whole business is being driven by cost avoidance specifically the avoidance of TCAP dips and cost of the SS7/C7 A-links etc. If the IETF does not confront the larger issue of SIP/PSTN interworking it will get solved but probably somewhere else and the result would be an even worse hack that what we have out in the field right now. -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean Willis Sent: Monday, March 29, 2010 2:19 AM To: Lawrence Conroy Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Lawrence Conroy wrote: > Hi Eric, folks, > Wasn't that the intent? > I don't have any other logical interpretation I can put on this thread. > > The alternatives of being forced to use other ports, or doing > anything like that, is absurd, and evil (i.e. bad and wrong). > ENUM works quite nicely on the DNS on port 53, despite the surreal > and/or doom laden air. But it doesn't gain traction in the IETF. > I suspect that part of the problem is that ENUM isn't REALLY in "the DNS". Some IETFers probably feel like they bent over backsards to put phone numbers into the scope of the Internet, and then the phone oeprators went and did these private ENUM things (which might use DNS technology but aren't "the DNS"), thereby making a walled-garden even more walled. Why should we do funky things to a core Internet technology in order to facilitate the priavte non-Internet use of somebody who has already proven not to be working on the best interest of the Internet? That said, there are people in the IETF who are interested in providing a high-speed distributed hierarchical database for phone-numbers and related data. However, those people just don't constitue a large enough chunk of the DNS leadership to be able to make changes to the DNS. But a closely-related technology that uses lessons learns fom the DNS but that is itself not the DNS would probably make the metadata problem more attractive to the IETF DNS pundits. -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From richard@shockey.us Mon Mar 29 09:49:10 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ED213A6AC3 for ; Mon, 29 Mar 2010 09:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXruZPZUGLK5 for ; Mon, 29 Mar 2010 09:49:09 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 446603A6AC0 for ; Mon, 29 Mar 2010 09:49:07 -0700 (PDT) Received: (qmail 6376 invoked by uid 0); 29 Mar 2010 16:49:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 29 Mar 2010 16:49:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=JHoOrg8a79wjZPAX0WuStlYayEnG1a54RVHi3exkbbwfhXtH1ID9C1IrfHsyK9E6dQv0CD/PLPYQ/mYyaE5cEZPopPyll8J2ZKob9nl8DJspVMYJrqLmvVMt69PCdEqa; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NwI9f-0000IJ-0f; Mon, 29 Mar 2010 10:49:35 -0600 From: "Richard Shockey" To: "'Otmar Lendl'" , References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB090B8.5050804@nic.at> In-Reply-To: <4BB090B8.5050804@nic.at> Date: Mon, 29 Mar 2010 12:49:31 -0400 Message-ID: <010b01cacf5f$ce3b3570$6ab1a050$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrPNBTv2QtTIhv+Th21ZMR49XJBtAAK2Ufw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:49:10 -0000 > 2) The ability to determine the "source" of the query in a standardized > manner. Hadriel has a proposal out there on a way to do this. But, > again, ***this is a broader subject and should definitely be handled as > a separate discussion track***. Again, this requirement contradicts one of the core design principles of the DNS architecture. Yes, Hadrian's draft provides an idea on how one could retrofit the DNS to accommodate this wish, but that's a very ugly hack. IMHO we need a requirements document to determine whether the DNS path is the right one. RS> Oh please we are long past the need for some superfluous requirements document. What is clear to me is we are not going to invent something new and what we have clearly works well in the field and scales very well. All I want is a clear syntax. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md From pkyzivat@cisco.com Mon Mar 29 10:40:53 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5867F3A6B10 for ; Mon, 29 Mar 2010 10:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y08wtdPKdaB8 for ; Mon, 29 Mar 2010 10:40:52 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6C83D3A6ABF for ; Mon, 29 Mar 2010 10:40:46 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIODsEtAZnwN/2dsb2JhbACbJXGnSZhYhQEE X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="97089401" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2010 17:41:14 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2THfDJG012696; Mon, 29 Mar 2010 17:41:14 GMT Message-ID: <4BB0E638.8050408@cisco.com> Date: Mon, 29 Mar 2010 13:41:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Shockey References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <00ec01cacf5f$75147c40$5f3d74c0$@us> In-Reply-To: <00ec01cacf5f$75147c40$5f3d74c0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 17:40:53 -0000 Richard, Its one thing to say "I want to use a hammer to drive screws". I think the hammer manufacturer cannot forbid you from doing that, even if it thinks the use unwise, and voids the warranty. Its another thing to demand changes in the design of the hammer to enhance its ability to hammer a wider variety of fasteners, such as nuts and bolts. The hammer manufacturer has every right to refuse to make such a change on the basis that it is outside the scope of applicability of the hammer design. Thanks, Paul Richard Shockey wrote: > Well obviously I agree with the earlier remarks from Hadriel and Eric > Berger. What some folks in the room IMHO did not seem to understand is that > the E2MD work is necessary to make SIP work better. This is not a DNS issue > at all .. the use of 3761 technology is simply the hammer and a very very > good one at that. It works its gobally deployed in various forms. As SIP has > fully deployed it is necessary to create more rational and more cost > effective ways of accessing what is traditionally PSTN data objects. This > whole business is being driven by cost avoidance specifically the avoidance > of TCAP dips and cost of the SS7/C7 A-links etc. > > If the IETF does not confront the larger issue of SIP/PSTN interworking it > will get solved but probably somewhere else and the result would be an even > worse hack that what we have out in the field right now. > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dean > Willis > Sent: Monday, March 29, 2010 2:19 AM > To: Lawrence Conroy > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > > Lawrence Conroy wrote: >> Hi Eric, folks, >> Wasn't that the intent? >> I don't have any other logical interpretation I can put on this thread. >> >> The alternatives of being forced to use other ports, or doing >> anything like that, is absurd, and evil (i.e. bad and wrong). >> ENUM works quite nicely on the DNS on port 53, despite the surreal >> and/or doom laden air. But it doesn't gain traction in the IETF. >> > > > I suspect that part of the problem is that ENUM isn't REALLY in "the > DNS". Some IETFers probably feel like they bent over backsards to put > phone numbers into the scope of the Internet, and then the phone > oeprators went and did these private ENUM things (which might use DNS > technology but aren't "the DNS"), thereby making a walled-garden even > more walled. Why should we do funky things to a core Internet technology > in order to facilitate the priavte non-Internet use of somebody who has > already proven not to be working on the best interest of the Internet? > > > > That said, there are people in the IETF who are interested in providing > a high-speed distributed hierarchical database for phone-numbers and > related data. However, those people just don't constitue a large enough > chunk of the DNS leadership to be able to make changes to the DNS. But a > closely-related technology that uses lessons learns fom the DNS but > that is itself not the DNS would probably make the metadata problem more > attractive to the IETF DNS pundits. > > -- > Dean > > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From kcartwright@tnsi.com Mon Mar 29 11:05:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16DE3A6B3B for ; Mon, 29 Mar 2010 11:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.602 X-Spam-Level: * X-Spam-Status: No, score=1.602 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2N4F6OD1gJG for ; Mon, 29 Mar 2010 11:05:49 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 9F84E3A6AE0 for ; Mon, 29 Mar 2010 11:05:46 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42013422; Mon, 29 Mar 2010 14:06:02 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 14:06:02 -0400 From: "Cartwright, Kenneth" To: Paul Kyzivat Date: Mon, 29 Mar 2010 14:06:01 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrPWx1dHnLpy/TUQ6KfXuPwzIcQRQADXWqQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0D237.7050700@cisco.com> In-Reply-To: <4BB0D237.7050700@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164@core3.amsl.com" , list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 18:05:50 -0000 Hi Paul, You bring up a somewhat valid analogy about how "meta-data" is accessed for= domain names resolved within "The DNS". 1) As I've mentioned in previous emails, there are different technologies t= hat can be applied to the meta-data problem. And the technologies that und= erlie the DNS are one such set. And, imo, the simple fact that they underl= ie the DNS does not, therefore, make them off base for application outside = the DNS. That being said, however, meta-data around the domain names that = are resolved via "The DNS" are not typically looked up via the technologies= that underlie DNS (at least in the US). However, as some have pointed out= in response to my previous statements about this fact, some of the key use= cases being considered here *will* benefit greatly from the use of the tec= hnologies that underlie the DNS as apposed to the technologies that underli= e things like WhoIs, EPP, etc. Furthermore, the unused and send-n use case= s are, imo, extremely coupled with the concept of resolving a TN (which tod= ay is typically done using DNS based technologies). 2) But on the broader point, I assume that you are not suggesting that ther= e is some person or company that should be the decider of what business mod= els and associated policy sets are *allowed* to use the technologies that u= nderlie the DNS. The reason I assume that you do not mean to imply that is= because that seems an untenable position to be taking. I think you must m= ean something else. Thanks Ken -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, March 29, 2010 12:16 PM To: Cartwright, Kenneth Cc: Dean Willis; E.164@core3.amsl.com; list Subject: Re: [e2md] alt structure suggested for CNAM Cartwright, Kenneth wrote: > I understand your point of view. And CNAM data could theoretically work = the way you are suggesting (and maybe one day it will). However, that is n= ot the current business/policy model that underlies much of the CNAM usage = scenarios. Trying to impose the public domain name lookup business/policy = model on all data that could be queried using some of the DNS technologies = is probably not a good stance. I think the technology should not get in th= e way of either business model, and the IETF's role, in my opinion, is not = to impose one or the other. Your vision is more purist, which is great and= elegant, but is not the only one and is not necessitated by the technologi= es that underlie DNS. > > Furthermore, there is a lot of meta-data around the public DNS's domain n= ames and domain name data bases that is also only provided to those that ei= ther pay for it or have the legal authority to have access to it. And how is the "meta-data around the public DNS's domain names and domain name data bases that is also only provided to those that either pay for it or have the legal authority to have access to it" accessed today? Presumably not via DNS queries. So maybe it would be appropriate to look at how that is dealt with to find a corresponding approach for e2md. Thanks, Paul > Ken > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 29, 2010 11:47 AM > To: Cartwright, Kenneth > Cc: Dean Willis; E.164@core3.amsl.com; list > Subject: Re: [e2md] alt structure suggested for CNAM > > I've been keeping out of this, but I just can't any longer... > > Cartwright, Kenneth wrote: >> Different organizations use different CNAM data providers. So they conf= igure their systems to access the CNAM data source that they have decided/a= greed/contracted/paid to use (if any). However, it would of course be good= if that data could be looked up and structured in a standard form, which i= s the goal of the CNAM proposal. You're exactly right. And because many o= f those organizations already use ENUM for other VoIP related lookups, havi= ng the technology for the CNAM lookup be very similar to ENUM is a no brain= er. (And to draw an analogy, in the "legacy" SS7 world TCAP, which is used= for SS7 call routing, is also used to lookup CNAM data, using an SS7 messa= ge that is sent specifically to lookup CNAM data. Iow, they did not invent = some completely different query/response protocol outside of TCAP just to l= ookup CNAM data. That would have been overkill.). > > The above approach seems to be to be entirely contrary to the philosophy > behind DNS. > > At the very least, the server(s) that are authoritative for a given DNS > name should be independent of who is asking. > > I guess that can still be honored by using a distinct ENUM root for the > lookup. But then, what is the *meaning* of looking up CNAM for a > particular phone number against two different ENUM roots? Are those to > be considered two different phone number namespaces, each with its own > CNAM, that might potentially differ from the others? I presume not. > > Apparently what you are saying is that CNAM retrieved from A.B.C.Root1 > means the same as from A.B.C.Root2 except that there is different access > and different billing for making the query. Is that right? > > Suppose that were applied to other aspects of DNS, like A records. I > think much of the world would (rightfully) go ballistic if that were > proposed. > > Thanks, > Paul > >> The CNAM proposal is necessary and is not really about "The DNS" imo. A= nd the notion that these proposals are about "The DNS" got much of the BOF = discussions way off track imo. From my point of view, these proposals are = about using DNS related technologies (DDDS, domain names, NAPTR RRs) to loo= kup data about TNs. Organizations already lookup CNAM data using E2U today= and would like to do it in a standardized way. And, believe me, the organ= izations that serve up CNAM data today know how to "keep it safe". And whi= le it would definitely be useful to have further technical tools in the sta= ndard toolkit around E2U/DDDS/E2M to allow it to be "kept safe" in a more s= tandard or elegant fashion, ***that is a broader subject and should definit= ely be handled as a separate discussion track***. >> >> The "unused" proposal would also be a very useful tool to have in the to= olkit. >> >> The improvements that I would like to see added into the technology tool= kit around E2U/E2M/DDDS are: >> 1) The ability to, in the resolution request, to specify which serviceTy= pe-SubType pairs the querier is interested in. This is useful for more tha= n one reason (allowing a specific querier to vary the content of their resp= onse per query, without requiring them to use a different root domain). Ri= ght now this is done via other means, some of which Hadriel has described. = But, again, ***this item is a broader subject and should definitely be han= dled as a separate discussion track***. >> 2) The ability to determine the "source" of the query in a standardized = manner. Hadriel has a proposal out there on a way to do this. But, again,= ***this is a broader subject and should definitely be handled as a separat= e discussion track***. >> >> Ken >> >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Friday, March 26, 2010 12:25 PM >> To: Cartwright, Kenneth >> Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] alt structure suggested for CNAM >> >> Cartwright, Kenneth wrote: >>> Exactly. And there are of course extremely good reasons why one must >>> usually ultimately go to different "resolution" server(s) to lookup >>> data like CNAM. First and foremost, the calling name data is usually >>> collected and consolidated and managed and offered up by a separate >>> company or organization whose business it is to do that. >> So how do you find out what server to query? Is there something like an >> indirection record in the DNS, or is it just a matter of configuring >> your systems to query against different roots for different sorts of >> information? >> >> I'm pretty sure it's the latter, but I'm fishing for some kind of reason >> why we're using "the DNS" instead of having an entirely independent >> protocol and operations framework that just sort of works like the DNS. >> If we were doing the latter, I'm pretty sure we would not get so much >> micromanagement from the appointed guardians of the DNS. This might make >> our lives a whole lot easier. >> >> -- >> Dean >> >> This e-mail message is for the sole use of the intended recipient(s)and = may >> contain confidential and privileged information of Transaction Network S= ervices. >> Any unauthorised review, use, disclosure or distribution is prohibited. = If you >> are not the intended recipient, please contact the sender by reply e-mai= l and destroy all copies of the original message. >> >> _______________________________________________ >> e2md mailing list >> e2md@ietf.org >> https://www.ietf.org/mailman/listinfo/e2md >> > > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > > This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Mon Mar 29 11:11:56 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD743A68B2 for ; Mon, 29 Mar 2010 11:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.038 X-Spam-Level: X-Spam-Status: No, score=-0.038 tagged_above=-999 required=5 tests=[AWL=1.431, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzpjfEOvCKPl for ; Mon, 29 Mar 2010 11:11:55 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 2C8293A6852 for ; Mon, 29 Mar 2010 11:11:54 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42013612; Mon, 29 Mar 2010 14:12:18 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 14:12:18 -0400 From: "Cartwright, Kenneth" To: Paul Kyzivat , Richard Shockey Date: Mon, 29 Mar 2010 14:12:16 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPZw7QumeprT8dR2CcAuCqX3B/ZAAA9VxA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529D1D@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <00ec01cacf5f$75147c40$5f3d74c0$@us> <4BB0E638.8050408@cisco.com> In-Reply-To: <4BB0E638.8050408@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 18:11:56 -0000 The Hammer/ScrewDriver analogy can only be taken so far. This discussion h= as now become too vague. I've lost track of what is the Hammer? Is DDDS t= he hammer? Why can't DDDS be extended? Or why can't additional standards be created a= nd *optionally* used in conjunction with DDDS? This is what we are talking= about, imo. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: Monday, March 29, 2010 1:41 PM To: Richard Shockey Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Richard, Its one thing to say "I want to use a hammer to drive screws". I think the hammer manufacturer cannot forbid you from doing that, even if it thinks the use unwise, and voids the warranty. Its another thing to demand changes in the design of the hammer to enhance its ability to hammer a wider variety of fasteners, such as nuts and bolts. The hammer manufacturer has every right to refuse to make such a change on the basis that it is outside the scope of applicability of the hammer design. Thanks, Paul Richard Shockey wrote: > Well obviously I agree with the earlier remarks from Hadriel and Eric > Berger. What some folks in the room IMHO did not seem to understand is t= hat > the E2MD work is necessary to make SIP work better. This is not a DNS iss= ue > at all .. the use of 3761 technology is simply the hammer and a very very > good one at that. It works its gobally deployed in various forms. As SIP = has > fully deployed it is necessary to create more rational and more cost > effective ways of accessing what is traditionally PSTN data objects. This > whole business is being driven by cost avoidance specifically the avoidan= ce > of TCAP dips and cost of the SS7/C7 A-links etc. > > If the IETF does not confront the larger issue of SIP/PSTN interworking i= t > will get solved but probably somewhere else and the result would be an ev= en > worse hack that what we have out in the field right now. > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of D= ean > Willis > Sent: Monday, March 29, 2010 2:19 AM > To: Lawrence Conroy > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > > Lawrence Conroy wrote: >> Hi Eric, folks, >> Wasn't that the intent? >> I don't have any other logical interpretation I can put on this thread. >> >> The alternatives of being forced to use other ports, or doing >> anything like that, is absurd, and evil (i.e. bad and wrong). >> ENUM works quite nicely on the DNS on port 53, despite the surreal >> and/or doom laden air. But it doesn't gain traction in the IETF. >> > > > I suspect that part of the problem is that ENUM isn't REALLY in "the > DNS". Some IETFers probably feel like they bent over backsards to put > phone numbers into the scope of the Internet, and then the phone > oeprators went and did these private ENUM things (which might use DNS > technology but aren't "the DNS"), thereby making a walled-garden even > more walled. Why should we do funky things to a core Internet technology > in order to facilitate the priavte non-Internet use of somebody who has > already proven not to be working on the best interest of the Internet? > > > > That said, there are people in the IETF who are interested in providing > a high-speed distributed hierarchical database for phone-numbers and > related data. However, those people just don't constitue a large enough > chunk of the DNS leadership to be able to make changes to the DNS. But a > closely-related technology that uses lessons learns fom the DNS but > that is itself not the DNS would probably make the metadata problem more > attractive to the IETF DNS pundits. > > -- > Dean > > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From pkyzivat@cisco.com Mon Mar 29 11:25:14 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381503A690F for ; Mon, 29 Mar 2010 11:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUYHJEA17jOg for ; Mon, 29 Mar 2010 11:25:12 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 965A23A69F0 for ; Mon, 29 Mar 2010 11:25:11 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA+OsEtAZnwM/2dsb2JhbACbJXGneZhhglmCKAQ X-IronPort-AV: E=Sophos;i="4.51,329,1267401600"; d="scan'208";a="97242206" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2010 18:25:38 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2TIPcRV027002; Mon, 29 Mar 2010 18:25:38 GMT Message-ID: <4BB0F0A3.80102@cisco.com> Date: Mon, 29 Mar 2010 14:25:39 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0D237.7050700@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "E.164@core3.amsl.com" , list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 18:25:14 -0000 Cartwright, Kenneth wrote: > Hi Paul, > > You bring up a somewhat valid analogy about how "meta-data" is accessed for domain names resolved within "The DNS". > > 1) As I've mentioned in previous emails, there are different technologies that can be applied to the meta-data problem. And the technologies that underlie the DNS are one such set. And, imo, the simple fact that they underlie the DNS does not, therefore, make them off base for application outside the DNS. > That being said, however, meta-data around the domain names that are resolved via "The DNS" are not typically looked up via the technologies that underlie DNS (at least in the US). I think that is not an accident. It should perhaps be viewed as a word to the wise. > However, as some have pointed out in response to my previous statements about this fact, some of the key use cases being considered here *will* benefit greatly from the use of the technologies that underlie the DNS as apposed to the technologies that underlie things like WhoIs, EPP, etc. Furthermore, the unused and send-n use cases are, imo, extremely coupled with the concept of resolving a TN (which today is typically done using DNS based technologies). ISTM that *some* of these metadata issues should indeed apply to the DNS as a whole, with common applicable solutions. However, some of the existing solutions may be a bit "long in the tooth" and not applicable unless replaced or modernized. Nevertheless, ISTM that it would be worth considering how many of these metadata things are indeed common problems. CNAM seems like one that might be. > 2) But on the broader point, I assume that you are not suggesting that there is some person or company that should be the decider of what business models and associated policy sets are *allowed* to use the technologies that underlie the DNS. The reason I assume that you do not mean to imply that is because that seems an untenable position to be taking. I think you must mean something else. No, I'm not suggesting that. But IIUC the current proposals are to use and extend things that are governed by RFCs that make up "the DNS". I'm not up on what the existing rules are for extension of those things. But I presume one way or another it will come to some kind of standards action that will require "rough consensus", and the community in which that consensus must be achieved will be the "DNS community" rather than just the "e2md" community. Hence the bar is higher. (If the rule is actually that anybody can put anything into a NAPTR or RR on a FCFS basis with no community approval, then I guess e2md has a much freer hand.) Thanks, Paul > Thanks > Ken > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 29, 2010 12:16 PM > To: Cartwright, Kenneth > Cc: Dean Willis; E.164@core3.amsl.com; list > Subject: Re: [e2md] alt structure suggested for CNAM > > > > Cartwright, Kenneth wrote: >> I understand your point of view. And CNAM data could theoretically work the way you are suggesting (and maybe one day it will). However, that is not the current business/policy model that underlies much of the CNAM usage scenarios. Trying to impose the public domain name lookup business/policy model on all data that could be queried using some of the DNS technologies is probably not a good stance. I think the technology should not get in the way of either business model, and the IETF's role, in my opinion, is not to impose one or the other. Your vision is more purist, which is great and elegant, but is not the only one and is not necessitated by the technologies that underlie DNS. >> >> Furthermore, there is a lot of meta-data around the public DNS's domain names and domain name data bases that is also only provided to those that either pay for it or have the legal authority to have access to it. > > And how is the "meta-data around the public DNS's domain names and > domain name data bases that is also only provided to those that either > pay for it or have the legal authority to have access to it" accessed > today? > > Presumably not via DNS queries. > > So maybe it would be appropriate to look at how that is dealt with to > find a corresponding approach for e2md. > > Thanks, > Paul > >> Ken >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, March 29, 2010 11:47 AM >> To: Cartwright, Kenneth >> Cc: Dean Willis; E.164@core3.amsl.com; list >> Subject: Re: [e2md] alt structure suggested for CNAM >> >> I've been keeping out of this, but I just can't any longer... >> >> Cartwright, Kenneth wrote: >>> Different organizations use different CNAM data providers. So they configure their systems to access the CNAM data source that they have decided/agreed/contracted/paid to use (if any). However, it would of course be good if that data could be looked up and structured in a standard form, which is the goal of the CNAM proposal. You're exactly right. And because many of those organizations already use ENUM for other VoIP related lookups, having the technology for the CNAM lookup be very similar to ENUM is a no brainer. (And to draw an analogy, in the "legacy" SS7 world TCAP, which is used for SS7 call routing, is also used to lookup CNAM data, using an SS7 message that is sent specifically to lookup CNAM data. Iow, they did not invent some completely different query/response protocol outside of TCAP just to lookup CNAM data. That would have been overkill.). >> The above approach seems to be to be entirely contrary to the philosophy >> behind DNS. >> >> At the very least, the server(s) that are authoritative for a given DNS >> name should be independent of who is asking. >> >> I guess that can still be honored by using a distinct ENUM root for the >> lookup. But then, what is the *meaning* of looking up CNAM for a >> particular phone number against two different ENUM roots? Are those to >> be considered two different phone number namespaces, each with its own >> CNAM, that might potentially differ from the others? I presume not. >> >> Apparently what you are saying is that CNAM retrieved from A.B.C.Root1 >> means the same as from A.B.C.Root2 except that there is different access >> and different billing for making the query. Is that right? >> >> Suppose that were applied to other aspects of DNS, like A records. I >> think much of the world would (rightfully) go ballistic if that were >> proposed. >> >> Thanks, >> Paul >> >>> The CNAM proposal is necessary and is not really about "The DNS" imo. And the notion that these proposals are about "The DNS" got much of the BOF discussions way off track imo. From my point of view, these proposals are about using DNS related technologies (DDDS, domain names, NAPTR RRs) to lookup data about TNs. Organizations already lookup CNAM data using E2U today and would like to do it in a standardized way. And, believe me, the organizations that serve up CNAM data today know how to "keep it safe". And while it would definitely be useful to have further technical tools in the standard toolkit around E2U/DDDS/E2M to allow it to be "kept safe" in a more standard or elegant fashion, ***that is a broader subject and should definitely be handled as a separate discussion track***. >>> >>> The "unused" proposal would also be a very useful tool to have in the toolkit. >>> >>> The improvements that I would like to see added into the technology toolkit around E2U/E2M/DDDS are: >>> 1) The ability to, in the resolution request, to specify which serviceType-SubType pairs the querier is interested in. This is useful for more than one reason (allowing a specific querier to vary the content of their response per query, without requiring them to use a different root domain). Right now this is done via other means, some of which Hadriel has described. But, again, ***this item is a broader subject and should definitely be handled as a separate discussion track***. >>> 2) The ability to determine the "source" of the query in a standardized manner. Hadriel has a proposal out there on a way to do this. But, again, ***this is a broader subject and should definitely be handled as a separate discussion track***. >>> >>> Ken >>> >>> -----Original Message----- >>> From: Dean Willis [mailto:dean.willis@softarmor.com] >>> Sent: Friday, March 26, 2010 12:25 PM >>> To: Cartwright, Kenneth >>> Cc: Hadriel Kaplan; E.164 To MetaData BOF discussion list >>> Subject: Re: [e2md] alt structure suggested for CNAM >>> >>> Cartwright, Kenneth wrote: >>>> Exactly. And there are of course extremely good reasons why one must >>>> usually ultimately go to different "resolution" server(s) to lookup >>>> data like CNAM. First and foremost, the calling name data is usually >>>> collected and consolidated and managed and offered up by a separate >>>> company or organization whose business it is to do that. >>> So how do you find out what server to query? Is there something like an >>> indirection record in the DNS, or is it just a matter of configuring >>> your systems to query against different roots for different sorts of >>> information? >>> >>> I'm pretty sure it's the latter, but I'm fishing for some kind of reason >>> why we're using "the DNS" instead of having an entirely independent >>> protocol and operations framework that just sort of works like the DNS. >>> If we were doing the latter, I'm pretty sure we would not get so much >>> micromanagement from the appointed guardians of the DNS. This might make >>> our lives a whole lot easier. >>> >>> -- >>> Dean >>> >>> This e-mail message is for the sole use of the intended recipient(s)and may >>> contain confidential and privileged information of Transaction Network Services. >>> Any unauthorised review, use, disclosure or distribution is prohibited. If you >>> are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. >>> >>> _______________________________________________ >>> e2md mailing list >>> e2md@ietf.org >>> https://www.ietf.org/mailman/listinfo/e2md >>> >> This e-mail message is for the sole use of the intended recipient(s)and may >> contain confidential and privileged information of Transaction Network Services. >> Any unauthorised review, use, disclosure or distribution is prohibited. If you >> are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. >> >> > > This e-mail message is for the sole use of the intended recipient(s)and may > contain confidential and privileged information of Transaction Network Services. > Any unauthorised review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > > From dean.willis@softarmor.com Mon Mar 29 11:55:39 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6BC3A6812 for ; Mon, 29 Mar 2010 11:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sy-9BexGAEJv for ; Mon, 29 Mar 2010 11:55:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 189013A690C for ; Mon, 29 Mar 2010 11:55:38 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TItfB0007294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 13:55:43 -0500 Message-Id: <699EC41F-C093-4D87-851C-4B21167EA1AE@softarmor.com> From: Dean Willis To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 13:55:35 -0500 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0D237.7050700@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> X-Mailer: Apple Mail (2.936) Cc: "E.164@core3.amsl.com" , list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 18:55:39 -0000 On Mar 29, 2010, at 1:06 PM, Cartwright, Kenneth wrote: > > Hi Paul, > > You bring up a somewhat valid analogy about how "meta-data" is > accessed for domain names resolved within "The DNS". > > 1) As I've mentioned in previous emails, there are different > technologies that can be applied to the meta-data problem. And the > technologies that underlie the DNS are one such set. And, imo, the > simple fact that they underlie the DNS does not, therefore, make > them off base for application outside the DNS. But we are asking the DNS directorate to authorize the making of such changes. That's the root of the problem. What Hadriel has suggested is taking an alt-root approach by saying "We're using technologies derived from DNS, but not extending "The DNS" itself. > That being said, however, meta-data around the domain names that are > resolved via "The DNS" are not typically looked up via the > technologies that underlie DNS (at least in the US). However, as > some have pointed out in response to my previous statements about > this fact, some of the key use cases being considered here *will* > benefit greatly from the use of the technologies that underlie the > DNS as apposed to the technologies that underlie things like WhoIs, > EPP, etc. Furthermore, the unused and send-n use cases are, imo, > extremely coupled with the concept of resolving a TN (which today is > typically done using DNS based technologies). > 2) But on the broader point, I assume that you are not suggesting > that there is some person or company that should be the decider of > what business models and associated policy sets are *allowed* to use > the technologies that underlie the DNS. The reason I assume that > you do not mean to imply that is because that seems an untenable > position to be taking. I think you must mean something else. The IETF's position is that the IETF IS the decider on what technologies are specified by the IETF. Their work process specifically establishes criteria for new work in general, and more specifically around DNS work. They have every right to say "no". So far, they haven't said "no", but they have said we haven't made a strong enough case. -- Dean From dean.willis@softarmor.com Mon Mar 29 12:02:05 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477673A6914 for ; Mon, 29 Mar 2010 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzpEV3pgcKMR for ; Mon, 29 Mar 2010 12:02:04 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8D5093A68D5 for ; Mon, 29 Mar 2010 12:02:04 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TJ2Tuu007370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 14:02:31 -0500 Message-Id: <3C576459-DB91-454E-A5FB-F59978FB5FD8@softarmor.com> From: Dean Willis To: Jay Daley In-Reply-To: <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 14:02:24 -0500 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:02:05 -0000 On Mar 29, 2010, at 3:02 AM, Jay Daley wrote: > >> > > > It appears to me from your statements above that all the various > objections, rat holes, mis-respresentations and distractions that > you have raised on this list are entirely of a political layer-9 > origin and in no way technical. Ironic since it the IETF way that > you claim to be defending. > Ok, I've had just about enough of this. I'm tired of being personally attacked for relaying things that various community influencers, primarily current/former IESG/IAB members, have told me OR TOLD THE E2MD COMMUNITY DURING OUR BOF about why they don't like the E2MD proposal. Or at least listen to the recording of the meeting, or read the draft minutes that I typed up and circulated for you. I'm not making this stuff up. If you don't like the way I'm relaying it, go take it up with the IAB and IESG yourself. -- Dean From kcartwright@tnsi.com Mon Mar 29 12:10:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43B33A6A2C for ; Mon, 29 Mar 2010 12:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=1.301, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHHToBeFa8O8 for ; Mon, 29 Mar 2010 12:10:20 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id D012B3A6971 for ; Mon, 29 Mar 2010 12:10:19 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42015930; Mon, 29 Mar 2010 15:10:41 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 15:10:40 -0400 From: "Cartwright, Kenneth" To: Dean Willis Date: Mon, 29 Mar 2010 15:10:38 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrPcYAiFL/bhthnTL+WN7exrP/aBQAAElEw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529D96@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0D237.7050700@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> <699EC41F-C093-4D87-851C-4B21167EA1AE@softarmor.com> In-Reply-To: <699EC41F-C093-4D87-851C-4B21167EA1AE@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164@core3.amsl.com" , list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:10:21 -0000 Your replies below do not seem to directly relate to the points I was makin= g. So I'll just say 1) Yes I understand what Hadriel is proposing and am fine with it 2) Yes I understand and agree with the fact that the IETF evaluates technol= ogies around the DNS, but I think that the IETF should definitely not be de= ciding what business models and associated policies are allowed to use thos= e technologies. That is the job of the regulators (e.g. ICANN, et.al.) and= the market place. Given my limited time to devote to discussions like this I need to now bow = out of this line of discussion about the role of the IETF and the relations= hip between "The DNS" and the technologies that underlie the DNS. Others a= re probably better suited to that discussion anyway. Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, March 29, 2010 2:56 PM To: Cartwright, Kenneth Cc: Paul Kyzivat; E.164@core3.amsl.com; list Subject: Re: [e2md] alt structure suggested for CNAM On Mar 29, 2010, at 1:06 PM, Cartwright, Kenneth wrote: > > Hi Paul, > > You bring up a somewhat valid analogy about how "meta-data" is > accessed for domain names resolved within "The DNS". > > 1) As I've mentioned in previous emails, there are different > technologies that can be applied to the meta-data problem. And the > technologies that underlie the DNS are one such set. And, imo, the > simple fact that they underlie the DNS does not, therefore, make > them off base for application outside the DNS. But we are asking the DNS directorate to authorize the making of such changes. That's the root of the problem. What Hadriel has suggested is taking an alt-root approach by saying "We're using technologies derived from DNS, but not extending "The DNS" itself. > That being said, however, meta-data around the domain names that are > resolved via "The DNS" are not typically looked up via the > technologies that underlie DNS (at least in the US). However, as > some have pointed out in response to my previous statements about > this fact, some of the key use cases being considered here *will* > benefit greatly from the use of the technologies that underlie the > DNS as apposed to the technologies that underlie things like WhoIs, > EPP, etc. Furthermore, the unused and send-n use cases are, imo, > extremely coupled with the concept of resolving a TN (which today is > typically done using DNS based technologies). > 2) But on the broader point, I assume that you are not suggesting > that there is some person or company that should be the decider of > what business models and associated policy sets are *allowed* to use > the technologies that underlie the DNS. The reason I assume that > you do not mean to imply that is because that seems an untenable > position to be taking. I think you must mean something else. The IETF's position is that the IETF IS the decider on what technologies are specified by the IETF. Their work process specifically establishes criteria for new work in general, and more specifically around DNS work. They have every right to say "no". So far, they haven't said "no", but they have said we haven't made a strong enough case. -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From dean.willis@softarmor.com Mon Mar 29 12:19:19 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 951AA3A690E for ; Mon, 29 Mar 2010 12:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.327 X-Spam-Level: X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAMsmvKt0du0 for ; Mon, 29 Mar 2010 12:19:18 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6855F3A6826 for ; Mon, 29 Mar 2010 12:19:18 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TJJicg007501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 14:19:45 -0500 Message-Id: <192A344E-AC0E-4D06-B521-8C79A2E97D63@softarmor.com> From: Dean Willis To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 14:19:38 -0500 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:19:19 -0000 On Mar 29, 2010, at 8:00 AM, Ray.Bellis@nominet.org.uk wrote: > > Despite the misleading statements made by some, there is no protocol > _or_ deployment police for the DNS. The concern of the IESG and IAB > should be to ensure interoperability and scalability, and to > facilitate standardisation efforts thereto. It should _not_ be for > certain members to apparently try to actively _prevent_ the effort > simply because some purists simply "don't like" the technology. As > yet there has been _no_ sound technical justification against doing > this work. All we're hearing is FUD, and even then it's third hand. Third hand? You were sitting there with me, and Hadriel, and Bernie, and Brian Rosen, while Jon Peterson explained his objections. You were also in the BOF, right? You heard Peter and Olaf and Jon and John Klensin rip up the proposed work? Did you disagree with what went into the draft minutes I posted, wherein we attempted to establish "what was said" so that it isn't all 3rd hand innuendo? Now you might technically disagree with them. You might well be right to do so; I technically disagree with many of these people on a regular basis, and I hope I'm at least occasionally "right" when doing so. But the IETF work process is what it is. There are limited resources available in the IETF, and new work gets chartered only if it meets the requirements of community consensus, WHERE THAT CONSENSUS IS DETERMINED BY THE IESG BASED ON COMMUNITY INPUT AND WITH ADVICE FROM THE IAB. RFC 2418 spells out this process. Specifically, you might wish to eyeball section 2.1. > > I do agree that NAPTR is slightly limiting because within DDDS we > are unable to query on service type. Well, frankly, that's tough. > It's old news. It's how the IETF defined it, and it's pretty much > all we've got. However that does not justify blocking future work > just because it happens to specify NAPTRs. > Several ADs pointed out that nothing is preventing the development of a new and more appropriate resource record type. -- Dean From HKaplan@acmepacket.com Mon Mar 29 12:39:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942AD3A67D2 for ; Mon, 29 Mar 2010 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECcTr5PgluTm for ; Mon, 29 Mar 2010 12:39:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 639FA3A6AFD for ; Mon, 29 Mar 2010 12:39:32 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 15:39:55 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 15:39:55 -0400 From: Hadriel Kaplan To: Jay Daley , Dean Willis Date: Mon, 29 Mar 2010 15:39:56 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPFlKdJXyGQl8XTWuNaGUMJCjnLwAXxkZQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> In-Reply-To: <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79E928FBmail_" MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:39:44 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79E928FBmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay= Daley Sent: Monday, March 29, 2010 4:02 AM To: Dean Willis On 29/03/2010, at 7:19 PM, Dean Willis wrote: 1. ENUM did not originate with carriers trying to pollute the Internet and= the IETF did not bend over backwards to put phone numbers onto the Interne= t. Quite the opposite. There was a lot of opposition to ENUM from ITU typ= es as they saw it as a cunning IETF plot to take over telephony. There are many public ENUM trees (at the country code level), it is hard to= see what is really more in the DNS than that. The success of ENUM in a pr= ivate context is surprising given the original hostility to ENUM from some = carriers, but is not an indication that this is a private protocol. Most carriers I've talked to were not hostile to ENUM using DNS the protoco= l - they were hostile to the data being put in The DNS. They actually like= the properties of the protocol, a lot. Carriers are not working against the best interests of the Internet, they a= re just trying to bring their experience, their values and their way of wor= king to the Internet. You might disagree with those but nobody holds the k= eys to the Internet, that is the whole point. I think you misunderstand Dean - he's being the messenger, not the source. = That's part of his role as the BOF Chair. 3. I don't mean to be rude but I don't think you understand DNS at all. F= or a start we are not taking about making changes to the DNS at all because= NAPTR already exists. All we are talking about it a standard data repres= entation within NAPTR. Actually he's relaying the comments he got from other IETF folks, again as = his role as BOF Chair and trying to help us move forward. And for some of = the mechanisms we need for ENUM, some IETF members appear to feel it is a c= hange to The DNS. Not a change to the protocol, perhaps, but to the databa= se. We've heard it consistently for the past 2 years: "this stuff doesn't = belong in The DNS". I and you and others feel there's nothing wrong with p= utting the data we want into The DNS, but if we have to get every piece of = data we want past a consensus call as well as the IESG, then we should to l= isten to them. -hadriel --_000_430FC6BDED356B4C8498F634416644A91A79E928FBmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: e2md-bou= nces@ietf.org [mailto:e2md-bounces@ietf.org] On Behal= f Of Jay Daley
Sent: Monday, March 29, 2010= 4:02 AM
To: Dean Willis

On 29/03/2010, at 7:19 PM, Dean Willis<= /st1:PersonName> wrote:

 

1.  ENUM did not originate with carriers trying to pollute the Internet and the IETF did not bend over backwards to put phone numbers onto= the Internet.  Quite the opposite.  There was a lot of opposition to = ENUM from ITU types as they saw it as a cunning IETF plot to take over telephony.   

There are many public ENUM trees (at the country code level), it is hard to see what is really more in the DNS than that.  The success of = ENUM in a private context is surprising given the original hostility to ENUM fro= m some carriers, but is not an indication that this is a private protocol.

<= span style=3D'font-size:12.0pt;color:navy'> 

Most carriers I’ve talked to wer= e not hostile to ENUM using DNS the protocol – they were hostile to the dat= a being put in The DNS.  They actually like the properties of the protoc= ol, a lot.

 

Carriers are not working against the best interests of the Internet= , they are just trying to bring their experience, their values and their way = of working to the Internet.  You might disagree with those but nobody hol= ds the keys to the Internet, that is the whole point.=

<= span style=3D'font-size:12.0pt;color:navy'> 

I think you misunderstand Dean –= he’s being the messenger, not the source.  That’s part of his role as= the BOF Chair.

 

3.  I don't mean to be rude but I don't think you understand D= NS at all.  For a start we are not taking about making changes to the DNS= at all because NAPTR already exists.   All we are talking about it a stan= dard data representation within NAPTR.  

<= span style=3D'font-size:12.0pt;color:navy'> 

<= span style=3D'font-size:12.0pt;color:navy'>Actually he’s relaying the comm= ents he got from other IETF folks, again as his role as BOF Chair and trying to = help us move forward.  And for some of the mechanisms we need for ENUM, som= e IETF members appear to feel it is a change to The DNS.  Not a change to the protocol, perhaps, but to th= e database.  We’ve heard it consistently for the past 2 years: = 220;this stuff doesn’t belong in The DNS”.  I and you and others fe= el there’s nothing wrong with putting the data we want into The DNS, but= if we have to get every piece of data we want past a consensus call as well as= the IESG, then we should to listen to them.

<= span style=3D'font-size:12.0pt;color:navy'> 

<= span style=3D'font-size:12.0pt;color:navy'>-hadriel

--_000_430FC6BDED356B4C8498F634416644A91A79E928FBmail_-- From jay@nzrs.net.nz Mon Mar 29 12:44:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588FE3A691B for ; Mon, 29 Mar 2010 12:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tByQtc11eHF for ; Mon, 29 Mar 2010 12:44:32 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id BC3193A67D2 for ; Mon, 29 Mar 2010 12:44:31 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 80E112DA369; Tue, 30 Mar 2010 08:44:59 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02ozzHuS2UFR; Tue, 30 Mar 2010 08:44:59 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 0B3642DA277; Tue, 30 Mar 2010 08:44:59 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-254--473077232 From: Jay Daley In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529B8B@TNS-MAIL-NA.win2k.corp.tnsi.com> Date: Tue, 30 Mar 2010 08:44:58 +1300 Message-Id: <03B43004-489B-431C-A0E6-1C2D8676EF54@nzrs.net.nz> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <754963199212404AB8E9CFCA6C3D0CDA1F69529B8B@TNS-MAIL-NA.win2k.corp.tnsi.com> To: "Cartwright, Kenneth" X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:44:34 -0000 --Apple-Mail-254--473077232 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 30/03/2010, at 4:25 AM, Cartwright, Kenneth wrote: > I=92d tend to agree with most of what Jay has said below. > =20 > The only exception being that my goal of supporting E2U and E2M is not = to =93get this data out in the open=94 (and I=92m not entirely sure what = you mean by that), but is instead to enable existing use cases in a more = standardized, and more fully baked manner. > =20 > Getting data =93out in the open=94 is a more of a policy decision that = the IETF does not really play a role in. But creating technical = standards for enabling use cases in a more standardized and fully baked = fashion is definitely the role of the IETF. Apologies, I do agree but I'd already written too much by then to = explain this properly. =20 cheers Jay > =20 > Ken > =20 > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Jay Daley > Sent: Monday, March 29, 2010 4:02 AM > To: Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is = stalling > =20 > =20 > On 29/03/2010, at 7:19 PM, Dean Willis wrote: >=20 >=20 > I suspect that part of the problem is that ENUM isn't REALLY in "the = DNS". Some IETFers probably feel like they bent over backsards to put = phone numbers into the scope of the Internet, and then the phone = oeprators went and did these private ENUM things (which might use DNS = technology but aren't "the DNS"), thereby making a walled-garden even = more walled. Why should we do funky things to a core Internet technology = in order to facilitate the priavte non-Internet use of somebody who has = already proven not to be working on the best interest of the Internet? >>=20 >> That said, there are people in the IETF who are interested in = providing a high-speed distributed hierarchical database for = phone-numbers and related data. However, those people just don't = constitue a large enough chunk of the DNS leadership to be able to make = changes to the DNS. But a closely-related technology that uses lessons = learns fom the DNS but that is itself not the DNS would probably make = the metadata problem more attractive to the IETF DNS pundits. > =20 > I finally understand where you are coming from! There is so much to = pick up on in your post that this is quite a long response, apologies in = advance for that. > =20 > 1. ENUM did not originate with carriers trying to pollute the = Internet and the IETF did not bend over backwards to put phone numbers = onto the Internet. Quite the opposite. There was a lot of opposition = to ENUM from ITU types as they saw it as a cunning IETF plot to take = over telephony. =20 > =20 > There are many public ENUM trees (at the country code level), it is = hard to see what is really more in the DNS than that. The success of = ENUM in a private context is surprising given the original hostility to = ENUM from some carriers, but is not an indication that this is a private = protocol. > =20 > Carriers are not working against the best interests of the Internet, = they are just trying to bring their experience, their values and their = way of working to the Internet. You might disagree with those but = nobody holds the keys to the Internet, that is the whole point. > =20 > 2. You are confusing 'the DNS' with 'the IANA root'. You are right = to describe the use of ENUM in private networks as a walled garden but = for the wrong reasons. It is not the private use of an Internet = protocol you should be blaming as that happens everywhere in other = contexts. For example EPP is only ever used within a contractual = framework. There is no such thing as a public EPP server. What is = 'walled' about private ENUM is the data in those trees. > =20 > What I want from e2md and many others I suspect also want, is to get = that data out into the open. Probably not in the e164.arpa tree but = certainly the public DNS.=20 > =20 > 3. I don't mean to be rude but I don't think you understand DNS at = all. For a start we are not taking about making changes to the DNS at = all because NAPTR already exists. All we are talking about it a = standard data representation within NAPTR. To suggest creating a = technology that is similar to DNS but is not DNS is both impractical as = it means an extraordinary volume of work and unnecessary because DNS and = ENUM already exists. > =20 > It appears to me from your statements above that all the various = objections, rat holes, mis-respresentations and distractions that you = have raised on this list are entirely of a political layer-9 origin and = in no way technical. Ironic since it the IETF way that you claim to be = defending. > =20 > regards > Jay >=20 >=20 >=20 > -- > Dean >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > =20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > =20 >=20 > This e-mail message is for the sole use of the intended = recipient(s)and may > contain confidential and privileged information of Transaction Network = Services. > Any unauthorised review, use, disclosure or distribution is = prohibited. If you > are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 --Apple-Mail-254--473077232 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 30/03/2010, at 4:25 AM, = Cartwright, Kenneth wrote:

I=92d tend to agree with most = of what Jay has said below.
The only exception being that my goal of supporting E2U = and E2M is not to =93get this data out in the open=94 (and I=92m not = entirely sure what you mean by that), but is instead to enable existing = use cases in a more standardized, and more fully baked = manner.
 
Getting data =93out in the = open=94 is a more of a policy decision that the IETF does not really = play a role in.  But creating technical standards for enabling use = cases in a more standardized and fully baked fashion is definitely the = role of the = IETF.

Apologies, I do agree but I'd already written too much by then to = explain this properly. =  

cheers
Jay

I’d tend to agree with most of w= hat Jay has said below.

 

The only exception being that my goal = of supporting E2U and E2M is not to “get this data out in the open= 221; (and I’m not entirely sure what you mean by that), but is instead to enable existing use cases in a m= ore standardized, and more fully baked manner.

 

Getting data “out in the open= 221; is a more of a policy decision that the IETF does not really play a ro= le in.  But creating technical standards for enabling use cases in a more standardized and fully baked fashion is d= efinitely the role of the IETF.

 

Ken

 

From: e2md= -bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay Daley
Sent: Monday, March 29, 2010= 4:02 AM
To: Dean Willis
Cc: E.164 To MetaData BOF di= scussion list
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 

 

On 29/03/2010, at 7:19 PM, Dean Willis wrote:



I suspect that part of the problem is that ENUM isn't REALLY in &qu= ot;the DNS". Some IETFers probably feel like they bent over backsards = to put phone numbers into the scope of the Internet, and then the phone oeprators went and did these private E= NUM things (which might use DNS technology but aren't "the DNS"),= thereby making a walled-garden even more walled. Why should we do funky th= ings to a core Internet technology in order to facilitate the priavte non-Internet use of somebody who has already pro= ven not to be working on the best interest of the Internet?


That said, there are people in the IETF who are interested in= providing a high-speed distributed hierarchical database for phone-numbers= and related data.  However, those people just don't constitue a large= enough chunk of the DNS leadership to be able to make changes to the DNS. But a  closely-related technology= that uses lessons learns fom the DNS but that is itself not the DNS would = probably make the metadata problem more attractive to the IETF DNS pundits.=

 

I finally understand where you are coming from!  There is so m= uch to pick up on in your post that this is quite a long response, apologie= s in advance for that.

 

1.  ENUM did not originate with carriers trying to pollute the= Internet and the IETF did not bend over backwards to put phone numbers ont= o the Internet.  Quite the opposite.  There was a lot of opposition to ENUM from ITU types as they saw it = as a cunning IETF plot to take over telephony.   =

 

There are many public ENUM trees (at the country code level), it is= hard to see what is really more in the DNS than that.  The success of= ENUM in a private context is surprising given the original hostility to ENUM from some carriers, but is= not an indication that this is a private protocol.

 

Carriers are not working against the best interests of the Internet= , they are just trying to bring their experience, their values and their wa= y of working to the Internet.  You might disagree with those but nobody holds the keys to the Inter= net, that is the whole point.

 

2.  You are confusing 'the DNS' with 'the IANA root'.   Y= ou are right to describe the use of ENUM in private networks as a wall= ed garden but for the wrong reasons.   It is not the private use of an Internet protocol you should be blami= ng as that happens everywhere in other contexts.  For example EPP is o= nly ever used within a contractual framework.  There is no such thing = as a public EPP server.  What is 'walled' about private ENUM is the data in those trees.

 

What I want from e2md and many others I suspect also want, is to ge= t that data out into the open.  Probably not in the e164.arpa tree but= certainly the public DNS. 

 

3.  I don't mean to be rude but I don't think you understand D= NS at all.  For a start we are not taking about making changes to the = DNS at all because NAPTR already exists.   All we are talking about it a standard data representation = within NAPTR.  To suggest creating a technology that is similar to DNS= but is not DNS is both impractical as it means an extraordinary volume of = work and unnecessary because DNS and ENUM already exists.

 

It appears to me from your statements above that all the various ob= jections, rat holes, mis-respresentations and distractions that you have ra= ised on this list are entirely of a political layer-9 origin and in no way technical.  Ironic since = it the IETF way that you claim to be defending.

 

regards

Jay




--
Dean


_______________________________________________
e2md mailing list
e2md@ietf.org
https://www.ietf.org/mailman/listinfo/e2md

 

=
-- 

= Jay Daley=

= Chief Exe= cutive

= .nz Regis= try Services (New Zealand Domain Name Registry Limited)

= desk: = 3;64 4 931 6977

= mobile: &= #43;64 21 678840

 

 
 
From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org= ] On Behalf Of Jay = Daley
Sent: Monday, March 29, 2010 4:02 = AM
To: Dean Willis
Cc: E.164 To MetaData BOF = discussion list
 Re: [e2md] E2MD, ENUM, and = the DNS: why our approach is = stalling
On = 29/03/2010, at 7:19 PM, Dean Willis = wrote:
I suspect = that part of the problem is that ENUM isn't REALLY in "the DNS". Some = IETFers probably feel like they bent over backsards to put phone numbers = into the scope of the Internet, and then the phone oeprators went and = did these private ENUM things (which might use DNS technology but aren't = "the DNS"), thereby making a walled-garden even more walled. Why should = we do funky things to a core Internet technology in order to facilitate = the priavte non-Internet use of somebody who has already proven not to = be working on the best interest of the = Internet?

That said, = there are people in the IETF who are interested in providing a = high-speed distributed hierarchical database for phone-numbers and = related data.  However, those people just don't constitue a large = enough chunk of the DNS leadership to be able to make changes to the = DNS. But a  closely-related technology that uses lessons learns fom = the DNS but that is itself not the DNS would probably make the metadata = problem more attractive to the IETF DNS = pundits.
I finally understand where you are coming from!  There is = so much to pick up on in your post that this is quite a long response, = apologies in advance for = that.
1.  ENUM did not originate with carriers trying to pollute = the Internet and the IETF did not bend over backwards to put phone = numbers onto the Internet.  Quite the opposite.  There was a = lot of opposition to ENUM from ITU types as they saw it as = a cunning IETF plot to take over telephony. =   
 
There are many public ENUM trees (at the country code level), it = is hard to see what is really more in the DNS than that.  The = success of ENUM in a private context is surprising given the original = hostility to ENUM from some carriers, but is not an indication that this = is a private protocol.
 
Carriers are not working against the best interests of the = Internet, they are just trying to bring their experience, their values = and their way of working to the Internet.  You might disagree with = those but nobody holds the keys to the Internet, that is the whole = point.
2.  You are confusing 'the DNS' with 'the IANA root'. =   You are right to describe the use of ENUM in private = networks as a walled garden but for the wrong reasons.   It is not = the private use of an Internet protocol you should be blaming as = that happens everywhere in other contexts.  For example EPP is only = ever used within a contractual framework.  There is no such thing = as a public EPP server.  What is 'walled' about private ENUM is the = data in those trees.
 
What I want from e2md and many others I suspect also want, is to = get that data out into the open.  Probably not in the e164.arpa = tree but certainly the public = DNS. 
 
3.  I don't mean to be rude but I don't think you = understand DNS at all.  For a start we are not taking about making = changes to the DNS at all because NAPTR already exists.   All we = are talking about it a standard data representation within NAPTR. =  To suggest creating a technology that is similar to DNS but is not = DNS is both impractical as it means an extraordinary volume of work and = unnecessary because DNS and ENUM already = exists.
 
It appears to me from your statements above that all the various = objections, rat holes, mis-respresentations and distractions that you = have raised on this list are entirely of a political layer-9 origin and = in no way technical.  Ironic since it the IETF way that you claim = to be defending.
 
regards
Jay


-- 
Jay = Daley
Chief Executive
.nz Registry Services (New = Zealand Domain Name Registry Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840

= --Apple-Mail-254--473077232-- From dean.willis@softarmor.com Mon Mar 29 12:45:58 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3607A3A691B for ; Mon, 29 Mar 2010 12:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.713 X-Spam-Level: X-Spam-Status: No, score=0.713 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xcc-ykoXwWl for ; Mon, 29 Mar 2010 12:45:57 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7B7F13A68F9 for ; Mon, 29 Mar 2010 12:45:56 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TJkKQ7007706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 14:46:22 -0500 Message-Id: <2C413F71-1DBA-4761-8FFA-4631D3C9D3F0@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 14:46:15 -0500 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:45:58 -0000 On Mar 29, 2010, at 2:39 PM, Hadriel Kaplan wrote: > > > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf =20= > Of Jay Daley > Sent: Monday, March 29, 2010 4:02 AM > To: Dean Willis > > On 29/03/2010, at 7:19 PM, Dean Willis wrote: > > 1. ENUM did not originate with carriers trying to pollute the =20 > Internet and the IETF did not bend over backwards to put phone =20 > numbers onto the Internet. Quite the opposite. There was a lot of =20= > opposition to ENUM from ITU types as they saw it as a cunning IETF =20 > plot to take over telephony. > There are many public ENUM trees (at the country code level), it is =20= > hard to see what is really more in the DNS than that. The success =20 > of ENUM in a private context is surprising given the original =20 > hostility to ENUM from some carriers, but is not an indication that =20= > this is a private protocol. > > Most carriers I=92ve talked to were not hostile to ENUM using DNS the =20= > protocol =96 they were hostile to the data being put in The DNS. They = =20 > actually like the properties of the protocol, a lot. > > Carriers are not working against the best interests of the Internet, =20= > they are just trying to bring their experience, their values and =20 > their way of working to the Internet. You might disagree with those =20= > but nobody holds the keys to the Internet, that is the whole point. > > I think you misunderstand Dean =96 he=92s being the messenger, not the = =20 > source. That=92s part of his role as the BOF Chair. > > 3. I don't mean to be rude but I don't think you understand DNS at =20= > all. For a start we are not taking about making changes to the DNS =20= > at all because NAPTR already exists. All we are talking about it a =20= > standard data representation within NAPTR. > > Actually he=92s relaying the comments he got from other IETF folks, =20= > again as his role as BOF Chair and trying to help us move forward. =20= > And for some of the mechanisms we need for ENUM, some IETF members =20 > appear to feel it is a change to The DNS. Not a change to the =20 > protocol, perhaps, but to the database. We=92ve heard it consistently = =20 > for the past 2 years: =93this stuff doesn=92t belong in The DNS=94. I = and =20 > you and others feel there=92s nothing wrong with putting the data we =20= > want into The DNS, but if we have to get every piece of data we want =20= > past a consensus call as well as the IESG, then we should to listen =20= > to them. > > Thank you, Hadriel! -- Dean= From HKaplan@acmepacket.com Mon Mar 29 12:47:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8625E3A691B for ; Mon, 29 Mar 2010 12:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6trTvu8QkFMx for ; Mon, 29 Mar 2010 12:47:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AA9EA3A68F9 for ; Mon, 29 Mar 2010 12:47:11 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 15:47:39 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 15:47:39 -0400 From: Hadriel Kaplan To: Otmar Lendl , "e2md@ietf.org" Date: Mon, 29 Mar 2010 15:47:40 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrPNB96UeEt30iRSSmniUBSchd7kAAQ5d3g Message-ID: <430FC6BDED356B4C8498F634416644A91A79E928FF@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB090B8.5050804@nic.at> In-Reply-To: <4BB090B8.5050804@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:47:12 -0000 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Otmar Lendl > Sent: Monday, March 29, 2010 7:36 AM >=20 > > 2) The ability to determine the "source" of the query in a standardized > > manner. Hadriel has a proposal out there on a way to do this. But, > > again, ***this is a broader subject and should definitely be handled as > > a separate discussion track***. >=20 > Again, this requirement contradicts one of the core design principles of > the DNS architecture. >=20 > Yes, Hadrian's draft provides an idea on how one could retrofit the DNS t= o > accommodate this wish, but that's a very ugly hack. Huh, I thought is was an elegant hack. :) It's not changing the structure of DNS - it just gives the server additiona= l data with which it can filter the response. I.e., the server has a big l= ist of matching NAPTRs for the query key, but the extension gives it a filt= er to apply to reduce the set it gives back in the response.=20 -hadriel p.s., it's "Hadriel" - hopefully my comments have not created a wall in Bri= tain. ;) From kcartwright@tnsi.com Mon Mar 29 12:47:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E623A6AFD for ; Mon, 29 Mar 2010 12:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.93 X-Spam-Level: X-Spam-Status: No, score=0.93 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcVx1nuvHG0f for ; Mon, 29 Mar 2010 12:47:43 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id BEFD73A6B68 for ; Mon, 29 Mar 2010 12:47:42 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42016934; Mon, 29 Mar 2010 15:48:05 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 15:48:05 -0400 From: "Cartwright, Kenneth" To: Dean Willis , Hadriel Kaplan Date: Mon, 29 Mar 2010 15:48:03 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPeIrf3kZnLJamRr2iZmohBXZSfAAAC2fQ Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529DF1@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <2C413F71-1DBA-4761-8FFA-4631D3C9D3F0@softarmor.com> In-Reply-To: <2C413F71-1DBA-4761-8FFA-4631D3C9D3F0@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:47:44 -0000 Point taken. :-) -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dea= n Willis Sent: Monday, March 29, 2010 3:46 PM To: Hadriel Kaplan Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling On Mar 29, 2010, at 2:39 PM, Hadriel Kaplan wrote: > > > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf > Of Jay Daley > Sent: Monday, March 29, 2010 4:02 AM > To: Dean Willis > > On 29/03/2010, at 7:19 PM, Dean Willis wrote: > > 1. ENUM did not originate with carriers trying to pollute the > Internet and the IETF did not bend over backwards to put phone > numbers onto the Internet. Quite the opposite. There was a lot of > opposition to ENUM from ITU types as they saw it as a cunning IETF > plot to take over telephony. > There are many public ENUM trees (at the country code level), it is > hard to see what is really more in the DNS than that. The success > of ENUM in a private context is surprising given the original > hostility to ENUM from some carriers, but is not an indication that > this is a private protocol. > > Most carriers I've talked to were not hostile to ENUM using DNS the > protocol - they were hostile to the data being put in The DNS. They > actually like the properties of the protocol, a lot. > > Carriers are not working against the best interests of the Internet, > they are just trying to bring their experience, their values and > their way of working to the Internet. You might disagree with those > but nobody holds the keys to the Internet, that is the whole point. > > I think you misunderstand Dean - he's being the messenger, not the > source. That's part of his role as the BOF Chair. > > 3. I don't mean to be rude but I don't think you understand DNS at > all. For a start we are not taking about making changes to the DNS > at all because NAPTR already exists. All we are talking about it a > standard data representation within NAPTR. > > Actually he's relaying the comments he got from other IETF folks, > again as his role as BOF Chair and trying to help us move forward. > And for some of the mechanisms we need for ENUM, some IETF members > appear to feel it is a change to The DNS. Not a change to the > protocol, perhaps, but to the database. We've heard it consistently > for the past 2 years: "this stuff doesn't belong in The DNS". I and > you and others feel there's nothing wrong with putting the data we > want into The DNS, but if we have to get every piece of data we want > past a consensus call as well as the IESG, then we should to listen > to them. > > Thank you, Hadriel! -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jay@nzrs.net.nz Mon Mar 29 12:59:23 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB243A694E for ; Mon, 29 Mar 2010 12:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiiifZkCH5g6 for ; Mon, 29 Mar 2010 12:59:22 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 833423A692B for ; Mon, 29 Mar 2010 12:59:09 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id AA8F52DA7A9; Tue, 30 Mar 2010 08:59:36 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97wfOFho+M5n; Tue, 30 Mar 2010 08:59:36 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 27D2F2DA237; Tue, 30 Mar 2010 08:59:36 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-255--472200313 From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> Date: Tue, 30 Mar 2010 08:59:35 +1300 Message-Id: References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 19:59:23 -0000 --Apple-Mail-255--472200313 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 30/03/2010, at 8:39 AM, Hadriel Kaplan wrote: >=20 > Most carriers I=92ve talked to were not hostile to ENUM using DNS the = protocol =96 they were hostile to the data being put in The DNS. They = actually like the properties of the protocol, a lot. Very different from the echoes I heard - "it doesn't have channel = security", "it doesn't have guaranteed delivery", "it doesn't have = deterministic response times", "the data is in a weird (i.e. non-XML) = format" and so on. > Carriers are not working against the best interests of the Internet, = they are just trying to bring their experience, their values and their = way of working to the Internet. You might disagree with those but = nobody holds the keys to the Internet, that is the whole point. > =20 > I think you misunderstand Dean =96 he=92s being the messenger, not the = source. That=92s part of his role as the BOF Chair. Sorry but that is just not the case. If that was solely the voice of = the messenger and not his own views then I'll put on a frilly dress and = sing the Marseillaise on the Wellington waterfront. I can sleep soundly = knowing that won't happen. > =20 > 3. I don't mean to be rude but I don't think you understand DNS at = all. For a start we are not taking about making changes to the DNS at = all because NAPTR already exists. All we are talking about it a = standard data representation within NAPTR. =20 > =20 > Actually he=92s relaying the comments he got from other IETF folks, = again as his role as BOF Chair and trying to help us move forward. And = for some of the mechanisms we need for ENUM, some IETF members appear to = feel it is a change to The DNS. Not a change to the protocol, perhaps, = but to the database. We=92ve heard it consistently for the past 2 = years: =93this stuff doesn=92t belong in The DNS=94. I and you and = others feel there=92s nothing wrong with putting the data we want into = The DNS, but if we have to get every piece of data we want past a = consensus call as well as the IESG, then we should to listen to them. I can understand that some people think it is a change to the database = not the protocol but that is a sophisticated view, not related to what = Dean is saying and does not change my view that Dean does not understand = DNS at all, there is too much clear evidence to support that. You and I know that when someone says "put it into a TXT record" that = means two things: 1. They're not objecting to a change in the database, because if they = were then they would not suggest keeping the same data in DNS. 2. They don't understand DNS. best Jay > =20 > -hadriel --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 --Apple-Mail-255--472200313 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252


Most carriers I=92ve talked to = were not hostile to ENUM using DNS the protocol =96 they were hostile to the data being put in The DNS.  They actually like the properties of the = protocol, a = lot.


Very different from the echoes I heard = - "it doesn't have channel security", "it doesn't have guaranteed = delivery", "it doesn't have deterministic response times", "the data is = in a weird (i.e. non-XML) format" and so on.

 Carriers are not working against the best interests = of the Internet, they are just trying to bring their experience, their values and their = way of working to the Internet.  You might disagree with those but nobody = holds the keys to the Internet, that is the whole = point.

 

<= p class=3D"MsoNormal">I think you misunderstand Dean =96 = he=92s being the messenger, not the source.  That=92s part of his role as = the BOF = Chair.


Sorry but that is just not the = case.  If that was solely the voice of the messenger and not his = own views then I'll put on a frilly dress and sing the Marseillaise on = the Wellington waterfront.  I can sleep soundly knowing that won't = happen.

 

3.  I don't mean to be rude but I don't think you = understand DNS at all.  For a start we are not taking about making changes to the = DNS at all because NAPTR already exists.   All we are talking about it a = standard data representation within NAPTR.  

 

<= p class=3D"MsoNormal">Actually he=92s = relaying the comments he got from other IETF folks, again as his role as BOF Chair and trying = to help us move forward.  And for some of the mechanisms we need for ENUM, = some IETF members appear to feel it is a change to The DNS.  Not a change to the protocol, perhaps, but to = the database.  We=92ve heard it consistently for the past 2 years: = =93this stuff doesn=92t belong in The DNS=94.  I and you and others feel there=92s nothing wrong with putting the data we want into The DNS, but = if we have to get every piece of data we want past a consensus call as well = as the IESG, then we should to listen to = them.


I can understand that some people = think it is a change to the database not the protocol but that is a = sophisticated view, not related to what Dean is saying and does not = change my view that Dean does not understand DNS at all, there is too = much clear evidence to support that.

You and I = know that when someone says "put it into a TXT record" that means two = things:

1.  They're not objecting to a = change in the database, because if they were then they would not suggest = keeping the same data in DNS.
2.  They don't understand = DNS.

best
Jay

 

<= p class=3D"MsoNormal">-hadriel


-- 
Jay = Daley
Chief Executive
.nz Registry Services (New = Zealand Domain Name Registry Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840

= --Apple-Mail-255--472200313-- From dean.willis@softarmor.com Mon Mar 29 13:01:10 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD593A689A for ; Mon, 29 Mar 2010 13:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqOqqU8AcYVb for ; Mon, 29 Mar 2010 13:01:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ECFF03A680F for ; Mon, 29 Mar 2010 13:01:08 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TK1R0Z007823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 15:01:29 -0500 Message-Id: From: Dean Willis To: "E.164 To MetaData BOF discussion list" Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 15:01:22 -0500 X-Mailer: Apple Mail (2.936) Cc: Olaf Kolkman , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , John C Klensin , pk@ISOC.DE Subject: [e2md] Revised draft minutes of E2MD BOF at IETF 77 X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:01:10 -0000 Bernie and I have made some further cleanup on the draft minutes of =20 the recent E2MD BOF. If you have any further feedback, please get it =20 back to us ASAP. Draft minutes follow: Draft Minutes for E2MD at IETF 77 based on notes by John Elwell Jabber session scribed by Patrik F=E4ltstr=F6m edited by Bernie H=F6neisen, Dean Willis Meeting started approximately 10 minute late due to delay in room exit by prior group and equipment problems. Both chair's personal computers kernel-panicked on connecting to the projector, and an attendees' =20 machine was pressed into service. Subsequently, the cord fell out of the main microphone. Chairs verbally reviewed "Note Well" and agenda, but did not present related slides due to equipment delay. Chair declared that the question for today's meeting was whether we should form a working group to solve the problems that will be discussed today using the general approach of a new DDDS based on ENUM. Chair noted prior guidance from the IESG is that such a specification would need to be written as if it were to be used on the public Internet, even though use in private networks is more common. AD Cullen Jennings declared that this was not necessarily the case, and the group should first decide what it wants to do. John Klensin suggested that if the work result is not intended for the public Internet then it should be renamed, because a name like E2MD implies a parallel to ENUM, which really was intended for the public Internet during its conceptualization phase. The chairs stated that the basic idea is similar to ENUM, but instead of mapping the E.164 number to a URI that identifies the resource labeled by the E.164 number, we are mapping the E.164 number to information about that phone number. Topic: Problem Statement and Use Cases led by Bernie Hoeneisen Slides presented reviewed several use cases under discussion: * "unused" use case introduced by Bernie * "send-n" use case introduced by Ray Bellis * "cnam" use case introduced by Richard Shockey * "Global Service Provider Identifier" use case introduced by Bernie Noted that the ENUM working group agreed a draft on the CNAM use case, and that the DRINKS working group earlier this week had discussed mechanisms for provisioning a global service provider identifier. Jon Peterson asked: What is metadata? These 3 use cases are all rather different - is there really anything in common? Debate ensued, with the one commonality noted that all the data in question has in common that it is keyed by the E.164 number and might be needed either when starting or accepting a session using that E.164 number as its target or source. Bernie noted that ENUM had different kinds and classes of ENUM services, and had provided a classification mechanism as part of the IANA registration document. Ray Bellis responded, discussing the relationships between the send-n and unused cases with ENUM. Both send-n and unused are helpful in resolving ENUM lookups and need to be done in conjunction with the ENUM lookup, literally at the same time. John Klensin challenged the assumption that the DNS is a good place to keep this data, noting that we have a lot of other information that might be keyed by the phone number but that we do not store in the DNS. Further, storing data in the DNS with record types that lead to a potential for contradictions or unclear semantics gives a potential for abuse of the DNS. We will need to be able to say why each piece of metadata is important enough to put it into the DNS, Bernie noted that the DNS is a good way of distributing the responsibility, and that the delegation structures and relationships of the metadata in question are identical to those of ENUM. Dean reported that John's question had already been discussed on the mailing list, and the sense of mailing list was that we already have the phone number keyed structure from ENUM and we need the same hierarchical and caching characteristics, so any new protocol would need 90% functionality of DNS making it not worth inventing something new. Peter Koch noted that CNAM is rather different from the other use cases. For send-n, he doesn't believe that the problems with the proposal are removed by using E2MD rather than ENUM -- that it makes no difference what the string in NAPTR is. He suggested that killing the whole dependency on ENUM stuff and doing a roll-over not based on NAPTR may be a better approach. Olaf Kolkman agreed that the ENUM tree matches well with hierarchy, but wondered what form of query/search systems might be needed. For example, if we need to search for metadata with a specific number, it might be better to have a service just for that. He suggested that it might be good idea to look for different tools for this problems. Dean noted that this had come up in on-list discussion, and that the later discussion would touch on using E2MD to find a URI for a metadata service. Dean noted that the existing use cases had been debated on the list and that the list felt that DNS was a good match for these use cases, but that we would need to provide guidance on evaluating future use cases as. John Klensin noted that when we did the ENUM work, we mapped phone numbers to DNS for a a specific reason, but assumption that numbers were well matched to DNS would be wrong. The inverse ordering model creates a vast number of DNS hierarchy levels and is not particularly optimal. Richard Shockey responded that ENUM does work well, and is deployed in a number of trees. Practical experience shows that it would work equally well for other types of data. Jon Peterson noted that ENUM kept running into security properties, and the constraints in E2MD may prove to be even more restrictive. Richard Shockey noted that there are many successful ENUM deployments in private environments, and that this resolves most of the security issues. Andrew Sullivan suggested that the problem is that there a tiny part of DNS that is not a good fit, but if that is an important part, then we should reconsider using DNS as the basis for E2MD. Topic: Issues from List led by Dean Willis Issue: DNS record size. List discussion agrees that the E2MD space in DNS is size constrained, and that each use case will have to be analyzed for suitability and unsuitable use cases rejected. further, the group agrees that they will have to produce guidance documents for future reviewers of use cases. Cullen challenged the group to scope this so it would be approvable, apparently asking for the review guidelines to be finalized before the work is done. He proposed a use case of putting a ring-tone into the DNS, and asked how we would evaluate it. Discussion ensued, with some participants maintaining that this is a valid use case, others suggesting that this was a bad idea and that it would perhaps be reasonable to insert a URI that indicates a ring tone. Lawrence Conroy noted (via remote) that an upper bound on size is probably 250 bytes. Issue: Is everything a NAPTR? Jon Peterson observed that this goes beyond just CNAM not being like the others. Why should we use NAPTR, if we have to do some kludge on the data just to make it fit into a NAPTR record Patrik F=E4ltstr=F6m noted that there had been a number of problems with NAPTR record with ENUM, so perhaps we shouldn't use it for this, in the same way we should not have for ENUM. Need to see what record types match and perhaps use a better choice, rather than just following ENUM. Jon noted that it is improbable that one RR type would fit all use cases, and that we would therefore have to look at each use case separately. This suggests that we do not need an overall framework for metadata, but should charter work for individual metadata use cases. Discussion moved onto response filtering and aggregation. Spencer suggested that having a profusion of reseource record types might be even scarier than everything being one NAPTR or one container. Dean noted that multiple RR types might be one approach, and that various other filtering techniques might be applied. For example, the underscore prefixing used with SRV records might give a clue to another possibility. Question: How large are the responses. Dean responded that with many use cases feeding into a NAPTR RR-set we might have very large responses. Dave Crocker observed that our current discussion is about low level implementation choices. We need to or might do lots of different things, but without very specific use cases as goals, we have no way to select an approach. He also berated the group for not having considered underscore prefixes as used in SRV records. Dean noted that we do have 4 specific use cases under discussion, with I-Ds on 3. Bernie stated that about 10 more have been proposed to the list. Jon asked what these use cases have in common? Dean responded that the information is indexed by the phone number and used when either setting up or answering a call, to which Jon disagreed without further explanation being recorded. David Schwartz noted that the common factor is not "has to do with call routing", since the CNAM proposal clearly doesn't. Issue: Registration Procedure Current document suggests Specification Required (with Expert Review procedures TBD) Cullen supposed that if ENUM were 1st come 1st served, we would not be having this BoF (we would have just done it in ENUM, with the implication that this would have been a Bad Thing). Richard Shockey noted that the proposed process follows ENUM as closely as possible, as the ENUM process has been shown to work. Conclusion: Polls of the Room Poll: Who thinks there is something worth looking it? A lot of people raised hands. Poll: Who thinks DNS is a suitable basis? Dave Crocker declared that since we don't have specific set of problems there is no rationale for deciding whether DNS is the right basis. Chair responded by moving to discussion of specifc use cases. Poll: Who agrees DNS is suitable for CNAM: 10 for, 3 against. Poll: (asked by Richard) We are debating solutions before we establish a charter.Is this a problem that we in IETF can solve, are there people who would like to fix problems? Response was mixed. Christer asked that if we assumes SIP is the main usage, can we solve CNAM with SIP OPTIONS? Dean responded that it is doable with a SIP event package, and that this approach had been previously suggested. Gonzalo suggested following up with questions from the "How to have a successful BOF" list such as "should a WG with the following charter be formed?" Poll: Who thinks the problem space has been clarified by the current drafts and proposed charter such that we understand the proposed scope? Mixed response. Poll: Are there people who want to solve problem: a fairly large number. Poll: Who has read the proposed charter? A large percentage responded. Poll: Who thinks the proposed charter is close to being usable? Response generally favored the negative. Poll: Who thinks the proposed charter is too vague or proposes an untenable approach? Response generally disagreed that the charter was adequate. Gonzalo observed that we didn't really discuss the charter in this room, and we should have asked the question whether we want to propose a WG based on that charter. The chairs, who thought they had just asked that question, merely nodded in response. John Klensin suggested that we should ask who thinks proposed charter it not ready to go. The chair responded that the question had already been asked, and that more people thought it was not ready to go than thought it was ready to go. Chair's conclusion: The problem scope appears to be clearly defined, but the general solution model of defining an open-ended framework is problematic due to concerns about review and approval, and concerns about the general applicability of the ENUM process to encompass the larger metadata problem. Consequently, the proposed charter defines too large a scope. An approach that scales back to solving specific metadata issues one at a time may be more sustainable. Alternately, a solution that strongly revises (or replaces) ENUM might be better tolerated by the community.= From richard@shockey.us Mon Mar 29 13:13:27 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4743A691B for ; Mon, 29 Mar 2010 13:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6Ud+XXNzvxL for ; Mon, 29 Mar 2010 13:13:19 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id AFD2F3A690D for ; Mon, 29 Mar 2010 13:13:17 -0700 (PDT) Received: (qmail 3855 invoked by uid 0); 29 Mar 2010 20:13:45 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 29 Mar 2010 20:13:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=aTwIUyq9UImQwKxc+b688Wp1Cf9+oadW3tS90lvaJ2iPb8CEz28lwvwoAdNiZM3IbXtrrQaavR8VTmZefIiXkrYn3u9b22CHEdacDdvweOmxJytVyWLiEDYnKqmNy5sH; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NwLLF-0003Sh-Dc; Mon, 29 Mar 2010 14:13:45 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Jay Daley'" , "'Dean Willis'" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> Date: Mon, 29 Mar 2010 16:13:41 -0400 Message-ID: <01b101cacf7c$540357c0$fc0a0740$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B2_01CACF5A.CCF1B7C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrPFlKdJXyGQl8XTWuNaGUMJCjnLwAXxkZQAAFQvzA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:13:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01B2_01CACF5A.CCF1B7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As for Dean ..No we should not shoot the messenger ..especially one that has so many guns. I wish there was some focus here on what the problem is. How do we help SIP network operators work better. There is a clear and demonstrable problem that needs to be addressed in SIP PSTN interworking. The discussion is getting wrapped up in orthogonal arguments about what is and is not appropriate use of DNS technology. I almost got the sense in the BOF that folks thought ENUM itself was a mistake. I know John Klensin almost wishes he had never heard the word J We have a mechanism for translating E.164 keys into FOO and it works quite well. We need a mechanism that translates E.164 numbers into other types of FOO otherwise SIP does not work as well as it should. An alternate port IMHO solves a load of problems and I don't see any problem with that. What I have a problem with is bashing up the proposed solutions here without understanding what problem we are trying to fix. This alternate use of DNS technology is well understood and widely deployed. Gee we have split DNS right? From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, March 29, 2010 3:40 PM To: Jay Daley; Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling _____ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay Daley Sent: Monday, March 29, 2010 4:02 AM To: Dean Willis On 29/03/2010, at 7:19 PM, Dean Willis wrote: 1. ENUM did not originate with carriers trying to pollute the Internet and the IETF did not bend over backwards to put phone numbers onto the Internet. Quite the opposite. There was a lot of opposition to ENUM from ITU types as they saw it as a cunning IETF plot to take over telephony. There are many public ENUM trees (at the country code level), it is hard to see what is really more in the DNS than that. The success of ENUM in a private context is surprising given the original hostility to ENUM from some carriers, but is not an indication that this is a private protocol. Most carriers I've talked to were not hostile to ENUM using DNS the protocol - they were hostile to the data being put in The DNS. They actually like the properties of the protocol, a lot. Carriers are not working against the best interests of the Internet, they are just trying to bring their experience, their values and their way of working to the Internet. You might disagree with those but nobody holds the keys to the Internet, that is the whole point. I think you misunderstand Dean - he's being the messenger, not the source. That's part of his role as the BOF Chair. 3. I don't mean to be rude but I don't think you understand DNS at all. For a start we are not taking about making changes to the DNS at all because NAPTR already exists. All we are talking about it a standard data representation within NAPTR. Actually he's relaying the comments he got from other IETF folks, again as his role as BOF Chair and trying to help us move forward. And for some of the mechanisms we need for ENUM, some IETF members appear to feel it is a change to The DNS. Not a change to the protocol, perhaps, but to the database. We've heard it consistently for the past 2 years: "this stuff doesn't belong in The DNS". I and you and others feel there's nothing wrong with putting the data we want into The DNS, but if we have to get every piece of data we want past a consensus call as well as the IESG, then we should to listen to them. -hadriel ------=_NextPart_000_01B2_01CACF5A.CCF1B7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As for Dean ..No we should not shoot the messenger = ..especially one that has so many guns.  I wish there was some focus here on = what the problem is. How do we help SIP network operators work better. There is a = clear and demonstrable problem that needs to be addressed in SIP PSTN = interworking.  The discussion is getting wrapped up in orthogonal arguments about what is = and is not appropriate use of DNS technology.

 

I almost got the sense in the BOF that folks thought ENUM = itself was a mistake.  I know John Klensin almost wishes he had never = heard the word J  We have a mechanism for translating E.164 keys into FOO and it works = quite well.  We need a mechanism that translates E.164 numbers into other = types of FOO otherwise SIP does not work as well as it should. =

 

An alternate port IMHO solves a load of problems and I = don’t see any problem with that.  What I have a problem with is bashing = up the proposed solutions here without understanding what problem we are trying to = fix.

 

This alternate use of DNS technology is well understood = and widely deployed. Gee we have split DNS right?

 

From:= e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of = Hadriel Kaplan
Sent: Monday, March 29, 2010 3:40 PM
To: Jay Daley; Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling

 

 

 

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay Daley
Sent: Monday, March 29, 2010 4:02 AM
To: Dean Willis

On 29/03/2010, at 7:19 PM, Dean Willis = wrote:

 

1.  ENUM did not originate with carriers = trying to pollute the Internet and the IETF did not bend over backwards to put = phone numbers onto the Internet.  Quite the opposite.  There was a = lot of opposition to ENUM from ITU types as they saw it as a cunning IETF = plot to take over telephony.   

There are many public ENUM trees (at the country = code level), it is hard to see what is really more in the DNS than that. =  The success of ENUM in a private context is surprising given the original = hostility to ENUM from some carriers, but is not an indication that this is a = private protocol.

 

Most carriers I’ve talked to were not hostile to ENUM = using DNS the protocol – they were hostile to the data being put in The DNS.  They actually like the properties of the protocol, a = lot.

 

Carriers are not working against the best interests = of the Internet, they are just trying to bring their experience, their values = and their way of working to the Internet.  You might disagree with = those but nobody holds the keys to the Internet, that is the whole = point.

 

I think you misunderstand Dean – he’s being the messenger, not the source.  That’s part of his role as the = BOF Chair.

 

3.  I don't mean to be rude but I don't think = you understand DNS at all.  For a start we are not taking about making = changes to the DNS at all because NAPTR already exists.   All we are = talking about it a standard data representation within NAPTR.  

 

Actually he’s = relaying the comments he got from other IETF folks, again as his role as BOF Chair = and trying to help us move forward.  And for some of the mechanisms we = need for ENUM, some IETF members appear to feel it is a change to The DNS.  Not a change to the protocol, perhaps, but to the database.  We’ve heard it consistently for the past 2 years: = “this stuff doesn’t belong in The DNS”.  I and you and others feel there’s nothing wrong with putting the data we want into The DNS, = but if we have to get every piece of data we want past a consensus call as well = as the IESG, then we should to listen to them.

 

-hadriel

------=_NextPart_000_01B2_01CACF5A.CCF1B7C0-- From jay@nzrs.net.nz Mon Mar 29 13:18:25 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54F543A6800 for ; Mon, 29 Mar 2010 13:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdLRjK5yUQRV for ; Mon, 29 Mar 2010 13:18:24 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id D729C3A689A for ; Mon, 29 Mar 2010 13:18:20 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id D9BF82DAFB3; Tue, 30 Mar 2010 09:18:48 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPjBhTBKXq8W; Tue, 30 Mar 2010 09:18:48 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A8EA12DAFA8; Tue, 30 Mar 2010 09:18:48 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> Date: Tue, 30 Mar 2010 09:18:48 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:18:25 -0000 On 29/03/2010, at 5:51 AM, Hadriel Kaplan wrote: > No, I would agree that would be bad - instead, a few of us have been = talking about possibly offering a Plan-B to the IETF: a separate = database for ENUM. > Same protocol on the wire, but for a different port number than 53, = and only for E.164 to Foo resolution, not domain names. Whether there'd = be a global root or not is debatable, but we'd split out from The DNS. >=20 > That way we could have unused, send-N, cnam, source-uri, and anything = else we actually need for ENUM but that the IETF is concerned about = adding to The DNS. This proposal confuses DNS with the IANA root. To help you understand = this, think of the IANA root as the database and DNS as the protocol. = If you want to move the data out of the database then you move to a = different database - i.e. another root or another branch (e164md.arpa?) = - not to another protocol. What you also appear to doing - and yes there is a bit of a leap here - = is laying claim that NAPTR belongs to SIP and if we want to use it for = something else then we have to go elsewhere. Not only do we have to = move to another database but we have to move to another protocol = entirely. kind regards Jay >=20 > -hadriel >=20 >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of >> Eric Burger >> Sent: Sunday, March 28, 2010 12:09 PM >> To: Dean Willis >>=20 >> I hope the logical conclusion from the argument below is NOT that = since >> many of these use cases could be used on the Internet but will be = used in >> private networks, the people that want to do this work decide to do = it >> outside of the IETF. >>=20 >> That would be a bad outcome. >>=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From kcartwright@tnsi.com Mon Mar 29 13:19:15 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB963A6925 for ; Mon, 29 Mar 2010 13:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.276 X-Spam-Level: X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[AWL=1.193, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF+rBsRE7ZXt for ; Mon, 29 Mar 2010 13:19:13 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 492ED3A6800 for ; Mon, 29 Mar 2010 13:19:05 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42017834; Mon, 29 Mar 2010 16:19:22 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 16:19:22 -0400 From: "Cartwright, Kenneth" To: Hadriel Kaplan , Otmar Lendl , "e2md@ietf.org" Date: Mon, 29 Mar 2010 16:19:20 -0400 Thread-Topic: [e2md] alt structure suggested for CNAM Thread-Index: AcrPNB96UeEt30iRSSmniUBSchd7kAAQ5d3gAAFVlpA= Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529E48@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB090B8.5050804@nic.at> <430FC6BDED356B4C8498F634416644A91A79E928FF@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E928FF@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:19:15 -0000 That's also the way I viewed it. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Monday, March 29, 2010 3:48 PM To: Otmar Lendl; e2md@ietf.org Subject: Re: [e2md] alt structure suggested for CNAM > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Otmar Lendl > Sent: Monday, March 29, 2010 7:36 AM > > > 2) The ability to determine the "source" of the query in a standardized > > manner. Hadriel has a proposal out there on a way to do this. But, > > again, ***this is a broader subject and should definitely be handled as > > a separate discussion track***. > > Again, this requirement contradicts one of the core design principles of > the DNS architecture. > > Yes, Hadrian's draft provides an idea on how one could retrofit the DNS t= o > accommodate this wish, but that's a very ugly hack. Huh, I thought is was an elegant hack. :) It's not changing the structure of DNS - it just gives the server additiona= l data with which it can filter the response. I.e., the server has a big l= ist of matching NAPTRs for the query key, but the extension gives it a filt= er to apply to reduce the set it gives back in the response. -hadriel p.s., it's "Hadriel" - hopefully my comments have not created a wall in Bri= tain. ;) _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jay@nzrs.net.nz Mon Mar 29 13:29:54 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1231C3A68F9 for ; Mon, 29 Mar 2010 13:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPawi2fh6qKb for ; Mon, 29 Mar 2010 13:29:52 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 2D34B3A689A for ; Mon, 29 Mar 2010 13:29:52 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 2405E2DA369; Tue, 30 Mar 2010 09:30:20 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B80EsS2NmZAn; Tue, 30 Mar 2010 09:30:20 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id B4B5D2DA277; Tue, 30 Mar 2010 09:30:19 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-258--470356607 From: Jay Daley In-Reply-To: <01b101cacf7c$540357c0$fc0a0740$@us> Date: Tue, 30 Mar 2010 09:30:19 +1300 Message-Id: <6C98563E-4749-41DE-BCD5-90385B0CC082@nzrs.net.nz> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1077) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:29:54 -0000 --Apple-Mail-258--470356607 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 30/03/2010, at 9:13 AM, Richard Shockey wrote: > As for Dean ..No we should not shoot the messenger ..especially one = that has so many guns. I wish there was some focus here on what the = problem is. How do we help SIP network operators work better. There is a = clear and demonstrable problem that needs to be addressed in SIP PSTN = interworking. The discussion is getting wrapped up in orthogonal = arguments about what is and is not appropriate use of DNS technology. > =20 > I almost got the sense in the BOF that folks thought ENUM itself was a = mistake. =20 Even for me who was not at the BOF that is coming across loud and clear. It doesn't take much thought to recognise now, with hindsight of course, = that the real culprit is NAPTR. It creates a database within a database = without the mechanism to selectively retrieve data from that second = database. (in other words, you get all the NAPTRs in one go). Either we = accept that and make it easy to process, which is where the distinction = between "e2u" and "e2md" is sufficient in my mind, or we put the data = under different domains such as=20 _e2md.7.7.9.6.1.3.9.4.4.6.e164.arpa (which Dean? suggested previously), = or 7.7.9.6.1.3.9.4.4.6.e164md.arpa best Jay > I know John Klensin almost wishes he had never heard the word J We = have a mechanism for translating E.164 keys into FOO and it works quite = well. We need a mechanism that translates E.164 numbers into other = types of FOO otherwise SIP does not work as well as it should. > =20 > An alternate port IMHO solves a load of problems and I don=92t see any = problem with that. What I have a problem with is bashing up the = proposed solutions here without understanding what problem we are trying = to fix. > =20 > This alternate use of DNS technology is well understood and widely = deployed. Gee we have split DNS right? > =20 > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: Monday, March 29, 2010 3:40 PM > To: Jay Daley; Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is = stalling > =20 > =20 > =20 > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Jay Daley > Sent: Monday, March 29, 2010 4:02 AM > To: Dean Willis >=20 > On 29/03/2010, at 7:19 PM, Dean Willis wrote: > =20 > 1. ENUM did not originate with carriers trying to pollute the = Internet and the IETF did not bend over backwards to put phone numbers = onto the Internet. Quite the opposite. There was a lot of opposition = to ENUM from ITU types as they saw it as a cunning IETF plot to take = over telephony. =20 > There are many public ENUM trees (at the country code level), it is = hard to see what is really more in the DNS than that. The success of = ENUM in a private context is surprising given the original hostility to = ENUM from some carriers, but is not an indication that this is a private = protocol. > =20 > Most carriers I=92ve talked to were not hostile to ENUM using DNS the = protocol =96 they were hostile to the data being put in The DNS. They = actually like the properties of the protocol, a lot. > =20 > Carriers are not working against the best interests of the Internet, = they are just trying to bring their experience, their values and their = way of working to the Internet. You might disagree with those but = nobody holds the keys to the Internet, that is the whole point. > =20 > I think you misunderstand Dean =96 he=92s being the messenger, not the = source. That=92s part of his role as the BOF Chair. > =20 > 3. I don't mean to be rude but I don't think you understand DNS at = all. For a start we are not taking about making changes to the DNS at = all because NAPTR already exists. All we are talking about it a = standard data representation within NAPTR. =20 > =20 > Actually he=92s relaying the comments he got from other IETF folks, = again as his role as BOF Chair and trying to help us move forward. And = for some of the mechanisms we need for ENUM, some IETF members appear to = feel it is a change to The DNS. Not a change to the protocol, perhaps, = but to the database. We=92ve heard it consistently for the past 2 = years: =93this stuff doesn=92t belong in The DNS=94. I and you and = others feel there=92s nothing wrong with putting the data we want into = The DNS, but if we have to get every piece of data we want past a = consensus call as well as the IESG, then we should to listen to them. > =20 > -hadriel --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 --Apple-Mail-258--470356607 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 30/03/2010, at 9:13 AM, Richard = Shockey wrote:

As for Dean ..No we should not = shoot the messenger ..especially one that has so many guns.  I wish = there was some focus here on what the problem is. How do we help SIP = network operators work better. There is a clear and demonstrable problem = that needs to be addressed in SIP PSTN interworking.  The = discussion is getting wrapped up in orthogonal arguments about what is = and is not appropriate use of DNS = technology.
I = almost got the sense in the BOF that folks thought ENUM itself was a = mistake. =  

Eve= n for me who was not at the BOF that is coming across loud and = clear.

It doesn't take much thought to = recognise now, with hindsight of course, that the real culprit is NAPTR. =  It creates a database within a database without the mechanism to = selectively retrieve data from that second database. (in other words, = you get all the NAPTRs in one go).  Either we accept that and make = it easy to process, which is where the distinction between "e2u" and = "e2md" is sufficient in my mind, or we put the data under different = domains such = as 

_e2md.7.7.9.6.1.3.9.4.4.6.e164.arpa =  (which Dean? suggested previously), = or
7.7.9.6.1.3.9.4.4.6.e164md.arpa

best=
Jay

I know John Klensin almost wishes = he had never heard the word J  We have a mechanism for = translating E.164 keys into FOO and it works quite well.  We need a = mechanism that translates E.164 numbers into other types of FOO = otherwise SIP does not work as well as it = should.
An = alternate port IMHO solves a load of problems and I don=92t see any = problem with that.  What I have a problem with is bashing up the = proposed solutions here without understanding what problem we are trying = to fix.
This = alternate use of DNS technology is well understood and widely deployed. = Gee we have split DNS right?
From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org= ] On Behalf Of Hadriel = Kaplan
Sent: Monday, March 29, 2010 3:40 = PM
To: Jay = Daley; Dean Willis
Cc: E.164 To MetaData BOF = discussion list
Subject: Re: [e2md] E2MD, ENUM, and = the DNS: why our approach is = stalling

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org= ] On Behalf Of Jay = Daley
Sent: Monday, March 29, 2010 4:02 = AM
To: Dean = Willis

On 29/03/2010, at 7:19 = PM, Dean Willis wrote:
 
1.  ENUM = did not originate with carriers trying to pollute the Internet and the = IETF did not bend over backwards to put phone numbers onto the Internet. =  Quite the opposite.  There was a lot of opposition to ENUM = from ITU types as they saw it as a cunning IETF plot to take over = telephony.   
There are many public ENUM trees (at the country code level), = it is hard to see what is really more in the DNS than that.  The = success of ENUM in a private context is surprising given the original = hostility to ENUM from some carriers, but is not an indication that this = is a private protocol.
Most carriers I=92ve = talked to were not hostile to ENUM using DNS the protocol =96 they were = hostile to the data being put in The DNS.  They actually like the = properties of the protocol, a lot.
 
Carriers are not working against the best interests of the = Internet, they are just trying to bring their experience, their values = and their way of working to the Internet.  You might disagree with = those but nobody holds the keys to the Internet, that is the whole = point.
 
I think you = misunderstand Dean =96 he=92s being the messenger, not the source.  = That=92s part of his role as the BOF Chair.
 
3.  I don't mean to be rude but I don't think you = understand DNS at all.  For a start we are not taking about making = changes to the DNS at all because NAPTR already exists.   All we = are talking about it a standard data representation within NAPTR. =  
Actually he=92s relaying the comments he got from other IETF = folks, again as his role as BOF Chair and trying to help us move = forward.  And for some of the mechanisms we need for ENUM, some = IETF members appear to feel it is a change to The DNS.  = Not a change to the protocol, perhaps, but to the database.  We=92ve = heard it consistently for the past 2 years: =93this stuff doesn=92t = belong in The DNS=94.  I and you and others feel there=92s nothing = wrong with putting the data we want into The DNS, but if we have to get = every piece of data we want past a consensus call as well as the IESG, = then we should to listen to them.

-- 
Jay = Daley
Chief Executive
.nz Registry Services (New = Zealand Domain Name Registry Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840

= --Apple-Mail-258--470356607-- From kcartwright@tnsi.com Mon Mar 29 13:36:49 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2F73A65A6 for ; Mon, 29 Mar 2010 13:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.606 X-Spam-Level: ** X-Spam-Status: No, score=2.606 tagged_above=-999 required=5 tests=[AWL=-1.859, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zMxUlvnfBlF for ; Mon, 29 Mar 2010 13:36:39 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 2A0083A680F for ; Mon, 29 Mar 2010 13:36:38 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42018309; Mon, 29 Mar 2010 16:37:03 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 16:37:03 -0400 From: "Cartwright, Kenneth" To: Richard Shockey , 'Hadriel Kaplan' , 'Jay Daley' , 'Dean Willis' Date: Mon, 29 Mar 2010 16:37:01 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPFlKdJXyGQl8XTWuNaGUMJCjnLwAXxkZQAAFQvzAAAMO3UA== Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> In-Reply-To: <01b101cacf7c$540357c0$fc0a0740$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_" MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:36:50 -0000 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now that maybe we're back on track, here's a rough re-statement of what one= might like to see from this E2U/E2M infrastructure we are supposed to be t= alking about, notice how similar it is to DDDS, plus some orthogonal extens= ions: 1) Have a standard query data structure for E2U and E2M from a *framework*= perspective (DDDS and ENUM gives us this). 2) Have a standard query response structure for E2U and E2M from a *framew= ork* perspective (DDDS and ENUM gives us this). 3) Have a standard query data structure for each E2U and E2M service withi= n that framework (DDDS and ENUM gives us this). 4) Have a standard query response structure for each E2U and E2M service w= ithin that framework (DDDS and ENUM gives us this). 5) Have a standard way to identify the source of a query, both at the orga= nization level, and down to the "device/node" level within an organization = (Hadriel's proposal gives us this). 6) Have the *option* to return both E2U and E2M service responses in a sin= gle query response (I think the E2M proposal did not forbid this). 7) Continue to allow "Bind" to function as, at least, a proxy pass-through= client for queries. Iow, the base query request/response structure needs = to be backward compatible with "Bind" (DDDS and ENUM gives us this). 8) Continue to allow both UDP and TCP as the layer 3 protocol (DDDS and EN= UM gives us this). 9) Have a standard way for the querier to specify, per query, which E2U an= d/or E2M services it is interested in having in its query response (althoug= h this is less vital, this is already done to a lesser extent today, but vi= a non-standard means) (however, Hadriel's proposal might also give us this)= . 10) There is of course more detail that can be added, but it just gets too= much for emails.... As you can tell, I very much like the framework approach that DDDS embodies= , even though it has some shortcomings. This is because a significant numb= er of systems in existence today return data across multiple E2U and the pr= oposed E2M services. So using the same query/response framework greatly fa= cilitates that type of situation. So I'd like to see us stick with the fra= mework approach offered by DDDS. This question came up at the BOF (Should = we use a framework or develop a separate dedicated, RR Type for each type o= f meta-data). And as mentioned in previous emails, I've not really been a fan of the fact= that we turn TNs into domain names to look them up. In fact I think it's = pretty humorous. However, that is a more principled/theoretical issue, not= a practical one. If we were to move away from treating TNs as domain name= s at this point, that would be too drastic a change, just to be able to loo= kup CNAM, unused, etc. Ken ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Ric= hard Shockey Sent: Monday, March 29, 2010 4:14 PM To: 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis' Cc: 'E.164 To MetaData BOF discussion list' Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling As for Dean ..No we should not shoot the messenger ..especially one that ha= s so many guns. I wish there was some focus here on what the problem is. H= ow do we help SIP network operators work better. There is a clear and demon= strable problem that needs to be addressed in SIP PSTN interworking. The d= iscussion is getting wrapped up in orthogonal arguments about what is and i= s not appropriate use of DNS technology. I almost got the sense in the BOF that folks thought ENUM itself was a mist= ake. I know John Klensin almost wishes he had never heard the word :) We = have a mechanism for translating E.164 keys into FOO and it works quite wel= l. We need a mechanism that translates E.164 numbers into other types of F= OO otherwise SIP does not work as well as it should. An alternate port IMHO solves a load of problems and I don't see any proble= m with that. What I have a problem with is bashing up the proposed solutio= ns here without understanding what problem we are trying to fix. This alternate use of DNS technology is well understood and widely deployed= . Gee we have split DNS right? From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Had= riel Kaplan Sent: Monday, March 29, 2010 3:40 PM To: Jay Daley; Dean Willis Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling ________________________________ From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay= Daley Sent: Monday, March 29, 2010 4:02 AM To: Dean Willis On 29/03/2010, at 7:19 PM, Dean Willis wrote: 1. ENUM did not originate with carriers trying to pollute the Internet and= the IETF did not bend over backwards to put phone numbers onto the Interne= t. Quite the opposite. There was a lot of opposition to ENUM from ITU typ= es as they saw it as a cunning IETF plot to take over telephony. There are many public ENUM trees (at the country code level), it is hard to= see what is really more in the DNS than that. The success of ENUM in a pr= ivate context is surprising given the original hostility to ENUM from some = carriers, but is not an indication that this is a private protocol. Most carriers I've talked to were not hostile to ENUM using DNS the protoco= l - they were hostile to the data being put in The DNS. They actually like= the properties of the protocol, a lot. Carriers are not working against the best interests of the Internet, they a= re just trying to bring their experience, their values and their way of wor= king to the Internet. You might disagree with those but nobody holds the k= eys to the Internet, that is the whole point. I think you misunderstand Dean - he's being the messenger, not the source. = That's part of his role as the BOF Chair. 3. I don't mean to be rude but I don't think you understand DNS at all. F= or a start we are not taking about making changes to the DNS at all because= NAPTR already exists. All we are talking about it a standard data repres= entation within NAPTR. Actually he's relaying the comments he got from other IETF folks, again as = his role as BOF Chair and trying to help us move forward. And for some of = the mechanisms we need for ENUM, some IETF members appear to feel it is a c= hange to The DNS. Not a change to the protocol, perhaps, but to the databa= se. We've heard it consistently for the past 2 years: "this stuff doesn't = belong in The DNS". I and you and others feel there's nothing wrong with p= utting the data we want into The DNS, but if we have to get every piece of = data we want past a consensus call as well as the IESG, then we should to l= isten to them. -hadriel ________________________________ This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Now that maybe we’re back on tra= ck, here’s a rough re-statement of what one might like to see from th= is E2U/E2M infrastructure we are supposed to be talking about, notice how similar it is to DDDS, plus some = orthogonal extensions:

 

1)  Have a standard query data structure for E2U and E2M fr= om a *framework* perspective (DDDS and ENUM gives us this).

2)  Have a standard query response structure for E2U and E2= M from a *framework* perspective (DDDS and ENUM gives us this).

3)  Have a standard query data structure for each E2U and E= 2M service within that framework (DDDS and ENUM gives us this).<= /span>

4)  Have a standard query response structure for each E2U a= nd E2M service within that framework (DDDS and ENUM gives us this).

5)  Have a standard way to identify the source of a query, = both at the organization level, and down to the "device/node" level within an organization (Hadriel’s proposal gives us this).

6)  Have the *option* to return both E2U and E2M service re= sponses in a single query response (I think the E2M proposal did not forbid this).

7)  Continue to allow "Bind" to function as, at l= east, a proxy pass-through client for queries.  Iow, the base query request/response structure needs to be backward compatible with "Bind= " (DDDS and ENUM gives us this).

8)  Continue to allow both UDP and TCP as the layer 3 proto= col (DDDS and ENUM gives us this).

9)  Have a standard way for the querier to specify, per que= ry, which E2U and/or E2M services it is interested in having in its query response (although this is less vital, this is already done t= o a lesser extent today, but via non-standard means) (however, Hadriel̵= 7;s proposal might also give us this).

10)  There is of course more detail that can be added, but = it just gets too much for emails….

 

As you can tell, I very much like the framework approach that DD= DS embodies, even though it has some shortcomings.  This is because a significant number of systems in existence today return data = across multiple E2U and the proposed E2M services.  So using the same = query/response framework greatly facilitates that type of situation.  = So I'd like to see us stick with the framework approach offered by DDDS.  This question came up at the BOF (Should w= e use a framework or develop a separate dedicated, RR Type for each type of= meta-data).

 

And as mentioned in previous emails, I've not really been a fan = of the fact that we turn TNs into domain names to look them up.  In fact I think it’s pretty humorous.  However, = that is a more principled/theoretical issue, not a practical one.  If = we were to move away from treating TNs as domain names at this point, that = would be too drastic a change, just to be able to lookup CNAM, unused, etc.

 

Ken

 

 

From: e2md= -bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: Monday, March 29, 2010= 4:14 PM
To: 'Hadriel Kaplan'; 'Jay D= aley'; 'Dean Willis'
Cc: 'E.164 To MetaData BOF d= iscussion list'
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 

= As for D= ean ..No we should not shoot the messenger ..especially one that has so man= y guns.  I wish there was some focus here on what the problem is. How do we help SIP network operators work better. = There is a clear and demonstrable problem that needs to be addressed in SIP= PSTN interworking.  The discussion is getting wrapped up in orthogona= l arguments about what is and is not appropriate use of DNS technology.

= &nb= sp;

= I almost= got the sense in the BOF that folks thought ENUM itself was a mistake. &nb= sp;I know John Klensin almost wishes he had never heard the word J  We have a mechanism for translating E.164 keys into FOO and it works quite= well.  We need a mechanism that translates E.164 numbers into other t= ypes of FOO otherwise SIP does not work as well as it should.

= &nb= sp;

= An alter= nate port IMHO solves a load of problems and I don’t see any problem = with that.  What I have a problem with is bashing up the proposed solutions here without understanding what problem we are t= rying to fix.

= &nb= sp;

= This alt= ernate use of DNS technology is well understood and widely deployed. Gee we= have split DNS right?

= &nb= sp;

From: e2md= -bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: Monday, March 29, 2010= 3:40 PM
To: Jay Daley; Dean Willis Cc: E.164 To MetaData BOF di= scussion list
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 

 

 

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay Daley
Sent: Monday, March 29, 2010= 4:02 AM
To: Dean Willis

On 29/03/2010, at 7:19 PM, Dean Willis wrote:

 

1.  ENUM did not originate with carriers trying to pollute the= Internet and the IETF did not bend over backwards to put phone numbers ont= o the Internet.  Quite the opposite.  There was a lot of opposition to ENUM from ITU types as they saw it = as a cunning IETF plot to take over telephony.   =

There are many public ENUM trees (at the country code level), it is= hard to see what is really more in the DNS than that.  The success of= ENUM in a private context is surprising given the original hostility to ENUM from some carriers, but is= not an indication that this is a private protocol.

 

Most carriers I’ve talked to wer= e not hostile to ENUM using DNS the protocol – they were hostile to t= he data being put in The DNS.  They actually like the properties of the protocol, a lot.

 

Carriers are not working against the best interests of the Internet= , they are just trying to bring their experience, their values and their wa= y of working to the Internet.  You might disagree with those but nobody holds the keys to the Inter= net, that is the whole point.

 

I think you misunderstand Dean –= he’s being the messenger, not the source.  That’s part of= his role as the BOF Chair.

 

3.  I don't mean to be rude but I don't think you understand D= NS at all.  For a start we are not taking about making changes to the = DNS at all because NAPTR already exists.   All we are talking about it a standard data representation = within NAPTR.  

 

Actually he’s relayi= ng the comments he got from other IETF folks, again as his role as BOF Chai= r and trying to help us move forward.  And for some of the mechanisms we need for ENUM, some IETF members appear to feel it is a change to The DNS. = Not a change to the protocol, perhaps, but to the database.  We’= ;ve heard it consistently for the past 2 years: “this stuff doesn’t belong in The DNS”.  I and you and others f= eel there’s nothing wrong with putting the data we want into The DNS,= but if we have to get every piece of data we want past a consensus call as= well as the IESG, then we should to listen to them.

 

-hadriel=


This e-mail message is for t= he sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Serv= ices.
Any unauthorised review, use, disclosure or distribution is prohibited. If = you
are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message.

 --_000_754963199212404AB8E9CFCA6C3D0CDA1F69529E7ATNSMAILNAwin2_-- From dean.willis@softarmor.com Mon Mar 29 13:37:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191403A6AA2 for ; Mon, 29 Mar 2010 13:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYtjA0IGI35H for ; Mon, 29 Mar 2010 13:37:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 06E163A6959 for ; Mon, 29 Mar 2010 13:37:28 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TKbnpC008150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 15:37:51 -0500 Message-Id: From: Dean Willis To: Jay Daley In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 15:37:40 -0500 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:37:30 -0000 On Mar 29, 2010, at 2:59 PM, Jay Daley wrote: > >> >> I think you misunderstand Dean =96 he=92s being the messenger, not = the =20 >> source. That=92s part of his role as the BOF Chair. > > Sorry but that is just not the case. If that was solely the voice =20 > of the messenger and not his own views then I'll put on a frilly =20 > dress and sing the Marseillaise on the Wellington waterfront. I can =20= > sleep soundly knowing that won't happen. > Aw c'mon. I want to see the video on YouTube. Seriously, I really don't give a damn about E2MD -- I've just been =20 trying to help out because I was asked to. I think we've got fairly =20 reasonable use cases and in general supported formation of the group. =20= I also think that "the opposition" has some arguments that need to be =20= understood and addressed. I'm also finding some of these arguments to =20= be compelling, enough so that I'm willing to concede they might well =20 be correct on several points. >> >> 3. I don't mean to be rude but I don't think you understand DNS at =20= >> all. For a start we are not taking about making changes to the DNS =20= >> at all because NAPTR already exists. All we are talking about it =20= >> a standard data representation within NAPTR. >> >> Actually he=92s relaying the comments he got from other IETF folks, =20= >> again as his role as BOF Chair and trying to help us move forward. =20= >> And for some of the mechanisms we need for ENUM, some IETF members =20= >> appear to feel it is a change to The DNS. Not a change to the =20 >> protocol, perhaps, but to the database. We=92ve heard it =20 >> consistently for the past 2 years: =93this stuff doesn=92t belong in =20= >> The DNS=94. I and you and others feel there=92s nothing wrong with =20= >> putting the data we want into The DNS, but if we have to get every =20= >> piece of data we want past a consensus call as well as the IESG, =20 >> then we should to listen to them. > > I can understand that some people think it is a change to the =20 > database not the protocol but that is a sophisticated view, not =20 > related to what Dean is saying and does not change my view that Dean =20= > does not understand DNS at all, there is too much clear evidence to =20= > support that. > I suspect I was running DNS systems before you ever heard of the =20 Internet. At least I was doing so while you were doing PC support for =20= a local government. Further I was certainly working on distributed =20 directory problems while you were failing to advance your education at =20= Sussex. I might be outdated, but you appear to be seriously =20 uninformed, not to mention a trifle rude. > You and I know that when someone says "put it into a TXT record" =20 > that means two things: > > 1. They're not objecting to a change in the database, because if =20 > they were then they would not suggest keeping the same data in DNS. > 2. They don't understand DNS. > I suspect you don't understand the concept of a strawman argument. I =20= find it to be a useful technique to help identify points of agreement =20= and disagreement in a community. We had numerous people (John Klensin, Jon Peterson, and Patrik =20 F=E4ltstr=F6m, among others) at IETF 77 telling us that we were using an = =20 inappropriate DNS record (NAPTR) for metadata. This suggests =20 dissecting the usage to find out what's inappropriate about it. In the =20= absence of any technical discussion (and no, shouting about how stupid =20= people are being does not constitute substantive technical =20 discussion), I found it useful to propose a model that had the =20 properties people were saying we needed and that NAPTR didn't have; =20 indeed, this elicited additional required properties (support for =20 wildcarding) that had not arisen in earlier discussion. Consequently, =20= I believe this to have been a useful inquiry. I might add that I have =20= found your participation, both in this forum and in private mail, to =20 be substantially less useful in moving towards some sort of broader =20 understanding and consensus. I believe that "broader understanding and consensus" are things we =20 need a lot more of if we wish this work to advance in the IETF. We =20 need to have both absolute clarity within the community of interest =20 AND a consensus understanding of the opposition's objections. So far, we have neither. -- Dean From dean.willis@softarmor.com Mon Mar 29 13:52:03 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B282D3A6AFD for ; Mon, 29 Mar 2010 13:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.893 X-Spam-Level: X-Spam-Status: No, score=0.893 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9xiemJEXski for ; Mon, 29 Mar 2010 13:52:02 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C251F3A6B7B for ; Mon, 29 Mar 2010 13:48:53 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TKnIPe008233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 15:49:20 -0500 Message-Id: <9C5F0CCC-F630-455B-80E8-62AF5A4D0E92@softarmor.com> From: Dean Willis To: Jay Daley In-Reply-To: <6C98563E-4749-41DE-BCD5-90385B0CC082@nzrs.net.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 15:49:13 -0500 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <6C98563E-4749-41DE-BCD5-90385B0CC082@nzrs.net.nz> X-Mailer: Apple Mail (2.936) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:52:03 -0000 On Mar 29, 2010, at 3:30 PM, Jay Daley wrote: > > > _e2md.7.7.9.6.1.3.9.4.4.6.e164.arpa (which Dean? suggested > previously), or > 7.7.9.6.1.3.9.4.4.6.e164md.arpa > I liked the first suggestion at the time that Bob Penfield made it (Dave Crocker independently suggested it), but I believe Otmar Lendl pointed out the fatal flaw with _prefixes during the discussion on the _displayname....TXT strawman. It doesn't work right with wildcarding. As Otmar said: > In Germany and Austria with their open dialing plans the carrier > only knows > to which customer the base number is associated with. The carrier > does not > know which extension do exist and what length they are. > > So unless the carrier delegates the ENUM space to the customer, the > carrier > has to work with wildcards for cnam in these cases. > > Prefixes just do not work with open numbering plans. Jay's second alternative here doesn't have that limitation. It also is consistent with a suggestion that I believe John Klensin made during the BOF: formally using a different root. It still doesn't address the "framework" vs. "specific use case" question raised by Jon Peterson. Nor does it address the repeatedly- raised question of differentiating between "metadata you need when setting up a call" and "metadata needed when answering a call". But it could well be a step forward. -- Dean From jay@nzrs.net.nz Mon Mar 29 13:53:01 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B103A6B5C for ; Mon, 29 Mar 2010 13:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.798 X-Spam-Level: ** X-Spam-Status: No, score=2.798 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr7B+KlP4lqS for ; Mon, 29 Mar 2010 13:53:00 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 5F7663A6B88 for ; Mon, 29 Mar 2010 13:51:55 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 5EF7A2DAFAF; Tue, 30 Mar 2010 09:52:21 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1rsh45KlP0d; Tue, 30 Mar 2010 09:52:21 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id DB24F2DA369; Tue, 30 Mar 2010 09:52:20 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-261--469035611 From: Jay Daley In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> Date: Tue, 30 Mar 2010 09:52:20 +1300 Message-Id: <55CBBA5C-5DF5-4E6A-8ACA-29590F6EF6BB@nzrs.net.nz> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> To: "Cartwright, Kenneth" X-Mailer: Apple Mail (2.1077) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:53:02 -0000 --Apple-Mail-261--469035611 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 30/03/2010, at 9:37 AM, Cartwright, Kenneth wrote: > Now that maybe we=92re back on track, here=92s a rough re-statement of = what one might like to see from this E2U/E2M infrastructure we are = supposed to be talking about, notice how similar it is to DDDS, plus = some orthogonal extensions: Did you intentionally include E2U? It seems to me that the list below addresses perceived issues with ENUM = not just e2md and what comes from this is revised requirements for ENUM, = not just e2md. If dealing with the lingering concerns over ENUM is = what it takes to get e2md accepted then I would prefer that to an = ongoing proxy struggle in e2md that is really about ENUM. cheers Jay > =20 > 1) Have a standard query data structure for E2U and E2M from a = *framework* perspective (DDDS and ENUM gives us this). > 2) Have a standard query response structure for E2U and E2M from a = *framework* perspective (DDDS and ENUM gives us this). > 3) Have a standard query data structure for each E2U and E2M service = within that framework (DDDS and ENUM gives us this). > 4) Have a standard query response structure for each E2U and E2M = service within that framework (DDDS and ENUM gives us this). > 5) Have a standard way to identify the source of a query, both at the = organization level, and down to the "device/node" level within an = organization (Hadriel=92s proposal gives us this). > 6) Have the *option* to return both E2U and E2M service responses in = a single query response (I think the E2M proposal did not forbid this). > 7) Continue to allow "Bind" to function as, at least, a proxy = pass-through client for queries. Iow, the base query request/response = structure needs to be backward compatible with "Bind" (DDDS and ENUM = gives us this). > 8) Continue to allow both UDP and TCP as the layer 3 protocol (DDDS = and ENUM gives us this). > 9) Have a standard way for the querier to specify, per query, which = E2U and/or E2M services it is interested in having in its query response = (although this is less vital, this is already done to a lesser extent = today, but via non-standard means) (however, Hadriel=92s proposal might = also give us this). > 10) There is of course more detail that can be added, but it just = gets too much for emails=85. > =20 > As you can tell, I very much like the framework approach that DDDS = embodies, even though it has some shortcomings. This is because a = significant number of systems in existence today return data across = multiple E2U and the proposed E2M services. So using the same = query/response framework greatly facilitates that type of situation. So = I'd like to see us stick with the framework approach offered by DDDS. = This question came up at the BOF (Should we use a framework or develop a = separate dedicated, RR Type for each type of meta-data). > =20 > And as mentioned in previous emails, I've not really been a fan of the = fact that we turn TNs into domain names to look them up. In fact I = think it=92s pretty humorous. However, that is a more = principled/theoretical issue, not a practical one. If we were to move = away from treating TNs as domain names at this point, that would be too = drastic a change, just to be able to lookup CNAM, unused, etc. > =20 > Ken > =20 > =20 > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Richard Shockey > Sent: Monday, March 29, 2010 4:14 PM > To: 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis' > Cc: 'E.164 To MetaData BOF discussion list' > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is = stalling > =20 > As for Dean ..No we should not shoot the messenger ..especially one = that has so many guns. I wish there was some focus here on what the = problem is. How do we help SIP network operators work better. There is a = clear and demonstrable problem that needs to be addressed in SIP PSTN = interworking. The discussion is getting wrapped up in orthogonal = arguments about what is and is not appropriate use of DNS technology. > =20 > I almost got the sense in the BOF that folks thought ENUM itself was a = mistake. I know John Klensin almost wishes he had never heard the word = J We have a mechanism for translating E.164 keys into FOO and it works = quite well. We need a mechanism that translates E.164 numbers into = other types of FOO otherwise SIP does not work as well as it should. > =20 > An alternate port IMHO solves a load of problems and I don=92t see any = problem with that. What I have a problem with is bashing up the = proposed solutions here without understanding what problem we are trying = to fix. > =20 > This alternate use of DNS technology is well understood and widely = deployed. Gee we have split DNS right? > =20 > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: Monday, March 29, 2010 3:40 PM > To: Jay Daley; Dean Willis > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is = stalling > =20 > =20 > =20 > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Jay Daley > Sent: Monday, March 29, 2010 4:02 AM > To: Dean Willis >=20 > On 29/03/2010, at 7:19 PM, Dean Willis wrote: > =20 > 1. ENUM did not originate with carriers trying to pollute the = Internet and the IETF did not bend over backwards to put phone numbers = onto the Internet. Quite the opposite. There was a lot of opposition = to ENUM from ITU types as they saw it as a cunning IETF plot to take = over telephony. =20 > There are many public ENUM trees (at the country code level), it is = hard to see what is really more in the DNS than that. The success of = ENUM in a private context is surprising given the original hostility to = ENUM from some carriers, but is not an indication that this is a private = protocol. > =20 > Most carriers I=92ve talked to were not hostile to ENUM using DNS the = protocol =96 they were hostile to the data being put in The DNS. They = actually like the properties of the protocol, a lot. > =20 > Carriers are not working against the best interests of the Internet, = they are just trying to bring their experience, their values and their = way of working to the Internet. You might disagree with those but = nobody holds the keys to the Internet, that is the whole point. > =20 > I think you misunderstand Dean =96 he=92s being the messenger, not the = source. That=92s part of his role as the BOF Chair. > =20 > 3. I don't mean to be rude but I don't think you understand DNS at = all. For a start we are not taking about making changes to the DNS at = all because NAPTR already exists. All we are talking about it a = standard data representation within NAPTR. =20 > =20 > Actually he=92s relaying the comments he got from other IETF folks, = again as his role as BOF Chair and trying to help us move forward. And = for some of the mechanisms we need for ENUM, some IETF members appear to = feel it is a change to The DNS. Not a change to the protocol, perhaps, = but to the database. We=92ve heard it consistently for the past 2 = years: =93this stuff doesn=92t belong in The DNS=94. I and you and = others feel there=92s nothing wrong with putting the data we want into = The DNS, but if we have to get every piece of data we want past a = consensus call as well as the IESG, then we should to listen to them. > =20 > -hadriel >=20 > This e-mail message is for the sole use of the intended = recipient(s)and may > contain confidential and privileged information of Transaction Network = Services. > Any unauthorised review, use, disclosure or distribution is = prohibited. If you > are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 --Apple-Mail-261--469035611 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 30/03/2010, at 9:37 AM, = Cartwright, Kenneth wrote:

Now that maybe we=92re back on = track, here=92s a rough re-statement of what one might like to see from = this E2U/E2M infrastructure we are supposed to be talking about, notice = how similar it is to DDDS, plus some orthogonal = extensions:

Did you = intentionally include = E2U?

It seems to me that = the list below addresses perceived issues with ENUM not just e2md and = what comes from this is revised requirements for ENUM, not just =  e2md.  If dealing with the lingering concerns over ENUM is = what it takes to get e2md accepted then I would prefer that to an = ongoing proxy struggle in e2md that is really about = ENUM.

cheers
Jay

 
1)  Have a standard query data = structure for E2U and E2M from a *framework* = perspective (DDDS and ENUM gives us = this).
7)  Continue to allow "Bind" to function as, at = least, a proxy pass-through client for queries.  Iow, the base = query request/response structure needs to be backward compatible with = "Bind" (DDDS and ENUM gives us this).
8)  Continue to allow both UDP and = TCP as the layer 3 protocol (DDDS and ENUM gives us = this).
10)  There is of course more detail = that can be added, but it just gets too much for = emails=85.
As = you can tell, I very much like the framework approach that DDDS = embodies, even though it has some shortcomings.  This is because a = significant number of systems in existence today return data across = multiple E2U and the proposed E2M services.  So using the same = query/response framework greatly facilitates that type of = situation.  So I'd like to see us stick with the framework approach = offered by DDDS.  This question came up at the BOF (Should we use a = framework or develop a separate dedicated, RR Type for each type of = meta-data).
And = as mentioned in previous emails, I've not really been a fan of the fact = that we turn TNs into domain names to look them up.  In fact I = think it=92s pretty humorous.  However, that is a more = principled/theoretical issue, not a practical one.  If we were to = move away from treating TNs as domain names at this point, that would be = too drastic a change, just to be able to lookup CNAM, unused, = etc.
 
From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org= ] On Behalf Of Richard = Shockey
Sent: Monday, March 29, 2010 4:14 = PM
To: 'Hadriel Kaplan'; 'Jay = Daley'; 'Dean Willis'
 'E.164 = To MetaData BOF discussion list'
 Re: [e2md] E2MD, ENUM, and = the DNS: why our approach is = stalling
As for Dean ..No we should not shoot the = messenger ..especially one that has so many guns.  I wish there was = some focus here on what the problem is. How do we help SIP network = operators work better. There is a clear and demonstrable problem that = needs to be addressed in SIP PSTN interworking.  The discussion is = getting wrapped up in orthogonal arguments about what is and is not = appropriate use of DNS technology.
I almost got the sense in the BOF that folks = thought ENUM itself was a mistake.  I know John Klensin almost = wishes he had never heard the word   We have a mechanism for translating E.164 keys into FOO = and it works quite well.  We need a mechanism that translates E.164 = numbers into other types of FOO otherwise SIP does not work as well as = it should.
 
 
From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org= ] On Behalf Of Hadriel = Kaplan
Sent: Monday, March 29, 2010 3:40 = PM
To: Jay Daley; Dean = Willis
Cc: E.164 To MetaData BOF = discussion list
 Re: [e2md] E2MD, ENUM, and = the DNS: why our approach is = stalling
 
 

From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org= ] On Behalf Of Jay = Daley
Sent: Monday, March 29, 2010 4:02 = AM
To: Dean = Willis

On = 29/03/2010, at 7:19 PM, Dean Willis = wrote:
 
1.  ENUM did not originate with carriers trying to pollute = the Internet and the IETF did not bend over backwards to put phone = numbers onto the Internet.  Quite the opposite.  There was a = lot of opposition to ENUM from ITU types as they saw it as = a cunning IETF plot to take over telephony. =   
There are many public ENUM trees (at the country code level), it = is hard to see what is really more in the DNS than that.  The = success of ENUM in a private context is surprising given the original = hostility to ENUM from some carriers, but is not an indication that this = is a private protocol.
Most carriers I=92ve talked to were not hostile to ENUM = using DNS the protocol =96 they were hostile to the data being put in = The DNS.  They actually like the properties of the protocol, a = lot.
 
Carriers are not working against the best interests of the = Internet, they are just trying to bring their experience, their values = and their way of working to the Internet.  You might disagree with = those but nobody holds the keys to the Internet, that is the whole = point.
 
I think you misunderstand Dean = =96 he=92s being the messenger, not the source.  That=92s part of = his role as the BOF Chair.
3.  I don't mean to be rude but I don't think you = understand DNS at all.  For a start we are not taking about making = changes to the DNS at all because NAPTR already exists.   All we = are talking about it a standard data representation within NAPTR. =   
Actually he=92s relaying the = comments he got from other IETF folks, again as his role as BOF Chair = and trying to help us move forward.  And for some of the mechanisms = we need for ENUM, some IETF members appear to feel it is a change to The DNS.  = Not a change to the protocol, perhaps, but to the database.  We=92ve = heard it consistently for the past 2 years: =93this stuff doesn=92t = belong in The DNS=94.  I and you and others feel there=92s nothing = wrong with putting the data we want into The DNS, but if we have to get = every piece of data we want past a consensus call as well as the IESG, = then we should to listen to them.
This e-mail message = is for the sole use of the intended recipient(s)and may
contain = confidential and privileged information of Transaction Network = Services.
Any unauthorised review, use, disclosure or distribution is = prohibited. If you
are not the intended recipient, please contact the = sender by reply e-mail and destroy all copies of the original = message.



-- 
Jay = Daley
Chief Executive
.nz Registry Services (New = Zealand Domain Name Registry Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840

= --Apple-Mail-261--469035611-- From HKaplan@acmepacket.com Mon Mar 29 13:53:20 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE513A6AFD for ; Mon, 29 Mar 2010 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P238Y3JdWClL for ; Mon, 29 Mar 2010 13:53:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 27A043A6B2B for ; Mon, 29 Mar 2010 13:52:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 16:52:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 16:52:46 -0400 From: Hadriel Kaplan To: Jay Daley Date: Mon, 29 Mar 2010 16:52:47 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPfRhwQZfk9Fb7SM6zy2oI0wtmlAAASB4A Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92934@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <430FC6BDED356B4C8498F634416644A91A79E926F2@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:53:20 -0000 > -----Original Message----- > From: Jay Daley [mailto:jay@nzrs.net.nz] > Sent: Monday, March 29, 2010 4:19 PM > To: Hadriel Kaplan >=20 > This proposal confuses DNS with the IANA root. To help you understand > this, think of the IANA root as the database and DNS as the protocol. If > you want to move the data out of the database then you move to a differen= t > database - i.e. another root or another branch (e164md.arpa?) - not to > another protocol. Nope, I'm not confused, or at least I think I'm not. (does a crazy person k= now they're crazy? ;) I was fully expecting to stipulate that it be a new separate root, if we ne= eded a public root. It just wasn't apparent to me there *were* many users = of The public DNS database for E.164 resolution data. I knew about the Aus= trian guys, but hadn't seen anything else. (although in my defense I don't= see everyone's config and only seem to get involved in cases where a priva= te database is being used, so it's a self-fulfilling view) I don't think moving to another branch alone will help, fwiw. It would hav= e to be a new root so we can get source-uri and such, and a new "protocol" = just to get out from concerns of a real alt-root scenario. But that new "p= rotocol" would look exactly like the old protocol. We'd just be sending to= or listening on a different port number. And we'd probably get it accepte= d more easily if we adopted a new TLD that got reserved from The DNS root a= s well, like ".enum" or some such. (ie, it would be reserved like the ones = in rfc2606) > What you also appear to doing - and yes there is a bit of a leap here - i= s > laying claim that NAPTR belongs to SIP and if we want to use it for > something else then we have to go elsewhere. Not only do we have to move > to another database but we have to move to another protocol entirely. Oh, no I definitely didn't mean that. -hadriel From jay@nzrs.net.nz Mon Mar 29 13:53:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E382A3A6986 for ; Mon, 29 Mar 2010 13:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39ree65dr07B for ; Mon, 29 Mar 2010 13:53:24 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id CA4B33A6B67 for ; Mon, 29 Mar 2010 13:52:39 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id DBE702DAFB6; Tue, 30 Mar 2010 09:53:07 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uft2qfrml2-P; Tue, 30 Mar 2010 09:53:07 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 94D362DA7A9; Tue, 30 Mar 2010 09:53:07 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <9C5F0CCC-F630-455B-80E8-62AF5A4D0E92@softarmor.com> Date: Tue, 30 Mar 2010 09:53:07 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <6C98563E-4749-41DE-BCD5-90385B0CC082@nzrs.net.nz> <9C5F0CCC-F630-455B-80E8-62AF5A4D0E92@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:53:25 -0000 On 30/03/2010, at 9:49 AM, Dean Willis wrote: >=20 > On Mar 29, 2010, at 3:30 PM, Jay Daley wrote: >>=20 >>=20 >> _e2md.7.7.9.6.1.3.9.4.4.6.e164.arpa (which Dean? suggested = previously), or >> 7.7.9.6.1.3.9.4.4.6.e164md.arpa >>=20 >=20 > I liked the first suggestion at the time that Bob Penfield made it = (Dave Crocker independently suggested it), but I believe Otmar Lendl = pointed out the fatal flaw with _prefixes during the discussion on the = _displayname....TXT strawman. It doesn't work right with wildcarding. As = Otmar said: Sorry, I forgot about that. Jay >=20 >=20 >> In Germany and Austria with their open dialing plans the carrier only = knows >> to which customer the base number is associated with. The carrier = does not >> know which extension do exist and what length they are. >>=20 >> So unless the carrier delegates the ENUM space to the customer, the = carrier >> has to work with wildcards for cnam in these cases. >>=20 >> Prefixes just do not work with open numbering plans. >=20 >=20 > Jay's second alternative here doesn't have that limitation. It also is = consistent with a suggestion that I believe John Klensin made during the = BOF: formally using a different root. >=20 > It still doesn't address the "framework" vs. "specific use case" = question raised by Jon Peterson. Nor does it address the = repeatedly-raised question of differentiating between "metadata you need = when setting up a call" and "metadata needed when answering a call". But = it could well be a step forward. >=20 > -- > Dean --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From pkyzivat@cisco.com Mon Mar 29 13:55:57 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9133A6800 for ; Mon, 29 Mar 2010 13:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[AWL=1.900, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHPwaS1rXi1s for ; Mon, 29 Mar 2010 13:55:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CBF613A65A6 for ; Mon, 29 Mar 2010 13:55:56 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADexsEtAZnwN/2dsb2JhbACbJ3GnC5h1glIBgi4EjlE X-IronPort-AV: E=Sophos;i="4.51,330,1267401600"; d="scan'208";a="97141992" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Mar 2010 20:56:24 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2TKuOqJ014383; Mon, 29 Mar 2010 20:56:24 GMT Message-ID: <4BB113F8.7030904@cisco.com> Date: Mon, 29 Mar 2010 16:56:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:55:57 -0000 Cartwright, Kenneth wrote: > 5) Have a standard way to identify the source of a query, both at the > organization level, and down to the "device/node" level within an > organization (Hadriel’s proposal gives us this). I must have missed it - what was Hadriel's proposal for this functionality? (5) seems to imply: 5b) have a way to restrict the return of certain information, or vary the value returned, based on the identy of the query source And that could be at odds with caching results and returning them to others until TTL has expired, depending on your identity model. How do you expect this to be handled? Thanks, Paul From HKaplan@acmepacket.com Mon Mar 29 13:56:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2343A6986 for ; Mon, 29 Mar 2010 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhHI-TdsO+Qc for ; Mon, 29 Mar 2010 13:56:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E48193A6901 for ; Mon, 29 Mar 2010 13:56:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 16:56:55 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 16:56:55 -0400 From: Hadriel Kaplan To: E.164 To MetaData BOF discussion list Date: Mon, 29 Mar 2010 16:56:56 -0400 Thread-Topic: Plan-B for ENUM Thread-Index: AcrPgl4MPMFDmyrzR0e0sGLNq5zwuQ== Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92938@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [e2md] Plan-B for ENUM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:56:28 -0000 BTW, it's not that I *want* a new database. I'm just trying to find a way = forward. In the best-case scenario, the IETF will consider the new proposal even wor= se than E2MD, and acquiesce to E2MD. In the worst-case, they like it and w= e're all changing port numbers and possibly using a new TLD. Bad strategy? -hadriel From kcartwright@tnsi.com Mon Mar 29 14:09:16 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E613A6985 for ; Mon, 29 Mar 2010 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO4r8tj9oKU8 for ; Mon, 29 Mar 2010 14:09:16 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id F2E5E3A6975 for ; Mon, 29 Mar 2010 14:09:15 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42019160; Mon, 29 Mar 2010 17:09:39 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 17:09:39 -0400 From: "Cartwright, Kenneth" To: Paul Kyzivat Date: Mon, 29 Mar 2010 17:09:37 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPgk0mxEf4/AYCRryGl6fACqmGxgAAC7vg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529ECE@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB113F8.7030904@cisco.com> In-Reply-To: <4BB113F8.7030904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:09:17 -0000 Hi Paul, As you may know, source based responses are all already being done today on= a wide scale, but in non-standard ways. Hadriel's proposal is one designe= d to standardize and enhance this capability. He would be better to convey= the details. And the relationship between the TTL settings (caching) and = the needs of the ENUM application is a matter of policy. And these two fea= tures are not at odds. Ken -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, March 29, 2010 4:56 PM To: Cartwright, Kenneth Cc: Richard Shockey; 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'; 'E.164 T= o MetaData BOF discussion list' Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Cartwright, Kenneth wrote: > 5) Have a standard way to identify the source of a query, both at the > organization level, and down to the "device/node" level within an > organization (Hadriel's proposal gives us this). I must have missed it - what was Hadriel's proposal for this functionality? (5) seems to imply: 5b) have a way to restrict the return of certain information, or vary the value returned, based on the identy of the query source And that could be at odds with caching results and returning them to others until TTL has expired, depending on your identity model. How do you expect this to be handled? Thanks, Paul This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jay@nzrs.net.nz Mon Mar 29 14:14:45 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0178E3A6989 for ; Mon, 29 Mar 2010 14:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.409 X-Spam-Level: * X-Spam-Status: No, score=1.409 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH1hARegvC9x for ; Mon, 29 Mar 2010 14:14:39 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 6F0403A6998 for ; Mon, 29 Mar 2010 14:14:09 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 4627C2DB3E6 for ; Tue, 30 Mar 2010 10:14:37 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4JxFHCFSFX0 for ; Tue, 30 Mar 2010 10:14:37 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id E88592DB076 for ; Tue, 30 Mar 2010 10:14:36 +1300 (NZDT) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Mar 2010 10:14:36 +1300 Message-Id: To: "E.164 To MetaData BOF discussion list" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:14:48 -0000 Correct me if this is wrong but the basic premise of the source-URI = proposal is for each recipient to get a different answer, depending on = they are. One way (1) of achieving this is to give a different response = depending on who asks, but it is not the only way. The alternative (2) is simple indirection combined with private data. So (1) goes - determine who has asked - find appropriate data - send it to them and (2) goes - send private data beforehand to different parties - when anyone asks for data give the same public data - each recipient then use the public data as a key into their private = data. Each recipient with different private data will get a different = answer. (2) does not require any change to DNS, eliminates all issues of = privacy, deals with caching and wildcards and just works. A more concrete example: - under 7.7.6.9.1.3.9.4.4.6.whatever is published NAPTR "e2md" "meta-endpoint:endpoint-1" - my best buddy carrier has private data that says "endpoint-1" is serviced by "sip:6449316977@somewhere-special" - all other carriers I am forced by regulators to connect to have data = that says "endpoint-1" is serviced by = "sip6449316977@little-box-in-the-corner" any thoughts? Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From HKaplan@acmepacket.com Mon Mar 29 14:16:52 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D0F3A697B for ; Mon, 29 Mar 2010 14:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=0.924, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgJgTzw3agzk for ; Mon, 29 Mar 2010 14:16:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 23AC13A6990 for ; Mon, 29 Mar 2010 14:16:50 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 17:17:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 17:17:17 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Cartwright, Kenneth" Date: Mon, 29 Mar 2010 17:17:18 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPgkvgXT04LVc+TzqbnpchcGNngAAAdQWw Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92948@mail> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB113F8.7030904@cisco.com> In-Reply-To: <4BB113F8.7030904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: discussion list' , 'E.164 Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:16:52 -0000 An old one: draft-kaplan-enum-source-uri-00 It's expired, but we implemented support for it and it appears to be popula= r for some folks. I've gotten several customer requests to re-submit this = recently, so we can get an officially reserved code number and so it's not = just an individual draft. The results are not cached - the TTL is zero. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 29, 2010 4:56 PM > To: Cartwright, Kenneth > Cc: Richard Shockey; Hadriel Kaplan; 'Jay Daley'; 'Dean Willis'; 'E.164 T= o > MetaData BOF discussion list' > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling >=20 >=20 >=20 > Cartwright, Kenneth wrote: >=20 > > 5) Have a standard way to identify the source of a query, both at the > > organization level, and down to the "device/node" level within an > > organization (Hadriel's proposal gives us this). >=20 > I must have missed it - what was Hadriel's proposal for this > functionality? >=20 > (5) seems to imply: >=20 > 5b) have a way to restrict the return of certain information, or vary > the value returned, based on the identy of the query source >=20 > And that could be at odds with caching results and returning them to > others until TTL has expired, depending on your identity model. How do > you expect this to be handled? >=20 > Thanks, > Paul From pkyzivat@cisco.com Mon Mar 29 14:18:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500443A6975 for ; Mon, 29 Mar 2010 14:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=1.520, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYGEn8lTMgXA for ; Mon, 29 Mar 2010 14:18:26 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 95B133A694E for ; Mon, 29 Mar 2010 14:18:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOa1sEtAZnwN/2dsb2JhbACbJ3GmZph6glIBBoIoBI5R X-IronPort-AV: E=Sophos;i="4.51,330,1267401600"; d="scan'208";a="97288832" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2010 21:18:54 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2TLIsJR021879; Mon, 29 Mar 2010 21:18:54 GMT Message-ID: <4BB1193E.5040606@cisco.com> Date: Mon, 29 Mar 2010 17:18:54 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB113F8.7030904@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529ECE@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529ECE@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:18:29 -0000 Cartwright, Kenneth wrote: > Hi Paul, > > As you may know, source based responses are all already being done today on a wide scale, but in non-standard ways. Hadriel's proposal is one designed to standardize and enhance this capability. He would be better to convey the details. And the relationship between the TTL settings (caching) and the needs of the ENUM application is a matter of policy. And these two features are not at odds. They can be at odds of there is an agent doing queries on behalf of multiple sources. The identity of the caching agent may be used in all cases, rather than the identity of the caching agent's client. This may or may not be the intended behavior. It at least needs to be specified. And of course it has the potential to degrade the value of caching. Thanks, Paul > Ken > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 29, 2010 4:56 PM > To: Cartwright, Kenneth > Cc: Richard Shockey; 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'; 'E.164 To MetaData BOF discussion list' > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > > > > Cartwright, Kenneth wrote: > >> 5) Have a standard way to identify the source of a query, both at the >> organization level, and down to the "device/node" level within an >> organization (Hadriel's proposal gives us this). > > I must have missed it - what was Hadriel's proposal for this functionality? > > (5) seems to imply: > > 5b) have a way to restrict the return of certain information, or vary > the value returned, based on the identy of the query source > > And that could be at odds with caching results and returning them to > others until TTL has expired, depending on your identity model. How do > you expect this to be handled? > > Thanks, > Paul > > > This e-mail message is for the sole use of the intended recipient(s)and may > contain confidential and privileged information of Transaction Network Services. > Any unauthorised review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > > From kcartwright@tnsi.com Mon Mar 29 14:27:46 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3BEE3A6990 for ; Mon, 29 Mar 2010 14:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ+zv93yZKmB for ; Mon, 29 Mar 2010 14:27:46 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id AC6043A6975 for ; Mon, 29 Mar 2010 14:27:43 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42019643; Mon, 29 Mar 2010 17:28:01 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 17:28:01 -0400 From: "Cartwright, Kenneth" To: Paul Kyzivat Date: Mon, 29 Mar 2010 17:27:59 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrPhXIy5+frqBXyQHu7RhoCoWMVIwAAHiBA Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529EE8@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB113F8.7030904@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529ECE@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB1193E.5040606@cisco.com> In-Reply-To: <4BB1193E.5040606@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:27:47 -0000 Hi Paul, Your use case if course valid. And you are correct to point out that one n= eeds to pay attention to TTL (cache settings) when establishing any data qu= ery/retrieval infrastructure. However, these two features are not at odds.= But they do have inter-dependence under some use cases. Iow, this is a m= atter of policy. As I said, this is already being done on a wide scale tod= ay. Nothing new under the sun here. Ken -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, March 29, 2010 5:19 PM To: Cartwright, Kenneth Cc: Richard Shockey; 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'; 'E.164 T= o MetaData BOF discussion list' Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Cartwright, Kenneth wrote: > Hi Paul, > > As you may know, source based responses are all already being done today = on a wide scale, but in non-standard ways. Hadriel's proposal is one desig= ned to standardize and enhance this capability. He would be better to conv= ey the details. And the relationship between the TTL settings (caching) an= d the needs of the ENUM application is a matter of policy. And these two f= eatures are not at odds. They can be at odds of there is an agent doing queries on behalf of multiple sources. The identity of the caching agent may be used in all cases, rather than the identity of the caching agent's client. This may or may not be the intended behavior. It at least needs to be specified. And of course it has the potential to degrade the value of caching. Thanks, Paul > Ken > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, March 29, 2010 4:56 PM > To: Cartwright, Kenneth > Cc: Richard Shockey; 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'; 'E.164= To MetaData BOF discussion list' > Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > > > > Cartwright, Kenneth wrote: > >> 5) Have a standard way to identify the source of a query, both at the >> organization level, and down to the "device/node" level within an >> organization (Hadriel's proposal gives us this). > > I must have missed it - what was Hadriel's proposal for this functionalit= y? > > (5) seems to imply: > > 5b) have a way to restrict the return of certain information, or vary > the value returned, based on the identy of the query source > > And that could be at odds with caching results and returning them to > others until TTL has expired, depending on your identity model. How do > you expect this to be handled? > > Thanks, > Paul > > > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > > This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From HKaplan@acmepacket.com Mon Mar 29 14:28:36 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326D03A6990 for ; Mon, 29 Mar 2010 14:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.732 X-Spam-Level: X-Spam-Status: No, score=0.732 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwJNYw4sN0Th for ; Mon, 29 Mar 2010 14:28:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4DBE83A6986 for ; Mon, 29 Mar 2010 14:28:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 17:29:00 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 17:29:00 -0400 From: Hadriel Kaplan To: Jay Daley , E.164 To MetaData BOF discussion list Date: Mon, 29 Mar 2010 17:29:00 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPhQKusl2k6XPSS/W8Nc2aa+e1lgAAEVyQ Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:28:36 -0000 Unfortunately it's not who asked the DNS query. (otherwise we could just us= e IP-Address based views) It's who originated the application request, which triggered the DNS query = (possibly by a third party). For example, in a private carrier model where proxies generate the ENUM-DNS= query when they get SIP requests, it's the SIP URI of the originator of th= e SIP request. The primary use-case of it is in the SIP or H.323 routing use-case with ENU= M, where the source of the call affects how the call gets routed. (for a bu= nch of reasons) So (2) wouldn't work because the same DNS client needs to use different res= ult data for the same query key, based on where the SIP request came from. -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Jay Daley > Sent: Monday, March 29, 2010 5:15 PM > To: E.164 To MetaData BOF discussion list > Subject: [e2md] Alternative to source URI >=20 > Correct me if this is wrong but the basic premise of the source-URI > proposal is for each recipient to get a different answer, depending on > they are. One way (1) of achieving this is to give a different response > depending on who asks, but it is not the only way. >=20 > The alternative (2) is simple indirection combined with private data. >=20 > So (1) goes > - determine who has asked > - find appropriate data > - send it to them >=20 > and (2) goes > - send private data beforehand to different parties > - when anyone asks for data give the same public data > - each recipient then use the public data as a key into their private dat= a. > Each recipient with different private data will get a different answer. >=20 > (2) does not require any change to DNS, eliminates all issues of privacy, > deals with caching and wildcards and just works. >=20 > A more concrete example: >=20 > - under 7.7.6.9.1.3.9.4.4.6.whatever is published > NAPTR "e2md" "meta-endpoint:endpoint-1" >=20 > - my best buddy carrier has private data that says > "endpoint-1" is serviced by "sip:6449316977@somewhere-special" >=20 > - all other carriers I am forced by regulators to connect to have data > that says > "endpoint-1" is serviced by "sip6449316977@little-box-in-the-corner" >=20 >=20 > any thoughts? > Jay >=20 > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From pkyzivat@cisco.com Mon Mar 29 14:29:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8C93A6998 for ; Mon, 29 Mar 2010 14:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.202 X-Spam-Level: X-Spam-Status: No, score=-8.202 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6S8E9diCZpN for ; Mon, 29 Mar 2010 14:29:11 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 138003A6986 for ; Mon, 29 Mar 2010 14:29:10 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+4sEtAZnwN/2dsb2JhbACbJ3Gmcph4glIBBoIoBI5R X-IronPort-AV: E=Sophos;i="4.51,330,1267401600"; d="scan'208";a="97291133" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2010 21:29:39 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2TLTcRa024875; Mon, 29 Mar 2010 21:29:38 GMT Message-ID: <4BB11BC2.5040600@cisco.com> Date: Mon, 29 Mar 2010 17:29:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Cartwright, Kenneth" References: <4BAA4248.2050601@softarmor.com> <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB113F8.7030904@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529ECE@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB1193E.5040606@cisco.com> In-Reply-To: <4BB1193E.5040606@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'E.164 To MetaData BOF discussion list'" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:29:12 -0000 Hadriel just sent me a ref to the proposal, which was different than I was imagining. Since the "source" is an explicit argument, and the TTL is specified to always be zero, I don't have *technical" objections to it. (I don't *like* it, but that is an opinion.) Thanks, Paul Paul Kyzivat wrote: > > > Cartwright, Kenneth wrote: >> Hi Paul, >> >> As you may know, source based responses are all already being done >> today on a wide scale, but in non-standard ways. Hadriel's proposal >> is one designed to standardize and enhance this capability. He would >> be better to convey the details. And the relationship between the TTL >> settings (caching) and the needs of the ENUM application is a matter >> of policy. And these two features are not at odds. > > They can be at odds of there is an agent doing queries on behalf of > multiple sources. The identity of the caching agent may be used in all > cases, rather than the identity of the caching agent's client. This may > or may not be the intended behavior. > > It at least needs to be specified. > > And of course it has the potential to degrade the value of caching. > > Thanks, > Paul > >> Ken >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, March 29, 2010 4:56 PM >> To: Cartwright, Kenneth >> Cc: Richard Shockey; 'Hadriel Kaplan'; 'Jay Daley'; 'Dean Willis'; >> 'E.164 To MetaData BOF discussion list' >> Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling >> >> >> >> Cartwright, Kenneth wrote: >> >>> 5) Have a standard way to identify the source of a query, both at the >>> organization level, and down to the "device/node" level within an >>> organization (Hadriel's proposal gives us this). >> >> I must have missed it - what was Hadriel's proposal for this >> functionality? >> >> (5) seems to imply: >> >> 5b) have a way to restrict the return of certain information, or vary >> the value returned, based on the identy of the query source >> >> And that could be at odds with caching results and returning them to >> others until TTL has expired, depending on your identity model. How do >> you expect this to be handled? >> >> Thanks, >> Paul >> >> >> This e-mail message is for the sole use of the intended >> recipient(s)and may >> contain confidential and privileged information of Transaction Network >> Services. >> Any unauthorised review, use, disclosure or distribution is >> prohibited. If you >> are not the intended recipient, please contact the sender by reply >> e-mail and destroy all copies of the original message. >> >> > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From dean.willis@softarmor.com Mon Mar 29 14:33:55 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994923A6B2D for ; Mon, 29 Mar 2010 14:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij97AEPHCsQa for ; Mon, 29 Mar 2010 14:33:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EADA43A698E for ; Mon, 29 Mar 2010 14:33:51 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TLYHSG008704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 16:34:19 -0500 Message-Id: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> From: Dean Willis To: Jay Daley In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 16:34:12 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:33:55 -0000 On Mar 29, 2010, at 4:14 PM, Jay Daley wrote: > > The alternative (2) is simple indirection combined with private data. > > ... > > and (2) goes > - send private data beforehand to different parties > - when anyone asks for data give the same public data > - each recipient then use the public data as a key into their > private data. Each recipient with different private data will get a > different answer. > > (2) does not require any change to DNS, eliminates all issues of > privacy, deals with caching and wildcards and just works. > > A more concrete example: > > - under 7.7.6.9.1.3.9.4.4.6.whatever is published > NAPTR "e2md" "meta-endpoint:endpoint-1" > > - my best buddy carrier has private data that says > "endpoint-1" is serviced by "sip:6449316977@somewhere-special" > > - all other carriers I am forced by regulators to connect to have > data that says > "endpoint-1" is serviced by "sip6449316977@little-box-in-the-corner" > > > any thoughts? I think it's very interesting. A fairly large number of people in Anaheim told me that they thought that the DNS's "immune system" would be open to putting in a pointer to a general metadata-lookup service along these lines. The model they seemed to have in mind is that "The DNS" would have a per-phone-number (or per-phone-number-aggregation) record that would point to the metadata service for that phone number or aggregation- range. This eliminates many of the concerns: 1) We don't end up putting an additional record into the DNS for each piece of metadata 2) We don't have to define a selective-query or search mechanism on top of DNS 3) We don't have very-large RR-sets in responses due to having many different metadata types 4) We don't need to extend DNS to support source-specific responses 5) Authentication and authorization concerns are pushed out of the DNS's core and onto "the other protocol/service" The one repeatedly-heard concern that I know of that this proposal doesn't directly address is the "framework vs. individual use case" issue. However, I believe that the main reason this issue comes up is that adding arbitrary metadata into the DNS is considered a problem due to to the questions above, which Jay's #2 proposal neatly bypasses. So, I don't think we'd have nearly the problem with saying that the external metadata service returns metadata within an extensible schema that we have with building an extensible metadata schema directly in the DNS. Further, the "metadata" service that the URI points to could well have all the fast-lookup properties that we know and love from DNS. One might think of the URI as being something of a "metadata delgation". -- Dean From dean.willis@softarmor.com Mon Mar 29 14:36:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6DB3A6B69 for ; Mon, 29 Mar 2010 14:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5DxFVbOwB42 for ; Mon, 29 Mar 2010 14:36:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 172183A6998 for ; Mon, 29 Mar 2010 14:36:24 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TLamRB008718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 16:36:50 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 16:36:42 -0500 References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:36:29 -0000 On Mar 29, 2010, at 4:29 PM, Hadriel Kaplan wrote: > > Unfortunately it's not who asked the DNS query. (otherwise we could > just use IP-Address based views) > It's who originated the application request, which triggered the DNS > query (possibly by a third party). > > For example, in a private carrier model where proxies generate the > ENUM-DNS query when they get SIP requests, it's the SIP URI of the > originator of the SIP request. > > The primary use-case of it is in the SIP or H.323 routing use-case > with ENUM, where the source of the call affects how the call gets > routed. (for a bunch of reasons) > > So (2) wouldn't work because the same DNS client needs to use > different result data for the same query key, based on where the SIP > request came from. 2 would apparently work if the "other protocol" used to dereference the E2MD URI conveyed the source information. -- Dean From kcartwright@tnsi.com Mon Mar 29 14:37:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338D93A698E for ; Mon, 29 Mar 2010 14:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.016 X-Spam-Level: * X-Spam-Status: No, score=1.016 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waWDFB+RA6ve for ; Mon, 29 Mar 2010 14:37:27 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id B20643A6989 for ; Mon, 29 Mar 2010 14:37:27 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42019862; Mon, 29 Mar 2010 17:37:54 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Mon, 29 Mar 2010 17:37:54 -0400 From: "Cartwright, Kenneth" To: Dean Willis , Jay Daley Date: Mon, 29 Mar 2010 17:37:52 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPh5yCncqROCmsRdOWNuWVNmteaQAADWJw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> In-Reply-To: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:37:30 -0000 This approach is less amenable to my needs and seems un-necessarily slow an= d complex for the use cases we have. However, there is of course nothing t= hat says that a given E2U/E2M service cannot re-direct to another URL if th= at is appropriate for that service. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Dea= n Willis Sent: Monday, March 29, 2010 5:34 PM To: Jay Daley Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI On Mar 29, 2010, at 4:14 PM, Jay Daley wrote: > > The alternative (2) is simple indirection combined with private data. > > ... > > and (2) goes > - send private data beforehand to different parties > - when anyone asks for data give the same public data > - each recipient then use the public data as a key into their > private data. Each recipient with different private data will get a > different answer. > > (2) does not require any change to DNS, eliminates all issues of > privacy, deals with caching and wildcards and just works. > > A more concrete example: > > - under 7.7.6.9.1.3.9.4.4.6.whatever is published > NAPTR "e2md" "meta-endpoint:endpoint-1" > > - my best buddy carrier has private data that says > "endpoint-1" is serviced by "sip:6449316977@somewhere-special" > > - all other carriers I am forced by regulators to connect to have > data that says > "endpoint-1" is serviced by "sip6449316977@little-box-in-the-corner= " > > > any thoughts? I think it's very interesting. A fairly large number of people in Anaheim told me that they thought that the DNS's "immune system" would be open to putting in a pointer to a general metadata-lookup service along these lines. The model they seemed to have in mind is that "The DNS" would have a per-phone-number (or per-phone-number-aggregation) record that would point to the metadata service for that phone number or aggregation- range. This eliminates many of the concerns: 1) We don't end up putting an additional record into the DNS for each piece of metadata 2) We don't have to define a selective-query or search mechanism on top of DNS 3) We don't have very-large RR-sets in responses due to having many different metadata types 4) We don't need to extend DNS to support source-specific responses 5) Authentication and authorization concerns are pushed out of the DNS's core and onto "the other protocol/service" The one repeatedly-heard concern that I know of that this proposal doesn't directly address is the "framework vs. individual use case" issue. However, I believe that the main reason this issue comes up is that adding arbitrary metadata into the DNS is considered a problem due to to the questions above, which Jay's #2 proposal neatly bypasses. So, I don't think we'd have nearly the problem with saying that the external metadata service returns metadata within an extensible schema that we have with building an extensible metadata schema directly in the DNS. Further, the "metadata" service that the URI points to could well have all the fast-lookup properties that we know and love from DNS. One might think of the URI as being something of a "metadata delgation". -- Dean _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jay@nzrs.net.nz Mon Mar 29 14:40:48 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0B33A69A5 for ; Mon, 29 Mar 2010 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.37 X-Spam-Level: * X-Spam-Status: No, score=1.37 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjIMTNkgi-Me for ; Mon, 29 Mar 2010 14:40:47 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id A956A3A699E for ; Mon, 29 Mar 2010 14:40:46 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 811152DB4ED; Tue, 30 Mar 2010 10:41:14 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaYkUHyEbfH3; Tue, 30 Mar 2010 10:41:14 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 36D092DAFB3; Tue, 30 Mar 2010 10:41:14 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-265--466102129 From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> Date: Tue, 30 Mar 2010 10:41:13 +1300 Message-Id: References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:40:48 -0000 --Apple-Mail-265--466102129 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry Hadriel I don't get what you are saying. >=20 On 30/03/2010, at 10:29 AM, Hadriel Kaplan wrote: > Unfortunately it's not who asked the DNS query. (otherwise we could = just use IP-Address based views) > It's who originated the application request, which triggered the DNS = query (possibly by a third party). >=20 > For example, in a private carrier model where proxies generate the = ENUM-DNS query when they get SIP requests, it's the SIP URI of the = originator of the SIP request. It is the originators who have the "private" data, not the proxies. > The primary use-case of it is in the SIP or H.323 routing use-case = with ENUM, where the source of the call affects how the call gets = routed. (for a bunch of reasons) Which is specifically what I intended it for.=20 > So (2) wouldn't work because the same DNS client needs to use = different result data for the same query key, based on where the SIP = request came from. I don't see what the DNS client has to do with it - it just passes on = the data to higher up the stack where the keying into the private data = takes place. If you could help me understand then I would appreciate it. thanks Jay >=20 > -hadriel >=20 >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of >> Jay Daley >> Sent: Monday, March 29, 2010 5:15 PM >> To: E.164 To MetaData BOF discussion list >> Subject: [e2md] Alternative to source URI >>=20 >> Correct me if this is wrong but the basic premise of the source-URI >> proposal is for each recipient to get a different answer, depending = on >> they are. One way (1) of achieving this is to give a different = response >> depending on who asks, but it is not the only way. >>=20 >> The alternative (2) is simple indirection combined with private data. >>=20 >> So (1) goes >> - determine who has asked >> - find appropriate data >> - send it to them >>=20 >> and (2) goes >> - send private data beforehand to different parties >> - when anyone asks for data give the same public data >> - each recipient then use the public data as a key into their private = data. >> Each recipient with different private data will get a different = answer. >>=20 >> (2) does not require any change to DNS, eliminates all issues of = privacy, >> deals with caching and wildcards and just works. >>=20 >> A more concrete example: >>=20 >> - under 7.7.6.9.1.3.9.4.4.6.whatever is published >> NAPTR "e2md" "meta-endpoint:endpoint-1" >>=20 >> - my best buddy carrier has private data that says >> "endpoint-1" is serviced by "sip:6449316977@somewhere-special" >>=20 >> - all other carriers I am forced by regulators to connect to have = data >> that says >> "endpoint-1" is serviced by = "sip6449316977@little-box-in-the-corner" >>=20 >>=20 >> any thoughts? >> Jay >>=20 >> -- >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >>=20 >> _______________________________________________ >> e2md mailing list >> e2md@ietf.org >> https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 --Apple-Mail-265--466102129 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 30/03/2010, at = 10:29 AM, Hadriel Kaplan wrote:

Unfortunately it's not who asked the DNS query. = (otherwise we could just use IP-Address based views)
It's who = originated the application request, which triggered the DNS query = (possibly by a third party).

For example, in a private carrier = model where proxies generate the ENUM-DNS query when they get SIP = requests, it's the SIP URI of the originator of the SIP = request.

It is the originators = who have the "private" data, not the proxies.

The primary use-case of it is in the SIP or H.323 = routing use-case with ENUM, where the source of the call affects how the = call gets routed. (for a bunch of = reasons)

Which is specifically = what I intended it for. 

So = (2) wouldn't work because the same DNS client needs to use different = result data for the same query key, based on where the SIP request came = from.

I don't see what the DNS = client has to do with it - it just passes on the data to higher up the = stack where the keying into the private data takes = place.

If you could help me understand then I = would appreciate = it.

thanks
Jay


-hadriel

-----Original Message-----
From: e2md-bounces@ietf.org = [mailto:e2md-bounces@ietf.org] On Behalf Of
Jay Daley
Sent: = Monday, March 29, 2010 5:15 PM
To: E.164 To MetaData BOF discussion = list
Subject: [e2md] = Alternative to source URI

Correct me if = this is wrong but the basic premise of the = source-URI
proposal is for = each recipient to get a different answer, depending = on
they are.  One way (1) = of achieving this is to give a different = response
depending on who = asks, but it is not the only way.

The alternative = (2) is simple indirection combined with private = data.

So (1) = goes
- determine who has = asked
- find appropriate = data
- send it to = them

and (2) = goes
- send private data = beforehand to different parties
- when anyone asks for data give the same public = data
- each recipient then use = the public data as a key into their private = data.
Each recipient with = different private data will get a different = answer.

(2) does not = require any change to DNS, eliminates all issues of = privacy,
deals with caching = and wildcards and just works.

A more concrete = example:

- under = 7.7.6.9.1.3.9.4.4.6.whatever is published
= NAPTR "e2md" = "meta-endpoint:endpoint-1"

- my best buddy = carrier has private data that says
= "endpoint-1" is serviced by "sip:6449316977@somewhere-special= "

- all other = carriers I am forced by regulators to connect to have = data
that = says
= "endpoint-1" is serviced by = "sip6449316977@little-box-in-the-corner"


any = thoughts?
Jay

--
Jay = Daley
Chief = Executive
.nz Registry = Services (New Zealand Domain Name Registry = Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840

_______________________________________________
e2md mailing = list
e2md@ietf.org
https://www.ietf.org/m= ailman/listinfo/e2md


-- 
Jay = Daley
Chief Executive
.nz Registry Services (New = Zealand Domain Name Registry Limited)
desk: +64 4 931 = 6977
mobile: +64 21 = 678840
= --Apple-Mail-265--466102129-- From jay@nzrs.net.nz Mon Mar 29 14:52:32 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D55A3A69B5 for ; Mon, 29 Mar 2010 14:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.34 X-Spam-Level: * X-Spam-Status: No, score=1.34 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuuKdh8dalpC for ; Mon, 29 Mar 2010 14:52:31 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id C8D923A69AE for ; Mon, 29 Mar 2010 14:52:30 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 93AA52DB4ED; Tue, 30 Mar 2010 10:52:58 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1CXaQBp7-bg; Tue, 30 Mar 2010 10:52:58 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 41E762DAFB3; Tue, 30 Mar 2010 10:52:58 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> Date: Tue, 30 Mar 2010 10:52:57 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> To: "Cartwright, Kenneth" X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:52:32 -0000 On 30/03/2010, at 10:37 AM, Cartwright, Kenneth wrote: > This approach is less amenable to my needs and seems un-necessarily = slow and complex for the use cases we have.=20 Can you explain why? I think it is actually faster as per this explanation: For (1) there are two additional lookups to plain DNS - lookup to check the validity of the source URI - lookup to retrieve information specific to the source URI for (2) there is only one additional lookup and that is done by the = recipient of the data not you - lookup to find private data keyed to public data It also seems far less complex - the information given out in DNS is always the same - there is no issue with spoofing of the source/validation of the source cheers Jay > However, there is of course nothing that says that a given E2U/E2M = service cannot re-direct to another URL if that is appropriate for that = service. >=20 > Ken >=20 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Dean Willis > Sent: Monday, March 29, 2010 5:34 PM > To: Jay Daley > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Alternative to source URI >=20 >=20 > On Mar 29, 2010, at 4:14 PM, Jay Daley wrote: >>=20 >> The alternative (2) is simple indirection combined with private data. >>=20 >> ... >>=20 >> and (2) goes >> - send private data beforehand to different parties >> - when anyone asks for data give the same public data >> - each recipient then use the public data as a key into their >> private data. Each recipient with different private data will get a >> different answer. >>=20 >> (2) does not require any change to DNS, eliminates all issues of >> privacy, deals with caching and wildcards and just works. >>=20 >> A more concrete example: >>=20 >> - under 7.7.6.9.1.3.9.4.4.6.whatever is published >> NAPTR "e2md" "meta-endpoint:endpoint-1" >>=20 >> - my best buddy carrier has private data that says >> "endpoint-1" is serviced by "sip:6449316977@somewhere-special" >>=20 >> - all other carriers I am forced by regulators to connect to have >> data that says >> "endpoint-1" is serviced by = "sip6449316977@little-box-in-the-corner" >>=20 >>=20 >> any thoughts? >=20 >=20 > I think it's very interesting. >=20 > A fairly large number of people in Anaheim told me that they thought > that the DNS's "immune system" would be open to putting in a pointer > to a general metadata-lookup service along these lines. >=20 > The model they seemed to have in mind is that "The DNS" would have a > per-phone-number (or per-phone-number-aggregation) record that would > point to the metadata service for that phone number or aggregation- > range. >=20 > This eliminates many of the concerns: >=20 > 1) We don't end up putting an additional record into the DNS for each > piece of metadata >=20 > 2) We don't have to define a selective-query or search mechanism on > top of DNS >=20 > 3) We don't have very-large RR-sets in responses due to having many > different metadata types >=20 > 4) We don't need to extend DNS to support source-specific responses >=20 > 5) Authentication and authorization concerns are pushed out of the > DNS's core and onto "the other protocol/service" >=20 > The one repeatedly-heard concern that I know of that this proposal > doesn't directly address is the "framework vs. individual use case" > issue. However, I believe that the main reason this issue comes up is > that adding arbitrary metadata into the DNS is considered a problem > due to to the questions above, which Jay's #2 proposal neatly > bypasses. So, I don't think we'd have nearly the problem with saying > that the external metadata service returns metadata within an > extensible schema that we have with building an extensible metadata > schema directly in the DNS. >=20 > Further, the "metadata" service that the URI points to could well have > all the fast-lookup properties that we know and love from DNS. One > might think of the URI as being something of a "metadata delgation". >=20 > -- > Dean >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 > This e-mail message is for the sole use of the intended = recipient(s)and may > contain confidential and privileged information of Transaction Network = Services. > Any unauthorised review, use, disclosure or distribution is = prohibited. If you > are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Mon Mar 29 14:58:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE6E3A68F6 for ; Mon, 29 Mar 2010 14:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.353 X-Spam-Level: X-Spam-Status: No, score=0.353 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyg1ukGefEBH for ; Mon, 29 Mar 2010 14:58:43 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A1F253A6937 for ; Mon, 29 Mar 2010 14:58:27 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TLwqat008889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Mar 2010 16:58:54 -0500 Message-Id: <75A48EA0-9FDF-42E3-839F-E128903F6B61@softarmor.com> From: Dean Willis To: "E.164 To MetaData BOF discussion list" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Mar 2010 16:58:46 -0500 References: X-Mailer: Apple Mail (2.936) Cc: Olaf Kolkman , pk@ISOC.DE, John C Klensin , =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Jon Peterson Subject: [e2md] Revision to draft minutes of E2MD; characterization of ENUM URI result X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 21:58:44 -0000 Where the previous draft minutes said: > > The chairs stated that the basic idea is similar to ENUM, but > instead of > mapping the E.164 number to a URI that identifies the resource labeled > by the E.164 number, we are mapping the E.164 number to information > about that phone number. Replace paragraph with: The chairs stated that the basic idea is similar to ENUM, but instead of mapping the E.164 number to a URI that identifies the resource labeled by the E.164 number, we are mapping the E.164 number to information about that phone number. Jon Peterson noted that there had been some discussion on the nature of the URI in ENUM, and that it identifies a resource but is not necessarily used for establishing a session with that resource. -- Dean From HKaplan@acmepacket.com Mon Mar 29 18:04:56 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5FF3A682C for ; Mon, 29 Mar 2010 18:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.742 X-Spam-Level: X-Spam-Status: No, score=0.742 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBAKEiIJcd+Q for ; Mon, 29 Mar 2010 18:04:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8456F3A67FA for ; Mon, 29 Mar 2010 18:04:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 21:05:23 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 21:05:23 -0400 From: Hadriel Kaplan To: Jay Daley Date: Mon, 29 Mar 2010 21:05:23 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPiJd1vSGBo3dwQXerUqWvFOr+WgAGrYWg Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92982@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 01:04:56 -0000 Sorry I thought you meant based on which endpoint made the DNS query. Maybe I'm confused as to the proposal in general. :) Basically, as far as I know, those of using it are using it in private sett= ings. You get a SIP call from an endpoint/pbx/peer, and you do a routing l= ookup by querying a private DNS server using ENUM, which returns the NAPTRs= for routing it on. But due to different tariffs and peering policies, whe= re you route it on to depends on where it came from. In some contexts this= is just a trunk difference - if it came from peer X with target number Y t= hen send it to Z. In other cases it's a number prefix difference - if it c= omes from prefix X with target number Y then send it to Z. So let's assume destination Y is 12345. I am a proxy. I get a SIP request= for destination 12345, from source 77777. I query 5.4.3.2.1.foo. What do I get back? How do I use what I get back to determine how to route= it, given this specific case is for source 67890, which is a different rou= te than if I got a SIP request for the same destination but from source 888= 88? -hadriel ________________________________________ From: Jay Daley [mailto:jay@nzrs.net.nz]=20 Sent: Monday, March 29, 2010 5:41 PM To: Hadriel Kaplan Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI Sorry Hadriel I don't get what you are saying. On 30/03/2010, at 10:29 AM, Hadriel Kaplan wrote: Unfortunately it's not who asked the DNS query. (otherwise we could just us= e IP-Address based views) It's who originated the application request, which triggered the DNS query = (possibly by a third party). For example, in a private carrier model where proxies generate the ENUM-DNS= query when they get SIP requests, it's the SIP URI of the originator of th= e SIP request. It is the originators who have the "private" data, not the proxies. The primary use-case of it is in the SIP or H.323 routing use-case with ENU= M, where the source of the call affects how the call gets routed. (for a bu= nch of reasons) Which is specifically what I intended it for.=A0 So (2) wouldn't work because the same DNS client needs to use different res= ult data for the same query key, based on where the SIP request came from. I don't see what the DNS client has to do with it - it just passes on the d= ata to higher up the stack where the keying into the private data takes pla= ce. If you could help me understand then I would appreciate it. thanks Jay -hadriel -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay Daley Sent: Monday, March 29, 2010 5:15 PM To: E.164 To MetaData BOF discussion list Subject: [e2md] Alternative to source URI Correct me if this is wrong but the basic premise of the source-URI proposal is for each recipient to get a different answer, depending on they are. =A0One way (1) of achieving this is to give a different response depending on who asks, but it is not the only way. The alternative (2) is simple indirection combined with private data. So (1) goes - determine who has asked - find appropriate data - send it to them and (2) goes - send private data beforehand to different parties - when anyone asks for data give the same public data - each recipient then use the public data as a key into their private data. Each recipient with different private data will get a different answer. (2) does not require any change to DNS, eliminates all issues of privacy, deals with caching and wildcards and just works. A more concrete example: - under 7.7.6.9.1.3.9.4.4.6.whatever is published NAPTR "e2md" "meta-endpoint:endpoint-1" - my best buddy carrier has private data that says "endpoint-1" is serviced by "sip:6449316977@somewhere-special" - all other carriers I am forced by regulators to connect to have data that says "endpoint-1" is serviced by "sip6449316977@little-box-in-the-corner" any thoughts? Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md --=A0 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From HKaplan@acmepacket.com Mon Mar 29 18:24:44 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61293A683F for ; Mon, 29 Mar 2010 18:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.751 X-Spam-Level: X-Spam-Status: No, score=0.751 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c373HKK9AZfl for ; Mon, 29 Mar 2010 18:24:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C956A3A6774 for ; Mon, 29 Mar 2010 18:24:42 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 21:25:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 21:25:10 -0400 From: Hadriel Kaplan To: Jay Daley , "Cartwright, Kenneth" Date: Mon, 29 Mar 2010 21:25:11 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPikHHe9pd67l9R+Cv63m9wnxWgAAGwRvw Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92990@mail> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> In-Reply-To: <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 01:24:45 -0000 I think I'm understanding your concern more now. You're thinking of it in = the public DNS context (ie, The DNS). In the private ENUM model it's the same server or database that has to answ= er the routing question, so moving the problem around doesn't help. In the public model you're right the public server has no idea how to route= the request from and through any given carrier. For that model I think some of us are thinking this would be where the SPID= /SPN comes in. The public servers would just return a SPID/SPN which the o= riginating/transit carriers would use for their internal lookups. There would be no source-based distinction for the public entries - the sam= e SPID/SPN would represent the terminating/final administrative domain rega= rdless of source. In that sense it *is* a form of indirection, I suppose. But internally within the originating/transit domains they'd need source-ur= i, because that SPID/SPN key still gets different results based on the sour= ce. (and in the US the SPID/SPN wouldn't be enough for an internal lookup k= ey, unless each LATA gets its own SPID/SPN) Although I could argue source-uri could still be useful in a public context= , so that for example a public ENUM of NZ numbers could say "if the call co= mes from +64, use this SPID, if it comes from the anything else use this SP= ID, except if it comes from +61 then don't call us". :) -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Jay Daley > Sent: Monday, March 29, 2010 5:53 PM > To: Cartwright, Kenneth > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Alternative to source URI >=20 >=20 > On 30/03/2010, at 10:37 AM, Cartwright, Kenneth wrote: >=20 > > This approach is less amenable to my needs and seems un-necessarily slo= w > and complex for the use cases we have. >=20 > Can you explain why? >=20 > I think it is actually faster as per this explanation: >=20 > For (1) there are two additional lookups to plain DNS >=20 > - lookup to check the validity of the source URI > - lookup to retrieve information specific to the source URI >=20 > for (2) there is only one additional lookup and that is done by the > recipient of the data not you >=20 > - lookup to find private data keyed to public data >=20 > It also seems far less complex >=20 > - the information given out in DNS is always the same > - there is no issue with spoofing of the source/validation of the source >=20 > cheers > Jay >=20 >=20 > > However, there is of course nothing that says that a given E2U/E2M > service cannot re-direct to another URL if that is appropriate for that > service. > > > > Ken > > > > -----Original Message----- > > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > > Sent: Monday, March 29, 2010 5:34 PM > > To: Jay Daley > > Cc: E.164 To MetaData BOF discussion list > > Subject: Re: [e2md] Alternative to source URI > > > > > > On Mar 29, 2010, at 4:14 PM, Jay Daley wrote: > >> > >> The alternative (2) is simple indirection combined with private data. > >> > >> ... > >> > >> and (2) goes > >> - send private data beforehand to different parties > >> - when anyone asks for data give the same public data > >> - each recipient then use the public data as a key into their > >> private data. Each recipient with different private data will get a > >> different answer. > >> > >> (2) does not require any change to DNS, eliminates all issues of > >> privacy, deals with caching and wildcards and just works. > >> > >> A more concrete example: > >> > >> - under 7.7.6.9.1.3.9.4.4.6.whatever is published > >> NAPTR "e2md" "meta-endpoint:endpoint-1" > >> > >> - my best buddy carrier has private data that says > >> "endpoint-1" is serviced by "sip:6449316977@somewhere-special" > >> > >> - all other carriers I am forced by regulators to connect to have > >> data that says > >> "endpoint-1" is serviced by "sip6449316977@little-box-in-the- > corner" > >> > >> > >> any thoughts? > > > > > > I think it's very interesting. > > > > A fairly large number of people in Anaheim told me that they thought > > that the DNS's "immune system" would be open to putting in a pointer > > to a general metadata-lookup service along these lines. > > > > The model they seemed to have in mind is that "The DNS" would have a > > per-phone-number (or per-phone-number-aggregation) record that would > > point to the metadata service for that phone number or aggregation- > > range. > > > > This eliminates many of the concerns: > > > > 1) We don't end up putting an additional record into the DNS for each > > piece of metadata > > > > 2) We don't have to define a selective-query or search mechanism on > > top of DNS > > > > 3) We don't have very-large RR-sets in responses due to having many > > different metadata types > > > > 4) We don't need to extend DNS to support source-specific responses > > > > 5) Authentication and authorization concerns are pushed out of the > > DNS's core and onto "the other protocol/service" > > > > The one repeatedly-heard concern that I know of that this proposal > > doesn't directly address is the "framework vs. individual use case" > > issue. However, I believe that the main reason this issue comes up is > > that adding arbitrary metadata into the DNS is considered a problem > > due to to the questions above, which Jay's #2 proposal neatly > > bypasses. So, I don't think we'd have nearly the problem with saying > > that the external metadata service returns metadata within an > > extensible schema that we have with building an extensible metadata > > schema directly in the DNS. > > > > Further, the "metadata" service that the URI points to could well have > > all the fast-lookup properties that we know and love from DNS. One > > might think of the URI as being something of a "metadata delgation". > > > > -- > > Dean > > > > > > _______________________________________________ > > e2md mailing list > > e2md@ietf.org > > https://www.ietf.org/mailman/listinfo/e2md > > > > This e-mail message is for the sole use of the intended recipient(s)and > may > > contain confidential and privileged information of Transaction Network > Services. > > Any unauthorised review, use, disclosure or distribution is prohibited. > If you > > are not the intended recipient, please contact the sender by reply e- > mail and destroy all copies of the original message. > > >=20 >=20 > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From HKaplan@acmepacket.com Mon Mar 29 18:26:10 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184393A682E for ; Mon, 29 Mar 2010 18:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE88xXLHuKDG for ; Mon, 29 Mar 2010 18:26:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 303183A6774 for ; Mon, 29 Mar 2010 18:26:09 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 29 Mar 2010 21:26:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 29 Mar 2010 21:26:37 -0400 From: Hadriel Kaplan To: Hadriel Kaplan , Jay Daley Date: Mon, 29 Mar 2010 21:26:38 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPiJd1vSGBo3dwQXerUqWvFOr+WgAGrYWgAAEpLqA= Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92993@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92982@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 01:26:10 -0000 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Monday, March 29, 2010 9:05 PM >=20 > So let's assume destination Y is 12345. I am a proxy. I get a SIP > request for destination 12345, from source 77777. I query 5.4.3.2.1.foo. > What do I get back? How do I use what I get back to determine how to > route it, given this specific case is for source 67890, which is a > different route than if I got a SIP request for the same destination but > from source 88888? Ugh, I meant "... given this specific case is for source 77777..." -hadriel From jay@nzrs.net.nz Mon Mar 29 19:16:15 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F3D3A683F for ; Mon, 29 Mar 2010 19:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.317 X-Spam-Level: * X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7QmjgOyEgLW for ; Mon, 29 Mar 2010 19:16:14 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 273C73A63EC for ; Mon, 29 Mar 2010 19:16:11 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id B9B772DBE4C; Tue, 30 Mar 2010 15:16:38 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBATTPLrF4BA; Tue, 30 Mar 2010 15:16:38 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 7679B2DBCE2; Tue, 30 Mar 2010 15:16:38 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92990@mail> Date: Tue, 30 Mar 2010 15:16:38 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <66B370E0-EAB9-438F-942D-060A46AAD2CA@nzrs.net.nz> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92990@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 02:16:15 -0000 On 30/03/2010, at 2:25 PM, Hadriel Kaplan wrote: > I think I'm understanding your concern more now. You're thinking of = it in the public DNS context (ie, The DNS). > In the private ENUM model it's the same server or database that has to = answer the routing question, so moving the problem around doesn't help. >=20 > In the public model you're right the public server has no idea how to = route the request from and through any given carrier. Yes indeed. There is an extraordinary spectrum of views that any = solution needs to address. At one end we have carriers who believe that = even making the existence of a number public is a privacy violation and = at the other end there are those who believe all the data should be = public. I'm interested in one flexible solution that can be used in = both ways. =20 The benefit of E2U + E2MD being delivered in one set of NAPTRs is that = the spectrum of views is effectively encoded in those records (in a = public tree). Those brave souls who allow public connection specify an = E2U, those that want control specify an E2MD. The originator just does = one lookup to see what options they have. > For that model I think some of us are thinking this would be where the = SPID/SPN comes in. The public servers would just return a SPID/SPN = which the originating/transit carriers would use for their internal = lookups. > There would be no source-based distinction for the public entries - = the same SPID/SPN would represent the terminating/final administrative = domain regardless of source. It needs to be an abstract identifier to deal with issues some carriers = have expressed to me of not advertising their network topology. > In that sense it *is* a form of indirection, I suppose. > But internally within the originating/transit domains they'd need = source-uri, because that SPID/SPN key still gets different results based = on the source. (and in the US the SPID/SPN wouldn't be enough for an = internal lookup key, unless each LATA gets its own SPID/SPN) I presume this is the same point as in your previous message so I'll = answer it there. > Although I could argue source-uri could still be useful in a public = context, so that for example a public ENUM of NZ numbers could say "if = the call comes from +64, use this SPID, if it comes from the anything = else use this SPID, except if it comes from +61 then don't call us". :) Or just give them blank private data! best Jay >=20 > -hadriel >=20 >> -----Original Message----- >> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of >> Jay Daley >> Sent: Monday, March 29, 2010 5:53 PM >> To: Cartwright, Kenneth >> Cc: E.164 To MetaData BOF discussion list >> Subject: Re: [e2md] Alternative to source URI >>=20 >>=20 >> On 30/03/2010, at 10:37 AM, Cartwright, Kenneth wrote: >>=20 >>> This approach is less amenable to my needs and seems un-necessarily = slow >> and complex for the use cases we have. >>=20 >> Can you explain why? >>=20 >> I think it is actually faster as per this explanation: >>=20 >> For (1) there are two additional lookups to plain DNS >>=20 >> - lookup to check the validity of the source URI >> - lookup to retrieve information specific to the source URI >>=20 >> for (2) there is only one additional lookup and that is done by the >> recipient of the data not you >>=20 >> - lookup to find private data keyed to public data >>=20 >> It also seems far less complex >>=20 >> - the information given out in DNS is always the same >> - there is no issue with spoofing of the source/validation of the = source >>=20 >> cheers >> Jay >>=20 >>=20 >>> However, there is of course nothing that says that a given E2U/E2M >> service cannot re-direct to another URL if that is appropriate for = that >> service. >>>=20 >>> Ken >>>=20 >>> -----Original Message----- >>> From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of >> Dean Willis >>> Sent: Monday, March 29, 2010 5:34 PM >>> To: Jay Daley >>> Cc: E.164 To MetaData BOF discussion list >>> Subject: Re: [e2md] Alternative to source URI >>>=20 >>>=20 >>> On Mar 29, 2010, at 4:14 PM, Jay Daley wrote: >>>>=20 >>>> The alternative (2) is simple indirection combined with private = data. >>>>=20 >>>> ... >>>>=20 >>>> and (2) goes >>>> - send private data beforehand to different parties >>>> - when anyone asks for data give the same public data >>>> - each recipient then use the public data as a key into their >>>> private data. Each recipient with different private data will get = a >>>> different answer. >>>>=20 >>>> (2) does not require any change to DNS, eliminates all issues of >>>> privacy, deals with caching and wildcards and just works. >>>>=20 >>>> A more concrete example: >>>>=20 >>>> - under 7.7.6.9.1.3.9.4.4.6.whatever is published >>>> NAPTR "e2md" "meta-endpoint:endpoint-1" >>>>=20 >>>> - my best buddy carrier has private data that says >>>> "endpoint-1" is serviced by "sip:6449316977@somewhere-special" >>>>=20 >>>> - all other carriers I am forced by regulators to connect to have >>>> data that says >>>> "endpoint-1" is serviced by "sip6449316977@little-box-in-the- >> corner" >>>>=20 >>>>=20 >>>> any thoughts? >>>=20 >>>=20 >>> I think it's very interesting. >>>=20 >>> A fairly large number of people in Anaheim told me that they thought >>> that the DNS's "immune system" would be open to putting in a pointer >>> to a general metadata-lookup service along these lines. >>>=20 >>> The model they seemed to have in mind is that "The DNS" would have a >>> per-phone-number (or per-phone-number-aggregation) record that would >>> point to the metadata service for that phone number or aggregation- >>> range. >>>=20 >>> This eliminates many of the concerns: >>>=20 >>> 1) We don't end up putting an additional record into the DNS for = each >>> piece of metadata >>>=20 >>> 2) We don't have to define a selective-query or search mechanism on >>> top of DNS >>>=20 >>> 3) We don't have very-large RR-sets in responses due to having many >>> different metadata types >>>=20 >>> 4) We don't need to extend DNS to support source-specific responses >>>=20 >>> 5) Authentication and authorization concerns are pushed out of the >>> DNS's core and onto "the other protocol/service" >>>=20 >>> The one repeatedly-heard concern that I know of that this proposal >>> doesn't directly address is the "framework vs. individual use case" >>> issue. However, I believe that the main reason this issue comes up = is >>> that adding arbitrary metadata into the DNS is considered a problem >>> due to to the questions above, which Jay's #2 proposal neatly >>> bypasses. So, I don't think we'd have nearly the problem with saying >>> that the external metadata service returns metadata within an >>> extensible schema that we have with building an extensible metadata >>> schema directly in the DNS. >>>=20 >>> Further, the "metadata" service that the URI points to could well = have >>> all the fast-lookup properties that we know and love from DNS. One >>> might think of the URI as being something of a "metadata delgation". >>>=20 >>> -- >>> Dean >>>=20 >>>=20 >>> _______________________________________________ >>> e2md mailing list >>> e2md@ietf.org >>> https://www.ietf.org/mailman/listinfo/e2md >>>=20 >>> This e-mail message is for the sole use of the intended = recipient(s)and >> may >>> contain confidential and privileged information of Transaction = Network >> Services. >>> Any unauthorised review, use, disclosure or distribution is = prohibited. >> If you >>> are not the intended recipient, please contact the sender by reply = e- >> mail and destroy all copies of the original message. >>>=20 >>=20 >>=20 >> -- >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >>=20 >> _______________________________________________ >> e2md mailing list >> e2md@ietf.org >> https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From jay@nzrs.net.nz Mon Mar 29 19:23:13 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6DCC3A63EC for ; Mon, 29 Mar 2010 19:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 729rmGt22pkv for ; Mon, 29 Mar 2010 19:23:12 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 5B3523A682E for ; Mon, 29 Mar 2010 19:23:08 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id AA32F2DA36A; Tue, 30 Mar 2010 15:23:36 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKeM3A32VnC9; Tue, 30 Mar 2010 15:23:36 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 6AB772DA152; Tue, 30 Mar 2010 15:23:36 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92982@mail> Date: Tue, 30 Mar 2010 15:23:36 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 02:23:14 -0000 On 30/03/2010, at 2:05 PM, Hadriel Kaplan wrote: > So let's assume destination Y is 12345. I am a proxy. I get a SIP = request for destination 12345, from source 77777. I query = 5.4.3.2.1.foo. > What do I get back? How do I use what I get back to determine how to = route it, given this specific case is for source 67890, which is a = different route than if I got a SIP request for the same destination but = from source 88888? Assuming the proxy is "allowed" to know this then they either have two = sets of private data, one for the source carrier that services 67890 and = one for the source carrier that services 88888. Or if the originating = carrier is the same then just one set of private data that identifies = the source within it: meta-endpoint -> source -> actual-endpoint The latter will have to exist anyway since it allows the private data to = encode transit arrangements (e.g. I'll accept your calls destined for = city B that originate in city A at my interconnect in city A because = we've agreed you will do the same.) cheers Jay >=20 > -hadriel >=20 > ________________________________________ > From: Jay Daley [mailto:jay@nzrs.net.nz]=20 > Sent: Monday, March 29, 2010 5:41 PM > To: Hadriel Kaplan > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Alternative to source URI >=20 > Sorry Hadriel I don't get what you are saying. >=20 > On 30/03/2010, at 10:29 AM, Hadriel Kaplan wrote: >=20 >=20 > Unfortunately it's not who asked the DNS query. (otherwise we could = just use IP-Address based views) > It's who originated the application request, which triggered the DNS = query (possibly by a third party). >=20 > For example, in a private carrier model where proxies generate the = ENUM-DNS query when they get SIP requests, it's the SIP URI of the = originator of the SIP request. >=20 > It is the originators who have the "private" data, not the proxies. >=20 >=20 > The primary use-case of it is in the SIP or H.323 routing use-case = with ENUM, where the source of the call affects how the call gets = routed. (for a bunch of reasons) >=20 > Which is specifically what I intended it for.=20 >=20 >=20 > So (2) wouldn't work because the same DNS client needs to use = different result data for the same query key, based on where the SIP = request came from. >=20 > I don't see what the DNS client has to do with it - it just passes on = the data to higher up the stack where the keying into the private data = takes place. >=20 > If you could help me understand then I would appreciate it. >=20 > thanks > Jay >=20 >=20 > -hadriel >=20 >=20 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of > Jay Daley > Sent: Monday, March 29, 2010 5:15 PM > To: E.164 To MetaData BOF discussion list > Subject: [e2md] Alternative to source URI >=20 > Correct me if this is wrong but the basic premise of the source-URI > proposal is for each recipient to get a different answer, depending on > they are. One way (1) of achieving this is to give a different = response > depending on who asks, but it is not the only way. >=20 > The alternative (2) is simple indirection combined with private data. >=20 > So (1) goes > - determine who has asked > - find appropriate data > - send it to them >=20 > and (2) goes > - send private data beforehand to different parties > - when anyone asks for data give the same public data > - each recipient then use the public data as a key into their private = data. > Each recipient with different private data will get a different = answer. >=20 > (2) does not require any change to DNS, eliminates all issues of = privacy, > deals with caching and wildcards and just works. >=20 > A more concrete example: >=20 > - under 7.7.6.9.1.3.9.4.4.6.whatever is published > NAPTR "e2md" "meta-endpoint:endpoint-1" >=20 > - my best buddy carrier has private data that says > "endpoint-1" is serviced by "sip:6449316977@somewhere-special" >=20 > - all other carriers I am forced by regulators to connect to have data > that says > "endpoint-1" is serviced by = "sip6449316977@little-box-in-the-corner" >=20 >=20 > any thoughts? > Jay >=20 > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From Ray.Bellis@nominet.org.uk Tue Mar 30 00:18:18 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF803A681B for ; Tue, 30 Mar 2010 00:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-oOXTA4nPEk for ; Tue, 30 Mar 2010 00:18:15 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id CDE603A6ACD for ; Tue, 30 Mar 2010 00:18:13 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=ZFBmDg56zX1i67BIQCl+v4C0o0PNlUMmGsW3Q87haZqHcZUrzEN23cIE yPKnOeHxBIJwjxYVRceZip2h41vzydz1vjmOFASsY2QwzP1g9lqqXboch g/K3xfqg4dylDFR; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269933523; x=1301469523; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20alt=20structure=20suggested=20for=20CNAM|Date:=20Tue, =2030=20Mar=202010=2008:18:40=20+0100|Message-ID:=20|To:=20Dean=20Willis=20|Cc:=20list=20|MIME-Version:=201.0 |In-Reply-To:=20<699EC41F-C093-4D87-851C-4B21167EA1AE@sof tarmor.com>|References:=20<4BAA4248.2050601@softarmor.com >=09<02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, =0D=0A=09<4BAA739B.2000609@softarmor.com>=09<754963199212 404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tns i.com>=0D=0A=09<4BAA88CE.3030904@softarmor.com>=09<430FC6 BDED356B4C8498F634416644A91A79CD1EC2@mail>=0D=0A=09<75496 3199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.c orp.tnsi.com>=0D=0A=09<4BACDFEF.20307@softarmor.com>=09<7 54963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win 2k.corp.tnsi.com>=0D=0A=09<4BB0CB8D.4050302@cisco.com>=09 <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.w in2k.corp.tnsi.com>=0D=0A=09<4BB0D237.7050700@cisco.com> =09<754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-N A.win2k.corp.tnsi.com>=20<699EC41F-C093-4D87-851C-4B21167 EA1AE@softarmor.com>; bh=bGC/U4B4cU32qrE4hmvLnXOKW/MR+X7HO8Vgqyx8Xaw=; b=cAnB44r3iyDtZIfMFD+Ss53Jhhkje24pb/cOEoUKO9DcwV04a03U74E0 13MK9XYoQ4aEFTHqyQrQ65dkUTI4nHw/uO7+i34gjCP6f3JaC1xHaMk9c 6mmIPC/b2ndNNxX; X-IronPort-AV: E=Sophos;i="4.51,333,1267401600"; d="scan'208";a="17467026" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 30 Mar 2010 08:18:41 +0100 In-Reply-To: <699EC41F-C093-4D87-851C-4B21167EA1AE@softarmor.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0D237.7050700@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> <699EC41F-C093-4D87-851C-4B21167EA1AE@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 30 Mar 2010 08:18:40 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 30/03/2010 08:18:40 AM, Serialize complete at 30/03/2010 08:18:40 AM Content-Type: multipart/alternative; boundary="=_alternative 002829C6802576F6_=" Cc: list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 07:18:18 -0000 This is a multipart message in MIME format. --=_alternative 002829C6802576F6_= Content-Type: text/plain; charset="US-ASCII" > But we are asking the DNS directorate to authorize the making of such > changes. No, we are NOT - that is FUD. Notwithstanding that at least one of the DNS directorate is one of those that would like NAPTR to go away, the _current_ E2MD documentation is suggesting NO changes to DNS protocols and is therefore generally out of scope for them (IMHO). I can double check that, though, seeing as I work in the same office as two of them. Ray --=_alternative 002829C6802576F6_= Content-Type: text/html; charset="US-ASCII"
> But we are asking the DNS directorate to authorize the making of such  
> changes.

No, we are NOT - that is FUD.

Notwithstanding that at least one of the DNS directorate is one of those that would like NAPTR to go away, the _current_ E2MD documentation is suggesting NO changes to DNS protocols and is therefore generally out of scope for them (IMHO).

I can double check that, though, seeing as I work in the same office as two of them.

Ray
--=_alternative 002829C6802576F6_=-- From Ray.Bellis@nominet.org.uk Tue Mar 30 00:53:14 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3491F3A67AF for ; Tue, 30 Mar 2010 00:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.22 X-Spam-Level: X-Spam-Status: No, score=-5.22 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXT06BwlGfQI for ; Tue, 30 Mar 2010 00:53:13 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id EC17E3A67A7 for ; Tue, 30 Mar 2010 00:53:12 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=QLJXJdR8j7Awhg3TvuM314S4tVCkWASBi0QM4fHXMNz7yifLLAa8Qmj8 YYqydhxw/dPQEoTM8PRk61PdbLQeyknpkkrbJpIszoCTo65zHWsnSO9wV 08jhaSEEnqH4M3/; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269935622; x=1301471622; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Revised=20draft=20minutes=20of=20E2MD=20BOF=20at=20IE TF=2077|Date:=20Tue,=2030=20Mar=202010=2008:53:39=20+0100 |Message-ID:=20|To:=20Dean=20Willis=20|Cc:=20"E.164=20To=20MetaData=20 BOF=20discussion=20list"=20|MIME-Version: =201.0|In-Reply-To:=20|References:=20; bh=nbzAJA26kQlqRYfJy8FGjRydYIR4xm4wMIdPofIuztE=; b=GmxLDi/M3KZ15iy4jCUO9L26KThaRLQPnDbElnJBSYPkbD8Asi0SFUIK hDFn11hSuNol34f4d4rjnttiPBHPmHGzwEMmeCfvlqvHImffXCag0GijE TYF4YyT8Ya+nWQA; X-IronPort-AV: E=Sophos;i="4.51,333,1267401600"; d="scan'208";a="17467430" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 30 Mar 2010 08:53:40 +0100 In-Reply-To: References: To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 30 Mar 2010 08:53:39 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 30/03/2010 08:53:40 AM, Serialize complete at 30/03/2010 08:53:40 AM Content-Type: multipart/alternative; boundary="=_alternative 002B5D9C802576F6_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Revised draft minutes of E2MD BOF at IETF 77 X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 07:53:14 -0000 This is a multipart message in MIME format. --=_alternative 002B5D9C802576F6_= Content-Type: text/plain; charset="US-ASCII" > Bernie and I have made some further cleanup on the draft minutes of > the recent E2MD BOF. If you have any further feedback, please get it > back to us ASAP. I disagree with the two notes re: a vote taken on whether the charter was ready or not. >From where I was sat it looked at worst evenly split, and not biased towards the negative camp as minuted. I also don't recall any announcement of such from the chair. Ray --=_alternative 002B5D9C802576F6_= Content-Type: text/html; charset="US-ASCII"
> Bernie and I have made some further cleanup on the draft minutes of  
> the recent E2MD BOF. If you have any further feedback, please get it  
> back to us ASAP.
I disagree with the two notes re: a vote taken on whether the charter was ready or not.

From where I was sat it looked at worst evenly split, and not biased towards the negative camp as minuted.  I also don't recall any announcement of such from the chair.

Ray

--=_alternative 002B5D9C802576F6_=-- From olaf@nlnetlabs.nl Tue Mar 30 01:01:53 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51CA73A6942 for ; Tue, 30 Mar 2010 01:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.3 X-Spam-Level: X-Spam-Status: No, score=-100.3 tagged_above=-999 required=5 tests=[AWL=1.170, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9YzCQskNqXL for ; Tue, 30 Mar 2010 01:01:52 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id 1B1353A698A for ; Tue, 30 Mar 2010 01:01:46 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7] ([IPv6:2001:7b8:206:1:226:bbff:fe0e:7cc7]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o2U81jBQ076406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Mar 2010 10:01:46 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Olaf Kolkman In-Reply-To: Date: Tue, 30 Mar 2010 10:01:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dean Willis X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 30 Mar 2010 10:01:46 +0200 (CEST) X-Mailman-Approved-At: Tue, 30 Mar 2010 01:05:47 -0700 Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , John C Klensin , "E.164 To MetaData BOF discussion list" , pk@ISOC.DE Subject: Re: [e2md] Revised draft minutes of E2MD BOF at IETF 77 X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:01:53 -0000 On Mar 29, 2010, at 10:01 PM, Dean Willis wrote: > Olaf Kolkman agreed that the ENUM tree matches well with hierarchy, > but wondered what form of query/search systems might be needed. For > example, if we need to search for metadata with a specific number, it > might be better to have a service just for that. He suggested that it > might be good idea to look for different tools for this problems. 'agreed (..) matches well' may a bit to strong, there are some problems = e.g. with +1 and the unknown delegation points in certain number plans. = But 'agreed (...) matches well' is what I said, so no need to change the = minutes.=20 --Olaf ________________________________________________________=20 Olaf M. Kolkman NLnet Labs Science Park 140,=20 http://www.nlnetlabs.nl/ 1098 XG Amsterdam From bernie@ietf.hoeneisen.ch Tue Mar 30 01:14:15 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E734E3A6857 for ; Tue, 30 Mar 2010 01:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.751 X-Spam-Level: * X-Spam-Status: No, score=1.751 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM9uo5kt9WmE for ; Tue, 30 Mar 2010 01:14:13 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 21E303A67FD for ; Tue, 30 Mar 2010 01:14:12 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NwWat-0003r9-KW for e2md@ietf.org; Tue, 30 Mar 2010 10:14:39 +0200 Date: Tue, 30 Mar 2010 10:14:39 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] Divide and conquer! X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:14:15 -0000 Hi, Reading through all the emails I believe the best way to address the problem space is the following approach: Divide and conquer! By that I mean to divide the problem space into a short term and a long term solution and conquer the both separately. - Short term solution: Approach the easy use cases along the lines of http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 (What the _easy_ use cases are, is yet to be determined.) I guess we'll have to ditch the framework approach (at least for the time being) and rather concentrate on the E2M DDDS application and the easy use cases. I could imagine to re-charter the ENUM WG for this. At least Dave Crocker indicated to me that an approach that simply enhances ENUM with additional records is more likely to get the required support, as opposed to define a new protocol decoupled from ENUM. Exact strategy for short term solution is yet to be worked out. - Long term solution: The long term solution goes through the normal IETF process and starts with the collection and documentation of requirements and use cases. The goal could be a general mapping mechanism to map phone numbers to other addresses (forth and back) including source dependent queries and other stuff that has been proposed. Note: The solution does not necessarily be in DNS. Once we have the requirements in written, we'll prioritize them and formulate a charter proposal. If we get the requirements ready in time for Maastricht, we'll propose a BoF, which needs to happen latest by May 2010, according to: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 What is your general feeling about this "divide and conquer" approach? If we go this way, we need a volunteer to make a proper requirements document for the long term solution. cheers, Bernie From bernie@ietf.hoeneisen.ch Tue Mar 30 01:30:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F833A687E for ; Tue, 30 Mar 2010 01:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.504 X-Spam-Level: X-Spam-Status: No, score=0.504 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKZRnUKV6pK1 for ; Tue, 30 Mar 2010 01:30:11 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 3D52B3A6870 for ; Tue, 30 Mar 2010 01:30:10 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1NwWqM-0003si-56 for e2md@ietf.org; Tue, 30 Mar 2010 10:30:38 +0200 Date: Tue, 30 Mar 2010 10:30:38 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "E.164 To MetaData BOF discussion list" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Subject: [e2md] HAMMER as proposed name for long term solution: (was: Divide and conquer!) X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:30:12 -0000 Oh yeah, and let's simply name the long term solution: HAMMER --> H... Address Mapping for Multimedia Enabling R... Any smart(er) ideas for the missing H and R (and other letters)? :-) Have fun! cheers, Bernie On Tue, 30 Mar 2010, Bernie Hoeneisen wrote: > Hi, > > Reading through all the emails I believe the best way to address the > problem space is the following approach: > > Divide and conquer! > > By that I mean to divide the problem space into a short term and a > long term solution and conquer the both separately. > > > - Short term solution: > > Approach the easy use cases along the lines of > http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 > (What the _easy_ use cases are, is yet to be determined.) > > I guess we'll have to ditch the framework approach (at least for the > time being) and rather concentrate on the E2M DDDS application and the > easy use cases. > > I could imagine to re-charter the ENUM WG for this. At least Dave > Crocker indicated to me that an approach that simply enhances ENUM > with additional records is more likely to get the required support, > as opposed to define a new protocol decoupled from ENUM. > > Exact strategy for short term solution is yet to be worked out. > > > - Long term solution: > > The long term solution goes through the normal IETF process and > starts with the collection and documentation of requirements and use > cases. > > The goal could be a general mapping mechanism to map phone numbers > to other addresses (forth and back) including source dependent > queries and other stuff that has been proposed. > > Note: The solution does not necessarily be in DNS. > > Once we have the requirements in written, we'll prioritize them and > formulate a charter proposal. If we get the requirements ready in > time for Maastricht, we'll propose a BoF, which needs to happen > latest by May 2010, according to: > http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 > > > What is your general feeling about this "divide and conquer" approach? > > If we go this way, we need a volunteer to make a proper requirements > document for the long term solution. > > cheers, > Bernie > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > From Ray.Bellis@nominet.org.uk Tue Mar 30 01:35:51 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CA93A6937 for ; Tue, 30 Mar 2010 01:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.234 X-Spam-Level: X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+yu6z-jXclM for ; Tue, 30 Mar 2010 01:35:49 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id C89EB3A68DC for ; Tue, 30 Mar 2010 01:35:43 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=q1QRFUZi4on6zhyz1udqb4/kdLIH0blNB3mlzd7Zo0qa2ZKieDYPTF6J nIfwCs24uXqz3XfqpSCiGKxMM34rHl0GHgy+bR/o06Pj64UllaooTt9Yb /39C7qdnBHsEsUR; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269938173; x=1301474173; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20E2MD,=20ENUM,=20and=20the=20DNS:=20why=20our=20approa ch=20is=20stalling|Date:=20Tue,=2030=20Mar=202010=2009:36 :11=20+0100|Message-ID:=20|To:=20Hadriel =20Kaplan=20|Cc:=20|MIME-Version:=201.0|In-Reply-To:=20<430FC6BDED356B4C849 8F634416644A91A79E92948@mail>|References:=20<4BAA4248.205 0601@softarmor.com>,=09<4BAA739B.2000609@softarmor.com> =09<754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-N A.win2k.corp.tnsi.com>=0D=0A=09<4BAA88CE.3030904@softarmo r.com>=09<430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail >=0D=0A=09<754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS -MAIL-NA.win2k.corp.tnsi.com>=0D=0A=09<4BACDFEF.20307@sof tarmor.com>=09<754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5 @TNS-MAIL-NA.win2k.corp.tnsi.com>=0D=0A=09<4BAD2039.30305 02@softarmor.com>=09<9AA6E358-4BEE-4A64-BA33-A94840AAEFB2 @standardstrack.com>=0D=0A=09=09<4BB04669.3070500@softarmor. com>=0D=0A=09<1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.n et.nz>=09<430FC6BDED356B4C8498F634416644A91A79E928FB@mail >=0D=0A=09<01b101cacf7c$540357c0$fc0a0740$@us>=09<7549631 99212404AB=20<430FC6BDED356B4C8498F634416644A91A79E92948@ mail>; bh=AWofWJ1UY4WN+6g4GjeXChO8v/eM7vsSuCq5tulOz8g=; b=Q8M+CHZJOw7mOObtxn6atFYj9gouvyuyjUl9Yy7UZMw0VphqFzIO3WAO wuPTqK2w9/5ffyo2gqvtXUINws4wNkkmkOupYs/LOAC+zxOzdQu/QCFLB E2Ev+iwdBdb7evq; X-IronPort-AV: E=Sophos;i="4.51,333,1267401600"; d="scan'208";a="17468020" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 30 Mar 2010 09:36:11 +0100 In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92948@mail> References: <4BAA4248.2050601@softarmor.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB <430FC6BDED356B4C8498F634416644A91A79E92948@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 30 Mar 2010 09:36:11 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 30/03/2010 09:36:11 AM, Serialize complete at 30/03/2010 09:36:11 AM Content-Type: multipart/alternative; boundary="=_alternative 002F4225802576F6_=" Cc: e2md@ietf.org Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:35:51 -0000 This is a multipart message in MIME format. --=_alternative 002F4225802576F6_= Content-Type: text/plain; charset="US-ASCII" > The results are not cached - the TTL is zero. More strictly, that probably means they're not cached by _your_ implementation? Unfortunately it's not unheard of for other implementations to ignore TTLs of zero and assume some other lower bound. Ray --=_alternative 002F4225802576F6_= Content-Type: text/html; charset="US-ASCII"
> The results are not cached - the TTL is zero.
More strictly, that probably means they're not cached by _your_ implementation?

Unfortunately it's not unheard of for other implementations to ignore TTLs of zero and assume some other lower bound.

Ray
--=_alternative 002F4225802576F6_=-- From jay@nzrs.net.nz Tue Mar 30 01:39:07 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55D63A69BD for ; Tue, 30 Mar 2010 01:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR6yi4mbSsJD for ; Tue, 30 Mar 2010 01:39:07 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 62EB33A69B7 for ; Tue, 30 Mar 2010 01:39:04 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id E0B562DBCAB; Tue, 30 Mar 2010 21:39:31 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lzBBtwUB0Q0; Tue, 30 Mar 2010 21:39:31 +1300 (NZDT) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 3D5BD2DA695; Tue, 30 Mar 2010 21:39:30 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Tue, 30 Mar 2010 21:39:28 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <8045A487-37F3-47C7-A508-657A69393D37@nzrs.net.nz> References: To: Bernie Hoeneisen X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Divide and conquer! X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:39:08 -0000 On 30/03/2010, at 9:14 PM, Bernie Hoeneisen wrote: > What is your general feeling about this "divide and conquer" approach? There are still two important issues that this does not resolve: 1. It appears this initiative has become a venue for a proxy war = against NAPTR and ENUM in general. If we don't resolve that then we = don't get anywhere. 2. We have no clear way of deciding what is easy and what is not. I = suspect your attempt to separate out "things that require a change to = the protocol" into the not easy pile will not work - the discussion over = the last day has already gone against that. > If we go this way, we need a volunteer to make a proper requirements > document for the long term solution. I think that is premature. We are better off determining what the = requirements are for easy and then seeing if the necessary features can = be delivered in a compliant way. For example my alternative to = source-uri is an 'easy' way of doing the same thing. cheers JAy >=20 > cheers, > Bernie >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From dean.willis@softarmor.com Tue Mar 30 01:46:25 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FC63A6878 for ; Tue, 30 Mar 2010 01:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.839 X-Spam-Level: X-Spam-Status: No, score=0.839 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG4qXsiWBsNN for ; Tue, 30 Mar 2010 01:46:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5A1C43A692F for ; Tue, 30 Mar 2010 01:46:23 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2U8kjAa012663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Mar 2010 03:46:48 -0500 Message-Id: From: Dean Willis To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 03:46:39 -0500 References: X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Revised draft minutes of E2MD BOF at IETF 77 X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:46:25 -0000 On Mar 30, 2010, at 2:53 AM, Ray.Bellis@nominet.org.uk wrote: > > > Bernie and I have made some further cleanup on the draft minutes of > > the recent E2MD BOF. If you have any further feedback, please get it > > back to us ASAP. > > I disagree with the two notes re: a vote taken on whether the > charter was ready or not. > > From where I was sat it looked at worst evenly split, and not biased > towards the negative camp as minuted. I also don't recall any > announcement of such from the chair. From John Elwell's notes: John Klensin: Should ask who thinks proposed charter it not ready to go. Dean: Asked that question. More thought it was not ready to go than thought it was ready to go However, we could and probably should note that a large proportion of people though the problem was worth working on and could be reasonably attacked in the IETF. -- Dean From dean.willis@softarmor.com Tue Mar 30 01:54:09 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD843A68AC for ; Tue, 30 Mar 2010 01:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPvJBs6hUT4I for ; Tue, 30 Mar 2010 01:54:08 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C8AE63A6817 for ; Tue, 30 Mar 2010 01:54:08 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2U8sZF6012749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Mar 2010 03:54:37 -0500 Message-Id: <3800DAD7-289F-49B3-AE2F-6A662DA028CE@softarmor.com> From: Dean Willis To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 03:54:28 -0500 References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA3@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0CB8D.4050302@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529BDB@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB0D237.7050700@cisco.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529D0F@TNS-MAIL-NA.win2k.corp.tnsi.com> <699EC41F-C093-4D87-851C-4B21167EA1AE@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: list Subject: Re: [e2md] alt structure suggested for CNAM X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:54:09 -0000 On Mar 30, 2010, at 2:18 AM, Ray.Bellis@nominet.org.uk wrote: > > > But we are asking the DNS directorate to authorize the making of > such > > changes. > > No, we are NOT - that is FUD. > We asked them to authorize a working group that would be defining a new DDDS service for metadata discovery, including extension of the NAPTR record format (for a "T" record), and an at-will (spec required) extension mechanism for subtypes, with effective carte-blanche for determining an initial set of subtypes with in the WG and an ongoing low-review-threshold mechanism for new subtypes. I believe that qualifies as making changes to the format of data allowed in the DNS, and even though YOU don't plan to put any data into "The DNS", I suspect that the DNS directorate folks believe that somehow, somewhere, people are going to use our extensions to populate "their DNS", and will probably do so in a way they find unpleasant. > Notwithstanding that at least one of the DNS directorate is one of > those that would like NAPTR to go away, the _current_ E2MD > documentation is suggesting NO changes to DNS protocols and is > therefore generally out of scope for them (IMHO). > > I can double check that, though, seeing as I work in the same office > as two of them. Please do! -- Dean From Ray.Bellis@nominet.org.uk Tue Mar 30 01:56:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3E63A687F for ; Tue, 30 Mar 2010 01:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.246 X-Spam-Level: X-Spam-Status: No, score=-5.246 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjt4Gb6aH+6h for ; Tue, 30 Mar 2010 01:56:28 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id D11B43A68AC for ; Tue, 30 Mar 2010 01:56:26 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=RrG4Zrb7lQUH4eeH3p2MaZoEBD4C0nME97V9PkMrZfTsD/NsIGcYoskM khWzf49TCRnUgSdS+B5wRvFoPQbnQSU0XuOakMSmt6vvXaUOUqDL5WTFk E0E0jBvcPXD4zaO; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269939416; x=1301475416; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Alternative=20to=20source=20URI|Date:=20Tue,=2030=20M ar=202010=2009:56:54=20+0100|Message-ID:=20|To:=20Dean=20Willis=20|Cc: =20"E.164=20To=20MetaData=20BOF=20discussion=20list"=20|MIME-Version:=201.0|In-Reply-To:=20<6ED52AC B-A78C-454A-AC73-7E24591A4EFD@softarmor.com>|References: =20=20< 6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com>; bh=oitANv8Y4IdsO2I3bdPVl9+EC+B4VPoDu9wF6Rfavao=; b=uj8GGxxIcFDcu5c8yJ5XjdFSHePWiEZTcjjNFKJKyKLqUJpiuJxBR9Uv RX1FGU/W5X6LLi/0nXAmYCuEwEB+BlCggfXyDGd+17b4hdK0uoOOQDG3k TXA/e3xHV6s0avr; X-IronPort-AV: E=Sophos;i="4.51,333,1267401600"; d="scan'208";a="17468413" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 30 Mar 2010 09:56:54 +0100 In-Reply-To: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 30 Mar 2010 09:56:54 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 30/03/2010 09:56:54 AM, Serialize complete at 30/03/2010 09:56:54 AM Content-Type: multipart/alternative; boundary="=_alternative 003127A1802576F6_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:56:29 -0000 This is a multipart message in MIME format. --=_alternative 003127A1802576F6_= Content-Type: text/plain; charset="US-ASCII" > I think it's very interesting. > > A fairly large number of people in Anaheim told me that they thought > that the DNS's "immune system" would be open to putting in a pointer > to a general metadata-lookup service along these lines. > > The model they seemed to have in mind is that "The DNS" would have a > per-phone-number (or per-phone-number-aggregation) record that would > point to the metadata service for that phone number or aggregation- > range. I believe that that's conflating too many of the existing and potential use cases. It still makes absolute sense (IMHO) to have "unused/void" and "send-n" exist as real (meta-)data in the ENUM tree, as their entire intent is to be returned instead of "normal" NAPTR results to optimise dialling and calling. > This eliminates many of the concerns: > > 1) We don't end up putting an additional record into the DNS for each > piece of metadata > > 2) We don't have to define a selective-query or search mechanism on > top of DNS > > 3) We don't have very-large RR-sets in responses due to having many > different metadata types > > 4) We don't need to extend DNS to support source-specific responses > > 5) Authentication and authorization concerns are pushed out of the > DNS's core and onto "the other protocol/service" > > ... If you (re-)read the message I sent to you and Dispatch on 8th March you'll see that this is very similar to Jay's proposal. This is unsurprising as we jointly worked on a similar proposed specification for the UK's number portability database before Jay headed to the Antipodes. This proposed solution is equivalent to the SPEERMINT "LUF", with the second stage lookup equivalent to the "LRF". However unlike SPEERMINT this version has the desirable (IMHO) property that it's source invariant, as you mention in 4) above. Ray --=_alternative 003127A1802576F6_= Content-Type: text/html; charset="US-ASCII"
> I think it's very interesting.
>
> A fairly large number of people in Anaheim told me that they thought  
> that the DNS's "immune system" would be open to putting in a pointer  
> to a general metadata-lookup service along these lines.
>
> The model they seemed to have in mind is that "The DNS" would have a  
> per-phone-number (or per-phone-number-aggregation) record that would  
> point to the metadata service for that phone number or aggregation-
> range.

I believe that that's conflating too many of the existing and potential use cases.

It still makes absolute sense (IMHO) to have "unused/void" and "send-n" exist as real (meta-)data in the ENUM tree, as their entire intent is to be returned instead of "normal" NAPTR results to optimise dialling and calling.
> This eliminates many of the concerns:
>
> 1) We don't end up putting an additional record into the DNS for each  
> piece of metadata
>
> 2) We don't have to define a selective-query or search mechanism on  
> top of DNS
>
> 3) We don't have very-large RR-sets in responses due to having many  
> different metadata types
>
> 4) We don't need to extend DNS to support source-specific responses
>
> 5) Authentication and authorization concerns are pushed out of the  
> DNS's core and onto "the other protocol/service"
>
> ...

If you (re-)read the message I sent to you and Dispatch on 8th March you'll see that this is very similar to Jay's proposal.  This is unsurprising as we jointly worked on a similar proposed specification for the UK's number portability database before Jay headed to the Antipodes.  This proposed solution is equivalent to the SPEERMINT "LUF", with the second stage lookup equivalent to the "LRF".  However unlike SPEERMINT this version has the desirable (IMHO) property that it's source invariant, as you mention in 4) above.

Ray

--=_alternative 003127A1802576F6_=-- From dean.willis@softarmor.com Tue Mar 30 01:58:53 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3475F3A69BE for ; Tue, 30 Mar 2010 01:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h03ltZIEs5GY for ; Tue, 30 Mar 2010 01:58:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2B2E13A6974 for ; Tue, 30 Mar 2010 01:58:52 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2U8x7kn012804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Mar 2010 03:59:09 -0500 Message-Id: <5CFEA0A5-A8E6-494B-9B33-C4EF998F811D@softarmor.com> From: Dean Willis To: Jay Daley In-Reply-To: <8045A487-37F3-47C7-A508-657A69393D37@nzrs.net.nz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 03:59:02 -0500 References: <8045A487-37F3-47C7-A508-657A69393D37@nzrs.net.nz> X-Mailer: Apple Mail (2.936) Cc: Bernie Hoeneisen , "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Divide and conquer! X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:58:53 -0000 On Mar 30, 2010, at 3:39 AM, Jay Daley wrote: >> > > I think that is premature. We are better off determining what the > requirements are for easy and then seeing if the necessary features > can be delivered in a compliant way. For example my alternative to > source-uri is an 'easy' way of doing the same thing. I'd like to work through Jay's proposal in a little more depth. It may well provide the basis of an "easy" approach that also leads us to solving the whole problem space in a way that makes E2MD both efficient and palatable to the DNS directorate folks (which would be very, very cool). Or it might not, but working through it will at least get us a better understanding of the potential solution space. -- Dean From dean.willis@softarmor.com Tue Mar 30 02:03:07 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5193A69C3 for ; Tue, 30 Mar 2010 02:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkfHHJngfsLY for ; Tue, 30 Mar 2010 02:03:06 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6EE593A687F for ; Tue, 30 Mar 2010 02:02:58 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2U93Pdu012863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Mar 2010 04:03:26 -0500 Message-Id: <366C986D-A35C-490E-B0D7-870CC179938D@softarmor.com> From: Dean Willis To: Ray.Bellis@nominet.org.uk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 04:03:19 -0500 References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 09:03:07 -0000 On Mar 30, 2010, at 3:56 AM, Ray.Bellis@nominet.org.uk wrote: > > > I think it's very interesting. > > > > A fairly large number of people in Anaheim told me that they thought > > that the DNS's "immune system" would be open to putting in a pointer > > to a general metadata-lookup service along these lines. > > > > The model they seemed to have in mind is that "The DNS" would have a > > per-phone-number (or per-phone-number-aggregation) record that would > > point to the metadata service for that phone number or aggregation- > > range. > > I believe that that's conflating too many of the existing and > potential use cases. > I think it covers the cases "about the number", but probably not the "send-n" case, which is more "about the tree". I'm on the fence as to which approach to take with "unused". > It still makes absolute sense (IMHO) to have "unused/void" and "send- > n" exist as real (meta-)data in the ENUM tree, as their entire > intent is to be returned instead of "normal" NAPTR results to > optimise dialling and calling. I agree, at least for send-n. > > If you (re-)read the message I sent to you and Dispatch on 8th March > you'll see that this is very similar to Jay's proposal. This is > unsurprising as we jointly worked on a similar proposed > specification for the UK's number portability database before Jay > headed to the Antipodes. This proposed solution is equivalent to > the SPEERMINT "LUF", with the second stage lookup equivalent to the > "LRF". However unlike SPEERMINT this version has the desirable > (IMHO) property that it's source invariant, as you mention in 4) > above. > You're talking about the I-D on destgroups? -- Dean From jay@nzrs.net.nz Tue Mar 30 02:23:11 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B743A67B4 for ; Tue, 30 Mar 2010 02:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBjN8rd5D3qT for ; Tue, 30 Mar 2010 02:23:10 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id CBE273A67A3 for ; Tue, 30 Mar 2010 02:23:08 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 9DCBC2DBCD6; Tue, 30 Mar 2010 22:23:37 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4u008FWTm32; Tue, 30 Mar 2010 22:23:37 +1300 (NZDT) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 022112DBCAB; Tue, 30 Mar 2010 22:23:36 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: Date: Tue, 30 Mar 2010 22:23:35 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> To: Ray.Bellis@nominet.org.uk X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 09:23:12 -0000 On 30/03/2010, at 9:56 PM, Ray.Bellis@nominet.org.uk wrote: >=20 > > I think it's very interesting. > >=20 > > A fairly large number of people in Anaheim told me that they thought = =20 > > that the DNS's "immune system" would be open to putting in a pointer = =20 > > to a general metadata-lookup service along these lines. > >=20 > > The model they seemed to have in mind is that "The DNS" would have a = =20 > > per-phone-number (or per-phone-number-aggregation) record that would = =20 > > point to the metadata service for that phone number or aggregation-=20= > > range.=20 >=20 > I believe that that's conflating too many of the existing and = potential use cases.=20 >=20 > It still makes absolute sense (IMHO) to have "unused/void" and = "send-n" exist as real (meta-)data in the ENUM tree, as their entire = intent is to be returned instead of "normal" NAPTR results to optimise = dialling and calling. I have been told repeatedly by carriers that there are privacy issues = over publishing "unused/void" in a public tree because it tells other = carriers what numbers they have in service. Has this been tackled in = NICC? =20 Anyone else care to comment? cheers Jay >=20 > > This eliminates many of the concerns: > >=20 > > 1) We don't end up putting an additional record into the DNS for = each =20 > > piece of metadata > >=20 > > 2) We don't have to define a selective-query or search mechanism on =20= > > top of DNS > >=20 > > 3) We don't have very-large RR-sets in responses due to having many =20= > > different metadata types > >=20 > > 4) We don't need to extend DNS to support source-specific responses > >=20 > > 5) Authentication and authorization concerns are pushed out of the =20= > > DNS's core and onto "the other protocol/service" > >=20 > > ...=20 >=20 > If you (re-)read the message I sent to you and Dispatch on 8th March = you'll see that this is very similar to Jay's proposal. This is = unsurprising as we jointly worked on a similar proposed specification = for the UK's number portability database before Jay headed to the = Antipodes. This proposed solution is equivalent to the SPEERMINT "LUF", = with the second stage lookup equivalent to the "LRF". However unlike = SPEERMINT this version has the desirable (IMHO) property that it's = source invariant, as you mention in 4) above.=20 >=20 > Ray=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From Ray.Bellis@nominet.org.uk Tue Mar 30 02:32:26 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8934A3A6916 for ; Tue, 30 Mar 2010 02:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.257 X-Spam-Level: X-Spam-Status: No, score=-5.257 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQD-+BBhDjjf for ; Tue, 30 Mar 2010 02:32:25 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id E208C3A67A3 for ; Tue, 30 Mar 2010 02:32:22 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=4kWEcyO+8zIoXF4N0eAwPWYxmxbgnnY6NhF7PMT7K03nGSWXoTTwE8FD AnhQLhOAL5gD4NhPQrcj1eryZUHMDe2rmaeGYqZNqVuxVp73BuKx7z1gm qTMCvCPW5GP+2JH; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269941572; x=1301477572; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Alternative=20to=20source=20URI|Date:=20Tue,=2030=20M ar=202010=2010:32:50=20+0100|Message-ID:=20|To:=20Dean=20Willis=20|Cc: =20"E.164=20To=20MetaData=20BOF=20discussion=20list"=20|MIME-Version:=201.0|In-Reply-To:=20<366C986 D-A35C-490E-B0D7-870CC179938D@softarmor.com>|References: =20=20< 6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com>=20=20<366C986D-A35C-490E-B0D7-870CC179938D@so ftarmor.com>; bh=stMAzS5b4rgn021y0MOLcxPj1XJ6b1b4T6SqEfhxkOQ=; b=mSVGmzpFHv0u1EXtY9Nq4lrhsoG7f++t5G8SXDL/OioHJa4m+jbJKRot e0ucBenfnQgiMhO7f8ItwOJuFakh//UfH9W8xUyoj5JRo0z8v+C9yPA5p s4XqttZYXOuQHaf; X-IronPort-AV: E=Sophos;i="4.51,333,1267401600"; d="scan'208";a="17479752" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 30 Mar 2010 10:32:50 +0100 In-Reply-To: <366C986D-A35C-490E-B0D7-870CC179938D@softarmor.com> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <366C986D-A35C-490E-B0D7-870CC179938D@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 30 Mar 2010 10:32:50 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 30/03/2010 10:32:50 AM, Serialize complete at 30/03/2010 10:32:50 AM Content-Type: multipart/alternative; boundary="=_alternative 0034720A802576F6_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 09:32:26 -0000 This is a multipart message in MIME format. --=_alternative 0034720A802576F6_= Content-Type: text/plain; charset="US-ASCII" > You're talking about the I-D on destgroups? Yes. Ray --=_alternative 0034720A802576F6_= Content-Type: text/html; charset="US-ASCII"
> You're talking about the I-D on destgroups?
Yes.

Ray
--=_alternative 0034720A802576F6_=-- From Ray.Bellis@nominet.org.uk Tue Mar 30 02:35:35 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D023A6916 for ; Tue, 30 Mar 2010 02:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.267 X-Spam-Level: X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL5R-zSAmQ7A for ; Tue, 30 Mar 2010 02:35:34 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 49F903A67B4 for ; Tue, 30 Mar 2010 02:35:32 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=smXodxq6tAKo9lQfRuaW7un6m5qlefi7zc+hel1AZXBL68vLTnVNPpoc BMj9D419eMAdxly3bRS6Jpq3y+Big8Yp2XGsnMAMXebcObQv1m1WkuB+b MT7QxZAANDN8uqj; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269941762; x=1301477762; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[e2md ]=20Alternative=20to=20source=20URI|Date:=20Tue,=2030=20M ar=202010=2010:36:00=20+0100|Message-ID:=20|To:=20Jay=20Daley=20|Cc:=20"E.164=20 To=20MetaData=20BOF=20discussion=20list"=20|MIME-Version:=201.0|In-Reply-To:=20|References:=20=20<6ED52ACB-A78C-4 54A-AC73-7E24591A4EFD@softarmor.com>=20 =20; bh=GVybOVlgnzrnGoI/KD2XPRvXYkV2unXQROteeh/hPvk=; b=3CEWW4/Yg+Va7Z598y4WlQmTW8WxCNfugAg2RX3JWrAmHZs/TMgzJ3up meiby4aHd7ffO7LZRvX5wydYEXMH7VurG9ybXOTzPmjCOcZCsIy2U/ylb MElijrkeRXX4DLB; X-IronPort-AV: E=Sophos;i="4.51,333,1267401600"; d="scan'208";a="17479802" Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 30 Mar 2010 10:36:01 +0100 In-Reply-To: References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> To: Jay Daley MIME-Version: 1.0 X-Mailer: Lotus Notes Release 8.5 December 05, 2008 Message-ID: From: Ray.Bellis@nominet.org.uk Date: Tue, 30 Mar 2010 10:36:00 +0100 X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 30/03/2010 10:36:00 AM, Serialize complete at 30/03/2010 10:36:00 AM Content-Type: multipart/alternative; boundary="=_alternative 0034BC17802576F6_=" Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 09:35:35 -0000 This is a multipart message in MIME format. --=_alternative 0034BC17802576F6_= Content-Type: text/plain; charset="US-ASCII" > I have been told repeatedly by carriers that there are privacy > issues over publishing "unused/void" in a public tree because it > tells other carriers what numbers they have in service. Has this > been tackled in NICC? No, it hasn't. At NICC we withdrew "unused" from the requirements. Ray --=_alternative 0034BC17802576F6_= Content-Type: text/html; charset="US-ASCII"
> I have been told repeatedly by carriers that there are privacy
> issues over publishing "unused/void" in a public tree because it
> tells other carriers what numbers they have in service.  Has this
> been tackled in NICC?  
No, it hasn't.  At NICC we withdrew "unused" from the requirements.

Ray
--=_alternative 0034BC17802576F6_=-- From HKaplan@acmepacket.com Tue Mar 30 09:09:29 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9598A3A6405 for ; Tue, 30 Mar 2010 09:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ORI12dzpOEc for ; Tue, 30 Mar 2010 09:09:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E3AD93A6A5B for ; Tue, 30 Mar 2010 09:09:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 30 Mar 2010 12:09:52 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 30 Mar 2010 12:09:52 -0400 From: Hadriel Kaplan To: "Ray.Bellis@nominet.org.uk" Date: Tue, 30 Mar 2010 12:09:50 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrP5A5yMDGWgO7ER9iM0bnX71V54wAPztDw Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92AB7@mail> References: <4BAA4248.2050601@softarmor.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB <430FC6BDED356B4C8498F634416644A91A79E92948@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91A79E92AB7mail_" MIME-Version: 1.0 Cc: "e2md@ietf.org" Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:09:29 -0000 --_000_430FC6BDED356B4C8498F634416644A91A79E92AB7mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correct - the draft actually says both that the TTL sent in the response mu= st be 0, and the client must not cache it, but no doubt there are those tha= t will. Not my problem if they do, though, really. They were warned. -hadriel ________________________________ From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk] Sent: Tuesday, March 30, 2010 4:36 AM To: Hadriel Kaplan Cc: e2md@ietf.org Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling > The results are not cached - the TTL is zero. More strictly, that probably means they're not cached by _your_ implementat= ion? Unfortunately it's not unheard of for other implementations to ignore TTLs = of zero and assume some other lower bound. Ray --_000_430FC6BDED356B4C8498F634416644A91A79E92AB7mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correct – the draft actually say= s both that the TTL sent in the response must be 0, and the client must not c= ache it, but no doubt there are those that will.  Not my problem if they do= , though, really.  They were warned.

-hadriel

 

 

From: Ray.Bellis@nominet.org.uk [mailto:Ray.Bellis@nominet.org.uk]
Sent: Tuesday, March 30, 201= 0 4:36 AM
To: Hadriel Kaplan
Cc: e2md@ietf.org
Subject: Re: [e2md] E2MD, EN= UM, and the DNS: why our approach is stalling

 


> The results are not cached - the TTL is= zero.

Mo= re strictly, that probably means they're not cached by _your_ implementation?<= /span>

Un= fortunately it's not unheard of for other implementations to ignore TTLs of zero and as= sume some other lower bound.

Ra= y

--_000_430FC6BDED356B4C8498F634416644A91A79E92AB7mail_-- From HKaplan@acmepacket.com Tue Mar 30 09:15:33 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93FA3A6C43 for ; Tue, 30 Mar 2010 09:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.718 X-Spam-Level: X-Spam-Status: No, score=0.718 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b182WWPNeUOc for ; Tue, 30 Mar 2010 09:15:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 289463A6AB9 for ; Tue, 30 Mar 2010 09:14:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 30 Mar 2010 12:15:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 30 Mar 2010 12:15:19 -0400 From: Hadriel Kaplan To: Jay Daley Date: Tue, 30 Mar 2010 12:15:18 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPsA2BZ2jPY1LMQ5WXPJEEGY5O5wAc3pfA Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> In-Reply-To: <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:15:34 -0000 > -----Original Message----- > From: Jay Daley [mailto:jay@nzrs.net.nz] > Sent: Monday, March 29, 2010 10:24 PM > To: Hadriel Kaplan >=20 > Assuming the proxy is "allowed" to know this then they either have two > sets of private data, one for the source carrier that services 67890 and > one for the source carrier that services 88888. Or if the originating > carrier is the same then just one set of private data that identifies the > source within it: >=20 > meta-endpoint -> source -> actual-endpoint It is the same source carrier for both calls originating from 77777 and 888= 88, hence the rub - even if the destination carrier says "meta-endpoint", t= he source carrier needs to do a lookup (somewhere) that takes the source nu= mber into account. In other words *someone* has to do a source-based looku= p, and that someone could/would use source-uri. -hadriel From HKaplan@acmepacket.com Tue Mar 30 09:58:52 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998A23A6A8A for ; Tue, 30 Mar 2010 09:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flDOaia0czs7 for ; Tue, 30 Mar 2010 09:58:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7BFCD3A6A80 for ; Tue, 30 Mar 2010 09:58:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 30 Mar 2010 12:59:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 30 Mar 2010 12:59:17 -0400 From: Hadriel Kaplan To: Dean Willis , Jay Daley Date: Tue, 30 Mar 2010 12:58:39 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPh5tDYkAgAOiTTO+WF7irymrW8QAnS1/Q Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92AD7@mail> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> In-Reply-To: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 16:58:52 -0000 This doesn't solve the problem at all - it just moves it around. What protocol do you think we would use to access the "metadata" referenced= ? Answer: DNS. -hadriel > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of > Dean Willis > Sent: Monday, March 29, 2010 5:34 PM > To: Jay Daley >=20 > A fairly large number of people in Anaheim told me that they thought > that the DNS's "immune system" would be open to putting in a pointer > to a general metadata-lookup service along these lines. >=20 > The model they seemed to have in mind is that "The DNS" would have a > per-phone-number (or per-phone-number-aggregation) record that would > point to the metadata service for that phone number or aggregation- > range. >=20 > This eliminates many of the concerns: >=20 > 1) We don't end up putting an additional record into the DNS for each > piece of metadata >=20 > 2) We don't have to define a selective-query or search mechanism on > top of DNS >=20 > 3) We don't have very-large RR-sets in responses due to having many > different metadata types >=20 > 4) We don't need to extend DNS to support source-specific responses >=20 > 5) Authentication and authorization concerns are pushed out of the > DNS's core and onto "the other protocol/service" >=20 > The one repeatedly-heard concern that I know of that this proposal > doesn't directly address is the "framework vs. individual use case" > issue. However, I believe that the main reason this issue comes up is > that adding arbitrary metadata into the DNS is considered a problem > due to to the questions above, which Jay's #2 proposal neatly > bypasses. So, I don't think we'd have nearly the problem with saying > that the external metadata service returns metadata within an > extensible schema that we have with building an extensible metadata > schema directly in the DNS. >=20 > Further, the "metadata" service that the URI points to could well have > all the fast-lookup properties that we know and love from DNS. One > might think of the URI as being something of a "metadata delgation". >=20 > -- > Dean >=20 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md From kcartwright@tnsi.com Tue Mar 30 10:30:12 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409A93A683A for ; Tue, 30 Mar 2010 10:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.023 X-Spam-Level: * X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M71uPaWswlj for ; Tue, 30 Mar 2010 10:30:10 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id 5EA1F3A67FB for ; Tue, 30 Mar 2010 10:30:10 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42050224; Tue, 30 Mar 2010 13:30:28 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Tue, 30 Mar 2010 13:30:29 -0400 From: "Cartwright, Kenneth" To: Jay Daley Date: Tue, 30 Mar 2010 13:30:26 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrPijY8aHm2wBcjTM228JUfUG1lPgAopvdw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6952A258@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> In-Reply-To: <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: E.164, list Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 17:30:12 -0000 I see the merits of it as a way to allay the concern about putting this dat= a into "The DNS". But from my perspective, I do not plan to put this data i= n "The DNS" anyway. But if there are folks that do plan to put this data i= n "The DNS" then this may very well be helpful. But for my use cases, it i= s entirely un-necessary. So, I think, my use cases are basically intereste= d in what the solution is *after* the location of the private data has been= determined. And if that portion of the solution adheres to the 10 rough r= equirements I stated in my email yesterday then *I think* I'm ok with what = is proposed below. So from my perspective, you're suggesting that the solution be broken in tw= o, (1) a mechanism to achieve indirection to the meta-data location, and (2= ) a mechanism to query and resolve the meta-data (the latter here being the= problem that I think we are really working to solve). And the use of part= (2) here can exist without the use of part (1) in the case of data that is= not in "The DNS". One potential issue here though, is the case where a server needs to serve = up both E2U service information and E2M service information. I assume that= that private source could server up both E2U and E2M. It does see a little contrived however, which concerns me a bit because the= re could be corner case issues that we've not thought of yet. And Hadriel = accurately suggests that, to a certain extent, this just moves the solution= space. But maybe that is enough to allay the concerns. Ken -----Original Message----- From: Jay Daley [mailto:jay@nzrs.net.nz] Sent: Monday, March 29, 2010 5:53 PM To: Cartwright, Kenneth Cc: Dean Willis; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI On 30/03/2010, at 10:37 AM, Cartwright, Kenneth wrote: > This approach is less amenable to my needs and seems un-necessarily slow = and complex for the use cases we have. Can you explain why? I think it is actually faster as per this explanation: For (1) there are two additional lookups to plain DNS - lookup to check the validity of the source URI - lookup to retrieve information specific to the source URI for (2) there is only one additional lookup and that is done by the recipie= nt of the data not you - lookup to find private data keyed to public data It also seems far less complex - the information given out in DNS is always the same - there is no issue with spoofing of the source/validation of the source cheers Jay > However, there is of course nothing that says that a given E2U/E2M servic= e cannot re-direct to another URL if that is appropriate for that service. > > Ken > > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of D= ean Willis > Sent: Monday, March 29, 2010 5:34 PM > To: Jay Daley > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Alternative to source URI > > > On Mar 29, 2010, at 4:14 PM, Jay Daley wrote: >> >> The alternative (2) is simple indirection combined with private data. >> >> ... >> >> and (2) goes >> - send private data beforehand to different parties >> - when anyone asks for data give the same public data >> - each recipient then use the public data as a key into their >> private data. Each recipient with different private data will get a >> different answer. >> >> (2) does not require any change to DNS, eliminates all issues of >> privacy, deals with caching and wildcards and just works. >> >> A more concrete example: >> >> - under 7.7.6.9.1.3.9.4.4.6.whatever is published >> NAPTR "e2md" "meta-endpoint:endpoint-1" >> >> - my best buddy carrier has private data that says >> "endpoint-1" is serviced by "sip:6449316977@somewhere-special" >> >> - all other carriers I am forced by regulators to connect to have >> data that says >> "endpoint-1" is serviced by "sip6449316977@little-box-in-the-corner= " >> >> >> any thoughts? > > > I think it's very interesting. > > A fairly large number of people in Anaheim told me that they thought > that the DNS's "immune system" would be open to putting in a pointer > to a general metadata-lookup service along these lines. > > The model they seemed to have in mind is that "The DNS" would have a > per-phone-number (or per-phone-number-aggregation) record that would > point to the metadata service for that phone number or aggregation- > range. > > This eliminates many of the concerns: > > 1) We don't end up putting an additional record into the DNS for each > piece of metadata > > 2) We don't have to define a selective-query or search mechanism on > top of DNS > > 3) We don't have very-large RR-sets in responses due to having many > different metadata types > > 4) We don't need to extend DNS to support source-specific responses > > 5) Authentication and authorization concerns are pushed out of the > DNS's core and onto "the other protocol/service" > > The one repeatedly-heard concern that I know of that this proposal > doesn't directly address is the "framework vs. individual use case" > issue. However, I believe that the main reason this issue comes up is > that adding arbitrary metadata into the DNS is considered a problem > due to to the questions above, which Jay's #2 proposal neatly > bypasses. So, I don't think we'd have nearly the problem with saying > that the external metadata service returns metadata within an > extensible schema that we have with building an extensible metadata > schema directly in the DNS. > > Further, the "metadata" service that the URI points to could well have > all the fast-lookup properties that we know and love from DNS. One > might think of the URI as being something of a "metadata delgation". > > -- > Dean > > > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md > > This e-mail message is for the sole use of the intended recipient(s)and m= ay > contain confidential and privileged information of Transaction Network Se= rvices. > Any unauthorised review, use, disclosure or distribution is prohibited. I= f you > are not the intended recipient, please contact the sender by reply e-mail= and destroy all copies of the original message. > -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From jay@nzrs.net.nz Tue Mar 30 12:29:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 632153A690C for ; Tue, 30 Mar 2010 12:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.283 X-Spam-Level: * X-Spam-Status: No, score=1.283 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EycZNZzlqODO for ; Tue, 30 Mar 2010 12:29:23 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 931A23A68ED for ; Tue, 30 Mar 2010 12:29:23 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 188732DB03B for ; Wed, 31 Mar 2010 08:29:52 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rIjCyOEekjk for ; Wed, 31 Mar 2010 08:29:51 +1300 (NZDT) Received: from [192.168.22.175] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id C01862DA245 for ; Wed, 31 Mar 2010 08:29:51 +1300 (NZDT) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Mar 2010 08:29:51 +1300 Message-Id: <14A14924-3942-43BD-A05F-FDD9ED330948@nzrs.net.nz> To: "E.164 To MetaData BOF discussion list" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [e2md] A matrix X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 19:29:24 -0000 If we accept there is a spectrum of use from 'public' to 'under = publisher control' we can draw up a matrix of where current features = possibly fit. For this I am assuming standard DNS - so no source-uri = and no private DNS Determining an endpoint public: E2U + URI controlled: E2MD + key into private data Unused/void public: E2U/E2MD + unused controlled: E2MD + key into private data (no entry in private = data) Subscriber info public: E2U/E2MD + CNAM controlled: ?? Send-n public: E2U/E2MD + send-n controlled: ?? =46rom this some decisions follow: 1. Is the general model acceptable? 2. Is there a need for 'controlled' variants where missing (I guess = many will say yes to subscriber info and few will say yes to send-n)? 3. Does this imply a split in usage, whereby public data is in E2U and = controlled in E2MD (e.g. for unused) or is that simplifying too much? cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From lendl@nic.at Tue Mar 30 13:21:34 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101293A68BE for ; Tue, 30 Mar 2010 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.65 X-Spam-Level: X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9TUHozi2swK for ; Tue, 30 Mar 2010 13:21:32 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id BEF593A681C for ; Tue, 30 Mar 2010 13:21:04 -0700 (PDT) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 2BF434CE74; Tue, 30 Mar 2010 22:21:32 +0200 (CEST) Message-ID: <4BB25D4A.6020104@nic.at> Date: Tue, 30 Mar 2010 22:21:30 +0200 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Dean Willis References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> In-Reply-To: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 20:21:34 -0000 On 29.03.2010 23:34, Dean Willis wrote: > > I think it's very interesting. > > A fairly large number of people in Anaheim told me that they thought > that the DNS's "immune system" would be open to putting in a pointer to > a general metadata-lookup service along these lines. As others have noted, speermint's LUF / LRF distinction also leads in this direction. > The model they seemed to have in mind is that "The DNS" would have a > per-phone-number (or per-phone-number-aggregation) record that would > point to the metadata service for that phone number or aggregation-range. > > This eliminates many of the concerns: > > 1) We don't end up putting an additional record into the DNS for each > piece of metadata > > 2) We don't have to define a selective-query or search mechanism on top > of DNS > > 3) We don't have very-large RR-sets in responses due to having many > different metadata types > > 4) We don't need to extend DNS to support source-specific responses > > 5) Authentication and authorization concerns are pushed out of the DNS's > core and onto "the other protocol/service" I see a slightly different split between the "direct data retrieval" and the "getting a key for a second look-up" use-cases: For me, if the use-case needs 2) (a more expressive query language) or 4) (different answers depending on who's asking), then a pure ENUM-like solution won't cut it and ENUM/E2MD needs to refer to another lookup mechanism. This way, the DNS continues to serve as simple directory and no assumptions on its operational parameters need to be re-evaluated. Your 5) isn't that much of a deal-breaker for me, private trees usually can handle this good enough. --------- So I'd view CNAM as a use-case where you put the actual data in your (probably private) DNS. After all, the name is the same regardless of who queries. (only access rules might apply, e.g. for emergency services) Regarding the overhead of a second query, e.g. for determining SIP routing information (outbound proxy, source dependent): I think that a good selection of the ENUM/E2MD (= the LUF) return values (e.g. destination groups) will enable very efficient caching of the answers retrieved from the second stage query (the LRF). For example: if simple E2MD queries yield the categorization of both calling and called number, then the routing decision is the same for all other calls where caller and callee are mapped to the same destination-group pair. otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From lendl@nic.at Tue Mar 30 13:30:27 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2203A6800 for ; Tue, 30 Mar 2010 13:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hak4ZUFF7YbX for ; Tue, 30 Mar 2010 13:30:25 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id A550F3A6405 for ; Tue, 30 Mar 2010 13:30:23 -0700 (PDT) Received: from [10.20.30.241] (alix.bofh.priv.at [213.129.239.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bofh.priv.at (Postfix) with ESMTPSA id 59DF94CE74 for ; Tue, 30 Mar 2010 22:30:52 +0200 (CEST) Message-ID: <4BB25F78.8080406@nic.at> Date: Tue, 30 Mar 2010 22:30:48 +0200 From: Otmar Lendl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: e2md@ietf.org References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 20:30:27 -0000 On 29.03.2010 22:37, Cartwright, Kenneth wrote: > Now that maybe we're back on track, here's a rough re-statement of what one might like to see from this E2U/E2M infrastructure we are supposed to be talking about, notice how similar it is to DDDS, plus some orthogonal extensions: > I think your list is very helpful. I'm not sure that > 5) Have a standard way to identify the source of a query, both at the > organization level, and down to the "device/node" level within an > organization (Hadriel's proposal gives us this). and > 9) Have a standard way for the querier to specify, per query, which E2U > and/or E2M services it is interested in having in its query response > (although this is less vital, this is already done to a lesser extent > today, but via non-standard means) (however, Hadriel's proposal might > also give us this). are compatible with > 7) Continue to allow "Bind" to function as, at least, a proxy > pass-through client for queries. Iow, the base query request/response > structure needs to be backward compatible with "Bind" (DDDS and ENUM > gives us this). This also applies to other current DNS software implementations (stub resolvers or recursors). otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // From dean.willis@softarmor.com Tue Mar 30 20:06:53 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB253A67F8 for ; Tue, 30 Mar 2010 20:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCB4ZKnlkUFH for ; Tue, 30 Mar 2010 20:06:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B8CE03A6783 for ; Tue, 30 Mar 2010 20:06:52 -0700 (PDT) Received: from localhost.localdomain (mobile-032-168-141-052.mycingular.net [32.168.141.52] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2V378Vu021684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Mar 2010 22:07:18 -0500 X-User-Agent: K-9 Mail for Android In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92AD7@mail> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79E92AD7@mail> Content-Type: multipart/mixed; boundary="----A3LXWE6QOMG0H23M4KVTVGP8VSY6YT" MIME-Version: 1.0 From: Dean Willis Date: Tue, 30 Mar 2010 22:07:11 -0500 To: Hadriel Kaplan , Jay Daley Message-ID: Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 03:06:53 -0000 ------A3LXWE6QOMG0H23M4KVTVGP8VSY6YT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiJIYWRyaWVsIEthcGxhbiIgPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+IHdyb3RlOgoKPgo+VGhp cyBkb2Vzbid0IHNvbHZlIHRoZSBwcm9ibGVtIGF0IGFsbCAtIGl0IGp1c3QgbW92ZXMgaXQgYXJv dW5kLgo+V2hhdCBwcm90b2NvbCBkbyB5b3UgdGhpbmsgd2Ugd291bGQgdXNlIHRvIGFjY2VzcyB0 aGUgIm1ldGFkYXRhIiByZWZlcmVuY2VkPwo+QW5zd2VyOiBETlMKCkkgYmVsaWV2ZSB5b3Ugd2Vy ZSBkZXNjcmliaW5nIGEgcHJvdG9jb2wgeW91IGNhbGxlZCBFTlMgd2hlbiB3ZXJlIGluIEFuYWhl aW0uICBFTlVNIHBvaW50cyB2aWEgYSBOQVBUUiB0byBhbiBFTlMgZW50cnkgcG9pbnQsIGFuZCBF TlMgY2FuIHRoZW4gZG8gYWxsIHRoZSB0aGluZ3Mgd2Ugd2FudGVkIGRvIGRvIGluIEROUyBidXQg Y291bGRuJ3QgZ2V0IHBhc3QgdGhlIGltbXVuZSBzeXN0ZW0uCgogCi0tIApEZWFuIFdpbGxpcw== ------A3LXWE6QOMG0H23M4KVTVGP8VSY6YT-- ------A3LXWE6QOMG0H23M4KVTVGP8VSY6YT-- From dean.willis@softarmor.com Tue Mar 30 21:25:28 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A7153A68F9 for ; Tue, 30 Mar 2010 21:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.838 X-Spam-Level: X-Spam-Status: No, score=0.838 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPl+2PtPLiXR for ; Tue, 30 Mar 2010 21:25:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 54E9C3A6A45 for ; Tue, 30 Mar 2010 21:25:07 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2V4PZU6022168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Mar 2010 23:25:37 -0500 Message-Id: <4277C379-8580-4213-8AC4-A98470238D75@softarmor.com> From: Dean Willis To: "Cartwright, Kenneth" In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6952A258@TNS-MAIL-NA.win2k.corp.tnsi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Mar 2010 23:25:29 -0500 References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> <754963199212404AB8E9CFCA6C3D0CDA1F6952A258@TNS-MAIL-NA.win2k.corp.tnsi.com> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 04:25:28 -0000 On Mar 30, 2010, at 12:30 PM, Cartwright, Kenneth wrote: > I see the merits of it as a way to allay the concern about putting > this data into "The DNS". But from my perspective, I do not plan to > put this data in "The DNS" anyway. But if there are folks that do > plan to put this data in "The DNS" then this may very well be helpful. The argument that we're not getting goes like this: Once the IETF has blessed the specifications for putting X in the DNS protocol (which they would need to do to let us use the DNS protocol for our private installations), then some yokel will come along and say "Gee whiz, Mom! The IETF says I should put my diary in The DNS!" and proceeds to do so. > Since this proposal can in no way be used to put a diary or other cruft into The DNS, it should be no more offensive to the DNS directorate than ENUM currently is (which is non-zero, but something they can't really complain about). Now it might well let somebody put a pointer to his diary into the DNS, but how is that any worse than having a pointer to wikipedia in there? -- Dean From jay@nzrs.net.nz Tue Mar 30 21:51:45 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73103A690A for ; Tue, 30 Mar 2010 21:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57phpycsAIzU for ; Tue, 30 Mar 2010 21:51:45 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id DF5E93A6905 for ; Tue, 30 Mar 2010 21:51:44 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 6E0F42DBC9E; Wed, 31 Mar 2010 17:52:11 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PSbz-fMqMxp; Wed, 31 Mar 2010 17:52:11 +1300 (NZDT) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id C54412DBC79; Wed, 31 Mar 2010 17:52:10 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> Date: Wed, 31 Mar 2010 17:01:54 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1077) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 04:51:45 -0000 On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote: >> Assuming the proxy is "allowed" to know this then they either have = two >> sets of private data, one for the source carrier that services 67890 = and >> one for the source carrier that services 88888. Or if the = originating >> carrier is the same then just one set of private data that identifies = the >> source within it: >>=20 >> meta-endpoint -> source -> actual-endpoint >=20 > It is the same source carrier for both calls originating from 77777 = and 88888, hence the rub - even if the destination carrier says = "meta-endpoint", the source carrier needs to do a lookup (somewhere) = that takes the source number into account. In other words *someone* has = to do a source-based lookup, and that someone could/would use = source-uri. I might be being thick here but I don't get why you think the only = solution is source-uri. What effect is achieved by source-uri that is = not achieved by the scheme I'm suggesting? As far as I can tell they = achieve exactly the same thing. cheers Jay >=20 > -hadriel --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From kcartwright@tnsi.com Wed Mar 31 06:12:15 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1B13A6856 for ; Wed, 31 Mar 2010 06:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.028 X-Spam-Level: * X-Spam-Status: No, score=1.028 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTxfWDT+Di2B for ; Wed, 31 Mar 2010 06:12:14 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id E83023A6878 for ; Wed, 31 Mar 2010 06:12:10 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42078555; Wed, 31 Mar 2010 09:12:37 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Mar 2010 09:12:37 -0400 From: "Cartwright, Kenneth" To: Dean Willis Date: Wed, 31 Mar 2010 09:12:35 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrQikEjKMSL5y6WRTiXVjmLaKL/VgAR+4bw Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6952A5C1@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <6ED52ACB-A78C-454A-AC73-7E24591A4EFD@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F69529EFF@TNS-MAIL-NA.win2k.corp.tnsi.com> <0882306D-0D50-4831-9258-374E08465DA4@nzrs.net.nz> <754963199212404AB8E9CFCA6C3D0CDA1F6952A258@TNS-MAIL-NA.win2k.corp.tnsi.com> <4277C379-8580-4213-8AC4-A98470238D75@softarmor.com> In-Reply-To: <4277C379-8580-4213-8AC4-A98470238D75@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 13:12:16 -0000 You do not seem to be directly responding to what I said. I said "I see th= e merits of it as a way to allay...". So Yes. I get that. I don't agree= with it, because the realities I have lived and observed around how the sy= stems and code that underlies "The DNS" is architected, maintained, managed= , and operated do not at all bear that out. But perhaps you did not like t= he fact that my underlying opinions bleed through in my email below. Sorry= about that, it just resulted in some email spam here. But believe me, I g= et that. That's why I agreed with the rough outline of Hadrliel's proposal= and in the email you responded to below to basically create a spec that fo= rmally moves the problem space I said "I see the merits of it". Ken -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, March 31, 2010 12:25 AM To: Cartwright, Kenneth Cc: Jay Daley; E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI On Mar 30, 2010, at 12:30 PM, Cartwright, Kenneth wrote: > I see the merits of it as a way to allay the concern about putting > this data into "The DNS". But from my perspective, I do not plan to > put this data in "The DNS" anyway. But if there are folks that do > plan to put this data in "The DNS" then this may very well be helpful. The argument that we're not getting goes like this: Once the IETF has blessed the specifications for putting X in the DNS protocol (which they would need to do to let us use the DNS protocol for our private installations), then some yokel will come along and say "Gee whiz, Mom! The IETF says I should put my diary in The DNS!" and proceeds to do so. > Since this proposal can in no way be used to put a diary or other cruft into The DNS, it should be no more offensive to the DNS directorate than ENUM currently is (which is non-zero, but something they can't really complain about). Now it might well let somebody put a pointer to his diary into the DNS, but how is that any worse than having a pointer to wikipedia in there? -- Dean This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Wed Mar 31 07:21:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098093A68BF for ; Wed, 31 Mar 2010 07:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.144 X-Spam-Level: ** X-Spam-Status: No, score=2.144 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, FB_IOW=3.333] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ygui0-fany9I for ; Wed, 31 Mar 2010 07:21:22 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id A3EF53A692D for ; Wed, 31 Mar 2010 07:21:14 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42081329; Wed, 31 Mar 2010 10:21:36 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Mar 2010 10:21:36 -0400 From: "Cartwright, Kenneth" To: Otmar Lendl , "e2md@ietf.org" Date: Wed, 31 Mar 2010 10:21:35 -0400 Thread-Topic: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling Thread-Index: AcrQR+2Umh0v6XVrTYyVrEUSrt28fwAkxi1A Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6952A65B@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <4BAA4248.2050601@softarmor.com> <02098184-D7B9-4CFB-B522-B3F16D8EF6C2@rfc1035.com>, <4BAA739B.2000609@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6937FE6D@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAA88CE.3030904@softarmor.com> <430FC6BDED356B4C8498F634416644A91A79CD1EC2@mail> <754963199212404AB8E9CFCA6C3D0CDA1F6911EE35@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BACDFEF.20307@softarmor.com> <754963199212404AB8E9CFCA6C3D0CDA1F6911EFA5@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BAD2039.3030502@softarmor.com> <9AA6E358-4BEE-4A64-BA33-A94840AAEFB2@standardstrack.com> <4BB04669.3070500@softarmor.com> <1C8477AA-1FB6-4064-B0AB-018049FDD24A@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E928FB@mail> <01b101cacf7c$540357c0$fc0a0740$@us> <754963199212404AB8E9CFCA6C3D0CDA1F69529E7A@TNS-MAIL-NA.win2k.corp.tnsi.com> <4BB25F78.8080406@nic.at> In-Reply-To: <4BB25F78.8080406@nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 14:21:24 -0000 I understand what you are getting at, but I do not see these statements as = incompatible. If an organization happens to be using a DNS codebase that d= oes not support some technical features (e.g. EDNS, which I think Hadriel's= proposal relies on) and/or does not support technical features that may be= orthogonal to what is considered "core DNS" technologies, then that organi= zation would of course not be able to employ the use cases enabled by those= features. But other organizations, who do have those features enabled, wo= uld. I do not see this as an all or nothing proposition. The willingness = to do source based selection, or selection based on other criteria are a ma= tter of policy. That being said, number 9 is really a "wish list" item, and should definite= ly be regarded as less critical than other requirements. Thanks Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Otm= ar Lendl Sent: Tuesday, March 30, 2010 4:31 PM To: e2md@ietf.org Subject: Re: [e2md] E2MD, ENUM, and the DNS: why our approach is stalling On 29.03.2010 22:37, Cartwright, Kenneth wrote: > Now that maybe we're back on track, here's a rough re-statement of what o= ne might like to see from this E2U/E2M infrastructure we are supposed to be= talking about, notice how similar it is to DDDS, plus some orthogonal exte= nsions: > I think your list is very helpful. I'm not sure that > 5) Have a standard way to identify the source of a query, both at the > organization level, and down to the "device/node" level within an > organization (Hadriel's proposal gives us this). and > 9) Have a standard way for the querier to specify, per query, which E2U > and/or E2M services it is interested in having in its query response > (although this is less vital, this is already done to a lesser extent > today, but via non-standard means) (however, Hadriel's proposal might > also give us this). are compatible with > 7) Continue to allow "Bind" to function as, at least, a proxy > pass-through client for queries. Iow, the base query request/response > structure needs to be backward compatible with "Bind" (DDDS and ENUM > gives us this). This also applies to other current DNS software implementations (stub resolvers or recursors). otmar -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From kcartwright@tnsi.com Wed Mar 31 08:53:50 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E800E3A69FC for ; Wed, 31 Mar 2010 08:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39gEpSFXTATX for ; Wed, 31 Mar 2010 08:53:50 -0700 (PDT) Received: from tnsi.com (relayus.tnsi.com [208.224.248.44]) by core3.amsl.com (Postfix) with ESMTP id DFF053A69FB for ; Wed, 31 Mar 2010 08:53:49 -0700 (PDT) Received: from ([172.17.7.231]) by relayus.tnsi.com with ESMTP with TLS id 4440551.42085465; Wed, 31 Mar 2010 11:54:05 -0400 Received: from TNS-MAIL-NA.win2k.corp.tnsi.com ([172.17.7.214]) by MAIL-HUB-NA.win2k.corp.tnsi.com ([172.17.7.231]) with mapi; Wed, 31 Mar 2010 11:54:04 -0400 From: "Cartwright, Kenneth" To: Jay Daley , Hadriel Kaplan Date: Wed, 31 Mar 2010 11:54:02 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrQjikUMuB4ZNrlQ6CUBC4jMtnh3QAWu+Bg Message-ID: <754963199212404AB8E9CFCA6C3D0CDA1F6952A756@TNS-MAIL-NA.win2k.corp.tnsi.com> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> In-Reply-To: <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 15:53:51 -0000 Source based responses can be selected at three levels of granularity (depe= nding on the policy driven need of the given use case): 1) Source Organization (done today through non-standard means such as a dif= ferent root domain to the same DNS server) 2) Source Node/IP (done today through non-standardized means such as source= IP address of the DNS query) 3) Source Person/Identity (done today via non-standardized means such as th= e callers SIP URI) Does what you propose directly support all three, directly support a subset= of the three, get in the way of any of the three, ignore any of the three,= etc? Granted I've not had the time to follow all of these emails, but it'= s not clear to me that it supports 2 and 3. Sorry if I missed something in= a previous email. If so please just point me at that email and I will rea= d/reread it. Ken -----Original Message----- From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf Of Jay= Daley Sent: Wednesday, March 31, 2010 12:02 AM To: Hadriel Kaplan Cc: E.164 To MetaData BOF discussion list Subject: Re: [e2md] Alternative to source URI On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote: >> Assuming the proxy is "allowed" to know this then they either have two >> sets of private data, one for the source carrier that services 67890 and >> one for the source carrier that services 88888. Or if the originating >> carrier is the same then just one set of private data that identifies th= e >> source within it: >> >> meta-endpoint -> source -> actual-endpoint > > It is the same source carrier for both calls originating from 77777 and 8= 8888, hence the rub - even if the destination carrier says "meta-endpoint",= the source carrier needs to do a lookup (somewhere) that takes the source = number into account. In other words *someone* has to do a source-based loo= kup, and that someone could/would use source-uri. I might be being thick here but I don't get why you think the only solution= is source-uri. What effect is achieved by source-uri that is not achieved= by the scheme I'm suggesting? As far as I can tell they achieve exactly t= he same thing. cheers Jay > > -hadriel -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 _______________________________________________ e2md mailing list e2md@ietf.org https://www.ietf.org/mailman/listinfo/e2md This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Serv= ices. Any unauthorised review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply e-mail a= nd destroy all copies of the original message. From HKaplan@acmepacket.com Wed Mar 31 10:08:04 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51C73A6BBE for ; Wed, 31 Mar 2010 10:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVA03DqEi5Tb for ; Wed, 31 Mar 2010 10:08:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 245313A69FC for ; Wed, 31 Mar 2010 09:59:13 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 31 Mar 2010 12:59:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 31 Mar 2010 12:59:42 -0400 From: Hadriel Kaplan To: Jay Daley Date: Wed, 31 Mar 2010 12:59:17 -0400 Thread-Topic: [e2md] Alternative to source URI Thread-Index: AcrQjfxLsI0SUKD/SsOayJKd16tntgAY3kuA Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92D4B@mail> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> In-Reply-To: <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:08:04 -0000 > -----Original Message----- > From: Jay Daley [mailto:jay@nzrs.net.nz] > Sent: Wednesday, March 31, 2010 12:02 AM >=20 > I might be being thick here but I don't get why you think the only > solution is source-uri. =20 Oh it may well be *me* being thick. :) But I'm not saying the source-uri mechanism in particular is the _only_ sol= ution - I mean you could skin the cat many ways. I just think skinning the= cat requires looking up some database at some point with a key that has so= urce information - not the source of the query to the DB, but the source of= the call. > What effect is achieved by source-uri that is not > achieved by the scheme I'm suggesting? As far as I can tell they achieve > exactly the same thing. Then I clearly don't understand your proposal. :( Afaict, what you're proposing is that given a query to destination 5.4.3.2.= 1.foo, you'd return a "key" which I would locally interpret, but that same = key value someone else would interpret differently. That's all fine, but i= t doesn't solve my problem: My problem is that when I do a query for 5.4.3.2.1.foo, sometimes it needs = to resolve to answer1, and sometimes to answer2 - for the *same* client tha= t asks the question/query. What decides whether it's answer1 or answer2 is= the source number/info of the SIP request. In the public DNS context I assume that in general the servers won't know w= hether its answer1/answer2 or even that there are multiple answers. All I = need from them is a SPID or a Dest-Group or whatever - some form of aggrega= tor "key" as you put it, which then gets used in my local/private next-stag= e, but I still need the source info to be used in that next-stage. -hadriel From dean.willis@softarmor.com Wed Mar 31 10:33:24 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8663A69BA for ; Wed, 31 Mar 2010 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5om4g73tHTz for ; Wed, 31 Mar 2010 10:33:23 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 90A213A691D for ; Wed, 31 Mar 2010 10:32:38 -0700 (PDT) Received: from localhost.localdomain (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2VHX4ie028727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Mar 2010 12:33:07 -0500 X-User-Agent: K-9 Mail for Android Content-Type: multipart/mixed; boundary="----HRJH0882LSLBCYHYHR3YKCNRTNSY64" MIME-Version: 1.0 From: Dean Willis Date: Wed, 31 Mar 2010 12:32:59 -0500 To: "Cartwright, Kenneth" Message-ID: <1d8fcc81-dbe1-4ff9-beb7-7c37f517aa97@email.android.com> Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 17:33:24 -0000 ------HRJH0882LSLBCYHYHR3YKCNRTNSY64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiJDYXJ0d3JpZ2h0LCBLZW5uZXRoIiA8a2NhcnR3cmlnaHRAdG5zaS5jb20+IHdyb3RlOgoKPllv dSBkbyBub3Qgc2VlbSB0byBiZSBkaXJlY3RseSByZXNwb25kaW5nIHRvIHdoYXQgSSBzYWlkLiAg SSBzYWlkICJJIHNlZSB0aGUgbWVyaXRzIG9mIGl0IGFzIGEgd2F5IHRvIGFsbGF5Li4uIi4gICBT byBZZXMuICBJIGdldCB0aGF0LiAgSSBkb24ndCBhZ3JlZSB3aXRoIGl0LCBiZWNhdXNlIHRoZSBy ZWFsaXRpZXMgSSBoYXZlIGxpdmVkIGFuZCBvYnNlcnZlZCBhcm91bmQgaG93IHRoZSBzeXN0ZW1z IGFuZCBjb2RlIHRoYXQgdW5kZXJsaWVzICJUaGUgRE5TIiBpcyBhcmNoaXRlY3RlZCwgbWFpbnRh aW5lZCwgbWFuYWdlZCwgYW5kIG9wZXJhdGVkIGRvIG5vdCBhdCBhbGwgYmVhciB0aGF0IG91dC4g IEJ1dCBwZXJoYXBzIHlvdSBkaWQgbm90IGxpa2UgdGhlIGZhY3QgdGhhdCBteSB1bmRlcmx5aW5n IG9waW5pb25zIGJsZWVkIHRocm91Z2ggaW4gbXkgZW1haWwgYmVsb3cuICBTb3JyeSBhYm91dCB0 aGF0LCBpdCBqdXN0IHJlc3VsdGVkIGluIHNvbWUgZW1haWwgc3BhbSBoZXJlLiAgQnV0IGJlbGll dmUgbWUsIEkgZ2V0IHRoYXQuICBUaGF0J3Mgd2h5IEkgYWdyZWVkIHdpdGggdGhlIHJvdWdoIG91 dGxpbmUgb2YgSGFkcmxpZWwncyBwcm9wb3NhbCBhbmQgaW4gdGhlIGVtYWlsIHlvdSByZXNwb25k ZWQgdG8gYmVsb3cgdG8gYmFzaWNhbGx5IGNyZWF0ZSBhIHNwZWMgdGhhdCBmb3JtYWxseSBtb3Zl cyB0aGUgcHJvYmxlbSBzcGFjZSBJIHNhaWQgIkkgc2VlIHRoZSBtZXJpdHMgb2YgaXQiLgo+CgoK SSdtIHNvcnJ5LiBJIHdhcyBpbnRlbmRpbmcgdG8gYWdyZWUgd2l0aCB3aGF0IHlvdSB3ZXJlIHNh eWluZyBhbmQgYW1wbGlmeSBvbiBpdHMgY29yZSBwaWVjZS4gSSdtIGFjdHVhbGx5IHF1aXRlIGhh cHB5IHdpdGggaG93IHRoZSBtYWlsaW5nIGxpc3QgY29udmVyc2F0aW9uIGlzIGdvaW5nIHJpZ2h0 IG5vdy4gV2UgaGF2ZSByZWFsbHkgc3RhcnRlZCB0byB0YWtlIHNvbWUgb2YgdGhlIGNyaXRpY2lz bSBpbnRvIGNvbnNpZGVyYXRpb24gYW5kIGFyZSBleHBsb3JpbmcgYWx0ZXJuYXRpdmVzLiBUaGF0 IGlzIEdSRUFULCBhbmQgSSBzaG91bGQgcHJvYmFibHkganVzdCBzaHV0IHVwIG5vdyBsZXN0IEkg ZGVyYWlsIHRoZSB0cmFpbiBvZiB0aG91Z2h0LgoKVGhhbmtzISAKLS0gCkRlYW4gV2lsbGlz ------HRJH0882LSLBCYHYHR3YKCNRTNSY64-- From jay@nzrs.net.nz Wed Mar 31 13:33:01 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18343A6AAE for ; Wed, 31 Mar 2010 13:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.112 X-Spam-Level: * X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtdWFgg54jPN for ; Wed, 31 Mar 2010 13:33:00 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 7F58A3A6AA1 for ; Wed, 31 Mar 2010 13:33:00 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 41C502CE00D; Thu, 1 Apr 2010 09:33:30 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+-16EGensik; Thu, 1 Apr 2010 09:33:30 +1300 (NZDT) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 22A1E2CE00B; Thu, 1 Apr 2010 09:33:28 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <754963199212404AB8E9CFCA6C3D0CDA1F6952A756@TNS-MAIL-NA.win2k.corp.tnsi.com> Date: Thu, 1 Apr 2010 09:33:27 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <106E39D6-65AF-4A53-A3F5-633D5F32A936@nzrs.net.nz> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> <754963199212404AB8E9CFCA6C3D0CDA1F6952A756@TNS-MAIL-NA.win2k.corp.tnsi.com> To: "Cartwright, Kenneth" X-Mailer: Apple Mail (2.1078) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 20:33:02 -0000 On 1/04/2010, at 4:54 AM, Cartwright, Kenneth wrote: > Source based responses can be selected at three levels of granularity = (depending on the policy driven need of the given use case): thanks, this is very helpful. > 1) Source Organization (done today through non-standard means such as = a different root domain to the same DNS server) That is achieved by deciding to whom to give what private data. > 2) Source Node/IP (done today through non-standardized means such as = source IP address of the DNS query) This is presumably an indirect mechanism for a different form of source = based filtering - in other words it is not the IP that actually matters = but who is using that IP? If is actually the IP then that is achieved by the contents of the = private data. > 3) Source Person/Identity (done today via non-standardized means such = as the callers SIP URI) That is achieved by the contents of the private data. > Does what you propose directly support all three, directly support a = subset of the three, get in the way of any of the three, ignore any of = the three, etc? Granted I've not had the time to follow all of these = emails, but it's not clear to me that it supports 2 and 3. Sorry if I = missed something in a previous email. If so please just point me at = that email and I will read/reread it. I think it does support all three but I need to understand the purpose = of 2 a bit better to be sure, assuming you think I have explained 1 and = 3 well enough. Can you provide more detail? thanks Jay >=20 > Ken >=20 >=20 > -----Original Message----- > From: e2md-bounces@ietf.org [mailto:e2md-bounces@ietf.org] On Behalf = Of Jay Daley > Sent: Wednesday, March 31, 2010 12:02 AM > To: Hadriel Kaplan > Cc: E.164 To MetaData BOF discussion list > Subject: Re: [e2md] Alternative to source URI >=20 >=20 > On 31/03/2010, at 5:15 AM, Hadriel Kaplan wrote: >=20 >>> Assuming the proxy is "allowed" to know this then they either have = two >>> sets of private data, one for the source carrier that services 67890 = and >>> one for the source carrier that services 88888. Or if the = originating >>> carrier is the same then just one set of private data that = identifies the >>> source within it: >>>=20 >>> meta-endpoint -> source -> actual-endpoint >>=20 >> It is the same source carrier for both calls originating from 77777 = and 88888, hence the rub - even if the destination carrier says = "meta-endpoint", the source carrier needs to do a lookup (somewhere) = that takes the source number into account. In other words *someone* has = to do a source-based lookup, and that someone could/would use = source-uri. >=20 > I might be being thick here but I don't get why you think the only = solution is source-uri. What effect is achieved by source-uri that is = not achieved by the scheme I'm suggesting? As far as I can tell they = achieve exactly the same thing. >=20 > cheers > Jay >=20 >=20 >>=20 >> -hadriel >=20 >=20 > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 > _______________________________________________ > e2md mailing list > e2md@ietf.org > https://www.ietf.org/mailman/listinfo/e2md >=20 > This e-mail message is for the sole use of the intended = recipient(s)and may > contain confidential and privileged information of Transaction Network = Services. > Any unauthorised review, use, disclosure or distribution is = prohibited. If you > are not the intended recipient, please contact the sender by reply = e-mail and destroy all copies of the original message. >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From jay@nzrs.net.nz Wed Mar 31 13:40:39 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E53A3A69FB for ; Wed, 31 Mar 2010 13:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.116 X-Spam-Level: * X-Spam-Status: No, score=1.116 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztyRQu3SG-Pd for ; Wed, 31 Mar 2010 13:40:38 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by core3.amsl.com (Postfix) with ESMTP id 5A2493A6970 for ; Wed, 31 Mar 2010 13:40:38 -0700 (PDT) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 3E2BC2CE00B; Thu, 1 Apr 2010 09:41:09 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h60rIkukkQf2; Thu, 1 Apr 2010 09:41:09 +1300 (NZDT) Received: from [192.168.1.4] (121-73-182-97.dsl.telstraclear.net [121.73.182.97]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 8F8392DBF4D; Thu, 1 Apr 2010 09:41:08 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jay Daley In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92D4B@mail> Date: Thu, 1 Apr 2010 09:41:07 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <9EF196ED-5A97-4DEE-9F84-3D077F65FB72@nzrs.net.nz> References: <430FC6BDED356B4C8498F634416644A91A79E92953@mail> <430FC6BDED356B4C8498F634416644A91A79E92982@mail> <30A5CA73-90EF-416C-8C15-BAF3B4593E28@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92ABE@mail> <1DD1342F-8CCA-4D7B-B688-C2F691D55B8B@nzrs.net.nz> <430FC6BDED356B4C8498F634416644A91A79E92D4B@mail> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1078) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] Alternative to source URI X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 20:40:39 -0000 On 1/04/2010, at 5:59 AM, Hadriel Kaplan wrote: >> I might be being thick here but I don't get why you think the only >> solution is source-uri. =20 >=20 > Oh it may well be *me* being thick. :) >=20 > But I'm not saying the source-uri mechanism in particular is the = _only_ solution - I mean you could skin the cat many ways. I just think = skinning the cat requires looking up some database at some point with a = key that has source information - not the source of the query to the DB, = but the source of the call. >=20 >> What effect is achieved by source-uri that is not >> achieved by the scheme I'm suggesting? As far as I can tell they = achieve >> exactly the same thing. >=20 > Then I clearly don't understand your proposal. :( >=20 > Afaict, what you're proposing is that given a query to destination = 5.4.3.2.1.foo, you'd return a "key" which I would locally interpret, but = that same key value someone else would interpret differently. That's = all fine, but it doesn't solve my problem: > My problem is that when I do a query for 5.4.3.2.1.foo, sometimes it = needs to resolve to answer1, and sometimes to answer2 - for the *same* = client that asks the question/query. What decides whether it's answer1 = or answer2 is the source number/info of the SIP request. The local interpretation is effectively looking up a tuple of "source number/info of the SIP request", "key", "answers" so the private data actually encodes within it everything needed to = produce either answer1 or answer2. Does that explain it? > In the public DNS context I assume that in general the servers won't = know whether its answer1/answer2 or even that there are multiple = answers. All I need from them is a SPID or a Dest-Group or whatever - = some form of aggregator "key" as you put it, which then gets used in my = local/private next-stage, but I still need the source info to be used in = that next-stage. So are you saying this lookup into private data will be done by a third = party who does not know the source info? =20 If so then does the mechanism look like this?: Originator O wishes to connect to Destination D through Proxy P O gives P some Source Info S that P cannot read or interpret P passes S to D D can interpret S and so responds to P with data based on that Jay >=20 > -hadriel --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From HKaplan@acmepacket.com Wed Mar 31 14:15:53 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF43F3A6AA1 for ; Wed, 31 Mar 2010 14:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbfb4TmsZewf for ; Wed, 31 Mar 2010 14:15:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 737513A689A for ; Wed, 31 Mar 2010 14:15:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 31 Mar 2010 17:16:20 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 31 Mar 2010 17:16:20 -0400 From: Hadriel Kaplan To: E.164 To MetaData BOF discussion list Date: Wed, 31 Mar 2010 17:16:18 -0400 Thread-Topic: E2MD virtual interim meeting Thread-Index: AcrRF2e637CB1MhLR52kAjBOrAXsQQ== Message-ID: <430FC6BDED356B4C8498F634416644A91A79E92E15@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [e2md] E2MD virtual interim meeting X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 21:15:53 -0000 To the BOF chairs: I think email is not a good way to discuss some of this, and is getting in = the way. I propose we have a virtual interim meeting, with slides and voice. And I = can host it (via WebEx) if the IETF cannot. -hadriel From dean.willis@softarmor.com Wed Mar 31 16:31:14 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C4A3A6A95 for ; Wed, 31 Mar 2010 16:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.773 X-Spam-Level: X-Spam-Status: No, score=0.773 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krcrvURvd9ZV for ; Wed, 31 Mar 2010 16:31:13 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4650D3A6A89 for ; Wed, 31 Mar 2010 16:31:13 -0700 (PDT) Received: from [192.168.2.112] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2VNVfPB031095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 31 Mar 2010 18:31:43 -0500 Message-Id: <7946C947-1DDD-4829-B10A-8FD416BAEE27@softarmor.com> From: Dean Willis To: Hadriel Kaplan In-Reply-To: <430FC6BDED356B4C8498F634416644A91A79E92E15@mail> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 31 Mar 2010 18:31:36 -0500 References: <430FC6BDED356B4C8498F634416644A91A79E92E15@mail> X-Mailer: Apple Mail (2.936) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD virtual interim meeting X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 23:31:14 -0000 On Mar 31, 2010, at 4:16 PM, Hadriel Kaplan wrote: > To the BOF chairs: > I think email is not a good way to discuss some of this, and is > getting in the way. > I propose we have a virtual interim meeting, with slides and voice. > And I can host it (via WebEx) if the IETF cannot. > Bad news: There are no "formal interims" for BOFs in the IETF work process (virtual or otherwise), so we can't have an interim BOF. Good news: the E2MD BOF is over (barring sending the final minutes in for the proceedings). What we now have is an IETF discussion (or "interest") list, where we can talk about the E2MD problem, and we can use any kind of discussion format we want. More good news -- I WAS a BOF chair. Now I'm just another dude on the mailing list, albeit with perhaps more of a background on the IETF organizational model than some (and probably less background on ENUM operations than most). Bernie is in the same boat, although he also knows more about ENUM than I do ;-). Any sort (subject to local law) of communication between participants is allowed as far as I know. So a conference call would be OK, with or without slides, and we don't need to meet any IETF rules for advance notice of the meeting, etc. It would be nice of us to take minutes and a participant list and post those to the E2MD mailing list, and we should probably do a "note well" at the beginning of the call. We may wish to appoint a moderator for a call, if we have one. I've found this helps things run a little more smoothly. Looking forward: If we decide to have another BOF with the intention of forming a WG in the future, we can do so -- and we can pick chairs for that BOF when it comes time for it. If we have another BOF, I strongly urge that we have a scope and charter and work plan that will give us a broader consensus in the IETF than our last attempt did. In fact, we might want to come up with what appears to be a completely different mission statement and acronym at that point, just to get decoupled from the controversy surrounding E2MD. -- Dean From dhc2@dcrocker.net Wed Mar 31 16:51:30 2010 Return-Path: X-Original-To: e2md@core3.amsl.com Delivered-To: e2md@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0D23A6991 for ; Wed, 31 Mar 2010 16:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.819 X-Spam-Level: X-Spam-Status: No, score=-4.819 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw74F9ybFvjj for ; Wed, 31 Mar 2010 16:51:29 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 398933A67CC for ; Wed, 31 Mar 2010 16:51:29 -0700 (PDT) Received: from [192.168.1.4] (adsl-67-127-191-90.dsl.pltn13.pacbell.net [67.127.191.90]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o2VNpqX6015806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 16:51:58 -0700 Message-ID: <4BB3E016.50109@dcrocker.net> Date: Wed, 31 Mar 2010 16:51:50 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dean Willis References: <430FC6BDED356B4C8498F634416644A91A79E92E15@mail> <7946C947-1DDD-4829-B10A-8FD416BAEE27@softarmor.com> In-Reply-To: <7946C947-1DDD-4829-B10A-8FD416BAEE27@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10683/Wed Mar 31 15:03:24 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 31 Mar 2010 16:51:58 -0700 (PDT) Cc: "E.164 To MetaData BOF discussion list" Subject: Re: [e2md] E2MD virtual interim meeting X-BeenThere: e2md@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "E.164 To MetaData \(E2MD\) BOF discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 23:51:30 -0000 On 3/31/2010 4:31 PM, Dean Willis wrote: > Bad news: There are no "formal interims" for BOFs in the IETF work > process (virtual or otherwise), so we can't have an interim BOF. > > Good news: the E2MD BOF is over (barring sending the final minutes in > for the proceedings). What we now have is an IETF discussion (or > "interest") list, where we can talk about the E2MD problem, and we can > use any kind of discussion format we want. A group can have any discussion or meeting it wants. The IETF has rules for official activities, not for unofficial ones. It's usually best to focus on deciding what will be the most productive, and then worry about the rules secondarily. > Any sort (subject to local law) of communication between participants is > allowed as far as I know. So a conference call would be OK, with or > without slides, and we don't need to meet any IETF rules for advance > notice of the meeting, etc. It would be nice of us to take minutes and a > participant list and post those to the E2MD mailing list, and we should > probably do a "note well" at the beginning of the call. Exactly right. Follow the discussion and meeting conduct rules of the IETF. Not because the group has to but because they are a well-understood framework for getting useful things done in a transparent manner. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net