IETF70 ENUM WG session ====================== 1300-1500 Afternoon Session I Salon D/E RAI enum Telephone Number Mapping 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: http://www3.ietf.org/proceedings/07dec/agenda/enum.txt Audio recording: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch5-tue-noon-enum.mp3 (numbers in brackets indicate offset in audio stream) --- meeting opens [10:20] Agenda Bashing [10:40] ====================== lawrence wants to add quick presentation on "unused" if there is time. Current document status [12:00] =============================== Alex Mayrhofer slides: http://www3.ietf.org/proceedings/07dec/slides/enum-2/sld1.htm enum-cnam document: Richard Shockey: Why data URIs deprecated? Jon: URI is used in DDDS for routing to some resource, "data:" was invented to put arbitrary "inline" data into web pages, and general view is to deprecate this. Jim: please document cases in which data: is acceptable Patrik: got discussion of other "opaque" options like "txt" DNS RR. they are too opaque Lawrence: outstanding question on the list from clive, please answer that? conclusion: "data:" is not a "resource identifier" lawrence: "pstndata:" is that different?? RFC3761bis (Scott Bradner) [23:30] ================================== slide: http://www3.ietf.org/proceedings/07dec/slides/enum-0/sld1.htm was asked to update RFC 3761. update boilerplat, translate from "patrik" to english :) looked at the experiences draft - good stuff in there, looking to fold parts of it in. redo security considerations, seems to be a bit of cut & paste Jon: Enumservice registration? Scott: got a few pointers, not much content Lawrence: feel uncomfortable about including registry policies Jon: meant enumservice registration, not DNS registry policies Lawrence: Include privacy issues? Scott: seems not to be much positive to say about? Jon: We had a enum privacy doc, any of that still of use? Richard: probably... Patrik: would be easier to have a current draft of the 3761bis to look at in the first place Patrik thanks Scott for picking up that task! Enumservice Registration [30:00] ================================ Bernie Hoeneisen slides: http://www3.ietf.org/proceedings/07dec/slides/enum-4.pdf draft: http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-06.txt couple of issues today to solve open issues (1,2,3 to be solved today, 4,5,6 later) Issue 1: Which process should be taken? --------------------------------------- Variant A pretty much like it is now, rather heavy, and puts burden on IESG Variant B is what we have currently in the document, kind of new/exotic process, slight preference to go away Variant C - really simple, IESG not in the process, simple and clear, but requires major changes to RFC3761 Variant D out of the question Jon: should use one of the options that is familiar to the IETF. Tends to B, likes C also. A smells like work, which is bad :). please use something that IETF knows. If that guideline doc has all the required info for the expert to decide, then we're done. Richard: if experts don't agree, might it be an option to put it "up" to the IESG? Jon: sure, why not. Scott: asking whether we should rule out IESG? Rule out standards action? Jon: think we needs to rule it out in the majority of the cases, but still keep it as an option? Scott: expert review OR "standard track" track, for example. Scott: look at RFC 2780... Lawrence: if expert review yields comments, should that be in the submission? One shot, or loop? Patrik: Lots of experience with experts review in the IETF Peter: If we redo the registration process, make it properly. Use C. Everything else is micro-management. Missing the publication thing? Bernie: this is on an upcoming slide. Jim: what happens if expert does not respond? Jon: 2434bis - norton draft, we need to follow it. Bernie: We could have both A and C. Patrik: Both A and C are "normal". Scott: Sequence stuff is not your business. just define which process to use. Patrik: seems to tend to A and C, with a reference instead of text (listing chain of names) Hum yields Option C. Patrik: Go and update document with option C. Option C process does not rule out other options. What kind of documentation? --------------------------- How is an Enumservice registration documented? everything from RFC to simple templates. Scott: requiring an RFC would be limiting. Jon: We see lot of requests from other bodies. RFC is too limiting. Conclusion: "specification required" Alex speaking. two smaller issues: Combination of type/subtype and URI scheme ------------------------------------------ Problem: client might select an Enumrecord which it doesn't support, even though there would be another one which is supported. slight personal preference to "B". There might be protocols we can't think of now, so even if we define rules, it could be overridden. Jason: secure/insecure seems irrelevant - objection to B. URI matching subtype would be easier, and most clear. suggests that (Option A). Patrik: dangerous to think just about a certain protocol... Jon: the problem is really the "classification", and what is said here applies to the "protocol" class. for application, it might be "C". We might need different rules for different classes. Lawrence: I understand that all options might be useful. from an implementors perspective, A is a lot easier. uncomfortable with C. Important: "guidelines", not "rules". Peter: If we would choose "B", who defines the "equivalent" uri schemes? Alex: no immediate answer to that. Jon: B won't work in the end. "A" won't work with backwards compatibility, too. Lawrence: only one that would need to be fixed. :-) Richard: Seems to look like if there's a tendency towards "C".. Can we get concensus? Classification into template? ----------------------------- fourth question: put classification information into the template to IANA? 3 more smaller issues: - impact on 3761bis? - IANA considerations - template download? And make the document easier to comprehend :) (Discussion about Enumservice registration concludes) Experimental Registration [70:45] ================================= slides: http://www3.ietf.org/proceedings/07dec/slides/enum-5.pdf draft: http://www.ietf.org/internet-drafts/draft-ietf-enum-x-service-regs-00.txt Patrik: don't see a need for registry at all - email headers doesn't have as well. Jon: Reason is avoidance of collisions. Lawrence: You should for email as well Jon: Ok for experimental, and trial, probably not for private Patrik: remember that we make the actual registration process itself much easier! Richard Shockey: Definition of "private" is not clear. Peter: Don't see the need for a registry Jason: different kinds of "private", keep that out. experimental and trial. Patrik: Goal is only to resolve collision, and provide contact. Jim: description which it actually does would be nice, but not required. hums: remove "private": Yes should have registry for collision avoidance, purpose, etc..: yes require a security analyis? have a "duration"? Patrik: anything that is deployed on the internet is deployed forever. Jim: don't require security analysis, leave it open. Reuse registry? defer that... Trunk Group Enumservice [81:50] =============================== draft: http://www.ietf.org/internet-drafts/draft-shockey-enum-trunkgroup-00.txt Richard Shockey speaks. will be used in private ENUM servers, not likely on the internet. RFC4904 - trunk group in tel URI. Jon: what is trunk? Richard: connection going into a switch. Alex: why not use SIP URI with trunk group parameter? Peter: evaluate against the Enumservice Guide, if accepted as WG item. accepted as WG item VMSG [90:20] ============ slides: http://www3.ietf.org/proceedings/07dec/slides/enum-7/sld1.htm draft: http://www.ietf.org/internet-drafts/draft-ietf-enum-vmsg-01.txt Jason Livingood speaking. two drafts combined (voice / video message) 3 types with several subtypes no comments on the presentation / doc Experiences [94:40] =================== draft: http://www3.tools.ietf.org/html/draft-ietf-enum-experiences-08 slides: http://www3.ietf.org/proceedings/07dec/slides/enum-5.pdf Lawrence Conroy speaking some of it will go into 3761bis. Peter: i see normative language in there, it seems to restrict what the standard allows. fine with operational advice, but restricting standard with normative language? unless it finds its way in 3761bis... otherwise is see contradiction here. Lawrence: not just ENUM, also DDDS Jim: disagree with peter, draft lists mistakes that still comply with the standard. This is not constraining what implementors can do. Patrik: aren't you all saying the same? "The original RFC is unclear?" Lawrence: this is not changing standard, just selecting from the options. Jon: what is left when we take parts out as discussed? Lawrence: Recommendations. Scott: RFC2119 is designed for standards conformance. Richard: both drafts have to undergo major modifications. do those discussions later parts will go into RFC3761bis, remaining parts will stay in this document. Softswitch [111:00] ========== slides: http://www3.ietf.org/proceedings/07dec/slides/enum-6/sld1.htm draft: http://www.ietf.org/internet-drafts/draft-ietf-enum-softswitch-req-01.txt Lawrence Conroy speaking. this is informational. no comments received since about 3 months. WGLC? Will be taken to the list Unused [114:30] =============== slides: http://www3.ietf.org/proceedings/07dec/slides/enum-8/sld1.htm draft: http://tools.ietf.org/id/draft-ietf-enum-unused-01.txt Use "pstndata" instead of "data" URI scheme? now progressing - publication requested meeting concludes.