ECRIT Agenda ============ * Official ECRIT WG Meeting THURSDAY, March 22, 2007 1510-1610 Afternoon Session II Congress I * 2nd Part of the SIPPING slot on FRIDAY, Congress II, March 23, 2007, namely 1030-1130, will be used for ECRIT as well Agenda: WG Update --------- Chairs * Mapping-arch needs review before we can forward to IESG - anyone who can, please send comments! * Brian - we're about to kick out LoST mechanism, but LoST doesn't describe forest guides, etc. If we don't have a complete solution, between the two documents, LoST isn't going to happen. * Henning - Mapping-arch left syncronization out, hope to talk about that during our meeting * No comments received on proposed milestones, hear silence as consensus in favor * Also need PhoneBCP working group review * Jonathan - March 2007 is, like, days. Can you deploy LoST without mapping-arch? very agressive. Likely LoST will be deployed without mapping-arch, mapping-arch will be more complicated, longer term work - but IESG isn't going to be happy without mapping-arch. * Is there any new work still required? haven't had any new work items in a while. Might recharter for authority-to-citizen work, but that's really new. * Steve Norris - BOF or recharter are the two choices, right? right * Henning - authority-to-citizen isn't emergency like defined in ECRIT, could overlap shutdown and startup * Are other SDOs working on authority-to-citizen? yes * Joint 3GPP/TISPAN-ECRIT call in November, IAB tech chat on ECRIT in February, IEEE/ECRIT joint meeting this week. Will look at each other's documents. * Brian - will resolve comments and draft reply to send to IEEE * 2nd SDO Emergency Service Coordination Workshop meeting in April, focused on citizen-to-authority communication. Good place for collaboration. * ATIS liaison - reviewers needed, need to coordinate review with GEOPRIV LoST: A Location-to-Service Translation Protocol ------------------------------------------------ Henning Schulzrinne http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.txt * Lots of changes, but only one change that generated discussion * couldn't agree on LoST URI, so removed it * No remaining issues except ID-cutoff mistakes, implementations and interop testing in progress, nothing left to do but editorial cleanup until IESG gets the document. Location-to-URL Mapping Architecture and Framework -------------------------------------------------- Henning Schulzrinne http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt * New version is available, resolved all comments to date, no known open issues. * Please review! * Decribes the forest guides and other architrecture concepts * Open issues - role of resolver, caching description (which components and what) * Left to do - some comments, WGLC * Omer - whenever LoST server gets a rquest, tries to figure out where the request came from - is this in LoST or not? * Henning - original source is in there, but isn't modified by intermediate nodes - prefer not to add complexity without use case. Isn't quite the same as Referred-by in HTTP. Don't see how this helps - potential number of referers is huge. * Omer - problem is that forest guide can forward request or redirect it * Henning - trying to avoid adding this if we can help it. Has been a proposal related to this - if you've been redirected, you capture that - it's in the March version, please look at LoST-06 version when available. Best Current Practice for Communications Services in support of Emergency Calling --------------------------------------------------------------- Brian Rosen or James Polk http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-01.txt * Need to split out phone and server parts. * Update depends on reviews arriving - would like to be done by mid-cycle (April) * Need expert reviewers (next two weeks) * James Polk - have gotten zero comments on location conveyance - please check this! * Normative references to L7-LCP document, no way to write the document without them Framework for Emergency Calling in Internet Multimedia ------------------------------------------------------ Brian Rosen or Henning Schulzrinne or Andy Newton or James Polk http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-01.txt No comments Synchronization (Individual draft) --------------------------------- Henning Schulzrinne * There are solutions, but they are proprietary - can't be multi-vendor in your network (for diversity purposes) * Peering - FG-FG, AS-FG, AS-AS * AS push coverage regions "up the tree" to the FG * manually-configured peering, long term value * , * Is usage model entire mappings or delta? Two cases - assume pushing when you have a change, pull at startup, or if you want to ensure that you're still in synch * Open issues - error conditions, update * Brian - startup throttling? * Henning - just a huge file transfer, files really aren't that big * Brian - like work and can use it in half-a-dozen places. Perhaps think about split-update-rejoin * Henning - would be a lot easier if I could assume time synchronization, but I was told to keep this simple. Not YouTube data volumes. * Otmar - pull requests when a mapping expires? pull for an individual identity? * Henning - need to understand when things really disappear - ghosts down hang around forever * Otmar - FG-FG is a problem here, if everyone knows the same thing, there are no FGs... * Henning - may receive objects that you just drop for policy reasons, relying on chained replication (new countries, etc.) isn't handled in current draft. Hope political hotspots happen rarely. * Otmar - how do trust relationships work? your approach may be way too simple. Would NENA allow Austria to influence routing? * Henning - this is like BGP, need to know who is authorized to announce stuff * Brian - data will have conflicts, need a resolution mechanism * Henning - implementer has separate database to notice that someone is announcing your territory * Otmar - need this work, and need to think about the trust relationships * Steve Kent - like BGP? optimistically using the future tense? * Henning - understand completely * Jabber - as long as this doesn't preclude other mechanisms, I'm in favor of it * Otmar - if you store the root, you're done. * Interested in picking this work up (after we talk to the ADs) - humm is in favor of adopting this work