From rbonica@juniper.net Fri Jan 6 12:48:00 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9B121F877C for ; Fri, 6 Jan 2012 12:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Kv4k3p8cvSOk for ; Fri, 6 Jan 2012 12:48:00 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id B302F21F8715 for ; Fri, 6 Jan 2012 12:47:59 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTwdd9rS/Il0R6TN+jRDMLdFl2d1Ar9Ep@postini.com; Fri, 06 Jan 2012 12:47:59 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 6 Jan 2012 12:45:54 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 6 Jan 2012 15:45:53 -0500 From: Ronald Bonica To: "opsawg@ietf.org" Date: Fri, 6 Jan 2012 15:45:46 -0500 Thread-Topic: OPSAWG Chairs Thread-Index: AczMtCozs7sZDfO9TWOI/Gy4wAUl8A== Message-ID: <13205C286662DE4387D9AF3AC30EF456D74EEEF240@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CNs3 EbdV Gmz0 HzL4 JhJh KXF2 M7ml OhXy RQMe RjhG Stuq Vpip W+2C cD58 cReE dkuR; 3; bQBlAGwAaQBuAGQAYQAuAHMAaABvAHIAZQBAAGcAbQBhAGkAbAAuAGMAbwBtADsAbwBwAHMAYQB3AGcALQBjAGgAYQBpAHIAcwBAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AG8AcABzAGEAdwBnAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {532873C1-70FB-449A-9D01-7733A8FE1E61}; cgBiAG8AbgBpAGMAYQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA=; Fri, 06 Jan 2012 20:45:46 GMT;TwBQAFMAQQBXAEcAIABDAGgAYQBpAHIAcwA= x-cr-puzzleid: {532873C1-70FB-449A-9D01-7733A8FE1E61} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg-chairs@tools.ietf.org" Subject: [OPSAWG] OPSAWG Chairs X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:48:00 -0000 Folks, Please welcome Melinda Shore as she joins Scott Bradner and Chris Liljensto= lpe as an OPSAWG chair. Many of you know Melinda from her previous WG parti= cipation and have benefited from the guidance that she has provided to vari= ous efforts. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From ietf@cdl.asgaard.org Tue Jan 17 00:45:10 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17CE21F8609 for ; Tue, 17 Jan 2012 00:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 ZH-T4MJM5g8t for ; Tue, 17 Jan 2012 00:45:06 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id B893B21F8600 for ; Tue, 17 Jan 2012 00:45:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 02BB0AD56EE; Tue, 17 Jan 2012 08:45:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxCX64KO9JED; Tue, 17 Jan 2012 08:45:00 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 192C2AD56DD; Tue, 17 Jan 2012 08:44:59 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_0F622B1E-5966-4DEB-A2B1-A28B242FF818"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Tue, 17 Jan 2012 00:44:57 -0800 Message-Id: <519C94F2-F0FB-46EE-AD8F-426E389F62B9@cdl.asgaard.org> To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-opsawg-management-stds@tools.ietf.org Subject: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:45:10 -0000 --Apple-Mail=_0F622B1E-5966-4DEB-A2B1-A28B242FF818 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings all, This is a WGLC for WGLC draft-ietf-opsawg-management-stds-03. = The call will be open until 00:01 UTC on 24 January. Please register = your support or disagreement as soon as possible. Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_0F622B1E-5966-4DEB-A2B1-A28B242FF818 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPFTUJAAoJEGmx2Mt/+Iw/DLUH/2WHzTuQDcQ/ZnQ6AQv2Lx6n rtf3oeA0CeSH7ifPO2+JPI8TKEqi4rBsq88rVwucYikEx//BD1Vf6nCTCvMh/7li oGL3g3wSaoUnM0Z3wc80FRiJn8d//8rIhmwgxo4n6nvJzvoB57Yi3Xf99cTkmZxO 14m0Tf8Ub/hRYx7XAlQJqduBLSwaawh6gPqNB1OEsUWI5emrKAT7p06LXlr0W/sd xTi/H2VOCEwQL7SCLDE2l+21yuJU7gHyutTJyExuUW9kBBQmR0TIlvKtwpcueM8d VlpbjcYl2V3fcAaQUFcaqUdmas6LV6tA7Mjwjl6d0uiXDj9NrSJd2c+1/CBHSHI= =wrBJ -----END PGP SIGNATURE----- --Apple-Mail=_0F622B1E-5966-4DEB-A2B1-A28B242FF818-- From cdl@asgaard.org Tue Jan 17 00:46:51 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4306921F84DD for ; Tue, 17 Jan 2012 00:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 OH+VRlnlukEa for ; Tue, 17 Jan 2012 00:46:47 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 277DA21F8571 for ; Tue, 17 Jan 2012 00:46:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id B758DAD5727; Tue, 17 Jan 2012 08:46:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UgNLJdyFxsi; Tue, 17 Jan 2012 08:46:40 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id DBC52AD5719; Tue, 17 Jan 2012 08:46:39 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_B94091A3-306F-4005-813F-EC7A50B78BF7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Tue, 17 Jan 2012 00:46:38 -0800 Message-Id: <17CAAB8A-E379-4369-B85A-5A4646B63810@asgaard.org> To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [OPSAWG] call for slots X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 08:46:51 -0000 --Apple-Mail=_B94091A3-306F-4005-813F-EC7A50B78BF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, It's getting time again folks. Scott and I would like to see = what we might need in terms of slots for Paris. Can you please write to = the group with requests. We will be strongly biased to drafts already = being discussed on the mailing list. =20 Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_B94091A3-306F-4005-813F-EC7A50B78BF7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBAgAGBQJPFTVuAAoJEGmx2Mt/+Iw/1m0H/37VZp4VVhBFFEYe1VynoEOY Zyia0XeOTkdj1lpvo2xkCl/z428gZzmrX9TsBhDF6M5d44TceU/gpMCGrhXWb7jb tw0X+u3VhZOf1CSeDMqZoBEXtaLup0/+vlLfdPEXbDGG3OKo8kaZTXvHOgey4ET7 AB8Cjj12madoFIuco9KY/uCCZ312AUaQsuJLQDwKY0JlVMCpgMBRRpl0cBtEJDub TZjitoCT4P5NUWzFZSsIG3qLcjCtpORVY4XwT93XrJxb15lU9K4JID9cB1sDTLqj 4Vv7OZNSJrDMotB+12yls+cqcX2uL7fZ3ua0hkuBRFDfxeFEtIuy3aSs81BTSqU= =/kKv -----END PGP SIGNATURE----- --Apple-Mail=_B94091A3-306F-4005-813F-EC7A50B78BF7-- From fred@cisco.com Fri Jan 20 17:27:08 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA4B21F85DF for ; Fri, 20 Jan 2012 17:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ZTdAIe67gCkw for ; Fri, 20 Jan 2012 17:27:08 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4760621F852B for ; Fri, 20 Jan 2012 17:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1957; q=dns/txt; s=iport; t=1327109228; x=1328318828; h=mime-version:subject:from:date:cc:message-id:references: to:content-transfer-encoding; bh=9dQFPEVlTGu06YFIcO56IbkmyH8oVXc4Tty2jpQebYI=; b=TFwTZaSReF35wH3qDzjVQPi0+hQyyqSvkRabWbnAR2xN+tHJMIJKXG2X WmOG1ukA6Vw20BCjZMiBkmW+bbEYpv2Cp5foo8+ATtV2zSrWGdVw47Aid 2CxFHZ3xk7HDA8Zy8ek8YVQS4aLLfGtZ8QvUHeB0pECwD/0W7cZzJI75e U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFsTGk+rRDoJ/2dsb2JhbABDrg2BBYFyAQEBAwESASc/BQscAwECL08IGSKHWgiaMQGeL4kKgjljBIg8jF2FVY0X X-IronPort-AV: E=Sophos;i="4.71,546,1320624000"; d="scan'208";a="26468161" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 21 Jan 2012 01:27:06 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0L1R5t1007046; Sat, 21 Jan 2012 01:27:06 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 20 Jan 2012 17:27:06 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 20 Jan 2012 17:27:06 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Fri, 20 Jan 2012 17:26:34 -0800 Message-Id: References: <20120121011325.3221.79641.idtracker@ietfa.amsl.com> To: opsawg@ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 Jan 2012 17:33:30 -0800 Cc: draft-vyncke-advanced-ipv6-security@tools.ietf.org, homenet-chairs@tools.ietf.org, james woodyatt , Ron Bonica Subject: [OPSAWG] draft-baker-opsawg-firewalls-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 01:27:09 -0000 > From: internet-drafts@ietf.org > Date: January 20, 2012 5:13:25 PM PST > To: fred@cisco.com > Cc: fred@cisco.com > Subject: New Version Notification for = draft-baker-opsawg-firewalls-00.txt >=20 > A new version of I-D, draft-baker-opsawg-firewalls-00.txt has been = successfully submitted by Fred Baker and posted to the IETF repository. >=20 > Filename: draft-baker-opsawg-firewalls > Revision: 00 > Title: On Firewalls in Internet Security > Creation date: 2012-01-21 > WG ID: Individual Submission > Number of pages: 12 >=20 > Abstract: > There is an ongoing discussion regarding the place of firewalls in > security. This note is intended to capture and try to make sense = out > of it. >=20 > The IETF Secretariat Folks: When the IPv6 Operations WG was looking at firewalls for IPv6, the = working group experienced a clash of worldviews. One world view said "I = have a marketplace requirement to provide perimeter security - firewalls = - or people won't deploy IPv6 in their residential networks", and the = other said "we really don't want to have firewalls in the IPv6 network."=20= The discussion has resurfaced in homenet. A little bedtime reading: https://tools.ietf.org/html/rfc6092 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service. J. Woodyatt, Ed.. January 2011. (Format: TXT=3D91729 bytes) (Status: INFORMATIONAL) http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security "Advanced Security for IPv6 CPE", Eric Vyncke, Andrew Yourtchenko, = Mark Townsley, 31-Oct-11 I took some time to attempt to organize a line of reasoning, that would = enable us to give hopefully-unbiased guidance on the topic, or at least = have a low-blood-pressure discussion of it. That's this draft. I would appreciate your thoughts on it and on the topic it addresses.= From j.schoenwaelder@jacobs-university.de Sun Jan 22 07:30:12 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38EA21F847E for ; Sun, 22 Jan 2012 07:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.23 X-Spam-Level: X-Spam-Status: No, score=-103.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 1wWnD4Fzg3q8 for ; Sun, 22 Jan 2012 07:30:11 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 46FCD21F8472 for ; Sun, 22 Jan 2012 07:30:10 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D50FD20C17; Sun, 22 Jan 2012 16:30:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1BTsRuIMp2A7; Sun, 22 Jan 2012 16:30:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1857D20251; Sun, 22 Jan 2012 16:30:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0D3F91C96CC2; Sun, 22 Jan 2012 16:29:51 +0100 (CET) Date: Sun, 22 Jan 2012 16:29:50 +0100 From: Juergen Schoenwaelder To: Christopher LILJENSTOLPE Message-ID: <20120122152950.GB42368@elstar.local> Mail-Followup-To: Christopher LILJENSTOLPE , opsawg@ietf.org, draft-ietf-opsawg-management-stds@tools.ietf.org References: <519C94F2-F0FB-46EE-AD8F-426E389F62B9@cdl.asgaard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <519C94F2-F0FB-46EE-AD8F-426E389F62B9@cdl.asgaard.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, draft-ietf-opsawg-management-stds@tools.ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 15:30:12 -0000 On Tue, Jan 17, 2012 at 12:44:57AM -0800, Christopher LILJENSTOLPE wrote: > Greetings all, > > This is a WGLC for WGLC draft-ietf-opsawg-management-stds-03. The call will be open until 00:01 UTC on 24 January. Please register your support or disagreement as soon as possible. > I have reviewed and below are my technical comments. (There are a number of editorial issues like missing articles, or singular/plural mismatches, or stylistic things like sentences starting with [RFCxxxx] that I am too lazy to write down.) Below, I am quoting parts of the document and I am providing concrete suggestions in order to make my points hopefully clear enough and actionable. a) The definition of MIB can probably be improved. Note that there is a separate definition of a MIB module - so the second sentence can be moved. OLD: o Management Information Base (MIB): An information repository with related collection of objects that represent an aggregation of resources to be managed. MIB modules are defined by using the modeling language SMI. NEW: o Management Information Base (MIB): An information repository with a collection of related objects that represent the resources to be managed. b) The definition of MIB module can probably be improved. I suggest to align with the definition found in RFC 3410 section 6.2. OLD: o MIB module: A MIB definition, typically for a particular network technology feature, that constitutes a subtree in an object identifier tree. A MIB that is provided by a management agent is typically composed of multiple instantiated MIB modules. NEW: o MIB module: MIB modules usually contain object definitions, may contain definitions of event notifications, and sometimes include compliance statements in terms of appropriate object and event notification groups. MIB modules are defined by using the data modeling language SMI. A MIB that is provided by a management agent is typically composed of multiple instantiated MIB modules. c) I suggest to remove this definition: o Trap: An unsolicited message sent by an agent to a management station to notify an unusual event. The reason is that we generally talk about notifications and the term does not show up many times in the document (and in some cases this should really be notification or it is text specific to SNMP protocol operations. Or replace it with this: o Notification: An unsolicited message sent by an agent to a management station to notify an unusual event. d) Use [STD58]? The old text is inconsistent in the way it refers to STDs or RFCs. Note also that STD58 comprises three RFCs not two. OLD: As such following standards build up the basis of the current SNMP Management Framework: o SNMPv3 protocol [STD62], o the modeling language SMIv2 [RFC2578][RFC2579], and NEW: As such following standards build up the basis of the current SNMP Management Framework: o SNMPv3 protocol [STD62], o the modeling language SMIv2 [STD58], and e) This text can probably go without loosing anything important for the target audience (but if people believe this is important...) OLD: The SNMPv3 Framework extends the architectural principles of SNMPv1 and SNMPv2 by: o building on these three basic architectural components, in some cases incorporating them from the SNMPv2 Framework by reference, and o by using the same layering principles in the definition of new capabilities in the security and administration portion of the architecture. NEW: f) This is technically wrong: The Trap PDU has been in SNMPv1 and the Inform is another PDU, not another message. OLD: SNMPv2 enhances this basic functionality with a Trap PDU, an Inform message, [...] NEW: SNMPv2 enhances this basic functionality with an Inform PDU, [...] g) SNMPv3 is STD since a looong time. And a STD reference to refer to a Proposed Standard also sounds wrong. OLD: offers sufficient security features. To address the security deficiencies of SNMPv1/v2, SNMPv3 was issued as a set of Proposed Standards (see [STD62]). NEW: offers sufficient security features. To address the security deficiencies of SNMPv1/v2, SNMPv3 was issued (see [STD62]). h) This is wrong: OLD: is often used to poll basic parameter of a device (e.g. sysUpTime, which reports the time since the last reinitialization of the device) NEW: is often used to poll basic parameter of a device (e.g. sysUpTime, which reports the time since the last reinitialization of the network management portion of the device) i) Terminology clarification. Note that YANG has statements, SMIv2 has macros. OLD: o [STD58][RFC2579] defines common MIB "Textual Conventions", NEW: o [STD58][RFC2579] defines the "Textual Conventions" macro for defining new types and it provides a core set of generally useful "Textual Convention" definitions j) Remove unclear and unneeded reference to "this architecture". OLD Secondary threats against which SNMP Security Models within this architecture can provide protection are "message stream NEW: Secondary threats against which SNMP Security Models can provide protection are "message stream OLD: There are two threats against which a Security Model within this architecture does not protect, since they are deemed to be of lesser NEW: There are two threats against which a Security Model does not protect, since they are deemed to be of lesser k) I fail to see why these are two different things. In particular, the example given in the first bullet seems to be a perfect fit for the second bullet. Here is a proposal for a shorter version: OLD: [...] An agent entity can restrict access to its MIB for a particular manager entity in two ways: o The agent entity can restrict access to a certain portion of its MIB, e.g., an agent may restrict most manager principals to viewing performance-related statistics and allow only a single designated manager principal to view and update configuration parameters. o The agent can limit the operations that a principal can use on that portion of the MIB. E.g., a particular manager principal could be limited to read-only access to a portion of an agent's MIB. NEW: [...] An agent entity can restrict access to a certain portion of its MIB for a particular manager principal, an agent may restrict some manager principals to viewing performance-related statistics and allow only a single designated manager principal to view and update configuration parameters. Some other manager principals may not even be allowed to read the performance-related statistics. l) I think this is wrong because my understanding is that there is a single community-based security model that is used by both SNMPv1 and SNMPv2. OLD: The SNMP Transport Security Model [RFC5591] is an alternative to the existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the User-based Security Model [RFC3414]. NEW: The SNMP Transport Security Model [RFC5591] is an alternative to the existing SNMPv1/SNMPv2 Community-based Security Model [RFC3584] and the User-based Security Model [RFC3414]. m) Why is this note here? Is it necessary to keep? Given that the SNMP text is long anyway, I suggest to remove the note. OLD: Note: Different IETF standards use security layers to address security threads (e.g. TLS [RFC5246], Simple Authentication and Security Layer (SASL) [RFC4422], and SSH [RFC4251]). Diverse management interfaces from IETF use a secure transport layer to provide secure information and message exchange to build management applications, e.g. SYSLOG [RFC5424], IPFIX [RFC5101] and NETCONF [RFC4741]. NEW: n) I suggest to put the following text into a more consistent order. This idea is to first say what SYSLOG is and then start talking about the BSD origin instead of switching focus every other paragraph. OLD: The body of an BSD SYSLOG message has traditionally been unstructured text. This content is human-friendly, but difficult to parse for applications. The content of BSD SYSLOG messages correlate across vendors and with other event reporting such as SNMP traps. The SYSLOG protocol enables a machine to send system log messages across networks to event message collectors. The protocol is simply designed to transport and distribute these event messages. By default, no acknowledgements of the receipt are made, except the reliable delivery extensions specified in [RFC3195] are used. The SYSLOG protocol and process does not require a stringent coordination between the transport sender and the receiver. Indeed, the transmission of SYSLOG messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. BSD SYSLOG had little uniformity for the message format and the content of SYSLOG messages. The IETF has standardized a new message header format, including timestamp, hostname, application, and message ID, to improve filtering, interoperability and correlation between compliant implementations. NEW: The SYSLOG protocol enables a machine to send system log messages across networks to event message collectors. The protocol is simply designed to transport and distribute these event messages. By default, no acknowledgements of the receipt are made, except the reliable delivery extensions specified in [RFC3195] are used. The SYSLOG protocol and process does not require a stringent coordination between the transport sender and the receiver. Indeed, the transmission of SYSLOG messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions. BSD SYSLOG had little uniformity for the message format and the content of SYSLOG messages. The body of an BSD SYSLOG message has traditionally been unstructured text. This content is human-friendly, but difficult to parse for applications. The IETF has standardized a new message header format, including timestamp, hostname, application, and message ID, to improve filtering, interoperability and correlation between compliant implementations. o) This seems to be wrong: RFC 5426 says "TLS transport [7] is REQUIRED to implement and RECOMMENDED for general use." Sure, it would be kind of stupid to implement SYSLOG without UDP support but the standard clearly says TLS. OLD: number of transport mappings. However, for interoperability purposes, SYSLOG protocol implementers are required to support the transmission of SYSLOG Messages over UDP as defined in [RFC5426]. NEW: number of transport mappings. However, for interoperability purposes, SYSLOG protocol implementers are required to support the transmission of SYSLOG Messages over TLS as defined in [RFC5426]. p) I suggest to replace references to RFC4741 with RFC6241 and RFC4742 with RFC6242 since these newer documents obsolete the former (and we generally can't cover the history of all protocols). This affects multiple places, please to a query replace. Similarly, I think this can go: OLD: The NETCONF working group updated the NETCONF base protocol standard as [RFC6241] and the SSH transport protocol mapping as [RFC6242]. NEW: q) Text can be updated since NACM meanwhile is in the RFC editor queue. OLD: At the time of this writing NETCONF Access Control Model (NACM) is being specified. NACM proposes standard mechanisms to restrict protocol access to particular users with a pre-configured subset of operations and content. NEW: The NETCONF Access Control Model (NACM) [I-D.NACM] provides a standard mechanisms to restrict protocol access to particular users with a pre-configured subset of operations and content. r) Fixing an editorial accident. OLD: DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the subnetwork supported by the router. NEW: DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the subnetwork supported by the router. s) Wrong section reference OLD: IETF for the realization of management tasks and applications. This subsection provides an overview of IETF data models with an FCAPS NEW: IETF for the realization of management tasks and applications. Section 4.2 provides an overview of IETF data models with an FCAPS t) Section 4.2 puts an emphasis on the standardization status since the text is structured into "Draft Standards" and "Proposed Standards" and sometimes "Full Standards". This leads to an odd structure since often various parts of a certain technology are at different levels and thus either can't be discussed together or we happen to see references to Proposed Standards in sections labeled Draft of Full Standard. Furthermore, given RFC 6410, some of the Draft Standards may change into Internet Standards or Proposed Standards within two years. So my recommendation would be to remove the structure and to mention the maturity level where it is useful, this is how the text is done for the rest of the document as well. On the other hand, if people insist on keeping the structure, you will have move around a number of things. u) Be explicit since we had sysUpTime wrong already (it seems a fairly common misunderstanding). OLD: device is still operating, and sysUpTime can be used to detect if a system has rebooted, and counters have been reinitialized. NEW: device is still operating, and sysUpTime can be used to detect if the network management portion of the system has restarted, and counters have been reinitialized. v) Is this history of any use for the target audience? Note that RFC 1229 was obsoleted in 1994, 18 years ago. I suggest to shrink this as follows: OLD: The Interfaces Group MIB [RFC2863] builds on MIB II [RFC1229] and is used as a primary MIB for managing and monitoring the status of network interfaces (e.g. SNMP linkdown and linkup notifications). The 'interfaces' group in MIB II [RFC1229] defines a generic set of managed objects and provides the means for additional managed objects specific to particular types of network interfaces, such as Ethernet. Extensions to the 'interfaces' group for media-specific management can be defined based on these managed objects. Experience with media-specific MIB modules has shown that the model defined by MIB-II is too simplistic and static for some types of media-specific management. The Interfaces Group MIB incorporates the interfaces group extensions documented in MIB II and standardizes an evolution to this model as well as fills in the detected gaps. NEW: The Interfaces Group MIB [RFC2863] defines a generic set of managed objects for network interfaces and it provides the infrastructure for additional managed objects specific to particular types of network interfaces, such as Ethernet. w) There are more SNMP configuration MIB modules. Why do you pick these and not the others? This is also an example where the maturity level classification went wrong. OLD: Draft standards: [RFC3418] contains objects in the system group useful e.g. for identifying the type of device, the location of the device, the person responsible for the device. [RFC3413], part of STD 62 SNMPv3, includes objects designed for configuring notification destinations, and for configuring proxy- forwarding SNMP agents, which can be used to forward messages through firewalls and Network Address Translation (NAT) devices. NEW: RFC 3418, part of [STD62], contains objects in the system group useful e.g. for identifying the type of device, the location of the device, the person responsible for the device. The SNMPv3 standard [STD62] includes objects designed for configuring principals, access control rules, notification destinations, and for configuring proxy- forwarding SNMP agents, which can be used to forward messages through firewalls and Network Address Translation (NAT) devices. x) I doubt these are in any way practically relevant nor am I sure about the support agreement argument. This neither RFC3165 nor RFC4011 seem to be used in practice, I would rather drop these three paragraphs. OLD: [RFC3165] supports the use of user-written scripts to delegate management functionality. Policy Based Management MIB [RFC4011] defines objects that enable policy-based monitoring using SNMP, using a scripting language, and a script execution environment. Few vendors have implemented MIB modules that support scripting. Some vendors consider running user-developed scripts within the managed device as a violation of support agreements. NEW: y) This text should probably be made more precise by saying monitoring instead of broadly management. The standard status becomes clear through the STD reference. OLD: RMON (Remote Network Monitoring) MIB [RFC2819] has the Full Standard status [STD59] and defines objects for managing remote network devices and collecting data related to network performance and traffic. An organization may employ many remote management probes, one per network segment, to manage its internet. These devices may be used by a network service provider to access a client network, often geographically remote. Most of the objects in the RMON MIB module are suitable for the management of any type of network, where some of them are specific to management of Ethernet networks. NEW: The RMON (Remote Network Monitoring) MIB [RFC2819] [STD59] defines objects for collecting data related to network performance and traffic from remote monitoring devices. An organization may employ many remote monitoring probes, one per network segment, to monitor its network. These devices may be used by a network service provider to access a client network, often geographically remote. Most of the objects in the RMON MIB module are suitable for the monitoring of any type of network, while some of them are specific to the monitoring of Ethernet networks. z) Why do we have text for something that according to RFC 6248 has seen no usage? OLD: The IPPM working group has defined [BCP108][RFC4148] "IP Performance Metrics (IPPM) Metrics Registry". The IANA-assigned registry contains an initial set of OBJECT IDENTITIES to currently defined metrics in the IETF as well as defines the rules for adding IP Performance Metrics that are defined in the future. However, the current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Due to the ambiguities between the current metrics registrations and the metrics used, and the apparent non-adoption of the registry in practice, it has been proposed to reclassify [RFC4148] as Obsolete. Note: With the publication of [RFC6248] the latest IANA registry for IPPM metrics and [RFC4148] have been declared Obsolete and IANA prevents registering new metrics. Actual users can continue using the current registry and its contents. NEW: A) Should NACM be mentioned in 4.2.5 right before the text on RADIUS starts? B) Something went wrong here... OLD: [STD58] McCloghrie, K., David, D., and J. Juergen, "Structure of Management Information Version 2 (SMIv2)", April 1999. NEW: [STD58] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", April 1999. C) The previous item B) made me look into std-index.txt and it seems standards made up of multiple RFCs happen to have their own name. STD62 for example is called "Simple Network Management Protocol Version 3 (SNMPv3)." and the authors are all the authors of the RFCs that are part of the standard. I assume the RFC editor knows how to properly cite a [STD]. (This comment likely also applies to BCPs, but we likely have fewer multi-document BCPs.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From aakhter@cisco.com Sun Jan 22 19:20:53 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587F721F85DB for ; Sun, 22 Jan 2012 19:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rOL3DfBQdXfY for ; Sun, 22 Jan 2012 19:20:52 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4386A21F85D9 for ; Sun, 22 Jan 2012 19:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=2198; q=dns/txt; s=iport; t=1327288852; x=1328498452; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=48R4CIpOluo9LEfRmulIjdfDs9EyS7FxeuAYVFIx3QY=; b=YLrlCFuSirXlcYz99iRsz+/HYYJtr/DjqZsqnEzdxjwG1h5BBDqt5AD3 uRfOoTWGgNmf2e9sDnWPMAIwftyBYtzXifvzsmQKKlXUJTNgjSnTC4vkE emO1FEjgTZ945sy3dAzT40KDdmwKyJHiPxa7VzGZTBMUiGcboNm62Jjdf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMbRHE+tJXG8/2dsb2JhbABDFoRzqCtxgQWBcgEBAQQSAQoGDQQ6FwYBBhMEAQEDAgYGFwECAgMBRAkJAQQBEggah2KaGwGMY5B3BIEviWEzYwSIO59L X-IronPort-AV: E=Sophos;i="4.71,553,1320624000"; d="scan'208";a="53040041" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jan 2012 03:20:51 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0N3KpL9018846; Mon, 23 Jan 2012 03:20:51 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 Jan 2012 21:20:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 22 Jan 2012 21:20:46 -0600 Message-ID: <7F298ACC76CC154F832B6D02852D169F06EF9AF2@XMB-RCD-101.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: request for presentation slot regarding perfmon drafts RE: [OPSAWG] call for slots Thread-Index: AczZfb6nwx3u8JP9QWObB8Wn74fxaw== From: "Aamer Akhter (aakhter)" To: "Christopher LILJENSTOLPE" , X-OriginalArrivalTime: 23 Jan 2012 03:20:51.0457 (UTC) FILETIME=[024C6710:01CCD97E] Subject: [OPSAWG] request for presentation slot regarding perfmon drafts RE: call for slots X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 03:20:53 -0000 SGkgT1BTQVdHLA0KDQpJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIHByZXNlbnRhdGlvbiBzbG90 IGZvciBhIHJldmlldywgY3VycmVudCBzdGF0dXMgb2YgdGhlIHBlcmZtb24gZHJhZnRzLiBUaGUg Zm9jdXMgd291bGQgYmUgb24gdGhlIG1ldGhvZG9sb2d5IGRvY3VtZW50LiANCg0KCWRyYWZ0LWFr aHRlci1vcHNhd2ctcGVyZm1vbi1pcGZpeCAJIA0KCWRyYWZ0LWFraHRlci1vcHNhd2ctcGVyZm1v bi1tZXRob2QgCSANCg0KICAgVGhlcmUgaXMgYSBuZWVkIHRvIGJlIGFibGUgdG8gcXVhbnRpZnkg YW5kIHJlcG9ydCB0aGUgcGVyZm9ybWFuY2Ugb2YNCiAgIG5ldHdvcmsgYXBwbGljYXRpb25zIGFu ZCB0aGUgbmV0d29yayBzZXJ2aWNlIGluIGhhbmRsaW5nIHVzZXIgZGF0YS4NCiAgIFRoaXMgcGVy Zm9ybWFuY2UgZGF0YSBwcm92aWRlcyBpbmZvcm1hdGlvbiBlc3NlbnRpYWwgaW4gdmFsaWRhdGlu Zw0KICAgc2VydmljZSBsZXZlbCBhZ3JlZW1lbnRzLCBmYXVsdCBpc29sYXRpb24gYXMgd2VsbCBh cyBlYXJseSB3YXJuaW5ncw0KICAgb2YgbmV0d29yayBncmVhdGVyIHByb2JsZW1zLiAgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBnZW5lcmljDQogICBtZXRob2RvbG9neSBmb3IgY2FsY3VsYXRp bmcgbWV0cmljcyByZWxhdGVkIHRvIG5ldHdvcmsgYmFzZWQNCiAgIGFwcGxpY2F0aW9ucy4gIElu IGFkZGl0aW9uLCB0byB0aGUgcGVyZm9ybWFuY2UgbWV0cmljcywgc2V2ZXJhbA0KICAgYWRkaXRp b25hbCBpbmZvcm1hdGlvbiBlbGVtZW50cyBhcmUgaW5jbHVkZWQgdG8gaGVscCBwcm92aWRlIGdy ZWF0ZXINCiAgIGNvbnRleHQgdG8gdGhlIHJlcG9ydHMuICBUaGUgbWVhc3VyZW1lbnRzIHVzZSBh dWRpby92aWRlbw0KICAgYXBwbGljYXRpb25zIGFzIGJhc2UgZXhhbXBsZXMgYnV0IGFyZSBub3Qg cmVzdHJpY3RlZCB0byB0aGVzZSBjbGFzcw0KICAgb2YgYXBwbGljYXRpb25zLg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0b3BoZXIgTElM SkVOU1RPTFBFDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDEyIDM6NDcgQU0NClRvOiBv cHNhd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFtPUFNBV0ddIGNhbGwgZm9yIHNsb3RzDQoNCkdyZWV0 aW5ncywNCg0KCUl0J3MgZ2V0dGluZyB0aW1lIGFnYWluIGZvbGtzLiAgU2NvdHQgYW5kIEkgd291 bGQgbGlrZSB0byBzZWUgd2hhdCB3ZSBtaWdodCBuZWVkIGluIHRlcm1zIG9mIHNsb3RzIGZvciBQ YXJpcy4gIENhbiB5b3UgcGxlYXNlIHdyaXRlIHRvIHRoZSBncm91cCB3aXRoIHJlcXVlc3RzLiAg V2Ugd2lsbCBiZSBzdHJvbmdseSBiaWFzZWQgdG8gZHJhZnRzIGFscmVhZHkgYmVpbmcgZGlzY3Vz c2VkIG9uIHRoZSBtYWlsaW5nIGxpc3QuICANCg0KCUNocmlzDQoNCi0tICANCuadjuafr+edvw0K Q2hlY2sgbXkgUEdQIGtleSBoZXJlOiBodHRwczovL3d3dy5hc2dhYXJkLm9yZy9+Y2RsL2NkbC5h c2MNCkN1cnJlbnQgdkNhcmQgaGVyZTogaHR0cHM6Ly93d3cuYXNnYWFyZC5vcmcvfmNkbC9jZGwu dmNmDQoNCg== From randy@psg.com Sun Jan 22 22:31:29 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A8D21F85DF for ; Sun, 22 Jan 2012 22:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 W+mX51l2naQy for ; Sun, 22 Jan 2012 22:31:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A821F85C0 for ; Sun, 22 Jan 2012 22:31:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RpDR6-000Jaa-Bw; Mon, 23 Jan 2012 06:31:24 +0000 Date: Mon, 23 Jan 2012 15:31:23 +0900 Message-ID: From: Randy Bush To: "Aamer Akhter (aakhter)" In-Reply-To: <7F298ACC76CC154F832B6D02852D169F06EF9AF2@XMB-RCD-101.cisco.com> References: <7F298ACC76CC154F832B6D02852D169F06EF9AF2@XMB-RCD-101.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] request for presentation slot regarding perfmon drafts RE: call for slots X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 06:31:29 -0000 > draft-akhter-opsawg-perfmon-ipfix > draft-akhter-opsawg-perfmon-method > > There is a need to be able to quantify and report the performance of > network applications and the network service in handling user data. > This performance data provides information essential in validating > service level agreements, fault isolation as well as early warnings > of network greater problems. This document describes a generic > methodology for calculating metrics related to network based > applications. In addition, to the performance metrics, several > additional information elements are included to help provide greater > context to the reports. The measurements use audio/video > applications as base examples but are not restricted to these class > of applications. isn't this bmwg stuff? randy From aakhter@cisco.com Mon Jan 23 05:55:13 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DE721F8714 for ; Mon, 23 Jan 2012 05:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 tknEoCAfBRvP for ; Mon, 23 Jan 2012 05:55:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5360B21F8700 for ; Mon, 23 Jan 2012 05:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=1352; q=dns/txt; s=iport; t=1327326912; x=1328536512; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SDRzZqhmKcDz2LQkzfvsZhZVxa530ke+hEIuPVJM4PQ=; b=f0RXB+FSN5dVz3+t5EATu1L7ry+7h7xHsLk6p3dKAxoAFmAhn4pearyH 2sqYBxC2LXFF7JWSimnfKpWNgMRIdWET6DwXPuIq/7NaYTsVvZjA1GXx3 MIjOD6tLhPiQTJR+q5GMUrSMcKdn9EzkqrplrHF1SoERNuBWHchGmV2Rl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKFlHU+tJV2a/2dsb2JhbABCriWBBYFyAQEBAwESAQoTCj8FBwQCAQgRBAEBCwYXAQYBRQkIAQEEEwgah1qaIAGdd4tDYwSIO59L X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="53137578" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jan 2012 13:55:12 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0NDtBQb007205; Mon, 23 Jan 2012 13:55:11 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 07:55:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jan 2012 07:54:51 -0600 Message-ID: <7F298ACC76CC154F832B6D02852D169F06EF9B4E@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] request for presentation slot regarding perfmon drafts RE: call for slots Thread-Index: AczZmKNNl+EBKedgTRaPXB8MRQmUfgAPcP5w References: <7F298ACC76CC154F832B6D02852D169F06EF9AF2@XMB-RCD-101.cisco.com> From: "Aamer Akhter (aakhter)" To: "Randy Bush" X-OriginalArrivalTime: 23 Jan 2012 13:55:11.0810 (UTC) FILETIME=[A0096220:01CCD9D6] Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] request for presentation slot regarding perfmon drafts RE: call for slots X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:55:13 -0000 Hi Randy, We're talked about it in BMWG, but as this proposal is regarding outside the lab (which is where the BMWG work exists) application traffic OPSAWG seemed to be the closest match. -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Monday, January 23, 2012 1:31 AM To: Aamer Akhter (aakhter) Cc: Christopher LILJENSTOLPE; opsawg@ietf.org Subject: Re: [OPSAWG] request for presentation slot regarding perfmon drafts RE: call for slots > draft-akhter-opsawg-perfmon-ipfix =20 > draft-akhter-opsawg-perfmon-method =20 >=20 > There is a need to be able to quantify and report the performance of > network applications and the network service in handling user data. > This performance data provides information essential in validating > service level agreements, fault isolation as well as early warnings > of network greater problems. This document describes a generic > methodology for calculating metrics related to network based > applications. In addition, to the performance metrics, several > additional information elements are included to help provide greater > context to the reports. The measurements use audio/video > applications as base examples but are not restricted to these class > of applications. isn't this bmwg stuff? randy From bclaise@cisco.com Mon Jan 23 09:36:03 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5441321F86CF for ; Mon, 23 Jan 2012 09:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 MqNuacC-OGGs for ; Mon, 23 Jan 2012 09:36:02 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFFC21F84A2 for ; Mon, 23 Jan 2012 09:36:02 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0NHZvoB014581; Mon, 23 Jan 2012 18:35:57 +0100 (CET) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0NHZrAI015237; Mon, 23 Jan 2012 18:35:54 +0100 (CET) Message-ID: <4F1D9A79.8030001@cisco.com> Date: Mon, 23 Jan 2012 18:35:53 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Christopher LILJENSTOLPE , opsawg@ietf.org, draft-ietf-opsawg-management-stds@tools.ietf.org References: <519C94F2-F0FB-46EE-AD8F-426E389F62B9@cdl.asgaard.org> <20120122152950.GB42368@elstar.local> In-Reply-To: <20120122152950.GB42368@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:36:03 -0000 Juergen, Thanks for your careful feedback, and suggestions. I specifically like the fact that you cared to propose some new text. Two comments > > x) I doubt these are in any way practically relevant nor am I sure > about the support agreement argument. This neither RFC3165 nor > RFC4011 seem to be used in practice, I would rather drop these > three paragraphs. > > OLD: > > [RFC3165] supports the use of user-written scripts to delegate > management functionality. > > Policy Based Management MIB [RFC4011] defines objects that enable > policy-based monitoring using SNMP, using a scripting language, and a > script execution environment. > > Few vendors have implemented MIB modules that support scripting. > Some vendors consider running user-developed scripts within the > managed device as a violation of support agreements. > > NEW: BC> Not sure if "This neither RFC3165 nor RFC4011 seem to be used in practice" is a good argument. So I would rather keep, as this RFC is supposed to be an inventory. > > > z) Why do we have text for something that according to RFC 6248 has > seen no usage? > > OLD: > > The IPPM working group has defined [BCP108][RFC4148] "IP Performance > Metrics (IPPM) Metrics Registry". The IANA-assigned registry > contains an initial set of OBJECT IDENTITIES to currently defined > metrics in the IETF as well as defines the rules for adding IP > Performance Metrics that are defined in the future. However, the > current registry structure has been found to be insufficiently > detailed to uniquely identify IPPM metrics. Due to the ambiguities > between the current metrics registrations and the metrics used, and > the apparent non-adoption of the registry in practice, it has been > proposed to reclassify [RFC4148] as Obsolete. > > Note: With the publication of [RFC6248] the latest IANA registry for > IPPM metrics and [RFC4148] have been declared Obsolete and IANA > prevents registering new metrics. Actual users can continue using > the current registry and its contents. > > NEW: BC> Since this decision [RFC6248] is brand new, I would rather keep the second paragraph. A little bit of history would not hurt. Thanks again. Regards, Benoit From j.schoenwaelder@jacobs-university.de Mon Jan 23 11:12:58 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7921F86C1 for ; Mon, 23 Jan 2012 11:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.23 X-Spam-Level: X-Spam-Status: No, score=-103.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 TxxujDOYajG6 for ; Mon, 23 Jan 2012 11:12:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0F82F21F8618 for ; Mon, 23 Jan 2012 11:12:57 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F989206A6; Mon, 23 Jan 2012 20:12:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2IAgUFC8kBGZ; Mon, 23 Jan 2012 20:12:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3B0420222; Mon, 23 Jan 2012 20:12:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 318C31C98E80; Mon, 23 Jan 2012 20:12:37 +0100 (CET) Date: Mon, 23 Jan 2012 20:12:37 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20120123191237.GA47321@elstar.local> Mail-Followup-To: Benoit Claise , Christopher LILJENSTOLPE , opsawg@ietf.org, draft-ietf-opsawg-management-stds@tools.ietf.org References: <519C94F2-F0FB-46EE-AD8F-426E389F62B9@cdl.asgaard.org> <20120122152950.GB42368@elstar.local> <4F1D9A79.8030001@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F1D9A79.8030001@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, draft-ietf-opsawg-management-stds@tools.ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 19:12:58 -0000 On Mon, Jan 23, 2012 at 06:35:53PM +0100, Benoit Claise wrote: > Juergen, > > Thanks for your careful feedback, and suggestions. > I specifically like the fact that you cared to propose some new text. > > Two comments > > > >x) I doubt these are in any way practically relevant nor am I sure > > about the support agreement argument. This neither RFC3165 nor > > RFC4011 seem to be used in practice, I would rather drop these > > three paragraphs. > > > > OLD: > > > > [RFC3165] supports the use of user-written scripts to delegate > > management functionality. > > > > Policy Based Management MIB [RFC4011] defines objects that enable > > policy-based monitoring using SNMP, using a scripting language, and a > > script execution environment. > > > > Few vendors have implemented MIB modules that support scripting. > > Some vendors consider running user-developed scripts within the > > managed device as a violation of support agreements. > > > > NEW: > > BC> Not sure if "This neither RFC3165 nor RFC4011 seem to be used in > practice" is a good argument. > So I would rather keep, as this RFC is supposed to be an inventory. I think you told me several times it is not inventory. If this is supposed to be an inventory, then I must say the document is somewhat incomplete. That said, I am religious since a reference to 3165 is actually good for my h-index (but otherwise likely more confusing readers than helping them ;-). > >z) Why do we have text for something that according to RFC 6248 has > > seen no usage? > > > > OLD: > > > > The IPPM working group has defined [BCP108][RFC4148] "IP Performance > > Metrics (IPPM) Metrics Registry". The IANA-assigned registry > > contains an initial set of OBJECT IDENTITIES to currently defined > > metrics in the IETF as well as defines the rules for adding IP > > Performance Metrics that are defined in the future. However, the > > current registry structure has been found to be insufficiently > > detailed to uniquely identify IPPM metrics. Due to the ambiguities > > between the current metrics registrations and the metrics used, and > > the apparent non-adoption of the registry in practice, it has been > > proposed to reclassify [RFC4148] as Obsolete. > > > > Note: With the publication of [RFC6248] the latest IANA registry for > > IPPM metrics and [RFC4148] have been declared Obsolete and IANA > > prevents registering new metrics. Actual users can continue using > > the current registry and its contents. > > > > NEW: > > BC> Since this decision [RFC6248] is brand new, I would rather keep the second > paragraph. A little bit of history would not hurt. > I remain unconvinced that pointing readers to stuff that is not used (and where it is even documented that it is not used) is helpful. A historic perspective of the development of NM standards I think is a different document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Jan 23 16:24:30 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756DE21F85C3 for ; Mon, 23 Jan 2012 16:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 RfM+SOp8weiu for ; Mon, 23 Jan 2012 16:24:29 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5104721F85BB for ; Mon, 23 Jan 2012 16:24:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0O0JDWD023459; Tue, 24 Jan 2012 01:19:13 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q0O0JAaL010071; Tue, 24 Jan 2012 01:19:11 +0100 (CET) Message-ID: <4F1DF8FE.2070205@cisco.com> Date: Tue, 24 Jan 2012 01:19:10 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <519C94F2-F0FB-46EE-AD8F-426E389F62B9@cdl.asgaard.org> <20120122152950.GB42368@elstar.local> <4F1D9A79.8030001@cisco.com> <20120123191237.GA47321@elstar.local> In-Reply-To: <20120123191237.GA47321@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org, draft-ietf-opsawg-management-stds@tools.ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:24:30 -0000 Hi Juergen, Ok, fine on my side. Regards, Benoit. > On Mon, Jan 23, 2012 at 06:35:53PM +0100, Benoit Claise wrote: >> Juergen, >> >> Thanks for your careful feedback, and suggestions. >> I specifically like the fact that you cared to propose some new text. >> >> Two comments >>> x) I doubt these are in any way practically relevant nor am I sure >>> about the support agreement argument. This neither RFC3165 nor >>> RFC4011 seem to be used in practice, I would rather drop these >>> three paragraphs. >>> >>> OLD: >>> >>> [RFC3165] supports the use of user-written scripts to delegate >>> management functionality. >>> >>> Policy Based Management MIB [RFC4011] defines objects that enable >>> policy-based monitoring using SNMP, using a scripting language, and a >>> script execution environment. >>> >>> Few vendors have implemented MIB modules that support scripting. >>> Some vendors consider running user-developed scripts within the >>> managed device as a violation of support agreements. >>> >>> NEW: >> BC> Not sure if "This neither RFC3165 nor RFC4011 seem to be used in >> practice" is a good argument. >> So I would rather keep, as this RFC is supposed to be an inventory. > I think you told me several times it is not inventory. If this is > supposed to be an inventory, then I must say the document is somewhat > incomplete. That said, I am religious since a reference to 3165 is > actually good for my h-index (but otherwise likely more confusing > readers than helping them ;-). > >>> z) Why do we have text for something that according to RFC 6248 has >>> seen no usage? >>> >>> OLD: >>> >>> The IPPM working group has defined [BCP108][RFC4148] "IP Performance >>> Metrics (IPPM) Metrics Registry". The IANA-assigned registry >>> contains an initial set of OBJECT IDENTITIES to currently defined >>> metrics in the IETF as well as defines the rules for adding IP >>> Performance Metrics that are defined in the future. However, the >>> current registry structure has been found to be insufficiently >>> detailed to uniquely identify IPPM metrics. Due to the ambiguities >>> between the current metrics registrations and the metrics used, and >>> the apparent non-adoption of the registry in practice, it has been >>> proposed to reclassify [RFC4148] as Obsolete. >>> >>> Note: With the publication of [RFC6248] the latest IANA registry for >>> IPPM metrics and [RFC4148] have been declared Obsolete and IANA >>> prevents registering new metrics. Actual users can continue using >>> the current registry and its contents. >>> >>> NEW: >> BC> Since this decision [RFC6248] is brand new, I would rather keep the second >> paragraph. A little bit of history would not hurt. >> > I remain unconvinced that pointing readers to stuff that is not used > (and where it is even documented that it is not used) is helpful. A > historic perspective of the development of NM standards I think is a > different document. > > /js > From balajivenkat@force10networks.com Wed Jan 25 20:11:52 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5821F85EE for ; Wed, 25 Jan 2012 20:11:52 -0800 (PST) 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.001, 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 3aMYWKDFQEop for ; Wed, 25 Jan 2012 20:11:51 -0800 (PST) Received: from mx.force10networks.com (maa.force10networks.com [59.163.202.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4A11021F85B7 for ; Wed, 25 Jan 2012 20:11:50 -0800 (PST) Received: from EXCH-CLUSTER-11.force10networks.com ([10.16.127.20]) by exch7-maa-fe.force10networks.com ([10.16.126.10]) with mapi; Thu, 26 Jan 2012 09:41:45 +0530 From: Balaji Venkat Venkataswami To: "opsawg@ietf.org" Date: Thu, 26 Jan 2012 09:41:40 +0530 Thread-Topic: I-D Action: draft-janapath-intarea-traceflow-00.txt Thread-Index: Aczb4GeAaWcXKGukTma2gO+dw9PEOwAAAVJw Message-ID: <5EC91DDA759C324DB62C5A5F7B492219394D4C2E1B@EXCH-CLUSTER-11.force10networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EqWy FVOa G7mi HzXP Ii8f KQLl KTob KvAq OHXr P96q Q4bE R1Kf Tc4w TxHk VPKx XfhV; 3; bwBwAHMAYQB3AGcAQABpAGUAdABmAC4AbwByAGcAOwBwAGgAbwBvAHMAZQBAAGYAYgAuAGMAbwBtADsAcgBnAHIAbwB2AGUAcwBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0A; Sosha1_v1; 7; {710B6B91-07D8-41D7-8C3A-40068954C5A6}; YgBhAGwAYQBqAGkAdgBlAG4AawBhAHQAQABmAG8AcgBjAGUAMQAwAG4AZQB0AHcAbwByAGsAcwAuAGMAbwBtAA==; Thu, 26 Jan 2012 04:11:40 GMT; RgBXADoAIABJAC0ARAAgAEEAYwB0AGkAbwBuADoAIABkAHIAYQBmAHQALQBqAGEAbgBhAHAAYQB0AGgALQBpAG4AdABhAHIAZQBhAC0AdAByAGEAYwBlAGYAbABvAHcALQAwADAALgB0AHgAdAA= x-cr-puzzleid: {710B6B91-07D8-41D7-8C3A-40068954C5A6} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5EC91DDA759C324DB62C5A5F7B492219394D4C2E1BEXCHCLUSTER11_" MIME-Version: 1.0 Cc: "phoose@fb.com" , "rgroves@microsoft.com" Subject: [OPSAWG] FW: I-D Action: draft-janapath-intarea-traceflow-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 04:11:52 -0000 --_000_5EC91DDA759C324DB62C5A5F7B492219394D4C2E1BEXCHCLUSTER11_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Cross-posting this draft to the opsawg-group for comments / suggestions as it may be of relevance. thanks and regards, Jana and team. From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com] Sent: Thursday, January 26, 2012 9:40 AM To: Balaji Venkat Venkataswami Subject: Fwd: I-D Action: draft-janapath-intarea-traceflow-00.txt ---------- Forwarded message ---------- From: > Date: Wed, Jan 25, 2012 at 10:57 AM Subject: I-D Action: draft-janapath-intarea-traceflow-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Traceflow Author(s) : Balaji Venkat Venkataswami Richard Groves Peter Hoose Filename : draft-janapath-intarea-traceflow-00.txt Pages : 43 Date : 2012-01-24 This document describes a new OAM protocol - TraceFlow that captures information pertaining to a traffic flow along the path that the flow takes through the network. TraceFlow is ECMP and link-aggregation aware and captures the information about constituent members through which the traffic flow passes. TraceFlow gathers information that is relevant to the flow such as outgoing interface Layer 3 address, Next-hop to which the packet of the flow is forwarded, effect of network policies such as access control lists on the flow. This draft requires the Traceflow protocol to be processed by Layer 3 devices only. Devices such as Layer 2 devices, MPLS LERs/LSRs along the way are passed through without any processing as if in a pass-through mode. IP tunnels such as IP-in-IP, IP-in-GRE mechanisms are expected to pass the Traceflow packets through them using the pass through mode. For achieving its purpose Traceflow advocates the use of a specific UDP destination port to be assigned from IANA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-janapath-intarea-traceflow-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-janapath-intarea-traceflow-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_5EC91DDA759C324DB62C5A5F7B492219394D4C2E1BEXCHCLUSTER11_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Cross-posting this draft to the opsawg-group for comments / suggestions

as it may be of relevance.

 

thanks and regards,

Jana and team.

 

From: Balaji venkat Venkataswami [mailto:balajivenkat299@gmail.com]
Sent: Thursday, January 26, 2012 9:40 AM
To: Balaji Venkat Venkataswami
Subject: Fwd: I-D Action: draft-janapath-intarea-traceflow-00.txt

 

 

---------- Forwarded message ----------
From: <internet-drafts@ietf.= org>
Date: Wed, Jan 25, 2012 at 10:57 AM
Subject: I-D Action: draft-janapath-intarea-traceflow-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

       Title           : Trace= flow
       Author(s)       : Balaji Venkat Venkataswami
                     = ;    Richard Groves
                     = ;    Peter Hoose
       Filename        : draft-janapath-intarea-traceflow-00.txt
       Pages           : 43        Date            : 2012-01-24

  This document describes a new OAM protocol - TraceFlow that captures=
  information pertaining to a traffic flow along the path that the flo= w
  takes through the network. TraceFlow is ECMP and link-aggregation   aware and captures the information about constituent members through=
  which the traffic flow passes. TraceFlow gathers information that is=
  relevant to the flow such as outgoing interface Layer 3 address,
  Next-hop to which the packet of the flow is forwarded, effect of
  network policies such as access control lists on the flow. This draf= t
  requires the Traceflow protocol to be processed by Layer 3 devices   only. Devices such as Layer 2 devices, MPLS LERs/LSRs along the way<= br>   are passed through without any processing as if in a pass-through   mode. IP tunnels such as IP-in-IP, IP-in-GRE mechanisms are expected=
  to pass the Traceflow packets through them using the pass through   mode.  For achieving its purpose Traceflow advocates the use of= a
  specific UDP destination port to be assigned from IANA.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-janapath-intare= a-traceflow-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-janapath-intarea= -traceflow-00.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

--_000_5EC91DDA759C324DB62C5A5F7B492219394D4C2E1BEXCHCLUSTER11_-- From mehmet.ersue@nsn.com Thu Jan 26 04:13:32 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE84921F8630 for ; Thu, 26 Jan 2012 04:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 RwhEiKBr2SKz for ; Thu, 26 Jan 2012 04:13:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F921F85ED for ; Thu, 26 Jan 2012 04:13:30 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0QCDPo3020311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 13:13:25 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0QCDJdV011124; Thu, 26 Jan 2012 13:13:25 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jan 2012 13:12:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jan 2012 13:12:16 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640352273B@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [OPSAWG] WGLC draft-ietf-opsawg-management-stds Thread-Index: AczZGr56I2ueFNurTXK2eqbMXub5TgBnDtZgACpytZA= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 26 Jan 2012 12:12:18.0064 (UTC) FILETIME=[BF6FC100:01CCDC23] Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 12:13:33 -0000 Hi Juergen, thank you for the long list of concrete and useful comments. However, a few of them need some tuning. See below. Mehmet=20 =20 > b) The definition of MIB module can probably be improved. I suggest to align > with the definition found in RFC 3410 section 6.2. >=20 > OLD: >=20 > o MIB module: A MIB definition, typically for a particular network > technology feature, that constitutes a subtree in an object > identifier tree. A MIB that is provided by a management agent is > typically composed of multiple instantiated MIB modules. >=20 > NEW: >=20 > o MIB module: MIB modules usually contain object definitions, may > contain definitions of event notifications, and sometimes include > compliance statements in terms of appropriate object and event > notification groups. MIB modules are defined by using the > data modeling language SMI. A MIB that is provided by a management > agent is typically composed of multiple instantiated MIB modules. I would suggest to remove the sentence on SMI as it does not add anything=20 substantial to the definition of the term MIB module and is also not mentioned=20 in RFC 3410 section 6.2. > e) This text can probably go without losing anything important for > the target audience (but if people believe this is important...) >=20 > OLD: >=20 > The SNMPv3 Framework extends the architectural principles of SNMPv1 > and SNMPv2 by: >=20 > o building on these three basic architectural components, in some > cases incorporating them from the SNMPv2 Framework by reference, > and >=20 > o by using the same layering principles in the definition of new > capabilities in the security and administration portion of the > architecture. >=20 > NEW: I tend to believe this would be useful as it describes exactly what the title=20 of the subchapter aims. > j) Remove unclear and unneeded reference to "this architecture". ...=20 > OLD: >=20 > There are two threats against which a Security Model within this > architecture does not protect, since they are deemed to be of lesser >=20 > NEW: >=20 > There are two threats against which a Security Model > does not protect, since they are deemed to be of lesser NEW: There are two threats against which SNMP Security Model=20 does not protect, since they are deemed to be of lesser =20 > k) I fail to see why these are two different things. In particular, > the example given in the first bullet seems to be a perfect fit for > the second bullet. Here is a proposal for a shorter version: >=20 > OLD: >=20 > [...] An agent > entity can restrict access to its MIB for a particular manager entity > in two ways: >=20 > o The agent entity can restrict access to a certain portion of its > MIB, e.g., an agent may restrict most manager principals to > viewing performance-related statistics and allow only a single > designated manager principal to view and update configuration > parameters. >=20 > o The agent can limit the operations that a principal can use on > that portion of the MIB. E.g., a particular manager principal > could be limited to read-only access to a portion of an agent's > MIB. >=20 > NEW: >=20 > [...] An agent > entity can restrict access to a certain portion of its MIB for a > particular manager principal, an agent may restrict some manager > principals to viewing performance-related statistics and allow only > a single designated manager principal to view and update > configuration parameters. Some other manager principals may not > even be allowed to read the performance-related statistics. I generally agree but would prefer a formulation which highlights that=20 these are examples. NEW:=20 An agent entity can restrict access to a certain portion of its MIB, e.g.=20 restrict some manager principals to view performance-related statistics, allow only a single designated manager principal to view or update=20 configuration parameters or disallow other manager principals to read=20 the performance-related statistics. =20 > l) I think this is wrong because my understanding is that there is a > single community-based security model that is used by both SNMPv1 > and SNMPv2. >=20 > OLD: >=20 > The SNMP Transport Security Model [RFC5591] is an alternative to the > existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security Model > [RFC3584], and the User-based Security Model [RFC3414]. >=20 > NEW: >=20 > The SNMP Transport Security Model [RFC5591] is an alternative to the > existing SNMPv1/SNMPv2 Community-based Security Model [RFC3584] and > the User-based Security Model [RFC3414]. It might be the case that SNMPv1 and SNMPv2 use a similar community- based security model. However, RFC3585 makes a differentiation between=20 the two and states that they are not identical.=20 NEW: The SNMP Transport Security Model [RFC5591] is an alternative to the existing SNMPv1 and SNMPv2 Community-based Security Models [RFC3584]=20 and the User-based Security Model [RFC3414]. > o) This seems to be wrong: RFC 5426 says "TLS transport [7] is > REQUIRED to implement and RECOMMENDED for general use." Sure, it > would be kind of stupid to implement SYSLOG without UDP support but > the standard clearly says TLS. >=20 > OLD: >=20 > number of transport mappings. However, for interoperability > purposes, SYSLOG protocol implementers are required to support the > transmission of SYSLOG Messages over UDP as defined in [RFC5426]. >=20 > NEW: >=20 > number of transport mappings. However, for interoperability > purposes, SYSLOG protocol implementers are required to support the > transmission of SYSLOG Messages over TLS as defined in [RFC5426]. The statements in RFC5426 could be interpreted as conflicting. However,=20 there are two different pov.: "for interoperability purposes, syslog protocol implementers are required to support this transport mapping."=20 and if congestion control and reliability is a concern "This is why the syslog TLS transport [7] is REQUIRED to implement and=20 RECOMMENDED for general use." I think if reliability is not a concern UDP transport can be used for interoperability.=20 Taking some text on UDP usage from RFC5426: NEW: The SYSLOG protocol layered architecture provides support for a number=20 of transport mappings. For interoperability purposes and especially in=20 managed networks, where the network path has been explicitly provisioned for UDP syslog traffic, SYSLOG protocol can be used over UDP [RFC5426].=20 To support congestion control and reliability [RFC5426] recommends=20 the use of the TLS transport. =20 > v) Is this history of any use for the target audience? Note that RFC > 1229 was obsoleted in 1994, 18 years ago. I suggest to shrink this > as follows: >=20 > OLD: >=20 > The Interfaces Group MIB [RFC2863] builds on MIB II [RFC1229] and is > used as a primary MIB for managing and monitoring the status of > network interfaces (e.g. SNMP linkdown and linkup notifications). > The 'interfaces' group in MIB II [RFC1229] defines a generic set of > managed objects and provides the means for additional managed objects > specific to particular types of network interfaces, such as Ethernet. > Extensions to the 'interfaces' group for media-specific management > can be defined based on these managed objects. Experience with > media-specific MIB modules has shown that the model defined by MIB-II > is too simplistic and static for some types of media-specific > management. The Interfaces Group MIB incorporates the interfaces > group extensions documented in MIB II and standardizes an evolution > to this model as well as fills in the detected gaps. >=20 > NEW: >=20 > The Interfaces Group MIB [RFC2863] defines a generic set of managed > objects for network interfaces and it provides the infrastructure > for additional managed objects specific to particular types of > network interfaces, such as Ethernet. You are right, however people outside of IETF still refer to MIB II very often. We need to get those people where they are and provide a reference.=20 I shortened as: NEW: The Interfaces Group MIB [RFC2863] builds on the old standard for MIB II [STD17] and is used as a primary MIB for managing and monitoring the=20 status of network interfaces. The Interfaces Group MIB [RFC2863] defines a=20 generic set of managed objects for network interfaces and it provides=20 the infrastructure for additional managed objects specific to particular types of network interfaces, such as Ethernet. > x) I doubt these are in any way practically relevant nor am I sure > about the support agreement argument. This neither RFC3165 nor > RFC4011 seem to be used in practice, I would rather drop these > three paragraphs. >=20 > OLD: >=20 > [RFC3165] supports the use of user-written scripts to delegate > management functionality. >=20 > Policy Based Management MIB [RFC4011] defines objects that enable > policy-based monitoring using SNMP, using a scripting language, and a > script execution environment. >=20 > Few vendors have implemented MIB modules that support scripting. > Some vendors consider running user-developed scripts within the > managed device as a violation of support agreements. >=20 > NEW: I agree that they are not that important. Especially RFC4011 can be skipped.=20 However, RFC3165 seems to be still in use in some SNMP tools (e.g. CIAgent=20 from snmp.com). If there is nobody in the WG who speaks up for it we=20 can skip it too. > z) Why do we have text for something that according to RFC 6248 has > seen no usage? >=20 > OLD: >=20 > The IPPM working group has defined [BCP108][RFC4148] "IP Performance > Metrics (IPPM) Metrics Registry". The IANA-assigned registry > contains an initial set of OBJECT IDENTITIES to currently defined > metrics in the IETF as well as defines the rules for adding IP > Performance Metrics that are defined in the future. However, the > current registry structure has been found to be insufficiently > detailed to uniquely identify IPPM metrics. Due to the ambiguities > between the current metrics registrations and the metrics used, and > the apparent non-adoption of the registry in practice, it has been > proposed to reclassify [RFC4148] as Obsolete. >=20 > Note: With the publication of [RFC6248] the latest IANA registry for > IPPM metrics and [RFC4148] have been declared Obsolete and IANA > prevents registering new metrics. Actual users can continue using > the current registry and its contents. >=20 > NEW: I believe it is the exact aim of this document, to highlight what is=20 recommended to use but also to explicitly state what shouldn't be=20 used anymore. As such I agree with Benoit and would like to reduce=20 the text but keep a note like below.=09 NEW: The IPPM working group has defined [RFC4148] "IP Performance Metrics=20 (IPPM) Metrics Registry". =20 Note that with the publication of [RFC6248], [RFC4148] and the corresponding=20 IANA registry for IPPM metrics have been declared Obsolete and shouldn't be used. From j.schoenwaelder@jacobs-university.de Thu Jan 26 06:50:07 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EE421F8635 for ; Thu, 26 Jan 2012 06:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.233 X-Spam-Level: X-Spam-Status: No, score=-103.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FPyFwFR5UuIK for ; Thu, 26 Jan 2012 06:50:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 664D421F8619 for ; Thu, 26 Jan 2012 06:50:04 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B5FD20C40; Thu, 26 Jan 2012 15:50:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vuSvBFj3QeAQ; Thu, 26 Jan 2012 15:50:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5AED20C35; Thu, 26 Jan 2012 15:50:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 458261CBB9A7; Thu, 26 Jan 2012 15:49:45 +0100 (CET) Date: Thu, 26 Jan 2012 15:49:44 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120126144944.GA64823@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , opsawg@ietf.org, Christopher LILJENSTOLPE References: <80A0822C5E9A4440A5117C2F4CD36A640352273B@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640352273B@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 14:50:07 -0000 On Thu, Jan 26, 2012 at 01:12:16PM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > > b) The definition of MIB module can probably be improved. I suggest to > align > > with the definition found in RFC 3410 section 6.2. > > > > OLD: > > > > o MIB module: A MIB definition, typically for a particular network > > technology feature, that constitutes a subtree in an object > > identifier tree. A MIB that is provided by a management agent > is > > typically composed of multiple instantiated MIB modules. > > > > NEW: > > > > o MIB module: MIB modules usually contain object definitions, may > > contain definitions of event notifications, and sometimes > include > > compliance statements in terms of appropriate object and event > > notification groups. MIB modules are defined by using the > > data modeling language SMI. A MIB that is provided by a > management > > agent is typically composed of multiple instantiated MIB > modules. > > I would suggest to remove the sentence on SMI as it does not add > anything > substantial to the definition of the term MIB module and is also not > mentioned > in RFC 3410 section 6.2. OK > > e) This text can probably go without losing anything important for > > the target audience (but if people believe this is important...) > > > > OLD: > > > > The SNMPv3 Framework extends the architectural principles of SNMPv1 > > and SNMPv2 by: > > > > o building on these three basic architectural components, in some > > cases incorporating them from the SNMPv2 Framework by reference, > > and > > > > o by using the same layering principles in the definition of new > > capabilities in the security and administration portion of the > > architecture. > > > > NEW: > > I tend to believe this would be useful as it describes exactly what the > title > of the subchapter aims. If you believe this is important... > > j) Remove unclear and unneeded reference to "this architecture". > ... > > OLD: > > > > There are two threats against which a Security Model within this > > architecture does not protect, since they are deemed to be of > lesser > > > > NEW: > > > > There are two threats against which a Security Model > > does not protect, since they are deemed to be of lesser > > NEW: > There are two threats against which SNMP Security Model > does not protect, since they are deemed to be of lesser Since the whole section is about SNMP and the term Security Model is SNMP specific, I do not think repeating SNMP is needed (but it also can't hurt). > > k) I fail to see why these are two different things. In particular, > > the example given in the first bullet seems to be a perfect fit for > > the second bullet. Here is a proposal for a shorter version: > > > > OLD: > > > > [...] An agent > > entity can restrict access to its MIB for a particular manager > entity > > in two ways: > > > > o The agent entity can restrict access to a certain portion of its > > MIB, e.g., an agent may restrict most manager principals to > > viewing performance-related statistics and allow only a single > > designated manager principal to view and update configuration > > parameters. > > > > o The agent can limit the operations that a principal can use on > > that portion of the MIB. E.g., a particular manager principal > > could be limited to read-only access to a portion of an agent's > > MIB. > > > > NEW: > > > > [...] An agent > > entity can restrict access to a certain portion of its MIB for a > > particular manager principal, an agent may restrict some manager > > principals to viewing performance-related statistics and allow only > > a single designated manager principal to view and update > > configuration parameters. Some other manager principals may not > > even be allowed to read the performance-related statistics. > > I generally agree but would prefer a formulation which highlights that > these are examples. > > NEW: > An agent entity can restrict access to a certain portion of its MIB, > e.g. > restrict some manager principals to view performance-related statistics, > > allow only a single designated manager principal to view or update > configuration parameters or disallow other manager principals to read > the performance-related statistics. OK > > l) I think this is wrong because my understanding is that there is a > > single community-based security model that is used by both SNMPv1 > > and SNMPv2. > > > > OLD: > > > > The SNMP Transport Security Model [RFC5591] is an alternative to > the > > existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security > Model > > [RFC3584], and the User-based Security Model [RFC3414]. > > > > NEW: > > > > The SNMP Transport Security Model [RFC5591] is an alternative to > the > > existing SNMPv1/SNMPv2 Community-based Security Model [RFC3584] and > > the User-based Security Model [RFC3414]. > > It might be the case that SNMPv1 and SNMPv2 use a similar community- > based security model. However, RFC3585 makes a differentiation between > the two and states that they are not identical. > > NEW: > The SNMP Transport Security Model [RFC5591] is an alternative to the > existing SNMPv1 and SNMPv2 Community-based Security Models [RFC3584] > and the User-based Security Model [RFC3414]. I am fine with the proposed text. > > o) This seems to be wrong: RFC 5426 says "TLS transport [7] is > > REQUIRED to implement and RECOMMENDED for general use." Sure, it > > would be kind of stupid to implement SYSLOG without UDP support but > > the standard clearly says TLS. > > > > OLD: > > > > number of transport mappings. However, for interoperability > > purposes, SYSLOG protocol implementers are required to support the > > transmission of SYSLOG Messages over UDP as defined in [RFC5426]. > > > > NEW: > > > > number of transport mappings. However, for interoperability > > purposes, SYSLOG protocol implementers are required to support the > > transmission of SYSLOG Messages over TLS as defined in [RFC5426]. > > The statements in RFC5426 could be interpreted as conflicting. However, > there are two different pov.: > > "for interoperability purposes, syslog protocol implementers are > required > to support this transport mapping." > > and if congestion control and reliability is a concern > "This is why the syslog TLS transport [7] is REQUIRED to implement and > RECOMMENDED for general use." > > I think if reliability is not a concern UDP transport can be used for > interoperability. > Taking some text on UDP usage from RFC5426: > > NEW: > The SYSLOG protocol layered architecture provides support for a number > of transport mappings. For interoperability purposes and especially in > managed networks, where the network path has been explicitly provisioned > > for UDP syslog traffic, SYSLOG protocol can be used over UDP [RFC5426]. > To support congestion control and reliability [RFC5426] recommends > the use of the TLS transport. I can accept the text since it seems to better reflect todays deployments. But I also note that RFC 5424 is pretty clear in stating the requirements: All implementations of this specification MUST support a TLS-based transport as described in [RFC5425]. All implementations of this specification SHOULD also support a UDP-based transport as described in [RFC5426]. It is RECOMMENDED that deployments of this specification use the TLS- based transport. This is not a conditional recommendation. But perhaps this text was the only way to get through the IESG. ;-) > > v) Is this history of any use for the target audience? Note that RFC > > 1229 was obsoleted in 1994, 18 years ago. I suggest to shrink this > > as follows: > > > > OLD: > > > > The Interfaces Group MIB [RFC2863] builds on MIB II [RFC1229] and > is > > used as a primary MIB for managing and monitoring the status of > > network interfaces (e.g. SNMP linkdown and linkup notifications). > > The 'interfaces' group in MIB II [RFC1229] defines a generic set of > > managed objects and provides the means for additional managed > objects > > specific to particular types of network interfaces, such as > Ethernet. > > Extensions to the 'interfaces' group for media-specific management > > can be defined based on these managed objects. Experience with > > media-specific MIB modules has shown that the model defined by > MIB-II > > is too simplistic and static for some types of media-specific > > management. The Interfaces Group MIB incorporates the interfaces > > group extensions documented in MIB II and standardizes an evolution > > to this model as well as fills in the detected gaps. > > > > NEW: > > > > The Interfaces Group MIB [RFC2863] defines a generic set of managed > > objects for network interfaces and it provides the infrastructure > > for additional managed objects specific to particular types of > > network interfaces, such as Ethernet. > > You are right, however people outside of IETF still refer to MIB II very > > often. We need to get those people where they are and provide a > reference. > I shortened as: > > NEW: > The Interfaces Group MIB [RFC2863] builds on the old standard for MIB II > > [STD17] and is used as a primary MIB for managing and monitoring the > status of network interfaces. The Interfaces Group MIB [RFC2863] > defines a > generic set of managed objects for network interfaces and it provides > the infrastructure for additional managed objects specific to particular > > types of network interfaces, such as Ethernet. OK > > x) I doubt these are in any way practically relevant nor am I sure > > about the support agreement argument. This neither RFC3165 nor > > RFC4011 seem to be used in practice, I would rather drop these > > three paragraphs. > > > > OLD: > > > > [RFC3165] supports the use of user-written scripts to delegate > > management functionality. > > > > Policy Based Management MIB [RFC4011] defines objects that enable > > policy-based monitoring using SNMP, using a scripting language, and > a > > script execution environment. > > > > Few vendors have implemented MIB modules that support scripting. > > Some vendors consider running user-developed scripts within the > > managed device as a violation of support agreements. > > > > NEW: > > I agree that they are not that important. Especially RFC4011 can be > skipped. > However, RFC3165 seems to be still in use in some SNMP tools (e.g. > CIAgent > from snmp.com). If there is nobody in the WG who speaks up for it we > can skip it too. Cool, I did not know RFC3165 is still being used in products. Now I am biased. ;-) > > z) Why do we have text for something that according to RFC 6248 has > > seen no usage? > > > > OLD: > > > > The IPPM working group has defined [BCP108][RFC4148] "IP > Performance > > Metrics (IPPM) Metrics Registry". The IANA-assigned registry > > contains an initial set of OBJECT IDENTITIES to currently defined > > metrics in the IETF as well as defines the rules for adding IP > > Performance Metrics that are defined in the future. However, the > > current registry structure has been found to be insufficiently > > detailed to uniquely identify IPPM metrics. Due to the ambiguities > > between the current metrics registrations and the metrics used, and > > the apparent non-adoption of the registry in practice, it has been > > proposed to reclassify [RFC4148] as Obsolete. > > > > Note: With the publication of [RFC6248] the latest IANA registry > for > > IPPM metrics and [RFC4148] have been declared Obsolete and IANA > > prevents registering new metrics. Actual users can continue using > > the current registry and its contents. > > > > NEW: > > I believe it is the exact aim of this document, to highlight what is > recommended to use but also to explicitly state what shouldn't be > used anymore. As such I agree with Benoit and would like to reduce > the text but keep a note like below. > > NEW: > The IPPM working group has defined [RFC4148] "IP Performance Metrics > (IPPM) Metrics Registry". > Note that with the publication of [RFC6248], [RFC4148] and the > corresponding > IANA registry for IPPM metrics have been declared Obsolete and shouldn't > be used. OK /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Sat Jan 28 09:30:33 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2042C21F852C for ; Sat, 28 Jan 2012 09:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 WcYmIu8MiPc0 for ; Sat, 28 Jan 2012 09:30:32 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 19AF221F8516 for ; Sat, 28 Jan 2012 09:30:32 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta07.westchester.pa.mail.comcast.net with comcast id T5Rd1i0031GhbT8575WYDL; Sat, 28 Jan 2012 17:30:32 +0000 Received: from [192.168.0.9] ([173.168.87.133]) by omta07.westchester.pa.mail.comcast.net with comcast id T5Vu1i00p2sd0iM3T5W1nR; Sat, 28 Jan 2012 17:30:27 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 28 Jan 2012 12:29:51 -0500 From: David Harrington To: Juergen Schoenwaelder , Mehmet Ersue Message-ID: Thread-Topic: [OPSAWG] WGLC draft-ietf-opsawg-management-stds In-Reply-To: <20120126144944.GA64823@elstar.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 17:30:33 -0000 Hi, > >> > k) I fail to see why these are two different things. In particular, >> > the example given in the first bullet seems to be a perfect fit for >> > the second bullet. Here is a proposal for a shorter version: >> > >> > OLD: >> > >> > [...] An agent >> > entity can restrict access to its MIB for a particular manager >> entity >> > in two ways: >> > >> > o The agent entity can restrict access to a certain portion of its >> > MIB, e.g., an agent may restrict most manager principals to >> > viewing performance-related statistics and allow only a single >> > designated manager principal to view and update configuration >> > parameters. >> > >> > o The agent can limit the operations that a principal can use on >> > that portion of the MIB. E.g., a particular manager principal >> > could be limited to read-only access to a portion of an agent's >> > MIB. >> > >> > NEW: >> > >> > [...] An agent >> > entity can restrict access to a certain portion of its MIB for a >> > particular manager principal, an agent may restrict some manager >> > principals to viewing performance-related statistics and allow only >> > a single designated manager principal to view and update >> > configuration parameters. Some other manager principals may not >> > even be allowed to read the performance-related statistics. >> >> I generally agree but would prefer a formulation which highlights that >> these are examples. >> >> NEW: >> An agent entity can restrict access to a certain portion of its MIB, >> e.g. >> restrict some manager principals to view performance-related statistics, >> >> allow only a single designated manager principal to view or update >> configuration parameters or disallow other manager principals to read >> the performance-related statistics. > >OK I agree with making the text examples. I think one example should be that some managers might only be allowed read-only access while others are allowed read-write access. The new text mixes operations and specific views (perf stats), so the RO vs RW example is not very clearly shown. > >> > o) This seems to be wrong: RFC 5426 says "TLS transport [7] is >> > REQUIRED to implement and RECOMMENDED for general use." Sure, it >> > would be kind of stupid to implement SYSLOG without UDP support but >> > the standard clearly says TLS. >> > >> > OLD: >> > >> > number of transport mappings. However, for interoperability >> > purposes, SYSLOG protocol implementers are required to support the >> > transmission of SYSLOG Messages over UDP as defined in [RFC5426]. >> > >> > NEW: >> > >> > number of transport mappings. However, for interoperability >> > purposes, SYSLOG protocol implementers are required to support the >> > transmission of SYSLOG Messages over TLS as defined in [RFC5426]. >> >> The statements in RFC5426 could be interpreted as conflicting. However, >> there are two different pov.: >> >> "for interoperability purposes, syslog protocol implementers are >> required >> to support this transport mapping." >> >> and if congestion control and reliability is a concern >> "This is why the syslog TLS transport [7] is REQUIRED to implement and >> RECOMMENDED for general use." >> >> I think if reliability is not a concern UDP transport can be used for >> interoperability. >> Taking some text on UDP usage from RFC5426: >> >> NEW: >> The SYSLOG protocol layered architecture provides support for a number >> of transport mappings. For interoperability purposes and especially in >> managed networks, where the network path has been explicitly provisioned >> >> for UDP syslog traffic, SYSLOG protocol can be used over UDP [RFC5426]. >> To support congestion control and reliability [RFC5426] recommends >> the use of the TLS transport. > >I can accept the text since it seems to better reflect todays >deployments. But I also note that RFC 5424 is pretty clear in stating >the requirements: > > All implementations of this specification MUST support a TLS-based > transport as described in [RFC5425]. > > All implementations of this specification SHOULD also support a > UDP-based transport as described in [RFC5426]. > > It is RECOMMENDED that deployments of this specification use the TLS- > based transport. > >This is not a conditional recommendation. But perhaps this text was >the only way to get through the IESG. ;-) RFC5426 reflects IETF consensus (not just IESG consensus) and is correctly formulated to meet the IETF-consensus about strong security found in BCP61 (RFC3365). Sometimes IETF consensus and industry deployment are not consistent (e.g., IPv6, syslog/tls, snmpv3 vs snmpv1, writable MIBs, netconf, YANG, and so on); that doesn't mean you can just ignore IETF consensus in your IETF documents. Please do NOT write your document to override the IETF consensus. David Harrington Director, Transport Area (and chair of the concluded syslog WG) From mehmet.ersue@nsn.com Mon Jan 30 11:30:49 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B6D21F8631 for ; Mon, 30 Jan 2012 11:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 eEKPjn-vs9Jl for ; Mon, 30 Jan 2012 11:30:49 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 24CEC21F858E for ; Mon, 30 Jan 2012 11:30:48 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0UJUi0I027439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jan 2012 20:30:46 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0UJUgNq015627; Mon, 30 Jan 2012 20:30:42 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 20:30:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jan 2012 20:30:41 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WGLC draft-ietf-opsawg-management-stds Thread-Index: Aczd4oryAq1gW2YHSY2z7rh/6y1TYgBorCxw References: <20120126144944.GA64823@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext David Harrington" X-OriginalArrivalTime: 30 Jan 2012 19:30:42.0175 (UTC) FILETIME=[A78F90F0:01CCDF85] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:30:49 -0000 Hi David, > >> NEW: > >> An agent entity can restrict access to a certain portion of its MIB, > >> e.g. > >> restrict some manager principals to view performance-related statistics, > >> > >> allow only a single designated manager principal to view or update > >> configuration parameters or disallow other manager principals to read > >> the performance-related statistics. > > > >OK >=20 > I agree with making the text examples. I think one example should be that > some managers might only be allowed read-only access while others are > allowed read-write access. > The new text mixes operations and specific views (perf stats), so the RO > vs RW example is not very clearly shown. Would this work for you? If not please provide some NEW text. NEW:=20 An agent entity can restrict access to a certain portion of its MIB, e.g. restrict=20 some manager principals to view only performance-related statistics, or disallow=20 other manager principals to read those performance-related statistics.=20 An agent entity can also restrict to monitoring (read-only) as opposed to monitoring=20 and configuration (read-write) of a certain portion of its MIB, e.g. allowing only a=20 single designated manager principal to update configuration parameters. Cheers, Mehmet From dromasca@avaya.com Tue Jan 31 02:49:50 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0685321F8508 for ; Tue, 31 Jan 2012 02:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.384 X-Spam-Level: X-Spam-Status: No, score=-103.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 t3BSzeIK5LLR for ; Tue, 31 Jan 2012 02:49:49 -0800 (PST) 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 3B4CB21F8505 for ; Tue, 31 Jan 2012 02:49:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALvGJ0+HCzI1/2dsb2JhbABDrl+BBYFyAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQELBgwLAQYBJh8JCAEBBAESCBqHY50Rm2gEiwEsBgGDZgGBBoJ1YwSbF4xa X-IronPort-AV: E=Sophos;i="4.71,595,1320642000"; d="scan'208";a="288814032" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 31 Jan 2012 05:49:47 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Jan 2012 05:35:53 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jan 2012 11:49:43 +0100 Message-ID: In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WGLC draft-ietf-opsawg-management-stds Thread-Index: Aczd4oryAq1gW2YHSY2z7rh/6y1TYgBorCxwACAK2PA= References: <20120126144944.GA64823@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext David Harrington" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:49:50 -0000 Sorry to jump in with a detail terminology question, but what does exactly 'manager principal' mean, where does this term come from? It is not used in the current version of the document AFAICT, possibly I missed something in the discussion. =20 Thanks and Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Ersue, Mehmet (NSN - DE/Munich) > Sent: Monday, January 30, 2012 9:31 PM > To: ext David Harrington > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds >=20 > Hi David, >=20 > > >> NEW: > > >> An agent entity can restrict access to a certain portion of its > MIB, > > >> e.g. > > >> restrict some manager principals to view performance-related > statistics, > > >> > > >> allow only a single designated manager principal to view or update > > >> configuration parameters or disallow other manager principals to > read > > >> the performance-related statistics. > > > > > >OK > > > > I agree with making the text examples. I think one example should be > that > > some managers might only be allowed read-only access while others are > > allowed read-write access. > > The new text mixes operations and specific views (perf stats), so the > RO > > vs RW example is not very clearly shown. >=20 > Would this work for you? If not please provide some NEW text. >=20 > NEW: > An agent entity can restrict access to a certain portion of its MIB, > e.g. restrict > some manager principals to view only performance-related statistics, or > disallow > other manager principals to read those performance-related statistics. > An agent entity can also restrict to monitoring (read-only) as opposed > to monitoring > and configuration (read-write) of a certain portion of its MIB, e.g. > allowing only a > single designated manager principal to update configuration parameters. >=20 > Cheers, > Mehmet >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From mehmet.ersue@nsn.com Tue Jan 31 03:10:05 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D3C21F8598 for ; Tue, 31 Jan 2012 03:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Xxlxab9Af44Z for ; Tue, 31 Jan 2012 03:10:03 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C1C3921F855E for ; Tue, 31 Jan 2012 03:09:58 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0VB9nGF009355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Jan 2012 12:09:50 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0VB9k7F011610; Tue, 31 Jan 2012 12:09:49 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 12:09:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jan 2012 12:09:46 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403563ECE@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WGLC draft-ietf-opsawg-management-stds Thread-Index: Aczd4oryAq1gW2YHSY2z7rh/6y1TYgBorCxwACAK2PAAAJJCkA== References: <20120126144944.GA64823@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Romascanu, Dan (Dan)" , "ext David Harrington" X-OriginalArrivalTime: 31 Jan 2012 11:09:47.0401 (UTC) FILETIME=[D7EEBF90:01CCE008] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 11:10:05 -0000 Hi Dan, STD62 uses the term principal to describe: securityName - the principal on whose behalf access is requested Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, January 31, 2012 11:50 AM > To: Ersue, Mehmet (NSN - DE/Munich); ext David Harrington > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] WGLC draft-ietf-opsawg-management-stds >=20 > Sorry to jump in with a detail terminology question, but what does > exactly 'manager principal' mean, where does this term come from? It is > not used in the current version of the document AFAICT, possibly I > missed something in the discussion. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf Of Ersue, Mehmet (NSN - DE/Munich) > > Sent: Monday, January 30, 2012 9:31 PM > > To: ext David Harrington > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds > > > > Hi David, > > > > > >> NEW: > > > >> An agent entity can restrict access to a certain portion of its > > MIB, > > > >> e.g. > > > >> restrict some manager principals to view performance-related > > statistics, > > > >> > > > >> allow only a single designated manager principal to view or > update > > > >> configuration parameters or disallow other manager principals to > > read > > > >> the performance-related statistics. > > > > > > > >OK > > > > > > I agree with making the text examples. I think one example should be > > that > > > some managers might only be allowed read-only access while others > are > > > allowed read-write access. > > > The new text mixes operations and specific views (perf stats), so > the > > RO > > > vs RW example is not very clearly shown. > > > > Would this work for you? If not please provide some NEW text. > > > > NEW: > > An agent entity can restrict access to a certain portion of its MIB, > > e.g. restrict > > some manager principals to view only performance-related statistics, > or > > disallow > > other manager principals to read those performance-related statistics. > > An agent entity can also restrict to monitoring (read-only) as opposed > > to monitoring > > and configuration (read-write) of a certain portion of its MIB, e.g. > > allowing only a > > single designated manager principal to update configuration > parameters. > > > > Cheers, > > Mehmet > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg From dromasca@avaya.com Tue Jan 31 03:11:46 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A758A21F8599 for ; Tue, 31 Jan 2012 03:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=-0.287, 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 A3XPL8bxfeHj for ; Tue, 31 Jan 2012 03:11:46 -0800 (PST) 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 0E83B21F8598 for ; Tue, 31 Jan 2012 03:11:45 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKDLJ0+HCzI1/2dsb2JhbABDrl+BBYFyAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQELBgwLAQYBJh8JCAEBBAESCBqHY50Mm2gEixAsBgGDZgGBBoJ1YwSbGYxc X-IronPort-AV: E=Sophos;i="4.71,595,1320642000"; d="scan'208";a="229373169" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 Jan 2012 06:11:44 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 31 Jan 2012 05:57:50 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jan 2012 12:11:41 +0100 Message-ID: In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403563ECE@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] WGLC draft-ietf-opsawg-management-stds Thread-Index: Aczd4oryAq1gW2YHSY2z7rh/6y1TYgBorCxwACAK2PAAAJJCkAAAUw6g References: <20120126144944.GA64823@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A6403563ECE@DEMUEXC006.nsn-intra.net> From: "Romascanu, Dan (Dan)" To: "Ersue, Mehmet (NSN - DE/Munich)" , "ext David Harrington" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 11:11:46 -0000 Can you please explain this and provide the reference in the text?=20 Thanks and Regards, Dan > -----Original Message----- > From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] > Sent: Tuesday, January 31, 2012 1:10 PM > To: Romascanu, Dan (Dan); ext David Harrington > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] WGLC draft-ietf-opsawg-management-stds >=20 > Hi Dan, >=20 > STD62 uses the term principal to describe: > securityName - the principal on whose behalf access is requested >=20 > Cheers, > Mehmet >=20 >=20 > > -----Original Message----- > > From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Tuesday, January 31, 2012 11:50 AM > > To: Ersue, Mehmet (NSN - DE/Munich); ext David Harrington > > Cc: opsawg@ietf.org > > Subject: RE: [OPSAWG] WGLC draft-ietf-opsawg-management-stds > > > > Sorry to jump in with a detail terminology question, but what does > > exactly 'manager principal' mean, where does this term come from? It > is > > not used in the current version of the document AFAICT, possibly I > > missed something in the discussion. > > > > Thanks and Regards, > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > > Behalf Of Ersue, Mehmet (NSN - DE/Munich) > > > Sent: Monday, January 30, 2012 9:31 PM > > > To: ext David Harrington > > > Cc: opsawg@ietf.org > > > Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds > > > > > > Hi David, > > > > > > > >> NEW: > > > > >> An agent entity can restrict access to a certain portion of > its > > > MIB, > > > > >> e.g. > > > > >> restrict some manager principals to view performance-related > > > statistics, > > > > >> > > > > >> allow only a single designated manager principal to view or > > update > > > > >> configuration parameters or disallow other manager principals > to > > > read > > > > >> the performance-related statistics. > > > > > > > > > >OK > > > > > > > > I agree with making the text examples. I think one example should > be > > > that > > > > some managers might only be allowed read-only access while others > > are > > > > allowed read-write access. > > > > The new text mixes operations and specific views (perf stats), so > > the > > > RO > > > > vs RW example is not very clearly shown. > > > > > > Would this work for you? If not please provide some NEW text. > > > > > > NEW: > > > An agent entity can restrict access to a certain portion of its > MIB, > > > e.g. restrict > > > some manager principals to view only performance-related > statistics, > > or > > > disallow > > > other manager principals to read those performance-related > statistics. > > > An agent entity can also restrict to monitoring (read-only) as > opposed > > > to monitoring > > > and configuration (read-write) of a certain portion of its MIB, > e.g. > > > allowing only a > > > single designated manager principal to update configuration > > parameters. > > > > > > Cheers, > > > Mehmet > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www.ietf.org/mailman/listinfo/opsawg From bertietf@bwijnen.net Tue Jan 31 03:22:33 2012 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250E921F84D0 for ; Tue, 31 Jan 2012 03:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 CK7T9bLjUEOD for ; Tue, 31 Jan 2012 03:22:32 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF0921F84C9 for ; Tue, 31 Jan 2012 03:22:32 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RsBnA-0004JE-1m; Tue, 31 Jan 2012 12:22:29 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RsBn9-0004ZK-KR; Tue, 31 Jan 2012 12:22:27 +0100 Message-ID: <4F27CEF3.8050000@bwijnen.net> Date: Tue, 31 Jan 2012 12:22:27 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <20120126144944.GA64823@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6403563BB5@DEMUEXC006.nsn-intra.net> <80A0822C5E9A4440A5117C2F4CD36A6403563ECE@DEMUEXC006.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4facd10000aa608af176d49dbbbde7878 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 11:22:33 -0000 I would think that "principal" is good enough, and that "manager principal" or "managers principals" is a weird term. I do not think STD62 speaks about "manager principal" or "server principal" but just about "principal". Not that I will loose any sleep over it though. Bert On 1/31/12 12:11 PM, Romascanu, Dan (Dan) wrote: > Can you please explain this and provide the reference in the text? > > Thanks and Regards, > > Dan > > > > >> -----Original Message----- >> From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com] >> Sent: Tuesday, January 31, 2012 1:10 PM >> To: Romascanu, Dan (Dan); ext David Harrington >> Cc: opsawg@ietf.org >> Subject: RE: [OPSAWG] WGLC draft-ietf-opsawg-management-stds >> >> Hi Dan, >> >> STD62 uses the term principal to describe: >> securityName - the principal on whose behalf access is requested >> >> Cheers, >> Mehmet >> >> >>> -----Original Message----- >>> From: ext Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] >>> Sent: Tuesday, January 31, 2012 11:50 AM >>> To: Ersue, Mehmet (NSN - DE/Munich); ext David Harrington >>> Cc: opsawg@ietf.org >>> Subject: RE: [OPSAWG] WGLC draft-ietf-opsawg-management-stds >>> >>> Sorry to jump in with a detail terminology question, but what does >>> exactly 'manager principal' mean, where does this term come from? It >> is >>> not used in the current version of the document AFAICT, possibly I >>> missed something in the discussion. >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On >>>> Behalf Of Ersue, Mehmet (NSN - DE/Munich) >>>> Sent: Monday, January 30, 2012 9:31 PM >>>> To: ext David Harrington >>>> Cc: opsawg@ietf.org >>>> Subject: Re: [OPSAWG] WGLC draft-ietf-opsawg-management-stds >>>> >>>> Hi David, >>>> >>>>>>> NEW: >>>>>>> An agent entity can restrict access to a certain portion of >> its >>>> MIB, >>>>>>> e.g. >>>>>>> restrict some manager principals to view performance-related >>>> statistics, >>>>>>> >>>>>>> allow only a single designated manager principal to view or >>> update >>>>>>> configuration parameters or disallow other manager principals >> to >>>> read >>>>>>> the performance-related statistics. >>>>>> >>>>>> OK >>>>> >>>>> I agree with making the text examples. I think one example > should >> be >>>> that >>>>> some managers might only be allowed read-only access while > others >>> are >>>>> allowed read-write access. >>>>> The new text mixes operations and specific views (perf stats), > so >>> the >>>> RO >>>>> vs RW example is not very clearly shown. >>>> >>>> Would this work for you? If not please provide some NEW text. >>>> >>>> NEW: >>>> An agent entity can restrict access to a certain portion of its >> MIB, >>>> e.g. restrict >>>> some manager principals to view only performance-related >> statistics, >>> or >>>> disallow >>>> other manager principals to read those performance-related >> statistics. >>>> An agent entity can also restrict to monitoring (read-only) as >> opposed >>>> to monitoring >>>> and configuration (read-write) of a certain portion of its MIB, >> e.g. >>>> allowing only a >>>> single designated manager principal to update configuration >>> parameters. >>>> >>>> Cheers, >>>> Mehmet >>>> >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >