MARTINI WG Interim2010-04-29

draft-ietf-martini-reqs-04John Elwell

Hadriel Kaplan (editors)

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

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

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 two”

• #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.”

• 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.”

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 22. 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 desirables4. 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