From dromasca@avaya.com Tue Sep 10 08:28:31 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FE521F9C0E for ; Tue, 10 Sep 2013 08:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.15 X-Spam-Level: X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j-EZAuqohVx for ; Tue, 10 Sep 2013 08:28:25 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6B32B21F9CA6 for ; Tue, 10 Sep 2013 08:28:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAF85L1KHCzI1/2dsb2JhbABbDoJYIThRwkCBJBZ0giUBAQEBAgEBAQEPKDEDEAcEAgEIDQEDAQMBAQEKFAkHJwsUAwYIAgQBEggah1oGAQukDpt3EwSPKjgGgxeBAAOeTIsVgmE/gio X-IronPort-AV: E=Sophos;i="4.90,879,1371096000"; d="scan'208";a="27005751" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Sep 2013 11:28:24 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Sep 2013 11:20:26 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Tue, 10 Sep 2013 17:28:22 +0200 From: "Romascanu, Dan (Dan)" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Websocket transport in SNMP Thread-Index: AQHOnzaayFCreM8HKUGNXjN8ngWUeZmhMXwAgAADCoCAAAK6AIAAGEuAgAAfTgCACUnMIIAAFFUAgBRnhGA= Date: Tue, 10 Sep 2013 15:28:22 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128CF499@AZ-FFEXMB04.global.avaya.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> <09AC0CC5-B63E-4D6D-B66B-E63BBD85FEAC@oracle.com> <0148B625-2D50-4337-BC5E-E16304D6DAE9@edvina.net> <949EF20990823C4C85C18D59AA11AD8B08A34C@FR712WXCHMBA11.zeu.alcatel-lucent.com> <521E375C.9090805@alum.mit.edu> In-Reply-To: <521E375C.9090805@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Websocket transport in SNMP X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:28:31 -0000 Hi Paul,=20 Sorry for the late response. Vacation interfered.=20 > Superficially anybody can look at a change that adds one more > value to an enumeration and say "ok, its syntactically correct and > addresses the new value requested". But is that enough? > What about: > - is this backward compatible? > - does this revised MIB meet current MIB standards and conventions? Yes, there is little to worry on this respect. Adding (syntactically correc= t) enumeration values results in a backward compatible change if the other = values stay untouched. Also by the time the SIP MIB RFC was issued the stan= dard for writing MIB modules was stable, so the MIB module stands compatibl= e with the current MIB standards and conventions. There are some changes in= the way MIB RFCs are written (for example Security Considerations sections= ), so the work of the supposed volunteer would not be zero, but not dramati= c either.=20 > * when updating the MIB, are we obligated to do more? In particular > are we expected to consider what else it ought to contain but > doesn't? This is completely up to the WG to decide.=20 I hope this helps.=20 Regards,=20 Dan > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, August 28, 2013 8:46 PM > To: sipcore@ietf.org; Romascanu, Dan (Dan) > Subject: Re: [sipcore] Websocket transport in SNMP >=20 > Keith, >=20 > I'm glad somebody remembers this. >=20 > On 8/28/13 10:37 AM, DRAGE, Keith (Keith) wrote: > > The SIP MIB was defined in the SIP WG. > > > > SIP was told that all protocols needed one, and a group of people > provided a candidate, and therefore we needed to progress it. > > > > It proved almost impossible to give it rigorous review from the > protocol experts, therefore it was progressed on the basis that what was > there was correct, but potentially incomplete. > > > > As such I can well understand what Hadriel is saying here. > > > > It is also a warning that apart from the issue under discussion, many > other useful things will also be missing. > > > > However reopen the document and you will face the same issue as the > SIP WG faced when it was first produced - trying to get sufficient > review to ensure it was complete. >=20 > So this issue may open a can of worms. >=20 > I hear one person asking to update the MIB definition in one very small > way. I imagine we can get a volunteer to do that much. But that leaves a > number of questions: >=20 > * do we have a sufficient body of people to review that change? > Superficially anybody can look at a change that adds one more > value to an enumeration and say "ok, its syntactically correct and > addresses the new value requested". But is that enough? > What about: > - is this backward compatible? > - does this revised MIB meet current MIB standards and conventions? >=20 > * when updating the MIB, are we obligated to do more? In particular > are we expected to consider what else it ought to contain but > doesn't? > If so, do we have people willing and qualified to do this? >=20 > Dan - can you give some guidance here? >=20 > Thanks, > Paul >=20 >=20 > > Keith > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >> Behalf Of Hadriel Kaplan > >> Sent: 22 August 2013 19:43 > >> To: Olle E. Johansson > >> Cc: sipcore@ietf.org WG > >> Subject: Re: [sipcore] Websocket transport in SNMP > >> > >> > >> On Aug 22, 2013, at 12:50 PM, Olle E. Johansson > wrote: > >> > >>>> When we looked at the MIB years ago, I think there was physical > >> laughter. :) > >>> I can understand why. Some parts are innovative. > >> > >> Uh huh. Name one innovative part. > >> > >> I didn't mean we ignored it because it did new things - we ignored it > >> because it (a) didn't do enough, in the sense that the things it > >> covered were minimal, and more importantly (b) it assumed a specific > >> internal system architecture/data model. > >> > >> But this isn't really a slam against the RFC - every standardized MIB > >> definition has this problem. When you assume a specific > >> config/stats/implementation data model, devices that have a different > >> one can't pretend they don't. > >> > >> That's why we laughed at it - not because it was fundamentally wrong > >> or broken, but because the things we make configurable/collect-stats- > for/etc. > >> follow a different data model; and we thought it was funny that the > >> IETF expected there to be "one to rule them all". > >> > >> So I was asking if anyone had implemented it, to see if at least > >> someone had that data model and it was worth updating the RFC. > >> Apparently it is. :) > >> > >> -hadriel > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > From iesg-secretary@ietf.org Fri Sep 13 11:41:31 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D9011E8181; Fri, 13 Sep 2013 11:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxor9Fd8Bqo6; Fri, 13 Sep 2013 11:41:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF9011E812F; Fri, 13 Sep 2013 11:41:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130913184130.30795.48625.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2013 11:41:30 -0700 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (Session Initiation Protocol (SIP) History-Info Header Call Flow Examples) to Informational RFC X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 18:41:31 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Session Initiation Protocol (SIP) History-Info Header Call Flow Examples' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis-callflows/ballot/ No IPR declarations have been submitted directly on this I-D. From oej@edvina.net Mon Sep 30 06:58:51 2013 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9F021F9C88 for ; Mon, 30 Sep 2013 06:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWrPdo4cw2QL for ; Mon, 30 Sep 2013 06:58:49 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF9121F9C0D for ; Mon, 30 Sep 2013 06:58:42 -0700 (PDT) Received: from [192.168.40.76] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6AAC393C2A2; Mon, 30 Sep 2013 13:58:39 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Sep 2013 15:58:39 +0200 Message-Id: <61F1252B-5DCA-49E0-878D-37CEEFA0B78C@edvina.net> To: "sipcore@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: "Olle E. Johansson" , "Gonzalo Salgueiro \(gsalguei\)" , Cullen Jennings Subject: [sipcore] Locating SIP servers in a dual stack IP network X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 13:58:51 -0000 Hi! We have written a draft that updates RFC 3263 to better handle dual = stack issues and prepare for another draft that clarifies Happy = Eyeballs-like procedures for setting up connections with SIP in dual = stack networks. The document in the current version can be found here: http://tools.ietf.org/html/draft-johansson-sip-dual-stack-01 This draft is a result of the work in the SIP forum IPv6 working group. = During SIPit events and discussions in the wg we've located a couple of = issues with RFC 3263 and the way we handle SRV results. During the IETF = meeting in Berlin I consulted with the IETF DNS directorate and they = confirmed that RFC 3263 doesn't follow the DNS SRV RFC in the way it = describes handling IPv6 and IPv4 - specially where it instructs = implementers to look up either address family, but not both. The DNS SRV = RFC clearly states that ALL addresses for a host name should be used and = connections should be tried before the next host name in the list is = used (higher priority). We've discussed this with the chairs of dispatch (Cullen, Mary) and they = feel this is a document for the SIPcore working group. The chairs of = SIPcore agreed in meetings in Berlin. The charter clearly states that = SIPcore handles updates to core documents. I guess the question now is if the SIPcore wg is willing to adopt this = work? Best regards, /Olle=