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. http://tools.ietf.org/html/draft-ietf-speermint-requirements-04 - 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. High level requirements based on SPEERMINT. - Scott Bradner said that there is a party, Verizon, that has a related patent, and we should be careful. - Tim Dwight 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. Further comments from Tim Dwight: 1) to confirm that the use case Hadriel had in mind (in proposing to include the calling party number in the Infrastructure ENUM query) was to allow the I-ENUM server to perform local vs. toll analysis (in other words, to determine whether calling and called party numbers are associated with the same rate center, in which case this is a local call). Presumably the I-ENUM server would return a different result for local calls than for toll calls. Hadriel confirmed that this was the intent. 2) to note that an equally compelling use case will be to include "where the query came from" (e.g., from what operator), again so that different results can be returned for the same telephone number, based on who sent the query. Some systems allow this today based on the source IP in the ENUM query, but this may not work in practice - usually the query has to come through a border element (e.g., SBC) so the source IP identifies your own border element, not the device that initiated the query. - 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.[ NOTE: CLARIFICATION: That was not my recollection of his comments. I remember him saying that he saw a need for this, based on Speermint. NOtes from mailing list: Clive Feather: 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. Rich Shockey: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. /////////////////// 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 Richard Shockey WG Secretary: Alexander Mayrhofer RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com RAI Area Advisor: Jon Peterson jon.peterson@neustar.biz Agenda Bashing. 1. Status of Drafts and in Drafts the Queue Overview - Alexander Mayhofer WG Secretary 10 2. Title : The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) Author(s) : S. Bradner, et al. Filename : draft-ietf-enum-3761bis-02.txt Pages : 20 Date : 2008-02-13 This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-3761bis-02.txt 3. Title : IANA Registration of Enumservices: Guide, Template and IANA Considerations Author(s) : B. Hoeneisen, et al. Filename : draft-ietf-enum-enumservices-guide-07.txt Pages : 36 Date : 2008-02-25 This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents. Registration of Enumservices is now handled using the "Expert Review" process. A Registration Document containing the specification of the Enumservice is required. However, contrary to earlier registration procedures, said Registration Document does not necessarily need to be promoted to RFC status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-07.txt 4. Title : DNS Extension for ENUM Source-URI Author(s) : H. Kaplan, et al. Filename : draft-kaplan-enum-source-uri-00.txt Pages : 8 Date : 2007-12-11 This document defines a specific DNS extension, based on the EDNS0 OPT RR, for an ENUM query to include the source URI which caused the ENUM request. This is useful, for example, to specify the originating SIP or TEL URI from a SIP request which triggered the ENUM query, so the ENUM server can provide a different response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt