From ops-area-bounces@ietf.org Mon Jun 2 10:40:20 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E753F3A6CC6; Mon, 2 Jun 2008 10:40:20 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0333A6CC0 for ; Mon, 2 Jun 2008 10:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKJfT55PDTz4 for ; Mon, 2 Jun 2008 10:40:20 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 027133A6D1D for ; Mon, 2 Jun 2008 10:34:32 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Yywr1Z00C0cZkys570V700; Mon, 02 Jun 2008 17:34:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id Z5aZ1Z00T4HwxpC3W00000; Mon, 02 Jun 2008 17:34:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=KOiMaYgTFfs3SSyOaT4A:9 a=RYaAAaDqTmz_yTJOp6wA:7 a=lyoDfgH1Eny3J9ymYpHSa_rXC2IA:4 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Phil Shafer'" References: <003101c8c109$cca067f0$0600a8c0@china.huawei.com> <200806021509.m52F9kW4061621@idle.juniper.net> Date: Mon, 2 Jun 2008 13:34:33 -0400 Message-ID: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjEwwdJhaZnq02XRKuJWvQpudu1aAADrWJQ In-Reply-To: <200806021509.m52F9kW4061621@idle.juniper.net> Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Monday, June 02, 2008 11:10 AM > To: David Harrington > Cc: ops-dir@ietf.org; 'OPS Area' > Subject: Re: [OPS-DIR] SNMP notification configuration > > "David Harrington" writes: > >For SNMP notifications, the SNMP agent will need to act as an SSH > >client, and the SNMP notification receivers will need to act > as an SSH > >server. Will operators find this objectionable? > > This would require a password/passphrase for an account on the > management station to be included in the device configuration, > right? Many operators will find this objectionable, though one can > make the ssh equivalent on an "anonymous ftp user" will a little > effort. Reachability via firewall (and nat) is also an issue. Yes, we know that NATs can be problematic. Hopefully someday the IETF will figure out how to make NATs less of a problem. > > >Question #2: > >Would operators prefer to modify their existing user and key > >management solutions, such as implementation-dependent CLI > scripts, to > >configure SSH clients on devices where they may not be found now, or > >would operators prefer to have the ISMS WG develop a standard MIB > >module to configure and manage the SSH credentials needed to > have SNMP > >agents act as SSH clients? > > There are few real-world deployment scenarios for MIBs for config > (unless forced) and the big motivation for using ssh is that the > infrastructure is already deployed. So my take is that no one needs > or will use a writable MIB for ssh credentials. Remeber that operators will need to configure the SNMP agents to send notifications, and we have standard MIBs to do that configuration. Lacking the ability to also configure the SSH client credebtials via SNMP means thay must use multiple management interfaces to config SNMP notifications (or not use the SNMPv3 standard MIBs for notifications). > > Another question: Given that NETCONF includes ssh-as-transport and > now has a notification mechanism, would snmp-over-netconf work > better than snmp-over-ssh? It doubt snmp-over-netconf would meet most operators' needs for SNMP notifications. SNMP supports asynchronous notifications. The agent initiates the session when an event occurs. This may occur at any time, and the manager (or notification-receiver) is expected to be listening (more or less) all the time. This is like having your phone ring when somebody calls you. One benefit of this approach is trap-directed-polling, The agent can notify the manager that an event has occured, and the manager can then poll for additional information to determine the nature and importance of the event. I think this is like using an answering machine to screen calls - it tells you who is calling, and maybe what they called about, but you would pick up or call back to get all the details when you're ready to handle the details. Netconf uses a subscribe approach. The client (manager) initiates the session over which the server (agent) will deliver notifications. The notifications can only be delivered if a manager has subscribed and the manager asks for a replay of the notifications it missed while not subscribed, or kept the session open to listen for new notifications. I think of this as polling-directed-traps. I think this is like calling your voicemail to see who called while you weren't home, or calling all your friends to open a long-term phone connection to each in case they want to talk to you later. SNMP notifications have traditionally been close-to-real-time and scalable. I think netconf notifications are great for interactive configuration work. I don't think the netconf subscribe approach is scalable to managing large networks. dbh > > Thanks, > Phil > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 3 02:10:21 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED1883A6914; Tue, 3 Jun 2008 02:10:21 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB98028C170; Mon, 2 Jun 2008 08:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwvh1-gUxebM; Mon, 2 Jun 2008 08:13:25 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 61E143A6CAF; Mon, 2 Jun 2008 08:12:05 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Mon, 02 Jun 2008 08:11:50 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jun 2008 08:11:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m52FBux60068; Mon, 2 Jun 2008 08:11:57 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m52F9kW4061621; Mon, 2 Jun 2008 15:09:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806021509.m52F9kW4061621@idle.juniper.net> To: "David Harrington" In-reply-to: <003101c8c109$cca067f0$0600a8c0@china.huawei.com> Date: Mon, 02 Jun 2008 11:09:46 -0400 From: Phil Shafer X-OriginalArrivalTime: 02 Jun 2008 15:11:57.0447 (UTC) FILETIME=[FFCE5170:01C8C4C2] X-Mailman-Approved-At: Tue, 03 Jun 2008 02:10:19 -0700 Cc: ops-dir@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org "David Harrington" writes: >For SNMP notifications, the SNMP agent will need to act as an SSH >client, and the SNMP notification receivers will need to act as an SSH >server. Will operators find this objectionable? This would require a password/passphrase for an account on the management station to be included in the device configuration, right? Many operators will find this objectionable, though one can make the ssh equivalent on an "anonymous ftp user" will a little effort. Reachability via firewall (and nat) is also an issue. >Question #2: >Would operators prefer to modify their existing user and key >management solutions, such as implementation-dependent CLI scripts, to >configure SSH clients on devices where they may not be found now, or >would operators prefer to have the ISMS WG develop a standard MIB >module to configure and manage the SSH credentials needed to have SNMP >agents act as SSH clients? There are few real-world deployment scenarios for MIBs for config (unless forced) and the big motivation for using ssh is that the infrastructure is already deployed. So my take is that no one needs or will use a writable MIB for ssh credentials. Another question: Given that NETCONF includes ssh-as-transport and now has a notification mechanism, would snmp-over-netconf work better than snmp-over-ssh? (And does this mean the next version of the Simple Book would refer to the operator? ;^) Thanks, Phil _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 3 07:39:23 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24AC3A683F; Tue, 3 Jun 2008 07:39:23 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC223A6849; Tue, 3 Jun 2008 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuY+4KoHAMb2; Tue, 3 Jun 2008 07:37:57 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id E6D7528C18B; Tue, 3 Jun 2008 07:36:38 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 07:36:40 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 07:36:34 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53EaXx87212; Tue, 3 Jun 2008 07:36:33 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53EYMRa076056; Tue, 3 Jun 2008 14:34:23 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031434.m53EYMRa076056@idle.juniper.net> To: "David Harrington" In-reply-to: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com> Date: Tue, 03 Jun 2008 10:34:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 14:36:34.0585 (UTC) FILETIME=[38E50890:01C8C587] X-Mailman-Approved-At: Tue, 03 Jun 2008 07:39:22 -0700 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org "David Harrington" writes: >SNMP notifications have traditionally been close-to-real-time and >scalable. I think netconf notifications are great for interactive >configuration work. I don't think the netconf subscribe approach is >scalable to managing large networks. The difference is much smaller, I think. SNMP sends async notifications based on content descriptions set in (typically) configuration. NETCONF sends async notifications based on content descriptions given in client subscriptions. Once set, both styles send notifications when event happen. The action of the snmp agent and the netconf agent are completly similar. The major difference is that NETCONF requires the manager establish a connection beforehand, where SNMP sends notifications without regard to the manager. The real cost is that a manager needs to have connections up and running to each managed device. The cost for the agent is a connection (one per manager) which is negligible. Thanks, Phil _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 3 08:59:34 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BECC3A6B3A; Tue, 3 Jun 2008 08:59:34 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41AD73A6B2C for ; Tue, 3 Jun 2008 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8dtEM1S+uOq for ; Tue, 3 Jun 2008 08:59:32 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 5EE633A6B2B for ; Tue, 3 Jun 2008 08:59:32 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id ZTVh1Z00R0lTkoCA402m00; Tue, 03 Jun 2008 15:59:34 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id ZTzY1Z0074HwxpC8Q00000; Tue, 03 Jun 2008 15:59:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=NTGhQEpmd0-iKNMwtdYA:9 a=KTui6D9nyqoTTnWOTQoA:7 a=LZlpZPHJDeb0JrC5TklWvQi_DUwA:4 a=NQ6Gw_dTYHUA:10 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Phil Shafer'" References: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com> <200806031434.m53EYMRa076056@idle.juniper.net> Date: Tue, 3 Jun 2008 11:59:31 -0400 Message-ID: <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200806031434.m53EYMRa076056@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjFhz3pm55KLCeTTtGF6o0EYlFQOQABU29Q Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Hi, comments inline, and a request for additional feedback from operators. > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, June 03, 2008 10:34 AM > To: David Harrington > Cc: ops-dir@ietf.org; 'OPS Area'; isms@ietf.org > Subject: Re: [OPS-DIR] SNMP notification configuration > > "David Harrington" writes: > >SNMP notifications have traditionally been close-to-real-time and > >scalable. I think netconf notifications are great for interactive > >configuration work. I don't think the netconf subscribe approach is > >scalable to managing large networks. > > The difference is much smaller, I think. SNMP sends async > notifications > based on content descriptions set in (typically) configuration. > NETCONF sends async notifications based on content descriptions > given in client subscriptions. Once set, both styles send > notifications > when event happen. The action of the snmp agent and the netconf > agent are completly similar. > > The major difference is that NETCONF requires the manager establish > a connection beforehand, where SNMP sends notifications without > regard to the manager. SNMP can send notifications when an event happens, without having to wait for a manager to initiate a connection first. This distinction can be important, especially during startup. As SNMP moves from a UDP transport to an SSH transport, an entity-to-entity connection will need to be initiated before the notification can be sent, so the fact that a connection must be instantiated first might become less important. The distinction of WHO must initiates the connection first might become more important because of NATs. > The real cost is that a manager needs to > have connections up and running to each managed device. The cost > for the agent is a connection (one per manager) which is negligible. These costs probably are similar between netconf/SSH and SNMP/SSH. So, in ISMS terms, would operators find it acceptable if SNMP adopted a "manager must subscribe to get notifications (with replay capability)" similar to the netconf notification protocol approach, when using SNMP over a secure transport layer like SSH or TLS? Using a manager-must-subscribe mechanism would eliminate the need for having the agent establish the SSH connection. The ISMS WG could consider using the same notification protocol design as netconf. This could be done by 1) using a MIB extension to the TARGET-MIB, EVENT-MIB, et. al., requiring a manager to use SNMP SETs to create subscriptions similar to that of the netconf notification protocol. Notifications would be buffered, possibly using the NOTIFICATION-LOG-MIB, just as with netconf notifications. or 2) not sending SNMP notifications over secure transports, but rather requiring support for the netconf notification protocol in all SNMP agents and managers that support SNMP/secure-transport, so managers would need to use netconf to get the notifications. SNMP would presumably continue to support its existing notification model, requiring no subscription (but still requring pre-configuration), when used over UDP. or 3) we could define a new SNMP operation to create a subscription comparable to the netconf notification protocol. The second and third approaches seem to be totally out of scope of the ISMS WG charter, but if they would be better solutions, we could presumably re-charter. (Once we get some operator feedback, we can take this discussion off the OPS lists and return to detailed engineering discussions in the ISMS WG. ;-) David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 3 09:40:08 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D522128C1A8; Tue, 3 Jun 2008 09:40:08 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B219C28C1A3 for ; Tue, 3 Jun 2008 09:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOJjOcYrvgFe for ; Tue, 3 Jun 2008 09:40:06 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 712823A682C for ; Tue, 3 Jun 2008 09:40:06 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id ZTTz1Z0140lTkoCA106U00; Tue, 03 Jun 2008 16:40:09 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id ZUg71Z0024HwxpC8Q00000; Tue, 03 Jun 2008 16:40:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=TsNevSaXmjjEHZoBEhAA:9 a=XJnkrROM32FM8VgAipNrHv9xAeAA:4 a=peF9eE_zjQwA:10 a=lZB815dzVvQA:10 a=9XSpoOj3B7kA:10 From: "David Harrington" To: "'Phil Shafer'" References: <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> <200806031619.m53GJduY077171@idle.juniper.net> Date: Tue, 3 Jun 2008 12:40:06 -0400 Message-ID: <00dc01c8c598$7c0c7070$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200806031619.m53GJduY077171@idle.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjFlfFZuOgTOGu5T4CzydgHTTx+dQAAX5Ug Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org As an SNMP "old dog", I have been indoctrinated with many assumptions that were true in the 80s, but might be less true now. Startup keeps getting smaller as a percentage of overall uptime; notifications may not be as desirable during startup as they once were; UDP may not be any more reliable than TCP for getting through broken networks, and so on. The ISMS WG is trying to make sure we don't change the basic assumptions of how SNMP works, but we occasionally need to question whether certain old assumptions are still valid. dbh > -----Original Message----- > From: Phil Shafer [mailto:phil@juniper.net] > Sent: Tuesday, June 03, 2008 12:20 PM > To: David Harrington > Cc: ops-dir@ietf.org; 'OPS Area'; isms@ietf.org > Subject: Re: [OPS-DIR] SNMP notification configuration > > "David Harrington" writes: > >SNMP can send notifications when an event happens, without having to > >wait for a manager to initiate a connection first. This distinction > >can be important, especially during startup. > > Sure, but in practice, startup is a painful time to send > notifications, > since the delays of interface bringup and learning routes may mean > your manager is unreachable. Waiting for a connection turns out > to be more useful than firing off packets into nowhere. > > Thanks, > Phil > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 3 11:00:21 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601583A69F7; Tue, 3 Jun 2008 11:00:21 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E2E3A6B5E; Tue, 3 Jun 2008 09:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKyghRnRFQnc; Tue, 3 Jun 2008 09:24:25 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 4A83228C1DD; Tue, 3 Jun 2008 09:21:53 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 09:21:55 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jun 2008 09:21:51 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53GLox20620; Tue, 3 Jun 2008 09:21:50 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53GJduY077171; Tue, 3 Jun 2008 16:19:39 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031619.m53GJduY077171@idle.juniper.net> To: "David Harrington" In-reply-to: <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> Date: Tue, 03 Jun 2008 12:19:38 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 16:21:51.0001 (UTC) FILETIME=[EDC5A090:01C8C595] X-Mailman-Approved-At: Tue, 03 Jun 2008 11:00:20 -0700 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org "David Harrington" writes: >SNMP can send notifications when an event happens, without having to >wait for a manager to initiate a connection first. This distinction >can be important, especially during startup. Sure, but in practice, startup is a painful time to send notifications, since the delays of interface bringup and learning routes may mean your manager is unreachable. Waiting for a connection turns out to be more useful than firing off packets into nowhere. Thanks, Phil _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 3 11:00:21 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2E073A6AC9; Tue, 3 Jun 2008 11:00:21 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E213A6805; Tue, 3 Jun 2008 10:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIy27rxR+QE6; Tue, 3 Jun 2008 10:37:27 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id B32AA3A6B4C; Tue, 3 Jun 2008 10:37:21 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Tue, 03 Jun 2008 10:37:09 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jun 2008 10:37:06 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m53Hb5x47046; Tue, 3 Jun 2008 10:37:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m53HYsSL078063; Tue, 3 Jun 2008 17:34:54 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200806031734.m53HYsSL078063@idle.juniper.net> To: "David Harrington" In-reply-to: <00dc01c8c598$7c0c7070$0600a8c0@china.huawei.com> Date: Tue, 03 Jun 2008 13:34:54 -0400 From: Phil Shafer X-OriginalArrivalTime: 03 Jun 2008 17:37:06.0570 (UTC) FILETIME=[7142C6A0:01C8C5A0] X-Mailman-Approved-At: Tue, 03 Jun 2008 11:00:20 -0700 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org "David Harrington" writes: >The ISMS WG is trying to make sure we don't change the basic >assumptions of how SNMP works, but we occasionally need to question >whether certain old assumptions are still valid. Sure, and I'm not out to make trouble, just wondering about cost/benefit tradeoffs. Thanks, Phil _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Jun 3 11:42:45 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CFB028C1A3; Tue, 3 Jun 2008 11:42:45 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031943A6A55; Tue, 3 Jun 2008 11:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8pZp6yiTy-e; Tue, 3 Jun 2008 11:42:44 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 69EDD3A6AB8; Tue, 3 Jun 2008 11:40:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dGtbmIagx1bguZlhPiQAYwkoRA/+ZirFOvKTgrOfswtrW4E1UDNUloj8y/UAfVp1; h=Received:Message-ID:From:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.89.73] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K3bQg-0002L3-Rl; Tue, 03 Jun 2008 14:40:19 -0400 Message-ID: <00a301c8c5a9$5a91ab20$6801a8c0@oemcomputer> From: "Randy Presuhn" References: <032601c8c4d6$ec0e6170$0600a8c0@china.huawei.com><200806031434.m53EYMRa076056@idle.juniper.net> <00ce01c8c592$d114fd90$0600a8c0@china.huawei.com> Date: Tue, 3 Jun 2008 11:40:52 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3dd97ece9fbbe0d32e9061a4d6823f15b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.73 Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [Isms] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Hi - > From: "David Harrington" > To: "'Phil Shafer'" > Cc: ; ; "'OPS Area'" > Sent: Tuesday, June 03, 2008 8:59 AM > Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration ... > The ISMS WG could consider using the same notification protocol design > as netconf. This could be done by > 1) using a MIB extension to the TARGET-MIB, EVENT-MIB, et. al., > requiring a manager to use SNMP SETs to create subscriptions similar > to that of the netconf notification protocol. Notifications would be > buffered, possibly using the NOTIFICATION-LOG-MIB, just as with > netconf notifications. or I'm no operator, but... For this solution, *no* extensions are needed. The log mib is already designed for this scenario. Yes, the manager would need to query the MIB to gather the notification payloads. However, I think this may be a feature rather than a bug. If we're going to start talking about replaying those notifications, we'd then need to limit that replay to transports with appropriate congestion avoidance built in. I think it's simpler to just use the existing MIBs to do what they were designed to do. Randy _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 5 12:07:06 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34B528C199; Thu, 5 Jun 2008 12:07:06 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439463A6CC9; Thu, 5 Jun 2008 12:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULzhM+BDaisc; Thu, 5 Jun 2008 12:07:02 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id EEBF428C23E; Thu, 5 Jun 2008 12:05:35 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m55J5SUj012442; Thu, 5 Jun 2008 22:05:28 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m55J5SLq012438; Thu, 5 Jun 2008 22:05:28 +0300 Date: Thu, 5 Jun 2008 22:05:28 +0300 (EEST) From: Pekka Savola To: Phil Shafer In-Reply-To: <200806031619.m53GJduY077171@idle.juniper.net> Message-ID: References: <200806031619.m53GJduY077171@idle.juniper.net> User-Agent: Alpine 1.10 (LRH 962 2008-03-14) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.93/6816/Fri Apr 18 03:41:09 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org On Tue, 3 Jun 2008, Phil Shafer wrote: > "David Harrington" writes: >> SNMP can send notifications when an event happens, without having to >> wait for a manager to initiate a connection first. This distinction >> can be important, especially during startup. > > Sure, but in practice, startup is a painful time to send notifications, > since the delays of interface bringup and learning routes may mean > your manager is unreachable. Waiting for a connection turns out > to be more useful than firing off packets into nowhere. FWIW my take on this is: We (our network) are happy enough with SNMP traps over UDP from the security (confidentiality etc.) perspective. I realize that some other operators, especially if their borders are not easily definable or have equipment all over the globe without virtual management interfaces (through tunnels etc.) may have a different perspective. The main problem with SNMP traps, syslog, etc. is that when a system reboots or a line goes down, they get lost. If the amount of loss is infrequent (every event does not cause loss), you can live with it as long as you can verify the correct operations using other, reliable means. On the other hand, if every event caused significant loss of information, the manual procedures would become more burdensome and you would need to use a different management model (e.g. almost exclusively polling based) to get the job done. This is to say that traps/notifications over TCP is not to _us_ very interesting if it doesn't also do something else -- i.e. make practically certain that all traps/notifications will in fact be delivered. If we examine how unreliable syslog can be made to work we may learn something for other protocols. Mostly unreliable syslog is fine. Some implementations AFAIK buffer syslog data and don't send it if there is no route to the destination. That helps a bit but not much if you're using default routes your network. But because syslog is also stored locally, you can either 1) go check the local syslog manually if in doubt, or 2) configure scripts to pull in devices' local syslog automatically after certain kinds of events to ensure that the syslog data you have should be complete. That makes me think that (unless this is already being done) an SNMP agent should also store traps/notifications locally at least for the duration of O(days), and that a management system could poll them after the fact to synchronize notification "state". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Jun 6 09:01:54 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572F53A6B17; Fri, 6 Jun 2008 09:01:54 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B247D3A6A12 for ; Fri, 6 Jun 2008 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WJYOWw8WkV2 for ; Fri, 6 Jun 2008 09:01:51 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 91F9E3A6967 for ; Fri, 6 Jun 2008 09:01:51 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA02.westchester.pa.mail.comcast.net with comcast id afuJ1Z00D0Fqzac5201l00; Fri, 06 Jun 2008 16:01:59 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id ag1y1Z0064HwxpC3U00000; Fri, 06 Jun 2008 16:01:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=abe5jlwL1A8A:10 a=LyrTWiuPIYU3A7sl8t0A:9 a=C24A5tC-Mls_OV849ZpbT0Ge9iEA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Pekka Savola'" , "'Phil Shafer'" References: <200806031619.m53GJduY077171@idle.juniper.net> Date: Fri, 6 Jun 2008 12:01:54 -0400 Message-ID: <036301c8c7ee$a4be7bf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcjHPySKoLfeACBXSLaPAiCDCMMWSwApDcAg Cc: ops-dir@ietf.org, isms@ietf.org, 'OPS Area' Subject: Re: [OPS-AREA] [OPS-DIR] SNMP notification configuration X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Hi, RFC3014 "Notification Log MIB" provides a pollable log of SNMP traps, and statistics that could be checked to see if the manager and agent are in sync. The Notification Log MIB also allows for aggregators, so all trap-generation devices do not need to keep historical logs; the Notification Log MIB can be implemented in a node that has greater storage capacity. If ISMS adopts a subscription-style approach, we could recommend or require the Notification Log MIB be used as the buffering and replay mechanism using a polling approach. dbh > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, June 05, 2008 3:05 PM > To: Phil Shafer > Cc: David Harrington; ops-dir@ietf.org; isms@ietf.org; 'OPS Area' > Subject: Re: [OPS-DIR] SNMP notification configuration > > On Tue, 3 Jun 2008, Phil Shafer wrote: > > "David Harrington" writes: > >> SNMP can send notifications when an event happens, without > having to > >> wait for a manager to initiate a connection first. This distinction > >> can be important, especially during startup. > > > > Sure, but in practice, startup is a painful time to send > notifications, > > since the delays of interface bringup and learning routes may mean > > your manager is unreachable. Waiting for a connection turns out > > to be more useful than firing off packets into nowhere. > > FWIW my take on this is: > > We (our network) are happy enough with SNMP traps over UDP from the > security (confidentiality etc.) perspective. I realize that some > other operators, especially if their borders are not easily definable > or have equipment all over the globe without virtual management > interfaces (through tunnels etc.) may have a different perspective. > > The main problem with SNMP traps, syslog, etc. is that when a system > reboots or a line goes down, they get lost. If the amount of loss is > infrequent (every event does not cause loss), you can live with it as > long as you can verify the correct operations using other, reliable > means. On the other hand, if every event caused significant loss of > information, the manual procedures would become more burdensome and > you would need to use a different management model (e.g. almost > exclusively polling based) to get the job done. > > This is to say that traps/notifications over TCP is not to _us_ very > interesting if it doesn't also do something else -- i.e. make > practically certain that all traps/notifications will in fact be > delivered. > > If we examine how unreliable syslog can be made to work we may learn > something for other protocols. > > Mostly unreliable syslog is fine. Some implementations AFAIK buffer > syslog data and don't send it if there is no route to the > destination. > That helps a bit but not much if you're using default routes your > network. But because syslog is also stored locally, you can > either 1) > go check the local syslog manually if in doubt, or 2) configure > scripts to pull in devices' local syslog automatically after certain > kinds of events to ensure that the syslog data you have should be > complete. > > That makes me think that (unless this is already being done) an SNMP > agent should also store traps/notifications locally at least for the > duration of O(days), and that a management system could poll them > after the fact to synchronize notification "state". > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Jun 15 06:16:37 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DA403A6A1A; Sun, 15 Jun 2008 06:16:37 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2DCD3A6A0E for ; Sun, 15 Jun 2008 06:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn5js+ZP3OVN for ; Sun, 15 Jun 2008 06:16:34 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 16D8C3A69EF for ; Sun, 15 Jun 2008 06:16:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,647,1204520400"; d="scan'208";a="111319427" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2008 09:17:10 -0400 X-IronPort-AV: E=Sophos;i="4.27,647,1204520400"; d="scan'208";a="218715519" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jun 2008 09:17:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 15 Jun 2008 15:17:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] OPSAREA meeting in Dublin Thread-Index: Aci7H7kqYsi0vwJEQSKFDfmdJp6G5gTwi+CA References: From: "Romascanu, Dan (Dan)" To: Subject: Re: [OPS-AREA] OPSAREA meeting in Dublin X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org The preliminary schedule is available at https://datatracker.ietf.org/meeting/72/agenda.html and shows OPSAREA meeting on Tuesday 7/29 during the morning session. Please keep the requests for agenda time coming. Dan > -----Original Message----- > From: ops-area-bounces@ietf.org > [mailto:ops-area-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Wednesday, May 21, 2008 11:51 AM > To: ops-area@ietf.org > Subject: [OPS-AREA] OPSAREA meeting in Dublin > > We will be holding an Operations and Management Area open > meeting in Dublin. > > Please send your proposals and requests for the agenda time. > > Thanks and Regards, > > Ron and Dan > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Jun 25 01:47:57 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5793E3A69E9; Wed, 25 Jun 2008 01:47:57 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D0033A6852; Wed, 25 Jun 2008 01:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EjPn43FYt+C; Wed, 25 Jun 2008 01:47:51 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 03E983A69C7; Wed, 25 Jun 2008 01:47:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,700,1204520400"; d="scan'208";a="124790996" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 25 Jun 2008 04:47:49 -0400 X-IronPort-AV: E=Sophos;i="4.27,700,1204520400"; d="scan'208";a="223730702" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jun 2008 04:47:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 10:47:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: IP Security Maintenance and Extensions(ipsecme) Thread-Index: AcjWF57d/96p82bISCmdmbuVhjd7DgAe8YmQAAMn7TA= From: "Romascanu, Dan (Dan)" To: , Subject: [OPS-AREA] FW: WG Review: IP Security Maintenance and Extensions(ipsecme) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1, 2008. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ Last Modified: June 19, 2008 Current Status: Proposed Working Group Chair(s): TBD Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. - A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall solicit help and reviews from the 6MAN WG to ensure that all aspects of IPv6 are properly considered. - A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the geteway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. - A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in July 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Milestones: Dec 2008 WG last call on IPv6 configuration payloads Dec 2008 WG last call on IPsec roadmap Jan 2009 WG last call on session resumption Feb 2009 WG last call on redirect Mar 2009 WG last call on IKEv2bis Apr 2009 WG last call on ESP NULL traffic visibility _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 26 04:11:07 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5264F3A6913; Thu, 26 Jun 2008 04:11:07 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272133A6880; Thu, 26 Jun 2008 04:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sA0QDwSAwIfT; Thu, 26 Jun 2008 04:11:05 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A16903A697A; Thu, 26 Jun 2008 04:11:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,708,1204520400"; d="scan'208";a="124969431" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 26 Jun 2008 07:11:06 -0400 X-IronPort-AV: E=Sophos;i="4.27,708,1204520400"; d="scan'208";a="224442654" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jun 2008 07:11:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 13:11:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RADEXT WG Last Call on RADIUS Design Guidelines Thread-Index: AcjW9bYsnrNGDLvOTKGBGhKB+lnLPQAhqY+A From: "Romascanu, Dan (Dan)" To: , Subject: [OPS-AREA] FW: RADEXT WG Last Call on RADIUS Design Guidelines X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba Sent: Wednesday, June 25, 2008 9:57 PM To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on RADIUS Design Guidelines This is an announcement of RADEXT WG Last Call on "RADIUS Design Guidelines" prior to requesting that the IESG publish it as a Best Current Practice RFC. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt WG Last Call will last until July 10, 2008. Please review the document and post your comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the format described on the RADEXT WG Issues list (http://www.drizzle.com/~aboba/RADEXT/). If you have read the document and approve of its publication, but have no comments, please also post this to the list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 26 05:00:17 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356473A6960; Thu, 26 Jun 2008 05:00:17 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED093A67AE; Thu, 26 Jun 2008 05:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7t0Dyksq8D+E; Thu, 26 Jun 2008 05:00:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2C5443A6960; Thu, 26 Jun 2008 05:00:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,708,1204520400"; d="scan'208";a="112667934" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jun 2008 08:00:15 -0400 X-IronPort-AV: E=Sophos;i="4.27,708,1204520400"; d="scan'208";a="224461452" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Jun 2008 08:00:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 14:00:12 +0200 Message-ID: In-Reply-To: <4863839B.1070405@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: JCA on Management (IETF) Thread-Index: AcjXg5Dy5JqLJO+VSpq0lYXR0pKOcgAAFgFg References: <4863839B.1070405@pi.nu> From: "Romascanu, Dan (Dan)" To: "Loa Andersson" Cc: ops-area@ietf.org, iab@iab.org, iesg@ietf.org, "*Bradner, Scott" Subject: Re: [OPS-AREA] FW: JCA on Management (IETF) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Thursday, June 26, 2008 2:55 PM > To: Romascanu, Dan (Dan) > Cc: iesg@ietf.org; iab@iab.org; opsarea@ietf.org; *Bradner, > Scott; Bert Wijnen - IETF > Subject: Re: FW: JCA on Management (IETF) > > Dan, > > Romascanu, Dan (Dan) wrote: > > Please find below a liaison communication received from the ITU-T, > > about the formation of a Joint Coordination Group on Management > > (JCA-Mgt) replacing the NGN Management Focus Group. > > > > In the past as long as the NGNMFG was active we chose to > participate > > in this work as individuals not officially representing the > IETF, but > > still known to be contributors in the IETF, and bringing to the > > attention of the ITU-T relevant work (in progress or > approved RFCs) from the IETF. > > Bert and myself were involved in this work for the few years, a few > > more folks were involved in the earlier phases of the work. > I suggest > > that we continue with this approach with the newly formed JCA-Mgt, > > also making a new announcement on the OPS Area list to > invite possible > > IETF participants who would be interested to join. > > > > Please comment if you agree with this approach, or if you have > > proposals for alternative approaches. > > I don't have any problem with the approach as far as it goes, > but I think we should tighten the nuts a wee bit. I'm not > saying that we should go as far as appointing > representatives, but in-line with the liaison shepherding > system the IAB is setting up we should be pretty explicit > about the reporting we expect. Also since this is on the > border of what our liaison manager/representatives are > working with, the reports should go to the liaison, the IESG > and the IAB. Makes sense to me. > Whether the report should go to the opsarea mailing lists is > probably depending on how official you think this relationship is. I would also say that this depends upon how relevant this work proves to be for the OPSAREA. Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Jun 26 19:17:04 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463633A6AC2; Thu, 26 Jun 2008 19:17:04 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DCB3A6A8E for ; Thu, 26 Jun 2008 19:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.341 X-Spam-Level: **** X-Spam-Status: No, score=4.341 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_50=0.001, CN_BODY_49=0.02, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRBCz9DP4lvt for ; Thu, 26 Jun 2008 19:17:02 -0700 (PDT) Received: from bay0-omc3-s41.bay0.hotmail.com (bay0-omc3-s41.bay0.hotmail.com [65.54.246.241]) by core3.amsl.com (Postfix) with ESMTP id 793293A6AC2 for ; Thu, 26 Jun 2008 19:17:02 -0700 (PDT) Received: from BAY111-W14 ([64.4.17.114]) by bay0-omc3-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 19:17:03 -0700 Message-ID: X-Originating-IP: [122.204.142.58] From: xuhui To: Date: Fri, 27 Jun 2008 02:17:02 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2008 02:17:03.0419 (UTC) FILETIME=[E38868B0:01C8D7FB] Subject: [OPS-AREA] An Updated Internet Draft for Evaluation on Data Modeling Languages in the Interest of NETCONF-Based X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0968114862==" Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org --===============0968114862== Content-Type: multipart/alternative; boundary="_710a69c8-5fa1-474a-b38b-422e6f71174a_" --_710a69c8-5fa1-474a-b38b-422e6f71174a_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello, We have updated our draft names "An Evaluation Framework for Data Modeling Languages in Network Management Domain". It can be found here: http://www.ietf.org/internet-drafts/draft-xiao-evaluate-dml-02.txt We are Debao Xiao and Hui Xu. Debao Xiao is a professor at Institute of Computer Network and Communication, Huazhong Normal University (http://inc.ccnu.edu.cn) and Hui Xu is a PhD student. Professor Xiao has many years of experience in the area of network management and we are now working in a research project (funded by both the key scientific and technological project of Hubei province in P.R. China and the key scientific and technological project of Wuhan city in P. R. China) about next generation network management and security management as well. In some scenarios, the multiplicity of network management models implies the use of multiple management data modeling languages, which model the resources to be managed. Each language differs in the level of various capabilities and expressiveness, most of which are not easily measured.One of the activities in our project has then been to address the problem about how to establish a framework of evaluation to compare different management data modeling languages based on a set of criteria. Another activity of our project is to prospect the essentail features of future data modeling language based on proposed framework of evaluation, since existing ones have drawbacks of different levels, which hinder them in adapting to the requirements of next generation network management. Our aim is to application of this framework to NETCONF-based data modeling, so as to promote the standardization progress of data modeling languages for NETCONF-based network management. We have demonstrated the most important part of our proposed criteria in this draft, which are modeling approaches, expressiveness, readability, interoperability, extensibility and others, and have also presented some pers pectives on developing future data modeling languages for next generation network management, possibly integrating existing ones. The characteristics of existing data modeling languages are then summarized through comparison based on given criteria for evaluation. An obvious update of this version to prior ones is that, with the use of our proposed evaluation framework, we compare the possible NETCONF data modeling languages that are XML Schema and YANG with SMIng. However, this is still a preparatory work, calling for further efforts. We hope our work can contribute to any future work on data modeling for next generation network management, especially for NETCONF-based one.If there is significant interest, we would be happy to give a presentation of this draft. Best regards,Debao Xiao and Hui Xu _________________________________________________________________ 多个邮箱同步管理，live mail客户端万人抢用中 http://get.live.cn/product/mail.html --_710a69c8-5fa1-474a-b38b-422e6f71174a_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Hello,

        
We have updated our draft names "An Evaluation Framework for Data Modeling
Languages in Network Management Domain". It can be found here:
 
 
http://www.ietf.org/internet-drafts/draft-xiao-evaluate-dml-02.txt
 
 
We are Debao Xiao and Hui Xu. Debao Xiao is a professor at Institute of Computer
Network and Communication, Huazhong Normal University (http://inc.ccnu.edu.cn)
and Hui Xu is a PhD student. Professor Xiao has many years of experience in the area
of network management and we are now working in a research project (funded by both
the key scientific and technological project of Hubei province in P.R. China and the
key scientific and technological project of Wuhan city in P. R. China) about next
ge neration network management and security management as well.
 
 
In some scenarios, the multiplicity of network management models implies the use of
multiple management data modeling languages, which model the resources to be
managed. Each language differs in the level of various capabilities and expressiveness,
most of which are not easily measured.
One of the activities in our project has then been to address the problem about how to
establish a framework of evaluation to compare different management data modeling
languages based on a set of criteria.
 
 
Another activity of our project is to prospect the essentail features of future data
modeling language based on proposed framework of evaluation, since existing ones
have drawbacks of different levels, which hinder them in adapting to the requirements
of next generation network management.
 
 
Our aim is to application of this fra mework to NETCONF-based data modeling, so as
to promote the standardization progress of data modeling languages for NETCONF-
based network management.
 
 
We have demonstrated the most important part of our proposed criteria in this draft,
which are modeling approaches, expressiveness, readability, interoperability,
extensibility and others, and have also presented some perspectives on developing
future data modeling languages for next generation network management, possibly
integrating existing ones. The characteristics of existing data modeling languages are
then summarized through comparison based on given criteria for evaluation.
 
 
An obvious update of this version to prior ones is that, with the use of our proposed
evaluation framework, we compare the possible NETCONF data modeling languages
that are XML Schema and YANG with SMIng. However, this is still a preparatory
work, calling for furthe r efforts.
 
 
We hope our work can contribute to any future work on data modeling for next
generation network management, especially for NETCONF-based one.
If there is significant interest, we would be happy to give a presentation of this draft.
 
 
Best regards,
Debao Xiao and Hui Xu
用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！ --_710a69c8-5fa1-474a-b38b-422e6f71174a_-- --===============0968114862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area --===============0968114862==-- From ops-area-bounces@ietf.org Sat Jun 28 21:02:04 2008 Return-Path: X-Original-To: ops-area-archive@optimus.ietf.org Delivered-To: ietfarch-ops-area-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F08773A6956; Sat, 28 Jun 2008 21:02:03 -0700 (PDT) X-Original-To: ops-area@core3.amsl.com Delivered-To: ops-area@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD8F3A6956 for ; Sat, 28 Jun 2008 21:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.275 X-Spam-Level: * X-Spam-Status: No, score=1.275 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_05=-1.11, FROM_LOCAL_NOVOWEL=3.196] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjXv1d2w1ogu for ; Sat, 28 Jun 2008 21:02:03 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 1E31E3A6875 for ; Sat, 28 Jun 2008 21:00:44 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so475377fga.41 for ; Sat, 28 Jun 2008 21:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:organization:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=NssZuzXpfetVKaTKX3NjvH2O+2cAsuZbX2LF/YxIBSI=; b=vCmiLiQQ2aN58KPpK50S04vRpoR46TZsli/53dpguqo3dOxXSdTKggCQgIk9IJ7g34 Q7RTvq+iPjp6w0Ugor1evv4+OcLHqh9ZWQsSrlgDIeB3ibFBX9WMSs1EmuLCksun2ZMy Axdq1YztalVqu3l1uB3S+QBrkV8A9N3x+plm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:organization:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=dC9BqHSmoKVNE6iOzuxcQX5CCtzCMCkXDw8osDP042ZXtOJiiCRfce3397whD7EnBl rUohnnnY+w9fop8LGVqWFT5nxthfzphzgOInWgdISazlh270B4FXpWEsoRlG4yCMdAkH KxyJwbeqpFHSIvwyd44g9xlVYoZ3J8/YKB034= Received: by 10.86.87.5 with SMTP id k5mr4281228fgb.59.1214712052100; Sat, 28 Jun 2008 21:00:52 -0700 (PDT) Received: from xyzzy ( [217.184.142.53]) by mx.google.com with ESMTPS id d6sm6675706fga.2.2008.06.28.21.00.49 (version=SSLv3 cipher=RC4-MD5); Sat, 28 Jun 2008 21:00:51 -0700 (PDT) Message-ID: <009801c8d99c$f46849a0$358eb8d9@xyzzy> From: "Frank Ellermann" To: Date: Sun, 29 Jun 2008 06:02:28 +0200 Organization: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Subject: [OPS-AREA] 2606bis draft covering IDN test TLDs X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Hi, see for a draft adding the eleven IDN test TLDs to RFC 2606. Apart from updating some references and ".localhost" it proposes to introduce a = registry of reserved TLDs based on IETF review, e.g., for future IDN example TLDs. Frank _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area