minutes of ENUM WG session IETF66 ================================= IETF 66 Telephone Number Mapping (ENUM) WG Agenda Preliminary V2 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 MONDAY, July 10, 2006 0800-1800 IETF Registration - Foyer 500D 0800-0900 Continental Breakfast - Foyer 500D 0900-1130 Morning Session I Room 520ABC RAI enum Telephone Number Mapping WG agenda accepted by the group overview of documents in publication queue (Alex Mayrhofer) comment by peter koch: The dnsop working group _does_ care about the doc, but this should be handled in ENUM WG. EDNS0 / Experiences: ==================== draft-ietf-enum-experiences-05 draft-conroy-enum-edns0-02.txt EDNS0: cable guys are looking at and the experiences draft. EDNS0 moving forward to last call by hum of working group. Experiences draft: peter koch: EDNS0 in much better shape than before. experiences draft suffers from claiming not to change standards, but somehow does. considers it confusing. experiences fine, but recommendations? cleanup work belongs into different doc, not experiences. patrick: experiences not moved forward until 3761bis? peter koch: service providers are "sitting" between 3761 and experiences draft. which one should they use? stastny: experiences was intermediate step. we wanted to do a "snapshot", so move forward and start a new version? otherwise we'll never finish it. shockey: appropriate for exp. to make recommendations? Jon? patrik: how to handle those kind of "snapshots"? jon: tactical docs updating 3761?` shockey: not intended to update 3761, but get around certain problems. jon: small updates to 3761 appropriate. Does EDNS0 saying "updates 3761"? shockey: experiences will not update, EDNS0 might. jon: experiences ok, but those small updates should go in seperate docs. paf: seems as if we don't have consensus to got forward. will go with lawrence thorugh experiences draft, what updates, etc. and report to wg. koch: experiences v2 v3 did not address issues raised. problem statements would be fine, but constraining NAPTR etc. ist wrong. WGLC candidates =============== shockey: asking for WGLC consensus on - Enumservices vCard: go ahead - Enumservices im: with add. review - Enumservices calendar: with add. review - Enum validation token: with add. review. CNAM prob. needs one more iteration before going to WGLC jon: concerned about very few voices on those drafts... additional reviewers during WGLC to be appointed. alex: reason for low interest probably because those drafts always the same? shockey: upcoming presentation about Enumservices guide. Enumservices guide ================== discussed in dallas, template and guide. next steps to publish 02 and WGLC. input on IANA recommendation section sought. feedback on type/subtpye (subtype optional). peter: dns considerations section? example: "void". should go to template. jon: alternate registration process than 3761? shockey: should answer "what is the process"? beyond WG existance... shockey: one more revision jon: complicated, but most needed... shockey: deal with "ex-post" process now? jon: trial for "expert review"? Enumservice ERN =============== to be used in infrastructure ENUM. first query i-ENUM, then the namespace indicated. could use URN as well. david oran: agreement for motivation? requirements consensus? schwartz: any method to reduce number of queries welcome newton: good, adding "DNS" uri? haberler: disjoint from federations. stastny: discovery and peering completely seperate. shockey (member): why do DNS? and why "hide numbers"? jean francois mule: how does this meet the reqs of hiding? stastny: stupid carriers are the motivation, mule: not stupid, undereducated. paf: discussion not about ERN, but i-enum reqs instead? shockey: do we need to go back to the reqs document? haberler: we see disintegration of ENUM into private namespaces - this is to fight it. paf: maybe we have a problem with consensus on reqs document? jon: happy to reopen doc, but should be discussed real soon. jim maceachern: take up requirements, and then solve the problem. david schwartz: req simple: carrier dont want open communication, richard proposes sowehow to merge private with public. shockey: maybe we should have a limited group of people to reopen reqs? jim: take to list. david oran: bullet 2 in richard's presentations is not in reqs, so going back to requirements necessary. The following people agree to work on the re-opened requirements doc: paul rikken - pee@erkkila.org jim mceachern - jmce@nortel.com martin dolly - mdolly@att.com david schwartz - david.schwartz@kayote.com adrian georgescu - ag@ag-projects.com carsten schiefner antoin verschuuren philippe fouquart - haberler: specific document? or general paf: general text of just the reqiurements document! agreed - people will work on this over the next few days until white smoke emerges. haberler combined carrier enum ------------------------------ adopted as WG item, as well as corresponding BLR draft. paf: be careful, reqs draft has just been reopened. but good to keep in sync marcos: should this be done in dnsext? paf/shockey: agreement to do it here, but keep in touch of course infrastructure enum ------------------- jason presents the draft. jonathan rosenberg: happy to see the "opaque" record which sort of "hides" the user part? maybe there should be a specific ENUM record for "hostname only" which has no user part? does that work in multi-service environments? jim: "put in: no more information than needed for interconnect" would address privacy concerns RFC3761bis ---------- ticket system (RT) caught a lot of spam. would not do that again with such a system because of this experience. Ticket system lists issues with 3761 presents the idea of "EnumNG", which would be a complete new system, although would not block "backwards compatibility". Would replace "NAPTR" with "URI" records. shockey: seperation user/infra in "EnumNG" would be very simple david schwartz: very good direction, would not even stop there. what if i have two things for same service? one query gives back all? or would multiple queries for multiple services be needed? paf: yes, multiple queries needed (like a vs. aaaa) haberler: nice solution for multiple resolution contexts. for registries just another "output driver" hoeneisen: discussion about infrastructure and user combination missing here? paf: nervous about creating toplevel domains for all things (eg. next mail people will come?) - otoh is telephony special enough to require a seperate domain? peter koch: seperating ENUM from DDDS looks like a good idea - but since ENUM catching up problem of communicating that to existing customers? alex: like this, but there seem to be issues with open numbering plans paf: yes, there are issues with the rewriting as well, because we are removing functionality by removing NAPTR. marcos: likes idea of subtyping using DNS. why choose this, and not the stuff from the iab dns choices doc? paf: wanted to use the "selection" technique of the labels. carsten: consideration about "owner of zone" when splitting zone between user and infrastructure? paf: technically, you can delegate user / infrastructure eg. out to different providers. paf: summing up - not throw "EnumNG" away, but think a bit more. other business -------------- no other business meeting concludes.