[martini] #61: Review

"martini issue tracker" <trac@tools.ietf.org> Sat, 24 July 2010 14:13 UTC

Return-Path: <trac@tools.ietf.org>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16BB53A69A8 for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.573
X-Spam-Level:
X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlN3dlLanUuZ for <martini@core3.amsl.com>; Sat, 24 Jul 2010 07:13:06 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 044E13A69A9 for <martini@ietf.org>; Sat, 24 Jul 2010 07:13:06 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1OcfTI-0000su-91; Sat, 24 Jul 2010 07:13:00 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: martini issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: adam@nostrum.com, pkyzivat@cisco.com
X-Trac-Project: martini
Date: Sat, 24 Jul 2010 14:13:00 -0000
X-URL: http://tools.ietf.org/martini/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/martini/trac/ticket/61
Message-ID: <060.5b4526d4c22b62aadd6b6d04a6998d50@tools.ietf.org>
X-Trac-Ticket-ID: 61
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: adam@nostrum.com, pkyzivat@cisco.com, martini@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: martini@ietf.org
Subject: [martini] #61: Review
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Jul 2010 14:13:08 -0000

#61: Review
--------------------------------+-------------------------------------------
 Reporter:  pkyzivat@…          |       Owner:  adam@…          
     Type:  defect              |      Status:  new             
 Priority:  major               |   Milestone:  milestone1      
Component:  gin                 |     Version:  1.0             
 Severity:  In WG Last Call     |    Keywords:                  
--------------------------------+-------------------------------------------
 This draft is hanging together very well now. I have a few comments:

 Section 7.1.2.2:

 According to RFC5627 (gruu) section 3.2, every registration refresh
 generates a new temp gruu, with special rules for expiration. Does that
 apply here too? Or is that changed for bnc registrations? Either way, I
 think the implications need to be discussed.

 Section 7.2.1:

 I think there may be an issue here. Normally RFC5628 (gruu reg event)
 would apply here, reporting the gruus assigned. (The most recent for the
 temp gruu.) That could work for the pub-gruu of each implicitly
 registered number. But it won't work for the temp gruus - the SSP
 doesn't even know what those are. If there was a record for the "base"
 AOR, that could contain the temp-gruu template. But that is currently
 forbidden.

 Again, I think something needs to be said about this, whatever way it
 should work.

 One thing to keep in mind is that management of temp gruus can be touchy
 relative to registration refreshes. If the registration ever expires,
 even momentarily, then the previously assigned temp gruus become
 invalid. Only new ones obtained after reregistration are then valid. In
 the case of the pbx with devices registered to it, that have have been
 issued "derived" temp gruus, those also become invalid.

 The only way to be certain this hasn't happened is to subscribe to the
 reg event package and get gruu reg event info about the temp gruu. But
 that will only work if the pbx can get temp gruu info from a reg event
 subscription to the SSP.

 Sorry to be so tardy in getting this info out. I think I alluded to it
 earlier, but I don't think I ever provided specifics.

         Thanks,
         Paul

 7.2.2

 There is an out for the SSP to handle the subscriptions if it can keep a
 complete, accurate and up to date copy of the data, e.g. through a
 backend subscription.) Its even harder than that, since the pbx could
 apply an authorization policy to each of those AORs, restricting who can
 see the info, and how much of it. The SSP couldn't learn that through
 backend subscriptions unless it maintains a distinct backend
 subscription for each potential subscriber.

 In this section gruus again rear their ugly heads. If the pbx supports
 gruu, then it probably SHOULD support the gruu reg event package and
 return the appropriate information.

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