From adam@nostrum.com Fri Aug 2 02:50:41 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 0908C11E8311 for ; Fri, 2 Aug 2013 02:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, SPF_PASS=-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 tzCw+AVgsJTl for ; Fri, 2 Aug 2013 02:50:39 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 077D411E82DC for ; Fri, 2 Aug 2013 02:50:38 -0700 (PDT) Received: from dhcp-55a4.meeting.ietf.org (dhcp-55a4.meeting.ietf.org [130.129.85.164]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r729oaUM096993 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 04:50:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51FB80EE.1030801@nostrum.com> Date: Fri, 02 Aug 2013 11:50:38 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "'SIPCORE'" References: <512E35D2.6080400@nostrum.com> In-Reply-To: <512E35D2.6080400@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 130.129.85.164 is authenticated by a trusted mechanism) Cc: draft-rosen-rph-reg-policy@tools.ietf.org Subject: Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00 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: Fri, 02 Aug 2013 09:50:41 -0000 [as chair] It has been brought to my attention that we (the chairs) neglected to mark the end of this two-week period. I apologize for this lapse. In reviewing the response to this last call, I find weak support and no opposition for adopting and publishing this document. I ask Brian, as the author of this document, to issue a new version, draft-ietf-sipcore-rph-reg-policy, adding an "Updates: RFC 4412" to the metainformation block. I note that the draft upload embargo was lifted earlier today. Given that WGLC is complete, I will request publication as soon as practical after the new draft appears. /a On 2/27/13 17:35, Adam Roach wrote: > [as chair] > > During the processing of draft-polk-local-emergency-rph-namespace, the > IESG, authors, and WG chairs determined that the policy described in > RFC4412, section 9 for defining a new namespace (Standards-Track RFC) > was probably selected in error, and that "IETF Review" is likely more > appropriate. The ECRIT working group has already been informed of this > situation, and no parties have objected to a change in policy: > > http://www.ietf.org/mail-archive/web/ecrit/current/msg08292.html > > Since this is a policy change to a core SIP header, our Area Director > has requested that the document that formally changes the policy be > processed as a SIPCORE document. The current draft is available here: > > http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00 > > (Aside: ignoring the boilerplate, references, and table of contents, > the document is about half as long as this email, and should take less > time to read). > > This message starts a call for adoption in parallel with a working > group last call. Both periods end in just over two weeks, on Friday, > March 15th (the final Friday of the Orlando IETF meeting). Please > reply to the mailing list indicating support or opposition to such > adoption, and with any comments on the document contents themselves. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From br@brianrosen.net Fri Aug 2 03:04:25 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 655AC21E8095 for ; Fri, 2 Aug 2013 03:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.643 X-Spam-Level: X-Spam-Status: No, score=-101.643 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 7db+yw+2cgVO for ; Fri, 2 Aug 2013 03:04:20 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4509511E8313 for ; Fri, 2 Aug 2013 03:04:14 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so501896pab.7 for ; Fri, 02 Aug 2013 03:04:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/4HiujOMftnL1syUiLgXUWimiloDTGPgWUnzW+112Fs=; b=T1E9qDVne2+t1MJSCu3Gl+JPx/L6mgI7+VE2Wb5t/5WtYsfq6+z7ENFldIU5hGh/HN vw81CMXYTMGhjPR0UedYfs0NTxJlhAyqq3blssmHAVYLZo3KhER6FjQjN06n5kJ/fOzF XyDYz8sQPQXXEBHUYDdNL+nhFUvodb8jiHu7aN+968WiuCifnrH3vfDiu52GnipF37EA HTs2Q9eR7nTkLp3574k+9nbIIMjEvirl85/2DFh0+O8wQnhIl55w2nJvLpG5B7jB7fTs En6uot1buqKmB53cTQ0ibBvwHpw2BviKxQYhJCYIdD0GB2E8PFtv+XMU5DGb6Yu9w0ce 3xLg== MIME-Version: 1.0 X-Received: by 10.69.15.33 with SMTP id fl1mr6733782pbd.189.1375437853817; Fri, 02 Aug 2013 03:04:13 -0700 (PDT) Received: by 10.70.23.225 with HTTP; Fri, 2 Aug 2013 03:04:13 -0700 (PDT) X-Originating-IP: [130.129.17.189] In-Reply-To: <51FB80EE.1030801@nostrum.com> References: <512E35D2.6080400@nostrum.com> <51FB80EE.1030801@nostrum.com> Date: Fri, 2 Aug 2013 06:04:13 -0400 Message-ID: From: Brian Rosen To: Adam Roach Content-Type: multipart/alternative; boundary=047d7b5d9553b019c704e2f41440 X-Gm-Message-State: ALoCoQn3dfZuotdNVbPYrHa4y6wZosawHDmU7ET9aAcmHzMiD8VkG7Rl4J2NTqMcoy2XGvVGGy+f Cc: "draft-rosen-rph-reg-policy@tools.ietf.org" , SIPCORE Subject: Re: [sipcore] Call for adoption/WGLC: draft-rosen-rph-reg-policy-00 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: Fri, 02 Aug 2013 10:04:25 -0000 --047d7b5d9553b019c704e2f41440 Content-Type: text/plain; charset=ISO-8859-1 I will make this update although it may be a day or so before I can do so. Thanks for getting this moving again. Brian On Friday, August 2, 2013, Adam Roach wrote: > [as chair] > > It has been brought to my attention that we (the chairs) neglected to mark > the end of this two-week period. I apologize for this lapse. > > In reviewing the response to this last call, I find weak support and no > opposition for adopting and publishing this document. > > I ask Brian, as the author of this document, to issue a new version, > draft-ietf-sipcore-rph-reg-**policy, adding an "Updates: RFC 4412" to the > metainformation block. I note that the draft upload embargo was lifted > earlier today. Given that WGLC is complete, I will request publication as > soon as practical after the new draft appears. > > /a > > On 2/27/13 17:35, Adam Roach wrote: > >> [as chair] >> >> During the processing of draft-polk-local-emergency-**rph-namespace, the >> IESG, authors, and WG chairs determined that the policy described in >> RFC4412, section 9 for defining a new namespace (Standards-Track RFC) was >> probably selected in error, and that "IETF Review" is likely more >> appropriate. The ECRIT working group has already been informed of this >> situation, and no parties have objected to a change in policy: >> >> http://www.ietf.org/mail-**archive/web/ecrit/current/**msg08292.html >> >> Since this is a policy change to a core SIP header, our Area Director has >> requested that the document that formally changes the policy be processed >> as a SIPCORE document. The current draft is available here: >> >> http://tools.ietf.org/html/**draft-rosen-rph-reg-policy-00 >> >> (Aside: ignoring the boilerplate, references, and table of contents, the >> document is about half as long as this email, and should take less time to >> read). >> >> This message starts a call for adoption in parallel with a working group >> last call. Both periods end in just over two weeks, on Friday, March 15th >> (the final Friday of the Orlando IETF meeting). Please reply to the mailing >> list indicating support or opposition to such adoption, and with any >> comments on the document contents themselves. >> >> /a >> ______________________________**_________________ >> 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 > --047d7b5d9553b019c704e2f41440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I will make this update although it may be a day or so before I can do so.<= div>
Thanks for getting this moving again.

Brian


On Friday, August 2, 2013, Adam= Roach wrote:
[as chair]

It has been brought to my attention that we (the chairs) neglected to mark = the end of this two-week period. I apologize for this lapse.

In reviewing the response to this last call, I find weak support and no opp= osition for adopting and publishing this document.

I ask Brian, as the author of this document, to issue a new version, draft-= ietf-sipcore-rph-reg-policy, adding an "Updates: RFC 4412"= to the metainformation block. I note that the draft upload embargo was lif= ted earlier today. Given that WGLC is complete, I will request publication = as soon as practical after the new draft appears.

/a

On 2/27/13 17:35, Adam Roach wrote:
[as chair]

During the processing of draft-polk-local-emergency-rph-namespace, t= he IESG, authors, and WG chairs determined that the policy described in RFC= 4412, section 9 for defining a new namespace (Standards-Track RFC) was prob= ably selected in error, and that "IETF Review" is likely more app= ropriate. The ECRIT working group has already been informed of this situati= on, and no parties have objected to a change in policy:

http://www.ietf.org/mail-archive/web/ecrit/curre= nt/msg08292.html

Since this is a policy change to a core SIP header, our Area Director has r= equested that the document that formally changes the policy be processed as= a SIPCORE document. The current draft is available here:

http://tools.ietf.org/html/draft-rosen-rph-reg-policy-00=

(Aside: ignoring the boilerplate, references, and table of contents, the do= cument is about half as long as this email, and should take less time to re= ad).

This message starts a call for adoption in parallel with a working group la= st call. Both periods end in just over two weeks, on Friday, March 15th (th= e final Friday of the Orlando IETF meeting). Please reply to the mailing li= st indicating support or opposition to such adoption, and with any comments= on the document contents themselves.

/a
_______________________________________________
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
--047d7b5d9553b019c704e2f41440-- From oej@edvina.net Thu Aug 22 05:53:17 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 5B84921F9F0A for ; Thu, 22 Aug 2013 05:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 zEM3Qa4DbSRL for ; Thu, 22 Aug 2013 05:53:17 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1421F89EB for ; Thu, 22 Aug 2013 05:53:15 -0700 (PDT) Received: from [192.168.40.38] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id CDC9A93DE3D for ; Thu, 22 Aug 2013 12:53:12 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> Date: Thu, 22 Aug 2013 14:53:15 +0200 To: "sipcore@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [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: Thu, 22 Aug 2013 12:53:17 -0000 During the IETF in Berlin I had a discussion with Adam (as chair) about = the need for updating the SNMP MIBs for SIP as we add a new transport. I = tried to discuss it with Paul, but noticed that he silently began = thinking about completely different things while running away. :-) I contacted the ops and mib people wg and they clearly said it's our = responsibility in sipcore to update the TC that includes the transport = bits. Just for the archives and a todo-list somewhere in the cloud. /O= From dromasca@avaya.com Thu Aug 22 06:06:56 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 0480611E81B2 for ; Thu, 22 Aug 2013 06:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.352 X-Spam-Level: X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=0.247, 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 Z9KiWqRdzM5L for ; Thu, 22 Aug 2013 06:06:50 -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 93FE811E81A4 for ; Thu, 22 Aug 2013 06:06:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAI0MFlLGmAcV/2dsb2JhbABagmQhNVHAB4EdFnSCJAEBAQEDAQEBDyg0FwQCAQgNBAQBAQsUCQcnCxQJCAIEARIIGoduAQuZZpR/EwSQNTgGgxV7A542iwqDH4Ir X-IronPort-AV: E=Sophos;i="4.89,934,1367985600"; d="scan'208";a="24627725" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Aug 2013 09:06:30 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Aug 2013 09:02:19 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 22 Aug 2013 09:06:29 -0400 From: "Romascanu, Dan (Dan)" To: "Olle E. Johansson" , "sipcore@ietf.org WG" Thread-Topic: [sipcore] Websocket transport in SNMP Thread-Index: AQHOnzaWURj7O4fuckG5zprJmUbsOpmhMUqg Date: Thu, 22 Aug 2013 13:06:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B5A33@AZ-FFEXMB04.global.avaya.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> In-Reply-To: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] 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: Thu, 22 Aug 2013 13:06:56 -0000 This should not be a big deal if the future authors resist the temptation o= f other updates and extensions besides the SipTCTransportProtocol TC. Until= then the value other(0) must be used by implementations to designate the w= ebsockets transport.=20 Regards,=20 Dan > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Olle E. Johansson > Sent: Thursday, August 22, 2013 3:53 PM > To: sipcore@ietf.org WG > Subject: [sipcore] Websocket transport in SNMP >=20 > During the IETF in Berlin I had a discussion with Adam (as chair) about > the need for updating the SNMP MIBs for SIP as we add a new transport. I > tried to discuss it with Paul, but noticed that he silently began > thinking about completely different things while running away. :-) >=20 > I contacted the ops and mib people wg and they clearly said it's our > responsibility in sipcore to update the TC that includes the transport > bits. >=20 > Just for the archives and a todo-list somewhere in the cloud. >=20 > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Thu Aug 22 06:46:40 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 F3C1111E81C1 for ; Thu, 22 Aug 2013 06:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 L-1s-6OFjWsp for ; Thu, 22 Aug 2013 06:46:35 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 10DD211E81BA for ; Thu, 22 Aug 2013 06:46:34 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta06.westchester.pa.mail.comcast.net with comcast id FoZf1m0081uE5Es56pmakZ; Thu, 22 Aug 2013 13:46:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id FpmZ1m01m3ZTu2S3cpmar3; Thu, 22 Aug 2013 13:46:34 +0000 Message-ID: <52161639.2050509@alum.mit.edu> Date: Thu, 22 Aug 2013 09:46:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> In-Reply-To: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377179194; bh=8LHcXvzgSrslyOFY+mCumF/mhFzak0xMw8H1c/l0BkE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WOjcWJXPCBPi6qJBLiVDfNB/3DVP0gl61aoEkWAjPGCUhh5uDBvny1vUHUTGK726/ MPDALg3Z4acEXAV5m1tQZA71e4MKOTUP34nJQsTx8/aLZj/8FFU5ULC4MNRFy1ngc1 BtcucqcUne3DdXdaZny5mBOGf7yA2uEFYnbclWiPmVxFO8C6MMeeg9aXocZRQNINb/ OQ2vaCrebuJlORq8cse5Hey7G5GMLrQ9Uw6LCEckrbv/pP4YadlviHj04qu0PH4C5q ZXNyDodlYlyZT24ZtavwNEmFYYGUDWVAMzGteoZzvkxLcb9jkJYahaNWKjMYii5DmP LRv2DLycQc7tg== 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: Thu, 22 Aug 2013 13:46:40 -0000 Just to clarify my position on this: I recognize that MIBs have value. But its not an area for which I have any experience, knowledge, or interest. Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP, MMUSIC, having been involved in creation of SIP MIBs. But if SIPCORE is the proper place to do the work, and there are people willing and able to do it, then I have no objection to the work being done in SIPCORE. Thanks, Paul On 8/22/13 8:53 AM, Olle E. Johansson wrote: > During the IETF in Berlin I had a discussion with Adam (as chair) about the need for updating the SNMP MIBs for SIP as we add a new transport. I tried to discuss it with Paul, but noticed that he silently began thinking about completely different things while running away. :-) > > I contacted the ops and mib people wg and they clearly said it's our responsibility in sipcore to update the TC that includes the transport bits. > > Just for the archives and a todo-list somewhere in the cloud. > > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dromasca@avaya.com Thu Aug 22 07:03:13 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 36FE411E80E2 for ; Thu, 22 Aug 2013 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.88 X-Spam-Level: X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, 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 UbCZJ3SBRoSV for ; Thu, 22 Aug 2013 07:03:07 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9793921F91CE for ; Thu, 22 Aug 2013 07:03:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAMUYFlKHCzI1/2dsb2JhbABaDoJWITVRwAiBHBZ0giQBAQEBAgEBAQEPKDQQBwQCAQgNAQMEAQEBChQJBycLFAkIAgQBEggah2gGAQuZfJR9EwSQNTgGgxV7A542iwqCYD+CKw X-IronPort-AV: E=Sophos;i="4.89,934,1367985600"; d="scan'208";a="25096596" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Aug 2013 10:03:06 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Aug 2013 09:55:48 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 22 Aug 2013 10:03:05 -0400 From: "Romascanu, Dan (Dan)" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Websocket transport in SNMP Thread-Index: AQHOnzaWURj7O4fuckG5zprJmUbsOpmhgKeA///A4NA= Date: Thu, 22 Aug 2013 14:03:04 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B5ABE@AZ-FFEXMB04.global.avaya.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <52161639.2050509@alum.mit.edu> In-Reply-To: <52161639.2050509@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.45] 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: Thu, 22 Aug 2013 14:03:13 -0000 Hi Paul, > Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP, > MMUSIC, having been involved in creation of SIP MIBs. Actually RFC 4780 was the product of the SIP MIB WG.=20 Regards, Dan > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, August 22, 2013 4:47 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Websocket transport in SNMP >=20 > Just to clarify my position on this: >=20 > I recognize that MIBs have value. > But its not an area for which I have any experience, knowledge, or > interest.=20 > But if SIPCORE is the proper place to do the work, and there are people > willing and able to do it, then I have no objection to the work being > done in SIPCORE. >=20 > Thanks, > Paul >=20 >=20 > On 8/22/13 8:53 AM, Olle E. Johansson wrote: > > During the IETF in Berlin I had a discussion with Adam (as chair) > > about the need for updating the SNMP MIBs for SIP as we add a new > > transport. I tried to discuss it with Paul, but noticed that he > > silently began thinking about completely different things while > > running away. :-) > > > > I contacted the ops and mib people wg and they clearly said it's our > responsibility in sipcore to update the TC that includes the transport > bits. > > > > Just for the archives and a todo-list somewhere in the cloud. > > > > /O > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Thu Aug 22 07:51:47 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 3DC4C11E81BB for ; Thu, 22 Aug 2013 07:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k5445VT7Ai0x for ; Thu, 22 Aug 2013 07:51:46 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7FA11E814C for ; Thu, 22 Aug 2013 07:51:46 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b4so1140637qen.34 for ; Thu, 22 Aug 2013 07:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8EWgdHyXOsd++4c0tZ21q1sILLf1GsJfmBPOGJsKwaA=; b=Nvy8ybskoWsMrb7vWUvjO7+IP59QHE+h6dJ/7oSm0yicRgc/p+mo39DpnH1EIDleK6 XzHFU6/dyrnga2tFkK51i0D/3V6kxJmRPW73jL3n5ieoN+vL9YCuqRlYqLB43yIMJXdm rkLhkYoGRPgHqQBKq74dPvTPq/V5FHj3MjSZIhfAa4I+RMQ0j98kie0JcuN4Ny7SIPOB Xpf3Zh1KT6XaBlyzZ6niM8Z2aD6pSUU0u+uUPymXmcMmQQqF1Sizim/1Ft+xf7P0AEag G7Yo8F7ta6OxBCPJ0zzyNR/+U4HRWhCmZ5B7c30buxJRXeZFSLMxKmOgVT86iYlTnAtk OKtw== MIME-Version: 1.0 X-Received: by 10.229.149.7 with SMTP id r7mr3890385qcv.3.1377183105316; Thu, 22 Aug 2013 07:51:45 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Thu, 22 Aug 2013 07:51:45 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128B5ABE@AZ-FFEXMB04.global.avaya.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <52161639.2050509@alum.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA128B5ABE@AZ-FFEXMB04.global.avaya.com> Date: Thu, 22 Aug 2013 09:51:45 -0500 Message-ID: From: Mary Barnes To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=e89a8f5036f4c880bf04e48a6dd3 Cc: "sipcore@ietf.org" 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: Thu, 22 Aug 2013 14:51:47 -0000 --e89a8f5036f4c880bf04e48a6dd3 Content-Type: text/plain; charset=ISO-8859-1 Dan, you mean a product of the SIP WG - correct (i.e., not SIP MIB WG)? On Thu, Aug 22, 2013 at 9:03 AM, Romascanu, Dan (Dan) wrote: > Hi Paul, > > > Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP, > > MMUSIC, having been involved in creation of SIP MIBs. > > > Actually RFC 4780 was the product of the SIP MIB WG. > > Regards, > > Dan > > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Thursday, August 22, 2013 4:47 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Websocket transport in SNMP > > > > Just to clarify my position on this: > > > > I recognize that MIBs have value. > > But its not an area for which I have any experience, knowledge, or > > interest. > > But if SIPCORE is the proper place to do the work, and there are people > > willing and able to do it, then I have no objection to the work being > > done in SIPCORE. > > > > Thanks, > > Paul > > > > > > On 8/22/13 8:53 AM, Olle E. Johansson wrote: > > > During the IETF in Berlin I had a discussion with Adam (as chair) > > > about the need for updating the SNMP MIBs for SIP as we add a new > > > transport. I tried to discuss it with Paul, but noticed that he > > > silently began thinking about completely different things while > > > running away. :-) > > > > > > I contacted the ops and mib people wg and they clearly said it's our > > responsibility in sipcore to update the TC that includes the transport > > bits. > > > > > > Just for the archives and a todo-list somewhere in the cloud. > > > > > > /O > > > _______________________________________________ > > > 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 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --e89a8f5036f4c880bf04e48a6dd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan, you mean a product of the SIP WG - correct (i.e., not= SIP MIB WG)?=A0


On Thu, Aug 22, 2013 at 9:03 AM, Romascanu, Dan (Dan) <dromasca@av= aya.com> wrote:
Hi Paul,

> Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP,
> MMUSIC, having been involved in creation of SIP MIBs.


Actually RFC 4780 was the product of the SIP MIB WG.

Regards,

Dan




> -----Original Message-----
> From: sipcore-bounces@ietf= .org [mailto:sipcore-bounce= s@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, August 22, 2013 4:47 PM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Websocket transport in SNMP
>
> Just to clarify my position on this:
>
> I recognize that MIBs have value.
> But its not an area for which I have any experience, knowledge, or
> interest.
> But if SIPCORE is the pr= oper place to do the work, and there are people
> willing and able to do it, then I have no objection to the work being<= br> > done in SIPCORE.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>
> On 8/22/13 8:53 AM, Olle E. Johansson wrote:
> > During the IETF in Berlin I had a discussion with Adam (as chair)=
> > about the need for updating the SNMP MIBs for SIP as we add a new=
> > transport. I tried to discuss it with Paul, but noticed that he > > silently began thinking about completely different things while > > running away. :-)
> >
> > I contacted the ops and mib people wg and they clearly said it= 9;s our
> responsibility in sipcore to update the TC that includes the transport=
> bits.
> >
> > Just for the archives and a todo-list somewhere in the cloud.
> >
> > /O
> > _______________________________________________
> > 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
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--e89a8f5036f4c880bf04e48a6dd3-- From hadriel.kaplan@oracle.com Thu Aug 22 08:03:33 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 C020611E80F1 for ; Thu, 22 Aug 2013 08:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HMRvAqtIK5Lm for ; Thu, 22 Aug 2013 08:03:27 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4675B11E81E8 for ; Thu, 22 Aug 2013 08:03:23 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7MF3G3M032688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 15:03:16 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MF3EEm008792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 15:03:15 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MF3EdK029906; Thu, 22 Aug 2013 15:03:14 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Aug 2013 08:03:14 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> Date: Thu, 22 Aug 2013 11:03:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "sipcore@ietf.org WG" 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: Thu, 22 Aug 2013 15:03:33 -0000 I'm not sure if SIPCORE is the right WG... not that I think it matters = much where it's done. But just adding another enumeration bit value to SipTCTransportProtocol = is pretty uncontroversial and could just be done with AD sponsorship = instead of a WG, imo. Regardless, does anyone actually implement and use the SIP MIB? -hadriel On Aug 22, 2013, at 8:53 AM, Olle E. Johansson wrote: > During the IETF in Berlin I had a discussion with Adam (as chair) = about the need for updating the SNMP MIBs for SIP as we add a new = transport. I tried to discuss it with Paul, but noticed that he silently = began thinking about completely different things while running away. :-) >=20 > I contacted the ops and mib people wg and they clearly said it's our = responsibility in sipcore to update the TC that includes the transport = bits. >=20 > Just for the archives and a todo-list somewhere in the cloud. >=20 > /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From oej@edvina.net Thu Aug 22 08:14:07 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 8491411E8176 for ; Thu, 22 Aug 2013 08:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 E7vzY0hnXA2y for ; Thu, 22 Aug 2013 08:14:07 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1C411E81E9 for ; Thu, 22 Aug 2013 08:14:05 -0700 (PDT) Received: from [192.168.40.38] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id F0FE993C1AF; Thu, 22 Aug 2013 15:14:02 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_DB6C4777-E345-4A1E-B11F-90A2F12742AD" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> Date: Thu, 22 Aug 2013 17:14:05 +0200 Message-Id: References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "sipcore@ietf.org WG" 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: Thu, 22 Aug 2013 15:14:07 -0000 --Apple-Mail=_DB6C4777-E345-4A1E-B11F-90A2F12742AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 22 aug 2013 kl. 17:03 skrev Hadriel Kaplan : >=20 > I'm not sure if SIPCORE is the right WG... not that I think it matters = much where it's done. > But just adding another enumeration bit value to = SipTCTransportProtocol is pretty uncontroversial and could just be done = with AD sponsorship instead of a WG, imo. >=20 > Regardless, does anyone actually implement and use the SIP MIB? We have an implementation in Kamailio. /O >=20 > -hadriel >=20 >=20 > On Aug 22, 2013, at 8:53 AM, Olle E. Johansson wrote: >=20 >> During the IETF in Berlin I had a discussion with Adam (as chair) = about the need for updating the SNMP MIBs for SIP as we add a new = transport. I tried to discuss it with Paul, but noticed that he silently = began thinking about completely different things while running away. :-) >>=20 >> I contacted the ops and mib people wg and they clearly said it's our = responsibility in sipcore to update the TC that includes the transport = bits. >>=20 >> Just for the archives and a todo-list somewhere in the cloud. >>=20 >> /O >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_DB6C4777-E345-4A1E-B11F-90A2F12742AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hadriel.kaplan@oracle.com>= ;:


I'm not sure if SIPCORE is the right WG... not that I = think it matters much where it's done.
But just adding another = enumeration bit value to SipTCTransportProtocol is pretty = uncontroversial and could just be done with AD sponsorship instead of a = WG, imo.

Regardless, does anyone actually implement and use the = SIP MIB?
We have an implementation in = Kamailio.

/O

-hadriel


On Aug 22, 2013, at 8:53 AM, Olle = E. Johansson <oej@edvina.net> = wrote:

During the IETF in Berlin I had = a discussion with Adam (as chair) about the need for updating the SNMP = MIBs for SIP as we add a new transport. I tried to discuss it with Paul, = but noticed that he silently began thinking about completely different = things while running away. :-)

I contacted the ops and mib people = wg and they clearly said it's our responsibility in sipcore to update = the TC that includes the transport bits.

Just for the archives = and a todo-list somewhere in the = cloud.

/O
_______________________________________________
sip= core mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore


---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_DB6C4777-E345-4A1E-B11F-90A2F12742AD-- From hadriel.kaplan@oracle.com Thu Aug 22 08:24:33 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 729E711E80F1 for ; Thu, 22 Aug 2013 08:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 sJ8ZjVYkGhww for ; Thu, 22 Aug 2013 08:24:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 95C1C11E80D5 for ; Thu, 22 Aug 2013 08:24:21 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7MFNqPX022731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 15:23:53 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MFNp4Z005909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 15:23:52 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MFNpiZ007205; Thu, 22 Aug 2013 15:23:51 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Aug 2013 08:23:51 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 22 Aug 2013 11:23:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <09AC0CC5-B63E-4D6D-B66B-E63BBD85FEAC@oracle.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "sipcore@ietf.org WG" 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: Thu, 22 Aug 2013 15:24:33 -0000 On Aug 22, 2013, at 11:14 AM, Olle E. Johansson wrote: >=20 > 22 aug 2013 kl. 17:03 skrev Hadriel Kaplan = : >=20 >>=20 >> I'm not sure if SIPCORE is the right WG... not that I think it = matters much where it's done. >> But just adding another enumeration bit value to = SipTCTransportProtocol is pretty uncontroversial and could just be done = with AD sponsorship instead of a WG, imo. >>=20 >> Regardless, does anyone actually implement and use the SIP MIB? > We have an implementation in Kamailio. Really? I'll have to take a look at Kamailio's implementation sometime. = Did you only implement a very few specific things from it? =20 When we looked at the MIB years ago, I think there was physical = laughter. :)=20 -hadriel From pkyzivat@alum.mit.edu Thu Aug 22 09:15:07 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 499CC11E81CD for ; Thu, 22 Aug 2013 09:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 5KqPG2aDWpTc for ; Thu, 22 Aug 2013 09:15:02 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id ACDC311E8100 for ; Thu, 22 Aug 2013 09:15:01 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta06.westchester.pa.mail.comcast.net with comcast id FoeK1m00A27AodY56sF1JR; Thu, 22 Aug 2013 16:15:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id FsF01m00y3ZTu2S3fsF07n; Thu, 22 Aug 2013 16:15:01 +0000 Message-ID: <52163900.8000300@alum.mit.edu> Date: Thu, 22 Aug 2013 12:14:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <52161639.2050509@alum.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA128B5ABE@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128B5ABE@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377188101; bh=4VWODI0SoxY+86RpxKI/4vkMBxcZIlysN82u4ouyKBA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m1MOpGTLaQobeGa9anraocIXkwDo6Tcm1HUBE3HSojU0z1rxAZ221pRewXoxeVdNR SGywlJduxiKXNzSsbqJu7+WgeMz1DfxkF0tH5QZLI9Dk7DPv927MBR++9H9ysR2MOn zuPQ1KbMAhfmH5bdh7c0PtXyajPT9/u7RPUIAW5YyjeVzWZbDashc1BH47faLVv8nR 7LJqe92imA/3IqW6Yg48c/sbdJDD7fMP64ozvQEWu3IB6svp7AVlTvO7Tpt98B6gP3 Ctuhr8uzVjMFJvZuee1aGU8oY4tIeV7a5x0fKyaNYXimwkW+iwQjDaT6dhVigBL6JV rPPbCCxo7gwOQ== Cc: "sipcore@ietf.org" 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: Thu, 22 Aug 2013 16:15:07 -0000 On 8/22/13 10:03 AM, Romascanu, Dan (Dan) wrote: > Hi Paul, > >> Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP, >> MMUSIC, having been involved in creation of SIP MIBs. > > > Actually RFC 4780 was the product of the SIP MIB WG. OK. I was around, but don't remember it. But I do see that it was. I'm sorry I didn't remember. Paul > Regards, > > Dan > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, August 22, 2013 4:47 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Websocket transport in SNMP >> >> Just to clarify my position on this: >> >> I recognize that MIBs have value. >> But its not an area for which I have any experience, knowledge, or >> interest. >> But if SIPCORE is the proper place to do the work, and there are people >> willing and able to do it, then I have no objection to the work being >> done in SIPCORE. >> >> Thanks, >> Paul >> >> >> On 8/22/13 8:53 AM, Olle E. Johansson wrote: >>> During the IETF in Berlin I had a discussion with Adam (as chair) >>> about the need for updating the SNMP MIBs for SIP as we add a new >>> transport. I tried to discuss it with Paul, but noticed that he >>> silently began thinking about completely different things while >>> running away. :-) >>> >>> I contacted the ops and mib people wg and they clearly said it's our >> responsibility in sipcore to update the TC that includes the transport >> bits. >>> >>> Just for the archives and a todo-list somewhere in the cloud. >>> >>> /O >>> _______________________________________________ >>> 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 pkyzivat@alum.mit.edu Thu Aug 22 09:20:52 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 7DFA611E81AA for ; Thu, 22 Aug 2013 09:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 VFIhT8OSSrj7 for ; Thu, 22 Aug 2013 09:20:47 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCAD11E80ED for ; Thu, 22 Aug 2013 09:20:46 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Fn8l1m0051vXlb85BsLmyc; Thu, 22 Aug 2013 16:20:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id FsLm1m00H3ZTu2S3dsLmcn; Thu, 22 Aug 2013 16:20:46 +0000 Message-ID: <52163A5D.9090203@alum.mit.edu> Date: Thu, 22 Aug 2013 12:20:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> In-Reply-To: <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377188446; bh=1MGbrP8bQ39CjunkBWeFIcR5VRRCNiUWeP7xdx20gSc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=huKW2ds400bzdeDQgL2d5XDibRYQiS/gHTLuoJ6kY2eJWLLUNJcqNx1z6fhybz3an X8LYyhovaNHZwe4b+Pv1pTOJm1LJg2rSt/jocxNkpMyefVXc/w43vzf0iAR03TVFOy 7Sur1nY7FJrx7wJ0eA2YHp51W/NTY/AygYI55Q+RyN9BLUx6pv6eefx5Tx5c4FoCGv vbK6xFSQYgec8mFfNHNJB0tw28Q4o6tdSHScSgIijt1BBupZldGKLUsqemu53XS23G wkgjTDMW9q6WJhB2Gh8HnCuqxi0Jnhx842BKn4IcCKaCWfzDzS7RanlcWJJJl9Cas4 My/3Wf10Oerag== 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: Thu, 22 Aug 2013 16:20:52 -0000 On 8/22/13 11:03 AM, Hadriel Kaplan wrote: > > I'm not sure if SIPCORE is the right WG... not that I think it matters much where it's done. > But just adding another enumeration bit value to SipTCTransportProtocol is pretty uncontroversial and could just be done with AD sponsorship instead of a WG, imo. *If* that is all that is required, and its clear to those who manage such things that this is the correct way to do it, then I agree. IMO the main point of doing it in a WG is so that knowledgeable people will review it and comment if there are better ways, or other things that should be considered, etc. For instance, is it really necessary for MIBs to have their own definitions for things that exist in IANA registries? Or should addition to a registry automatically enable support in the MIB? I can ask that question in the abstract, unemcumbered with any knowledge of existing practice in MIBs, technological limitations, etc. But I expect that there are a set of people equipped to have that discussion. I just don't know if they are in the sipcore wg. Thanks, Paul > Regardless, does anyone actually implement and use the SIP MIB? > > -hadriel > > > On Aug 22, 2013, at 8:53 AM, Olle E. Johansson wrote: > >> During the IETF in Berlin I had a discussion with Adam (as chair) about the need for updating the SNMP MIBs for SIP as we add a new transport. I tried to discuss it with Paul, but noticed that he silently began thinking about completely different things while running away. :-) >> >> I contacted the ops and mib people wg and they clearly said it's our responsibility in sipcore to update the TC that includes the transport bits. >> >> Just for the archives and a todo-list somewhere in the cloud. >> >> /O >> _______________________________________________ >> 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 dromasca@avaya.com Thu Aug 22 09:21:12 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 7552921F9CF1 for ; Thu, 22 Aug 2013 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=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 cnSrptlSNTYC for ; Thu, 22 Aug 2013 09:21:07 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0711E81F8 for ; Thu, 22 Aug 2013 09:21:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQFAMQ5FlLGmAcV/2dsb2JhbABagkMjITVRwAiBHRZ0giQBAQEBAgEBAQEPG0ELBQcEAgEIDQQEAQEBCh0HIQYLFAkIAgQOBQgah1wDCQYBC5oTkwoNiVETBI1tgkgtBAYBBoMVewOVfAGIOYVhhSmDH4Ir X-IronPort-AV: E=Sophos;i="4.89,935,1367985600"; d="scan'208,217";a="25121811" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Aug 2013 12:21:02 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Aug 2013 12:16:50 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Thu, 22 Aug 2013 12:21:01 -0400 From: "Romascanu, Dan (Dan)" To: Mary Barnes Thread-Topic: [sipcore] Websocket transport in SNMP Thread-Index: AQHOnzaWURj7O4fuckG5zprJmUbsOpmhgKeA///A4NCAAFFXgP//1ccw Date: Thu, 22 Aug 2013 16:21:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B5E5E@AZ-FFEXMB04.global.avaya.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <52161639.2050509@alum.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA128B5ABE@AZ-FFEXMB04.global.avaya.com> In-Reply-To: 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: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA128B5E5EAZFFEXMB04globa_" MIME-Version: 1.0 Cc: "sipcore@ietf.org" 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: Thu, 22 Aug 2013 16:21:12 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA128B5E5EAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Of course, sorry for the imprecision :) From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Thursday, August 22, 2013 5:52 PM To: Romascanu, Dan (Dan) Cc: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] Websocket transport in SNMP Dan, you mean a product of the SIP WG - correct (i.e., not SIP MIB WG)? On Thu, Aug 22, 2013 at 9:03 AM, Romascanu, Dan (Dan) > wrote: Hi Paul, > Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP, > MMUSIC, having been involved in creation of SIP MIBs. Actually RFC 4780 was the product of the SIP MIB WG. Regards, Dan > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:s= ipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, August 22, 2013 4:47 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Websocket transport in SNMP > > Just to clarify my position on this: > > I recognize that MIBs have value. > But its not an area for which I have any experience, knowledge, or > interest. > But if SIPCORE is the proper place to do the work, and there are people > willing and able to do it, then I have no objection to the work being > done in SIPCORE. > > Thanks, > Paul > > > On 8/22/13 8:53 AM, Olle E. Johansson wrote: > > During the IETF in Berlin I had a discussion with Adam (as chair) > > about the need for updating the SNMP MIBs for SIP as we add a new > > transport. I tried to discuss it with Paul, but noticed that he > > silently began thinking about completely different things while > > running away. :-) > > > > I contacted the ops and mib people wg and they clearly said it's our > responsibility in sipcore to update the TC that includes the transport > bits. > > > > Just for the archives and a todo-list somewhere in the cloud. > > > > /O > > _______________________________________________ > > 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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_9904FB1B0159DA42B0B887B7FA8119CA128B5E5EAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Of course, sorry for the = imprecision J

 <= /p>

 <= /p>

From: Mary Bar= nes [mailto:mary.ietf.barnes@gmail.com]
Sent: Thursday, August 22, 2013 5:52 PM
To: Romascanu, Dan (Dan)
Cc: Paul Kyzivat; sipcore@ietf.org
Subject: Re: [sipcore] Websocket transport in SNMP=

 

Dan, you mean a product of the SIP WG - correct (i.e= ., not SIP MIB WG)? 

 

On Thu, Aug 22, 2013 at 9:03 AM, Romascanu, Dan (Dan= ) <dromasca@avay= a.com> wrote:

Hi Paul,


> Nor am I aware of the SIPCORE wg, or its ancestor wgs SIP,
> MMUSIC, having been involved in creation of SIP MIBs.

Actually RFC 4780 was the product of the SIP MIB WG.=


Regards,

Dan




> -----Original Message-----
> From: sipcore-bounces@ietf= .org [mailto:sipcore-bounce= s@ietf.org] On

> Behalf Of Paul Kyzivat
> Sent: Thursday, August 22, 2013 4:47 PM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Websocket transport in SNMP
>
> Just to clarify my position on this:
>
> I recognize that MIBs have value.
> But its not an area for which I have any experience, knowledge, or
> interest.

> But if SIPCORE is the proper place to do the wo= rk, and there are people
> willing and able to do it, then I have no objection to the work being<= br> > done in SIPCORE.
>
>       Thanks,
>       Paul
>
>
> On 8/22/13 8:53 AM, Olle E. Johansson wrote:
> > During the IETF in Berlin I had a discussion with Adam (as chair)=
> > about the need for updating the SNMP MIBs for SIP as we add a new=
> > transport. I tried to discuss it with Paul, but noticed that he > > silently began thinking about completely different things while > > running away. :-)
> >
> > I contacted the ops and mib people wg and they clearly said it's = our
> responsibility in sipcore to update the TC that includes the transport=
> bits.
> >
> > Just for the archives and a todo-list somewhere in the cloud.
> >
> > /O
> > _______________________________________________
> > 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
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA128B5E5EAZFFEXMB04globa_-- From dromasca@avaya.com Thu Aug 22 09:24:46 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 0179411E81CD for ; Thu, 22 Aug 2013 09:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.351 X-Spam-Level: X-Spam-Status: No, score=-103.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 bVUecaYea2CN for ; Thu, 22 Aug 2013 09:24:40 -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 903DE11E8200 for ; Thu, 22 Aug 2013 09:24:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAD46FlLGmAcV/2dsb2JhbABaDoJYITVRwAiBHRZ0giQBAQEBAgEBAQEPKDQQBwQCAQgNAQMEAQEBChQJBycLFAkIAgQBEggah2gGAQuaFpxoEwSQNTgGgxV7A542iwqCYD+CKw X-IronPort-AV: E=Sophos;i="4.89,935,1367985600"; d="scan'208";a="24665732" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Aug 2013 12:24:39 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Aug 2013 12:20:27 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 22 Aug 2013 12:24:38 -0400 From: "Romascanu, Dan (Dan)" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Websocket transport in SNMP Thread-Index: AQHOnzaWURj7O4fuckG5zprJmUbsOpmhlhEAgAAVq4D//709wA== Date: Thu, 22 Aug 2013 16:24:37 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B5E7F@AZ-FFEXMB04.global.avaya.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> <52163A5D.9090203@alum.mit.edu> In-Reply-To: <52163A5D.9090203@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: Thu, 22 Aug 2013 16:24:46 -0000 > For instance, is it really necessary for MIBs to have their own > definitions for things that exist in IANA registries? Or should addition > to a registry automatically enable support in the MIB? > This is not possible, I am afraid. There is no such level of 'automation' i= n definition of MIB modules. There is something that can be done however - = to make the TC a separate module that is maintained by IANA, so that adding= new enumeration values can be made by IANA (as values are added in the reg= istry) instead of requiring the modification of the RFC each time.=20 Regards, Dan > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, August 22, 2013 7:21 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Websocket transport in SNMP >=20 > On 8/22/13 11:03 AM, Hadriel Kaplan wrote: > > > > I'm not sure if SIPCORE is the right WG... not that I think it matters > much where it's done. > > But just adding another enumeration bit value to > SipTCTransportProtocol is pretty uncontroversial and could just be done > with AD sponsorship instead of a WG, imo. >=20 > *If* that is all that is required, and its clear to those who manage > such things that this is the correct way to do it, then I agree. >=20 > IMO the main point of doing it in a WG is so that knowledgeable people > will review it and comment if there are better ways, or other things > that should be considered, etc. >=20 > For instance, is it really necessary for MIBs to have their own > definitions for things that exist in IANA registries? Or should addition > to a registry automatically enable support in the MIB? >=20 > I can ask that question in the abstract, unemcumbered with any knowledge > of existing practice in MIBs, technological limitations, etc. But I > expect that there are a set of people equipped to have that discussion. > I just don't know if they are in the sipcore wg. >=20 > Thanks, > Paul >=20 > > Regardless, does anyone actually implement and use the SIP MIB? > > > > -hadriel > > > > > > On Aug 22, 2013, at 8:53 AM, Olle E. Johansson wrote: > > > >> During the IETF in Berlin I had a discussion with Adam (as chair) > >> about the need for updating the SNMP MIBs for SIP as we add a new > >> transport. I tried to discuss it with Paul, but noticed that he > >> silently began thinking about completely different things while > >> running away. :-) > >> > >> I contacted the ops and mib people wg and they clearly said it's our > responsibility in sipcore to update the TC that includes the transport > bits. > >> > >> Just for the archives and a todo-list somewhere in the cloud. > >> > >> /O > >> _______________________________________________ > >> 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 > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From oej@edvina.net Thu Aug 22 09:51:00 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 225D911E80E3 for ; Thu, 22 Aug 2013 09:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 NKoWec96uss0 for ; Thu, 22 Aug 2013 09:50:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0205511E80FC for ; Thu, 22 Aug 2013 09:50:57 -0700 (PDT) Received: from [192.168.40.38] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 03D3193DE53; Thu, 22 Aug 2013 16:50:48 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_0CAFE938-B533-46DF-A347-5023E7A7524F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <09AC0CC5-B63E-4D6D-B66B-E63BBD85FEAC@oracle.com> Date: Thu, 22 Aug 2013 18:50:47 +0200 Message-Id: <0148B625-2D50-4337-BC5E-E16304D6DAE9@edvina.net> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> <09AC0CC5-B63E-4D6D-B66B-E63BBD85FEAC@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "sipcore@ietf.org WG" 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: Thu, 22 Aug 2013 16:51:00 -0000 --Apple-Mail=_0CAFE938-B533-46DF-A347-5023E7A7524F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 22 aug 2013 kl. 17:23 skrev Hadriel Kaplan : >=20 > On Aug 22, 2013, at 11:14 AM, Olle E. Johansson = wrote: >=20 >>=20 >> 22 aug 2013 kl. 17:03 skrev Hadriel Kaplan = : >>=20 >>>=20 >>> I'm not sure if SIPCORE is the right WG... not that I think it = matters much where it's done. >>> But just adding another enumeration bit value to = SipTCTransportProtocol is pretty uncontroversial and could just be done = with AD sponsorship instead of a WG, imo. >>>=20 >>> Regardless, does anyone actually implement and use the SIP MIB? >> We have an implementation in Kamailio. >=20 > Really? I'll have to take a look at Kamailio's implementation = sometime. Did you only implement a very few specific things from it? =20= We have not implemented all, but a subset that matches. >=20 > When we looked at the MIB years ago, I think there was physical = laughter. :)=20 I can understand why. Some parts are innovative. /O >=20 > -hadriel >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_0CAFE938-B533-46DF-A347-5023E7A7524F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hadriel.kaplan@oracle.com>= ;:

On Aug 22, 2013, at 11:14 AM, Olle E. Johansson <oej@edvina.net> = wrote:


22 aug 2013 kl. 17:03 skrev = Hadriel Kaplan <hadriel.kaplan@oracle.com>= ;:


I'm not sure if SIPCORE is the = right WG... not that I think it matters much where it's done.
But = just adding another enumeration bit value to SipTCTransportProtocol is = pretty uncontroversial and could just be done with AD sponsorship = instead of a WG, imo.

Regardless, does anyone actually implement = and use the SIP MIB?
We have an implementation in = Kamailio.

Really?  I'll have to take a look at = Kamailio's implementation sometime.  Did you only implement a very = few specific things from it?  
We have not = implemented all, but a subset that matches.

When we looked at the MIB years ago, I think there was = physical laughter. :)
I can understand why. Some parts = are innovative.

/O

-hadriel


---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_0CAFE938-B533-46DF-A347-5023E7A7524F-- From hadriel.kaplan@oracle.com Thu Aug 22 11:43:07 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 E005921F9EF0 for ; Thu, 22 Aug 2013 11:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rD4570GxDF3k for ; Thu, 22 Aug 2013 11:43:01 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD1E21F9C6E for ; Thu, 22 Aug 2013 11:43:00 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7MIgrsh017132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 18:42:55 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MIgqVj025167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 18:42:53 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MIgqD7025147; Thu, 22 Aug 2013 18:42:52 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Aug 2013 11:42:52 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <0148B625-2D50-4337-BC5E-E16304D6DAE9@edvina.net> Date: Thu, 22 Aug 2013 14:42:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "sipcore@ietf.org WG" 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: Thu, 22 Aug 2013 18:43:08 -0000 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. :)=20 > I can understand why. Some parts are innovative. Uh huh. Name one innovative part. =20 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 From stpeter@stpeter.im Thu Aug 22 11:51:58 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 052E211E81F5 for ; Thu, 22 Aug 2013 11:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, 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 d7wk2X8Pj+Lq for ; Thu, 22 Aug 2013 11:51:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5511E820A for ; Thu, 22 Aug 2013 11:51:53 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 40D20414D6; Thu, 22 Aug 2013 12:55:18 -0600 (MDT) Message-ID: <52165DC6.4020504@stpeter.im> Date: Thu, 22 Aug 2013 12:51:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan 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> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org WG" , "Olle E. Johansson" 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: Thu, 22 Aug 2013 18:51:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/22/13 12:42 PM, Hadriel Kaplan wrote: > > 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. FWIW and IMHO, this is why there hasn't been much interest in a MIB for XMPP. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSFl3GAAoJEOoGpJErxa2pZQgP+gPMH6Uc7b1ALxW/aOqC8bVP 00OOHlQEtnk7evfN8jInTrqZEwcv3K5n7DmTsGTkhNY5yt7UbLxepKcSNlYgtdMk tzhSF86VXZ5TCx0Wh5iwlBpaYZq+HSIjN0d8fREIc9ss8H7jxQehur8ZzsFEAIKU WDGQnB+xSB9d21RXeqWlg/P+9ay2m+x49GwmcMYEElyh0hUzAbCQ0XvYuB98A7GL kRL+RmYbyUE6Q0ToV/hEkCoHjrq4SDRzd3t4B/YHfwhkWF3FNRHfgv8FxAaT3sZX z+6Z63cFNe5sV6PBfVFq5EhBGSM3BoTRrVA6juKqAsJX2pXNqXfyYLacE73/75Jv Q0oCPDhZ9jqrNmDvZiY/AUkSUylkQU5mYa//uiGsGzz4SjEESrwcCzxmk9wCb5pH jw0W87nwKzwiZvCRbRuOEbDvYMhmQ/tF90/WxQ3V+Zsz0CO+LhqGoCtxBDjl4csB qdYd4TfTgnxu+hTtNQqc3q4Fc9Mul6xI7B0XJe0fyhdczgmpaLxRgfd2yY8fkvKp Yht8W0NR6Qmh5qKh9XvjmGaHOMcJC6EebADmpni/bXdifPkphjBUPk7ux/8r4uUL +fWLG1RwnGuo5hGK99PPjFkRfSg5Td64CBxYEOHcCq2PqEyJgRq1racfui5qmAbU byBYEpJQ6B12Ft9S1kMk =S3yB -----END PGP SIGNATURE----- From oej@edvina.net Thu Aug 22 12:12:47 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 9E5F221F9A37 for ; Thu, 22 Aug 2013 12:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 8elFMPhsUp28 for ; Thu, 22 Aug 2013 12:12:47 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id EEE1C21F9B0A for ; Thu, 22 Aug 2013 12:12:42 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id B3A6393C1AF; Thu, 22 Aug 2013 19:12:40 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <52165DC6.4020504@stpeter.im> Date: Thu, 22 Aug 2013 21:12:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C7D3D9E-64E9-4D63-8C7F-13086E33CB98@edvina.net> 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> <52165DC6.4020504@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1508) Cc: "sipcore@ietf.org WG" 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: Thu, 22 Aug 2013 19:12:47 -0000 22 aug 2013 kl. 20:51 skrev Peter Saint-Andre : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 8/22/13 12:42 PM, Hadriel Kaplan wrote: >>=20 >> On Aug 22, 2013, at 12:50 PM, Olle E. Johansson =20 >> wrote: >>=20 >>>> When we looked at the MIB years ago, I think there was >>>> physical laughter. :) >>> I can understand why. Some parts are innovative. >>=20 >> Uh huh. Name one innovative part. >>=20 >> 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. >=20 > FWIW and IMHO, this is why there hasn't been much interest in a MIB > for XMPP. I agree. But we've taken bits and pieces as inspiration. That's a good = start. Starting all over again is a lot of work. If it's only we, then there's no point in updating the RFC. I have = already added the missing bit in Kamailio. /O= From pkyzivat@alum.mit.edu Thu Aug 22 13:09:05 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 6EB9D21F9F23 for ; Thu, 22 Aug 2013 13:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 qPItQY46r9zc for ; Thu, 22 Aug 2013 13:09:00 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 66A3721F9FDA for ; Thu, 22 Aug 2013 13:09:00 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id Fqcp1m00M0bG4ec5Aw8xzD; Thu, 22 Aug 2013 20:08:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Fw8x1m00c3ZTu2S3Pw8x0d; Thu, 22 Aug 2013 20:08:57 +0000 Message-ID: <52166FD7.8030109@alum.mit.edu> Date: Thu, 22 Aug 2013 16:08:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> <52163A5D.9090203@alum.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA128B5E7F@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128B5E7F@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377202137; bh=k8JpgEA635Y3mhEvoSk0T2CgFbcJcDygOpjOrEIB250=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=l2BKXFd1rBK3Vu6iKiAOSpR5gnIR/1eCiqnXpEvZC0Bu8Xzt683jcgC4B7c/ggEsE hAYaqoH5nw0O/484l+J9SbOgEvK2+knSs7xBMBEFineUpW3rsup3+apeYWp3tCBahZ 99jRRseHqcYYQVjm+3zgT9a/kle1r/BzqsyboAcICcWLKI2VML6QjRyRr+bdpRy1oi pscnpZivMvvt0VLUCIql6lWi8TcWeZ9FvEM9pXCbbYFjwxeAIdD7CkhfYl4PbPuv8/ t0uKOqDXZjqt8FZ5EJDj9TK+Oi1/1AZ+djla1qF3IayMWf1k1l42yONUNKGcMdRg7H 3DdxYbXeLBZfw== Cc: "sipcore@ietf.org" 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: Thu, 22 Aug 2013 20:09:05 -0000 On 8/22/13 12:24 PM, Romascanu, Dan (Dan) wrote: >> For instance, is it really necessary for MIBs to have their own >> definitions for things that exist in IANA registries? Or should addition >> to a registry automatically enable support in the MIB? >> > > This is not possible, I am afraid. There is no such level of 'automation' in definition of MIB modules. There is something that can be done however - to make the TC a separate module that is maintained by IANA, so that adding new enumeration values can be made by IANA (as values are added in the registry) instead of requiring the modification of the RFC each time. Then perhaps we should introduce something into IANA registries that indicates "when this registry is updated the xxx MIB definition must also be updated". Thanks, Paul > Regards, > > Dan > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, August 22, 2013 7:21 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Websocket transport in SNMP >> >> On 8/22/13 11:03 AM, Hadriel Kaplan wrote: >>> >>> I'm not sure if SIPCORE is the right WG... not that I think it matters >> much where it's done. >>> But just adding another enumeration bit value to >> SipTCTransportProtocol is pretty uncontroversial and could just be done >> with AD sponsorship instead of a WG, imo. >> >> *If* that is all that is required, and its clear to those who manage >> such things that this is the correct way to do it, then I agree. >> >> IMO the main point of doing it in a WG is so that knowledgeable people >> will review it and comment if there are better ways, or other things >> that should be considered, etc. >> >> For instance, is it really necessary for MIBs to have their own >> definitions for things that exist in IANA registries? Or should addition >> to a registry automatically enable support in the MIB? >> >> I can ask that question in the abstract, unemcumbered with any knowledge >> of existing practice in MIBs, technological limitations, etc. But I >> expect that there are a set of people equipped to have that discussion. >> I just don't know if they are in the sipcore wg. >> >> Thanks, >> Paul >> >>> Regardless, does anyone actually implement and use the SIP MIB? >>> >>> -hadriel >>> >>> >>> On Aug 22, 2013, at 8:53 AM, Olle E. Johansson wrote: >>> >>>> During the IETF in Berlin I had a discussion with Adam (as chair) >>>> about the need for updating the SNMP MIBs for SIP as we add a new >>>> transport. I tried to discuss it with Paul, but noticed that he >>>> silently began thinking about completely different things while >>>> running away. :-) >>>> >>>> I contacted the ops and mib people wg and they clearly said it's our >> responsibility in sipcore to update the TC that includes the transport >> bits. >>>> >>>> Just for the archives and a todo-list somewhere in the cloud. >>>> >>>> /O >>>> _______________________________________________ >>>> 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 >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From dromasca@avaya.com Fri Aug 23 01:30: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 0DCC911E80FD for ; Fri, 23 Aug 2013 01:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.363 X-Spam-Level: X-Spam-Status: No, score=-103.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 Oe0WhmTyhxRb for ; Fri, 23 Aug 2013 01:30:25 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A5D5C11E80F2 for ; Fri, 23 Aug 2013 01:30:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAKYcF1LGmAcV/2dsb2JhbABaDoJYITVRv36BHxZ0giQBAQEBAwEBAQ8oNAsMBAIBCA0BAwQBAQEKFAkHJwsUCQgCBA4FCBqHbgELmiWcWxMEkDUxBwaDFXsDnjaLCoJgP4Ir X-IronPort-AV: E=Sophos;i="4.89,939,1367985600"; d="scan'208";a="21002623" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Aug 2013 04:30:20 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Aug 2013 04:26:05 -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; Fri, 23 Aug 2013 10:30:18 +0200 From: "Romascanu, Dan (Dan)" To: Paul Kyzivat Thread-Topic: [sipcore] Websocket transport in SNMP Thread-Index: AQHOnzaWURj7O4fuckG5zprJmUbsOpmhlhEAgAAVq4D//709wIAAgoOAgACLnPA= Date: Fri, 23 Aug 2013 08:30:17 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B63F7@AZ-FFEXMB04.global.avaya.com> References: <4A434401-CEB9-4E8B-815D-6AB3B2DDCA07@edvina.net> <3DC67FF2-E613-412D-A02C-CAD8882BE532@oracle.com> <52163A5D.9090203@alum.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA128B5E7F@AZ-FFEXMB04.global.avaya.com> <52166FD7.8030109@alum.mit.edu> In-Reply-To: <52166FD7.8030109@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.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" 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: Fri, 23 Aug 2013 08:30:31 -0000 Yep, ways can be found to synchronize the content of the IANA registry with= the enumeration in an IANA-maintained TC. Regards, Dan > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, August 22, 2013 11:09 PM > To: Romascanu, Dan (Dan) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Websocket transport in SNMP >=20 > On 8/22/13 12:24 PM, Romascanu, Dan (Dan) wrote: > >> For instance, is it really necessary for MIBs to have their own > >> definitions for things that exist in IANA registries? Or should > >> addition to a registry automatically enable support in the MIB? > >> > > > > This is not possible, I am afraid. There is no such level of > 'automation' in definition of MIB modules. There is something that can > be done however - to make the TC a separate module that is maintained by > IANA, so that adding new enumeration values can be made by IANA (as > values are added in the registry) instead of requiring the modification > of the RFC each time. >=20 > Then perhaps we should introduce something into IANA registries that > indicates "when this registry is updated the xxx MIB definition must > also be updated". >=20 > Thanks, > Paul >=20 > > Regards, > > > > Dan > > > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Thursday, August 22, 2013 7:21 PM > >> To: sipcore@ietf.org > >> Subject: Re: [sipcore] Websocket transport in SNMP > >> > >> On 8/22/13 11:03 AM, Hadriel Kaplan wrote: > >>> > >>> I'm not sure if SIPCORE is the right WG... not that I think it > >>> matters > >> much where it's done. > >>> But just adding another enumeration bit value to > >> SipTCTransportProtocol is pretty uncontroversial and could just be > >> done with AD sponsorship instead of a WG, imo. > >> > >> *If* that is all that is required, and its clear to those who manage > >> such things that this is the correct way to do it, then I agree. > >> > >> IMO the main point of doing it in a WG is so that knowledgeable > >> people will review it and comment if there are better ways, or other > >> things that should be considered, etc. > >> > >> For instance, is it really necessary for MIBs to have their own > >> definitions for things that exist in IANA registries? Or should > >> addition to a registry automatically enable support in the MIB? > >> > >> I can ask that question in the abstract, unemcumbered with any > >> knowledge of existing practice in MIBs, technological limitations, > >> etc. But I expect that there are a set of people equipped to have > that discussion. > >> I just don't know if they are in the sipcore wg. > >> > >> Thanks, > >> Paul > >> > >>> Regardless, does anyone actually implement and use the SIP MIB? > >>> > >>> -hadriel > >>> > >>> > >>> On Aug 22, 2013, at 8:53 AM, Olle E. Johansson > wrote: > >>> > >>>> During the IETF in Berlin I had a discussion with Adam (as chair) > >>>> about the need for updating the SNMP MIBs for SIP as we add a new > >>>> transport. I tried to discuss it with Paul, but noticed that he > >>>> silently began thinking about completely different things while > >>>> running away. :-) > >>>> > >>>> I contacted the ops and mib people wg and they clearly said it's > >>>> our > >> responsibility in sipcore to update the TC that includes the > >> transport bits. > >>>> > >>>> Just for the archives and a todo-list somewhere in the cloud. > >>>> > >>>> /O > >>>> _______________________________________________ > >>>> 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 > >>> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > From keith.drage@alcatel-lucent.com Wed Aug 28 07:37:58 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 3B43A21F9D17 for ; Wed, 28 Aug 2013 07:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.616 X-Spam-Level: X-Spam-Status: No, score=-110.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 WRSAFRh0UOfK for ; Wed, 28 Aug 2013 07:37:51 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id A02B421F9E6D for ; Wed, 28 Aug 2013 07:37:51 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7SEbiX8012397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Aug 2013 09:37:45 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r7SEbfxt006365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 16:37:42 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 28 Aug 2013 16:37:41 +0200 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan , "Olle E. Johansson" Thread-Topic: [sipcore] Websocket transport in SNMP Thread-Index: AQHOnzaayFCreM8HKUGNXjN8ngWUeZmhMXwAgAADCoCAAAK6AIAAGEuAgAAfTgCACUnMIA== Date: Wed, 28 Aug 2013 14:37:41 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B08A34C@FR712WXCHMBA11.zeu.alcatel-lucent.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> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "sipcore@ietf.org WG" 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: Wed, 28 Aug 2013 14:37:58 -0000 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 ex= perts, therefore it was progressed on the basis that what was there was cor= rect, 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 ensur= e it was complete. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > 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 >=20 >=20 > On Aug 22, 2013, at 12:50 PM, Olle E. Johansson wrote: >=20 > >> When we looked at the MIB years ago, I think there was physical > laughter. :) > > I can understand why. Some parts are innovative. >=20 > Uh huh. Name one innovative part. >=20 > 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. >=20 > 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. >=20 > 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". >=20 > 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. :) >=20 > -hadriel >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed Aug 28 10:27:24 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 60F0921E804D for ; Wed, 28 Aug 2013 10:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 HTcmrkD0JIrY for ; Wed, 28 Aug 2013 10:27:18 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 37C7721F9C32 for ; Wed, 28 Aug 2013 10:27:17 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta02.westchester.pa.mail.comcast.net with comcast id JCzU1m0061vXlb851HT6EF; Wed, 28 Aug 2013 17:27:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id JHT61m0133ZTu2S3dHT6ie; Wed, 28 Aug 2013 17:27:06 +0000 Message-ID: <521E32E9.6050809@alum.mit.edu> Date: Wed, 28 Aug 2013 13:27:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <20130729073108.1851.41406.idtracker@ietfa.amsl.com> <202BC05C-3463-4E7A-AAF0-6367975119EB@oracle.com> <51F684D9.6040204@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377710826; bh=0hHOqbcc/Kczkyw0Dcu33zMV6URtrWihC/qiUu+fNWc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eWiQL2u6TOHv3x33sZp2M6XU0qY9EqBhgroGUkvySjDgcgqIoRysz+5ZLVHBE7ZcZ sxRqDpzUCyZRH6wAn2WRsrpvMSFOY9VYU3KTYm18a0gRo9Uay/25kp7YzA7yXznf6n iJ2nacL8xQ6x+EnFRpa11WpfBlesaoJKWM9nEI1+/UPvk++PuRqW8PNIkPKXfOl39O 2+ccSJsY3+nuy7UpOuzxBgy3qbarum1AM/TOnhiABmIsisPi1nuxipxSJEawdVfHD6 BEaeqx+cJad1n6AODDe6S+iQCs4PJhtVZQMQQycBhzEW8R2gpBQar5KXty5kZWxh0O 1PdkqiEo0DESg== Cc: SIPCORE Subject: Re: [sipcore] [dispatch] Dispatch request: draft-kaplan-dispatch-sip-205-response-00 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: Wed, 28 Aug 2013 17:27:24 -0000 I was just reminded that conversation stopped when the token was probably with me to respond. I'm taking it to the sipcore list. On 7/30/13 3:13 AM, Hadriel Kaplan wrote: > > On Jul 29, 2013, at 11:06 AM, Paul Kyzivat wrote: > >> Hadriel, >> >> As sipcore co-chair, I also think sipcore will ultimately be the right place for this. But it may be valuable to leave it on dispatch for awhile. My main concern is that we talk through whether the decision to use 205 is well defined, and if introducing this will solve any problems. (And I say this in spite of this having been (IIRC) my suggestion in the first place.) >> >> It is far from clear to me whether there can be clear rules for when to use 205. >> - Should it be used whenever a call has been forwarded? > > By "call forwarded", you mean the call/dialog is answered/established at a SIP layer, but then the UAS makes a separate second call to another UA and ultimately bridges the media together? When I wrote this I was thinking of a target change while routing the original INVITE. Of course, it makes no sense to do for every one of these, since that includes mapping an AOR to a registered contact. So that rule is too simple. But can a clear rule be defined? This starts to smell like the rules used to tag H-I entries. :-( >> - Should a VM server use it? (In some sense the VM server is an agent >> of the callee, and is entitled to use 200.) > > You used the phrase "entitled to use 200", IMO the spec should give some guidance for when to use this. The cases where is must or may use it are "entitled", while others are not. I think the guidance is something like "this is not the intended destination for the call". > but the way I tried writing the 205 draft was not to mandate VMs to use 205 - it was to *allow* them to use 205. In other words, a VM (or its operator) can decide whether to send a 205 or not, based on what it wants the UAC to do. The rationale for sending a 205 would be to save resources on the VM, because in theory the UAC can know it's been redirected to voicemail and can hang up immediately. (I'm not saying the draft is good enough yet to make the distinction that it's reached a VM, but that can be worked on...) Its fair enough to give discretion over when to use this. But then there must be some expectation for what will be different if I use 205 rather than 200, to drive my decision. In the case of VM, I think there can be some debate whether the VM server is one of the legitimate intended destinations of a call or not. Whether that is justification for discretion on the part of the server depends on whether you think that server is the right place to decide that. It may be that we should just decide once and for all. >> It is also not clear to me that it will solve the traceroute problem. >> - what if the call is forwarded. Then it might get a 205, but not for >> the right reason. Will that be sufficient to stop the traceroute? > > Yes - the Reason header will have a cause code of 483 when it's answered by the B2BUA for the traceroute purpose. Once the testing UAC increases Max-Forwards, the next 205 would have a different Reason code. OK. Thanks, Paul From pkyzivat@alum.mit.edu Wed Aug 28 10:46:23 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 EC12111E81B9 for ; Wed, 28 Aug 2013 10:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 cqlAuQAEojIL for ; Wed, 28 Aug 2013 10:46:19 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 6881111E8196 for ; Wed, 28 Aug 2013 10:46:05 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta10.westchester.pa.mail.comcast.net with comcast id JBDQ1m00D0bG4ec5AHm4tx; Wed, 28 Aug 2013 17:46:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id JHm41m01B3ZTu2S3PHm4if; Wed, 28 Aug 2013 17:46:04 +0000 Message-ID: <521E375C.9090805@alum.mit.edu> Date: Wed, 28 Aug 2013 13:46:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org, "Romascanu, Dan ((Dan))" 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> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B08A34C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377711964; bh=Y4QwPnnfYixnek83a13oLXBfHTRcXH9PQoF6FeN/8W8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h6uWtPv4JPyDgj13mzuKEv0tmtoB1fVGjjjwPmPvv+rGOe6CFj6AeubO2w6GbFUPt AilsjZ2sDOa171BKNIweXHIbJ78Ub8QP8Aa6UY9F8Tsjy2lCh0v2R20OA8Ddo7P5oj Ly8KclcGBbrCb9wkMB0yI9Qy8R3/ls8DzuPxHNaoXL42j0h146eFnm4XVuSc+NBm5U 4dsunmzJLz40dZeRDPTbMUV68Gc2yxUWO4HJ9yQDEGTwPclCktceeDecEG+kA9bFwj XXZ5gzQh/nB/gBjpTjpDuUg2vw4+C20xES9J5gqCCgtAsFXwqNDFNMhgkOcqlzuvyO g3P1CvTeEQb3Q== 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: Wed, 28 Aug 2013 17:46:24 -0000 Keith, I'm glad somebody remembers this. 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. So this issue may open a can of worms. 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: * 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? * 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? Dan - can you give some guidance here? Thanks, Paul > 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 worley@shell01.TheWorld.com Thu Aug 29 08:21:28 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 9015C21F8E70 for ; Thu, 29 Aug 2013 08:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 HKU4G7W7mp8J for ; Thu, 29 Aug 2013 08:21:13 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1216121F90FD for ; Thu, 29 Aug 2013 08:21:11 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r7TFKvof029443 for ; Thu, 29 Aug 2013 11:21:01 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r7TFKs4J195834 for ; Thu, 29 Aug 2013 11:20:55 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r7TFKqhn195816; Thu, 29 Aug 2013 11:20:52 -0400 (EDT) Date: Thu, 29 Aug 2013 11:20:52 -0400 (EDT) Message-Id: <201308291520.r7TFKqhn195816@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] Comments on draft-kaplan-dispatch-sip-205-response-00 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: Thu, 29 Aug 2013 15:21:28 -0000 It's not clear to me why we need a separate response code for this function. It seems to me that the same functionality could be obtained with a 200 response with an additional header that means "I may not be the droid you're looking for." The concept of "not the originally intended target" doesn't seem to be defined anywhere. For the 205 code to be useful, the UAC and UAS need to have the same understanding of that phrase; that is, it must be standardized. That may be difficult in light of the possibility for multiple redirections between UAC and UAS. We should also note that using the Reason header in responses to carry SIP response codes isn't defined generally; the suggested use of Reason is an extension relative to previous practice. That meshes with the fact that the suggested examples of Reason in the draft explicitly define what those examples mean ... which means that we need to provide an explicit definition of the meaning of Reason with a SIP response code in a response. Dale From pkyzivat@alum.mit.edu Thu Aug 29 09:22:00 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 AFA4621E80A1 for ; Thu, 29 Aug 2013 09:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 UaKZaUscpUev for ; Thu, 29 Aug 2013 09:21:53 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id E560E21F9D75 for ; Thu, 29 Aug 2013 09:21:34 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id Jfsj1m0051GhbT85FgMaaH; Thu, 29 Aug 2013 16:21:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id JgMZ1m01q3ZTu2S3TgMZeQ; Thu, 29 Aug 2013 16:21:34 +0000 Message-ID: <521F750D.5020802@alum.mit.edu> Date: Thu, 29 Aug 2013 12:21:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: sipcore@ietf.org References: <201308291520.r7TFKqhn195816@shell01.TheWorld.com> In-Reply-To: <201308291520.r7TFKqhn195816@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377793294; bh=e5aPfjDfeS08E+t5X+RsRYBHyJP+Wm/xFdUKi5DlPpU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ipb9O8YWVROho+85BmHuv9lW1f5HE60mz7tL8R78Vi3QuHfugA9clw7ab4lLIAwrb RNXRtoqk6DX740JSzZm8KtZbvgBfL9oUo8Jamwlc7ueY3jq4T3fiJs6lE+JSP2w0SA GXyl9V2IEWDB4KGyj/rHhUKQlyOynGLmYhaOeuxIN+yhNp5shksvspCFcr9wHY1hoF 4i/042aNx2BJbGsnOvkSd6OLgHOC0zMvxrVxheN+LWCI4qsS+QeprzaOZHlCKy0zcy RouZaPZv/qjUXPyx1grNK5qGrJ+FQ5Zdj7+TF49liSvT3ILK8Txg5Hd8F37665KaFg b2YOAxutKNipQ== Subject: Re: [sipcore] Comments on draft-kaplan-dispatch-sip-205-response-00 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: Thu, 29 Aug 2013 16:22:00 -0000 On 8/29/13 11:20 AM, Dale R. Worley wrote: > It's not clear to me why we need a separate response code for this > function. It seems to me that the same functionality could be > obtained with a 200 response with an additional header that means "I > may not be the droid you're looking for." Sure. That would also work. But a different response seems to serve the purpose without cluttering things up with a new header. > The concept of "not the originally intended target" doesn't seem to be > defined anywhere. For the 205 code to be useful, the UAC and UAS need > to have the same understanding of that phrase; that is, it must be > standardized. That may be difficult in light of the possibility for > multiple redirections between UAC and UAS. This is indeed the think that needs to be sorted out - can we come up with a clear and useful definition of this. The case that prompted this proposal is pretty clear - the routing process has been truncated due to max-forwards reaching zero. Normally that would be an error. But in this case we want it to be a success, but its a special kind of success. If we define a code for that specific case, should it be generalized to any other cases? The one that comes to mind is redirection, to a device that doesn't speak for the AOR. But that itself is a fuzzy concept. - At one extreme, a proxy acting for the *caller* my intercept a call that has been ringing too long and send it to an IVR that asks what you want to do. IMO that would qualify as not being the intended target. - At the other extreme, a proxy acting for the *callee* (target AOR) might intercept a call that has been ringing too long and send it do an IVR to do VM. Depending on your point of view, you might consider that to be an unintended target, or not. (If the call includes caller preferences saying that it doesn't want to talk to an automaton, and it is still routed to an automaton, then it might be clearer.) The simple answer would be to say that this code is *only* for the max-forwards case. > We should also note that using the Reason header in responses to carry > SIP response codes isn't defined generally; the suggested use of > Reason is an extension relative to previous practice. That meshes > with the fact that the suggested examples of Reason in the draft > explicitly define what those examples mean ... which means that we > need to provide an explicit definition of the meaning of Reason with a > SIP response code in a response. Yes. Thanks, Paul