Subject: [Enum] preliminary notes from the WG meeting in Philidelphia ..

From: "Richard Shockey" <[email-masked]>
Date: Mon, 17 Mar 2008 14:37:17 -0400

Actually thanks to Jason for taking the notes here ...

If there is anyting we left out here let us know.

IETF 71 
ENUM WG Notes
03/13/2008
15:10 hrs

1 - Scott Bradner and Lawrence Conroy present 3761-bis update
- Document looks done
- WG chairs and authors have indicated that WGLC will be issued next week
(week of 17 March)
- one minor issue to correct in draft was the IANA considerations.

2 - Alex Mayrhofer presents update on all ENUM WG drafts in queue

A - Unused draft discussion:
- Some discussion of draft-ietf-enum-unused was declared as DEAD.
- Hadriel Kaplan, and Rohan Mahy objected to this dropping solely because
the editor has retired.
- Lawrence Conroy mentioned several AD objections
- Jon Peterson (AD) noted that many concerns have been raised on this I-D
over time.  He suggested Lawrence make a few changes, that he felt could
enable the draft to progress.
- Lawrence will FOLLOW UP and publish Jon's comments / suggestions on the WG
list.  One was related to the data URI, which Jon has STRONG objections to.
Jon believes there are valid alternatives to the data URI, and he thinks
with those changes it could progress
- Hadriel Kaplan strongly objects top dropping the draft.
- Rohan Mahy agrees that the use of data URI is inappropriate, but he
believes there are alternatives, as this draft is important, and that we
should find a new editor that could move this draft along.
- Lawrence Conroy suggests that any new editor be young, as this could take
forever.
- Rich Shockey will go to the list and declare the draft 'abandoned' and ask
the WG if anyone wishes to take over the draft as editor.
- Hadriel Kaplan has volunteered to take over the draft, and the chairs
accepted happily.
- Jon Peterson read out the WG charter and feels that the milestones are a
couple of years in the past, and he suggests that the chairs may wish to
update their milestones.  And 'please do tell me what we're doing here' so
the WG needs to clarify the charter text as well.

B - Infrastructure draft discussion:
- Jon Peterson said he thinks that the draft will go to last call before
IETF 72.  It has been held up for an external review of the document, but he
feels it is about to move ahead.

C - EDNS0 draft discussion:
- Alex said the draft is waiting for a new revision, and this was indicated
to be imminent.

D - CNAM draft discussion:
- Alex said the draft is waiting for a new revision, and this was indicated
to be imminent.

E - IAX draft discussion:
- Alex said draft is expired, and Ed Guy (editor) said it will be updated
shortly, which will renew the draft.

F - Calendar draft discussion:
- Rohan Mahy indicated that Alex Mayrhofer contacted him to add some things
to the draft. 
- Rohan got some new sub-type suggestions while in IESG review, in order to
have one URI for accessing a calendar and one URI for scheduling a new
calendar item.
- Rohan will post the sub-types he is thinking of on the WG list, but no
objections raised in the meeting room.

G - Document Flowchart shown by Alex, which demonstrated the linkages
between 3761bis, x-services, enumservices guide, experiences.
- Jon Peterson said that the enumservices guide can move ahead independently
of 3761bis and experiences.

3 - Alex Mayrhofer presents update on ENUMservice Guide
- Many changes since IETF 70
- Is no longer a guide and template, now actually specifies the IANA
registry, registration procedures, guidelines.
- 3761 no longer contains the registry guide.
- New registration process, which is easier and simpler than before. Based
pn expert review, in combination with specification required.  This is based
on RFC2434bis process, plus flowchart for feedback collection.
- All registration specs moved from 3761bis, such as IANA registry
specification, and IANA registration template
- Classifications are: Protocol, Application, Data Format.  Class would be
listed in the registration template, but it is okay to have a NULL class.
- URI scheme and sub-type relations were explained a bit, as there are some
changes here.

- Alex asked the WG whether 'Intended Usage' is really of use to the
registration.
- Jon Peterson felt that drafts like the PSTN draft might be designated as
LIMITED USE, so he feels that we may want to look back through the registray
and pick registrations out that are limited use and designate them as such.
This is also an arguement for keeping this Intended Usage field.

- Alex also indicated that the 'Name' field is not really used or defined.
3 options: (1) leave it unspecified, which is preferred by Alex, (2) specify
further, or (3) remove it from the registration template.
- Jon Peterson says: either specify what this is, or remove it. 
- Jon Peterson asked the room if anyone felt it was needed, and no one spoke
up.  Thus, he recommended its removal.  But he asked that we evaluate the
existing registry and determine what would have to be removed from previous
registrations.

- Alex also raised the issue of how to publish the registration documents
themselves.  
- Jon Peterson suggested that it should be either a RFC or a published,
stable public document.
- Peter Koch suggested that other standards bodies could publish such
documents. He suggested 'specification required.'
- Scott Bradner suggested that if it was not a RFC, that the reference to
the document should include a reference to a specific revision.
- Lawrence Conroy suggested that within IETF this would mean it would need
to be a RFC, and Scott Bradner agreed with this statement.

- Some discussion between Alex, Scott Bradner, and Rich Shockey: Once the
registration document has been completed and RFC published that expert
review can obsolete previous or other registrations, and this needs to be
specified in the new revision of the draft.  ((IS THIS CORRECT??))

- Alex closed by mentioning that there is an online issue tracker for this
document.

4 - Rich Shockey discussed the potential use of a 'p flag' with the group
and asked if it was a good idea.
- Jack Burton asked if you queried 
- Bob Moscowitz said he runs extensive ENUM zones internally, which have
some views of external data, and he does not think it is needed.
- Lawrence Conroy said this is basically 'leakage control' and he said that
if you are on the global internet and you get a record with a p-flag, it
indicates a leakage and it should be ignored.
- Rich said he'll take this issue to the WG mailing list.
- Peter Koch suggested that the text would need to be reworded, but the
intent seems good.  He will also help write this text with Rich Shockey and
Lawrence Conroy.
- Jon Peterson asked if this would hold up the enumservices guide until this
question is resolved.
- Lawrence Conroy things it would not hold up the guide, that text would
need to go into 3761bis.
- Jon Peterson would like to see a concrete proposal before he says if this
is crazy or not.
- Patrik Falstrom indicated that there should be use and mis-use cases
(failure or leakage cases) described clearly.
- Tom Creighton raised a question that the normative language is not
specified on this proposal, and should be described when this is proposed
more formally on the list.

5 - Presentation by Olafur Gudmundsson, DNSext WG Chairman 
- EDNS0 specs are being revised now, target is to move to draft standard.
- That WG is discussing whether ENDS0 support should be mandated, and
whether the minimum buffer size should be specified.  Please get onto the
DNSext WG list and discuss if you have an opinion.

6 - Presentation by Hadriel Kaplan regarding Private ENUM real-world use.
- He is suggesting a problem statement that these mechanisms are missing
source-based queries.
- This is not a public ENUM issue, but a private one.
- Proposed solution is to use EDNS0 to define a OPT-RR.
- The mailing list has suggested other things like LDAP, SQL, and other
mechanisms.  But Hadriel said there are big reasons why this is not the
case, such as the speed of DNS, efficiency, low cost, easy distribution of
data, etc.
- One speaker (??) suggested that he supported this draft.
- Lawrence Conroy questioned what WG this should be in, and that ENUM WG may
not be appropriate.  He suggested DNSops or DNSext as potential options,
since the applications could be more broad that ENUM.
- Jean-Francois Mule said that he felt high-level requirements are needed in
this draft.  He does not understand the problem or the solution.
- Peter Koch expressed a strong opinion that this work should be in a
different WG, not in ENUM.  He felt DNSext was the right WG.
- Scott Bradner said that there is a party, Verizon, that has a related
patent, and we should be careful.
- Tim Dewhite from Verizon said that he felt this was useful to do local vs.
toll lookups.
- Co-Chairs cut-off discussion for time reasons.  Rich indicated that
another revision is necessary and there will be more discussion on the list.
- Jon Peterson agreed with Jean-Francois Mule that there needs to be a
better description of the problem and the solution.
- Patrick Falstrom also suggested that Hadriel work closely with the DNSext
folks for their input.

///////////////////  OFFICIAL AGENDA BELOW ///////////////////

IETF 71 Telephone Number Mapping (ENUM) WG Agenda 

THURSDAY, March 13, 2008 

1510-1610 Afternoon Session II
Franklin 3/4	INT	savi	Source Address Validation Improvements BOF
Franklin 11/12	RAI	avt	Audio/Video Transport WG
Franklin 6/7	RAI	enum	Telephone Number Mapping WG
Salon I	SEC	smime	S/MIME Mail Security WG

Chair(s):
Patrik Faltstrom <[email-masked]> 
Richard Shockey <[email-masked]>

WG Secretary:
Alexander Mayrhofer <[email-masked]> 

RAI Director(s):
Jon Peterson [email-masked]
Cullen Jennings [email-masked]

RAI Area Advisor:
Jon Peterson [email-masked]

Agenda Bashing.

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 18 Mar 2008 10:45:02 +0000

> A - Unused draft discussion:
[...]

> - Rohan Mahy agrees that the use of data URI is inappropriate,

Are these objections to the data URI documented anywhere? As far as I can
see, it's the right thing to use for a whole slew of stuff including this.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 18 Mar 2008 11:48:20 -0400

I had the same problem with the CNAM draft ..the word from on high is that
they don't want us to use data: but specific URI's.  We are just doing what
we are told. IMHO its similar to the issues with TXT in RR ..its just become
a junk pile for anyone trying to do anything.

>  -----Original Message-----
>  From: Clive D.W. Feather [mailto:[email-masked]]
>  Sent: Tuesday, March 18, 2008 6:45 AM
>  To: Richard Shockey
>  Cc: [email-masked]
>  Subject: Re: [Enum] preliminary notes from the WG meeting in
>  Philidelphia ..
>  
>  Richard Shockey said:

---

From: [email-masked]
Date: Tue, 18 Mar 2008 16:43:36 +0000

> a junk pile for anyone trying to do anything.

I have a potential draft to be co-authored with Clive to formally document 
an ENUM (sub-)service-type and NAPTR record that is to be used in the UK's 
number portability database.

It's currently represented as a (very) short data: URI, containing either 
one or two short numbers, i.e. data:,1 or data:,8-10.  The information 
therein is meta-information about the ENUM tree.

Like Clive, I agree that the data: URI format is perfect for this.  I've 
looked at the currently registered URI schemes and there's nothing else 
suitable.  A previous version of the specification held the information in 
a TXT record but this was discarded in favour of NAPTR records to ensure 
that a single DNS query with QTYPE=NAPTR could return both meta-data and 
real data.

Jon - are we supposed to invent a new URI scheme to represent this?   FWIW 
- there are UK Neustar people involved with this particular project too.

cheers,

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Mar 2008 14:28:31 -0400

Howdy,
Inline...

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Shockey
>

That was not my recollection of his comments.  I remember him saying that he saw a need for this, based on Speermint.

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 18 Mar 2008 21:42:53 -0400

In line ... as I mentioned before I had the same problem of using the DATA:
uri scheme in my CNAM drafts.

You do not want to know the time and effort I went through to understand
that the use of DATA: would not happen. 

The only solution is another URI type which, for lack of anything better, we
are going to call PSTNDATA:  I have already socialized the general scheme
with the powers that be and there seems to be no general objection to a new
URI type for the specific purpose of general pstn data types in conjunction
with the correct ENUM service registration etc.

This IMHO is the way to go forward on these issues. My personal advice would
be to revise your drafts accordingly.

>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of [email-masked]
>  Sent: Tuesday, March 18, 2008 12:44 PM
>  To: Richard Shockey
>  Cc: [email-masked]; 'Clive D.W. Feather'
>  > I had the same problem with the CNAM draft ..the word from on high
>  is
>  that
>  > they don't want us to use data: but specific URI's.  We are just
>  doing
>  what
>  > we are told. IMHO its similar to the issues with TXT in RR ..its
>  just
>  become

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 18 Mar 2008 22:26:10 -0400

FYI ..this is what I have so far ..you can obviously suggest another data
type.

Comments are welcome 

**********************

IANA Registration Template for URI "pstndata:" 

  URI scheme name.

     The name of the URI is "pstndata:".

   Status.

  The intended status is Permanent.  NOTE: The distribution of CNAM data is
often highly restricted. Usage of this URI should either be within

  a service providers internal network, or on a private basis between one or
more parties using a variety of security mechanisms to prevent

  general public access. The records described herein should not be part of
the e164.arpa or any other portion of the DNS tree.

  URI scheme syntax.

    pstndatauri  = "pstndata:" datatype ["/" telephone-subscriber ] ";"

              (content / reason)

    datatype     = "cnam"

                 ; Other datatypes can be defined by adding

                 alternative values.

    content      = [ mediatype ] [ ":base64" ] "," data

    mediatype    = [ type "/" subtype ] *( ";" parameter )

    data         = *urlchar

    parameter    = attribute "=" value

    reason       = "available=" ("p" / "u")

  where "telephone-subscriber" is imported from RFC 3966 [19], "urlchar" is
imported from RFC 2396 [20], and "attribute" and "value"

  are imported from RFC 2045 [21].

  URI scheme semantics.

    Two optional parameters are defined.

  a) Calling Name Privacy Indicator: 'available=p'  

  This parameter defined as the Calling Name information may be available
but the Calling Party does not wish to have their Calling

  Name data displayed by Called Party User Agents. 

  Intended usage: 'available=p'

  b) Calling Name Status Indicator: 'available=u' 

  This parameter is defined as there is no Calling Name data for that  E.164
number available.

  Intended usage: 'unavailable=u'

  Encoding considerations.

  The purpose of this URI is to enable service providers to place   Calling
Name Delivery information (CNAM) into RFC 3761 [ENUM]  databases or to send
ENUM queries to a protocol converter that would  have access to the
Signaling System 7 (SS7) Network.  This, in turn, could enable such parties
to offer Calling Name Delivery services  using the technology provided by
RFC 3761.

  The information stored in these databases can be encoded to  facilitate
storage and retrieval operations.  The type of encoding used is identified
using appropriate media type parameters.  If not  otherwise identified,
character data is presumed to be encoded using

  US-ASCII [9].

  Applications and/or protocols that use this URI scheme name.

  This URI scheme is intended for use in RFC 3761 [ENUM] databases.

  Interoperability considerations.

  The URI is designed to be used specifically in conjunction with trusted
systems that utilize the RFC 3761 [ENUM] databases. 

  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 [A]
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.

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 19 Mar 2008 10:11:02 +0100

Hadriel Kaplan wrote:

>> - Jean-Francois Mule said that he felt high-level requirements are needed
>> in this draft.  He does not understand the problem or the solution.
> 

IMHO this derives from 
http://tools.ietf.org/html/draft-ietf-speermint-requirements-04

  o  Requirement #4:
       The mechanisms recommended for the declaration or advertisement of
       SBE and DBE entities must allow for peer and media variability.

/ol