Subject: Re: [martini] #15: support for non E.164 numbers

From: "martini issue tracker" <[email-masked]>
Date: Mon, 26 Apr 2010 08:24:12 -0000

#15: support for non E.164 numbers
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:            
     Type:  defect                   |       Status:  closed    
 Priority:  critical                 |    Milestone:  milestone1
Component:  reqs                     |      Version:  1.0       
 Severity:  In WG Last Call          |   Resolution:  wontfix   
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by john.elwell@…):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 This is being discussed in the context of the olive draft. In addition,
 there was agreement at IETF#77 to add text explaining the limitations,
 which was done in -03.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/15#comment:1>
martini <http://tools.ietf.org/martini/>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 26 Apr 2010 20:38:17 +0200

Indeed this is being partly addressed in the olive draft, which shows
that there is a need for this.

Therefore please incorporate the requirement as was proposed in the
original ticket.

/Hans Erik van Elburg

On Mon, Apr 26, 2010 at 10:24 AM, martini issue tracker
<[email-masked]> wrote:
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 26 Apr 2010 20:40:35 +0200

Forgot to say that I do not agree with that it is being closed. Please reopen.

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Apr 2010 21:25:05 +0200

For both #15 and #16, the issue is where to document requirements for subsequent deliverables, given that, in accordance with an agreement many weeks ago, initial deliverables are limited to E.164-based AORs. Other forms of AOR are being considered in the context of the olive draft, but I am not sure whether requirements need to go into the present requirements draft, and if so how to segregate them. Perhaps chair guidance on this would be appropriate.

John 

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 26 April 2010 19:38
> To: martini issue tracker
> Cc: Elwell, John; [email-masked]
> Subject: Re: [martini] #15: support for non E.164 numbers
> 
> >  Reporter:  ietf.hanserik@.          |        Owner:
> > Changes (by john.elwell@.):
> >
> >  * status:  new => closed
> >  * resolution:  => wontfix
> >
> >
> > Comment:
> >
> > Ticket URL: 
> <http://trac.tools.ietf.org/wg/martini/trac/ticket/15#comment:1>

---

From: <[email-masked]>
Date: Tue, 27 Apr 2010 08:51:58 +0200

Whatever is supported by the gin draft should not change the requirements. The industry does have a requirement to support other forms of identities than just E.164. Therefore I believe #15 and #16 should be incorporated in the requirements draft.
BC

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Elwell, John
> Envoyé : lundi 26 avril 2010 21:25
> À : Hans Erik van Elburg; martini issue tracker
> Cc : [email-masked]
> Objet : [martini] #15 and #16 (was RE: #15: support for non 
> E.164 numbers)
> 
> For both #15 and #16, the issue is where to document 
> requirements for subsequent deliverables, given that, in 
> accordance with an agreement many weeks ago, initial 
> deliverables are limited to E.164-based AORs. Other forms of 
> AOR are being considered in the context of the olive draft, 
> but I am not sure whether requirements need to go into the 
> present requirements draft, and if so how to segregate them. 
> Perhaps chair guidance on this would be appropriate.
> 
> John 
>

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Tue, 27 Apr 2010 04:49:25 -0400

Requirements 15/16 should remain.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 27 Apr 2010 10:59:16 +0200

Bruno,

The MARTINI charter says "The solution will support AoRs with E.164
addresses at a minimum, although support for other classes of AoRs may
be included." I think the req-04 draft reflects that well.

John

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 27 April 2010 07:52
> To: Elwell, John; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [martini] #15 and #16 (was RE: #15: support for 
> non E.164 numbers)
> 
> Whatever is supported by the gin draft should not change the 
> requirements. The industry does have a requirement to support 
> other forms of identities than just E.164. Therefore I 
> believe #15 and #16 should be incorporated in the requirements draft.
> BC
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Apr 2010 13:09:04 -0500

On Apr 27, 2010, at 1:51 AM, <[email-masked]> <[email-masked] 
 > wrote:

> requirements. The industry does have a requirement to support other  
> forms of identities than just E.164. Therefore I believe #15 and #16  
> should be incorporated in the requirements draft.

Is this requirements draft supposed to cover just phase 1, or  
everything the MARTINI group plans to do over its lifetime?

If the former, then we risk stalling the work because the first-gen  
solutions drafts don't (and aren't meant to) meet every possible  
requirement.

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 27 Apr 2010 17:04:51 -0500

After chatting with my co-chair...

Bernard and I are sympathetic to these requirements.

We don't want to cycle on closing/reopening them.

We are seeing people doing analysis for these requirements (see OLIVE, as a 
start).

We don't want to stall on delivering a solution that meets the scope we were 
chartered for, because we accepted these as requirements.

We propose that we accept both #15 and #16 for Section 5, "Desireables".

There is no penalty for delivering a solution that provides this support.

Please feel free to express opinions about this, of course.

Spencer, as co-chair

----- Original Message ----- 
From: "Elwell, John" <[email-masked]>
To: "Hans Erik van Elburg" <[email-masked]>; "martini issue 
tracker" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 26, 2010 2:25 PM
Subject: [martini] #15 and #16 (was RE: #15: support for non E.164 numbers)

For both #15 and #16, the issue is where to document requirements for 
subsequent deliverables, given that, in accordance with an agreement many 
weeks ago, initial deliverables are limited to E.164-based AORs. Other forms 
of AOR are being considered in the context of the olive draft, but I am not 
sure whether requirements need to go into the present requirements draft, 
and if so how to segregate them. Perhaps chair guidance on this would be 
appropriate.

John

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Apr 2010 19:47:07 -0500

On Apr 27, 2010, at 5:04 PM, Spencer Dawkins wrote:

> We are seeing people doing analysis for these requirements (see  
> OLIVE, as a start).
>
> We don't want to stall on delivering a solution that meets the scope  
> we were chartered for, because we accepted these as requirements.
>

That works for documentary purposes, but I'd like to see somewhere a  
commitment to getting the things done "at some point" that GIN doesn't  
do. Olive is a good start, of course; it shows that we know that there  
is more work to do and are working on in a reasonable incremental  
fashion.

The cleanest solution would probably be to structure the requirements  
into phases inside the actual requirements draft. That's also a pretty  
heavy solution.

Another approach would be to add a preamble to the requirements that  
says something about eventually finding solutions to all the  
requirements but not anticipating that a single mechanism or draft is  
likely to solve everything.  With this route, we could keep 15 and 16  
"in place" as requirements, but be able to advance a draft like Gin  
without somebody saying "You can't advance this draft, it doesn't meet  
all the requirements in the requirements draft!" This approach lets  
next-step drafts refer back to the requirements with something like  
"This draft addresses Requirements 15 and 16, which were not addressed  
by draft-gin..."

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 22:36:53 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dean Willis
> Sent: Tuesday, April 27, 2010 8:47 PM
> 

I agree, but I think the "commitment" is simply the interest of the group.  If there is interest, we keep working; if there isn't, we don't. 

> into phases inside the actual requirements draft. That's also a pretty

Isn't that what charters are for?  We make changes the charters to add new goals, with milestones, etc.  

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 22:41:09 -0400

+1.
#15 and #16 seem like good desireables to me, and I think Hans Erik's proposed language captures that.

-hadriel

> Of Spencer Dawkins
> Sent: Tuesday, April 27, 2010 6:05 PM
> To: Elwell, John; Hans Erik van Elburg
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Apr 2010 10:11:47 +0200

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 28 April 2010 01:47
> To: Spencer Dawkins
> Cc: Elwell, John; Hans Erik van Elburg; [email-masked]
> Subject: Re: [martini] #15 and #16 (was RE: #15: support for 
> non E.164 numbers)
> 
> 
[JRE] Also the inclusion of requirements for a second phase, populated by #15 and #16, would seem to imply we already know the total set of additional requirements for the second phase. When we come to work on the second phase, there might be more requirements we haven't yet thought of (perhaps arising from implementation experience with phase 1). So I believe we should state phase 2 requirements when we are ready to start work on phase 2. I prefer the chairs' proposal of introducing #15 and #16 as desirables.

> "This draft addresses Requirements 15 and 16, which were not 
[JRE] The problem with this approach is that the vagueness introduced by such a preamble would extend to all requirements, not just #15 and #16.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 28 Apr 2010 14:19:35 +0200

On Wed, Apr 28, 2010 at 2:47 AM, Dean Willis <[email-masked]> wrote:
> Another approach would be to add a preamble to the requirements that says
> something about eventually finding solutions to all the requirements but not
> anticipating that a single mechanism or draft is likely to solve everything.
>  With this route, we could keep 15 and 16 "in place" as requirements, but be
> able to advance a draft like Gin without somebody saying "You can't advance
> this draft, it doesn't meet all the requirements in the requirements draft!"
> This approach lets next-step drafts refer back to the requirements with
> something like "This draft addresses Requirements 15 and 16, which were not
> addressed by draft-gin..."
>

I do think that would be a good approach. The intention is not to
stall work on GIN, but recognise that these are important requirements
that martini would need to solve before disolving the wg.

BR,
/Hans Erik

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 30 Apr 2010 15:03:34 -0000

#15: support for non E.164 numbers
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:            
     Type:  defect                   |       Status:  reopened  
 Priority:  critical                 |    Milestone:  milestone1
Component:  reqs                     |      Version:  1.0       
 Severity:  In WG Last Call          |   Resolution:            
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by john.elwell@…):

  * status:  closed => reopened
  * resolution:  wontfix =>

Comment:

 Reopened due to ongoing discussion on the list. Discussion during the
 MARTINI interim meeting 2010-04-29 revealed support for accepting this
 change with rewording along the lines of "The mechanism MUST be extensible
 to allow..." (i.e. similar to ticket #16). If there are no objections I
 will close this as 'fixed' (subject to that wording change).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/15#comment:2>
martini <http://tools.ietf.org/martini/>