Minutes of the ENUM WG session at IETF69 ======================================== Mon, 23 Jul 2007, 15:20 - 17:20 Palmer House Hilton, Chicago, IL, USA 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 Session audio recordings: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch5-mon-afnoon.mp3 (note - file is 447M, only the first ~70M required for ENUM session. Time stamps behind headlines indicate time relative to start of recording) Jabber log: http://www3.ietf.org/meetings/ietf-logs/enum/2007-07-23.html Meeting opens [00:20] --------------------- Agenda bashing [01:10] ====================== Richard Shockey proposed agenda at: http://www3.ietf.org/proceedings/07jul/agenda/enum.txt adding infrastructure ENUM to the agenda rfc3761bis clarifications skipped - scott bradner not here agenda accepted [03:10] Draft Overview [04:20] ====================== A. Mayrhofer slides: http://www3.ietf.org/proceedings/07jul/slides/enum-3/sld1.htm background is draft publication, status of drafts is 23rd jul morning. Jon Peterson: IM service is fine, will go forward soon Shockey: posted WGLC on iax document Ed Guy: no comments on that registration received EDNS0: Jon says it won't be difficult to resolve, but takes some time. Jim Reid: join us in the bar. Combined draft [11:20] ====================== Otmar Lendl drafts: http://www.ietf.org/internet-drafts/draft-ietf-enum-combined-07.txt http://www.ietf.org/internet-drafts/draft-ietf-enum-branch-location-record-03.txt slides: http://www3.ietf.org/proceedings/07jul/slides/enum-2/sld1.htm remark on validation-token draft status: some comments on key sizes etc, one remaining DISCUSS to resolve. Reminder: What is that about? Long term / near term solution for infrastructure ENUM. This is about bridging until the long term. original idea to branch off the e164.arpa tree question: where to branch off? CC or NPA? Idea to put branching "meta" information into RRTYPE definition (EBL) testdriving 2929bis - tree walking and location of EBL didn't make them happy also, suggestion to not use labels - that needed an EBL for each use case. comment from Jon on AD evaluation triggered "devil's advocate" investigation on the motivation of the draft by otmar himself. if: we could agree on a label. if: we could position the EBL fixed at CC level. then: apex could be also indicated by a simple DNAME. solution would be possible without EBL, and use DNAME instead. choice between: keep EBL, and go forward, or drop it entirely. Jon Peterson: who did understand this? (about half of the people raised hands). Suggests more information to the group before the group decides. Stastny: For a temporary solution, simple would be better. Rohan Mahy: Fixed branch is fine, makes it simpler, and doesn't trash DNS. Does long term solution need the DNAME too? Shockey: Concerned about DNAME, but much cleaner than original EBL stuff. Stastny: DNAME problem is temporary, too. Jim Reid: Let's go for something really quick. Shockey: +1 exception probably not needed Otmar: easy to define - could be either 1 or 4 digits in +1 Jon: DNS experts here who can comment on DNAME? Ed Lewis: should work if _all_ queries should with no exception should go to the new destination. Semantics pretty well known, CNAME synthesizing. Stastny: If this application of DNAME does not work, what is DNAME then for? Jim: Thinks that DNAME is fine for that purpose.. Marcos: Anything below left hand side cannot be used as a destination for a NS record (because of CNAME syntesizing, and delegations must not point to CNAMEs) Rohan: Are we deciding about the place for the "i" now? Jon: Yes, but in the sense of "behind the country code", not the actual position Hum: Room is in favour of going for the "simple" solution without EBL. Q: seperator? A: "i" is fine with most people. Rohan: Not for us to decide, but let IESG decide? Hum on the string "i": will need to be taken to the list, as like as other things. Enumservices guide [47:30] ========================== Bernie Hoeneisen draft: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-04.txt slides: http://www3.ietf.org/proceedings/07jul/slides/enum-4.pdf Is about a ENUMservice registration template and a guide to fill it out WEITER BEI 48:30... changes from the last version: comments from prague, added text about extending existing services, proposed status now BCP cleaning up security considerations, classification concept extended, some more editorial stuff There are some open issues: classification (up next) process when WG is dormant? Jon raised some issues to be put into next revision IANA impact of document is to be clarified URL for downloading template? Alex Mayrhofer speaks about Enumservice classification: Wide variety of Enumservices registrated, attempt at classification of the Enumservice. First only rough idea, now more "normative" - protocol class - application class - data format class Protocol: Related to single protocol, and to URI scheme of protocol. eg. SIP and XMPP Jon: There are gonna be Enumservices that will have various URI schemes. Alex: Yes, Q is whether more than one URI scheme per subtype is allowed. Jon: Support for protocol can mean support for various URI schemes. Application: Related to an application, can use several protocols and URI schemes. Is a "use case", not a protocol. eg. "web", "mailto", "ft", probably "im" (has "abstract" URI scheme). Data Format: Related to an actual data format, various transport / representation protocols. eg. vCard, CNAM. Jon: categories are good, are the right categories, ENUM is a petri dish for every bizarre relation between addresses, resources, etc., and there might be ENUMservices which don't fit in, but we should do that. It's a tough road. Issue to remember: Does protocol class Enumservice allow more than one URI scheme per Subtype? Process discussion: Bernie speaking: What are the requirements? Will it go into the Enumservices document, or in a seperate doc? Richard Shockey (WG chair hat off): Would like to see it in the document itself. Mark: one document would be IANA's preferences as well. Also, there are many registries in IANA that are managed without WGs. There is a lot of history on that. eg. expert review. categorization would allow to nominate seperate experts. There is also a draft on how to write IANA considerations. Advice is to put process into this document itself. Shockey: IANA will look at the document Jason: Does it only recommend once the WG is no more, or already before? Shockey: Document could supersede the WG in that function. Jim Reid: Would like to have seperate documents, because what happens if you change the process? Shockey: Then change the whole doc? Jim: Within which working group? Jon: some kind of expert together with individual submission - RFC. Guidelines provided by this document. Reason for proposed standard is the overlap between the various things that people want to do. At least the IESG would want to have someone looking at it to find it useful. Up to the group to decide whether letting thousands of flowers bloom, or be conservative. Jim: could be done like RRTYPE. Also, difference between "WG is no more", or "goes to sleep, and does not meet, but still exists". ??: Expert review is quite simple _if_ there are well defined criteria. Option could also be an "object" type process, where an expert shepherds an Enumservice, and if someone objects then more formal review takes place. Shockey: RFC or not? ??: Could be done without, but i understand Jon that he wants some IESG review. Jon: probably enumerate what policies people currently use to decide in similar situations: RRTYPE, etc... Bernie: Proposal how that could be done: - internet draft - announce to mailing list - work on feedback - submit it "somewhere"? - some expert review taking place - then goes forward (IANA, or if to be published RFC to rfc-ed?) examples: RRTYPE, MIME-Type, URI scheme... currently required status for Enumservices is fixed in RFC3761, although we're rewriting that. Otmar: someone needs to be in charge of the process itself (experience from 2929bis). Marc: simple template "before" internet draft is good enough... final action "IESG approval" is not necessary probably. Should only be template unless the final product is going to be published as RFC. Thinks that IESG approval is not neccessarily needed. Need to fix that Enumservice registrations need to be standards track. jim: what to do if expert does not respond or no expert steps forward? Ed Lewis: We need criteria to say yes or no. Peter: WG should choose from what is there (2434bis), and not invent something new, or contribute to 2434bis Otmar: 2929bis uses simple templates. Jason: How to you point implementors to documentation then? Alex: most Enumservice drafts dealt with security considerations, that was the most complicated issue for most services. Most related to privacy considerations. RFC 3761 already contains a really simple template, so if we get around the repeating PII discussion we're essentially done. Jim: Suggest to collect volunteer names for Enumservices experts. Shockey: conclusion: everything combined in one, expert review, need to take to list whether RFC/ID/template should be used. Personal preference to not use RFC. Experimental Enumservice Registration Document is skipped. slides: http://www3.ietf.org/proceedings/07jul/slides/enum-1.pdf draft: http://www.ietf.org/internet-drafts/draft-hoeneisen-enum-x-service-regs-01.txt MGCP Enumservice [92:00] ======================== slides: http://www3.ietf.org/proceedings/07jul/slides/enum-5/sld1.htm draft: http://www.ietf.org/internet-drafts/draft-chenbo-enum-mgcp-01.txt Brian: What is that used for? Mapping of the gateway is local configuration? Some confusion about what the "Call agent" is - looks like a SIP/MGCP gateway Shockey: For a SIP gateway to find an MGCP call control platform? Would make more sense.. Conclusion: needs more work to make the use case clear. Softswitch requirements [105:50] ================================ JoonHyung Lim slides: http://www3.ietf.org/proceedings/07jul/slides/enum-0/sld1.htm draft: http://www.ietf.org/internet-drafts/draft-ietf-enum-softswitch-req-00.txt New co-author Lawrence Conroy. Please report is you do have infrastructure ENUM use cases for this. Otmar: writes out "unwritten" assumptions, worthwhile addition. Jim: Infrastructure trials should contribute to this draft - very useful. conclusion: review that document again, and then move that forward to last calls.. General open mike time ====================== Seems like there will be at least another session of the ENUM working group, probably even more. Meeting concludes - see you in Vancouver.