Subject: [e2md] BoF Agenda

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 5 Mar 2010 14:14:22 +0100 (CET)

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 <[email-masked]>
Last Modified: 2010-03-05

BOF CHAIRS:

    Bernie Hoeneisen <[email-masked]>
    Dean Willis <[email-masked]>

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: Dean Willis <[email-masked]>
Date: Fri, 5 Mar 2010 14:59:12 -0600

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" <[email-masked]>
Date: Fri, 5 Mar 2010 16:26:08 -0500

inline

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

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

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.

Text string? CNAM=William Tecumseh Sherman;SPID=A45BB21 

I'm open minded here

--
Dean
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md