1. MARTINI WG Interim 2010-04-29 draft-ietf-martini-reqs-04 John Elwell Hadriel Kaplan (editors)

2. Current status draft-ietf-martini-reqs-04 posted 2010-04- 26 1 remaining open issue (#39) Issues #15 and #16 closed but still being discussed on list

3. Issue #39 Explanatory text in section 1 Was added as a result of agreement during IETF#77 Since then, the olive draft has appeared, so the question is whether the text would be more appropriate in olive, say

4. Issues #15 and #16 #15 – support for non-E.164 numbers –Proposes to add REQ19 - The mechanism MUST allow a set of assigned telephone numbers to comprise local numbers as specified in RFC3966, which can be in contiguous ranges, discrete, or in any combination of the twoRFC3966 #16 – extensibility to support any AOR –Proposes to add REQ20 - The mechanism MUST be extensible to allow a set of arbitrary assigned SIP URI's as specified in RFC3261, without requiring a complete change of mechanism as compared to that used for numbers.RFC3261 Both are being discussed in context of olive Charter states: The solution will support AoRs with E.164 addresses at a minimum, although support for other classes of AoRs may be included.

5. Issues #15 and #16 – ways forward 1.Do nothing (do not include requirements based on proposals in #15 and #16) –We lose known requirements for phase 2 2.Adopt #15 and #16 as they stand –We know phase 1 will have difficulty meeting #15 and #16 in full, so we have to justify it in the phase 1 solution document, rather than dealing with it at the requirements stage 3.Adopt #15 and #16 as desirables 4.Restructure the requirements document into phase 1 and phase 2 requirements –Involves more work –Are we really in a position to identify ALL phase 2 requirements yet? 5.Add preamble about eventually finding solutions to all requirements, but not anticipating that a single solution will satisfy all –All requirements would then be watered down by this statement