Subject: [martini] #16: Extensibility to support any AOR

From: "martini issue tracker" <[email-masked]>
Date: Thu, 18 Mar 2010 22:12:23 -0000

#16: Extensibility to support any AOR
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |       Owner:            
     Type:  enhancement              |      Status:  new       
 Priority:  critical                 |   Milestone:  milestone1
Component:  reqs                     |     Version:  1.0       
 Severity:  In WG Last Call          |    Keywords:            
-------------------------------------+--------------------------------------
 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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/16>
martini <http://tools.ietf.org/martini/>

---

From: Adam Roach <[email-masked]>
Date: Thu, 18 Mar 2010 17:53:09 -0500

Satisfying this requirement would require solving the general case 
before we can declare victory on the phone number case. I think we've 
already come to a pretty strong consensus that we're doing the phone 
number case first, for the sake of expediency.

I would also argue that opening trac bugs to request features that are 
intentionally duplicates (this one duplicates bugs #5 and #6) and 
contrary to apparent working group consensus is an abuse of the trac system.

This should be closed as a duplicate of #6.

/a

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 10:06:09 +0100

Adam,

I disagree, it is different in that it formulates a design goal that the
solution must not inhibit using the same mechanism for non number AOR's. Of
course if that is not clear we could rephrase.

I used TRAC as a guesture to the group where it was expressed to be the tool
of choice for such remarks.
Accusations of bad intent are totally inappropriate.

Best Regards,
/Hans Erik van Elburg

On Thu, Mar 18, 2010 at 11:53 PM, Adam Roach <[email-masked]> wrote:

> Satisfying this requirement would require solving the general case before
> we can declare victory on the phone number case. I think we've already come
> to a pretty strong consensus that we're doing the phone number case first,
> for the sake of expediency.
>
> intentionally duplicates (this one duplicates bugs #5 and #6) and contrary
> to apparent working group consensus is an abuse of the trac system.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Mar 2010 11:54:58 +0100

As editor, I see #16 as being different from #6, so this is acceptable use of the issue tracker.

As individual, I have difficult accepting #16. The group consensus to work on an initial version that addresses the E.164 use case was made in the knowledge that a more general solution would be harder, and probably would need to take a quite different direction (probably not based on REGISTER). In that case I doubt the proposed new requirement REQ20 is achievable without reversing our decision to focus initially on E.164 numbers. Stating requirements that are known to be unachievable will not move the work forward. Therefore my proposal would be to reject this request.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 19 March 2010 09:06
> To: Adam Roach
> Cc: martini issue tracker; [email-masked]; [email-masked]
> Subject: Re: [martini] #16: Extensibility to support any AOR
> 
> Adam,
> 
> I disagree, it is different in that it formulates a design 
> goal that the solution must not inhibit using the same 
> mechanism for non number AOR's. Of course if that is not 
> clear we could rephrase.
> 
> I used TRAC as a guesture to the group where it was expressed 
> to be the tool of choice for such remarks. 
> 	Satisfying this requirement would require solving the 
> general case before we can declare victory on the phone 
> number case. I think we've already come to a pretty strong 
> consensus that we're doing the phone number case first, for 
> the sake of expediency.
> 	
> 	I would also argue that opening trac bugs to request 
> features that are intentionally duplicates (this one 
> duplicates bugs #5 and #6) and contrary to apparent working 
> group consensus is an abuse of the trac system.
> 	
> 		 Reporter:  ietf.hanserik@...          |       Owner:

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 12:30:38 +0100

It is not clear why implicit registration could be equally valid here.

The question is not how such requests reach the SSP, the question is how
given that such requests are handled by the SSP such can be delivered to an
IP-PBX to which they are assigned.

The point is that an SSP may have more complete enterprise offering that
would require calls to be delivered via the SSP cloud to enterprise private
numbers that do not have a DID E.164 number, but which are assigned to a
PBX. Such private numbers are completely under control of the enterprise and
do not require reservation of E.164 for no good reason.

The current solution should not prohibit such service offerings and I
haven't seen a good reason why this should not be covered.

/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 11:54 AM, Elwell, John <
[email-masked]> wrote:

> As individual, I have difficult accepting #16. The group consensus to work
> on an initial version that addresses the E.164 use case was made in the
> knowledge that a more general solution would be harder, and probably would
> need to take a quite different direction (probably not based on REGISTER).
> In that case I doubt the proposed new requirement REQ20 is achievable
> without reversing our decision to focus initially on E.164 numbers. Stating
> requirements that are known to be unachievable will not move the work
> forward. Therefore my proposal would be to reject this request.
>
> John
>

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 19 Mar 2010 11:35:18 -0000

#16: Extensibility to support any AOR
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:            
     Type:  enhancement              |       Status:  closed    
 Priority:  critical                 |    Milestone:  milestone1
Component:  reqs                     |      Version:  1.0       
 Severity:  In WG Last Call          |   Resolution:  duplicate 
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by bernard_aboba@…):

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

Comment:

 This is duplicate of Issue #6.

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

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 12:50:19 +0100

This is not a duplicate. Please justify your action.

BR,
/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 12:35 PM, martini issue tracker <[email-masked]
> wrote:

> Ticket URL: <
> http://trac.tools.ietf.org/wg/martini/trac/ticket/16#comment:1>
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 19 Mar 2010 12:06:13 -0000

#16: Extensibility to support any AOR
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:            
     Type:  enhancement              |       Status:  reopened  
 Priority:  critical                 |    Milestone:  milestone1
Component:  reqs                     |      Version:  1.0       
 Severity:  In WG Last Call          |   Resolution:            
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by bernard_aboba@…):

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

Comment:

 This issue is different from #6 in that it formulates a design goal that
 the solution must not inhibit using the same mechanism for non number
 AOR's.

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