Subject: [martini] #25: Sections 7.1-7.5

From: "martini issue tracker" <[email-masked]>
Date: Tue, 06 Apr 2010 22:10:15 -0000

#25: Sections 7.1-7.5
--------------------------------------+-------------------------------------
 Reporter:  francois.audet@…          |       Owner:  adam@…          
     Type:  defect                    |      Status:  new             
 Priority:  major                     |   Milestone:  milestone1      
Component:  gin                       |     Version:  1.0             
 Severity:  Active WG Document        |    Keywords:                  
--------------------------------------+-------------------------------------
 I had a quick look at draft-roach-martini-gin-01, and specifically at
 sections 7.1, 7.3, 7.4, 7.5.

 I don't believe that it makes any sense to have sections 7.3 (on
 Outbound), 7.4 (on Path) and section 7.5 (Service route) as separate
 sections.

 In particular, I feel the topic of outbound is really intertwined with
 section 7.1 (GRUU).

 Section 7.1 talks first about Self-made GRUUs (7.1.1) and then Anonymous
 GRUUs (7.1.2). When I read this section, it feels very theoretical to me
 (as it is crafted on the GRUU specification). The second paragraph of
 7.1.2.1 attempts to explain when a self-made GRUU is not appropriate, but
 it is not easy to follow.

 Rather, it seems to me that we should think about what is our target
 audience for this specification: who will be deploying this? For example,
 it seems to me that lots of PBXs will be deployed behind a NAT/FW. This
 points to the use of Outbound. Furthermore, the fact that many virtual
 end-users are effectively using the same registration, it seems to me that
 a good high-availability mechanism (multiple signaling connections) is
 required, in case a connection fails. Again, this points to using
 Outbound.

 In other words, the questions the reader will have is more likely to be
 "Am I using this behind a NAT/FW?" and "Do I need redundant signaling
 connections?", rather than "Do I want to use a self-made GRUU?" or "Do I
 want an anonymous public GRUU?".

 I would therefore rewrite section 7.1 to talk about the topology of the
 deployment first. In the more common deployment model, this will imply
 Outbound (which includes support for Path, and the +sip.instance).
 Sections 7.3-7.5 can then be eliminated. The use of the "self-made" GRUUs
 will be restricted to the case of "I'm not behind a NAT/FW", and "I don't
 need multiple signaling connections".

 PS: I really don't see much to be said about Service routes.

 [BA] Posted by Francois on March 23, 2010:
 http://www.ietf.org/mail-archive/web/martini/current/msg01025.html

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

---

From: "martini issue tracker" <[email-masked]>
Date: Mon, 19 Apr 2010 22:21:09 -0000

#25: Sections 7.1-7.5
--------------------------------------+-------------------------------------
 Reporter:  francois.audet@…          |        Owner:  adam@…          
     Type:  defect                    |       Status:  closed          
 Priority:  major                     |    Milestone:  milestone1      
Component:  gin                       |      Version:  1.0             
 Severity:  Active WG Document        |   Resolution:  worksforme      
 Keywords:                            |  
--------------------------------------+-------------------------------------
Changes (by adam@…):

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

Comment:

 I think the additional text regarding Path and Service-Route makes it much
 clearer what is intended by these sections -- we're wanting to ensure that
 neither the mechanism itself nor any associated security mechanism is
 disrupted.

 I'm closing this ticket as no longer being relevant to the text that
 currently exists. If anyone thinks I've done this in error, feel free to
 re-open the ticket -- but please include concrete text to include rather
 than vague suggestions when doing so.

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