Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue

From: "martini issue tracker" <[email-masked]>
Date: Mon, 19 Apr 2010 08:01:05 -0000

#20: Section 3.1.2 does not decscribe an issue
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:  john.elwell@…                     
     Type:  defect                   |       Status:  reopened                          
 Priority:  minor                    |    Milestone:  milestone1                        
Component:  reqs                     |      Version:  1.0                               
 Severity:  In WG Last Call          |   Resolution:                                    
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by ietf.hanserik@…):

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

Comment:

 There is no agreement if the issue described in the document is really an
 issue, therefore we keep the issue. ???? I would rather say, it is better
 to remove the issue from the requirements document in that case,
 especially as no requirement has been derived from it.

 Replying to [comment:2 john.elwell@…]:
 > We don't seem to have any consensus to make a change, so closing.

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

---

From: "martini issue tracker" <[email-masked]>
Date: Tue, 20 Apr 2010 10:41:38 -0000

#20: Section 3.1.2 does not decscribe an issue
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:  john.elwell@…                     
     Type:  defect                   |       Status:  new                               
 Priority:  minor                    |    Milestone:  milestone1                        
Component:  reqs                     |      Version:  1.0                               
 Severity:  In WG Last Call          |   Resolution:                                    
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by john.elwell@…):

  * status:  reopened => new

Comment:

 The present text of 3.1.2 states "There is no defined behavior for the
 SIP-PBX if the PAU header field's list of URIs does not match what the
 SIP-PBX expects it to be.  It is not clear if the SIP-PBX should de-
 register, re-register, or ignore the difference; nor is there a way for
 the SIP-PBX to indicate the error in signaling."

 I think this is missing some context. I would propose that we insert text
 at the start of 3.1.2 stating: "Some current implementations return a list
 of registered AORs in the response, by inclusion of the P-Associated-URI
 header field."

 Concerning Hans Erik's assertion that no requirement has been derived from
 this, should we add a requirement along the lines of "REQxx - Any solution
 involving transmitting a list of registered AORs from SIP-PBX to SSP or
 vice versa MUST define procedures for dealing with the case where the
 received list does not match expectations."?

 Note that since gin does not transmit such a list, it does not fail this
 requirement.

 John

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/20#comment:4>
martini <http://tools.ietf.org/martini/>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Tue, 20 Apr 2010 13:38:46 +0200

Hi John,

My point was not that we need to derive a requirement, my point was
that it is not an issue and does  therefore not be listed/described as
an issue ;-)

The main reason that P-Associated-URI is used in the ETSI/3GPP
solution is to provide the P-CSCF (edge proxy) with information about
explicitly and implicitly registered AORs, which allows this edge
proxy to perform its policies regarding P-Preferred-Identity,
P-Asserted-Identity and P-Served-User handling. It was IMHO not ment
for any special processing by the PBX.

BR,
/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Apr 2010 10:37:10 +0200

I would like to seek Hadriel's opinion on this, because he provided the text for this section.

John 

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email-masked]] 
> Sent: 20 April 2010 12:39
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [martini] #20: Section 3.1.2 does not decscribe an issue
> 
> Hi John,
> 
> >  Reporter:  ietf.hanserik@.          |        Owner:  john.elwell@.
> > Changes (by john.elwell@.):
> >
> > Ticket URL: 
> <https://wiki.tools.ietf.org/wg/martini/trac/ticket/20#comment:4>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Apr 2010 10:55:11 -0400

Right, no debate it wasn't intended for PBX's in 3gpp's usage of it.  As far as I know, it's mostly used today by middleboxes for later authorization checks for requests coming from the PBX. (or at least that's what SBC's do with it :)

However, in earlier discussions in Martini and in SIP-Forum there was interest in using it for provisioning verification (ie, the PBX making sure it and the SSP are in synch about the AoRs).  That's what made me add this section in the problems draft, to avoid the problems we'd seen with PAU previously when even the authorization usage by middleboxes had interop problems when the PAU contents didn't match a format the middlebox expected or knew what to do with.

But now that we're not talking about using it for provisioning verification, I agree this section should be removed as it's no longer applicable.

-hadriel

> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, April 22, 2010 4:37 AM
>

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 23 Apr 2010 15:10:38 -0000

#20: Section 3.1.2 does not decscribe an issue
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:  john.elwell@…                     
     Type:  defect                   |       Status:  closed                            
 Priority:  minor                    |    Milestone:  milestone1                        
Component:  reqs                     |      Version:  1.0                               
 Severity:  In WG Last Call          |   Resolution:  fixed                             
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by john.elwell@…):

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

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