From nobody Mon Feb 2 09:32:38 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C65D1A87AB for ; Mon, 2 Feb 2015 09:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56e1jtb4hSAz for ; Mon, 2 Feb 2015 09:32:28 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7441A87A8 for ; Mon, 2 Feb 2015 09:32:26 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-04v.sys.comcast.net with comcast id nVYD1p00257bBgG01VYSGY; Mon, 02 Feb 2015 17:32:26 +0000 Received: from [192.168.0.5] ([72.187.162.59]) by resomta-po-13v.sys.comcast.net with comcast id nVYC1p0081HC2N001VYFDA; Mon, 02 Feb 2015 17:32:24 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Harrington In-Reply-To: <54BB6D67.6010509@gmx.net> Date: Mon, 2 Feb 2015 12:32:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <23D534A9-90E7-45C0-AE78-419617965D15@comcast.net> References: <54BB6D67.6010509@gmx.net> To: "B.-C. Boesch" X-Mailer: Apple Mail (2.1878.6) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1422898346; bh=8pUoZYFPNPe6N1SEtoWGzQJHwLbKjoLAD/Vstz68ZAc=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=OqZJgy7X7KvsachavAZeTmYF2hyglQZjC7zA+QgwygtLjlY3bcFMNVqUVTa24exbI tJmPvP+nYx0jZFikhkbqVoptj1EWTmqWFApS/AiAQYNyQYuwi2FgAU9FUBLxrtpn14 wFCz41WpXG5U1W+PFAgQ003jOrlsO4h1bm3nplwjUFnWKRheQn+lWu9TJubmhMOZ22 2ZfbjRCVaTkyaBKeEGjVgziexxVj9lnXgWJvfHZcl4SpgTHhmJVfGkcJow/pjF2bRd WHr7M2tNXRQjFFHuk5OHWyjvXaQKd/RzMtnh1NUqxmNWuJGGdI2y8zU6oi/Na95M+p O27V22zFoHuSA== Archived-At: Cc: OPSAWG@ietf.org, Lime@ietf.org Subject: Re: [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 17:32:33 -0000 I think similar work is being addressed in the sacm wg. David Harrington ietfdbh@comcast.net On Jan 18, 2015, at 3:23 AM, B.-C. Boesch wrote: > Dear Community, >=20 > Efficiency of Intrusion Detection Systems (IDS) depends on their = configuration and coverage of services. The coverage depends on used IDS = with currently vendor-specific configurations. In case of usage of = multiple systems the operations could become complex. Individual = Communication between management interface and the IDS entities results = that current multi-vendor IDS architectures do not interact with each = other. They are independent coexistent. >=20 > The Internet Draft defines data formats and exchange procedures to = standardize parametrization information exchange into intrusion = detection and response systems from a Manager to an Analyzer. >=20 > The created Intrusion Detection Parametrization Exchange Format = (IDPEF) is intended to be a standard data format to parametrize IDS. The = development of this open standardized format and the Intrusion Detection = Message Exchange Format (IDMEF) will be enable in combination = interoperability among commercial, open source, and research systems, = allowing users to mix-and-match the deployment of these systems = according to their strong and weak points to obtain an optimal IDS = implementation. >=20 > The most obvious place to implement IDPEF is in the data channel = between a Manager and an Analyzer of an IDS within this data channel = where the Manager sends the configuration parameters to the Analyzers. = But there are other places where the IDPEF can be useful: >=20 > - Combination of specialized IDS like application-IDS with server-IDS, = WLAN-IDS and network-IDS to one functional interacting meta-IDS. >=20 > - Management of different IDS vendors with one central management = interface. >=20 > - Interaction of different IDS by using IDPEF and IDMEF. >=20 > - Parametrization backups and restore of parametrized IDS entities. >=20 > - For a communication between a Manager and a Manager in a multi-stage = management architecture. >=20 > I am happy to invite you to give me feedback, suggestions, notations, = hints, recommendations, etc. to improve the Internet Draft. The initial = version of the Internet Draft could be found at: >=20 > http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt >=20 > Kind regards, >=20 > B.-C. Boesch >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Feb 2 11:14:28 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009A11A1A42; Mon, 2 Feb 2015 11:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfQtoxJrRgGL; Mon, 2 Feb 2015 11:13:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6DC1A1A46; Mon, 2 Feb 2015 11:13:38 -0800 (PST) Received: from [192.168.2.105] ([79.246.19.23]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MOw4N-1YKqsp1qkh-006KeN; Mon, 02 Feb 2015 20:13:36 +0100 Message-ID: <54CFCC5F.6080709@gmx.net> Date: Mon, 02 Feb 2015 20:13:35 +0100 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Harrington References: <54BB6D67.6010509@gmx.net> <23D534A9-90E7-45C0-AE78-419617965D15@comcast.net> In-Reply-To: <23D534A9-90E7-45C0-AE78-419617965D15@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:D8XI1M81zqUQs/mD82mPNbovlVl+YhAB2M0BxmN6l+yef3I72Gm RBmqa8MIcSSPBmRuo7euT1KgU7SC6+22Hjsqb0m6UnLMWHWBoauPK3DMWFpN6c30gf3rJD9 wxDyLGVHK3wydOcPCfyFxUTkuudUJjmthFo7XtAwkYOgtjMustNP/mZQRiujTXbB4Ky9Six bzZn7HNj623gks1pjxXkw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: ietf@ietf.org, OPSAWG@ietf.org, Lime@ietf.org, sacm@ietf.org, saag@ietf.org Subject: Re: [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:13:51 -0000 Dear David, thanks for your hint to the SACM WG. I have also posted it within the SACM community for any comments, feedback, suggestions, notations, hints, recommendations, etc. but haven´t received any response or feedback to the Internet Draft so far. I hope this will change and a lively discussion is going to come up. Kind regards B.-C. Boesch Am 02.02.2015 um 18:32 schrieb David Harrington: > I think similar work is being addressed in the sacm wg. > > David Harrington > ietfdbh@comcast.net > > > > On Jan 18, 2015, at 3:23 AM, B.-C. Boesch wrote: > >> Dear Community, >> >> Efficiency of Intrusion Detection Systems (IDS) depends on their configuration and coverage of services. The coverage depends on used IDS with currently vendor-specific configurations. In case of usage of multiple systems the operations could become complex. Individual Communication between management interface and the IDS entities results that current multi-vendor IDS architectures do not interact with each other. They are independent coexistent. >> >> The Internet Draft defines data formats and exchange procedures to standardize parametrization information exchange into intrusion detection and response systems from a Manager to an Analyzer. >> >> The created Intrusion Detection Parametrization Exchange Format (IDPEF) is intended to be a standard data format to parametrize IDS. The development of this open standardized format and the Intrusion Detection Message Exchange Format (IDMEF) will be enable in combination interoperability among commercial, open source, and research systems, allowing users to mix-and-match the deployment of these systems according to their strong and weak points to obtain an optimal IDS implementation. >> >> The most obvious place to implement IDPEF is in the data channel between a Manager and an Analyzer of an IDS within this data channel where the Manager sends the configuration parameters to the Analyzers. But there are other places where the IDPEF can be useful: >> >> - Combination of specialized IDS like application-IDS with server-IDS, WLAN-IDS and network-IDS to one functional interacting meta-IDS. >> >> - Management of different IDS vendors with one central management interface. >> >> - Interaction of different IDS by using IDPEF and IDMEF. >> >> - Parametrization backups and restore of parametrized IDS entities. >> >> - For a communication between a Manager and a Manager in a multi-stage management architecture. >> >> I am happy to invite you to give me feedback, suggestions, notations, hints, recommendations, etc. to improve the Internet Draft. The initial version of the Internet Draft could be found at: >> >> http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt >> >> Kind regards, >> >> B.-C. Boesch >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Feb 3 09:54:40 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1501A701F for ; Tue, 3 Feb 2015 09:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXunGUIoc0Kl for ; Tue, 3 Feb 2015 09:54:35 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2591A0378 for ; Tue, 3 Feb 2015 09:54:35 -0800 (PST) Received: from mb-aye.local ([192.252.247.9]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t13HsXHl086634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 3 Feb 2015 17:54:34 GMT (envelope-from joelja@bogus.com) Message-ID: <54D10B59.1020500@bogus.com> Date: Tue, 03 Feb 2015 11:54:33 -0600 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <54CC8AF0.5060609@bogus.com> In-Reply-To: <54CC8AF0.5060609@bogus.com> X-Forwarded-Message-Id: <54CC8AF0.5060609@bogus.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HI3AMen0wDnJr9NWiQpaT7XHpWDTrUsnp" Archived-At: Subject: [OPSAWG] Fwd: Re: AD help needed by opsawg X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 17:54:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HI3AMen0wDnJr9NWiQpaT7XHpWDTrUsnp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable forwarded to opsawg -------- Forwarded Message -------- Subject: Re: AD help needed by opsawg Date: Fri, 30 Jan 2015 23:57:36 -0800 From: joel jaeggli To: Bradner, Scott , ops-ads@tools.ietf.org CC: Warren Kumari On 1/30/15 2:59 AM, Bradner, Scott wrote: > Joel can you help here The registration procedure for the snmp number spaces is by-in-large standards track modula transport which is spec-required. Requesting a new auth protocol is therefore question of the draft creating one, not of altering 3411. if you are changing the registry policy or altering the interpretation of 3411 that would entail updating the draft. in the meantime we can allocate points within the number space without changing our interpretation of how the registry works. Lets roll some hmac-sha2 thanks joel > Scott >=20 >=20 >> Begin forwarded message: >> >> From: t.petch >> To: >> Date: January 30, 2015 at 5:21:37 AM EST >> Cc: , Scott Bradner >> Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp= -00.txt >> >> Joel >> >> One of the issues that I raise below on this I-D would benefit from AD= >> guidance. >> >> The I-D adds entries to a registry established by RFC3411. Should the= >> I-D then say that is updates RFC3411 or not? My experience is that so= me >> ADs say that this is NOT an update, while other ADs have said, at leas= t >> in the past, that it IS an update. I would prefer that the I-D is in= >> line with your thinking before it advances. >> >> Guidance please. >> >> The nearest parallel in the SNMP world is RFC3826 which added an >> snmpPrivProtocol to the registry also established by RFC3411, in June >> 2004, and which is not listed as updating any RFC. >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Johannes Merkle" >> To: "t.petch" ; "Warren Kumari" >> Cc: ; "Scott Bradner" >> Sent: Thursday, January 29, 2015 8:03 AM >> >>> Tom, >>> >>> thanks for the thorough review. This really helps improving the >> document. >>> >>>> s4.2.1 step 2 uses RFC6234 in a way that I think must make it a >>>> Normative reference. RFC6234 is not Standards Track but that is ok,= >> it >>>> is already in the list of IESG permitted downrefs (does that need >>>> calling out at IETF Last Call?) >>> >>> You are right, but the question is whether I should rather use >> references [RFC2104] and [SHA] here. >>> >>>> >>>> s9.1 >>>> /apply the use /apply to the use / >>> >>> Right. >>> >>>> >>>> s9.2 >>>> is it the length of the key that gives it strength or its entropy? >> Is >>>> abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 >>>> really stronger than >>>> !qaurk/99SS~ ? >>> >>> Strictly speaking, you are right, but it is common sense that >> cryptographic keys should have maximum entropy, i.e., they >>> should be selected uniformly at random from bit string of that length= =2E >> Consequently, virtually all cryptographic papers >>> and text books use key the key length synonymous to its entropy. Thus= , >> I consider this distinction as unnecessary. >>> >>>> >>>> s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I >> think >>>> that s9.4 should reflect that (lest it confuses, or am I confused >> having >>>> missed an OBJECT somewhere?) >>> >>> Here I definitely need help, as I have no knowledge about MIBs. >> Actually, I copied that section from RFC 3411. Please >>> give advise what to write here or if this section is needed at all. >>> >>> >>>> The names used for the four protocols are not consistent within the >>>> document. Following RFC3414, I think that including Auth is >> correct. >>>> >>> oops, this escaped my attention. >>> >>>> Updates to this registry requires a Standards Track document which >> this >>>> is not. >>> >>> Wright. If the chairs agree, I'll change the track. >>> >>>> >>>> MIB Module copyright is 2004 >>> >>> opps again. Copy and paste error. >>> >>>> >>>> Does this document update RFC3414? It adds to the registry that >> that >>>> RFC created which some ADs say is NOT an update, some ADs say it IS >> an >>>> update; I think that we need guidance here (the update by RFC5590 of= >>>> RFC3414 is a whole different ball game). >>> >>> I will wait for the guidance here. >>> >>> -- >>> Johannes >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 >=20 --HI3AMen0wDnJr9NWiQpaT7XHpWDTrUsnp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTRC1kACgkQ8AA1q7Z/VrK7eQCeL1ISQSq7GQP1lOIPTAf+Jpto s0gAn3gq8/jZQCfdOzGVCCiwr5o4JwL7 =RdOm -----END PGP SIGNATURE----- --HI3AMen0wDnJr9NWiQpaT7XHpWDTrUsnp-- From nobody Fri Feb 6 13:43:05 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255D11A8880; Fri, 6 Feb 2015 13:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjyHppMlM5ZO; Fri, 6 Feb 2015 13:42:57 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E771A8876; Fri, 6 Feb 2015 13:42:00 -0800 (PST) Received: by iecat20 with SMTP id at20so4609332iec.3; Fri, 06 Feb 2015 13:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=D0kOlwOdc/JtP7LVcSdyKa90I10Z9P12vYgVhu9cQtQ=; b=YKptMTJy0TghmLU6+xYUQ5YLBhcbrU4jd3ONWwTeBBUVM5tdKGnyUHEroxCnmRSOQd UEnwcsU0sxMw0qldRUIOsHydl1HhhWWVJDz1zqL7n3l6JPi/dqGHSA9tZDXNBnq5+pRG 58MiKNWhk57wxvK4hrYGXirE2wbsc2JLqu9zRtx0UlkY/ycTPJDXz9JO8loXrDheQaCa 8My1Ur22H9z9ltWpUSlUsjE6sAhO+o5JYCzfKAz0N82ZCUHY1YD/3MF0I/j0WQEFaNBl hJFt/jWu/gb2jr37UThrsSQPQrNdMbx52QunKY+8peQhMMyQAIa4Jxcn2rEMuI1lpiJ/ vRsA== X-Received: by 10.50.119.9 with SMTP id kq9mr4443463igb.36.1423258919426; Fri, 06 Feb 2015 13:41:59 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-73-98.tor.primus.ca. [173.206.73.98]) by mx.google.com with ESMTPSA id qs3sm1118326igb.8.2015.02.06.13.41.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Feb 2015 13:41:59 -0800 (PST) Message-ID: <54D5351B.3020601@gmail.com> Date: Fri, 06 Feb 2015 16:41:47 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 21:42:59 -0000 draft-perrault-behave-natv2-mib-01 is almost ready. I considered in the past and rejected in my own mind a per-subscriber control on whether statistics are enabled or not for that subscriber. I rejected it thinking that the impact on processor consumption would be minimal, after the processor looked up the subscriber data in the first place. I've changed my mind for two reasons: first, that I probably made too many assumptions about implementation, and secondly, because the impact on storage requirements for per-subscriber statistics would be potentially huge if such a control were available. I therefore propose the following: 1) In the description of the CGN application scenario (Section 3.4 of draft-perrault-behave-natv2-mib-00), add the following sentence: "An implementation MAY limit the number of subscribers for which collection of statistics is enabled at any one time." 2) Add the following object to natv2SubscriberTable: natv2SubscriberCountersEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If true(1), accumulation of statistics in the counters for this subscriber is enabled and the current values of the counters can be presented to the manager. If false(1) (default), accumulation of statistics in the counters for this subscriber is disabled and the values presented to the manager MUST be zero regardless of their actual value. Whenever the value of this object changes, natv2SubscriberDiscontinuityTime MUST be updated to the time of change." ::= { natv2SubscriberEntry xx } Comments? Tom Taylor From nobody Sat Feb 7 06:26:22 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F871A7026 for ; Sat, 7 Feb 2015 06:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqz0imalkExR for ; Sat, 7 Feb 2015 06:24:59 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5C51A1AB9 for ; Sat, 7 Feb 2015 06:24:59 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-09v.sys.comcast.net with comcast id pSQb1p0062EPM3101SQyuF; Sat, 07 Feb 2015 14:24:58 +0000 Received: from JV6RVH1 ([67.189.237.137]) by resomta-ch2-07v.sys.comcast.net with comcast id pSQx1p00S2yZEBF01SQyLY; Sat, 07 Feb 2015 14:24:58 +0000 From: "ietfdbh" To: "'Tom Taylor'" , , References: <54D5351B.3020601@gmail.com> In-Reply-To: <54D5351B.3020601@gmail.com> Date: Sat, 7 Feb 2015 09:24:56 -0500 Message-ID: <011101d042e1$d90d80c0$8b288240$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHiE4rbppInpmPKEKd+xR7X7Tm7U5zBhlSA Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1423319098; bh=2XjQk0pUBQSEIgrQvmop+QflYz77c+SUf6Pz4DgJZ9E=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=EXNu6up5wdSUpw7avm++H8ptEdSxRhCM42kqBFX7ypRfeLCX3OrbEMavje659qaaX neoNMFXDkNgo6w2KDnZG4FB5oMOlMs8+xuU0GNRtPW1Xlc31pr+q6Fulwy25TEQMzH EtwFOqnH01IpfdXhWD6smawg/9NbP8XgEI9eTSUR8zKl1oc/c90HyOOW6PqbxfNbdS HzvCosdGu/mdhPRL0rDX1juQwcGGnB4EEpWOfELTdRD2XenDImONo6mXfGbr3gYLIB 7FqBWiUl25EPHsU7vl8i8hx4BrilyYHOH5wM7AVvvDLpHrvYRCjgRbbMTlTb05Y6XR 8v4kuAg9LuvLg== Archived-At: Subject: Re: [OPSAWG] [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 14:25:02 -0000 Hi, I think this is a bad idea. 1) I used to work at implementing a manager-side application for network management. I am concerned that dynamic enable/disable statistics gathering for this one MIB module could affect a lot of processing on the manager side. Managers already need to do a lot of work just to determine what MIB modules are supported by a device, and then to determine whether the device supports the MIB module in a compliant manner, or is missing some objects from the implementation, and whether the data reported is reliable. Adding a dynamic enable/disable collection at the subscriber level would seem to introduce a great deal of additional complexity for the manager, and more importantly, for the operator trying to diagnose a network problem. What impact would this on-off discontinuity have on the multiple manager scenario. What happens if one manager is monitoring a subscriber's stats for a period of time, and another manager goes in a mucks about with the continuity of collection? SNMP's design of counters - read, then read again and consider the delta, rather than zeroing counters constantly - is done to support the (very common) multiple manager scenario. The counters are consistently available, which is useful for historical trending, etc. The dynamic enable/disable of collection would seem to defeat that important SNMP design choice, and make interpretation of the discontinuous values over time more difficult and less useful. So I think there needs to be considerate discussion of the operational impact of such a switch in this MIB. 3) Do we have feedback from implementers discussing the actual or estimated implementation resources required to support subscriber stats, to justify needing such a switch? If device implementers think this really demands too many resources to support, maybe the subscriber stats should be removed from this MIB module and moved to a separate MIB module that is optional to implement, and then support of subscriber stats can be a question to be resolved between vendors and their customers. I would like to know that such a switch really is justified before adding such complexity. 4) SNMP SETs are not supported very widely, and with the approval and promotion of NETCONF as the IETF standard for configuration, I expect fewer operators will allow SETs even if supported by the agent implementation. Do we really need to standardize a read-write object to make it consistent across vendors, when many deployments may not support the SET capability? 5) All of which leads me to ask - Are the subscriber stats REALLY IMPORTANT to have? Here are some principles of MIB design to keep in mind (from RFC4188 and others): 1. Start with a small set of essential objects and add only as further objects are needed. 2. Require that objects be essential for either fault or configuration management. 3. Consider evidence of current use and/or utility. 4. Limit the total number of objects. 5. Exclude objects that are simply derivable from others in this or other MIB modules. 6. Avoid causing critical sections to be heavily instrumented. The guideline that was followed is one counter per critical section per layer. If per-subscriber stats can be enabled/disabled, does the NATv2 MIB meet these principles? Are these stats **essential** for fault management? If operators think they really are not essential enough to keep them enabled at all times, do we really NEED subscriber stats in the MIB module? If we do NEED them for fault management, what impact does turning them off have on fault management? Are non-standard per-subscriber stats currently being used for fault management? Do operators currently collect and utilize per-subscriber stats through the available non-standard interfaces of NAT devices? What do they do with these stats, so we can understand the design requirements to support these current use cases? Is standardizing these stats in the MIB really important to operators for apples-to-apples comparison across devices from multiple vendors? 6) Another principle about good agent implementation is "never mislead the operator". It was a common problem that early SNMP agent implementations reported zero values, when objects were actually not implemented. This was misleading to operators, causing delays in resolving faults, and wasting operators' time at critical moments. This proposed text certainly fails that principle: ". If false(1) > (default), accumulation of statistics in the counters for > this subscriber is disabled and the values presented to the > manager MUST be zero regardless of their actual value." If a counter is disabled, then it would be more appropriate to not report a value, and to return an error/exception instead. -- I would like to see operator feedback on whether subscriber stats are essential to have in a standard MIB, and whether enabling/disabling those stats would be problematic for operations and management. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Behave [mailto:behave-bounces@ietf.org] On Behalf Of Tom Taylor > Sent: Friday, February 06, 2015 4:42 PM > To: behave@ietf.org; opsawg@ietf.org > Cc: Tina TSOU > Subject: [BEHAVE] NATV2-MIB: Proposed additional read-write control on > per-subscriber statistics > > draft-perrault-behave-natv2-mib-01 is almost ready. > > I considered in the past and rejected in my own mind a per-subscriber > control on whether statistics are enabled or not for that subscriber. I > rejected it thinking that the impact on processor consumption would be > minimal, after the processor looked up the subscriber data in the first > place. I've changed my mind for two reasons: first, that I probably made > too many assumptions about implementation, and secondly, because the > impact on storage requirements for per-subscriber statistics would be > potentially huge if such a control were available. > > I therefore propose the following: > > 1) In the description of the CGN application scenario (Section 3.4 of > draft-perrault-behave-natv2-mib-00), add the following sentence: > > "An implementation MAY limit the number of subscribers for which > collection of statistics is enabled at any one time." > > 2) Add the following object to natv2SubscriberTable: > > natv2SubscriberCountersEnabled OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "If true(1), accumulation of statistics in the counters for > this subscriber is enabled and the current values of the > counters can be presented to the manager. If false(1) > (default), accumulation of statistics in the counters for > this subscriber is disabled and the values presented to the > manager MUST be zero regardless of their actual value. > Whenever the value of this object changes, > natv2SubscriberDiscontinuityTime MUST be updated to the time > of change." > ::= { natv2SubscriberEntry xx } > > Comments? > > Tom Taylor > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From nobody Sat Feb 7 10:21:31 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F731A6F3B; Sat, 7 Feb 2015 10:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3SdypozgzGf; Sat, 7 Feb 2015 10:21:26 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 531DD1A6F38; Sat, 7 Feb 2015 10:21:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=a/ehGZMNKKNztf0+rlF+yQpMYikXieacR3KVvyKZI8m0H8WyWggZE9P7gRHSdYHl; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.46] (helo=elwamui-royal.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YKA0S-0002Sr-NJ; Sat, 07 Feb 2015 13:21:24 -0500 Received: from 76.254.51.90 by webmail.earthlink.net with HTTP; Sat, 7 Feb 2015 13:21:24 -0500 Message-ID: <21435188.1423333284432.JavaMail.root@elwamui-royal.atl.sa.earthlink.net> Date: Sat, 7 Feb 2015 10:21:24 -0800 (GMT-08:00) From: Randy Presuhn To: ietfdbh , 'Tom Taylor' , behave@ietf.org, opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537b7343701542303123d6069e6d0a6bac0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.46 Archived-At: Subject: Re: [OPSAWG] [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 18:21:28 -0000 Hi - >From: ietfdbh >Sent: Feb 7, 2015 6:24 AM >To: 'Tom Taylor' , behave@ietf.org, opsawg@ietf.org >Subject: Re: [OPSAWG] [BEHAVE] NATV2-MIB: Proposed additional read-write control on per-subscriber statistics ... >What impact would this on-off discontinuity have on the multiple manager >scenario. What happens if one manager is monitoring a subscriber's stats for >a period of time, and another manager goes in a mucks about with the >continuity of collection? > >SNMP's design of counters - read, then read again and consider the delta, >rather than zeroing counters constantly - is done to support the (very >common) multiple manager scenario. The counters are consistently available, >which is useful for historical trending, etc. The dynamic enable/disable of >collection would seem to defeat that important SNMP design choice, and make >interpretation of the discontinuous values over time more difficult and less >useful. > >So I think there needs to be considerate discussion of the operational >impact of such a switch in this MIB. I think this specific concern could be easily addressed by a read-only object in the table which reports the sysUptime of the most recent change to that row's switch setting or RowStatus. Randy From nobody Wed Feb 11 14:42:31 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA51A1A10 for ; Wed, 11 Feb 2015 14:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWVdN_g_CG83 for ; Wed, 11 Feb 2015 14:42:26 -0800 (PST) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 608701A00F9 for ; Wed, 11 Feb 2015 14:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1423694545; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=d9CdRG2JU7aTeb16Wj7thzZ6niqLaqM8IlhfJlI7KvI=; b=Gj3+Uv+7XlsSIzN2wl4DdMlXz7UVOmZg3xQh9KURuwTK+ab75xX4uTyJIPZ9EK/EKeFFsdkdvqshCRMki9iFWXkdOyo0i1O0hWQppGbKMKT2vOA25Tv6QatfSQzS53vxlyYmU72ehiEGJPmIlKaD+RaKiH+Rqa6xcjnpj/4iyXc= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R661e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=r46d02008; MF=dacheng.zdc@alibaba-inc.com; PH=DS; RN=1; RT=1; SR=0; Received: from 172.16.9.161(mailfrom:dacheng.zdc@alibaba-inc.com ip:4.28.11.130) by smtp.aliyun-inc.com(127.0.0.1); Thu, 12 Feb 2015 06:42:23 +0800 User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Thu, 12 Feb 2015 06:42:18 +0800 From: "Dacheng Zhang" To: Message-ID: Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3506510543_21866230" Archived-At: Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2015 22:42:28 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3506510543_21866230 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Just read the document by accident and support to move it forward. Cheers Dacheng --B_3506510543_21866230 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Just read the document by accide= nt and support to move it forward. 

Cheers

Dacheng

--B_3506510543_21866230-- From nobody Thu Feb 12 10:12:30 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2A1A1B24; Thu, 12 Feb 2015 10:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrIMaWSuXzED; Thu, 12 Feb 2015 10:12:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id A5BC21A1B0B; Thu, 12 Feb 2015 10:12:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 217EE187E3B; Thu, 12 Feb 2015 10:11:27 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150212181127.217EE187E3B@rfc-editor.org> Date: Thu, 12 Feb 2015 10:11:27 -0800 (PST) Archived-At: Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 7448 on MIB Transfer from the IETF to the IEEE 802.3 WG X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 18:12:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7448 Title: MIB Transfer from the IETF to the IEEE 802.3 WG Author: T. Taylor, Ed., D. Romascanu Status: Informational Stream: IETF Date: February 2015 Mailbox: tom.taylor.stds@gmail.com, dromasca@avaya.com Pages: 7 Characters: 12501 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-mibs-to-ieee80231-01.txt URL: https://www.rfc-editor.org/info/rfc7448 This document records the transfer of responsibility for the Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group (WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Feb 13 09:23:30 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABDD1A8761; Fri, 13 Feb 2015 09:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.622 X-Spam-Level: ** X-Spam-Status: No, score=2.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qaoksSko2VU; Fri, 13 Feb 2015 09:23:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA201A0162; Fri, 13 Feb 2015 09:23:18 -0800 (PST) Received: from [192.168.2.100] ([79.246.51.108]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M3d9B-1XW0O20QQD-00rHSb; Fri, 13 Feb 2015 18:23:15 +0100 Message-ID: <54DE32FF.5030504@gmx.net> Date: Fri, 13 Feb 2015 18:23:11 +0100 From: "B.-C. Boesch" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jerome Athias , sacm@ietf.org, saag@ietf.org, ietf@ietf.org, OPSAWG@ietf.org References: <54BB6D67.6010509@gmx.net> <23D534A9-90E7-45C0-AE78-419617965D15@comcast.net> <54CFCC5F.6080709@gmx.net> <54D12183.2090105@gmx.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040006060109020703050002" X-Provags-ID: V03:K0:axO4E17ajvDU1oagUwCaFzpMyMr+mQrEWbN7PSE28lnqRF2iWPs MOeHXgchTlbKCLhK4yGQ55flks72ZZd8m6ylbmqrEPFf6U9/N3UL8r/bbogVarLoJ81Yr5t RfpaGQ4DQUovy85f3X6D62Bxs9gCvI2Z62aj+bDDqX6SQ83dTWqhw8QsxaXcpJnn4GPk9Tu o5XhXsctsgwHiDB2jMYpA== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [OPSAWG] [sacm] Internet Draft: Standardized Parameterization of Intrusion Detection Entities X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:23:22 -0000 This is a multi-part message in MIME format. --------------040006060109020703050002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Jerome, thanks for your feedback and support to align "contact" with "3.10. Contact Class" of RfC 5070 (IODEFv2). I had lots of thoughts about**your recommendation and currently I am not sure if this is the best choice. The IODEFv2 is focussed on exchange and handle of incident information by CSIRT humans (maybe with systems support and so it should be parsable). So more than one contact could be helpful to handle the incident. Also it must be flexible to use it for any kind of contact. IDMEF (RfC 4765) is focused on signalling of events / incidents within an IDS or its user interface. The IDPEF as Internet Draft is intended to parametrize the Analyzer of an IDS (communication between Manager and Manager or Analyzer). The information handler use the information which is presented to him by the format. Focused on the contact class for the field service and the technical contact there will be a single point of contact. The contact node of IDPEF provides multiple contact channels for the field service or a second level service / technical administration where other information like postal address or contact name is located in upper nodes. So This could be the input for IDMEF / IODEF and should predefine to information for this two support contacts of an entity. And there is always one group exclusive responsible for this job. IMHO this kind of detailed structured information supports that all information are present. With a machine-machine interaction this could be checked automatically. On the other hand an Analyzer is able to combine or chain these values for IDMEF / IODEF with less efforts, but maybe in any cases not the complete information is needed. I am aware that IDPEF and its structure (especially the contact section) could be change in the next years be new communication methods and channels but I believe that at this point it will be time to update IDPEF to a new version. Did you (or the community) have any example, what information for field services or technical administration could be necessary which is currently not addressed by IDPEF with could be valuable for incident handling? Thanks for the feedback and the start of discussion. Kind regards. B.-C. Boesch Am 03.02.2015 um 22:21 schrieb Jerome Athias: > after partial second review, I would suggest reviewing "contact" to > align it on "3.10. Contact Class" that you can find here > https://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-10 > > > > 2015-02-03 20:29 GMT+01:00 B.-C. Boesch : >> Hi Jerome, >> >> thanks for your feedback and the post to the STIX community. This is very >> useful to me. >> >> Currently I am not familiar with the STIX specifications but I hope that I >> will be become acquainted with it in the next time. At the first view it >> seems that STIX is focused on signalizing and correlation of events like >> IDMEF. My approach is more a parametrization of IDS entities (Analyzers). I >> keep to make some Data model mappings with STIX. I hope that I will be able >> to spend some time on it next weekend to get familiar with STIX. >> >> I am looking forward to a valuable feedback from the STIX community. >> >> kind regards >> >> Bjoern.-C. Boesch >> >> Am 02.02.2015 um 22:40 schrieb Jerome Athias: >> >>> Hi, >>> >>> very interesting idea and document. >>> Congratulations, and thanks! >>> >>> After a first review, I think I would have quite a lot of comments. >>> Unfortunately I would not have time for proper review before this >>> week-end. >>> Meantime, I would think that there is an opportunity to suggest your >>> work as an extension for STIX, and CybOX >>> http://stix.mitre.org/ >>> Are you familiar with these specifications? >>> I would mainly recommend trying some mappings, etc. I'll be able to help >>> >>> I understand the importance for you to obtain feedbacks, so I should >>> introduce your draft into the STIX community >>> >>> http://making-security-measurable.1364806.n2.nabble.com/STIX-Discussion-List-f7579090.html >>> I hope it's ok for you, and I'm pretty sure you could obtain valuable >>> feedback from there (even if this community is not working with the >>> same requirements as IETF) >>> >>> Best regards >>> >>> 2015-02-02 20:13 GMT+01:00 B.-C. Boesch : >>>> Dear David, >>>> >>>> thanks for your hint to the SACM WG. I have also posted it within the >>>> SACM >>>> community for any comments, feedback, suggestions, notations, hints, >>>> recommendations, etc. but haven´t received any response or feedback to >>>> the >>>> Internet Draft so far. I hope this will change and a lively discussion is >>>> going to come up. >>>> >>>> Kind regards >>>> >>>> B.-C. Boesch >>>> >>>> >>>> Am 02.02.2015 um 18:32 schrieb David Harrington: >>>>> I think similar work is being addressed in the sacm wg. >>>>> >>>>> David Harrington >>>>> ietfdbh@comcast.net >>>>> >>>>> >>>>> >>>>> On Jan 18, 2015, at 3:23 AM, B.-C. Boesch wrote: >>>>> >>>>>> Dear Community, >>>>>> >>>>>> Efficiency of Intrusion Detection Systems (IDS) depends on their >>>>>> configuration and coverage of services. The coverage depends on used >>>>>> IDS >>>>>> with currently vendor-specific configurations. In case of usage of >>>>>> multiple >>>>>> systems the operations could become complex. Individual Communication >>>>>> between management interface and the IDS entities results that current >>>>>> multi-vendor IDS architectures do not interact with each other. They >>>>>> are >>>>>> independent coexistent. >>>>>> >>>>>> The Internet Draft defines data formats and exchange procedures to >>>>>> standardize parametrization information exchange into intrusion >>>>>> detection >>>>>> and response systems from a Manager to an Analyzer. >>>>>> >>>>>> The created Intrusion Detection Parametrization Exchange Format (IDPEF) >>>>>> is intended to be a standard data format to parametrize IDS. The >>>>>> development >>>>>> of this open standardized format and the Intrusion Detection Message >>>>>> Exchange Format (IDMEF) will be enable in combination interoperability >>>>>> among >>>>>> commercial, open source, and research systems, allowing users to >>>>>> mix-and-match the deployment of these systems according to their strong >>>>>> and >>>>>> weak points to obtain an optimal IDS implementation. >>>>>> >>>>>> The most obvious place to implement IDPEF is in the data channel >>>>>> between >>>>>> a Manager and an Analyzer of an IDS within this data channel where the >>>>>> Manager sends the configuration parameters to the Analyzers. But there >>>>>> are >>>>>> other places where the IDPEF can be useful: >>>>>> >>>>>> - Combination of specialized IDS like application-IDS with server-IDS, >>>>>> WLAN-IDS and network-IDS to one functional interacting meta-IDS. >>>>>> >>>>>> - Management of different IDS vendors with one central management >>>>>> interface. >>>>>> >>>>>> - Interaction of different IDS by using IDPEF and IDMEF. >>>>>> >>>>>> - Parametrization backups and restore of parametrized IDS entities. >>>>>> >>>>>> - For a communication between a Manager and a Manager in a multi-stage >>>>>> management architecture. >>>>>> >>>>>> I am happy to invite you to give me feedback, suggestions, notations, >>>>>> hints, recommendations, etc. to improve the Internet Draft. The initial >>>>>> version of the Internet Draft could be found at: >>>>>> >>>>>> http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> B.-C. Boesch >>>>>> >>>>>> _______________________________________________ >>>>>> OPSAWG mailing list >>>>>> OPSAWG@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/opsawg >>>> >>>> _______________________________________________ >>>> sacm mailing list >>>> sacm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sacm >> --------------040006060109020703050002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Hi Jerome,

thanks for your feedback and support to align "contact" with "3.10. Contact Class" of RfC 5070 (IODEFv2). I had lots of thoughts about your recommendation and currently I am not sure if this is the best choice. The IODEFv2 is focussed on exchange and handle of incident information by CSIRT humans (maybe with systems support and so it should be parsable). So more than one contact could be helpful to handle the incident. Also it must be flexible to use it for any kind of contact. 

IDMEF (RfC 4765) is focused on signalling of events / incidents within an IDS or its user interface. The IDPEF as Internet Draft is intended to parametrize the Analyzer of an IDS (communication between Manager and Manager or Analyzer). The information handler use the information which is presented to him by the format. 

Focused on the contact class for the field service and the technical contact there will be a single point of contact. The contact node of IDPEF provides multiple contact channels for the field service or a second level service / technical administration where other information like postal address or contact name is located in upper nodes. So This could be the input for IDMEF / IODEF and should predefine to information for this two support contacts of an entity. And there is always one group exclusive responsible for this job. 

IMHO this kind of detailed structured information supports that all information are present. With a machine-machine interaction this could be checked automatically. On the other hand an Analyzer is able to combine or chain these values for IDMEF / IODEF with less efforts, but maybe in any cases not the complete information is needed. 

I am aware that IDPEF and its structure (especially the contact section) could be change in the next years be new communication methods and channels but I believe that at this point it will be time to update IDPEF to a new version. Did you (or the community) have any example, what information for field services or technical administration could be necessary which is currently not addressed by IDPEF with could be valuable for incident handling? 

Thanks for the feedback and the start of discussion. 

Kind regards. 

B.-C. Boesch
Am 03.02.2015 um 22:21 schrieb Jerome Athias:
after partial second review, I would suggest reviewing "contact" to
align it on "3.10. Contact Class" that you can find here
https://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-10



2015-02-03 20:29 GMT+01:00 B.-C. Boesch <bjoernboesch@gmx.net>:

Hi Jerome,

thanks for your feedback and the post to the STIX community. This is very
useful to me.

Currently I am not familiar with the STIX specifications but I hope that I
will be become acquainted with it in the next time. At the first view it
seems that STIX is focused on signalizing and correlation of events like
IDMEF. My approach is more a parametrization of IDS entities (Analyzers). I
keep to make some Data model mappings with STIX. I hope that I will be able
to spend some time on it next weekend to get familiar with STIX.

I am looking forward to a valuable feedback from the STIX community.

kind regards

Bjoern.-C. Boesch

Am 02.02.2015 um 22:40 schrieb Jerome Athias:


Hi,

very interesting idea and document.
Congratulations, and thanks!

After a first review, I think I would have quite a lot of comments.
Unfortunately I would not have time for proper review before this
week-end.
Meantime, I would think that there is an opportunity to suggest your
work as an extension for STIX, and CybOX
http://stix.mitre.org/
Are you familiar with these specifications?
I would mainly recommend trying some mappings, etc. I'll be able to help

I understand the importance for you to obtain feedbacks, so I should
introduce your draft into the STIX community

http://making-security-measurable.1364806.n2.nabble.com/STIX-Discussion-List-f7579090.html
I hope it's ok for you, and I'm pretty sure you could obtain valuable
feedback from there (even if this community is not working with the
same requirements as IETF)

Best regards

2015-02-02 20:13 GMT+01:00 B.-C. Boesch <bjoernboesch@gmx.net>:

Dear David,

thanks for your hint to the SACM WG. I have also posted it within the
SACM
community for any comments, feedback, suggestions, notations, hints,
recommendations, etc. but haven´t  received any response or feedback to
the
Internet Draft so far. I hope this will change and a lively discussion is
going to come up.

Kind regards

B.-C. Boesch


Am 02.02.2015 um 18:32 schrieb David Harrington:

I think similar work is being addressed in the sacm wg.

David Harrington
ietfdbh@comcast.net



On Jan 18, 2015, at 3:23 AM, B.-C. Boesch <bjoernboesch@gmx.net> wrote:


Dear Community,

Efficiency of Intrusion Detection Systems (IDS) depends on their
configuration and coverage of services. The coverage depends on used
IDS
with currently vendor-specific configurations. In case of usage of
multiple
systems the operations could become complex. Individual Communication
between management interface and the IDS entities results that current
multi-vendor IDS architectures do not interact with each other. They
are
independent coexistent.

The Internet Draft defines data formats and exchange procedures to
standardize parametrization information exchange into intrusion
detection
and response systems from a Manager to an Analyzer.

The created Intrusion Detection Parametrization Exchange Format (IDPEF)
is intended to be a standard data format to parametrize IDS. The
development
of this open standardized format and the Intrusion Detection Message
Exchange Format (IDMEF) will be enable in combination interoperability
among
commercial, open source, and research systems, allowing users to
mix-and-match the deployment of these systems according to their strong
and
weak points to obtain an optimal IDS implementation.

The most obvious place to implement IDPEF is in the data channel
between
a Manager and an Analyzer of an IDS within this data channel where the
Manager sends the configuration parameters to the Analyzers. But there
are
other places where the IDPEF can be useful:

- Combination of specialized IDS like application-IDS with server-IDS,
WLAN-IDS and network-IDS to one functional interacting meta-IDS.

- Management of different IDS vendors with one central management
interface.

- Interaction of different IDS by using IDPEF and IDMEF.

- Parametrization backups and restore of parametrized IDS entities.

- For a communication between a Manager and a Manager in a multi-stage
management architecture.

I am happy to invite you to give me feedback, suggestions, notations,
hints, recommendations, etc. to improve the Internet Draft. The initial
version of the Internet Draft could be found at:

http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt

Kind regards,

B.-C. Boesch

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

--------------040006060109020703050002-- From nobody Sat Feb 14 13:27:27 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84A1A0072; Sat, 14 Feb 2015 13:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT-W9RbaYaKS; Sat, 14 Feb 2015 13:27:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B82191A00E6; Sat, 14 Feb 2015 13:27:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214212724.5681.58842.idtracker@ietfa.amsl.com> Date: Sat, 14 Feb 2015 13:27:24 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Telechat update notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 21:27:26 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Sat Feb 14 13:27:32 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8B4621A0161; Sat, 14 Feb 2015 13:27:26 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84A1A0072; Sat, 14 Feb 2015 13:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT-W9RbaYaKS; Sat, 14 Feb 2015 13:27:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B82191A00E6; Sat, 14 Feb 2015 13:27:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214212724.5681.58842.idtracker@ietfa.amsl.com> Date: Sat, 14 Feb 2015 13:27:24 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Telechat update notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 21:27:26 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Sat Feb 14 13:28:21 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25AF1A00E6; Sat, 14 Feb 2015 13:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmYatWTiOH4z; Sat, 14 Feb 2015 13:28:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B661A0072; Sat, 14 Feb 2015 13:28:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214212818.26410.33491.idtracker@ietfa.amsl.com> Date: Sat, 14 Feb 2015 13:28:18 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Telechat update notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 21:28:20 -0000 Telechat date has been changed to 2015-02-19 from 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Sat Feb 14 13:28:28 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F272B1A0145; Sat, 14 Feb 2015 13:28:19 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25AF1A00E6; Sat, 14 Feb 2015 13:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmYatWTiOH4z; Sat, 14 Feb 2015 13:28:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B661A0072; Sat, 14 Feb 2015 13:28:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214212818.26410.33491.idtracker@ietfa.amsl.com> Date: Sat, 14 Feb 2015 13:28:18 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Telechat update notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 21:28:20 -0000 Telechat date has been changed to 2015-02-19 from 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Sun Feb 15 02:48:02 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB5E1A1AB9 for ; Sun, 15 Feb 2015 02:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.49 X-Spam-Level: X-Spam-Status: No, score=-13.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvC5yHN9rpo5 for ; Sun, 15 Feb 2015 02:47:55 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754501A1AAE for ; Sun, 15 Feb 2015 02:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2385; q=dns/txt; s=iport; t=1423997275; x=1425206875; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=QKcHKmSkzQYVsv4kC2/bZ0wbmF0oWJs65+VhdJEzizo=; b=YfYlB1dR+8JUwV2fU8Jm1JkCfTINDd+K5dFJwN4l0dLYPEwvTnpTIdsL Vk1O+LIcVDG8AaqkI7gyPKUpQ8Ss21rSaEUgaH/4Pgijpv41ItGkcGEM/ JY7huni0kr8ZpIWZ/kaIU4UWL4wo6R34TLIzjbi+1CcmH9Qq68H2KCDhk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DsDACAeOBU/xbLJq1bg1hawjEKhSdACgIogSgBAQEBAQF8hAQJAQEEAQEBNRYgCgEQCxQNAxMPCQMCAQIBDwYKJhADAQUCAQEQBwIEhVCCKAMRDckaDYVGAQEBAQEBAQMBAQEBAQEBFwSLDIE9gQaBVwVOB4J2gTQBBJMPhBqBRoZPhjqGBCKCD4FgPTEBgQqBOAEBBQ X-IronPort-AV: E=Sophos;i="5.09,581,1418083200"; d="scan'208";a="350268173" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 15 Feb 2015 10:47:53 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1FAlqW6008802 for ; Sun, 15 Feb 2015 10:47:53 GMT Message-ID: <54E07958.2010102@cisco.com> Date: Sun, 15 Feb 2015 11:47:52 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 CC: opsawg@ietf.org References: <20150212181127.217EE187E3B@rfc-editor.org> In-Reply-To: <20150212181127.217EE187E3B@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] RFC 7448 on MIB Transfer from the IETF to the IEEE 802.3 WG X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 10:47:58 -0000 Thank you Tom and Dan for driving this effort. Regards, Benoit > A new Request for Comments is now available in online RFC libraries. > > > RFC 7448 > > Title: MIB Transfer from the IETF > to the IEEE 802.3 WG > Author: T. Taylor, Ed., > D. Romascanu > Status: Informational > Stream: IETF > Date: February 2015 > Mailbox: tom.taylor.stds@gmail.com, > dromasca@avaya.com > Pages: 7 > Characters: 12501 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-opsawg-mibs-to-ieee80231-01.txt > > URL: https://www.rfc-editor.org/info/rfc7448 > > This document records the transfer of responsibility for the > Ethernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB, > POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB, > ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group > (WG). This document also describes the procedures associated with the > transfer in a similar way to how RFC 4663 records the transfer of the > IETF Bridge MIB work to the IEEE 802.1 WG. > > This document is a product of the Operations and Management Area Working Group Working Group of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > . > From nobody Mon Feb 16 07:23:51 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38E01A8888; Mon, 16 Feb 2015 07:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zprNIMbttW2Q; Mon, 16 Feb 2015 07:23:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EAF1A88B3; Mon, 16 Feb 2015 07:23:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216152337.23677.23380.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 07:23:37 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 15:23:39 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Mon Feb 16 07:23:53 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-capwap-hybridmac.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6B7381A88C6; Mon, 16 Feb 2015 07:23:39 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38E01A8888; Mon, 16 Feb 2015 07:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zprNIMbttW2Q; Mon, 16 Feb 2015 07:23:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EAF1A88B3; Mon, 16 Feb 2015 07:23:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216152337.23677.23380.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 07:23:37 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 15:23:39 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Mon Feb 16 12:06:04 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D171A8899; Mon, 16 Feb 2015 12:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ryfj8YIaoddx; Mon, 16 Feb 2015 12:05:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC981A875E; Mon, 16 Feb 2015 12:05:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216200548.8899.85118.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 12:05:48 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 20:05:52 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Mon Feb 16 12:06:07 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-capwap-hybridmac.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 144F01A875E; Mon, 16 Feb 2015 12:05:51 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D171A8899; Mon, 16 Feb 2015 12:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ryfj8YIaoddx; Mon, 16 Feb 2015 12:05:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC981A875E; Mon, 16 Feb 2015 12:05:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216200548.8899.85118.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 12:05:48 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 20:05:52 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Tue Feb 17 05:54:13 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0291A1B13 for ; Tue, 17 Feb 2015 05:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpwBaO0Pr7S2 for ; Tue, 17 Feb 2015 05:54:07 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185701A1B39 for ; Tue, 17 Feb 2015 05:53:58 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id A5DB91A00AF; Tue, 17 Feb 2015 14:53:45 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Cgm4ZkfXzLFJ; Tue, 17 Feb 2015 14:53:44 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id A69571A00A5; Tue, 17 Feb 2015 14:53:44 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 17 Feb 2015 14:53:53 +0100 Message-ID: <54E347F1.9000901@secunet.com> Date: Tue, 17 Feb 2015 14:53:53 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: t.petch , Warren Kumari References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> <01f001d03bb1$0e9a7c80$4001a8c0@gateway.2wire.net> In-Reply-To: <01f001d03bb1$0e9a7c80$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 13:54:09 -0000 Tom, >>> > > s9.2 >>> > > is it the length of the key that gives it strength or its entropy? >>> > > Is abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 >>> > > really stronger than !qaurk/99SS~ ? >> > >> > Strictly speaking, you are right, but it is common sense that > cryptographic keys should have maximum entropy, i.e., they >> > should be selected uniformly at random from bit string of that length. > Consequently, virtually all cryptographic papers >> > and text books use key the key length synonymous to its entropy. Thus, > I consider this distinction as unnecessary. > > Yes but, consider the audience. Cryptographic material is aimed at > cryptographers who know about entropy without being told, the audience > of this I-D is all sorts, including MIB module specialists whose > knowledge of cryptography is probably less than useless. So I think > 'length' is wrong, 'entropy' is probably too technical (especially if, > like me, Thermodynamics was part of your degree), RFC5310 uses 'size and > quality of the key' which is probably a good compromise. > This section is about the influences of the cryptographic parameters of HMAC on the security. The entropy or quality (I don't like that term) of the key is not a parameter, thus, it is not appropriate to mention is along the size. I suggest the following wording: The security of each HMAC-SHA-2 authentication protocol depends on the parameters used in the corresponding HMAC computation, which are the length of the key (if the key has maximum entropy), the size of the [...] Rational: If the key's entropy is not maximal, the length does not necessarily influence the the security. abcdabcdabcdabcdabcd is not necessarily more secure than abcdabcdabcdabcd. At least, the key length is not a primary parameter in this case. On the other hand, it is best cryptographic practice to choose keys uniformly at random, so that their entropy is maximal. -- Johannes From nobody Tue Feb 17 06:59:16 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2961A8879; Tue, 17 Feb 2015 06:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMbn20zYMbZq; Tue, 17 Feb 2015 06:59:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A41A89F0; Tue, 17 Feb 2015 06:58:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217145819.13409.18445.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 06:58:19 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:59:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP Authors : Johannes Merkle Manfred Lochter Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt Pages : 13 Date : 2015-02-17 Abstract: This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 17 06:59:19 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1F1A8879; Tue, 17 Feb 2015 06:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzgJkwgEzAch; Tue, 17 Feb 2015 06:59:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0E1A89FB; Tue, 17 Feb 2015 06:58:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217145819.13409.67736.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 06:58:19 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:59:13 -0000 A new version (-02) has been submitted for draft-ietf-opsawg-hmac-sha-2-usm-snmp: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Feb 17 06:59:20 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A32CA1A89EF; Tue, 17 Feb 2015 06:59:13 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1F1A8879; Tue, 17 Feb 2015 06:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzgJkwgEzAch; Tue, 17 Feb 2015 06:59:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0E1A89FB; Tue, 17 Feb 2015 06:58:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217145819.13409.67736.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 06:58:19 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 14:59:13 -0000 A new version (-02) has been submitted for draft-ietf-opsawg-hmac-sha-2-usm-snmp: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Feb 17 07:03:49 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4081A8A14 for ; Tue, 17 Feb 2015 07:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKShJGy6Z_Qi for ; Tue, 17 Feb 2015 07:03:46 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D841A8A66 for ; Tue, 17 Feb 2015 07:02:04 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 739601A00B4 for ; Tue, 17 Feb 2015 16:01:53 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kUixmAeFuuK2 for ; Tue, 17 Feb 2015 16:01:48 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 5B6F31A0093 for ; Tue, 17 Feb 2015 16:01:48 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 17 Feb 2015 16:01:57 +0100 Message-ID: <54E357E5.3010304@secunet.com> Date: Tue, 17 Feb 2015 16:01:57 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20150217145819.13409.18445.idtracker@ietfa.amsl.com> In-Reply-To: <20150217145819.13409.18445.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 15:03:48 -0000 I have updated the draft according to Toms comments and the Text suggested by Juergen for Section 9.4. The intended Status is now standard track as required by the policy of the IANA registry. Johannes internet-drafts@ietf.org schrieb am 17.02.2015 um 15:58: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. > > Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP > Authors : Johannes Merkle > Manfred Lochter > Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-02.txt > Pages : 13 > Date : 2015-02-17 > > Abstract: > This memo specifies new HMAC-SHA-2 authentication protocols for the > User-based Security Model (USM) for SNMPv3 defined in RFC 3414. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > -- Mit freundlichen Grüßen, Dr. Johannes Merkle Principal Division Innere Sicherheit secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From nobody Tue Feb 17 10:22:20 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D211A8F44 for ; Tue, 17 Feb 2015 10:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPHL6rBfAU2k for ; Tue, 17 Feb 2015 10:22:16 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E538E1A8F40 for ; Tue, 17 Feb 2015 10:22:15 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.87.18; Tue, 17 Feb 2015 18:21:57 +0000 Message-ID: <025101d04ade$5cbe12a0$4001a8c0@gateway.2wire.net> From: t.petch To: Johannes Merkle , Warren Kumari References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> <01f001d03bb1$0e9a7c80$4001a8c0@gateway.2wire.net> <54E347F1.9000901@secunet.com> Date: Tue, 17 Feb 2015 18:12:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB3PR05CA0031.eurprd05.prod.outlook.com (25.160.41.159) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) Authentication-Results: secunet.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AMXPR07MB055; X-Forefront-PRVS: 0490BBA1F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(76176999)(81686999)(40100003)(230783001)(50986999)(14496001)(122386002)(44736004)(50226001)(19580395003)(84392001)(77096005)(19580405001)(46102003)(62966003)(87976001)(77156002)(61296003)(42186005)(93886004)(92566002)(62236002)(44716002)(116806002)(66066001)(47776003)(33646002)(23746002)(86362001)(50466002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2015 18:21:57.1379 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 18:22:18 -0000 ----- Original Message ----- From: "Johannes Merkle" To: "t.petch" ; "Warren Kumari" Cc: ; "Scott Bradner" Sent: Tuesday, February 17, 2015 1:53 PM > Tom, > > >>> > > s9.2 > >>> > > is it the length of the key that gives it strength or its entropy? > >>> > > Is abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > >>> > > really stronger than !qaurk/99SS~ ? > >> > > >> > Strictly speaking, you are right, but it is common sense that > > cryptographic keys should have maximum entropy, i.e., they > >> > should be selected uniformly at random from bit string of that length. > > Consequently, virtually all cryptographic papers > >> > and text books use key the key length synonymous to its entropy. Thus, > > I consider this distinction as unnecessary. > > > > Yes but, consider the audience. Cryptographic material is aimed at > > cryptographers who know about entropy without being told, the audience > > of this I-D is all sorts, including MIB module specialists whose > > knowledge of cryptography is probably less than useless. So I think > > 'length' is wrong, 'entropy' is probably too technical (especially if, > > like me, Thermodynamics was part of your degree), RFC5310 uses 'size and > > quality of the key' which is probably a good compromise. > > > > This section is about the influences of the cryptographic parameters of HMAC on the security. > The entropy or quality (I don't like that term) of the key is not a parameter, thus, it is not appropriate to mention is > along the size. I suggest the following wording: > > The security of each HMAC-SHA-2 authentication protocol depends on the parameters > used in the corresponding HMAC computation, which are the length of the key > (if the key has maximum entropy), the size of the [...] OK, Tom Petch > Rational: If the key's entropy is not maximal, the length does not necessarily influence the the security. > abcdabcdabcdabcdabcd is not necessarily more secure than abcdabcdabcdabcd. At least, the key length is not a primary > parameter in this case. On the other hand, it is best cryptographic practice to choose keys uniformly at random, so that > their entropy is maximal. > > -- > Johannes From nobody Tue Feb 17 10:51:24 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DB81A873D; Tue, 17 Feb 2015 10:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMT6CVYqGsEF; Tue, 17 Feb 2015 10:51:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E551A9085; Tue, 17 Feb 2015 10:50:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217185059.5608.1695.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 10:50:59 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:51:20 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Tue Feb 17 10:51:26 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-capwap-hybridmac.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7017A1A9081; Tue, 17 Feb 2015 10:51:20 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DB81A873D; Tue, 17 Feb 2015 10:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMT6CVYqGsEF; Tue, 17 Feb 2015 10:51:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E551A9085; Tue, 17 Feb 2015 10:50:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217185059.5608.1695.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 10:50:59 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:51:20 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Tue Feb 17 11:45:58 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FE11A1B2F; Tue, 17 Feb 2015 11:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBfKZ72s7ShC; Tue, 17 Feb 2015 11:45:53 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB081A0010; Tue, 17 Feb 2015 11:45:53 -0800 (PST) Received: by iecar1 with SMTP id ar1so43590391iec.0; Tue, 17 Feb 2015 11:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=iQBfKw0O1ixvzLer98vsr/03SEvOsrj53HRoGRfcF3Q=; b=Pjds79FwzyLnRbouSi5AOsGvEJwjKFoe0eP0CQLLlDVIGD3cO2hy9gNSLlHncefQg/ 1eDQuqC0hh0rfaV0iLDfSmXjyo8Ad6vcY4Vo4XDaiyCuPSlrCzDYfY0d0hdy0db+DHkY Uks87leLT0qWzR8fnyH3cj1BwluAes67+BLuwfRP09M4wwfGGKdvZmdS4J/4kh2x17l6 KTalnJY/uKM+ee14pe397xagNlfTnKPvmrycASibduouxH63AqCB/+MNp4Nzup4NSlA7 OVEn0UZpFbH3vOFXROIs/ono1WYlQAhvfN7VAqksMrVE1o6d1S0fDqjwukO+qwGgZD2p ZS7w== X-Received: by 10.107.149.212 with SMTP id x203mr11210471iod.12.1424202352684; Tue, 17 Feb 2015 11:45:52 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-36-51.tor.primus.ca. [173.206.36.51]) by mx.google.com with ESMTPSA id w3sm10716424igz.1.2015.02.17.11.45.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 11:45:52 -0800 (PST) Message-ID: <54E39A6E.2040507@gmail.com> Date: Tue, 17 Feb 2015 14:45:50 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "opsawg@ietf.org" , "behave@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Spencer Dawkins , "Fuyu \(Eleven\)" Subject: [OPSAWG] Submission of draft-perrault-behave-natv2-mib-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 19:45:58 -0000 I have finished work on draft-perrault-behave-natv2-mib-01 at last. I will follow up with a series of messages proposing parts of the document for review over the next week or so. In the meantime, I'd better learn how to use lint to check the MIB module itself. Changes from the -00 version: ============================ 1. Filled out the Operations and Management Considerations section and updated the Security Considerations section. 2. Renamed: natv2NextProtocolxxx to simply natv2Protocolxxx. 3. Added a few items of terminology to Section 2: "upper layer protocol", "trigger", "report", and "address realm". 4. Added text to the definition of the statistic "Other resource failure drops": "The most likely case would be packets where the upper layer protocol is not one supported by the NAT instance." Dropped this statistic from other levels, reporting it only at the NAT instance level. I notice that I failed to follow through in the Conformance section, so that has to be fixed. 5. Added natv2PortMapExternalPool to the port map table. 6. Renamed: natv2PoolPortMin -> natv2PoolMinimumPort, and similarly for maximum. 7. Added RFCs 2460 and 3489 as references. 3489 was supposed to be informative, but I seem to have put it in the wrong place. That has to be fixed. Tom Taylor From nobody Tue Feb 17 12:15:57 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2E1A1B21 for ; Tue, 17 Feb 2015 12:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hf393YmDdeW for ; Tue, 17 Feb 2015 12:15:53 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF02D1A044F for ; Tue, 17 Feb 2015 12:15:52 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id l18so38372584wgh.8 for ; Tue, 17 Feb 2015 12:15:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QgLpKZ8lPZpKyutUO4M5PNdgjIJOfkA0/1lm0Sf/3uo=; b=Mx+PjXkX5JX4aTl1Bla4H3MXhvKpaxumHm1rqap6qacfJtK3rRPG7+RpXkiR66k4jX VwR6NyEFsgYq7Pup/QrVUx1bb5uh14mQp7bSAbxhUvo/4YbxP4cpnVWSZcYGeEyPEHWx dOjmK5ntNcVgex709O5YUpxk9r1bb2Bos1iaaeQ1puSD1WrjQvlj2m2VtW0gBVXLRxOD +utj86IPZA8wN/bAqFCePPKNdcIWi69HqjPiIKguFV0wqWKwgDZI9g+t4Z3UieuPLQ2g m3e9mMea8SOQ9BbGPJ1osvtcz6gKYPYMDxaYguAmaGa5fxQYOvk/8CUWNuzWFctDosLF t4Fg== X-Gm-Message-State: ALoCoQk7FCeRG2AR69iuwOGFn6Mj5FZFgG4+03zOd23gjt7r4xXADheunA1K/phadSolaLJVSZgy MIME-Version: 1.0 X-Received: by 10.180.102.69 with SMTP id fm5mr59752934wib.61.1424204151353; Tue, 17 Feb 2015 12:15:51 -0800 (PST) Received: by 10.194.158.229 with HTTP; Tue, 17 Feb 2015 12:15:51 -0800 (PST) In-Reply-To: <013001d03c76$a5da50a0$4001a8c0@gateway.2wire.net> References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> <013001d03c76$a5da50a0$4001a8c0@gateway.2wire.net> Date: Tue, 17 Feb 2015 15:15:51 -0500 Message-ID: From: Warren Kumari To: "t.petch" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 20:15:54 -0000 Apologies for the delay - Scott and I were planning on meeting in Singapore to discuss a bunch of OpsAWG stuff, but the scheduling didn't work out (we were there for different meetings and he arrived just before I left...) Anyway, yup, Standards Track (which you've already done, this just closes the loop...) On Fri, Jan 30, 2015 at 5:22 AM, t.petch wrote: > Warren > > One of the points I raise below calls for input from the WG Chairs. > > The registry that is being updated > http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh > tml#snmp-number-spaces-5 > requires Standards Track for updating. The current I-D is > Informational. This will hit a brick wall when it reaches IANA (I-d > Advancement Not Admissible). > > Johannes wisely said that that he would look for the agreement of the > chairs for this change. > > Do you agree? > > Tom Petch > > ----- Original Message ----- > From: "Johannes Merkle" > To: "t.petch" ; "Warren Kumari" > Cc: ; "Scott Bradner" > Sent: Thursday, January 29, 2015 8:03 AM > >> Tom, >> >> thanks for the thorough review. This really helps improving the > document. >> >> > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a >> > Normative reference. RFC6234 is not Standards Track but that is ok, > it >> > is already in the list of IESG permitted downrefs (does that need >> > calling out at IETF Last Call?) >> >> You are right, but the question is whether I should rather use > references [RFC2104] and [SHA] here. >> >> > >> > s9.1 >> > /apply the use /apply to the use / >> >> Right. >> >> > >> > s9.2 >> > is it the length of the key that gives it strength or its entropy? > Is >> > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 >> > really stronger than >> > !qaurk/99SS~ ? >> >> Strictly speaking, you are right, but it is common sense that > cryptographic keys should have maximum entropy, i.e., they >> should be selected uniformly at random from bit string of that length. > Consequently, virtually all cryptographic papers >> and text books use key the key length synonymous to its entropy. Thus, > I consider this distinction as unnecessary. >> >> > >> > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I > think >> > that s9.4 should reflect that (lest it confuses, or am I confused > having >> > missed an OBJECT somewhere?) >> >> Here I definitely need help, as I have no knowledge about MIBs. > Actually, I copied that section from RFC 3411. Please >> give advise what to write here or if this section is needed at all. >> >> >> > The names used for the four protocols are not consistent within the >> > document. Following RFC3414, I think that including Auth is > correct. >> > >> oops, this escaped my attention. >> >> > Updates to this registry requires a Standards Track document which > this >> > is not. >> >> Wright. If the chairs agree, I'll change the track. >> >> > >> > MIB Module copyright is 2004 >> >> opps again. Copy and paste error. >> >> > >> > Does this document update RFC3414? It adds to the registry that > that >> > RFC created which some ADs say is NOT an update, some ADs say it IS > an >> > update; I think that we need guidance here (the update by RFC5590 of >> > RFC3414 is a whole different ball game). >> >> I will wait for the guidance here. >> >> -- >> Johannes > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 17 12:57:06 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A21A876C; Tue, 17 Feb 2015 12:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCQp74IOzW_j; Tue, 17 Feb 2015 12:57:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E851A86F3; Tue, 17 Feb 2015 12:57:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217205700.5559.49278.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 12:57:00 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 20:57:02 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of this draft, but of course a number of comments about Section 3.10 on Transport protocols: - Req-ID: 10.001: Not sure if this is really a requirement for a transport protocol. I would read this as a requirement for the implementation of a transport protocol. - Req-ID: 10.002 says Description: Diverse applications need a reliable transport of messages. The reliability might be achieved based on a transport protocol such as TCP or can be supported based on message repetition if an acknowledgment is missing. Repitition without any limitation on the number of repititions, etc is not a feature of a reliable transport protocol. I would remove "or can be supported based on message repetition if an acknowledgment is missing". Otherwise the text will blow up when you try to specific what features a reliable transport protocol should have. - Req-ID: 10.003: Multicast is not a feature of the transport layer. From nobody Tue Feb 17 12:57:15 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7136B1A8778; Tue, 17 Feb 2015 12:57:02 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A21A876C; Tue, 17 Feb 2015 12:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCQp74IOzW_j; Tue, 17 Feb 2015 12:57:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E851A86F3; Tue, 17 Feb 2015 12:57:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217205700.5559.49278.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 12:57:00 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 20:57:02 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the publication of this draft, but of course a number of comments about Section 3.10 on Transport protocols: - Req-ID: 10.001: Not sure if this is really a requirement for a transport protocol. I would read this as a requirement for the implementation of a transport protocol. - Req-ID: 10.002 says Description: Diverse applications need a reliable transport of messages. The reliability might be achieved based on a transport protocol such as TCP or can be supported based on message repetition if an acknowledgment is missing. Repitition without any limitation on the number of repititions, etc is not a feature of a reliable transport protocol. I would remove "or can be supported based on message repetition if an acknowledgment is missing". Otherwise the text will blow up when you try to specific what features a reliable transport protocol should have. - Req-ID: 10.003: Multicast is not a feature of the transport layer. From nobody Tue Feb 17 13:17:14 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C31A90B5; Tue, 17 Feb 2015 13:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lurViF-zX7i2; Tue, 17 Feb 2015 13:17:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 069421A90BC; Tue, 17 Feb 2015 13:17:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217211710.20512.95285.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 13:17:10 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-use-cases-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:17:11 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The write-up says something about additional reviews. Does this include reviews by an outside party of the IETF that, for instance, an entity that operates building automation systems? From nobody Tue Feb 17 13:17:16 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 80B3A1A90CB; Tue, 17 Feb 2015 13:17:11 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C31A90B5; Tue, 17 Feb 2015 13:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lurViF-zX7i2; Tue, 17 Feb 2015 13:17:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 069421A90BC; Tue, 17 Feb 2015 13:17:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217211710.20512.95285.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 13:17:10 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-use-cases-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 21:17:11 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The write-up says something about additional reviews. Does this include reviews by an outside party of the IETF that, for instance, an entity that operates building automation systems? From nobody Tue Feb 17 13:48:49 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900E81A1AF0 for ; Tue, 17 Feb 2015 13:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw0CfNQkZyWl for ; Tue, 17 Feb 2015 13:48:45 -0800 (PST) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE531A0113 for ; Tue, 17 Feb 2015 13:48:45 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hi2so37171310wib.0 for ; Tue, 17 Feb 2015 13:48:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UXAcQaPeb5Pn+0/rDqxKFhmLOAPUgrEcYN7ybcEE0qE=; b=JI+7v6QsFpjHeMXL7E+1RiCM1CL21WLg+DKEutQ5f5XnZIBsiv4exwUd8i888chxKy 8zkAO0Mnhc10rruulErWNsTSP+AHXNi0jJw5k3j9ykEfE6q/08FYPIEFEUY/HnCCeG01 tQDM8t9duX5Mz67Ghw6Prt+d2ilppwV7boDN0tuBuIVHfMR3YdMRAotlhKXrA7HBX9uR DtlVlXylnMIZvlcjx/0YhSWyeWOPOhFURKnY6c7vqojNP0zL0NrI5O/l19s8LRip8Nod I9F7PrbMvbyG4IR9Kd1TZ5agNZ3WAGiIOKncX+Pd4HjNOwRFJO6fAKj9W3UQPr6M7ASS Qjmg== X-Gm-Message-State: ALoCoQkjc3vFi+VXS4FDghzwIzFqeWVwtPiO+wWxdgzIPzMZq7QrDTqtZ+h/l+2IU3teO/R5QgpF MIME-Version: 1.0 X-Received: by 10.180.208.20 with SMTP id ma20mr39709419wic.22.1424209722855; Tue, 17 Feb 2015 13:48:42 -0800 (PST) Received: by 10.194.158.229 with HTTP; Tue, 17 Feb 2015 13:48:42 -0800 (PST) In-Reply-To: References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> <013001d03c76$a5da50a0$4001a8c0@gateway.2wire.net> Date: Tue, 17 Feb 2015 16:48:42 -0500 Message-ID: From: Warren Kumari To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 21:48:47 -0000 And I *think* that this addresses the open questions (see Joel's response on the "adding an entry to a registry" question) - please feel free to poke me is I missed any... While having another look before starting the WGLC I found a few more minor nits. 1: Values of constants M (the length of the secret key) and N (the length of the MAC output) used below, are: usmHMAC128SHA224AuthProtocol: M=28, N=16; ..." it might be nice to say that M and N lengths are octets. This should be blindingly obvious from the text in Section 4.1, but doesn't hurt. 2: Your instructions to the RFC Ed contain an off-by-one type error: " ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA -- RFC Ed.: replace cc with actual number assigned by IANA & remove this line" 3: -02 still has a reference to RFC4231, which isn't used in the doc. Other: There are still some downward references to Informational documents, which is a process issue I've not had to deal with recently, and so have forgotten the procedure... I poked around and there are ~80 Standards Track documents that have Normative downrefs to RFC2104, and 3 that reference RFC6234. RFC3967 (Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level) says that the normal last call happens, and we note that there are downward refs. If the AD believes that this is a well known case, they may waive this bit. Entertainingly enough, it also uses RFC2104 as an example of this ("For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well known among cryptographers."). So, I think we can go ahead with this and I'll make a note when we send it over to our AD and he can deal with it. While we *could* note these in the WGLC call, I think it would be cleaner if you could post a new version, and then I think we can kick off the WGLC. W On Tue, Feb 17, 2015 at 3:15 PM, Warren Kumari wrote: > Apologies for the delay - Scott and I were planning on meeting in > Singapore to discuss a bunch of OpsAWG stuff, but the scheduling > didn't work out (we were there for different meetings and he arrived > just before I left...) > > Anyway, yup, Standards Track (which you've already done, this just > closes the loop...) > > > On Fri, Jan 30, 2015 at 5:22 AM, t.petch wrote: >> Warren >> >> One of the points I raise below calls for input from the WG Chairs. >> >> The registry that is being updated >> http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh >> tml#snmp-number-spaces-5 >> requires Standards Track for updating. The current I-D is >> Informational. This will hit a brick wall when it reaches IANA (I-d >> Advancement Not Admissible). >> >> Johannes wisely said that that he would look for the agreement of the >> chairs for this change. >> >> Do you agree? >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Johannes Merkle" >> To: "t.petch" ; "Warren Kumari" >> Cc: ; "Scott Bradner" >> Sent: Thursday, January 29, 2015 8:03 AM >> >>> Tom, >>> >>> thanks for the thorough review. This really helps improving the >> document. >>> >>> > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a >>> > Normative reference. RFC6234 is not Standards Track but that is ok, >> it >>> > is already in the list of IESG permitted downrefs (does that need >>> > calling out at IETF Last Call?) >>> >>> You are right, but the question is whether I should rather use >> references [RFC2104] and [SHA] here. >>> >>> > >>> > s9.1 >>> > /apply the use /apply to the use / >>> >>> Right. >>> >>> > >>> > s9.2 >>> > is it the length of the key that gives it strength or its entropy? >> Is >>> > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 >>> > really stronger than >>> > !qaurk/99SS~ ? >>> >>> Strictly speaking, you are right, but it is common sense that >> cryptographic keys should have maximum entropy, i.e., they >>> should be selected uniformly at random from bit string of that length. >> Consequently, virtually all cryptographic papers >>> and text books use key the key length synonymous to its entropy. Thus, >> I consider this distinction as unnecessary. >>> >>> > >>> > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I >> think >>> > that s9.4 should reflect that (lest it confuses, or am I confused >> having >>> > missed an OBJECT somewhere?) >>> >>> Here I definitely need help, as I have no knowledge about MIBs. >> Actually, I copied that section from RFC 3411. Please >>> give advise what to write here or if this section is needed at all. >>> >>> >>> > The names used for the four protocols are not consistent within the >>> > document. Following RFC3414, I think that including Auth is >> correct. >>> > >>> oops, this escaped my attention. >>> >>> > Updates to this registry requires a Standards Track document which >> this >>> > is not. >>> >>> Wright. If the chairs agree, I'll change the track. >>> >>> > >>> > MIB Module copyright is 2004 >>> >>> opps again. Copy and paste error. >>> >>> > >>> > Does this document update RFC3414? It adds to the registry that >> that >>> > RFC created which some ADs say is NOT an update, some ADs say it IS >> an >>> > update; I think that we need guidance here (the update by RFC5590 of >>> > RFC3414 is a whole different ball game). >>> >>> I will wait for the guidance here. >>> >>> -- >>> Johannes >> > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 17 14:27:32 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD71A88C1 for ; Tue, 17 Feb 2015 14:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrjUngXqySSN for ; Tue, 17 Feb 2015 14:27:22 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10301A88F8 for ; Tue, 17 Feb 2015 14:27:21 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id em10so37197659wid.1 for ; Tue, 17 Feb 2015 14:27:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MXR+dFyfgnoXmLY4SYmnDSBg5xO4YFcYKnUVt3T2gqw=; b=XtPQUUwIw79yXuAXwjuWJjiGeA0Vxrrz5M+EGcDZ2ORQQvO3nrehshBLYC/bezAyKC ekee1Qqt5LXz9VyhgFeXFenWkLd5G1zNcX/mMQF6+DC32GIAGD/2oH4nERVksod+G8+C c3Ec+F7GO5zbXKFf/Os2OL144fCVHnniW/yZczWo636sKodXQt/jf9z/w7R5zQTlb2qL OMweh/8np2+Ou/0F1p1bIyjK9o8D1rwtLPsDc89FB3Z6+Osyp6aOzb+vW/yoTDen9NT3 4MufJO0bKDKF4B+3InuXnbA9m3iuB+2Fzt6t1117WUtEzL8Frvudm26zWn3mKeG1omj5 V2/g== X-Gm-Message-State: ALoCoQnQbmXuKMA9pS+BnxMZ/GsHKUXaunJ85H7AFfGR8wtjYsQ5GaEZo1KoUX2pY9Cz1LcV38fY MIME-Version: 1.0 X-Received: by 10.180.84.100 with SMTP id x4mr51492314wiy.89.1424212040422; Tue, 17 Feb 2015 14:27:20 -0800 (PST) Received: by 10.194.158.229 with HTTP; Tue, 17 Feb 2015 14:27:20 -0800 (PST) In-Reply-To: <20150217211710.20512.95285.idtracker@ietfa.amsl.com> References: <20150217211710.20512.95285.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 17:27:20 -0500 Message-ID: From: Warren Kumari To: Martin Stiemerling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: Re: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-use-cases-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 22:27:24 -0000 On Tue, Feb 17, 2015 at 4:17 PM, Martin Stiemerling wrote: > Martin Stiemerling has entered the following ballot position for > draft-ietf-opsawg-coman-use-cases-04: No Objection [ SNIP ] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The write-up says something about additional reviews. Does this include > reviews by an outside party of the IETF that, for instance, an entity > that operates building automation systems? > Apologies, I (doc shepherd) was unclear - the additional reviews was Thomas and Pascal asking participants in 6TiSCH and 6lo (IPv6 over Networks of Resource-constrained Nodes) to review. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 17 14:27:35 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 53DB71A90EC; Tue, 17 Feb 2015 14:27:26 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389BC1A90E8 for ; Tue, 17 Feb 2015 14:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3pxr0SqIA3x for ; Tue, 17 Feb 2015 14:27:25 -0800 (PST) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B642A1A88D4 for ; Tue, 17 Feb 2015 14:27:21 -0800 (PST) Received: by wesq59 with SMTP id q59so1228458wes.1 for ; Tue, 17 Feb 2015 14:27:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MXR+dFyfgnoXmLY4SYmnDSBg5xO4YFcYKnUVt3T2gqw=; b=R4dAJbsYHomb9Yy17fzcUz5u+Gg6ytuL9vRGtIOKYvJcFi3W/ZndrSvO5iiRDdwZzo wOe7P/pJ/RyRve4qY/+sW49I1/rmy324BSAprOTgMa5hSa0qWc7I3QzsyUHf9+GNk1zQ y9HH6rH3iM8IT8dbHb/N7NgqQeLZHDi5APojXY4wO99f/6i4cXzBVqLC0Of0Ogg/nmIZ XhJ8f26K5iyu8HmP3aq9TWJhGrmAl+7IYek+qWayZ/EXV1wzBnaNNU+wXmI47qEkv2dC UBEfhqG6fcbxhP2euFg1ARhkK0VrrMqvMKBft1LArMCE1XNcuBJSueM3pm/BdIJ0w0d2 lSzw== X-Gm-Message-State: ALoCoQnsAcRpvEmc605TKYq+4MIzzgT6z6SwRX1BtiF8fvefZXgRNRZNZE56FxdhZCxOwER9R7Z/ MIME-Version: 1.0 X-Received: by 10.180.84.100 with SMTP id x4mr51492314wiy.89.1424212040422; Tue, 17 Feb 2015 14:27:20 -0800 (PST) Received: by 10.194.158.229 with HTTP; Tue, 17 Feb 2015 14:27:20 -0800 (PST) In-Reply-To: <20150217211710.20512.95285.idtracker@ietfa.amsl.com> References: <20150217211710.20512.95285.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 17:27:20 -0500 Message-ID: From: Warren Kumari To: Martin Stiemerling Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: Re: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-use-cases-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 22:27:26 -0000 On Tue, Feb 17, 2015 at 4:17 PM, Martin Stiemerling wrote: > Martin Stiemerling has entered the following ballot position for > draft-ietf-opsawg-coman-use-cases-04: No Objection [ SNIP ] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The write-up says something about additional reviews. Does this include > reviews by an outside party of the IETF that, for instance, an entity > that operates building automation systems? > Apologies, I (doc shepherd) was unclear - the additional reviews was Thomas and Pascal asking participants in 6TiSCH and 6lo (IPv6 over Networks of Resource-constrained Nodes) to review. -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 17 19:05:12 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD991A9244; Tue, 17 Feb 2015 19:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q76lprGGJ54X; Tue, 17 Feb 2015 19:05:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FEB1A8937; Tue, 17 Feb 2015 19:05:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218030508.15883.30491.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 19:05:08 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:05:10 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Tue Feb 17 19:05:13 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-capwap-hybridmac.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7F1B41A924C; Tue, 17 Feb 2015 19:05:10 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD991A9244; Tue, 17 Feb 2015 19:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q76lprGGJ54X; Tue, 17 Feb 2015 19:05:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FEB1A8937; Tue, 17 Feb 2015 19:05:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218030508.15883.30491.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 19:05:08 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:05:10 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Tue Feb 17 19:22:50 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A961A9251; Tue, 17 Feb 2015 19:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYPPSiFWjVKk; Tue, 17 Feb 2015 19:22:42 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F631A86DD; Tue, 17 Feb 2015 19:22:42 -0800 (PST) Received: by iecar1 with SMTP id ar1so45969379iec.0; Tue, 17 Feb 2015 19:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=j+BrLrpilMW9XqQFahPi5MTFco1um6INQnOEZ5NgmeE=; b=ln+Dw2f1T+r7is6FVWur8aiBIBJZ/mwEriTMu6E7q9rPuNmOURY8cVgpB51KttyRb6 MBFo3wa434dS0s7CUa8+xCM3pts7hYC+lLhsb9X3h0sjNtcNCcG9WX4/V3meeSTG1usc l+zHNga/9r10JlvM852XOlCTupOsaXJ0wU94OuBfYJLjbh1zBq9lJLefLC4ulHTksxq5 YS8bgxvsZ2xpU1D5zp8KkqSTqIq+AilRIcA0Md3nF66nuOvKb+XTN+B87udyOCRbThLn S+ekPl/P4H8T10BK6sSPb/OvVhID1oPE82RrZ/sFYLaac/QJgjzzYwM9nN76dfxh1IbG j4EQ== X-Received: by 10.50.43.162 with SMTP id x2mr451288igl.46.1424229762058; Tue, 17 Feb 2015 19:22:42 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-36-51.tor.primus.ca. [173.206.36.51]) by mx.google.com with ESMTPSA id s17sm11272179igr.2.2015.02.17.19.22.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 19:22:41 -0800 (PST) Message-ID: <54E40579.8060508@gmail.com> Date: Tue, 17 Feb 2015 22:22:33 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "opsawg@ietf.org" , "behave@ietf.org" , Senthil Sivakumar , Simon Perreault , Tina TSOU , Spencer Dawkins Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "fuyu \(Eleven\)" Subject: [OPSAWG] draft-perrault-behave-natv2-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 03:22:47 -0000 I have submitted another update to the NATV2-MIB draft. This corrects the errors noted in my previous E-mail, and also corrects a number of errors in the MIB module that were revealed by the smilint tool. Subject to the results of your review, this draft should be good to go, except that there is a potential sub-identifier issue with the keys to the address and the port map tables that I have to clear with the MIB experts. Tom Taylor From nobody Wed Feb 18 02:49:41 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C598F1A872E for ; Wed, 18 Feb 2015 02:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIcp40ZlPr8C for ; Wed, 18 Feb 2015 02:49:35 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377531A911E for ; Wed, 18 Feb 2015 02:49:35 -0800 (PST) Received: from pc6 (81.151.167.59) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 10:49:17 +0000 Message-ID: <025001d04b68$4a240160$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari , Johannes Merkle References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com><54B79418.2080709@secunet.com><030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net><01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net><54C9E945.5010808@secunet.com><013001d03c76$a5da50a0$4001a8c0@gateway.2wire.net> Date: Wed, 18 Feb 2015 10:46:42 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0028.eurprd05.prod.outlook.com (25.160.40.38) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) Authentication-Results: kumari.net; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AMXPR07MB055; X-Forefront-PRVS: 04916EA04C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51444003)(52044002)(51914003)(52314003)(51704005)(24454002)(13464003)(81686999)(44716002)(62236002)(47776003)(44736004)(33646002)(122386002)(23676002)(66066001)(50986999)(76176999)(14496001)(92566002)(50226001)(77096005)(15975445007)(19580395003)(19580405001)(84392001)(42186005)(62966003)(77156002)(50466002)(87976001)(93886004)(61296003)(116806002)(40100003)(46102003)(86362001)(230783001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2015 10:49:17.6293 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055 Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 10:49:37 -0000 ----- Original Message ----- From: "Warren Kumari" To: "Johannes Merkle" Cc: ; "Scott Bradner" ; "t.petch" Sent: Tuesday, February 17, 2015 9:48 PM > And I *think* that this addresses the open questions (see Joel's > response on the "adding an entry to a registry" question) - please > feel free to poke me is I missed any... > > While having another look before starting the WGLC I found a few more > minor nits. > > 1: > Values of constants M (the length of the secret key) and N (the length > of the MAC output) used below, are: > usmHMAC128SHA224AuthProtocol: M=28, N=16; > ..." > it might be nice to say that M and N lengths are octets. This should > be blindingly obvious from the text in Section 4.1, but doesn't hurt. > > 2: > Your instructions to the RFC Ed contain an off-by-one type error: > " ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA > -- RFC Ed.: replace cc with actual number assigned by IANA & > remove this line" > 3: > -02 still has a reference to RFC4231, which isn't used in the doc. > > Other: > There are still some downward references to Informational documents, > which is a process issue I've not had to deal with recently, and so > have forgotten the procedure... Warren You go to the website and see if they have already been approved. http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry# (2104 6234 have and the latter has a Normative Reference to FIPS 180-3 which should serve although a strict reading of the web page says not; but then a strict reading of the web page says that Russ Housley should have caused the FIPS document to have been added to the web page which it wasn't). Then it is up to the AD to see if they warrant a mention in IETF Last Call using the information that the Document Shepherd has put in section 15. Tom Petch > I poked around and there are ~80 Standards Track documents that have > Normative downrefs to RFC2104, and 3 that reference RFC6234. > RFC3967 (Clarifying when Standards Track Documents may Refer > Normatively to Documents at a Lower Level) says that the normal last > call happens, and we note that there are downward refs. If the AD > believes that this is a well known case, they may waive this bit. > Entertainingly enough, it also uses RFC2104 as an example of this > ("For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well > known among cryptographers."). > So, I think we can go ahead with this and I'll make a note when we > send it over to our AD and he can deal with it. > > While we *could* note these in the WGLC call, I think it would be > cleaner if you could post a new version, and then I think we can kick > off the WGLC. > > W > > > On Tue, Feb 17, 2015 at 3:15 PM, Warren Kumari wrote: > > Apologies for the delay - Scott and I were planning on meeting in > > Singapore to discuss a bunch of OpsAWG stuff, but the scheduling > > didn't work out (we were there for different meetings and he arrived > > just before I left...) > > > > Anyway, yup, Standards Track (which you've already done, this just > > closes the loop...) > > > > > > On Fri, Jan 30, 2015 at 5:22 AM, t.petch wrote: > >> Warren > >> > >> One of the points I raise below calls for input from the WG Chairs. > >> > >> The registry that is being updated > >> http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh > >> tml#snmp-number-spaces-5 > >> requires Standards Track for updating. The current I-D is > >> Informational. This will hit a brick wall when it reaches IANA (I-d > >> Advancement Not Admissible). > >> > >> Johannes wisely said that that he would look for the agreement of the > >> chairs for this change. > >> > >> Do you agree? > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "Johannes Merkle" > >> To: "t.petch" ; "Warren Kumari" > >> Cc: ; "Scott Bradner" > >> Sent: Thursday, January 29, 2015 8:03 AM > >> > >>> Tom, > >>> > >>> thanks for the thorough review. This really helps improving the > >> document. > >>> > >>> > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a > >>> > Normative reference. RFC6234 is not Standards Track but that is ok, > >> it > >>> > is already in the list of IESG permitted downrefs (does that need > >>> > calling out at IETF Last Call?) > >>> > >>> You are right, but the question is whether I should rather use > >> references [RFC2104] and [SHA] here. > >>> > >>> > > >>> > s9.1 > >>> > /apply the use /apply to the use / > >>> > >>> Right. > >>> > >>> > > >>> > s9.2 > >>> > is it the length of the key that gives it strength or its entropy? > >> Is > >>> > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > >>> > really stronger than > >>> > !qaurk/99SS~ ? > >>> > >>> Strictly speaking, you are right, but it is common sense that > >> cryptographic keys should have maximum entropy, i.e., they > >>> should be selected uniformly at random from bit string of that length. > >> Consequently, virtually all cryptographic papers > >>> and text books use key the key length synonymous to its entropy. Thus, > >> I consider this distinction as unnecessary. > >>> > >>> > > >>> > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I > >> think > >>> > that s9.4 should reflect that (lest it confuses, or am I confused > >> having > >>> > missed an OBJECT somewhere?) > >>> > >>> Here I definitely need help, as I have no knowledge about MIBs. > >> Actually, I copied that section from RFC 3411. Please > >>> give advise what to write here or if this section is needed at all. > >>> > >>> > >>> > The names used for the four protocols are not consistent within the > >>> > document. Following RFC3414, I think that including Auth is > >> correct. > >>> > > >>> oops, this escaped my attention. > >>> > >>> > Updates to this registry requires a Standards Track document which > >> this > >>> > is not. > >>> > >>> Wright. If the chairs agree, I'll change the track. > >>> > >>> > > >>> > MIB Module copyright is 2004 > >>> > >>> opps again. Copy and paste error. > >>> > >>> > > >>> > Does this document update RFC3414? It adds to the registry that > >> that > >>> > RFC created which some ADs say is NOT an update, some ADs say it IS > >> an > >>> > update; I think that we need guidance here (the update by RFC5590 of > >>> > RFC3414 is a whole different ball game). > >>> > >>> I will wait for the guidance here. > >>> > >>> -- > >>> Johannes > >> > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf From nobody Wed Feb 18 03:04:57 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC34E1A911F for ; Wed, 18 Feb 2015 03:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEC8PZY6w-gU for ; Wed, 18 Feb 2015 03:04:53 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF0F1A1A96 for ; Wed, 18 Feb 2015 03:04:52 -0800 (PST) Received: from AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) by AMXPR07MB120.eurprd07.prod.outlook.com (10.242.70.156) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 11:04:33 +0000 Received: from pc6 (81.151.167.59) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 11:04:31 +0000 Message-ID: <026e01d04b6a$6b08cda0$4001a8c0@gateway.2wire.net> From: t.petch To: Warren Kumari , Johannes Merkle References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com><54B79418.2080709@secunet.com><030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net><01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net><54C9E945.5010808@secunet.com><013001d03c76$a5da50a0$4001a8c0@gateway.2wire.net> Date: Wed, 18 Feb 2015 10:54:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR05CA0009.eurprd05.prod.outlook.com (25.160.40.19) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) Authentication-Results: kumari.net; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:AMXPR07MB053; X-Forefront-PRVS: 04916EA04C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(52044002)(51704005)(51444003)(377454003)(24454002)(52314003)(51914003)(42186005)(46102003)(44736004)(61296003)(44716002)(33646002)(50466002)(50226001)(93886004)(23676002)(81686999)(84392001)(50986999)(76176999)(14496001)(86362001)(19580405001)(19580395003)(77096005)(40100003)(122386002)(92566002)(15975445007)(66066001)(77156002)(47776003)(62236002)(62966003)(116806002)(230783001)(87976001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB053; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB053; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2015 11:04:31.8719 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB053 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB120; X-OriginatorOrg: btconnect.com Archived-At: Cc: opsawg@ietf.org, Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 11:04:56 -0000 ----- Original Message ----- From: "Warren Kumari" To: "Johannes Merkle" Cc: ; "Scott Bradner" ; "t.petch" Sent: Tuesday, February 17, 2015 9:48 PM > And I *think* that this addresses the open questions (see Joel's > response on the "adding an entry to a registry" question) - please > feel free to poke me is I missed any... > > While having another look before starting the WGLC I found a few more > minor nits. > > 1: > Values of constants M (the length of the secret key) and N (the length > of the MAC output) used below, are: > usmHMAC128SHA224AuthProtocol: M=28, N=16; > ..." > it might be nice to say that M and N lengths are octets. This should > be blindingly obvious from the text in Section 4.1, but doesn't hurt. > > 2: > Your instructions to the RFC Ed contain an off-by-one type error: > " ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA > -- RFC Ed.: replace cc with actual number assigned by IANA & > remove this line" It's not one off. There is a similar mismatch for 'cc' and 'dd' and 'dd' and 'ff' Tom Petch > 3: > -02 still has a reference to RFC4231, which isn't used in the doc. > > Other: > There are still some downward references to Informational documents, > which is a process issue I've not had to deal with recently, and so > have forgotten the procedure... > I poked around and there are ~80 Standards Track documents that have > Normative downrefs to RFC2104, and 3 that reference RFC6234. > RFC3967 (Clarifying when Standards Track Documents may Refer > Normatively to Documents at a Lower Level) says that the normal last > call happens, and we note that there are downward refs. If the AD > believes that this is a well known case, they may waive this bit. > Entertainingly enough, it also uses RFC2104 as an example of this > ("For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well > known among cryptographers."). > So, I think we can go ahead with this and I'll make a note when we > send it over to our AD and he can deal with it. > > While we *could* note these in the WGLC call, I think it would be > cleaner if you could post a new version, and then I think we can kick > off the WGLC. > > W > > > On Tue, Feb 17, 2015 at 3:15 PM, Warren Kumari wrote: > > Apologies for the delay - Scott and I were planning on meeting in > > Singapore to discuss a bunch of OpsAWG stuff, but the scheduling > > didn't work out (we were there for different meetings and he arrived > > just before I left...) > > > > Anyway, yup, Standards Track (which you've already done, this just > > closes the loop...) > > > > > > On Fri, Jan 30, 2015 at 5:22 AM, t.petch wrote: > >> Warren > >> > >> One of the points I raise below calls for input from the WG Chairs. > >> > >> The registry that is being updated > >> http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh > >> tml#snmp-number-spaces-5 > >> requires Standards Track for updating. The current I-D is > >> Informational. This will hit a brick wall when it reaches IANA (I-d > >> Advancement Not Admissible). > >> > >> Johannes wisely said that that he would look for the agreement of the > >> chairs for this change. > >> > >> Do you agree? > >> > >> Tom Petch > >> > >> ----- Original Message ----- > >> From: "Johannes Merkle" > >> To: "t.petch" ; "Warren Kumari" > >> Cc: ; "Scott Bradner" > >> Sent: Thursday, January 29, 2015 8:03 AM > >> > >>> Tom, > >>> > >>> thanks for the thorough review. This really helps improving the > >> document. > >>> > >>> > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a > >>> > Normative reference. RFC6234 is not Standards Track but that is ok, > >> it > >>> > is already in the list of IESG permitted downrefs (does that need > >>> > calling out at IETF Last Call?) > >>> > >>> You are right, but the question is whether I should rather use > >> references [RFC2104] and [SHA] here. > >>> > >>> > > >>> > s9.1 > >>> > /apply the use /apply to the use / > >>> > >>> Right. > >>> > >>> > > >>> > s9.2 > >>> > is it the length of the key that gives it strength or its entropy? > >> Is > >>> > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 > >>> > really stronger than > >>> > !qaurk/99SS~ ? > >>> > >>> Strictly speaking, you are right, but it is common sense that > >> cryptographic keys should have maximum entropy, i.e., they > >>> should be selected uniformly at random from bit string of that length. > >> Consequently, virtually all cryptographic papers > >>> and text books use key the key length synonymous to its entropy. Thus, > >> I consider this distinction as unnecessary. > >>> > >>> > > >>> > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I > >> think > >>> > that s9.4 should reflect that (lest it confuses, or am I confused > >> having > >>> > missed an OBJECT somewhere?) > >>> > >>> Here I definitely need help, as I have no knowledge about MIBs. > >> Actually, I copied that section from RFC 3411. Please > >>> give advise what to write here or if this section is needed at all. > >>> > >>> > >>> > The names used for the four protocols are not consistent within the > >>> > document. Following RFC3414, I think that including Auth is > >> correct. > >>> > > >>> oops, this escaped my attention. > >>> > >>> > Updates to this registry requires a Standards Track document which > >> this > >>> > is not. > >>> > >>> Wright. If the chairs agree, I'll change the track. > >>> > >>> > > >>> > MIB Module copyright is 2004 > >>> > >>> opps again. Copy and paste error. > >>> > >>> > > >>> > Does this document update RFC3414? It adds to the registry that > >> that > >>> > RFC created which some ADs say is NOT an update, some ADs say it IS > >> an > >>> > update; I think that we need guidance here (the update by RFC5590 of > >>> > RFC3414 is a whole different ball game). > >>> > >>> I will wait for the guidance here. > >>> > >>> -- > >>> Johannes > >> > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf From nobody Wed Feb 18 05:53:56 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104CD1A1A6E; Wed, 18 Feb 2015 05:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dZ5dmwOUFjs; Wed, 18 Feb 2015 05:53:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 976171A8790; Wed, 18 Feb 2015 05:53:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218135352.15606.31349.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 05:53:52 -0800 Archived-At: Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:53:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP Authors : Johannes Merkle Manfred Lochter Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt Pages : 13 Date : 2015-02-18 Abstract: This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 18 05:54:09 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22AA1A87E7; Wed, 18 Feb 2015 05:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TdCwuOj3_ii; Wed, 18 Feb 2015 05:53:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C28FE1A87B2; Wed, 18 Feb 2015 05:53:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218135352.15606.91354.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 05:53:52 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:53:55 -0000 A new version (-03) has been submitted for draft-ietf-opsawg-hmac-sha-2-usm-snmp: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Feb 18 05:54:11 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CB8091A87EB; Wed, 18 Feb 2015 05:53:55 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-hmac-sha-2-usm-snmp.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22AA1A87E7; Wed, 18 Feb 2015 05:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TdCwuOj3_ii; Wed, 18 Feb 2015 05:53:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C28FE1A87B2; Wed, 18 Feb 2015 05:53:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218135352.15606.91354.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 05:53:52 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 13:53:55 -0000 A new version (-03) has been submitted for draft-ietf-opsawg-hmac-sha-2-usm-snmp: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Feb 18 06:58:34 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83121A8835 for ; Wed, 18 Feb 2015 06:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLTJDjhoGJdv for ; Wed, 18 Feb 2015 06:58:30 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5764F1A87D7 for ; Wed, 18 Feb 2015 06:58:30 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id em10so2743701wid.5 for ; Wed, 18 Feb 2015 06:58:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Hh6q8iGpxHs+E8WACjEnfBB9uux88/WXXIpwwt7Jkno=; b=jcLNH1h826yOxJlBVknpUXOIvr1o16+8UYqhgESV0Ktpxh6kSfLGTRBkmu0g0jOW6w KWpkFYFA4PXDbSdJw8p2890bN4ijdeskESVbWfNPvx1U+kr2JtmvFKckLy42r4R02KyF umcJFXqfF1yKysHgWoMgyrlDClc8AhwhRuAGR1vtRM+/iwYTi9pcUHx2RtWY34z+eZGu 9D21nEWxasPLojuXEWPw2qXDhu9jl4evZlNSF8EPjb7J8N+5HIreHnB/9ye6VclvaEh3 w3lyFumZp+7yGpHVm0shy1sUzBIoFS/IKiLeel9nc9t58/2unAqKvzjNr43KSnRnkIiF adqA== X-Gm-Message-State: ALoCoQlVfMtpcCA/xK4N26rvjTtZ5UnqPTuXFt3Ea0KgYNGTUm1sfUC4lnq49fmo6vqow/5D/XIl MIME-Version: 1.0 X-Received: by 10.180.84.100 with SMTP id x4mr5497739wiy.89.1424271508813; Wed, 18 Feb 2015 06:58:28 -0800 (PST) Received: by 10.194.158.229 with HTTP; Wed, 18 Feb 2015 06:58:28 -0800 (PST) In-Reply-To: <025001d04b68$4a240160$4001a8c0@gateway.2wire.net> References: <20141212223024.19483.34288.idtracker@ietfa.amsl.com> <54B79418.2080709@secunet.com> <030a01d03a5c$9d3d8000$4001a8c0@gateway.2wire.net> <01b501d03b29$cab67f00$4001a8c0@gateway.2wire.net> <54C9E945.5010808@secunet.com> <013001d03c76$a5da50a0$4001a8c0@gateway.2wire.net> <025001d04b68$4a240160$4001a8c0@gateway.2wire.net> Date: Wed, 18 Feb 2015 09:58:28 -0500 Message-ID: From: Warren Kumari To: "t.petch" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "opsawg@ietf.org" , Scott Bradner Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 14:58:32 -0000 On Wed, Feb 18, 2015 at 5:46 AM, t.petch wrote: > ----- Original Message ----- > From: "Warren Kumari" > To: "Johannes Merkle" > Cc: ; "Scott Bradner" ; "t.petch" > > Sent: Tuesday, February 17, 2015 9:48 PM > >> And I *think* that this addresses the open questions (see Joel's >> response on the "adding an entry to a registry" question) - please >> feel free to poke me is I missed any... >> >> While having another look before starting the WGLC I found a few more >> minor nits. >> >> 1: >> Values of constants M (the length of the secret key) and N (the length >> of the MAC output) used below, are: >> usmHMAC128SHA224AuthProtocol: M=28, N=16; >> ..." >> it might be nice to say that M and N lengths are octets. This should >> be blindingly obvious from the text in Section 4.1, but doesn't hurt. >> >> 2: >> Your instructions to the RFC Ed contain an off-by-one type error: >> " ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA >> -- RFC Ed.: replace cc with actual number assigned by IANA & >> remove this line" >> 3: >> -02 still has a reference to RFC4231, which isn't used in the doc. >> >> Other: >> There are still some downward references to Informational documents, >> which is a process issue I've not had to deal with recently, and so >> have forgotten the procedure... > > Warren > > You go to the website and see if they have already been approved. > > http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry# > > (2104 6234 have and the latter has a Normative Reference to FIPS 180-3 > which should serve although a strict reading of the web page says not; > but then a strict reading of the web page says that Russ Housley should > have caused the FIPS document to have been added to the web page which > it wasn't). > > Then it is up to the AD to see if they warrant a mention in IETF Last > Call using the information that the Document Shepherd has put in section > 15. > Oh, excellent. Thank you, my search foo failed me... W > Tom Petch > > >> I poked around and there are ~80 Standards Track documents that have >> Normative downrefs to RFC2104, and 3 that reference RFC6234. >> RFC3967 (Clarifying when Standards Track Documents may Refer >> Normatively to Documents at a Lower Level) says that the normal last >> call happens, and we note that there are downward refs. If the AD >> believes that this is a well known case, they may waive this bit. >> Entertainingly enough, it also uses RFC2104 as an example of this >> ("For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well >> known among cryptographers."). >> So, I think we can go ahead with this and I'll make a note when we >> send it over to our AD and he can deal with it. >> >> While we *could* note these in the WGLC call, I think it would be >> cleaner if you could post a new version, and then I think we can kick >> off the WGLC. >> >> W >> >> >> On Tue, Feb 17, 2015 at 3:15 PM, Warren Kumari > wrote: >> > Apologies for the delay - Scott and I were planning on meeting in >> > Singapore to discuss a bunch of OpsAWG stuff, but the scheduling >> > didn't work out (we were there for different meetings and he arrived >> > just before I left...) >> > >> > Anyway, yup, Standards Track (which you've already done, this just >> > closes the loop...) >> > >> > >> > On Fri, Jan 30, 2015 at 5:22 AM, t.petch > wrote: >> >> Warren >> >> >> >> One of the points I raise below calls for input from the WG Chairs. >> >> >> >> The registry that is being updated >> >> > http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh >> >> tml#snmp-number-spaces-5 >> >> requires Standards Track for updating. The current I-D is >> >> Informational. This will hit a brick wall when it reaches IANA > (I-d >> >> Advancement Not Admissible). >> >> >> >> Johannes wisely said that that he would look for the agreement of > the >> >> chairs for this change. >> >> >> >> Do you agree? >> >> >> >> Tom Petch >> >> >> >> ----- Original Message ----- >> >> From: "Johannes Merkle" >> >> To: "t.petch" ; "Warren Kumari" > >> >> Cc: ; "Scott Bradner" >> >> Sent: Thursday, January 29, 2015 8:03 AM >> >> >> >>> Tom, >> >>> >> >>> thanks for the thorough review. This really helps improving the >> >> document. >> >>> >> >>> > s4.2.1 step 2 uses RFC6234 in a way that I think must make it a >> >>> > Normative reference. RFC6234 is not Standards Track but that is > ok, >> >> it >> >>> > is already in the list of IESG permitted downrefs (does that > need >> >>> > calling out at IETF Last Call?) >> >>> >> >>> You are right, but the question is whether I should rather use >> >> references [RFC2104] and [SHA] here. >> >>> >> >>> > >> >>> > s9.1 >> >>> > /apply the use /apply to the use / >> >>> >> >>> Right. >> >>> >> >>> > >> >>> > s9.2 >> >>> > is it the length of the key that gives it strength or its > entropy? >> >> Is >> >>> > abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 >> >>> > really stronger than >> >>> > !qaurk/99SS~ ? >> >>> >> >>> Strictly speaking, you are right, but it is common sense that >> >> cryptographic keys should have maximum entropy, i.e., they >> >>> should be selected uniformly at random from bit string of that > length. >> >> Consequently, virtually all cryptographic papers >> >>> and text books use key the key length synonymous to its entropy. > Thus, >> >> I consider this distinction as unnecessary. >> >>> >> >>> > >> >>> > s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I >> >> think >> >>> > that s9.4 should reflect that (lest it confuses, or am I > confused >> >> having >> >>> > missed an OBJECT somewhere?) >> >>> >> >>> Here I definitely need help, as I have no knowledge about MIBs. >> >> Actually, I copied that section from RFC 3411. Please >> >>> give advise what to write here or if this section is needed at > all. >> >>> >> >>> >> >>> > The names used for the four protocols are not consistent within > the >> >>> > document. Following RFC3414, I think that including Auth is >> >> correct. >> >>> > >> >>> oops, this escaped my attention. >> >>> >> >>> > Updates to this registry requires a Standards Track document > which >> >> this >> >>> > is not. >> >>> >> >>> Wright. If the chairs agree, I'll change the track. >> >>> >> >>> > >> >>> > MIB Module copyright is 2004 >> >>> >> >>> opps again. Copy and paste error. >> >>> >> >>> > >> >>> > Does this document update RFC3414? It adds to the registry that >> >> that >> >>> > RFC created which some ADs say is NOT an update, some ADs say it > IS >> >> an >> >>> > update; I think that we need guidance here (the update by > RFC5590 of >> >>> > RFC3414 is a whole different ball game). >> >>> >> >>> I will wait for the guidance here. >> >>> >> >>> -- >> >>> Johannes >> >> >> > >> > >> > >> > -- >> > I don't think the execution is relevant when it was obviously a bad >> > idea in the first place. >> > This is like putting rabid weasels in your pants, and later > expressing >> > regret at having chosen those particular rabid weasels and that pair >> > of pants. >> > ---maf >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Feb 18 11:05:12 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3F1A0146; Wed, 18 Feb 2015 11:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjSRVRxigisC; Wed, 18 Feb 2015 11:05:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3381A011E; Wed, 18 Feb 2015 11:05:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218190508.15772.91904.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 11:05:08 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 19:05:10 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Wed Feb 18 11:05:13 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-capwap-hybridmac.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1EC8C1A014E; Wed, 18 Feb 2015 11:05:10 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3F1A0146; Wed, 18 Feb 2015 11:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjSRVRxigisC; Wed, 18 Feb 2015 11:05:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3381A011E; Wed, 18 Feb 2015 11:05:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218190508.15772.91904.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 11:05:08 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 19:05:10 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Wed Feb 18 12:07:56 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72A1A020B; Wed, 18 Feb 2015 12:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB4AQmjhHfot; Wed, 18 Feb 2015 12:07:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CEA1A037F; Wed, 18 Feb 2015 12:06:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218200614.15833.41736.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 12:06:14 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:07:53 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Wed Feb 18 12:07:57 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-capwap-hybridmac.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4CCF01A03A8; Wed, 18 Feb 2015 12:07:53 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-capwap-hybridmac.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72A1A020B; Wed, 18 Feb 2015 12:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vB4AQmjhHfot; Wed, 18 Feb 2015 12:07:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CEA1A037F; Wed, 18 Feb 2015 12:06:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218200614.15833.41736.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 12:06:14 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 20:07:53 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ From nobody Wed Feb 18 15:56:47 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6756A1A1B5E; Wed, 18 Feb 2015 15:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngvUBDA7CEpC; Wed, 18 Feb 2015 15:54:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DB41A1AF4; Wed, 18 Feb 2015 15:54:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 15:54:36 -0800 Archived-At: X-Mailman-Approved-At: Wed, 18 Feb 2015 15:56:45 -0800 Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 23:54:37 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm putting this in as a DISCUSS in the event that the authors/WG want to discuss it or that I'm just missing some context, but I will happily move to ABSTAIN if there is no appetite for such discussion -- I see no need to block the document from advancing on the basis of my comments. It's really hard to tell how the "requirements" listed in this document are intended to be used. In fact, it seems incorrect to call them "requirements" at all -- in the sense of somehow being "required" -- given the following: This document provides a problem statement and lists potential requirements for the management of a network with constrained devices. ... Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. ... This document in general does not recommend the realization of any subset of the described requirements. As such this document avoids selecting any of the requirements as mandatory to implement. A device might be able to provide only a particular selected set of requirements and might not be capable to provide all requirements in this document. On the other hand a device vendor might select a specific relevant subset of the requirements to implement. It's hard to see how the approach described above will contribute towards useful standardization. The "requirements" seem more like a laundry list of all the properties that a management architecture, management protocols, networks of constrained devices, and/or individual implementations might find desirable. This also makes me wonder how the WG intends for these "requirements" to be used. What is the next step as far as standardization goes? To design the "management architecture" that is mentioned? Or the "management protocols" that are mentioned -- one or more, working together or separately? Or to consider how existing management protocols can be repurposed for constrained networks (which is sort of hinted at in section 2, but not stated explicitly), to meet some undefined subset of the listed "requirements"? I think publishing a laundry list of desirable properties is ok if people find value in it, but I'm having trouble seeing how this document specifies either a problem statement or requirements that will somehow contribute to standardization efforts in the future. From nobody Wed Feb 18 15:56:48 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 91A611A1B91; Wed, 18 Feb 2015 15:54:37 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6756A1A1B5E; Wed, 18 Feb 2015 15:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngvUBDA7CEpC; Wed, 18 Feb 2015 15:54:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DB41A1AF4; Wed, 18 Feb 2015 15:54:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 15:54:36 -0800 Archived-At: X-Mailman-Approved-At: Wed, 18 Feb 2015 15:56:45 -0800 Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 23:54:37 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm putting this in as a DISCUSS in the event that the authors/WG want to discuss it or that I'm just missing some context, but I will happily move to ABSTAIN if there is no appetite for such discussion -- I see no need to block the document from advancing on the basis of my comments. It's really hard to tell how the "requirements" listed in this document are intended to be used. In fact, it seems incorrect to call them "requirements" at all -- in the sense of somehow being "required" -- given the following: This document provides a problem statement and lists potential requirements for the management of a network with constrained devices. ... Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. ... This document in general does not recommend the realization of any subset of the described requirements. As such this document avoids selecting any of the requirements as mandatory to implement. A device might be able to provide only a particular selected set of requirements and might not be capable to provide all requirements in this document. On the other hand a device vendor might select a specific relevant subset of the requirements to implement. It's hard to see how the approach described above will contribute towards useful standardization. The "requirements" seem more like a laundry list of all the properties that a management architecture, management protocols, networks of constrained devices, and/or individual implementations might find desirable. This also makes me wonder how the WG intends for these "requirements" to be used. What is the next step as far as standardization goes? To design the "management architecture" that is mentioned? Or the "management protocols" that are mentioned -- one or more, working together or separately? Or to consider how existing management protocols can be repurposed for constrained networks (which is sort of hinted at in section 2, but not stated explicitly), to meet some undefined subset of the listed "requirements"? I think publishing a laundry list of desirable properties is ok if people find value in it, but I'm having trouble seeing how this document specifies either a problem statement or requirements that will somehow contribute to standardization efforts in the future. From nobody Wed Feb 18 17:03:59 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23F1A1AF0 for ; Wed, 18 Feb 2015 17:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bktyiowdwe_c for ; Wed, 18 Feb 2015 17:03:55 -0800 (PST) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F2B1A1C00 for ; Wed, 18 Feb 2015 17:03:54 -0800 (PST) Received: by wevm14 with SMTP id m14so4444784wev.8 for ; Wed, 18 Feb 2015 17:03:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OXD4UqXYMqpmvH0VnoxG4iTTRch8aL2b6Wm9ks9GRJk=; b=jPadDEIR4W4izkAMIx+rSrnYbIWtlMbMYSexxURFPhEBDcZQ7T9cHmBiKLbP2HBtv3 0r1aPTwlErzFq5Jutn3Dgy04MgsrYwWtaLNVJQ3mwobdsIUR/+DHlLI1HVC+dj+J6dxm BBO06J+6ziJcRB2GrN0sfDlUgHhJVqo00BRufW8jrsKJftqfb8GZ22DIBZIKbdwL5M+J s60oEgXEtJIuDh4FP1mt0IFXFgEp/1xsXy0qoEXPF8KXjEqUrxl9z0Fe7ia4v0KVimRB 3QdnevLDE0w0q0a4HXdInYtuBaDNFQlnffn6p5LyjYIoqJJwPsdXXgdCaxvMY8SZqToV hF9g== X-Gm-Message-State: ALoCoQmXZ3CjdUFVNPjRNuwn3O0WGheBUkZpOUOkKslWuatOlqt5cwtcla1g7AASbS2jbK0k/ilA MIME-Version: 1.0 X-Received: by 10.194.84.176 with SMTP id a16mr3594182wjz.113.1424307833423; Wed, 18 Feb 2015 17:03:53 -0800 (PST) Received: by 10.194.158.229 with HTTP; Wed, 18 Feb 2015 17:03:53 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Feb 2015 20:03:53 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-vmm-mib@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 01:03:57 -0000 [ Top post ] Scott and I discussed this document again today, and, in light of the comments we got after the WGLC ended, have decided that there is now enough evidence of support to proceed. Thank you to everyone who commented, and apologies to the authors for the runaround. One of us will write up the shepherd document shortly. W On Wed, Jan 28, 2015 at 6:40 PM, Warren Kumari wrote: > On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari wrote: >> Dear OpsAWG WG, >> >> The authors of draft-ietf-opsawg-vmm-mib have indicated that they >> believe that the document is ready, and have asked for Working Group >> Last Call. >> >> The draft is available here: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ >> >> Please review this draft to see if you think it is ready for >> publication and send comments to the list, clearly stating your view. >> >> This WGLC ends Fri 23-Jan-2015. >> >> In addition, to satisfy RFC 6702 ("Promoting Compliance with >> Intellectual Property Rights (IPR)"): >> Are you personally aware of any IPR that applies to >> draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in >> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 >> for more details.) >> >> Thanks, >> Warren Kumari >> (as OpsAWG WG co-chair) > > The WGLC has concluded with no feedback or comments, and so we have to > conclude that the WG is no longer interested in this work. > > Apologies to the authors, > W > >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Feb 19 06:41:19 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F71A87BA; Thu, 19 Feb 2015 06:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHHNqUZVuG7D; Thu, 19 Feb 2015 06:41:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA701A874E; Thu, 19 Feb 2015 06:41:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219144113.6630.13217.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:41:13 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Ted Lemon's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:41:16 -0000 Ted Lemon has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I was surprised to see no mention of the specific security requirements of the various use cases described here. E.g., the medical use case makes no mention at all of security. While in general security is required in all cases, I think there are differences in the level of security that is required for the various use cases described here, and I wonder if the authors considered this, and if so, why it wasn't mentioned. I don't necessarily want to delay the document's publication pending a resolution to this issue, but I'd like to have a quick discussion about it. From nobody Thu Feb 19 06:41:20 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id ABC611A883F; Thu, 19 Feb 2015 06:41:16 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5F71A87BA; Thu, 19 Feb 2015 06:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHHNqUZVuG7D; Thu, 19 Feb 2015 06:41:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA701A874E; Thu, 19 Feb 2015 06:41:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219144113.6630.13217.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:41:13 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Ted Lemon's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:41:16 -0000 Ted Lemon has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I was surprised to see no mention of the specific security requirements of the various use cases described here. E.g., the medical use case makes no mention at all of security. While in general security is required in all cases, I think there are differences in the level of security that is required for the various use cases described here, and I wonder if the authors considered this, and if so, why it wasn't mentioned. I don't necessarily want to delay the document's publication pending a resolution to this issue, but I'd like to have a quick discussion about it. From nobody Thu Feb 19 08:05:12 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2981A9136; Thu, 19 Feb 2015 08:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq4QCpNU1je8; Thu, 19 Feb 2015 08:05:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 729ED1A912B; Thu, 19 Feb 2015 08:05:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219160506.28882.91163.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 08:05:06 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Ted Lemon's No Objection on draft-ietf-opsawg-coman-use-cases-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:05:08 -0000 Ted Lemon has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm dropping my DISCUSS since Kathleen raised the same point with a lot more detail than I did. FTR, I support Kathleen's DISCUSS. Here is the text of my former DISCUSS: I was surprised to see no mention of the specific security requirements of the various use cases described here. E.g., the medical use case makes no mention at all of security. While in general security is required in all cases, I think there are differences in the level of security that is required for the various use cases described here, and I wonder if the authors considered this, and if so, why it wasn't mentioned. I don't necessarily want to delay the document's publication pending a resolution to this issue, but I'd like to have a quick discussion about it. From nobody Thu Feb 19 08:05:15 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 561231A913F; Thu, 19 Feb 2015 08:05:08 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2981A9136; Thu, 19 Feb 2015 08:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq4QCpNU1je8; Thu, 19 Feb 2015 08:05:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 729ED1A912B; Thu, 19 Feb 2015 08:05:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219160506.28882.91163.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 08:05:06 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Ted Lemon's No Objection on draft-ietf-opsawg-coman-use-cases-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:05:08 -0000 Ted Lemon has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm dropping my DISCUSS since Kathleen raised the same point with a lot more detail than I did. FTR, I support Kathleen's DISCUSS. Here is the text of my former DISCUSS: I was surprised to see no mention of the specific security requirements of the various use cases described here. E.g., the medical use case makes no mention at all of security. While in general security is required in all cases, I think there are differences in the level of security that is required for the various use cases described here, and I wonder if the authors considered this, and if so, why it wasn't mentioned. I don't necessarily want to delay the document's publication pending a resolution to this issue, but I'd like to have a quick discussion about it. From nobody Thu Feb 19 08:09:33 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477711A90F6; Thu, 19 Feb 2015 07:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAbejU0OTmc6; Thu, 19 Feb 2015 07:45:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09611A9152; Thu, 19 Feb 2015 07:43:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 07:43:59 -0800 Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 08:09:31 -0800 Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 15:45:58 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft, I just have some security stuff I'd like to discuss that should be easy to resolve as some text is provided. In section 4.5, it is critical to also include a statement on security in addition to privacy. Medical devices with network attachments could be used to kill someone. http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/story?id=20633284 Suggest changing this text from: In both cases, however, it is crucial to protect the privacy of the people to which medical devices are attached. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. To: In both cases, however, it is crucial to protect the safety and privacy of the people to which medical devices are attached. Security precautions to protect access (authentication, encryption, integrity protections, etc.) to such devices may be critical to protecting the safety of the individual. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. General statement: Many of the other use case scenarios also have safety as a concern, requiring security protections (Confidentiality, Integrity, Availability). Sensors used to control environmental settings is another example where air regulation might include detection of harmful things in the air (carbon monoxide). I'm sure there are other safety concerns that motivate security protections in each of the use cases, it's not just privacy (which is important). What if a sensor was tampered with to report or not report something detected? That's not covered in the discussion on availability related problems in 4.6, but does represent another set of security considerations that could lead to safety issues. More text on access control considerations for NMS may help. From nobody Thu Feb 19 08:09:35 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 63F0C1AC3F7; Thu, 19 Feb 2015 07:45:58 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477711A90F6; Thu, 19 Feb 2015 07:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAbejU0OTmc6; Thu, 19 Feb 2015 07:45:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09611A9152; Thu, 19 Feb 2015 07:43:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 07:43:59 -0800 Archived-At: X-Mailman-Approved-At: Thu, 19 Feb 2015 08:09:32 -0800 Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-use-cases.all@ietf.org Subject: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 15:45:58 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-coman-use-cases-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft, I just have some security stuff I'd like to discuss that should be easy to resolve as some text is provided. In section 4.5, it is critical to also include a statement on security in addition to privacy. Medical devices with network attachments could be used to kill someone. http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/story?id=20633284 Suggest changing this text from: In both cases, however, it is crucial to protect the privacy of the people to which medical devices are attached. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. To: In both cases, however, it is crucial to protect the safety and privacy of the people to which medical devices are attached. Security precautions to protect access (authentication, encryption, integrity protections, etc.) to such devices may be critical to protecting the safety of the individual. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. General statement: Many of the other use case scenarios also have safety as a concern, requiring security protections (Confidentiality, Integrity, Availability). Sensors used to control environmental settings is another example where air regulation might include detection of harmful things in the air (carbon monoxide). I'm sure there are other safety concerns that motivate security protections in each of the use cases, it's not just privacy (which is important). What if a sensor was tampered with to report or not report something detected? That's not covered in the discussion on availability related problems in 4.6, but does represent another set of security considerations that could lead to safety issues. More text on access control considerations for NMS may help. From nobody Thu Feb 19 08:10:26 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DF51A90B4; Thu, 19 Feb 2015 08:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvRlBxIv9ezl; Thu, 19 Feb 2015 08:10:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D491A9142; Thu, 19 Feb 2015 08:10:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 08:10:02 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:10:24 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have not had time to read the full draft, but do see a gap in the security requirements that I'd like to see if we can address. The section on access controls for management systems and devices reads as follows: Req-ID: 6.003 Title: Access control on management system and devices Description: Systems acting in a management role must provide an access control mechanism that allows the security administrator to restrict which devices can access the managing system (e.g., using an access control white list of known devices). On the other hand managed constrained devices must provide an access control mechanism that allows the security administrator to restrict how systems in a management role can access the device (e.g., no- access, read-only access, and read-write access). Source: Basic security requirement for use cases where access control is essential. The way I read this, there is no statement about general access protections to the device outside of what is designated by a security administrator. I would think a statement on access controls on the device would be very important in consideration of safety concerns that put a strong need for security on such devices (medical, environmental monitors, etc.). Are there additional access mechanisms to the device besides what is possible by the management connection? Could there be factory defaults in place with local access work-arounds or even wireless int he even that there are issues accessing devices from management stations? Do these cause security problems? Are there ports other than those for management open that could lead to security breaches? Or are these out-of-scope because the discussion is about management connections? If it's out-of-scope, it would be good to state that it is even though that would be a concern. Text on this should be added to the security considerations section as a general discussion if it's a concern, but not in scope, similar to what was done for privacy. From nobody Thu Feb 19 08:10:30 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AD3FD1A914D; Thu, 19 Feb 2015 08:10:24 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DF51A90B4; Thu, 19 Feb 2015 08:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvRlBxIv9ezl; Thu, 19 Feb 2015 08:10:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D491A9142; Thu, 19 Feb 2015 08:10:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 08:10:02 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:10:24 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have not had time to read the full draft, but do see a gap in the security requirements that I'd like to see if we can address. The section on access controls for management systems and devices reads as follows: Req-ID: 6.003 Title: Access control on management system and devices Description: Systems acting in a management role must provide an access control mechanism that allows the security administrator to restrict which devices can access the managing system (e.g., using an access control white list of known devices). On the other hand managed constrained devices must provide an access control mechanism that allows the security administrator to restrict how systems in a management role can access the device (e.g., no- access, read-only access, and read-write access). Source: Basic security requirement for use cases where access control is essential. The way I read this, there is no statement about general access protections to the device outside of what is designated by a security administrator. I would think a statement on access controls on the device would be very important in consideration of safety concerns that put a strong need for security on such devices (medical, environmental monitors, etc.). Are there additional access mechanisms to the device besides what is possible by the management connection? Could there be factory defaults in place with local access work-arounds or even wireless int he even that there are issues accessing devices from management stations? Do these cause security problems? Are there ports other than those for management open that could lead to security breaches? Or are these out-of-scope because the discussion is about management connections? If it's out-of-scope, it would be good to state that it is even though that would be a concern. Text on this should be added to the security considerations section as a general discussion if it's a concern, but not in scope, similar to what was done for privacy. From nobody Thu Feb 19 11:36:12 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07941A006B; Thu, 19 Feb 2015 11:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKrNC5pSNmnG; Thu, 19 Feb 2015 11:36:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14F1A00E6; Thu, 19 Feb 2015 11:35:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193559.24627.65462.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:35:59 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:36:10 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Thu Feb 19 11:36:13 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D12CE1A00DC; Thu, 19 Feb 2015 11:36:10 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07941A006B; Thu, 19 Feb 2015 11:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKrNC5pSNmnG; Thu, 19 Feb 2015 11:36:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE14F1A00E6; Thu, 19 Feb 2015 11:35:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193559.24627.65462.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:35:59 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:36:11 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ From nobody Thu Feb 19 11:38:25 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731301A002F; Thu, 19 Feb 2015 11:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bh63SpuuP4z; Thu, 19 Feb 2015 11:38:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3186C1A0058; Thu, 19 Feb 2015 11:37:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193750.25186.13153.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:37:50 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:38:06 -0000 X-List-Received-Date: Thu, 19 Feb 2015 19:38:06 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Thu Feb 19 11:38:27 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A6F4A1A0058; Thu, 19 Feb 2015 11:38:06 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731301A002F; Thu, 19 Feb 2015 11:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bh63SpuuP4z; Thu, 19 Feb 2015 11:38:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3186C1A0058; Thu, 19 Feb 2015 11:37:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193750.25186.13153.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:37:50 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:38:06 -0000 IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-use-cases/ From nobody Fri Feb 20 00:47:51 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE671A86DF for ; Fri, 20 Feb 2015 00:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8gCmsE7_Sws for ; Fri, 20 Feb 2015 00:47:47 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04BA1A710C for ; Fri, 20 Feb 2015 00:47:46 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2C5D21A00BE for ; Fri, 20 Feb 2015 09:47:35 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id N-pkbH7BC7mn for ; Fri, 20 Feb 2015 09:47:33 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id E2C401A00AC for ; Fri, 20 Feb 2015 09:47:33 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 20 Feb 2015 09:47:43 +0100 Message-ID: <54E6F4AF.7050604@secunet.com> Date: Fri, 20 Feb 2015 09:47:43 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20150218135352.15606.31349.idtracker@ietfa.amsl.com> In-Reply-To: <20150218135352.15606.31349.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 08:47:49 -0000 this draft addresses Warren's comments. Ready for LC? Johannes internet-drafts@ietf.org schrieb am 18.02.2015 um 14:53: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. > > Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP > Authors : Johannes Merkle > Manfred Lochter > Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt > Pages : 13 > Date : 2015-02-18 > > Abstract: > This memo specifies new HMAC-SHA-2 authentication protocols for the > User-based Security Model (USM) for SNMPv3 defined in RFC 3414. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From nobody Fri Feb 20 03:00:41 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719731A886B for ; Fri, 20 Feb 2015 03:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMwaPw0Y_qKR for ; Fri, 20 Feb 2015 03:00:29 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F71A1A886F for ; Fri, 20 Feb 2015 03:00:24 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.93.16; Fri, 20 Feb 2015 10:56:02 +0000 Message-ID: <021c01d04cfb$8e7b6c60$4001a8c0@gateway.2wire.net> From: t.petch To: Johannes Merkle , References: <20150218135352.15606.31349.idtracker@ietfa.amsl.com> <54E6F4AF.7050604@secunet.com> Date: Fri, 20 Feb 2015 10:11:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [81.151.167.59] X-ClientProxiedBy: DB4PR03CA0004.eurprd03.prod.outlook.com (25.160.39.142) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:DBXPR07MB063; X-Forefront-PRVS: 0493852DA9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(51704005)(377454003)(13464003)(199003)(377424004)(189002)(46102003)(97736003)(66066001)(50466002)(33646002)(116806002)(92566002)(101416001)(84392001)(19580395003)(230783001)(19580405001)(61296003)(1720100001)(15975445007)(23756003)(1456003)(86362001)(14496001)(44716002)(62236002)(106356001)(81816999)(81686999)(50226001)(122386002)(105586002)(68736005)(77096005)(50986999)(76176999)(40100003)(64706001)(87976001)(1556002)(44736004)(42186005)(62966003)(107886001)(77156002)(47776003)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2015 10:56:02.0811 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB063 Archived-At: Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:00:34 -0000 ----- Original Message ----- From: "Johannes Merkle" To: Sent: Friday, February 20, 2015 8:47 AM > this draft addresses Warren's comments. and mine Tom Petch > Ready for LC? > > Johannes > > > internet-drafts@ietf.org schrieb am 18.02.2015 um 14:53: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. > > > > Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP > > Authors : Johannes Merkle > > Manfred Lochter > > Filename : draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt > > Pages : 13 > > Date : 2015-02-18 > > > > Abstract: > > This memo specifies new HMAC-SHA-2 authentication protocols for the > > User-based Security Model (USM) for SNMPv3 defined in RFC 3414. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-0 3 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 From nobody Fri Feb 20 03:56:34 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAC91A88BC for ; Fri, 20 Feb 2015 03:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VHfgPkb2BU6 for ; Fri, 20 Feb 2015 03:56:29 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5121A8969 for ; Fri, 20 Feb 2015 03:50:05 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 701F91A00B9; Fri, 20 Feb 2015 12:49:53 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id K37wQDeodu4V; Fri, 20 Feb 2015 12:49:52 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 77F781A00B4; Fri, 20 Feb 2015 12:49:52 +0100 (CET) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 20 Feb 2015 12:50:01 +0100 Message-ID: <54E71F6A.4040509@secunet.com> Date: Fri, 20 Feb 2015 12:50:02 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: t.petch , References: <20150218135352.15606.31349.idtracker@ietfa.amsl.com> <54E6F4AF.7050604@secunet.com> <021c01d04cfb$8e7b6c60$4001a8c0@gateway.2wire.net> In-Reply-To: <021c01d04cfb$8e7b6c60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:56:31 -0000 >> this draft addresses Warren's comments. > > and mine your's had been addressed by version 02 already. Johannes From nobody Fri Feb 20 06:47:30 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B7A1A87A3 for ; Fri, 20 Feb 2015 06:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caIHM7S5nCVJ for ; Fri, 20 Feb 2015 06:47:27 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD44D1A7007 for ; Fri, 20 Feb 2015 06:47:26 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id n12so13622133wgh.1 for ; Fri, 20 Feb 2015 06:47:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=6svLUYiitGG/RRxLtVFiT+rzHvJijtE2Qefedt07KpA=; b=Uzqv1G0BSz1VZlZHdMVwqsnNWpUQnNE3kDHfoNDFuv4+5p41DwsjWchlYBlNUBSPYg clgZeZLqlavtVA5tNKTPgFq2JGM00OPuDbrzSWiHg3xkbHZ7ASWYZuUMRsW1Vkw6pvGH UiMe19R8O807HZly7BgeqmVNNGSxrRHqynFni7RTyrYRE73EQ3DmB+32xH4wWnbj+ksc wd+HngGA74eZI5BPwWlbVbtQYtHxhlc9R+Mr8OALEyiNUrPCKF9wgbFiG6cVKHOHbyFS T6AX/9d2a8DH7814v3ailnD7nVth/FsRYSfaq39j1pBontMrjTZi8U6zW0TElFcU+qpp dNxg== X-Gm-Message-State: ALoCoQmPS42Vr9xzjKP0nHWNKVxtfUmcdJr++0IsbCp24rcKMdFznxpsUpCtsC/Ssw12yJkWLgOR MIME-Version: 1.0 X-Received: by 10.180.74.111 with SMTP id s15mr6195649wiv.61.1424443644753; Fri, 20 Feb 2015 06:47:24 -0800 (PST) Received: by 10.194.158.229 with HTTP; Fri, 20 Feb 2015 06:47:24 -0800 (PST) Date: Fri, 20 Feb 2015 09:47:24 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 14:47:29 -0000 Dear OpsAWG WG, The authors of draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 have indicated that they believe that the document is ready, and have asked for Working Group Last Call. The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03/ Please review this draft to see if you think it is ready for publication and send comments to the list, clearly stating your view. This document has already received significant review during adoption, etc. and so reviewing it should not be a large hardship. We'd like at **least** 5 regular WG participants to chime in saying that they support the document. This WGLC ends Fri 06-Mar-2015. In addition, to satisfy RFC 6702 ("Promoting Compliance with Intellectual Property Rights (IPR)"): Are you personally aware of any IPR that applies to draft-ietf-opsawg-hmac-sha-2-usm-snmp-03? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Thanks, Warren Kumari (as OpsAWG WG co-chair) -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Feb 20 08:49:23 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BFE1A03F9 for ; Fri, 20 Feb 2015 08:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdZWoMs6UaeZ for ; Fri, 20 Feb 2015 08:49:17 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D121A044D for ; Fri, 20 Feb 2015 08:49:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 977DE93E; Fri, 20 Feb 2015 17:49:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8fvma6b9ntsU; Fri, 20 Feb 2015 17:49:00 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 20 Feb 2015 17:49:14 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9D8E20036; Fri, 20 Feb 2015 17:49:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ITJ2QH7wQyBN; Fri, 20 Feb 2015 17:49:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A257220031; Fri, 20 Feb 2015 17:49:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7F1DF323413B; Fri, 20 Feb 2015 17:49:13 +0100 (CET) Date: Fri, 20 Feb 2015 17:49:13 +0100 From: Juergen Schoenwaelder To: Warren Kumari Message-ID: <20150220164913.GA35856@elstar.local> Mail-Followup-To: Warren Kumari , "opsawg@ietf.org" , draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org, "opsawg-chairs@tools.ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" , draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 20 Feb 2015 16:49:20 -0000 Hi, I have reviewed this document and I support it moving forward. There are a couple of nits that should be fixed before submitting the document to the IESG. Section 7.1: - replace "MIB" with "MIB module" Section 7.2: - replace "The SNMP Management Architecture MIB (SNMP-FRAMEWORK-MIB)" with "SNMP-FRAMEWORK-MIB" - remove "Therefore, the use of the HMAC-SHA2 authentication protocols requires the usage of the objects defined in the SNMP-FRAMEWORK-MIB." since this sentence is not needed Section 7.3: - replace "IMPORTS objects" with "IMPORTS definitions" Section 8: - The comment behind LAST-UPDATED is wrong (this happens once there is redundant information) - The DESCRIPTION clause of the MODULE-IDENTITY macro says that there is supplementary information at IANA. I am not sure what this means. Perhaps this last paragraph needs to be changed to what other recent MIB modules include, namely a short version of the copyright statement. See for example RFC 7331. - This may be wrong: usmHMAC384SHA12AuthProtocol (a 5 missing) - The MIB modules compiles using smilint after fixing the RFC Ed. comments below the definition of usmHMAC256SHA384AuthProtocol and usmHMAC384SHA12AuthProtocol. Section 9.1: - I think this sentence should be changed to this: The security considerations of [RFC3414] also apply to the HMAC-SHA-2 authentication protocols defined in this 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 nobody Fri Feb 20 09:54:37 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 226581A8A9E; Fri, 20 Feb 2015 09:50:16 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02691A8A99; Fri, 20 Feb 2015 09:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx23qO6b83Pn; Fri, 20 Feb 2015 09:50:13 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CDE1A90C1; Fri, 20 Feb 2015 09:46:37 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t1KHkZ6e007182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Feb 2015 17:46:35 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t1KHkXgp011962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Feb 2015 18:46:33 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 20 Feb 2015 18:46:33 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 18:46:32 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Martin Stiemerling , The IESG Thread-Topic: Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) Thread-Index: AQHQSvRJbYbiF2N5gUmbfXCYNR53/pz5zEAw Date: Fri, 20 Feb 2015 17:46:32 +0000 Message-ID: References: <20150217205700.5559.49278.idtracker@ietfa.amsl.com> In-Reply-To: <20150217205700.5559.49278.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5552 X-purgate-ID: 151667::1424454395-000067C4-B4E3755A/0/0 Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 09:54:36 -0800 Cc: "opsawg-chairs@ietf.org" , "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 17:50:16 -0000 SGkgTWFydGluLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMuDQoNCj4gLSBSZXEtSUQ6 ICAxMC4wMDE6IE5vdCBzdXJlIGlmIHRoaXMgaXMgcmVhbGx5IGEgcmVxdWlyZW1lbnQgZm9yIGEN Cj4gdHJhbnNwb3J0IHByb3RvY29sLiBJIHdvdWxkIHJlYWQgdGhpcyBhcyBhIHJlcXVpcmVtZW50 IGZvciB0aGUNCj4gaW1wbGVtZW50YXRpb24gb2YgYSB0cmFuc3BvcnQgcHJvdG9jb2wuDQoNClRo ZSByZXF1aXJlbWVudCB3YXMgbm90IG1lYW50IHRvIGJlIGZvciBhIHBhcnRpY3VsYXIgdHJhbnNw b3J0IHByb3RvY29sLg0KVGhlIHJlcXVpcmVtZW50IGludm9sdmVzIGluZGVlZCB0aGUgdXBwZXIg bGF5ZXIgd2l0aCBtZXNzYWdlIHRyYW5zcG9ydC4NCkEgc2ltcGxlIGV4YW1wbGUgaXMgdGhlIHVz ZSBvZiBDb0FQIGF2b2lkaW5nIG1lc3NhZ2UgZnJhZ21lbnRhdGlvbi4NCg0KSSB3b3VsZCBsaWtl IHRvIHByb3Bvc2UgZm9sbG93aW5nIGNoYW5nZToNCg0Kcy9zY2FsYWJsZSB0cmFuc3BvcnQgbGF5 ZXIvc2NhbGFibGUgbWVzc2FnZSB0cmFuc3BvcnQvDQoNCj4gLSBSZXEtSUQ6ICAxMC4wMDIgc2F5 cw0KPiAgICAgICBEZXNjcmlwdGlvbjogIERpdmVyc2UgYXBwbGljYXRpb25zIG5lZWQgYSByZWxp YWJsZSB0cmFuc3BvcnQgb2YNCj4gICAgICAgbWVzc2FnZXMuICBUaGUgcmVsaWFiaWxpdHkgbWln aHQgYmUgYWNoaWV2ZWQgYmFzZWQgb24gYSB0cmFuc3BvcnQNCj4gICAgICAgcHJvdG9jb2wgc3Vj aCBhcyBUQ1Agb3IgY2FuIGJlIHN1cHBvcnRlZCBiYXNlZCBvbiBtZXNzYWdlDQo+ICAgICAgIHJl cGV0aXRpb24gaWYgYW4gYWNrbm93bGVkZ21lbnQgaXMgbWlzc2luZy4NCj4NCj4gUmVwaXRpdGlv biB3aXRob3V0IGFueSBsaW1pdGF0aW9uIG9uIHRoZSBudW1iZXIgb2YgcmVwaXRpdGlvbnMsIGV0 YyBpcw0KPiBub3QgYSBmZWF0dXJlIG9mIGEgcmVsaWFibGUgdHJhbnNwb3J0IHByb3RvY29sLiBJ IHdvdWxkIHJlbW92ZSAib3IgY2FuIGJlDQo+IHN1cHBvcnRlZCBiYXNlZCBvbiBtZXNzYWdlIHJl cGV0aXRpb24gaWYgYW4gYWNrbm93bGVkZ21lbnQgaXMgbWlzc2luZyIuDQo+IE90aGVyd2lzZSB0 aGUgdGV4dCB3aWxsIGJsb3cgdXAgd2hlbiB5b3UgdHJ5IHRvIHNwZWNpZmljIHdoYXQgZmVhdHVy ZXMgYQ0KPiByZWxpYWJsZSB0cmFuc3BvcnQgcHJvdG9jb2wgc2hvdWxkIGhhdmUuDQoNCklmIHdl IHJlbW92ZSB0aGUgcGFydCB5b3UgbWVhbnQgSSB0aGluayB3ZSBhcmUgbG9zaW5nIHNvbWV0aGlu Zy4NCkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRvIGNoYW5nZSBhcyBmb2xsb3dpbmcuDQoNCk9M RDoNCiAgICAgIFRoZSByZWxpYWJpbGl0eSBtaWdodCBiZSBhY2hpZXZlZCBiYXNlZCBvbiBhIHRy YW5zcG9ydA0KICAgICAgcHJvdG9jb2wgc3VjaCBhcyBUQ1Agb3IgY2FuIGJlIHN1cHBvcnRlZCBi YXNlZCBvbiBtZXNzYWdlDQogICAgICByZXBldGl0aW9uIGlmIGFuIGFja25vd2xlZGdtZW50IGlz IG1pc3NpbmcuDQpORVc6DQogICAgICBUaGUgcmVsaWFiaWxpdHkgbWlnaHQgYmUgYWNoaWV2ZWQg YmFzZWQgb24gYSB0cmFuc3BvcnQNCiAgICAgIHByb3RvY29sIHN1Y2ggYXMgVENQIG9yIGNhbiBi ZSBzdXBwb3J0ZWQgdXNpbmcgYSBtZXNzYWdlDQogICAgICByZXBldGl0aW9uIGZvciB0aGUgbWVz c2FnZSB0cmFuc3BvcnQuDQoNCj4gLSBSZXEtSUQ6ICAxMC4wMDM6IE11bHRpY2FzdCBpcyBub3Qg YSBmZWF0dXJlIG9mIHRoZSB0cmFuc3BvcnQgbGF5ZXIuDQoNClRoZSByZXF1aXJlbWVudCBpcyBs ZWFuZWQgb24gbWVzc2FnZSB0cmFuc3BvcnQuDQoNCldpdGggdGhpcyBtYXkgYmUgc2hvdWxkIGFs c28gY2hhbmdlIHRoZSBzdWJzZWN0aW9uIHRpdGxlIHRvOg0KMy4xMC4gVHJhbnNwb3J0IGxheWVy IGFuZCBNZXNzYWdlIFRyYW5zcG9ydCANCg0KQ2hlZXJzLCANCk1laG1ldCANCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IE1hcnRpbiBTdGllbWVybGluZyBbbWFpbHRv Om1scy5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNywgMjAxNSA5 OjU3IFBNDQpUbzogVGhlIElFU0cNCkNjOiBvcHNhd2dAaWV0Zi5vcmc7IHdhcnJlbkBrdW1hcmku bmV0OyBkcmFmdC1pZXRmLW9wc2F3Zy1jb21hbi1wcm9ic3RhdGUtcmVxcy5hbGxAaWV0Zi5vcmc7 IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IE1hcnRpbiBTdGllbWVybGluZydzIE5v IE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9wc2F3Zy1jb21hbi1wcm9ic3RhdGUtcmVxcy0wNDog KHdpdGggQ09NTUVOVCkNCg0KTWFydGluIFN0aWVtZXJsaW5nIGhhcyBlbnRlcmVkIHRoZSBmb2xs b3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1vcHNhd2ctY29tYW4tcHJvYnN0 YXRlLXJlcXMtMDQ6IE5vIE9iamVjdGlvbg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVw IHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCmVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz DQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8g aHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwN CmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3Np dGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW9wc2F3Zy1jb21hbi1wcm9ic3RhdGUtcmVxcy8NCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk5vIG9iamVjdGlvbiB0byB0aGUgcHVibGlj YXRpb24gb2YgdGhpcyBkcmFmdCwgYnV0IG9mIGNvdXJzZSBhIG51bWJlciBvZg0KY29tbWVudHMg YWJvdXQgU2VjdGlvbiAzLjEwIG9uIFRyYW5zcG9ydCBwcm90b2NvbHM6DQoNCi0gUmVxLUlEOiAg MTAuMDAxOiBOb3Qgc3VyZSBpZiB0aGlzIGlzIHJlYWxseSBhIHJlcXVpcmVtZW50IGZvciBhDQp0 cmFuc3BvcnQgcHJvdG9jb2wuIEkgd291bGQgcmVhZCB0aGlzIGFzIGEgcmVxdWlyZW1lbnQgZm9y IHRoZQ0KaW1wbGVtZW50YXRpb24gb2YgYSB0cmFuc3BvcnQgcHJvdG9jb2wuIA0KDQotIFJlcS1J RDogIDEwLjAwMiBzYXlzDQogICAgICBEZXNjcmlwdGlvbjogIERpdmVyc2UgYXBwbGljYXRpb25z IG5lZWQgYSByZWxpYWJsZSB0cmFuc3BvcnQgb2YNCiAgICAgIG1lc3NhZ2VzLiAgVGhlIHJlbGlh YmlsaXR5IG1pZ2h0IGJlIGFjaGlldmVkIGJhc2VkIG9uIGEgdHJhbnNwb3J0DQogICAgICBwcm90 b2NvbCBzdWNoIGFzIFRDUCBvciBjYW4gYmUgc3VwcG9ydGVkIGJhc2VkIG9uIG1lc3NhZ2UNCiAg ICAgIHJlcGV0aXRpb24gaWYgYW4gYWNrbm93bGVkZ21lbnQgaXMgbWlzc2luZy4NCg0KUmVwaXRp dGlvbiB3aXRob3V0IGFueSBsaW1pdGF0aW9uIG9uIHRoZSBudW1iZXIgb2YgcmVwaXRpdGlvbnMs IGV0YyBpcw0Kbm90IGEgZmVhdHVyZSBvZiBhIHJlbGlhYmxlIHRyYW5zcG9ydCBwcm90b2NvbC4g SSB3b3VsZCByZW1vdmUgIm9yIGNhbiBiZQ0Kc3VwcG9ydGVkIGJhc2VkIG9uIG1lc3NhZ2UgcmVw ZXRpdGlvbiBpZiBhbiBhY2tub3dsZWRnbWVudCBpcyBtaXNzaW5nIi4NCk90aGVyd2lzZSB0aGUg dGV4dCB3aWxsIGJsb3cgdXAgd2hlbiB5b3UgdHJ5IHRvIHNwZWNpZmljIHdoYXQgZmVhdHVyZXMg YQ0KcmVsaWFibGUgdHJhbnNwb3J0IHByb3RvY29sIHNob3VsZCBoYXZlLiANCg0KLSBSZXEtSUQ6 ICAxMC4wMDM6IE11bHRpY2FzdCBpcyBub3QgYSBmZWF0dXJlIG9mIHRoZSB0cmFuc3BvcnQgbGF5 ZXIuDQoNCg0K From nobody Fri Feb 20 10:04:18 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308731A6EF8 for ; Fri, 20 Feb 2015 10:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9kF75DNnEq0 for ; Fri, 20 Feb 2015 10:04:14 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2771A037C for ; Fri, 20 Feb 2015 10:02:59 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA11408; Fri, 20 Feb 2015 13:02:52 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id NAA07772; Fri, 20 Feb 2015 13:02:51 -0500 (EST) Message-Id: <201502201802.NAA07772@adminfs.snmp.com> To: Warren Kumari From: David Reid In-reply-to: Your message of Fri, 20 Feb 2015 09:47:24 -0500. Date: Fri, 20 Feb 2015 13:02:50 -0500 Sender: reid@snmp.com Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" , draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:04:17 -0000 I have reviewed the document and I think it is ready for publication. We have also implemented it (using private OIDs for now). -David Reid > Dear OpsAWG WG, > > The authors of draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 have indicated > that they believe that the document is ready, and have asked for > Working Group Last Call. > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This document has already received significant review during adoption, > etc. and so reviewing it should not be a large hardship. We'd like at > **least** 5 regular WG participants to chime in saying that they > support the document. > > > This WGLC ends Fri 06-Mar-2015. > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-hmac-sha-2-usm-snmp-03? If so, has this IPR been > disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, > 3669, and 5378 for more details.) > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Feb 20 10:38:22 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A200E1A6F24 for ; Fri, 20 Feb 2015 10:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNp-BZoC0B-a for ; Fri, 20 Feb 2015 10:38:18 -0800 (PST) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40D931A3BA9 for ; Fri, 20 Feb 2015 10:38:17 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t1KIbt8h012161 for ; Fri, 20 Feb 2015 13:38:16 -0500 From: "Blumenthal, Uri - 0558 - MITLL" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. Thread-Index: AQHQTTwijbOomfl1Dkub85hYM915hg== Date: Fri, 20 Feb 2015 18:36:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3507284179_155421" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-20_09:2015-02-20,2015-02-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502200176 Archived-At: Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 18:38:21 -0000 --B_3507284179_155421 Content-type: multipart/alternative; boundary="B_3507284179_158387" --B_3507284179_158387 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I reviewed this draft, and think that it should be published (and implemented). I=E2=80=99m not aware of any IPR that would apply. Thanks! P.S. Juergen is correct (post of Feb 20), and I=E2=80=99d like to see his corrections applied before the final submission. --=20 Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 > Dear OpsAWG WG, >=20 > The authors of draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 have indicated > that they believe that the document is ready, and have asked for > Working Group Last Call. > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03= / >=20 > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. >=20 > This document has already received significant review during adoption, > etc. and so reviewing it should not be a large hardship. We'd like at > **least** 5 regular WG participants to chime in saying that they > support the document. >=20 >=20 > This WGLC ends Fri 06-Mar-2015. >=20 >=20 > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-hmac-sha-2-usm-snmp-03? If so, has this IPR been > disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, > 3669, and 5378 for more details.) >=20 > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG at ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --B_3507284179_158387 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I reviewed this draft, and th= ink that it should be published (and implemented).

= I’m not aware of any IPR that would apply.

Th= anks!

P.S. Juergen is correct (post of Feb 20), and= I’d like to see his corrections applied before the final submission.<= /div>
-- 
Regards,<= /div>
Uri Blumenthal       &n= bsp;                     &= nbsp; Voice: (781) 981-1638
Cyber Syst= ems and Technology   Fax:    (781) 981-0186

> Dear OpsAWG WG,
> 
> The authors of draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 have indicated=

> that they believe that the document is ready, and have asked for
> Working Group Last Call.
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-op=
sawg-hmac-sha-2-usm-snmp-03/
> 
> Please review this draft to see if you think it is ready for
> publication and send comments to the list, clearly stating your view.
> 
> This document has already received significant review during adoption,=

> etc. and so reviewing it should not be a large hardship. We'd like at
> **least** 5 regular WG participants to chime in saying that they
> support the document.
> 
> 
> This WGLC ends Fri 06-Mar-2015.
> 
> 
> In addition, to satisfy RFC 6702 ("Promoting Compliance with
> Intellectual Property Rights (IPR)"):
> Are you personally aware of any IPR that applies to
> draft-ietf-opsawg-hmac-sha-2-usm-snmp-03?  If so, has this IPR been
> disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879,
> 3669, and 5378 for more details.)
> 
> Thanks,
> Warren Kumari
> (as OpsAWG WG co-chair)
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing=

> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG at ietf.org
> =
https://www.ietf.org/mailman/listinfo/opsawg
--B_3507284179_158387-- --B_3507284179_155421 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK KHB6MgAAAAAtBzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE1MDEyMzE3NDkyOVoXDTE2MDEyMzE3NDkyOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDF+Rcs9hNO5hvlE0YeltqeXGUW1u3RVMG4/2ag6J2FgcsOJxOZy/m+7FeYfCo3XYrNqx6/ 3IZmDSYln3JnxzPionDcbK2TJ9xAOoWlrUykAhgUl+PCO8ahDV5Yc0tmMzf5MXBrsub0nUyJ eDkxOUY2Id58D1UVzzXh9Kvjc+ZCcBRFoViAgn7MznnuvK8Y5m7Lor1oLWSxNNUyp98gC4Ep dHLnA8yP1WqmNr0x+YssjJgEiIfZFqx8Gvv2OqtHaFGHh7Y6+WOWIZULMaAc9JJEq8ctns9m GIRldf2JMFcNsahQJDhgUspmP6c1Wz9OrUxsgwnGQ5feIq9c/4YZYEZ/AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQUR0hebk4i6063YnpEEVXyQUyfSFMwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBDAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBADim5zjTb/h3ea/66DNM6wSmi1Ti9F2f2/Are2a7a9E/ IPXfleh39lVG7uTaneEJMSHzDltkB5k6DYMv/t28ntQm2jLI9adMwccDlKSR2uIDsiA7jodi TxbqL/aRi+WC4ybWWhXuzSbkMesayt5QAKpuKLAr7newfZaWx8zPnWU1nWZBbJR7cLKgUTaE iQu/NlCWIFJIC9yRhze+KR41vIa+7niQnUANjoYCCu32Z8xgxhK4kQr5teUVUNDoCj02x781 GFfwCknxpsWEm95OWM1iaXKCGJ8ciioulEzksZUrIHdImISaQVV+Xdmbcd3OH6y8fNl1mZdX n8sxNJc+/g0xggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCh9F 2aAAAAAAAc0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgTM+Mxwe0I22eaMo0 z+0wtvEHfbLooeRkiHlMMDYG6bswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTUwMjIwMTgzNjE5WjANBgkqhkiG9w0BAQEFAASCAQBcH5zVimmLippUExef k/sY2EmzywHIgZr31zuHT4amf6rwZTh6+237chIBBmqg8yL8LCMgjEmyvOCAMbBTSySzyoH9 HeXXMPitWJVsq8frmzXbAhQDkYl8WG9OV4RpjrhZNxmqwEajWULBAVtJ6hS4HRgU7gGkBs4K c+vcAD2CEdYN4beeatHYdhw5WUKK2XxAwWEitNjeTsq0ao7N/Ykx8RBDpFiTZggHM1Ptyj8F /ZcTyvor0yiULR8+dCLOxxRfPuG5X5AIlBZpEmi8mu+yJHPL17WUwt2rLBYsJff9fYIDHQYj JVdqe+eIM1TmCm+H3Sn3zBu7sUn3NORIFZ0r --B_3507284179_155421-- From nobody Sun Feb 22 07:52:03 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1A61A1BCB; Sun, 22 Feb 2015 07:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhvEuB3vvecZ; Sun, 22 Feb 2015 07:51:59 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994DF1A1BC7; Sun, 22 Feb 2015 07:51:59 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so13218770igb.5; Sun, 22 Feb 2015 07:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=qcTiJbiwgsuAHbNZdv6xeQvAISUu7oIG1ggctYOnCPY=; b=koifMrudZDBGCkptAlkVmT75ISKJY+zevr2LqXTY8LZ33PjIbb+h5NpYGQnCWAH99m b/JhRl7Xf09zpb+DaH2rThpQS1eIy6S1KgPiCyMjcybY+6l8k7tMY3ufscu4dkL6MawO BigBCFA9l8P3i3cxJZNiiaL6oMFurdtwZPOy8JW9p3S2ifqtDxWXetGrIQA5eojKW2C+ vKIM/q04RdM1FpcLf7YiaXh6KqtHZtt6dlq2ravio+sdHAEBucI3Wg/n9Ctm6EqnyYXV FLlv18ddAmKxuEijy+yCYZVSWn9N+OFFNViuhS5nRIAiw9eRWcz+BtJCVhrBvPR6sbsQ 9G/g== X-Received: by 10.43.34.137 with SMTP id ss9mr7538341icb.11.1424620318830; Sun, 22 Feb 2015 07:51:58 -0800 (PST) Received: from [192.168.0.102] (dsl-173-206-74-106.tor.primus.ca. [173.206.74.106]) by mx.google.com with ESMTPSA id t41sm20618989ioi.0.2015.02.22.07.51.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 07:51:58 -0800 (PST) Message-ID: <54E9FB1F.1060401@gmail.com> Date: Sun, 22 Feb 2015 10:51:59 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "behave@ietf.org" , "opsawg@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] Reviewing draft-perrault-behave-natv2-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 15:52:01 -0000 Could I direct reviewers to Section 3.1.4 of draft-perrault-behave-natv2-mib-02 to start with? Are the statistics described there sufficient for NAT management, and do we have the granularities right? Is there anything we could do without? Tom Taylor From nobody Sun Feb 22 08:02:19 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A58471A1B2C; Sat, 21 Feb 2015 23:44:03 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD741A1B25 for ; Sat, 21 Feb 2015 23:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXDi7MKlvhcY for ; Sat, 21 Feb 2015 23:44:02 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B74D1A1B22 for ; Sat, 21 Feb 2015 23:44:02 -0800 (PST) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:dc23:37b0:8843:73a1]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t1M7hxAx007775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 22 Feb 2015 07:44:00 GMT (envelope-from joelja@bogus.com) Message-ID: <54E988BF.7020302@bogus.com> Date: Sat, 21 Feb 2015 23:43:59 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <20150217205700.5559.49278.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fGMXjHwNiSqdwukajqaRk3dAjIrkjHnS3" Archived-At: X-Mailman-Approved-At: Sun, 22 Feb 2015 08:02:17 -0800 Cc: "opsawg-chairs@ietf.org" , "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 07:44:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fGMXjHwNiSqdwukajqaRk3dAjIrkjHnS3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable thanks mehmet On 2/20/15 9:46 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Martin, >=20 > thank you for your comments. >=20 >> - Req-ID: 10.001: Not sure if this is really a requirement for a >> transport protocol. I would read this as a requirement for the >> implementation of a transport protocol. >=20 > The requirement was not meant to be for a particular transport protocol= =2E > The requirement involves indeed the upper layer with message transport.= > A simple example is the use of CoAP avoiding message fragmentation. >=20 > I would like to propose following change: >=20 > s/scalable transport layer/scalable message transport/ >=20 >> - Req-ID: 10.002 says >> Description: Diverse applications need a reliable transport of >> messages. The reliability might be achieved based on a transpor= t >> protocol such as TCP or can be supported based on message >> repetition if an acknowledgment is missing. >> >> Repitition without any limitation on the number of repititions, etc is= >> not a feature of a reliable transport protocol. I would remove "or can= be >> supported based on message repetition if an acknowledgment is missing"= =2E >> Otherwise the text will blow up when you try to specific what features= a >> reliable transport protocol should have. >=20 > If we remove the part you meant I think we are losing something. > I would like to suggest to change as following. >=20 > OLD: > The reliability might be achieved based on a transport > protocol such as TCP or can be supported based on message > repetition if an acknowledgment is missing. > NEW: > The reliability might be achieved based on a transport > protocol such as TCP or can be supported using a message > repetition for the message transport. >=20 >> - Req-ID: 10.003: Multicast is not a feature of the transport layer. >=20 > The requirement is leaned on message transport. >=20 > With this may be should also change the subsection title to: > 3.10. Transport layer and Message Transport=20 >=20 > Cheers,=20 > Mehmet=20 >=20 >=20 > -----Original Message----- > From: ext Martin Stiemerling [mailto:mls.ietf@gmail.com]=20 > Sent: Tuesday, February 17, 2015 9:57 PM > To: The IESG > Cc: opsawg@ietf.org; warren@kumari.net; draft-ietf-opsawg-coman-probsta= te-reqs.all@ietf.org; opsawg-chairs@ietf.org > Subject: Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-p= robstate-reqs-04: (with COMMENT) >=20 > Martin Stiemerling has entered the following ballot position for > draft-ietf-opsawg-coman-probstate-reqs-04: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/= >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > No objection to the publication of this draft, but of course a number o= f > comments about Section 3.10 on Transport protocols: >=20 > - Req-ID: 10.001: Not sure if this is really a requirement for a > transport protocol. I would read this as a requirement for the > implementation of a transport protocol.=20 >=20 > - Req-ID: 10.002 says > Description: Diverse applications need a reliable transport of > messages. The reliability might be achieved based on a transport= > protocol such as TCP or can be supported based on message > repetition if an acknowledgment is missing. >=20 > Repitition without any limitation on the number of repititions, etc is > not a feature of a reliable transport protocol. I would remove "or can = be > supported based on message repetition if an acknowledgment is missing".= > Otherwise the text will blow up when you try to specific what features = a > reliable transport protocol should have.=20 >=20 > - Req-ID: 10.003: Multicast is not a feature of the transport layer. >=20 >=20 >=20 --fGMXjHwNiSqdwukajqaRk3dAjIrkjHnS3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlTpiL8ACgkQ8AA1q7Z/VrLzdQCdF1KUqXx4jHt6NhbCxBXeTXJ5 3yQAn1W3SeApi9FAU0SzCeJfPsp9bB+p =URkn -----END PGP SIGNATURE----- --fGMXjHwNiSqdwukajqaRk3dAjIrkjHnS3-- From nobody Mon Feb 23 05:11:56 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855FC1A1A97; Mon, 23 Feb 2015 05:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22OjuH-tb4lL; Mon, 23 Feb 2015 05:11:53 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EDE1A1A8F; Mon, 23 Feb 2015 05:11:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkGAHkm61TGmAcV/2dsb2JhbABbgmQiUloEgwStLwEBAQEBAQaSVIVwAhyBBkMBAQEBAQF8hA8BAQEBAxIREUUMBAIBCA0EAQMBAQMCBh0DAgICMBQBAgYIAgQOBQgTB4gNAQyvWIpJmAUBAQEBAQEBAQIBAQEBAQEBAQEBARMEgSGEZoUMhAwRAR8xBwaCYi+BFAWFYolwg16CFoRqgxWCRIw/IoIygTxvgQs5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,630,1418101200"; d="scan'208";a="105154388" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Feb 2015 08:11:51 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 23 Feb 2015 08:11:51 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 23 Feb 2015 08:11:50 -0500 From: "Romascanu, Dan (Dan)" To: Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) Thread-Index: AQHQS9ZCbb+H3Oxo3E6K/tJc6OC49pz+NwVA Date: Mon, 23 Feb 2015 13:11:49 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9A0A07@AZ-FFEXMB04.global.avaya.com> References: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> In-Reply-To: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "opsawg-chairs@ietf.org" , "opsawg@ietf.org" , "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 13:11:55 -0000 SGkgQWxpc3NhLA0KDQpMZXQgbWUgdHJ5IHRvIGFkZHJlc3MgdGhlIGlzc3VlcyB0aGF0IHlvdSBh cmUgcmFpc2luZy4gVGhlIGNvbWFuIHRlYW0gd29ya2VkIGFzIGEgbm9uLVdHIHRlYW0gZm9yIGFi b3V0IDItMyB5ZWFycywgYW5kIG9ubHkgYXQgdGhlIGxhc3QgcGhhc2Ugb2YgdGhlIHdvcmsgZGVj aWRlZCB0byBzZW5kIHRoZSB0d28gcmVzdWx0aW5nIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIHRv IHRoZSBPUFNBV0cgZm9yIGEgYnJvYWRlciByZXZpZXcgYW5kIGV4cG9zdXJlLCBhdCB0aGUgYWR2 aWNlIG9mIG91ciBBRC4gVGhlIHR3byBkb2N1bWVudHMgYXJlIGluZm9ybWF0aW9uYWwsIG9uZSBk ZXNjcmliZXMgdGhlIHVzZSBjYXNlcyBhbmQgdGhlIHNlY29uZCBvbmUgdGhlIHJlcXVpcmVtZW50 cyBmb3IgdGhlIGJyb2FkZXIgc3BhY2UgZGlzY3Vzc2VkIGJ5IHRoZSB1c2UgY2FzZXMgcmVsYXRl ZCB0byBtYW5hZ2VtZW50IG9mIG5ldHdvcmtzIHdpdGggY29uc3RyYWluZWQgZGV2aWNlcy4uIE9u ZSBvZiB0aGUgY29uY2x1c2lvbnMgb2YgdGhlIHdvcmsgaXMgdGhhdCB3ZSBkbyBub3QgYmVsaWV2 ZSB0aGF0IHRoZXJlIGlzIG9uZSBzaW5nbGUgc29sdXRpb24gdGhhdCB3b3VsZCBmaXQgYWxsIHVz ZSBjYXNlcywgdGhpcyB0aGVyZSBpcyBubyBzaW5nbGUgc2V0IG9mIG1hbmRhdG9yeSByZXF1aXJl bWVudHMgdGhhdCBhcHBseSB0byBhbGwgdGhlIHVzZSBjYXNlcy4gTm8gZm9sbG93LXVwIHdvcmsg aXMgcGxhbm5lZCBpbiBPUFMuIFdlIGZlZWwgaG93ZXZlciB0aGF0IHRoZSB0d28gaW5mb3JtYXRp b25hbCBkb2N1bWVudHMgd2lsbCBiZSB1c2VmdWwgZm9yIGZ1cnRoZXIgcmVmZXJlbmNlIGZvciB0 aGVzZSB0ZWFtcyBvciBXR3MgdGhhdCB0cnkgdG8gYnVpbGQgbWFuYWdlbWVudCBzb2x1dGlvbnMg Zm9yIG9uZSBvciBtb3JlIG9mIHRoZSB1c2UgY2FzZXMuIA0KDQpJbiBvcmRlciB0byBtYWtlIHRo ZSBnb2FscyBvZiB0aGUgZG9jdW1lbnQgbW9yZSBjbGVhciB3ZSBzdWdnZXN0IHRoZSBmb2xsb3dp bmcgZWRpdHM6IA0KDQpJbiBBYnN0cmFjdDogDQoNCk9MRDogDQoNCiAgVGhpcyBkb2N1bWVudCBw cm92aWRlcyBhIHByb2JsZW0gc3RhdGVtZW50LCBkZXBsb3ltZW50IGFuZCBtYW5hZ2VtZW50DQog ICB0b3BvbG9neSBvcHRpb25zIGFzIHdlbGwgYXMgcG90ZW50aWFsIHJlcXVpcmVtZW50cyBmb3Ig dGhlIG1hbmFnZW1lbnQNCiAgIG9mIG5ldHdvcmtzIHdoZXJlIGNvbnN0cmFpbmVkIGRldmljZXMg YXJlIGludm9sdmVkLg0KDQpORVc6IA0KDQogIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBwcm9i bGVtIHN0YXRlbWVudCwgZGVwbG95bWVudCBhbmQgbWFuYWdlbWVudA0KICAgdG9wb2xvZ3kgb3B0 aW9ucyBhcyB3ZWxsIGFzIHJlcXVpcmVtZW50cyBhZGRyZXNzaW5nIHRoZSBkaWZmZXJlbnQgdXNl IGNhc2VzIG9mIA0KICAgdGhlIG1hbmFnZW1lbnQgb2YgbmV0d29ya3Mgd2hlcmUgY29uc3RyYWlu ZWQgZGV2aWNlcyBhcmUgaW52b2x2ZWQuDQoNCkluIFNlY3Rpb24gMS4xOiANCg0KT0xEOiANCg0K ICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIGxpc3RzIHBv dGVudGlhbA0KICAgcmVxdWlyZW1lbnRzIGZvciB0aGUgbWFuYWdlbWVudCBvZiBhIG5ldHdvcmsg d2l0aCBjb25zdHJhaW5lZA0KICAgZGV2aWNlcy4gIFNlY3Rpb24gMS4zIGFuZCBTZWN0aW9uIDEu NSBkZXNjcmliZSBkaWZmZXJlbnQgdG9wb2xvZ3kNCiAgIG9wdGlvbnMgZm9yIHRoZSBuZXR3b3Jr aW5nIGFuZCBtYW5hZ2VtZW50IG9mIGNvbnN0cmFpbmVkIGRldmljZXMuDQogICBTZWN0aW9uIDIg cHJvdmlkZXMgYSBwcm9ibGVtIHN0YXRlbWVudCBvbiB0aGUgaXNzdWUgb2YgdGhlIG1hbmFnZW1l bnQNCiAgIG9mIG5ldHdvcmtlZCBjb25zdHJhaW5lZCBkZXZpY2VzLiAgU2VjdGlvbiAzIGxpc3Rz IHJlcXVpcmVtZW50cyBvbg0KICAgdGhlIG1hbmFnZW1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBu ZXR3b3JrcyB3aXRoIGNvbnN0cmFpbmVkIGRldmljZXMuDQogICBOb3RlIHRoYXQgdGhlIHJlcXVp cmVtZW50cyBsaXN0ZWQgaW4gU2VjdGlvbiAzIGhhdmUgYmVlbiBzZXBhcmF0ZWQNCiAgIGZyb20g dGhlIGNvbnRleHQgaW4gd2hpY2ggdGhleSBtYXkgYXBwZWFyLiAgRGVwZW5kaW5nIG9uIHRoZSBj b25jcmV0ZQ0KICAgY2lyY3Vtc3RhbmNlcywgYW4gaW1wbGVtZW50ZXIgbWF5IGRlY2lkZSB0byBh ZGRyZXNzIGEgY2VydGFpbg0KICAgcmVsZXZhbnQgc3Vic2V0IG9mIHRoZSByZXF1aXJlbWVudHMu DQoNCiAgIFRoZSB1c2UgY2FzZXMgaW4gdGhlIGNvbnRleHQgb2YgbmV0d29ya3Mgd2l0aCBjb25z dHJhaW5lZCBkZXZpY2VzIGNhbg0KICAgYmUgZm91bmQgaW4gdGhlIGNvbXBhbmlvbiBkb2N1bWVu dCBbQ09NLVVTRV0uDQoNCk5FVzogDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBwcm9i bGVtIHN0YXRlbWVudCBhbmQgbGlzdHMgcmVxdWlyZW1lbnRzIGZvciB0aGUgDQogICBkaWZmZXJl bnQgdXNlIGNhc2VzIG9mIG1hbmFnZW1lbnQgb2YgYSBuZXR3b3JrIHdpdGggY29uc3RyYWluZWQN CiAgIGRldmljZXMuICBTZWN0aW9uIDEuMyBhbmQgU2VjdGlvbiAxLjUgZGVzY3JpYmUgZGlmZmVy ZW50IHRvcG9sb2d5DQogICBvcHRpb25zIGZvciB0aGUgbmV0d29ya2luZyBhbmQgbWFuYWdlbWVu dCBvZiBjb25zdHJhaW5lZCBkZXZpY2VzLg0KICAgU2VjdGlvbiAyIHByb3ZpZGVzIGEgcHJvYmxl bSBzdGF0ZW1lbnQgb24gdGhlIGlzc3VlIG9mIHRoZSBtYW5hZ2VtZW50DQogICBvZiBuZXR3b3Jr ZWQgY29uc3RyYWluZWQgZGV2aWNlcy4gIFNlY3Rpb24gMyBsaXN0cyByZXF1aXJlbWVudHMgb24N CiAgIHRoZSBtYW5hZ2VtZW50IG9mIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29ya3Mgd2l0aCBjb25z dHJhaW5lZCBkZXZpY2VzLg0KICAgTm90ZSB0aGF0IHRoZSByZXF1aXJlbWVudHMgbGlzdGVkIGlu IFNlY3Rpb24gMyBoYXZlIGJlZW4gc2VwYXJhdGVkDQogICBmcm9tIHRoZSBjb250ZXh0IGluIHdo aWNoIHRoZXkgbWF5IGFwcGVhci4gIERlcGVuZGluZyBvbiB0aGUgY29uY3JldGUNCiAgIGNpcmN1 bXN0YW5jZXMsIGFuIGltcGxlbWVudGVyIG1heSBkZWNpZGUgdG8gYWRkcmVzcyBhIGNlcnRhaW4N CiAgIHJlbGV2YW50IHN1YnNldCBvZiB0aGUgcmVxdWlyZW1lbnRzLg0KDQogICBUaGUgdXNlIGNh c2VzIGluIHRoZSBjb250ZXh0IG9mIG5ldHdvcmtzIHdpdGggY29uc3RyYWluZWQgZGV2aWNlcyBj YW4NCiAgIGJlIGZvdW5kIGluIHRoZSBjb21wYW5pb24gZG9jdW1lbnQgW0NPTS1VU0VdLiBUaGlz IGluZm9ybWF0aW9uYWwgDQogICBkb2N1bWVudCBwcm92aWRlcyBhIGxpc3Qgb2Ygb2JqZWN0aXZl cyBmb3IgZGlzY3Vzc2lvbnMgYW5kIGRvZXMgbm90IGFpbSANCiAgIHRvIGJlIGEgc3RyaWN0IHJl cXVpcmVtZW50cyBkb2N1bWVudCBmb3IgYWxsIHVzZSBjYXNlcy4gSW4gZmFjdCwgdGhlcmUgbGlr ZWx5IA0KICAgaXMgbm90IGEgc2luZ2xlIHNvbHV0aW9uIHRoYXQgd29ya3MgZXF1YWxseSB3ZWxs IGZvciBhbGwgdGhlIHVzZSBjYXNlcy4NCg0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxpc3NhIENvb3BlciBb bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTks IDIwMTUgMTo1NSBBTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IG9wc2F3Z0BpZXRmLm9yZzsgd2Fy cmVuQGt1bWFyaS5uZXQ7IGRyYWZ0LWlldGYtb3BzYXdnLWNvbWFuLQ0KPiBwcm9ic3RhdGUtcmVx cy5hbGxAaWV0Zi5vcmc7IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogQWxpc3Nh IENvb3BlcidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vcHNhd2ctY29tYW4tcHJvYnN0YXRlLXJl cXMtDQo+IDA0OiAod2l0aCBESVNDVVNTKQ0KPiANCj4gQWxpc3NhIENvb3BlciBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1vcHNhd2ct Y29tYW4tcHJvYnN0YXRlLXJlcXMtMDQ6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFp bA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+ IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtDQo+IDNBX193d3cuaWV0Zi5vcmdfaWVzZ19zdGF0ZW1lbnRfZGlzY3Vzcy0N Cj4gMkRjcml0ZXJpYS5odG1sJmQ9QXdJQ2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPUk0 ZHpHeFIzMU9jDQo+IE5YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09TFJUTGlORDV6 TGxla1dVbXNGb2FWS2prcnVnWg0KPiBNLUtudUFxMHU4Nmh5bVEmcz1lSmpBZC0NCj4gQk9Rekd5 dTloeTFiaEk2dlFJbDd4c0hBV016QkxzUGp3R1ZQVSZlPQ0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEb3BzYXdn LTJEY29tYW4tDQo+IDJEcHJvYnN0YXRlLQ0KPiAyRHJlcXNfJmQ9QXdJQ2FRJmM9QkZwV1F3OGJz dUtwbDFTZ2laSDY0USZyPUk0ZHpHeFIzMU9jTlhDSmZRDQo+IHp2bHNpTFFmdWNCWFJ1Y1B2ZHJw aHBCc0ZBJm09TFJUTGlORDV6TGxla1dVbXNGb2FWS2prcnVnWk0tDQo+IEtudUFxMHU4Nmh5bVEm cz1LbUVpbTRnRktDVE5LYnJwczJiUXNrUHpubGtyVGhSZy0NCj4gYk8wZ2pUdnhFTSZlPQ0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IEknbSBwdXR0aW5nIHRoaXMgaW4gYXMgYSBESVNDVVNTIGluIHRoZSBldmVudCB0aGF0IHRo ZSBhdXRob3JzL1dHIHdhbnQgdG8NCj4gZGlzY3VzcyBpdCBvciB0aGF0IEknbSBqdXN0IG1pc3Np bmcgc29tZSBjb250ZXh0LCBidXQgSSB3aWxsIGhhcHBpbHkgbW92ZQ0KPiB0byBBQlNUQUlOIGlm IHRoZXJlIGlzIG5vIGFwcGV0aXRlIGZvciBzdWNoIGRpc2N1c3Npb24gLS0gSSBzZWUgbm8gbmVl ZA0KPiB0byBibG9jayB0aGUgZG9jdW1lbnQgZnJvbSBhZHZhbmNpbmcgb24gdGhlIGJhc2lzIG9m IG15IGNvbW1lbnRzLg0KPiANCj4gSXQncyByZWFsbHkgaGFyZCB0byB0ZWxsIGhvdyB0aGUgInJl cXVpcmVtZW50cyIgbGlzdGVkIGluIHRoaXMgZG9jdW1lbnQNCj4gYXJlIGludGVuZGVkIHRvIGJl IHVzZWQuIEluIGZhY3QsIGl0IHNlZW1zIGluY29ycmVjdCB0byBjYWxsIHRoZW0NCj4gInJlcXVp cmVtZW50cyIgYXQgYWxsIC0tIGluIHRoZSBzZW5zZSBvZiBzb21laG93IGJlaW5nICJyZXF1aXJl ZCIgLS0NCj4gZ2l2ZW4gdGhlIGZvbGxvd2luZzoNCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgYSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgbGlzdHMgcG90ZW50aWFsDQo+ICAgIHJlcXVp cmVtZW50cyBmb3IgdGhlIG1hbmFnZW1lbnQgb2YgYSBuZXR3b3JrIHdpdGggY29uc3RyYWluZWQN Cj4gICAgZGV2aWNlcy4gLi4uIERlcGVuZGluZyBvbiB0aGUgY29uY3JldGUNCj4gICAgY2lyY3Vt c3RhbmNlcywgYW4gaW1wbGVtZW50ZXIgbWF5IGRlY2lkZSB0byBhZGRyZXNzIGEgY2VydGFpbg0K PiAgICByZWxldmFudCBzdWJzZXQgb2YgdGhlIHJlcXVpcmVtZW50cy4NCj4gLi4uDQo+ICAgIFRo aXMgZG9jdW1lbnQgaW4gZ2VuZXJhbA0KPiAgICBkb2VzIG5vdCByZWNvbW1lbmQgdGhlIHJlYWxp emF0aW9uIG9mIGFueSBzdWJzZXQgb2YgdGhlIGRlc2NyaWJlZA0KPiAgICByZXF1aXJlbWVudHMu ICBBcyBzdWNoIHRoaXMgZG9jdW1lbnQgYXZvaWRzIHNlbGVjdGluZyBhbnkgb2YgdGhlDQo+ICAg IHJlcXVpcmVtZW50cyBhcyBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LiAgQSBkZXZpY2UgbWlnaHQg YmUgYWJsZSB0bw0KPiAgICBwcm92aWRlIG9ubHkgYSBwYXJ0aWN1bGFyIHNlbGVjdGVkIHNldCBv ZiByZXF1aXJlbWVudHMgYW5kIG1pZ2h0IG5vdA0KPiAgICBiZSBjYXBhYmxlIHRvIHByb3ZpZGUg YWxsIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50LiAgT24gdGhlDQo+ICAgIG90aGVyIGhh bmQgYSBkZXZpY2UgdmVuZG9yIG1pZ2h0IHNlbGVjdCBhIHNwZWNpZmljIHJlbGV2YW50IHN1YnNl dCBvZg0KPiAgICB0aGUgcmVxdWlyZW1lbnRzIHRvIGltcGxlbWVudC4NCj4gDQo+IEl0J3MgaGFy ZCB0byBzZWUgaG93IHRoZSBhcHByb2FjaCBkZXNjcmliZWQgYWJvdmUgd2lsbCBjb250cmlidXRl IHRvd2FyZHMNCj4gdXNlZnVsIHN0YW5kYXJkaXphdGlvbi4gVGhlICJyZXF1aXJlbWVudHMiIHNl ZW0gbW9yZSBsaWtlIGEgbGF1bmRyeSBsaXN0DQo+IG9mIGFsbCB0aGUgcHJvcGVydGllcyB0aGF0 IGEgbWFuYWdlbWVudCBhcmNoaXRlY3R1cmUsIG1hbmFnZW1lbnQNCj4gcHJvdG9jb2xzLCBuZXR3 b3JrcyBvZiBjb25zdHJhaW5lZCBkZXZpY2VzLCBhbmQvb3IgaW5kaXZpZHVhbA0KPiBpbXBsZW1l bnRhdGlvbnMgbWlnaHQgZmluZCBkZXNpcmFibGUuDQo+IA0KPiBUaGlzIGFsc28gbWFrZXMgbWUg d29uZGVyIGhvdyB0aGUgV0cgaW50ZW5kcyBmb3IgdGhlc2UgInJlcXVpcmVtZW50cyINCj4gdG8N Cj4gYmUgdXNlZC4gV2hhdCBpcyB0aGUgbmV4dCBzdGVwIGFzIGZhciBhcyBzdGFuZGFyZGl6YXRp b24gZ29lcz8gVG8gZGVzaWduDQo+IHRoZSAibWFuYWdlbWVudCBhcmNoaXRlY3R1cmUiIHRoYXQg aXMgbWVudGlvbmVkPyBPciB0aGUgIm1hbmFnZW1lbnQNCj4gcHJvdG9jb2xzIiB0aGF0IGFyZSBt ZW50aW9uZWQgLS0gb25lIG9yIG1vcmUsIHdvcmtpbmcgdG9nZXRoZXIgb3INCj4gc2VwYXJhdGVs eT8gT3IgdG8gY29uc2lkZXIgaG93IGV4aXN0aW5nIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGNhbiBi ZQ0KPiByZXB1cnBvc2VkIGZvciBjb25zdHJhaW5lZCBuZXR3b3JrcyAod2hpY2ggaXMgc29ydCBv ZiBoaW50ZWQgYXQgaW4NCj4gc2VjdGlvbiAyLCBidXQgbm90IHN0YXRlZCBleHBsaWNpdGx5KSwg dG8gbWVldCBzb21lIHVuZGVmaW5lZCBzdWJzZXQgb2YNCj4gdGhlIGxpc3RlZCAicmVxdWlyZW1l bnRzIj8NCj4gDQo+IEkgdGhpbmsgcHVibGlzaGluZyBhIGxhdW5kcnkgbGlzdCBvZiBkZXNpcmFi bGUgcHJvcGVydGllcyBpcyBvayBpZiBwZW9wbGUNCj4gZmluZCB2YWx1ZSBpbiBpdCwgYnV0IEkn bSBoYXZpbmcgdHJvdWJsZSBzZWVpbmcgaG93IHRoaXMgZG9jdW1lbnQNCj4gc3BlY2lmaWVzIGVp dGhlciBhIHByb2JsZW0gc3RhdGVtZW50IG9yIHJlcXVpcmVtZW50cyB0aGF0IHdpbGwgc29tZWhv dw0KPiBjb250cmlidXRlIHRvIHN0YW5kYXJkaXphdGlvbiBlZmZvcnRzIGluIHRoZSBmdXR1cmUu DQo+IA0KPiANCj4gDQoNCg== From nobody Mon Feb 23 05:11:57 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A88831A1AA0; Mon, 23 Feb 2015 05:11:55 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855FC1A1A97; Mon, 23 Feb 2015 05:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22OjuH-tb4lL; Mon, 23 Feb 2015 05:11:53 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EDE1A1A8F; Mon, 23 Feb 2015 05:11:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkGAHkm61TGmAcV/2dsb2JhbABbgmQiUloEgwStLwEBAQEBAQaSVIVwAhyBBkMBAQEBAQF8hA8BAQEBAxIREUUMBAIBCA0EAQMBAQMCBh0DAgICMBQBAgYIAgQOBQgTB4gNAQyvWIpJmAUBAQEBAQEBAQIBAQEBAQEBAQEBARMEgSGEZoUMhAwRAR8xBwaCYi+BFAWFYolwg16CFoRqgxWCRIw/IoIygTxvgQs5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,630,1418101200"; d="scan'208";a="105154388" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Feb 2015 08:11:51 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 23 Feb 2015 08:11:51 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 23 Feb 2015 08:11:50 -0500 From: "Romascanu, Dan (Dan)" To: Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) Thread-Index: AQHQS9ZCbb+H3Oxo3E6K/tJc6OC49pz+NwVA Date: Mon, 23 Feb 2015 13:11:49 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C9A0A07@AZ-FFEXMB04.global.avaya.com> References: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> In-Reply-To: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "opsawg-chairs@ietf.org" , "opsawg@ietf.org" , "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 13:11:55 -0000 SGkgQWxpc3NhLA0KDQpMZXQgbWUgdHJ5IHRvIGFkZHJlc3MgdGhlIGlzc3VlcyB0aGF0IHlvdSBh cmUgcmFpc2luZy4gVGhlIGNvbWFuIHRlYW0gd29ya2VkIGFzIGEgbm9uLVdHIHRlYW0gZm9yIGFi b3V0IDItMyB5ZWFycywgYW5kIG9ubHkgYXQgdGhlIGxhc3QgcGhhc2Ugb2YgdGhlIHdvcmsgZGVj aWRlZCB0byBzZW5kIHRoZSB0d28gcmVzdWx0aW5nIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIHRv IHRoZSBPUFNBV0cgZm9yIGEgYnJvYWRlciByZXZpZXcgYW5kIGV4cG9zdXJlLCBhdCB0aGUgYWR2 aWNlIG9mIG91ciBBRC4gVGhlIHR3byBkb2N1bWVudHMgYXJlIGluZm9ybWF0aW9uYWwsIG9uZSBk ZXNjcmliZXMgdGhlIHVzZSBjYXNlcyBhbmQgdGhlIHNlY29uZCBvbmUgdGhlIHJlcXVpcmVtZW50 cyBmb3IgdGhlIGJyb2FkZXIgc3BhY2UgZGlzY3Vzc2VkIGJ5IHRoZSB1c2UgY2FzZXMgcmVsYXRl ZCB0byBtYW5hZ2VtZW50IG9mIG5ldHdvcmtzIHdpdGggY29uc3RyYWluZWQgZGV2aWNlcy4uIE9u ZSBvZiB0aGUgY29uY2x1c2lvbnMgb2YgdGhlIHdvcmsgaXMgdGhhdCB3ZSBkbyBub3QgYmVsaWV2 ZSB0aGF0IHRoZXJlIGlzIG9uZSBzaW5nbGUgc29sdXRpb24gdGhhdCB3b3VsZCBmaXQgYWxsIHVz ZSBjYXNlcywgdGhpcyB0aGVyZSBpcyBubyBzaW5nbGUgc2V0IG9mIG1hbmRhdG9yeSByZXF1aXJl bWVudHMgdGhhdCBhcHBseSB0byBhbGwgdGhlIHVzZSBjYXNlcy4gTm8gZm9sbG93LXVwIHdvcmsg aXMgcGxhbm5lZCBpbiBPUFMuIFdlIGZlZWwgaG93ZXZlciB0aGF0IHRoZSB0d28gaW5mb3JtYXRp b25hbCBkb2N1bWVudHMgd2lsbCBiZSB1c2VmdWwgZm9yIGZ1cnRoZXIgcmVmZXJlbmNlIGZvciB0 aGVzZSB0ZWFtcyBvciBXR3MgdGhhdCB0cnkgdG8gYnVpbGQgbWFuYWdlbWVudCBzb2x1dGlvbnMg Zm9yIG9uZSBvciBtb3JlIG9mIHRoZSB1c2UgY2FzZXMuIA0KDQpJbiBvcmRlciB0byBtYWtlIHRo ZSBnb2FscyBvZiB0aGUgZG9jdW1lbnQgbW9yZSBjbGVhciB3ZSBzdWdnZXN0IHRoZSBmb2xsb3dp bmcgZWRpdHM6IA0KDQpJbiBBYnN0cmFjdDogDQoNCk9MRDogDQoNCiAgVGhpcyBkb2N1bWVudCBw cm92aWRlcyBhIHByb2JsZW0gc3RhdGVtZW50LCBkZXBsb3ltZW50IGFuZCBtYW5hZ2VtZW50DQog ICB0b3BvbG9neSBvcHRpb25zIGFzIHdlbGwgYXMgcG90ZW50aWFsIHJlcXVpcmVtZW50cyBmb3Ig dGhlIG1hbmFnZW1lbnQNCiAgIG9mIG5ldHdvcmtzIHdoZXJlIGNvbnN0cmFpbmVkIGRldmljZXMg YXJlIGludm9sdmVkLg0KDQpORVc6IA0KDQogIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBwcm9i bGVtIHN0YXRlbWVudCwgZGVwbG95bWVudCBhbmQgbWFuYWdlbWVudA0KICAgdG9wb2xvZ3kgb3B0 aW9ucyBhcyB3ZWxsIGFzIHJlcXVpcmVtZW50cyBhZGRyZXNzaW5nIHRoZSBkaWZmZXJlbnQgdXNl IGNhc2VzIG9mIA0KICAgdGhlIG1hbmFnZW1lbnQgb2YgbmV0d29ya3Mgd2hlcmUgY29uc3RyYWlu ZWQgZGV2aWNlcyBhcmUgaW52b2x2ZWQuDQoNCkluIFNlY3Rpb24gMS4xOiANCg0KT0xEOiANCg0K ICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIGxpc3RzIHBv dGVudGlhbA0KICAgcmVxdWlyZW1lbnRzIGZvciB0aGUgbWFuYWdlbWVudCBvZiBhIG5ldHdvcmsg d2l0aCBjb25zdHJhaW5lZA0KICAgZGV2aWNlcy4gIFNlY3Rpb24gMS4zIGFuZCBTZWN0aW9uIDEu NSBkZXNjcmliZSBkaWZmZXJlbnQgdG9wb2xvZ3kNCiAgIG9wdGlvbnMgZm9yIHRoZSBuZXR3b3Jr aW5nIGFuZCBtYW5hZ2VtZW50IG9mIGNvbnN0cmFpbmVkIGRldmljZXMuDQogICBTZWN0aW9uIDIg cHJvdmlkZXMgYSBwcm9ibGVtIHN0YXRlbWVudCBvbiB0aGUgaXNzdWUgb2YgdGhlIG1hbmFnZW1l bnQNCiAgIG9mIG5ldHdvcmtlZCBjb25zdHJhaW5lZCBkZXZpY2VzLiAgU2VjdGlvbiAzIGxpc3Rz IHJlcXVpcmVtZW50cyBvbg0KICAgdGhlIG1hbmFnZW1lbnQgb2YgYXBwbGljYXRpb25zIGFuZCBu ZXR3b3JrcyB3aXRoIGNvbnN0cmFpbmVkIGRldmljZXMuDQogICBOb3RlIHRoYXQgdGhlIHJlcXVp cmVtZW50cyBsaXN0ZWQgaW4gU2VjdGlvbiAzIGhhdmUgYmVlbiBzZXBhcmF0ZWQNCiAgIGZyb20g dGhlIGNvbnRleHQgaW4gd2hpY2ggdGhleSBtYXkgYXBwZWFyLiAgRGVwZW5kaW5nIG9uIHRoZSBj b25jcmV0ZQ0KICAgY2lyY3Vtc3RhbmNlcywgYW4gaW1wbGVtZW50ZXIgbWF5IGRlY2lkZSB0byBh ZGRyZXNzIGEgY2VydGFpbg0KICAgcmVsZXZhbnQgc3Vic2V0IG9mIHRoZSByZXF1aXJlbWVudHMu DQoNCiAgIFRoZSB1c2UgY2FzZXMgaW4gdGhlIGNvbnRleHQgb2YgbmV0d29ya3Mgd2l0aCBjb25z dHJhaW5lZCBkZXZpY2VzIGNhbg0KICAgYmUgZm91bmQgaW4gdGhlIGNvbXBhbmlvbiBkb2N1bWVu dCBbQ09NLVVTRV0uDQoNCk5FVzogDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBwcm9i bGVtIHN0YXRlbWVudCBhbmQgbGlzdHMgcmVxdWlyZW1lbnRzIGZvciB0aGUgDQogICBkaWZmZXJl bnQgdXNlIGNhc2VzIG9mIG1hbmFnZW1lbnQgb2YgYSBuZXR3b3JrIHdpdGggY29uc3RyYWluZWQN CiAgIGRldmljZXMuICBTZWN0aW9uIDEuMyBhbmQgU2VjdGlvbiAxLjUgZGVzY3JpYmUgZGlmZmVy ZW50IHRvcG9sb2d5DQogICBvcHRpb25zIGZvciB0aGUgbmV0d29ya2luZyBhbmQgbWFuYWdlbWVu dCBvZiBjb25zdHJhaW5lZCBkZXZpY2VzLg0KICAgU2VjdGlvbiAyIHByb3ZpZGVzIGEgcHJvYmxl bSBzdGF0ZW1lbnQgb24gdGhlIGlzc3VlIG9mIHRoZSBtYW5hZ2VtZW50DQogICBvZiBuZXR3b3Jr ZWQgY29uc3RyYWluZWQgZGV2aWNlcy4gIFNlY3Rpb24gMyBsaXN0cyByZXF1aXJlbWVudHMgb24N CiAgIHRoZSBtYW5hZ2VtZW50IG9mIGFwcGxpY2F0aW9ucyBhbmQgbmV0d29ya3Mgd2l0aCBjb25z dHJhaW5lZCBkZXZpY2VzLg0KICAgTm90ZSB0aGF0IHRoZSByZXF1aXJlbWVudHMgbGlzdGVkIGlu IFNlY3Rpb24gMyBoYXZlIGJlZW4gc2VwYXJhdGVkDQogICBmcm9tIHRoZSBjb250ZXh0IGluIHdo aWNoIHRoZXkgbWF5IGFwcGVhci4gIERlcGVuZGluZyBvbiB0aGUgY29uY3JldGUNCiAgIGNpcmN1 bXN0YW5jZXMsIGFuIGltcGxlbWVudGVyIG1heSBkZWNpZGUgdG8gYWRkcmVzcyBhIGNlcnRhaW4N CiAgIHJlbGV2YW50IHN1YnNldCBvZiB0aGUgcmVxdWlyZW1lbnRzLg0KDQogICBUaGUgdXNlIGNh c2VzIGluIHRoZSBjb250ZXh0IG9mIG5ldHdvcmtzIHdpdGggY29uc3RyYWluZWQgZGV2aWNlcyBj YW4NCiAgIGJlIGZvdW5kIGluIHRoZSBjb21wYW5pb24gZG9jdW1lbnQgW0NPTS1VU0VdLiBUaGlz IGluZm9ybWF0aW9uYWwgDQogICBkb2N1bWVudCBwcm92aWRlcyBhIGxpc3Qgb2Ygb2JqZWN0aXZl cyBmb3IgZGlzY3Vzc2lvbnMgYW5kIGRvZXMgbm90IGFpbSANCiAgIHRvIGJlIGEgc3RyaWN0IHJl cXVpcmVtZW50cyBkb2N1bWVudCBmb3IgYWxsIHVzZSBjYXNlcy4gSW4gZmFjdCwgdGhlcmUgbGlr ZWx5IA0KICAgaXMgbm90IGEgc2luZ2xlIHNvbHV0aW9uIHRoYXQgd29ya3MgZXF1YWxseSB3ZWxs IGZvciBhbGwgdGhlIHVzZSBjYXNlcy4NCg0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxpc3NhIENvb3BlciBb bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTks IDIwMTUgMTo1NSBBTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IG9wc2F3Z0BpZXRmLm9yZzsgd2Fy cmVuQGt1bWFyaS5uZXQ7IGRyYWZ0LWlldGYtb3BzYXdnLWNvbWFuLQ0KPiBwcm9ic3RhdGUtcmVx cy5hbGxAaWV0Zi5vcmc7IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogQWxpc3Nh IENvb3BlcidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vcHNhd2ctY29tYW4tcHJvYnN0YXRlLXJl cXMtDQo+IDA0OiAod2l0aCBESVNDVVNTKQ0KPiANCj4gQWxpc3NhIENvb3BlciBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1vcHNhd2ct Y29tYW4tcHJvYnN0YXRlLXJlcXMtMDQ6IERpc2N1c3MNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFp bA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+ IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtDQo+IDNBX193d3cuaWV0Zi5vcmdfaWVzZ19zdGF0ZW1lbnRfZGlzY3Vzcy0N Cj4gMkRjcml0ZXJpYS5odG1sJmQ9QXdJQ2FRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPUk0 ZHpHeFIzMU9jDQo+IE5YQ0pmUXp2bHNpTFFmdWNCWFJ1Y1B2ZHJwaHBCc0ZBJm09TFJUTGlORDV6 TGxla1dVbXNGb2FWS2prcnVnWg0KPiBNLUtudUFxMHU4Nmh5bVEmcz1lSmpBZC0NCj4gQk9Rekd5 dTloeTFiaEk2dlFJbDd4c0hBV016QkxzUGp3R1ZQVSZlPQ0KPiBmb3IgbW9yZSBpbmZvcm1hdGlv biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRo ZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91 bmQgaGVyZToNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtDQo+IDNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEb3BzYXdn LTJEY29tYW4tDQo+IDJEcHJvYnN0YXRlLQ0KPiAyRHJlcXNfJmQ9QXdJQ2FRJmM9QkZwV1F3OGJz dUtwbDFTZ2laSDY0USZyPUk0ZHpHeFIzMU9jTlhDSmZRDQo+IHp2bHNpTFFmdWNCWFJ1Y1B2ZHJw aHBCc0ZBJm09TFJUTGlORDV6TGxla1dVbXNGb2FWS2prcnVnWk0tDQo+IEtudUFxMHU4Nmh5bVEm cz1LbUVpbTRnRktDVE5LYnJwczJiUXNrUHpubGtyVGhSZy0NCj4gYk8wZ2pUdnhFTSZlPQ0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IEknbSBwdXR0aW5nIHRoaXMgaW4gYXMgYSBESVNDVVNTIGluIHRoZSBldmVudCB0aGF0IHRo ZSBhdXRob3JzL1dHIHdhbnQgdG8NCj4gZGlzY3VzcyBpdCBvciB0aGF0IEknbSBqdXN0IG1pc3Np bmcgc29tZSBjb250ZXh0LCBidXQgSSB3aWxsIGhhcHBpbHkgbW92ZQ0KPiB0byBBQlNUQUlOIGlm IHRoZXJlIGlzIG5vIGFwcGV0aXRlIGZvciBzdWNoIGRpc2N1c3Npb24gLS0gSSBzZWUgbm8gbmVl ZA0KPiB0byBibG9jayB0aGUgZG9jdW1lbnQgZnJvbSBhZHZhbmNpbmcgb24gdGhlIGJhc2lzIG9m IG15IGNvbW1lbnRzLg0KPiANCj4gSXQncyByZWFsbHkgaGFyZCB0byB0ZWxsIGhvdyB0aGUgInJl cXVpcmVtZW50cyIgbGlzdGVkIGluIHRoaXMgZG9jdW1lbnQNCj4gYXJlIGludGVuZGVkIHRvIGJl IHVzZWQuIEluIGZhY3QsIGl0IHNlZW1zIGluY29ycmVjdCB0byBjYWxsIHRoZW0NCj4gInJlcXVp cmVtZW50cyIgYXQgYWxsIC0tIGluIHRoZSBzZW5zZSBvZiBzb21laG93IGJlaW5nICJyZXF1aXJl ZCIgLS0NCj4gZ2l2ZW4gdGhlIGZvbGxvd2luZzoNCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgYSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgbGlzdHMgcG90ZW50aWFsDQo+ICAgIHJlcXVp cmVtZW50cyBmb3IgdGhlIG1hbmFnZW1lbnQgb2YgYSBuZXR3b3JrIHdpdGggY29uc3RyYWluZWQN Cj4gICAgZGV2aWNlcy4gLi4uIERlcGVuZGluZyBvbiB0aGUgY29uY3JldGUNCj4gICAgY2lyY3Vt c3RhbmNlcywgYW4gaW1wbGVtZW50ZXIgbWF5IGRlY2lkZSB0byBhZGRyZXNzIGEgY2VydGFpbg0K PiAgICByZWxldmFudCBzdWJzZXQgb2YgdGhlIHJlcXVpcmVtZW50cy4NCj4gLi4uDQo+ICAgIFRo aXMgZG9jdW1lbnQgaW4gZ2VuZXJhbA0KPiAgICBkb2VzIG5vdCByZWNvbW1lbmQgdGhlIHJlYWxp emF0aW9uIG9mIGFueSBzdWJzZXQgb2YgdGhlIGRlc2NyaWJlZA0KPiAgICByZXF1aXJlbWVudHMu ICBBcyBzdWNoIHRoaXMgZG9jdW1lbnQgYXZvaWRzIHNlbGVjdGluZyBhbnkgb2YgdGhlDQo+ICAg IHJlcXVpcmVtZW50cyBhcyBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LiAgQSBkZXZpY2UgbWlnaHQg YmUgYWJsZSB0bw0KPiAgICBwcm92aWRlIG9ubHkgYSBwYXJ0aWN1bGFyIHNlbGVjdGVkIHNldCBv ZiByZXF1aXJlbWVudHMgYW5kIG1pZ2h0IG5vdA0KPiAgICBiZSBjYXBhYmxlIHRvIHByb3ZpZGUg YWxsIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvY3VtZW50LiAgT24gdGhlDQo+ICAgIG90aGVyIGhh bmQgYSBkZXZpY2UgdmVuZG9yIG1pZ2h0IHNlbGVjdCBhIHNwZWNpZmljIHJlbGV2YW50IHN1YnNl dCBvZg0KPiAgICB0aGUgcmVxdWlyZW1lbnRzIHRvIGltcGxlbWVudC4NCj4gDQo+IEl0J3MgaGFy ZCB0byBzZWUgaG93IHRoZSBhcHByb2FjaCBkZXNjcmliZWQgYWJvdmUgd2lsbCBjb250cmlidXRl IHRvd2FyZHMNCj4gdXNlZnVsIHN0YW5kYXJkaXphdGlvbi4gVGhlICJyZXF1aXJlbWVudHMiIHNl ZW0gbW9yZSBsaWtlIGEgbGF1bmRyeSBsaXN0DQo+IG9mIGFsbCB0aGUgcHJvcGVydGllcyB0aGF0 IGEgbWFuYWdlbWVudCBhcmNoaXRlY3R1cmUsIG1hbmFnZW1lbnQNCj4gcHJvdG9jb2xzLCBuZXR3 b3JrcyBvZiBjb25zdHJhaW5lZCBkZXZpY2VzLCBhbmQvb3IgaW5kaXZpZHVhbA0KPiBpbXBsZW1l bnRhdGlvbnMgbWlnaHQgZmluZCBkZXNpcmFibGUuDQo+IA0KPiBUaGlzIGFsc28gbWFrZXMgbWUg d29uZGVyIGhvdyB0aGUgV0cgaW50ZW5kcyBmb3IgdGhlc2UgInJlcXVpcmVtZW50cyINCj4gdG8N Cj4gYmUgdXNlZC4gV2hhdCBpcyB0aGUgbmV4dCBzdGVwIGFzIGZhciBhcyBzdGFuZGFyZGl6YXRp b24gZ29lcz8gVG8gZGVzaWduDQo+IHRoZSAibWFuYWdlbWVudCBhcmNoaXRlY3R1cmUiIHRoYXQg aXMgbWVudGlvbmVkPyBPciB0aGUgIm1hbmFnZW1lbnQNCj4gcHJvdG9jb2xzIiB0aGF0IGFyZSBt ZW50aW9uZWQgLS0gb25lIG9yIG1vcmUsIHdvcmtpbmcgdG9nZXRoZXIgb3INCj4gc2VwYXJhdGVs eT8gT3IgdG8gY29uc2lkZXIgaG93IGV4aXN0aW5nIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGNhbiBi ZQ0KPiByZXB1cnBvc2VkIGZvciBjb25zdHJhaW5lZCBuZXR3b3JrcyAod2hpY2ggaXMgc29ydCBv ZiBoaW50ZWQgYXQgaW4NCj4gc2VjdGlvbiAyLCBidXQgbm90IHN0YXRlZCBleHBsaWNpdGx5KSwg dG8gbWVldCBzb21lIHVuZGVmaW5lZCBzdWJzZXQgb2YNCj4gdGhlIGxpc3RlZCAicmVxdWlyZW1l bnRzIj8NCj4gDQo+IEkgdGhpbmsgcHVibGlzaGluZyBhIGxhdW5kcnkgbGlzdCBvZiBkZXNpcmFi bGUgcHJvcGVydGllcyBpcyBvayBpZiBwZW9wbGUNCj4gZmluZCB2YWx1ZSBpbiBpdCwgYnV0IEkn bSBoYXZpbmcgdHJvdWJsZSBzZWVpbmcgaG93IHRoaXMgZG9jdW1lbnQNCj4gc3BlY2lmaWVzIGVp dGhlciBhIHByb2JsZW0gc3RhdGVtZW50IG9yIHJlcXVpcmVtZW50cyB0aGF0IHdpbGwgc29tZWhv dw0KPiBjb250cmlidXRlIHRvIHN0YW5kYXJkaXphdGlvbiBlZmZvcnRzIGluIHRoZSBmdXR1cmUu DQo+IA0KPiANCj4gDQoNCg== From nobody Mon Feb 23 13:08:26 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 585701A6F04; Mon, 23 Feb 2015 12:37:28 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371251A6F02; Mon, 23 Feb 2015 12:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUCvtg-jzXZT; Mon, 23 Feb 2015 12:37:25 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5941A3BA6; Mon, 23 Feb 2015 12:37:25 -0800 (PST) Received: by wgha1 with SMTP id a1so1197586wgh.12; Mon, 23 Feb 2015 12:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Lpo5DisLtCVN6LAKHhfnDXMbn4Uyiak1q2t8fa5uIhY=; b=fD5nbKpEy+o9PBbxoAGBWgwS4yOdoWCe0kT2YHQENag67QdcH/GcNt/uCBqintTA5Y 0vVHuoDgiTtUnEuC9BrRKj5GxyqNZQCt9XUP5LNpQraiNKffiioj78Pjsq//86gvSLhZ RQqQEt3fa9H1rV/yZqtHPTN1AYxW/shESG4sWT9bxY0Wc1m5wKg2BwX/w4YXmvhjN6sU fa3PsDa2mbtQxT+Wb/oin/E5v2wP3MUxs7SyyNYf3/+1kTMJrFucqTGcFBde2RQUD9mN VT1qZ+eZ7tO9j+5T35zrparaSl0eWMDfm2L0DcfcIEh2AJIwkvUZVyzd+gedtQ47TDYH 4t+Q== X-Received: by 10.180.14.7 with SMTP id l7mr24432314wic.40.1424723844230; Mon, 23 Feb 2015 12:37:24 -0800 (PST) Received: from Martins-MBP.fritz.box (port-92-202-87-30.dynamic.qsc.de. [92.202.87.30]) by mx.google.com with ESMTPSA id ka1sm57126974wjc.2.2015.02.23.12.37.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 12:37:23 -0800 (PST) Message-ID: <54EB8F82.60001@gmail.com> Date: Mon, 23 Feb 2015 21:37:22 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , The IESG References: <20150217205700.5559.49278.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 23 Feb 2015 13:08:25 -0800 Cc: "opsawg-chairs@ietf.org" , "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 20:37:28 -0000 Hi Mehmet, All your proposed changes looks good, including the change of the Section proposed at the very end of the emails. Thans and schöne Grüße nach München! Martin Am 20.02.15 um 18:46 schrieb Ersue, Mehmet (NSN - DE/Munich): > Hi Martin, > > thank you for your comments. > >> - Req-ID: 10.001: Not sure if this is really a requirement for a >> transport protocol. I would read this as a requirement for the >> implementation of a transport protocol. > > The requirement was not meant to be for a particular transport protocol. > The requirement involves indeed the upper layer with message transport. > A simple example is the use of CoAP avoiding message fragmentation. > > I would like to propose following change: > > s/scalable transport layer/scalable message transport/ > >> - Req-ID: 10.002 says >> Description: Diverse applications need a reliable transport of >> messages. The reliability might be achieved based on a transport >> protocol such as TCP or can be supported based on message >> repetition if an acknowledgment is missing. >> >> Repitition without any limitation on the number of repititions, etc is >> not a feature of a reliable transport protocol. I would remove "or can be >> supported based on message repetition if an acknowledgment is missing". >> Otherwise the text will blow up when you try to specific what features a >> reliable transport protocol should have. > > If we remove the part you meant I think we are losing something. > I would like to suggest to change as following. > > OLD: > The reliability might be achieved based on a transport > protocol such as TCP or can be supported based on message > repetition if an acknowledgment is missing. > NEW: > The reliability might be achieved based on a transport > protocol such as TCP or can be supported using a message > repetition for the message transport. > >> - Req-ID: 10.003: Multicast is not a feature of the transport layer. > > The requirement is leaned on message transport. > > With this may be should also change the subsection title to: > 3.10. Transport layer and Message Transport > > Cheers, > Mehmet > > > -----Original Message----- > From: ext Martin Stiemerling [mailto:mls.ietf@gmail.com] > Sent: Tuesday, February 17, 2015 9:57 PM > To: The IESG > Cc: opsawg@ietf.org; warren@kumari.net; draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org; opsawg-chairs@ietf.org > Subject: Martin Stiemerling's No Objection on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) > > Martin Stiemerling has entered the following ballot position for > draft-ietf-opsawg-coman-probstate-reqs-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > No objection to the publication of this draft, but of course a number of > comments about Section 3.10 on Transport protocols: > > - Req-ID: 10.001: Not sure if this is really a requirement for a > transport protocol. I would read this as a requirement for the > implementation of a transport protocol. > > - Req-ID: 10.002 says > Description: Diverse applications need a reliable transport of > messages. The reliability might be achieved based on a transport > protocol such as TCP or can be supported based on message > repetition if an acknowledgment is missing. > > Repitition without any limitation on the number of repititions, etc is > not a feature of a reliable transport protocol. I would remove "or can be > supported based on message repetition if an acknowledgment is missing". > Otherwise the text will blow up when you try to specific what features a > reliable transport protocol should have. > > - Req-ID: 10.003: Multicast is not a feature of the transport layer. > > From nobody Tue Feb 24 05:51:28 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABF01A1A82; Tue, 24 Feb 2015 05:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxMPrzGgc5n1; Tue, 24 Feb 2015 05:51:23 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A741A0378; Tue, 24 Feb 2015 05:51:23 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C640B734; Tue, 24 Feb 2015 14:51:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cWaFvUO8Djsx; Tue, 24 Feb 2015 14:51:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Feb 2015 14:51:20 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DE6520036; Tue, 24 Feb 2015 14:51:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qmuvMtRHY0ZJ; Tue, 24 Feb 2015 14:51:18 +0100 (CET) Received: from exchange.jacobs-university.de (shubcas03.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 8E36620031; Tue, 24 Feb 2015 14:51:17 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 14:51:17 +0100 From: "Sehgal, Anuj" To: ext Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) Thread-Index: AQHQTFsqtesxW4DlN02d4UBGqHidrJz/yHEA Date: Tue, 24 Feb 2015 13:51:17 +0000 Message-ID: <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> References: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> In-Reply-To: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.244.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-coman-use-cases.all@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 13:51:26 -0000 Hi, The following inline comments are an overview of the actions taken to resolve the issues raised by Kathleen and Ted. > On 19 Feb 2015, at 4:43 pm, ext Kathleen Moriarty wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft, I just have some security stuff I'd > like to discuss that should be easy to resolve as some text is provided. >=20 > In section 4.5, it is critical to also include a statement on security in > addition to privacy. Medical devices with network attachments could be > used to kill someone. > http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justifi= ed-experts/story?id=3D20633284 >=20 > Suggest changing this text from: > In both cases, however, > it is crucial to protect the privacy of the people to which medical > devices are attached. Even though the data collected by a heart beat > monitor might be protected, the pure fact that someone carries such a > device may need protection. As such, certain medical appliances may > not want to participate in discovery and self-configuration protocols > in order to remain invisible. > To: > In both cases, however, > it is crucial to protect the safety and privacy of the people to which > medical > devices are attached. Security precautions to protect access > (authentication, encryption, integrity protections, etc.) to such devices > may be critical to protecting the safety of the individual. Even though > the data collected by a heart beat > monitor might be protected, the pure fact that someone carries such a > device may need protection. As such, certain medical appliances may > not want to participate in discovery and self-configuration protocols > in order to remain invisible. Adopted text in Section 4.5 - Medical Applications. > General statement: > Many of the other use case scenarios also have safety as a concern, > requiring security protections (Confidentiality, Integrity, > Availability). Sensors used to control environmental settings is another > example where air regulation might include detection of harmful things in > the air (carbon monoxide). I'm sure there are other safety concerns that > motivate security protections in each of the use cases, it's not just > privacy (which is important). What if a sensor was tampered with to > report or not report something detected? That's not covered in the > discussion on availability related problems in 4.6, but does represent > another set of security considerations that could lead to safety issues. > More text on access control considerations for NMS may help. I propose adding the following text to the respective sections. Section 4.1 - Environmental Monitoring Since many applications of environmental monitoring sensors are likely to be in areas that are important to safety (flood monitoring, nuclear radiation monitoring, etc.) it is important for management protocols and network management systems (NMS) to ensure appropriate security protections that ensure not only access control, integrity and availability of data, but also provide appropriate mechanisms that can deal with situations that might be categorized as emergencies or when tampering with sensors/data might be detected. Section 4.2 - Infrastructure Monitoring Since infrastructure monitoring is closely related to ensuring safety,=09 management protocols and systems must provide appropriate security=09 protections to ensure confidentiality, integrity and availability of=09 data. Section 4.3 - Industrial Applications Management protocols and NMSs must ensure appropriate access control since different users of industrial control systems will have varying levels of permissions. E.g., while supervisors might be allowed to change production parameters, they should not be allowed to modify the functional configuration of devices like a technician should. It is also important to ensure integrity and availability of data since malfunctions can potentially become safety issues. This also implies that management systems must be able to react to situations that may pose dangers to worker safety. Section 4.5 - Medical Applications In both cases, however, it is crucial to protect the safety and privacy of the people to which medical devices are attached. Security precautions to protect access (authentication, encryption, integrity protections, etc.) to such devices may be critical to safeguarding the individual. The level of access granted to different users also may need to be regulated. For example, an authorized surgeon or doctor must be allowed to configure all necessary options on the devices, however, a nurse or technician may only be allowed to retrieve data that can assist in diagnosis. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. Section 4.6 - Building Automation It is also important for a building automation NMS to take safety and security into account. Ensuring privacy and confidentiality of data, such that unauthorized parties do not get access to it, is likely to be important since users' individual behaviors could be potentially understood via their settings. Appropriate security considerations for authorization and access control to the NMS is also important since different users are likely to have varied levels of operational permissions in the system. E.g., while end users should be able to control lighting systems, HVACs, etc., only qualified technicians should be able to configure parameters that change the fundamental operation of a device. It is also important for devices and the NMS to be able to detect and report any tampering they might detect, since these could lead to potential user safety concerns, e.g., if sensors controlling air quality are tampered with such that the levels of Carbon Monoxide become life threatening. This implies that a NMS should also be able to deal with and appropriately prioritize situations that might potentially lead to safety concerns. Section 4.8 - Transport Applications Since transport applications of the constrained devices and networks deal with automotive vehicles, malfunctions and misuse can potentially lead to safety concerns as well. As such, besides access control, privacy of user data and timeliness management systems should also be able to detect situations that are potentially hazardous to safety. Some of these situations could be automatically mitigated, e.g., traffic lights with incorrect timing, but others might require human intervention, e.g., failed traffic lights. The management system should take appropriate actions in these situations. Maintaining data confidentiality and integrity is also an important security aspect of a management system since tampering (or malfunction) can also lead to potentially dangerous situations. Hopefully this text is enough to resolve these issues. Regards, Anuj From nobody Tue Feb 24 05:51:32 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 691531A1B28; Tue, 24 Feb 2015 05:51:26 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABF01A1A82; Tue, 24 Feb 2015 05:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxMPrzGgc5n1; Tue, 24 Feb 2015 05:51:23 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A741A0378; Tue, 24 Feb 2015 05:51:23 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C640B734; Tue, 24 Feb 2015 14:51:21 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cWaFvUO8Djsx; Tue, 24 Feb 2015 14:51:12 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Feb 2015 14:51:20 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DE6520036; Tue, 24 Feb 2015 14:51:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qmuvMtRHY0ZJ; Tue, 24 Feb 2015 14:51:18 +0100 (CET) Received: from exchange.jacobs-university.de (shubcas03.jacobs.jacobs-university.de [10.70.0.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 8E36620031; Tue, 24 Feb 2015 14:51:17 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS05.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 14:51:17 +0100 From: "Sehgal, Anuj" To: ext Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) Thread-Index: AQHQTFsqtesxW4DlN02d4UBGqHidrJz/yHEA Date: Tue, 24 Feb 2015 13:51:17 +0000 Message-ID: <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> References: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> In-Reply-To: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.244.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-coman-use-cases.all@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 13:51:26 -0000 Hi, The following inline comments are an overview of the actions taken to resolve the issues raised by Kathleen and Ted. > On 19 Feb 2015, at 4:43 pm, ext Kathleen Moriarty wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for your work on this draft, I just have some security stuff I'd > like to discuss that should be easy to resolve as some text is provided. >=20 > In section 4.5, it is critical to also include a statement on security in > addition to privacy. Medical devices with network attachments could be > used to kill someone. > http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justifi= ed-experts/story?id=3D20633284 >=20 > Suggest changing this text from: > In both cases, however, > it is crucial to protect the privacy of the people to which medical > devices are attached. Even though the data collected by a heart beat > monitor might be protected, the pure fact that someone carries such a > device may need protection. As such, certain medical appliances may > not want to participate in discovery and self-configuration protocols > in order to remain invisible. > To: > In both cases, however, > it is crucial to protect the safety and privacy of the people to which > medical > devices are attached. Security precautions to protect access > (authentication, encryption, integrity protections, etc.) to such devices > may be critical to protecting the safety of the individual. Even though > the data collected by a heart beat > monitor might be protected, the pure fact that someone carries such a > device may need protection. As such, certain medical appliances may > not want to participate in discovery and self-configuration protocols > in order to remain invisible. Adopted text in Section 4.5 - Medical Applications. > General statement: > Many of the other use case scenarios also have safety as a concern, > requiring security protections (Confidentiality, Integrity, > Availability). Sensors used to control environmental settings is another > example where air regulation might include detection of harmful things in > the air (carbon monoxide). I'm sure there are other safety concerns that > motivate security protections in each of the use cases, it's not just > privacy (which is important). What if a sensor was tampered with to > report or not report something detected? That's not covered in the > discussion on availability related problems in 4.6, but does represent > another set of security considerations that could lead to safety issues. > More text on access control considerations for NMS may help. I propose adding the following text to the respective sections. Section 4.1 - Environmental Monitoring Since many applications of environmental monitoring sensors are likely to be in areas that are important to safety (flood monitoring, nuclear radiation monitoring, etc.) it is important for management protocols and network management systems (NMS) to ensure appropriate security protections that ensure not only access control, integrity and availability of data, but also provide appropriate mechanisms that can deal with situations that might be categorized as emergencies or when tampering with sensors/data might be detected. Section 4.2 - Infrastructure Monitoring Since infrastructure monitoring is closely related to ensuring safety,=09 management protocols and systems must provide appropriate security=09 protections to ensure confidentiality, integrity and availability of=09 data. Section 4.3 - Industrial Applications Management protocols and NMSs must ensure appropriate access control since different users of industrial control systems will have varying levels of permissions. E.g., while supervisors might be allowed to change production parameters, they should not be allowed to modify the functional configuration of devices like a technician should. It is also important to ensure integrity and availability of data since malfunctions can potentially become safety issues. This also implies that management systems must be able to react to situations that may pose dangers to worker safety. Section 4.5 - Medical Applications In both cases, however, it is crucial to protect the safety and privacy of the people to which medical devices are attached. Security precautions to protect access (authentication, encryption, integrity protections, etc.) to such devices may be critical to safeguarding the individual. The level of access granted to different users also may need to be regulated. For example, an authorized surgeon or doctor must be allowed to configure all necessary options on the devices, however, a nurse or technician may only be allowed to retrieve data that can assist in diagnosis. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. Section 4.6 - Building Automation It is also important for a building automation NMS to take safety and security into account. Ensuring privacy and confidentiality of data, such that unauthorized parties do not get access to it, is likely to be important since users' individual behaviors could be potentially understood via their settings. Appropriate security considerations for authorization and access control to the NMS is also important since different users are likely to have varied levels of operational permissions in the system. E.g., while end users should be able to control lighting systems, HVACs, etc., only qualified technicians should be able to configure parameters that change the fundamental operation of a device. It is also important for devices and the NMS to be able to detect and report any tampering they might detect, since these could lead to potential user safety concerns, e.g., if sensors controlling air quality are tampered with such that the levels of Carbon Monoxide become life threatening. This implies that a NMS should also be able to deal with and appropriately prioritize situations that might potentially lead to safety concerns. Section 4.8 - Transport Applications Since transport applications of the constrained devices and networks deal with automotive vehicles, malfunctions and misuse can potentially lead to safety concerns as well. As such, besides access control, privacy of user data and timeliness management systems should also be able to detect situations that are potentially hazardous to safety. Some of these situations could be automatically mitigated, e.g., traffic lights with incorrect timing, but others might require human intervention, e.g., failed traffic lights. The management system should take appropriate actions in these situations. Maintaining data confidentiality and integrity is also an important security aspect of a management system since tampering (or malfunction) can also lead to potentially dangerous situations. Hopefully this text is enough to resolve these issues. Regards, Anuj From nobody Tue Feb 24 06:35:33 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5BC1A1B28; Tue, 24 Feb 2015 06:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g79P6i5UFEFG; Tue, 24 Feb 2015 06:35:27 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F281A0203; Tue, 24 Feb 2015 06:35:27 -0800 (PST) Received: by lbiz12 with SMTP id z12so25040224lbi.11; Tue, 24 Feb 2015 06:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=plukhzTzuU5YYKKZPYaJvNb/IcIVcn5HTszKzqZPpbs=; b=cPNOVPyA9w5gfsRSNSyX9Zo/ID3rWKFuN8o8F+dXPNnjBESG1j7UuQnPju4VES0SLF huvyjY0xMNEGWjR2g20fo90zBFdJfh7PpAQ5qNP2MIngoSEy88VT/4/Rt7CoBV64ML6h pNrOAZ0hE8e5QT8LQwzeLQ+zC5ktZ4UZ7AP0aAFJFKuUyEmS/PmIDvgCt9j7QypMnuNT ItxWEYnjns2+5RQlfMvjvVOL0fjiDgWmpSz4yrYu8MQ35I0X+DDvHA/if20MllKs1t2o 4JYXy+8AiiQJ3VZdH9HpczxVDE4ZFJsU6Zv0EObioNxFOol3uZWnOOUMBHzYVgN76WLH RAVQ== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr14609970lbb.4.1424788525576; Tue, 24 Feb 2015 06:35:25 -0800 (PST) Received: by 10.112.167.101 with HTTP; Tue, 24 Feb 2015 06:35:25 -0800 (PST) In-Reply-To: <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> References: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> Date: Tue, 24 Feb 2015 09:35:25 -0500 Message-ID: From: Kathleen Moriarty To: "Sehgal, Anuj" Content-Type: multipart/alternative; boundary=001a11345b12f2778f050fd66d1f Archived-At: Cc: "draft-ietf-opsawg-coman-use-cases.all@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 14:35:31 -0000 --001a11345b12f2778f050fd66d1f Content-Type: text/plain; charset=UTF-8 Hello, Thank you for taking to time to add in the additional text, this hits the points needed and addresses my discuss. One of the sections has a run-on sentence, so I'll try to help fix that below. Please let me know when the updates are made and I will clear my discuss. On Tue, Feb 24, 2015 at 8:51 AM, Sehgal, Anuj wrote: > Hi, > > The following inline comments are an overview of the actions taken > to resolve the issues raised by Kathleen and Ted. > > > On 19 Feb 2015, at 4:43 pm, ext Kathleen Moriarty < > Kathleen.Moriarty.ietf@gmail.com> wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for your work on this draft, I just have some security stuff I'd > > like to discuss that should be easy to resolve as some text is provided. > > > > In section 4.5, it is critical to also include a statement on security in > > addition to privacy. Medical devices with network attachments could be > > used to kill someone. > > > http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/story?id=20633284 > > > > Suggest changing this text from: > > In both cases, however, > > it is crucial to protect the privacy of the people to which medical > > devices are attached. Even though the data collected by a heart beat > > monitor might be protected, the pure fact that someone carries such a > > device may need protection. As such, certain medical appliances may > > not want to participate in discovery and self-configuration protocols > > in order to remain invisible. > > To: > > In both cases, however, > > it is crucial to protect the safety and privacy of the people to which > > medical > > devices are attached. Security precautions to protect access > > (authentication, encryption, integrity protections, etc.) to such devices > > may be critical to protecting the safety of the individual. Even though > > the data collected by a heart beat > > monitor might be protected, the pure fact that someone carries such a > > device may need protection. As such, certain medical appliances may > > not want to participate in discovery and self-configuration protocols > > in order to remain invisible. > > Adopted text in Section 4.5 - Medical Applications. > > > General statement: > > Many of the other use case scenarios also have safety as a concern, > > requiring security protections (Confidentiality, Integrity, > > Availability). Sensors used to control environmental settings is another > > example where air regulation might include detection of harmful things in > > the air (carbon monoxide). I'm sure there are other safety concerns that > > motivate security protections in each of the use cases, it's not just > > privacy (which is important). What if a sensor was tampered with to > > report or not report something detected? That's not covered in the > > discussion on availability related problems in 4.6, but does represent > > another set of security considerations that could lead to safety issues. > > More text on access control considerations for NMS may help. > > I propose adding the following text to the respective sections. > > Section 4.1 - Environmental Monitoring > > Since many applications of environmental monitoring sensors are likely > to be in areas that are important to safety (flood monitoring, nuclear > radiation monitoring, etc.) it is important for management protocols > and network management systems (NMS) to ensure appropriate security > protections. These protections include > not only access control, integrity and > availability of data, but also provide appropriate mechanisms that can > deal with situations that might be categorized as emergencies or when > tampering with sensors/data might be detected. > > Section 4.2 - Infrastructure Monitoring > > Since infrastructure monitoring is closely related to ensuring safety, > management protocols and systems must provide appropriate security > protections to ensure confidentiality, integrity and availability of > data. > > Section 4.3 - Industrial Applications > > Management protocols and NMSs must ensure appropriate access control > since different users of industrial control systems will have varying > levels of permissions. E.g., while supervisors might be allowed to > change production parameters, they should not be allowed to modify the > functional configuration of devices like a technician should. It is > also important to ensure integrity and availability of data since > malfunctions can potentially become safety issues. This also implies > that management systems must be able to react to situations that may > pose dangers to worker safety. > > Section 4.5 - Medical Applications > > In both cases, however, it is crucial to protect the safety and > privacy of the people to which medical devices are attached. Security > precautions to protect access (authentication, encryption, integrity > protections, etc.) to such devices may be critical to safeguarding the > individual. The level of access granted to different users also may > need to be regulated. For example, an authorized surgeon or doctor > must be allowed to configure all necessary options on the devices, > however, a nurse or technician may only be allowed to retrieve data > that can assist in diagnosis. Even though the data collected by a > heart beat monitor might be protected, the pure fact that someone > carries such a device may need protection. As such, certain medical > appliances may not want to participate in discovery and > self-configuration protocols in order to remain invisible. > > Section 4.6 - Building Automation > > It is also important for a building automation NMS to take safety and > security into account. Ensuring privacy and confidentiality of data, > such that unauthorized parties do not get access to it, is likely to > be important since users' individual behaviors could be potentially > understood via their settings. Appropriate security considerations > for authorization and access control to the NMS is also important > since different users are likely to have varied levels of operational > permissions in the system. E.g., while end users should be able to > control lighting systems, HVACs, etc., only qualified technicians > should be able to configure parameters that change the fundamental > operation of a device. It is also important for devices and the NMS > to be able to detect and report any tampering they might detect, since > these could lead to potential user safety concerns, e.g., if sensors > controlling air quality are tampered with such that the levels of > Carbon Monoxide become life threatening. This implies that a NMS > should also be able to deal with and appropriately prioritize > situations that might potentially lead to safety concerns. > > Section 4.8 - Transport Applications > > Since transport applications of the constrained devices and networks > deal with automotive vehicles, malfunctions and misuse can potentially > lead to safety concerns as well. As such, besides access control, > privacy of user data and timeliness management systems should also be > able to detect situations that are potentially hazardous to safety. > Some of these situations could be automatically mitigated, e.g., > traffic lights with incorrect timing, but others might require human > intervention, e.g., failed traffic lights. The management system > should take appropriate actions in these situations. Maintaining data > confidentiality and integrity is also an important security aspect of > a management system since tampering (or malfunction) can also lead to > potentially dangerous situations. > > > > Hopefully this text is enough to resolve these issues. > Yes, thank you! Kathleen > > Regards, > Anuj > > -- Best regards, Kathleen --001a11345b12f2778f050fd66d1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thank you for taking to time to = add in the additional text, this hits the points needed and addresses my di= scuss.=C2=A0 One of the sections has a run-on sentence, so I'll try to = help fix that below.=C2=A0 Please let me know when the updates are made and= I will clear my discuss.

On Tue, Feb 24, 2015 at 8:51 AM, Sehgal, Anuj <s.a= nuj@jacobs-university.de> wrote:
Hi,

The following inline comments are an overview of the actions taken
to resolve the issues raised by Kathleen and Ted.

> On 19 Feb 2015, at 4:43 pm, ext Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>= ; wrote:
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Thanks for your work on this draft, I just have some security stuff I&= #39;d
> like to discuss that should be easy to resolve as some text is provide= d.
>
> In section 4.5, it is critical to also include a statement on security= in
> addition to privacy.=C2=A0 Medical devices with network attachments co= uld be
> used to kill someone.
> http://abcn= ews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/st= ory?id=3D20633284
>
> Suggest changing this text from:
>=C2=A0 =C2=A0In both cases, however,
>=C2=A0 =C2=A0it is crucial to protect the privacy of the people to whic= h medical
>=C2=A0 =C2=A0devices are attached.=C2=A0 Even though the data collected= by a heart beat
>=C2=A0 =C2=A0monitor might be protected, the pure fact that someone car= ries such a
>=C2=A0 =C2=A0device may need protection.=C2=A0 As such, certain medical= appliances may
>=C2=A0 =C2=A0not want to participate in discovery and self-configuratio= n protocols
>=C2=A0 =C2=A0in order to remain invisible.
> To:
>=C2=A0 =C2=A0In both cases, however,
>=C2=A0 =C2=A0it is crucial to protect the safety and privacy of the peo= ple to which
> medical
>=C2=A0 =C2=A0devices are attached.=C2=A0 Security precautions to protec= t access
> (authentication, encryption, integrity protections, etc.) to such devi= ces
> may be critical to protecting the safety of the individual. Even thoug= h
> the data collected by a heart beat
>=C2=A0 =C2=A0monitor might be protected, the pure fact that someone car= ries such a
>=C2=A0 =C2=A0device may need protection.=C2=A0 As such, certain medical= appliances may
>=C2=A0 =C2=A0not want to participate in discovery and self-configuratio= n protocols
>=C2=A0 =C2=A0in order to remain invisible.

Adopted text in Section 4.5 - Medical Applications.

> General statement:
> Many of the other use case scenarios also have safety as a concern, > requiring security protections (Confidentiality, Integrity,
> Availability).=C2=A0 Sensors used to control environmental settings is= another
> example where air regulation might include detection of harmful things= in
> the air (carbon monoxide).=C2=A0 I'm sure there are other safety c= oncerns that
> motivate security protections in each of the use cases, it's not j= ust
> privacy (which is important).=C2=A0 What if a sensor was tampered with= to
> report or not report something detected?=C2=A0 That's not covered = in the
> discussion on availability related problems in 4.6, but does represent=
> another set of security considerations that could lead to safety issue= s.
> More text on access control considerations for NMS may help.

I propose adding the following text to the respective sections.

Section 4.1 - Environmental Monitoring

Since many applications of environmental monitoring sensors are likely
to be in areas that are important to safety (flood monitoring, nuclear
radiation monitoring, etc.) it is important for management protocols
and network management systems (NMS) to ensure appropriate security
protections.
These protections include=C2=A0
=C2=A0not only access control, integrity and
availability of data, but also provide appropriate mechanisms that can
deal with situations that might be categorized as emergencies or when
tampering with sensors/data might be detected.

Section 4.2 - Infrastructure Monitoring

Since infrastructure monitoring is closely related to ensuring safety,
management protocols and systems must provide appropriate security
protections to ensure confidentiality, integrity and availability of
data.

Section 4.3 - Industrial Applications

Management protocols and NMSs must ensure appropriate access control
since different users of industrial control systems will have varying
levels of permissions.=C2=A0 E.g., while supervisors might be allowed to change production parameters, they should not be allowed to modify the
functional configuration of devices like a technician should.=C2=A0 It is also important to ensure integrity and availability of data since
malfunctions can potentially become safety issues.=C2=A0 This also implies<= br> that management systems must be able to react to situations that may
pose dangers to worker safety.

Section 4.5 - Medical Applications

In both cases, however, it is crucial to protect the safety and
privacy of the people to which medical devices are attached. Security
precautions to protect access (authentication, encryption, integrity
protections, etc.) to such devices may be critical to safeguarding t= he
individual. The level of access granted to different users also may
need to be regulated. For example, an authorized surgeon or doctor
must be allowed to configure all necessary options on the devices,
however, a nurse or technician may only be allowed to retrieve data
that can assist in diagnosis. Even though the data collected by a
heart beat monitor might be protected, the pure fact that = someone
carries such a device may need protection. As such, certain medical
appliances may not want to participate in discovery and
self-configuration protocols in order to remain invisible.

Section 4.6 - Building Automation

It is also important for a building automation NMS to take safety and
security into account.=C2=A0 Ensuring privacy and confidentiality of data,<= br> such that unauthorized parties do not get access to it, is likely to
be important since users' individual behaviors could be potentially
understood via their settings.=C2=A0 Appropriate security considerations for authorization and access control to the NMS is also important
since different users are likely to have varied levels of operational
permissions in the system.=C2=A0 E.g., while end users should be able to control lighting systems, HVACs, etc., only qualified technicians
should be able to configure parameters that change the fundamental
operation of a device.=C2=A0 It is also important for devices and the NMS to be able to detect and report any tampering they might detect, since
these could lead to potential user safety concerns, e.g., if sensors
controlling air quality are tampered with such that the levels of
Carbon Monoxide become life threatening.=C2=A0 This implies that a NMS
should also be able to deal with and appropriately prioritize
situations that might potentially lead to safety concerns.

Section 4.8 - Transport Applications

Since transport applications of the constrained devices and networks
deal with automotive vehicles, malfunctions and misuse can potentially
lead to safety concerns as well.=C2=A0 As such, besides access control,
privacy of user data and timeliness management systems should also be
able to detect situations that are potentially hazardous to safety.
Some of these situations could be automatically mitigated, e.g.,
traffic lights with incorrect timing, but others might require human
intervention, e.g., failed traffic lights.=C2=A0 The management system
should take appropriate actions in these situations.=C2=A0 Maintaining data=
confidentiality and integrity is also an important security aspect of
a management system since tampering (or malfunction) can also lead to
potentially dangerous situations.



Hopefully this text is enough to resolve these issues.

Yes, thank you!
Kathleen=C2=A0

Regards,
Anuj




--

Best regards,
Kath= leen
--001a11345b12f2778f050fd66d1f-- From nobody Tue Feb 24 06:35:44 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 70F6E1A0203; Tue, 24 Feb 2015 06:35:31 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5BC1A1B28; Tue, 24 Feb 2015 06:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g79P6i5UFEFG; Tue, 24 Feb 2015 06:35:27 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F281A0203; Tue, 24 Feb 2015 06:35:27 -0800 (PST) Received: by lbiz12 with SMTP id z12so25040224lbi.11; Tue, 24 Feb 2015 06:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=plukhzTzuU5YYKKZPYaJvNb/IcIVcn5HTszKzqZPpbs=; b=cPNOVPyA9w5gfsRSNSyX9Zo/ID3rWKFuN8o8F+dXPNnjBESG1j7UuQnPju4VES0SLF huvyjY0xMNEGWjR2g20fo90zBFdJfh7PpAQ5qNP2MIngoSEy88VT/4/Rt7CoBV64ML6h pNrOAZ0hE8e5QT8LQwzeLQ+zC5ktZ4UZ7AP0aAFJFKuUyEmS/PmIDvgCt9j7QypMnuNT ItxWEYnjns2+5RQlfMvjvVOL0fjiDgWmpSz4yrYu8MQ35I0X+DDvHA/if20MllKs1t2o 4JYXy+8AiiQJ3VZdH9HpczxVDE4ZFJsU6Zv0EObioNxFOol3uZWnOOUMBHzYVgN76WLH RAVQ== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr14609970lbb.4.1424788525576; Tue, 24 Feb 2015 06:35:25 -0800 (PST) Received: by 10.112.167.101 with HTTP; Tue, 24 Feb 2015 06:35:25 -0800 (PST) In-Reply-To: <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> References: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> Date: Tue, 24 Feb 2015 09:35:25 -0500 Message-ID: From: Kathleen Moriarty To: "Sehgal, Anuj" Content-Type: multipart/alternative; boundary=001a11345b12f2778f050fd66d1f Archived-At: Cc: "draft-ietf-opsawg-coman-use-cases.all@ietf.org" , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" , "ted.lemon@nominum.com" Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 14:35:31 -0000 --001a11345b12f2778f050fd66d1f Content-Type: text/plain; charset=UTF-8 Hello, Thank you for taking to time to add in the additional text, this hits the points needed and addresses my discuss. One of the sections has a run-on sentence, so I'll try to help fix that below. Please let me know when the updates are made and I will clear my discuss. On Tue, Feb 24, 2015 at 8:51 AM, Sehgal, Anuj wrote: > Hi, > > The following inline comments are an overview of the actions taken > to resolve the issues raised by Kathleen and Ted. > > > On 19 Feb 2015, at 4:43 pm, ext Kathleen Moriarty < > Kathleen.Moriarty.ietf@gmail.com> wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for your work on this draft, I just have some security stuff I'd > > like to discuss that should be easy to resolve as some text is provided. > > > > In section 4.5, it is critical to also include a statement on security in > > addition to privacy. Medical devices with network attachments could be > > used to kill someone. > > > http://abcnews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/story?id=20633284 > > > > Suggest changing this text from: > > In both cases, however, > > it is crucial to protect the privacy of the people to which medical > > devices are attached. Even though the data collected by a heart beat > > monitor might be protected, the pure fact that someone carries such a > > device may need protection. As such, certain medical appliances may > > not want to participate in discovery and self-configuration protocols > > in order to remain invisible. > > To: > > In both cases, however, > > it is crucial to protect the safety and privacy of the people to which > > medical > > devices are attached. Security precautions to protect access > > (authentication, encryption, integrity protections, etc.) to such devices > > may be critical to protecting the safety of the individual. Even though > > the data collected by a heart beat > > monitor might be protected, the pure fact that someone carries such a > > device may need protection. As such, certain medical appliances may > > not want to participate in discovery and self-configuration protocols > > in order to remain invisible. > > Adopted text in Section 4.5 - Medical Applications. > > > General statement: > > Many of the other use case scenarios also have safety as a concern, > > requiring security protections (Confidentiality, Integrity, > > Availability). Sensors used to control environmental settings is another > > example where air regulation might include detection of harmful things in > > the air (carbon monoxide). I'm sure there are other safety concerns that > > motivate security protections in each of the use cases, it's not just > > privacy (which is important). What if a sensor was tampered with to > > report or not report something detected? That's not covered in the > > discussion on availability related problems in 4.6, but does represent > > another set of security considerations that could lead to safety issues. > > More text on access control considerations for NMS may help. > > I propose adding the following text to the respective sections. > > Section 4.1 - Environmental Monitoring > > Since many applications of environmental monitoring sensors are likely > to be in areas that are important to safety (flood monitoring, nuclear > radiation monitoring, etc.) it is important for management protocols > and network management systems (NMS) to ensure appropriate security > protections. These protections include > not only access control, integrity and > availability of data, but also provide appropriate mechanisms that can > deal with situations that might be categorized as emergencies or when > tampering with sensors/data might be detected. > > Section 4.2 - Infrastructure Monitoring > > Since infrastructure monitoring is closely related to ensuring safety, > management protocols and systems must provide appropriate security > protections to ensure confidentiality, integrity and availability of > data. > > Section 4.3 - Industrial Applications > > Management protocols and NMSs must ensure appropriate access control > since different users of industrial control systems will have varying > levels of permissions. E.g., while supervisors might be allowed to > change production parameters, they should not be allowed to modify the > functional configuration of devices like a technician should. It is > also important to ensure integrity and availability of data since > malfunctions can potentially become safety issues. This also implies > that management systems must be able to react to situations that may > pose dangers to worker safety. > > Section 4.5 - Medical Applications > > In both cases, however, it is crucial to protect the safety and > privacy of the people to which medical devices are attached. Security > precautions to protect access (authentication, encryption, integrity > protections, etc.) to such devices may be critical to safeguarding the > individual. The level of access granted to different users also may > need to be regulated. For example, an authorized surgeon or doctor > must be allowed to configure all necessary options on the devices, > however, a nurse or technician may only be allowed to retrieve data > that can assist in diagnosis. Even though the data collected by a > heart beat monitor might be protected, the pure fact that someone > carries such a device may need protection. As such, certain medical > appliances may not want to participate in discovery and > self-configuration protocols in order to remain invisible. > > Section 4.6 - Building Automation > > It is also important for a building automation NMS to take safety and > security into account. Ensuring privacy and confidentiality of data, > such that unauthorized parties do not get access to it, is likely to > be important since users' individual behaviors could be potentially > understood via their settings. Appropriate security considerations > for authorization and access control to the NMS is also important > since different users are likely to have varied levels of operational > permissions in the system. E.g., while end users should be able to > control lighting systems, HVACs, etc., only qualified technicians > should be able to configure parameters that change the fundamental > operation of a device. It is also important for devices and the NMS > to be able to detect and report any tampering they might detect, since > these could lead to potential user safety concerns, e.g., if sensors > controlling air quality are tampered with such that the levels of > Carbon Monoxide become life threatening. This implies that a NMS > should also be able to deal with and appropriately prioritize > situations that might potentially lead to safety concerns. > > Section 4.8 - Transport Applications > > Since transport applications of the constrained devices and networks > deal with automotive vehicles, malfunctions and misuse can potentially > lead to safety concerns as well. As such, besides access control, > privacy of user data and timeliness management systems should also be > able to detect situations that are potentially hazardous to safety. > Some of these situations could be automatically mitigated, e.g., > traffic lights with incorrect timing, but others might require human > intervention, e.g., failed traffic lights. The management system > should take appropriate actions in these situations. Maintaining data > confidentiality and integrity is also an important security aspect of > a management system since tampering (or malfunction) can also lead to > potentially dangerous situations. > > > > Hopefully this text is enough to resolve these issues. > Yes, thank you! Kathleen > > Regards, > Anuj > > -- Best regards, Kathleen --001a11345b12f2778f050fd66d1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thank you for taking to time to = add in the additional text, this hits the points needed and addresses my di= scuss.=C2=A0 One of the sections has a run-on sentence, so I'll try to = help fix that below.=C2=A0 Please let me know when the updates are made and= I will clear my discuss.

On Tue, Feb 24, 2015 at 8:51 AM, Sehgal, Anuj <s.a= nuj@jacobs-university.de> wrote:
Hi,

The following inline comments are an overview of the actions taken
to resolve the issues raised by Kathleen and Ted.

> On 19 Feb 2015, at 4:43 pm, ext Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>= ; wrote:
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Thanks for your work on this draft, I just have some security stuff I&= #39;d
> like to discuss that should be easy to resolve as some text is provide= d.
>
> In section 4.5, it is critical to also include a statement on security= in
> addition to privacy.=C2=A0 Medical devices with network attachments co= uld be
> used to kill someone.
> http://abcn= ews.go.com/Health/dick-cheneys-fear-heart-device-hacks-justified-experts/st= ory?id=3D20633284
>
> Suggest changing this text from:
>=C2=A0 =C2=A0In both cases, however,
>=C2=A0 =C2=A0it is crucial to protect the privacy of the people to whic= h medical
>=C2=A0 =C2=A0devices are attached.=C2=A0 Even though the data collected= by a heart beat
>=C2=A0 =C2=A0monitor might be protected, the pure fact that someone car= ries such a
>=C2=A0 =C2=A0device may need protection.=C2=A0 As such, certain medical= appliances may
>=C2=A0 =C2=A0not want to participate in discovery and self-configuratio= n protocols
>=C2=A0 =C2=A0in order to remain invisible.
> To:
>=C2=A0 =C2=A0In both cases, however,
>=C2=A0 =C2=A0it is crucial to protect the safety and privacy of the peo= ple to which
> medical
>=C2=A0 =C2=A0devices are attached.=C2=A0 Security precautions to protec= t access
> (authentication, encryption, integrity protections, etc.) to such devi= ces
> may be critical to protecting the safety of the individual. Even thoug= h
> the data collected by a heart beat
>=C2=A0 =C2=A0monitor might be protected, the pure fact that someone car= ries such a
>=C2=A0 =C2=A0device may need protection.=C2=A0 As such, certain medical= appliances may
>=C2=A0 =C2=A0not want to participate in discovery and self-configuratio= n protocols
>=C2=A0 =C2=A0in order to remain invisible.

Adopted text in Section 4.5 - Medical Applications.

> General statement:
> Many of the other use case scenarios also have safety as a concern, > requiring security protections (Confidentiality, Integrity,
> Availability).=C2=A0 Sensors used to control environmental settings is= another
> example where air regulation might include detection of harmful things= in
> the air (carbon monoxide).=C2=A0 I'm sure there are other safety c= oncerns that
> motivate security protections in each of the use cases, it's not j= ust
> privacy (which is important).=C2=A0 What if a sensor was tampered with= to
> report or not report something detected?=C2=A0 That's not covered = in the
> discussion on availability related problems in 4.6, but does represent=
> another set of security considerations that could lead to safety issue= s.
> More text on access control considerations for NMS may help.

I propose adding the following text to the respective sections.

Section 4.1 - Environmental Monitoring

Since many applications of environmental monitoring sensors are likely
to be in areas that are important to safety (flood monitoring, nuclear
radiation monitoring, etc.) it is important for management protocols
and network management systems (NMS) to ensure appropriate security
protections.
These protections include=C2=A0
=C2=A0not only access control, integrity and
availability of data, but also provide appropriate mechanisms that can
deal with situations that might be categorized as emergencies or when
tampering with sensors/data might be detected.

Section 4.2 - Infrastructure Monitoring

Since infrastructure monitoring is closely related to ensuring safety,
management protocols and systems must provide appropriate security
protections to ensure confidentiality, integrity and availability of
data.

Section 4.3 - Industrial Applications

Management protocols and NMSs must ensure appropriate access control
since different users of industrial control systems will have varying
levels of permissions.=C2=A0 E.g., while supervisors might be allowed to change production parameters, they should not be allowed to modify the
functional configuration of devices like a technician should.=C2=A0 It is also important to ensure integrity and availability of data since
malfunctions can potentially become safety issues.=C2=A0 This also implies<= br> that management systems must be able to react to situations that may
pose dangers to worker safety.

Section 4.5 - Medical Applications

In both cases, however, it is crucial to protect the safety and
privacy of the people to which medical devices are attached. Security
precautions to protect access (authentication, encryption, integrity
protections, etc.) to such devices may be critical to safeguarding t= he
individual. The level of access granted to different users also may
need to be regulated. For example, an authorized surgeon or doctor
must be allowed to configure all necessary options on the devices,
however, a nurse or technician may only be allowed to retrieve data
that can assist in diagnosis. Even though the data collected by a
heart beat monitor might be protected, the pure fact that = someone
carries such a device may need protection. As such, certain medical
appliances may not want to participate in discovery and
self-configuration protocols in order to remain invisible.

Section 4.6 - Building Automation

It is also important for a building automation NMS to take safety and
security into account.=C2=A0 Ensuring privacy and confidentiality of data,<= br> such that unauthorized parties do not get access to it, is likely to
be important since users' individual behaviors could be potentially
understood via their settings.=C2=A0 Appropriate security considerations for authorization and access control to the NMS is also important
since different users are likely to have varied levels of operational
permissions in the system.=C2=A0 E.g., while end users should be able to control lighting systems, HVACs, etc., only qualified technicians
should be able to configure parameters that change the fundamental
operation of a device.=C2=A0 It is also important for devices and the NMS to be able to detect and report any tampering they might detect, since
these could lead to potential user safety concerns, e.g., if sensors
controlling air quality are tampered with such that the levels of
Carbon Monoxide become life threatening.=C2=A0 This implies that a NMS
should also be able to deal with and appropriately prioritize
situations that might potentially lead to safety concerns.

Section 4.8 - Transport Applications

Since transport applications of the constrained devices and networks
deal with automotive vehicles, malfunctions and misuse can potentially
lead to safety concerns as well.=C2=A0 As such, besides access control,
privacy of user data and timeliness management systems should also be
able to detect situations that are potentially hazardous to safety.
Some of these situations could be automatically mitigated, e.g.,
traffic lights with incorrect timing, but others might require human
intervention, e.g., failed traffic lights.=C2=A0 The management system
should take appropriate actions in these situations.=C2=A0 Maintaining data=
confidentiality and integrity is also an important security aspect of
a management system since tampering (or malfunction) can also lead to
potentially dangerous situations.



Hopefully this text is enough to resolve these issues.

Yes, thank you!
Kathleen=C2=A0

Regards,
Anuj




--

Best regards,
Kath= leen
--001a11345b12f2778f050fd66d1f-- From nobody Tue Feb 24 07:19:49 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31C1A87DE; Tue, 24 Feb 2015 07:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oetlGbVUUmem; Tue, 24 Feb 2015 07:19:40 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB091A1B28; Tue, 24 Feb 2015 07:19:40 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id DB8A7DA0203; Tue, 24 Feb 2015 15:19:39 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A0B1653E0B1; Tue, 24 Feb 2015 07:19:39 -0800 (PST) Received: from CAS-04.WIN.NOMINUM.COM (64.89.235.67) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 24 Feb 2015 07:19:39 -0800 Received: from [10.0.20.107] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 24 Feb 2015 07:19:38 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> Date: Tue, 24 Feb 2015 10:19:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6FE041A3-354A-4F71-BDD2-CC4B8FDF3335@nominum.com> References: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> To: "Sehgal, Anuj" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsawg-coman-use-cases.all@ietf.org" , ext Kathleen Moriarty , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 15:19:45 -0000 On Feb 24, 2015, at 8:51 AM, Sehgal, Anuj = wrote: > Hopefully this text is enough to resolve these issues. I'm very happy with this update--thanks for doing it! From nobody Tue Feb 24 07:19:50 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-use-cases.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5B68A1A87E2; Tue, 24 Feb 2015 07:19:45 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-use-cases.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31C1A87DE; Tue, 24 Feb 2015 07:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oetlGbVUUmem; Tue, 24 Feb 2015 07:19:40 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB091A1B28; Tue, 24 Feb 2015 07:19:40 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id DB8A7DA0203; Tue, 24 Feb 2015 15:19:39 +0000 (UTC) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A0B1653E0B1; Tue, 24 Feb 2015 07:19:39 -0800 (PST) Received: from CAS-04.WIN.NOMINUM.COM (64.89.235.67) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 24 Feb 2015 07:19:39 -0800 Received: from [10.0.20.107] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 24 Feb 2015 07:19:38 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> Date: Tue, 24 Feb 2015 10:19:34 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6FE041A3-354A-4F71-BDD2-CC4B8FDF3335@nominum.com> References: <20150219154359.13340.37635.idtracker@ietfa.amsl.com> <38EB3E83-5B43-41E0-BA20-F6C355308D41@jacobs-university.de> To: "Sehgal, Anuj" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: "draft-ietf-opsawg-coman-use-cases.all@ietf.org" , ext Kathleen Moriarty , "opsawg-chairs@ietf.org" , The IESG , "opsawg@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-use-cases-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 15:19:45 -0000 On Feb 24, 2015, at 8:51 AM, Sehgal, Anuj = wrote: > Hopefully this text is enough to resolve these issues. I'm very happy with this update--thanks for doing it! From nobody Tue Feb 24 15:13:32 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E991A0076 for ; Tue, 24 Feb 2015 15:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4XxZwxVS_RF for ; Tue, 24 Feb 2015 15:13:29 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846581A0070 for ; Tue, 24 Feb 2015 15:13:29 -0800 (PST) Received: by wggy19 with SMTP id y19so137070wgg.13 for ; Tue, 24 Feb 2015 15:13:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=gxo0rxeehOZ+l/rv0swcyDHozQqJXbL8+7LcjJziG0k=; b=kmGVnFOWT3LEQxFpZeS1AnlgOcETT8zFg07cSBJuroWAzyJ6LuAtmRMlYAUsdCBlNg w4ewMEbLkLv2Gl31ZUiemTSpb9pLrp/GdcegMN2q23Hcdy2QjwTtYYEX9Zc2qKVEGvu3 b2rSBWPki7augtFoIzxKxKDUME2Rp4K1dxheIWEW9Kfsr8wVB3Og7Px1UMEhD+6kX0yf nGKcK5DMYj/Wwbe3Vki5DalcY9S9UUIwEAiYZKC3R/8gDb4YjX6Yy2QDEDQNoo0s+Gpi yw4iAvrmtjpADvIjGMCUA7hjTiMzRJt1pcLE1VGPtAsyUpg7r77Mct7YtAV75OXyiL/P GYaA== X-Gm-Message-State: ALoCoQk11uOeUwKqwAZceA4GCMt03iZuVvLuwrxIHpjXTrKwufQdGUP2abM8nFrXAD5MLVtcdJLx MIME-Version: 1.0 X-Received: by 10.194.63.16 with SMTP id c16mr276649wjs.117.1424819608095; Tue, 24 Feb 2015 15:13:28 -0800 (PST) Received: by 10.194.158.229 with HTTP; Tue, 24 Feb 2015 15:13:28 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 18:13:28 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" , draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org, "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 23:13:31 -0000 Reminder: This is an ongoing WGLC. We have 3 responses so far, but I *know* more folk have read (and commented on) the document. Please send comments to the list, clearly stating your view. W On Fri, Feb 20, 2015 at 9:47 AM, Warren Kumari wrote: > Dear OpsAWG WG, > > The authors of draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 have indicated > that they believe that the document is ready, and have asked for > Working Group Last Call. > The draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03/ > > Please review this draft to see if you think it is ready for > publication and send comments to the list, clearly stating your view. > > This document has already received significant review during adoption, > etc. and so reviewing it should not be a large hardship. We'd like at > **least** 5 regular WG participants to chime in saying that they > support the document. > > > This WGLC ends Fri 06-Mar-2015. > > > In addition, to satisfy RFC 6702 ("Promoting Compliance with > Intellectual Property Rights (IPR)"): > Are you personally aware of any IPR that applies to > draft-ietf-opsawg-hmac-sha-2-usm-snmp-03? If so, has this IPR been > disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, > 3669, and 5378 for more details.) > > Thanks, > Warren Kumari > (as OpsAWG WG co-chair) > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 24 15:16:52 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFE51A0276 for ; Tue, 24 Feb 2015 15:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcALkG_Ii5uf for ; Tue, 24 Feb 2015 15:16:50 -0800 (PST) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DBB1A0058 for ; Tue, 24 Feb 2015 15:16:49 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so1103113wiv.2 for ; Tue, 24 Feb 2015 15:16:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=am9cE3kHvkKOoXtKqGozfcwEZ78ql1tKkQrSjdJRbHM=; b=el6WTkYmz1ch4cgbut2w+ZdeEIClzv44/YHM/qHTVY3S5dPBAijCWF5j5QU/SqvYq5 fK/OZIgIMjHzs5WCu8kn7ZpQmM20ruouZ2w4AHb+91A7flRE2F/kBWpLSYOcMiuoqvBm SWbDQ/6t2DsBU0gAmvaOUI6nrin1JZk0KKJMELgLR6jTZGj4YdvX6TV8YHS5rwXPrDEA njGnEBxgzfXSWNLlvYPTqIJQcUQHTuDZyI70TJ+/l59Hk+MKjyxV13ai1vFShRIX9nEO 5z1I9isnDKWiU0zIzOIO7zcQZyW+VBf9zxG6CkaLiMXhFpq7fMB9EK4QbcG59sYSxMEs GShw== X-Gm-Message-State: ALoCoQnlPvk8zM+rMFrEvkX/albUzfo0feFIvh4dhpgHlIBVLGhkGGMo+2Z7w3HHY8DsThBoSbPV MIME-Version: 1.0 X-Received: by 10.180.102.199 with SMTP id fq7mr870434wib.89.1424819808577; Tue, 24 Feb 2015 15:16:48 -0800 (PST) Received: by 10.194.158.229 with HTTP; Tue, 24 Feb 2015 15:16:48 -0800 (PST) Date: Tue, 24 Feb 2015 18:16:48 -0500 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [OPSAWG] OpsAWG agenda time in Dallas. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 23:16:50 -0000 Hi opsawgers, We have a meeting slot in Dallas (once again, it is shared with OpsArea). We currently have one agenda item to cover, please speak up if you have agenda items you;d like to cover. Thanks, W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Feb 24 17:42:12 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15B31A8899 for ; Tue, 24 Feb 2015 17:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q2JmEsrAFtk for ; Tue, 24 Feb 2015 17:42:07 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108DB1A8892 for ; Tue, 24 Feb 2015 17:42:06 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 442D220B58 for ; Tue, 24 Feb 2015 20:42:05 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 24 Feb 2015 20:42:06 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=G3NQbOgiaaFD5NHadjd3cCNUVjY=; b=r5Fu9JXeg0LmHS9BmV08P nBC3KjYKV0ynHI/C2ZwiJwq9nSygLB51ZypY5WfL+QtPC6qYwcnXp6YWCC7THxld ZKajIXIajq3EHi5zwxoG7zSr1qaQhlBRZRdYzhX8QMe41RxyDqdTmGvrxgoXmm+D 9maaziuAezIt072dxcrt8o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=G3NQbOgiaaFD5NHadjd3cCN UVjY=; b=AdJ7z8awVMowb/mSM3H26FUtZbf6YcPz0lHFtF+swM24nGDqqR96BxO W/cwu7plppUam/TbMn4SHYnDi4Bh3vTWYBu6KA3jfjnvzQLV6gQ1sGx/njgHImSl /GpYK7fcZsalRgq32DwEjEkBzwssCwtxTax8+tNaVPM74n4yDI3o= X-Sasl-enc: k9il8Dzh6n8mu0XI8mEI20mP1xISMjjn7HY5QPmDu7kN 1424828525 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 02E17C002A4; Tue, 24 Feb 2015 20:42:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C9A0A07@AZ-FFEXMB04.global.avaya.com> Date: Tue, 24 Feb 2015 17:42:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5C9A0A07@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "opsawg-chairs@ietf.org" , "opsawg@ietf.org" , IESG , "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 01:42:10 -0000 I did not manage to get to this before heading out on maternity leave, = so I will change my ballot to abstain and have you all handle it as you = wish. Thanks, Alissa On Feb 23, 2015, at 5:11 AM, Romascanu, Dan (Dan) = wrote: > Hi Alissa, >=20 > Let me try to address the issues that you are raising. The coman team = worked as a non-WG team for about 2-3 years, and only at the last phase = of the work decided to send the two resulting informational documents to = the OPSAWG for a broader review and exposure, at the advice of our AD. = The two documents are informational, one describes the use cases and the = second one the requirements for the broader space discussed by the use = cases related to management of networks with constrained devices.. One = of the conclusions of the work is that we do not believe that there is = one single solution that would fit all use cases, this there is no = single set of mandatory requirements that apply to all the use cases. No = follow-up work is planned in OPS. We feel however that the two = informational documents will be useful for further reference for these = teams or WGs that try to build management solutions for one or more of = the use cases.=20 >=20 > In order to make the goals of the document more clear we suggest the = following edits:=20 >=20 > In Abstract:=20 >=20 > OLD:=20 >=20 > This document provides a problem statement, deployment and management > topology options as well as potential requirements for the = management > of networks where constrained devices are involved. >=20 > NEW:=20 >=20 > This document provides a problem statement, deployment and management > topology options as well as requirements addressing the different = use cases of=20 > the management of networks where constrained devices are involved. >=20 > In Section 1.1:=20 >=20 > OLD:=20 >=20 > This document provides a problem statement and lists potential > requirements for the management of a network with constrained > devices. Section 1.3 and Section 1.5 describe different topology > options for the networking and management of constrained devices. > Section 2 provides a problem statement on the issue of the = management > of networked constrained devices. Section 3 lists requirements on > the management of applications and networks with constrained = devices. > Note that the requirements listed in Section 3 have been separated > from the context in which they may appear. Depending on the = concrete > circumstances, an implementer may decide to address a certain > relevant subset of the requirements. >=20 > The use cases in the context of networks with constrained devices = can > be found in the companion document [COM-USE]. >=20 > NEW:=20 >=20 > This document provides a problem statement and lists requirements = for the=20 > different use cases of management of a network with constrained > devices. Section 1.3 and Section 1.5 describe different topology > options for the networking and management of constrained devices. > Section 2 provides a problem statement on the issue of the = management > of networked constrained devices. Section 3 lists requirements on > the management of applications and networks with constrained = devices. > Note that the requirements listed in Section 3 have been separated > from the context in which they may appear. Depending on the = concrete > circumstances, an implementer may decide to address a certain > relevant subset of the requirements. >=20 > The use cases in the context of networks with constrained devices = can > be found in the companion document [COM-USE]. This informational=20 > document provides a list of objectives for discussions and does not = aim=20 > to be a strict requirements document for all use cases. In fact, = there likely=20 > is not a single solution that works equally well for all the use = cases. >=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in] >> Sent: Thursday, February 19, 2015 1:55 AM >> To: The IESG >> Cc: opsawg@ietf.org; warren@kumari.net; draft-ietf-opsawg-coman- >> probstate-reqs.all@ietf.org; opsawg-chairs@ietf.org >> Subject: Alissa Cooper's Discuss on = draft-ietf-opsawg-coman-probstate-reqs- >> 04: (with DISCUSS) >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-opsawg-coman-probstate-reqs-04: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >> Please refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__www.ietf.org_iesg_statement_discuss- >> 2Dcriteria.html&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31Oc >> NXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DLRTLiND5zLlekWUmsFoaVKjkrugZ >> M-KnuAq0u86hymQ&s=3DeJjAd- >> BOQzGyu9hy1bhI6vQIl7xsHAWMzBLsPjwGVPU&e=3D >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dopsawg-2Dcoman- >> 2Dprobstate- >> 2Dreqs_&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQ >> zvlsiLQfucBXRucPvdrphpBsFA&m=3DLRTLiND5zLlekWUmsFoaVKjkrugZM- >> KnuAq0u86hymQ&s=3DKmEim4gFKCTNKbrps2bQskPznlkrThRg- >> bO0gjTvxEM&e=3D >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I'm putting this in as a DISCUSS in the event that the authors/WG = want to >> discuss it or that I'm just missing some context, but I will happily = move >> to ABSTAIN if there is no appetite for such discussion -- I see no = need >> to block the document from advancing on the basis of my comments. >>=20 >> It's really hard to tell how the "requirements" listed in this = document >> are intended to be used. In fact, it seems incorrect to call them >> "requirements" at all -- in the sense of somehow being "required" -- >> given the following: >>=20 >> This document provides a problem statement and lists potential >> requirements for the management of a network with constrained >> devices. ... Depending on the concrete >> circumstances, an implementer may decide to address a certain >> relevant subset of the requirements. >> ... >> This document in general >> does not recommend the realization of any subset of the described >> requirements. As such this document avoids selecting any of the >> requirements as mandatory to implement. A device might be able to >> provide only a particular selected set of requirements and might = not >> be capable to provide all requirements in this document. On the >> other hand a device vendor might select a specific relevant subset = of >> the requirements to implement. >>=20 >> It's hard to see how the approach described above will contribute = towards >> useful standardization. The "requirements" seem more like a laundry = list >> of all the properties that a management architecture, management >> protocols, networks of constrained devices, and/or individual >> implementations might find desirable. >>=20 >> This also makes me wonder how the WG intends for these "requirements" >> to >> be used. What is the next step as far as standardization goes? To = design >> the "management architecture" that is mentioned? Or the "management >> protocols" that are mentioned -- one or more, working together or >> separately? Or to consider how existing management protocols can be >> repurposed for constrained networks (which is sort of hinted at in >> section 2, but not stated explicitly), to meet some undefined subset = of >> the listed "requirements"? >>=20 >> I think publishing a laundry list of desirable properties is ok if = people >> find value in it, but I'm having trouble seeing how this document >> specifies either a problem statement or requirements that will = somehow >> contribute to standardization efforts in the future. >>=20 >>=20 >>=20 >=20 From nobody Tue Feb 24 17:42:15 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D50CA1A8881; Tue, 24 Feb 2015 17:42:11 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3271A8899 for ; Tue, 24 Feb 2015 17:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSI2RRs6QI2O for ; Tue, 24 Feb 2015 17:42:10 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B491A884E for ; Tue, 24 Feb 2015 17:42:06 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4FDCF20C6F for ; Tue, 24 Feb 2015 20:42:05 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Tue, 24 Feb 2015 20:42:06 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=G3NQbOgiaaFD5NHadjd3cCNUVjY=; b=r5Fu9JXeg0LmHS9BmV08P nBC3KjYKV0ynHI/C2ZwiJwq9nSygLB51ZypY5WfL+QtPC6qYwcnXp6YWCC7THxld ZKajIXIajq3EHi5zwxoG7zSr1qaQhlBRZRdYzhX8QMe41RxyDqdTmGvrxgoXmm+D 9maaziuAezIt072dxcrt8o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=G3NQbOgiaaFD5NHadjd3cCN UVjY=; b=AdJ7z8awVMowb/mSM3H26FUtZbf6YcPz0lHFtF+swM24nGDqqR96BxO W/cwu7plppUam/TbMn4SHYnDi4Bh3vTWYBu6KA3jfjnvzQLV6gQ1sGx/njgHImSl /GpYK7fcZsalRgq32DwEjEkBzwssCwtxTax8+tNaVPM74n4yDI3o= X-Sasl-enc: k9il8Dzh6n8mu0XI8mEI20mP1xISMjjn7HY5QPmDu7kN 1424828525 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 02E17C002A4; Tue, 24 Feb 2015 20:42:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C9A0A07@AZ-FFEXMB04.global.avaya.com> Date: Tue, 24 Feb 2015 17:42:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150218235436.22366.1746.idtracker@ietfa.amsl.com> <9904FB1B0159DA42B0B887B7FA8119CA5C9A0A07@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "opsawg-chairs@ietf.org" , "opsawg@ietf.org" , IESG , "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 01:42:12 -0000 I did not manage to get to this before heading out on maternity leave, = so I will change my ballot to abstain and have you all handle it as you = wish. Thanks, Alissa On Feb 23, 2015, at 5:11 AM, Romascanu, Dan (Dan) = wrote: > Hi Alissa, >=20 > Let me try to address the issues that you are raising. The coman team = worked as a non-WG team for about 2-3 years, and only at the last phase = of the work decided to send the two resulting informational documents to = the OPSAWG for a broader review and exposure, at the advice of our AD. = The two documents are informational, one describes the use cases and the = second one the requirements for the broader space discussed by the use = cases related to management of networks with constrained devices.. One = of the conclusions of the work is that we do not believe that there is = one single solution that would fit all use cases, this there is no = single set of mandatory requirements that apply to all the use cases. No = follow-up work is planned in OPS. We feel however that the two = informational documents will be useful for further reference for these = teams or WGs that try to build management solutions for one or more of = the use cases.=20 >=20 > In order to make the goals of the document more clear we suggest the = following edits:=20 >=20 > In Abstract:=20 >=20 > OLD:=20 >=20 > This document provides a problem statement, deployment and management > topology options as well as potential requirements for the = management > of networks where constrained devices are involved. >=20 > NEW:=20 >=20 > This document provides a problem statement, deployment and management > topology options as well as requirements addressing the different = use cases of=20 > the management of networks where constrained devices are involved. >=20 > In Section 1.1:=20 >=20 > OLD:=20 >=20 > This document provides a problem statement and lists potential > requirements for the management of a network with constrained > devices. Section 1.3 and Section 1.5 describe different topology > options for the networking and management of constrained devices. > Section 2 provides a problem statement on the issue of the = management > of networked constrained devices. Section 3 lists requirements on > the management of applications and networks with constrained = devices. > Note that the requirements listed in Section 3 have been separated > from the context in which they may appear. Depending on the = concrete > circumstances, an implementer may decide to address a certain > relevant subset of the requirements. >=20 > The use cases in the context of networks with constrained devices = can > be found in the companion document [COM-USE]. >=20 > NEW:=20 >=20 > This document provides a problem statement and lists requirements = for the=20 > different use cases of management of a network with constrained > devices. Section 1.3 and Section 1.5 describe different topology > options for the networking and management of constrained devices. > Section 2 provides a problem statement on the issue of the = management > of networked constrained devices. Section 3 lists requirements on > the management of applications and networks with constrained = devices. > Note that the requirements listed in Section 3 have been separated > from the context in which they may appear. Depending on the = concrete > circumstances, an implementer may decide to address a certain > relevant subset of the requirements. >=20 > The use cases in the context of networks with constrained devices = can > be found in the companion document [COM-USE]. This informational=20 > document provides a list of objectives for discussions and does not = aim=20 > to be a strict requirements document for all use cases. In fact, = there likely=20 > is not a single solution that works equally well for all the use = cases. >=20 >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in] >> Sent: Thursday, February 19, 2015 1:55 AM >> To: The IESG >> Cc: opsawg@ietf.org; warren@kumari.net; draft-ietf-opsawg-coman- >> probstate-reqs.all@ietf.org; opsawg-chairs@ietf.org >> Subject: Alissa Cooper's Discuss on = draft-ietf-opsawg-coman-probstate-reqs- >> 04: (with DISCUSS) >>=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-opsawg-coman-probstate-reqs-04: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >> Please refer to https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__www.ietf.org_iesg_statement_discuss- >> 2Dcriteria.html&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31Oc >> NXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DLRTLiND5zLlekWUmsFoaVKjkrugZ >> M-KnuAq0u86hymQ&s=3DeJjAd- >> BOQzGyu9hy1bhI6vQIl7xsHAWMzBLsPjwGVPU&e=3D >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dopsawg-2Dcoman- >> 2Dprobstate- >> 2Dreqs_&d=3DAwICaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQ >> zvlsiLQfucBXRucPvdrphpBsFA&m=3DLRTLiND5zLlekWUmsFoaVKjkrugZM- >> KnuAq0u86hymQ&s=3DKmEim4gFKCTNKbrps2bQskPznlkrThRg- >> bO0gjTvxEM&e=3D >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I'm putting this in as a DISCUSS in the event that the authors/WG = want to >> discuss it or that I'm just missing some context, but I will happily = move >> to ABSTAIN if there is no appetite for such discussion -- I see no = need >> to block the document from advancing on the basis of my comments. >>=20 >> It's really hard to tell how the "requirements" listed in this = document >> are intended to be used. In fact, it seems incorrect to call them >> "requirements" at all -- in the sense of somehow being "required" -- >> given the following: >>=20 >> This document provides a problem statement and lists potential >> requirements for the management of a network with constrained >> devices. ... Depending on the concrete >> circumstances, an implementer may decide to address a certain >> relevant subset of the requirements. >> ... >> This document in general >> does not recommend the realization of any subset of the described >> requirements. As such this document avoids selecting any of the >> requirements as mandatory to implement. A device might be able to >> provide only a particular selected set of requirements and might = not >> be capable to provide all requirements in this document. On the >> other hand a device vendor might select a specific relevant subset = of >> the requirements to implement. >>=20 >> It's hard to see how the approach described above will contribute = towards >> useful standardization. The "requirements" seem more like a laundry = list >> of all the properties that a management architecture, management >> protocols, networks of constrained devices, and/or individual >> implementations might find desirable. >>=20 >> This also makes me wonder how the WG intends for these "requirements" >> to >> be used. What is the next step as far as standardization goes? To = design >> the "management architecture" that is mentioned? Or the "management >> protocols" that are mentioned -- one or more, working together or >> separately? Or to consider how existing management protocols can be >> repurposed for constrained networks (which is sort of hinted at in >> section 2, but not stated explicitly), to meet some undefined subset = of >> the listed "requirements"? >>=20 >> I think publishing a laundry list of desirable properties is ok if = people >> find value in it, but I'm having trouble seeing how this document >> specifies either a problem statement or requirements that will = somehow >> contribute to standardization efforts in the future. >>=20 >>=20 >>=20 >=20 From nobody Tue Feb 24 17:43:04 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CFB1A8871; Tue, 24 Feb 2015 17:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taCUgnH_NoEk; Tue, 24 Feb 2015 17:42:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A211A1B1D; Tue, 24 Feb 2015 17:42:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150225014259.11841.51237.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 17:42:59 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Alissa Cooper's Abstain on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 01:43:00 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Switching this to abstain -- I see no need to block the document from advancing on the basis of my comments. It's really hard to tell how the "requirements" listed in this document are intended to be used. In fact, it seems incorrect to call them "requirements" at all -- in the sense of somehow being "required" -- given the following: This document provides a problem statement and lists potential requirements for the management of a network with constrained devices. ... Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. ... This document in general does not recommend the realization of any subset of the described requirements. As such this document avoids selecting any of the requirements as mandatory to implement. A device might be able to provide only a particular selected set of requirements and might not be capable to provide all requirements in this document. On the other hand a device vendor might select a specific relevant subset of the requirements to implement. It's hard to see how the approach described above will contribute towards useful standardization. The "requirements" seem more like a laundry list of all the properties that a management architecture, management protocols, networks of constrained devices, and/or individual implementations might find desirable. This also makes me wonder how the WG intends for these "requirements" to be used. What is the next step as far as standardization goes? To design the "management architecture" that is mentioned? Or the "management protocols" that are mentioned -- one or more, working together or separately? Or to consider how existing management protocols can be repurposed for constrained networks (which is sort of hinted at in section 2, but not stated explicitly), to meet some undefined subset of the listed "requirements"? I think publishing a laundry list of desirable properties is ok if people find value in it, but I'm having trouble seeing how this document specifies either a problem statement or requirements that will somehow contribute to standardization efforts in the future. From nobody Tue Feb 24 17:43:06 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B53631A88AB; Tue, 24 Feb 2015 17:43:00 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CFB1A8871; Tue, 24 Feb 2015 17:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taCUgnH_NoEk; Tue, 24 Feb 2015 17:42:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A211A1B1D; Tue, 24 Feb 2015 17:42:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150225014259.11841.51237.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 17:42:59 -0800 Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: [OPSAWG] Alissa Cooper's Abstain on draft-ietf-opsawg-coman-probstate-reqs-04: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 01:43:00 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Switching this to abstain -- I see no need to block the document from advancing on the basis of my comments. It's really hard to tell how the "requirements" listed in this document are intended to be used. In fact, it seems incorrect to call them "requirements" at all -- in the sense of somehow being "required" -- given the following: This document provides a problem statement and lists potential requirements for the management of a network with constrained devices. ... Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. ... This document in general does not recommend the realization of any subset of the described requirements. As such this document avoids selecting any of the requirements as mandatory to implement. A device might be able to provide only a particular selected set of requirements and might not be capable to provide all requirements in this document. On the other hand a device vendor might select a specific relevant subset of the requirements to implement. It's hard to see how the approach described above will contribute towards useful standardization. The "requirements" seem more like a laundry list of all the properties that a management architecture, management protocols, networks of constrained devices, and/or individual implementations might find desirable. This also makes me wonder how the WG intends for these "requirements" to be used. What is the next step as far as standardization goes? To design the "management architecture" that is mentioned? Or the "management protocols" that are mentioned -- one or more, working together or separately? Or to consider how existing management protocols can be repurposed for constrained networks (which is sort of hinted at in section 2, but not stated explicitly), to meet some undefined subset of the listed "requirements"? I think publishing a laundry list of desirable properties is ok if people find value in it, but I'm having trouble seeing how this document specifies either a problem statement or requirements that will somehow contribute to standardization efforts in the future. From nobody Wed Feb 25 01:23:13 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E638E1A7034; Wed, 25 Feb 2015 01:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOHQkfNmDG7s; Wed, 25 Feb 2015 01:23:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FEC1A70FE; Wed, 25 Feb 2015 01:23:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150225092310.11065.5148.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 01:23:10 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 09:23:12 -0000 IESG state changed to AD is watching from AD Evaluation::AD Followup On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" wrote: > Dear draft-ietf-opsawg-capwap-alt-tunnel and > draft-xue-opsawg-capwap-alt-tunnel-information authors, > > Can you please a draft version according to Sri's plan below. > > Regards, Benoit >> wfm >> >>> On Dec 19, 2014, at 10:05 AM, Benoit Claise wrote: >>> >>> On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: >>>> Hi Benoit, >>>> >>>>> Let me propose a solution: augment >>>>> draft-ietf-opsawg-capwap-alt-tunnel with the information elements for >>>>> CAPWAP (not the others one). >>>> The above draft defines number of encapsulation modes and that list >>>> includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. >>>> Each of those tunnel types can be activated with a set of tunnel >>>> parameters. These parameters include source IP, destination IP, sport, >>>> dport, GRE key ..etc. To most part this is about identifying a common >>>> set of parameters, providing definition for those parameters and >>>> grouping the relevant one's for each of the encapsulation modes. >>>> Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not >>>> radically different from the others and the above common parameter set >>>> is sufficient for these modes. To create a tunnel with GRE with IPv4 >>>> transport is not any different from GRE with IPv6 transport, or for >>>> that matter for IP-in-IP mode. >>>> >>>> It is to be noted there are no proposed changes to any of these >>>> encapsulation modes, or to the control protocols activating those >>>> encap modes. Its mostly about activating a tunnel state with a >>>> set of parameters. If at all, CAPWAP data plane may be bit complex >>>> and even L2TP as its unclear if the control protocol has semantics for >>>> the L2TP peers to separate control and data plane. If not, it requires >>>> changes to the L2TP protocol. So, its easier to keep CAPWAP + >>>> GRE/IP-in-IP modes in the main spec as the work has a well defined >>>> scope. >>> If it works for the WG, it works for me. Any objections anybody? >>> That would imply a new draft and a new consensus call. >>> >>> Regards, Benoit ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ From nobody Wed Feb 25 01:23:14 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-capwap-alt-tunnel.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 150A31A7D82; Wed, 25 Feb 2015 01:23:12 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-capwap-alt-tunnel.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-capwap-alt-tunnel.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E638E1A7034; Wed, 25 Feb 2015 01:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOHQkfNmDG7s; Wed, 25 Feb 2015 01:23:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FEC1A70FE; Wed, 25 Feb 2015 01:23:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150225092310.11065.5148.idtracker@ietfa.amsl.com> Date: Wed, 25 Feb 2015 01:23:10 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] ID Tracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 09:23:12 -0000 IESG state changed to AD is watching from AD Evaluation::AD Followup On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" wrote: > Dear draft-ietf-opsawg-capwap-alt-tunnel and > draft-xue-opsawg-capwap-alt-tunnel-information authors, > > Can you please a draft version according to Sri's plan below. > > Regards, Benoit >> wfm >> >>> On Dec 19, 2014, at 10:05 AM, Benoit Claise wrote: >>> >>> On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: >>>> Hi Benoit, >>>> >>>>> Let me propose a solution: augment >>>>> draft-ietf-opsawg-capwap-alt-tunnel with the information elements for >>>>> CAPWAP (not the others one). >>>> The above draft defines number of encapsulation modes and that list >>>> includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. >>>> Each of those tunnel types can be activated with a set of tunnel >>>> parameters. These parameters include source IP, destination IP, sport, >>>> dport, GRE key ..etc. To most part this is about identifying a common >>>> set of parameters, providing definition for those parameters and >>>> grouping the relevant one's for each of the encapsulation modes. >>>> Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not >>>> radically different from the others and the above common parameter set >>>> is sufficient for these modes. To create a tunnel with GRE with IPv4 >>>> transport is not any different from GRE with IPv6 transport, or for >>>> that matter for IP-in-IP mode. >>>> >>>> It is to be noted there are no proposed changes to any of these >>>> encapsulation modes, or to the control protocols activating those >>>> encap modes. Its mostly about activating a tunnel state with a >>>> set of parameters. If at all, CAPWAP data plane may be bit complex >>>> and even L2TP as its unclear if the control protocol has semantics for >>>> the L2TP peers to separate control and data plane. If not, it requires >>>> changes to the L2TP protocol. So, its easier to keep CAPWAP + >>>> GRE/IP-in-IP modes in the main spec as the work has a well defined >>>> scope. >>> If it works for the WG, it works for me. Any objections anybody? >>> That would imply a new draft and a new consensus call. >>> >>> Regards, Benoit ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ From nobody Wed Feb 25 01:24:21 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FBB1A702F for ; Wed, 25 Feb 2015 01:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nChUKtWa6B_f for ; Wed, 25 Feb 2015 01:24:17 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885291A0373 for ; Wed, 25 Feb 2015 01:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9175; q=dns/txt; s=iport; t=1424856256; x=1426065856; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fJj3GGwht4N1REoF9EkA6/isGdNnsPaptuPsE7wHfMA=; b=WABXvslBKtYZ0qwa3xpPJSHoJ2t33wwC8n5eF7qiOw8WjBcWFWI5Jwpb Q1mZpwugZwFvfNGSNK3I8MD4FYv6FJSkByTfQpCA0o5zNq4I0gmsCGykm SF275CNvaB3rsF0EN9x1b5PlSA97jMT8n7aRt9k6CdtYOoOXcl2FbbeMq Y=; X-IronPort-AV: E=Sophos;i="5.09,643,1418083200"; d="scan'208";a="355813384" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 25 Feb 2015 09:24:14 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1P9OEcG014002; Wed, 25 Feb 2015 09:24:14 GMT Message-ID: <54ED94BE.7050408@cisco.com> Date: Wed, 25 Feb 2015 10:24:14 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Rajesh Pazhyannur (rpazhyan)" , "Scott O. Bradner" References: <54943ED5.6050506@cisco.com> <54BE5AC1.9050901@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "opsawg@ietf.org" , "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" , "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and draft-xue-opsawg-capwap-alt-tunnel-information relationship X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 09:24:19 -0000 Dear draft-ietf-opsawg-capwap-alt-tunnel authors, I put this draft in AD watching status, as opposed to AD review. This is the correct state. Regards, Benoit > Hi Benoit > > Yes, I am working on it. > I will get you a date by the end of the week of when a draft will be ready. > > Thanks > > Rajesh > > On 1/20/15, 5:40 AM, "Benoit Claise (bclaise)" wrote: > >> Dear draft-ietf-opsawg-capwap-alt-tunnel and >> draft-xue-opsawg-capwap-alt-tunnel-information authors, >> >> Can you please a draft version according to Sri's plan below. >> >> Regards, Benoit >>> wfm >>> >>>> On Dec 19, 2014, at 10:05 AM, Benoit Claise wrote: >>>> >>>> On 03/12/2014 08:59, Sri Gundavelli (sgundave) wrote: >>>>> Hi Benoit, >>>>> >>>>>> Let me propose a solution: augment >>>>>> draft-ietf-opsawg-capwap-alt-tunnel with the information elements for >>>>>> CAPWAP (not the others one). >>>>> The above draft defines number of encapsulation modes and that list >>>>> includes, CAPWAP, L2TPv2, L2TPv3, IP-in-IP, PMIPv6, GREv4 and GREv6. >>>>> Each of those tunnel types can be activated with a set of tunnel >>>>> parameters. These parameters include source IP, destination IP, sport, >>>>> dport, GRE key ..etc. To most part this is about identifying a common >>>>> set of parameters, providing definition for those parameters and >>>>> grouping the relevant one's for each of the encapsulation modes. >>>>> Taking GREv4, GREv6, IP-in-IP or PMIP (uses GRE), each are not >>>>> radically different from the others and the above common parameter set >>>>> is sufficient for these modes. To create a tunnel with GRE with IPv4 >>>>> transport is not any different from GRE with IPv6 transport, or for >>>>> that matter for IP-in-IP mode. >>>>> >>>>> It is to be noted there are no proposed changes to any of these >>>>> encapsulation modes, or to the control protocols activating those >>>>> encap modes. Its mostly about activating a tunnel state with a >>>>> set of parameters. If at all, CAPWAP data plane may be bit complex >>>>> and even L2TP as its unclear if the control protocol has semantics for >>>>> the L2TP peers to separate control and data plane. If not, it requires >>>>> changes to the L2TP protocol. So, its easier to keep CAPWAP + >>>>> GRE/IP-in-IP modes in the main spec as the work has a well defined >>>>> scope. >>>> If it works for the WG, it works for me. Any objections anybody? >>>> That would imply a new draft and a new consensus call. >>>> >>>> Regards, Benoit >>>>> So, my suggestion is to allow draft-ietf-opsawg-capwap-alt-tunnel to >>>>> also support GRE/IP-in-IP modes and have draft-xue focus exclusively >>>>> on L2TP extensions and move it on a fast track. IMO, this is a >>>>> reasonably split. I'm also happy to provide the text for the above >>>>> encap modes and ensure the changes do not delay the publication. >>>>> >>>>> >>>>> Regards >>>>> Sri >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: "Benoit Claise (bclaise)" >>>>> Date: Monday, December 1, 2014 7:37 AM >>>>> To: "Rajesh Pazhyannur (rpazhyan)" , >>>>> "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >>>>> , >>>>> "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>>> >>>>> Cc: "opsawg@ietf.org" >>>>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >>>>> draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>>> >>>>> Hi Rajesh, >>>>> >>>>> I'm concerned that: >>>>> - draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >>>>> solution >>>>> - draft-ietf-opsawg-capwap-alt-tunnel requires the encoding from >>>>> draft-xue-opsawg-capwap-alt-tunnel-information, an individual draft. >>>>> - draft-xue-opsawg-capwap-alt-tunnel-information covers 6 different >>>>> tunnel types, and required expertise from many different group. This >>>>> might take some time... >>>>> >>>>> Let me propose a solution: augment >>>>> draft-ietf-opsawg-capwap-alt-tunnel with the information elements for >>>>> CAPWAP (not the others one). This way, this draft would be a complete >>>>> solution. >>>>> And if people wants alternate tunnel types, this would be done in >>>>> draft-xue-opsawg-capwap-alt-tunnel-information >>>>> >>>>> Regards, Benoit >>>>> >>>>>> Hello >>>>>> >>>>>> I realized there was a typographical error in my response below. >>>>>> Please see corrections. >>>>>> >>>>>> Regards >>>>>> >>>>>> Rajesh >>>>>> From: Rajesh Pazhyannur >>>>>> Date: Thursday, November 20, 2014 at 12:30 AM >>>>>> To: "Benoit Claise (bclaise)" , >>>>>> "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >>>>>> , >>>>>> "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>>>> >>>>>> Cc: "opsawg@ietf.org" >>>>>> Subject: Re: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >>>>>> draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>>>> >>>>>> Hi Benoit >>>>>> >>>>>> But now I wonder: why do we have two different drafts, as opposed to >>>>>> a single one? >>>>>> >>>>>> This is a good question. >>>>>> >>>>>> [original] Yes, you are correct that >>>>>> draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >>>>>> solution and needs something like >>>>>> draft-ietf-opsawg-capwap-alt-tunnel to complete the solution. >>>>>> [corrected statement] Yes, you are correct that >>>>>> draft-ietf-opsawg-capwap-alt-tunnel does not provide a complete >>>>>> solution and needs something like >>>>>> draft-xue-opsawg-capwap-alt-tunnel-information to complete the >>>>>> solution. >>>>>> >>>>>> The best answer I have is that we wanted the keep the following two >>>>>> areas separate (and in different drafts) >>>>>> € Discover and negotiation of alternate tunneling capability. These >>>>>> are independent of specific alternate tunnel method >>>>>> € [original] Definition of tunnel specific message elements. While >>>>>> draft-ietf-opsawg-capwap-alt-tunnel contains message elements for >>>>>> most of the tunneling methods defined in >>>>>> draft-ietf-opsawg-capwap-alt-tunnel, I had anticipated separate >>>>>> drafts for each tunneling protocol. >>>>>> [corrected] 2 Definition of tunnel specific message elements. While >>>>>> draft-ietf-opsawg-capwap-alt-tunnel contains message elements for >>>>>> most of the tunneling methods defined in >>>>>> draft-xue-opsawg-capwap-alt-tunnel-information I had anticipated >>>>>> separate drafts for each tunneling protocol. >>>>>> >>>>>> Finishing 1. would allow 2. to be completed separately and >>>>>> independently in potentially different drafts (and potentially >>>>>> different groups with relevant expertise). It is somewhat akin >>>>>> (though not identical) to separation between RFC 5415 and RFC 5416 >>>>>> where RFC 5415 is wireless technology independent and RFC 5416 is >>>>>> 802.11 specific. >>>>>> >>>>>> Hope the above makes sense. >>>>>> >>>>>> Regards >>>>>> >>>>>> Rajesh >>>>>> From: "Benoit Claise (bclaise)" >>>>>> Date: Wednesday, November 19, 2014 at 11:50 AM >>>>>> To: "draft-xue-opsawg-capwap-alt-tunnel-information@tools.ietf.org" >>>>>> , >>>>>> "draft-ietf-opsawg-capwap-alt-tunnel@tools.ietf.org" >>>>>> >>>>>> Cc: "opsawg@ietf.org" >>>>>> Subject: [OPSAWG] draft-ietf-opsawg-capwap-alt-tunnel and >>>>>> draft-xue-opsawg-capwap-alt-tunnel-information relationship >>>>>> >>>>>> Dear CAPWAP authors, >>>>>> >>>>>> After the draft-xue-opsawg-capwap-alt-tunnel-information >>>>>> presentation at the last IETF meeting, I've been wondering about the >>>>>> relationship between the two drafts: >>>>>> - draft-ietf-opsawg-capwap-alt-tunnel provides the tunnel types >>>>>> Note:this draft is currently in AD review, so close to be sent to >>>>>> the IESG. >>>>>> - draft-xue-opsawg-capwap-alt-tunnel-information provides the >>>>>> encoding of the tunnel-specific fields. >>>>>> >>>>>> I believe I'm correct that the draft-ietf-opsawg-capwap-alt-tunnel >>>>>> doesn't provide a complete solution without >>>>>> draft-xue-opsawg-capwap-alt-tunnel-information? >>>>>> >>>>>> I'm aware of the changes between version 3 and 4 (attached picture >>>>>> and >>>>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel >>>>>> -04.txt) >>>>>> >>>>>> But now I wonder: why do we have two different drafts, as opposed to >>>>>> a single one? >>>>>> >>>>>> Regards, Benoit >>>>>> >>>>>> >>>>> . >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> OPSAWG@ietf.org >>>> https://www.ietf.org/mailman/listinfo/opsawg >>> . >>> > . > From nobody Wed Feb 25 05:47:09 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393061A1A42 for ; Wed, 25 Feb 2015 05:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaCiZXTC8BUf for ; Wed, 25 Feb 2015 05:47:07 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0008F1A039B for ; Wed, 25 Feb 2015 05:47:06 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4C6D428B003D; Wed, 25 Feb 2015 08:47:06 -0500 (EST) Received: from ispx.vb.futz.org (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id EE4D01F8035; Wed, 25 Feb 2015 08:47:05 -0500 (EST) Date: Wed, 25 Feb 2015 08:47:02 -0500 From: Robert Story To: Warren Kumari Message-ID: <20150225084702.04f5b61b@ispx.vb.futz.org> In-Reply-To: References: Organization: Parsons X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Gk1ZzcPGeH9M=C+al_i=8WJ"; protocol="application/pgp-signature" Archived-At: Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" , draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 13:47:08 -0000 --Sig_/Gk1ZzcPGeH9M=C+al_i=8WJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 20 Feb 2015 09:47:24 -0500 Warren wrote: WK> The draft is available here: WK> https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp-= 03/ WK>=20 WK> Please review this draft to see if you think it is ready for WK> publication and send comments to the list, clearly stating your view. WK>=20 WK> This document has already received significant review during adoption, WK> etc. and so reviewing it should not be a large hardship. We'd like at WK> **least** 5 regular WG participants to chime in saying that they WK> support the document. I hope irregular participants count too. ;-) I've read this draft and am strongly in favor of updating to stronger auth protocols. Robert --=20 Senior Software Engineer @ Parsons --Sig_/Gk1ZzcPGeH9M=C+al_i=8WJ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU7dJZAAoJEMHFVuy5l8Y4l1gP/jg9atSjRIZrYTC6LefUshca 7q68b1FW/sac0jze7SeDh+BFPIpSlfXYGfQAfkGALKWOkSTxzhZ7eFIH5Pw6+N+v xuWi4UyWr0I12xUxM1jmdTxlwSO3p+x2jv9A6hUvVxzmbIAEfFAceQ+CmVtjgoo2 Evya7AduxWMdQC5/d93Wl3Wkbf7xgl1Z7oarALT4oMvSIMQcD0t2sicbSvs3o2PS zaMnJwD63rDMxykjWNqf6D8uEG4HFg4HP4lljg6WCO0BK20wYGXt1L3zLJ+DRgfq tYe16sJipCCVjc7wAsXoJArIhaH2uRD7ve573cCyPVPP4UsVEF0NTfuV9hA3K56q +0reeNyM3zBG/rE6wqvYox0d/80hV/wr1hSEZB0dN31Mh75ap8+6bc6pai0uR6X7 W2jqY3k7H0Npwf9GAgB8IFCse3wBuFJe43eplcO6+XY6lfrWs0fNKG78YQsgYuz8 cKTHCG4WO5hjgvut2xBd7NjV4mEzceur1wPo4R48KpEwAe4FJiESsBcCyb+xcPJx GennuJQ8CKVbDQ7noVeBOvnarjCmxL5j2iy7q2aWh9OwN18wdrgATG3SnGhJo7Rt TZ7HAtFn2U6wnT6kWkNCEl9zi+dUrPna8f6KI4qheDGwwo71GOokhxXJ5VfnF7MT 6OP9ohlte1UgUD6YKeFO =JPQy -----END PGP SIGNATURE----- --Sig_/Gk1ZzcPGeH9M=C+al_i=8WJ-- From nobody Wed Feb 25 08:26:36 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8B01A885C for ; Wed, 25 Feb 2015 08:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-sW8OvIjSOC for ; Wed, 25 Feb 2015 08:26:33 -0800 (PST) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEF41A9138 for ; Wed, 25 Feb 2015 08:25:07 -0800 (PST) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id DECF828690; Wed, 25 Feb 2015 08:25:06 -0800 (PST) Received: from EX13-CAS-005.vmware.com (EX13-CAS-005.vmware.com [10.113.191.55]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id D68FD18109; Wed, 25 Feb 2015 08:25:06 -0800 (PST) Received: from EX13-MBX-020.vmware.com (10.113.191.40) by EX13-MBX-002.vmware.com (10.113.191.22) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 25 Feb 2015 08:25:04 -0800 Received: from EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7]) by EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7%15]) with mapi id 15.00.0913.011; Wed, 25 Feb 2015 08:24:45 -0800 From: Michael MacFaden To: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. Thread-Index: AQHQTRwpoa9j6iKqlki8ZOfB0V7UI50B7vQAgAAsD4A= Date: Wed, 25 Feb 2015 16:24:44 +0000 Message-ID: <5E06D39E-A4B2-44E4-A087-18F56C14BCA3@vmware.com> References: <20150225084702.04f5b61b@ispx.vb.futz.org> In-Reply-To: <20150225084702.04f5b61b@ispx.vb.futz.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.113.160.246] Content-Type: multipart/alternative; boundary="_000_5E06D39EA4B244E4A08718F56C14BCA3vmwarecom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 16:26:35 -0000 --_000_5E06D39EA4B244E4A08718F56C14BCA3vmwarecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable WK>Please review this draft to see if you think it is ready for WK> publication and send comments to the list, clearly stating your view. Regarding https://tools.ietf.org/id/draft-ietf-opsawg-hmac-sha-2-usm-snmp-= 03.txt I also support adoption of the draft. Putting on the mib doctor hat, I ran smilint over the mib module as well using faux oids, smilint reports clean. $ smilint -l9 ./SNMP-USM-HMAC-SHA2-MIB $smidump -f tree SNMP-USM-HMAC-SHA2-MIB registration tree (generated by smidump 0.4.8) --snmpModules(1.3.6.1.6.3) | +--snmpFrameworkMIB(10) | | | +--snmpFrameworkAdmin(1) | | | +--snmpAuthProtocols(1) | | | +--usmHMAC192SHA256AuthProtocol(888) | | | +=97usmHMAC384SHA12AuthProtocol(999) | | | +=97usmHMAC128SHA224AuthProtocol(777) | | | +=97usmHMAC256SHA384AuthProtocol(666) | +=97snmpUsmHmacSha2MIB(666) In the Security Considerations section I had these comments: 1) To be clear, I interpret section 9.2 which states: At the time of this writing, to mean the date when the document is published. 2) Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security the boiler plate text to add here would be the clause starting with the sentence =93There are no management objects.=94 but would change =93textual conventions=94 to =93oid value assignments" 3) There exist rfc normative references listed in the above url boilerplate= not included in the draft typically used in rfcs containing mib modules. Mike MacFaden --_000_5E06D39EA4B244E4A08718F56C14BCA3vmwarecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <851A0AE47502444FA07D50555100D405@pa-exch1.vmware.com> Content-Transfer-Encoding: quoted-printable
WK>Please review this draft to see if you thin= k it is ready for
WK> publication and send comments to the list, clearly stating your view= .


I also support adoption of the draft.

Putting on the mib doctor hat, I ran smilint over the  mib module= as well 
using faux oids, smilint reports clean.

$ smilint -l9 ./SNMP-USM-HMAC-SHA2-MIB

 $smidump -f tree SNMP-USM-HMAC-SHA2-MIB
 registration tree (generated by smidump 0.4.8)
--snmpModules(1.3.6.1.6.3)
  |
  +--snmpFrameworkMIB(10)
  |  |
  |  +--snmpFrameworkAdmin(1)
  |     |
  |     +--snmpAuthProtocols(1)
  |        |
  |        +--usmHMAC192SHA256AuthProtoco= l(888)
  |        |
  |        +=97usmHMAC384SHA12AuthProtoco= l(999)
  |        |
  |        +=97usmHMAC128SHA224AuthProtoc= ol(777)
  |        |
  |        +=97usmHMAC256SHA384AuthProtoc= ol(666)
  |
  +=97snmpUsmHmacSha2MIB(666)

In the Security Considerations
section I had these comments:

1) To be clear, I interpret section 9.2 which states:
   At the time of this writing,
to mean the date when the document is published. 

the boiler plate text to add here would be the clause starting with th= e
sentence  =93There are no management objects.=94 but would change=  
=93textual conventions=94 to =93oid value assignments"

3) There exist rfc normative references listed in the above url boiler= plate not included in the draft
typically used in rfcs containing mib modules.

Mike MacFaden



--_000_5E06D39EA4B244E4A08718F56C14BCA3vmwarecom_-- From nobody Wed Feb 25 08:58:31 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A1E1A8780 for ; Wed, 25 Feb 2015 08:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5p1MZyskJm9 for ; Wed, 25 Feb 2015 08:58:27 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6C71A8828 for ; Wed, 25 Feb 2015 08:58:24 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 5AB811A00C7; Wed, 25 Feb 2015 17:58:12 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hhQFaJjiLkMV; Wed, 25 Feb 2015 17:58:11 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id F1CDA1A00C5; Wed, 25 Feb 2015 17:58:10 +0100 (CET) Received: from [172.16.40.201] (172.16.40.201) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Feb 2015 17:58:20 +0100 Message-ID: <54EDFF27.8050406@secunet.com> Date: Wed, 25 Feb 2015 17:58:15 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michael MacFaden , "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" References: <20150225084702.04f5b61b@ispx.vb.futz.org> <5E06D39E-A4B2-44E4-A087-18F56C14BCA3@vmware.com> In-Reply-To: <5E06D39E-A4B2-44E4-A087-18F56C14BCA3@vmware.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [172.16.40.201] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Cc: "draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 16:58:29 -0000 > Putting on the mib doctor hat, I ran smilint over the mib module as well > using faux oids, smilint reports clean. > Thanks for checking this. As Juergen pointed out there are some small issues in the MIB module which I will fix as soon as the WG LC has ended. > > In the Security Considerations > section I had these comments: > > 1) To be clear, I interpret section 9.2 which states: > At the time of this writing, > to mean the date when the document is published. Yes, but IMHO this is obvious and does not require further clarification. > > 2) Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security > the boiler plate text to add here would be the clause starting with the > sentence “There are no management objects.” but would change > “textual conventions” to “oid value assignments" > Isn't that essentially the same statement as the current text in Section 9.4? The SNMP-USM-HMAC-SHA2-MIB module defines OBJECT IDENTIFIER values for use in other MIB modules. It does not define any objects that can be accessed. As such, the SNMP-USM-HMAC-SHA2-MIB does not, by itself, have any effect on the security of the Internet. > 3) There exist rfc normative references listed in the above url boilerplate not included in the draft > typically used in rfcs containing mib modules. Well, if we use the text you referred to (“There are no management objects...” ), or even keep the current text in 9.4, no references are needed, right? -- Johannes From nobody Wed Feb 25 09:50:00 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1D81A0018 for ; Wed, 25 Feb 2015 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UkmJgAlDK2V for ; Wed, 25 Feb 2015 09:49:55 -0800 (PST) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C671A0015 for ; Wed, 25 Feb 2015 09:49:55 -0800 (PST) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 43E352872E; Wed, 25 Feb 2015 09:49:54 -0800 (PST) Received: from EX13-CAS-006.vmware.com (EX13-CAS-006.vmware.com [10.113.191.56]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 3FAD31812B; Wed, 25 Feb 2015 09:49:54 -0800 (PST) Received: from EX13-MBX-020.vmware.com (10.113.191.40) by EX13-MBX-027.vmware.com (10.113.191.47) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 25 Feb 2015 09:49:53 -0800 Received: from EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7]) by EX13-MBX-020.vmware.com ([fe80::8489:873c:5a56:44a7%15]) with mapi id 15.00.0913.011; Wed, 25 Feb 2015 09:49:53 -0800 From: Michael MacFaden To: Johannes Merkle Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. Thread-Index: AQHQTRwpoa9j6iKqlki8ZOfB0V7UI50B7vQAgAAsD4CAAAlegIAADmuA Date: Wed, 25 Feb 2015 17:49:52 +0000 Message-ID: <2F62FEFE-EBBA-478E-92B9-60C860732DDE@vmware.com> References: <20150225084702.04f5b61b@ispx.vb.futz.org> <5E06D39E-A4B2-44E4-A087-18F56C14BCA3@vmware.com> <54EDFF27.8050406@secunet.com> In-Reply-To: <54EDFF27.8050406@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.113.160.246] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-hmac-sha-2-usm-snmp-03@tools.ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 17:49:57 -0000 On Feb 25, 2015, at 8:58 AM, Johannes Merkle = wrote: >>=20 >> 1) To be clear, I interpret section 9.2 which states: >> At the time of this writing, >> to mean the date when the document is published.=20 >=20 > Yes, but IMHO this is obvious and does not require further clarification. Good, just confirming. But obvious to one is not always obvious to another= imo. > 2) Per https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__trac.tools.i= etf.org_area_ops_trac_wiki_mib-2Dsecurity&d=3DAwID-g&c=3DSqcl0Ez6M0X8aeM67L= KIiDJAXVeAw-YihVMNtXt-uEs&r=3DyK0D6Un7Scv4gg9WMTtDbQ&m=3DpiI9X6SNFjQ9dT0MJs= VL5FHAInIjRv7Fbs9wGm3sjP8&s=3DoqNQnXfIgQvTeG7o8SJ6SOSkAcmUk4_ZZN8ts-dy0_o&e= =3D=20 >> the boiler plate text to add here would be the clause starting with the >> sentence =93There are no management objects.=94 but would change=20 >> =93textual conventions=94 to =93oid value assignments" >>=20 >=20 > Isn't that essentially the same statement as the current text in Section = 9.4? True, I just searched for the boilerplate. The mib module simply registers = object identifier values using OBJECT IDENTITY. >> 3) There exist rfc normative references listed in the above url boilerpl= ate not included in the draft >> typically used in rfcs containing mib modules. >=20 > Well, if we use the text you referred to (=93There are no management obje= cts...=94 ), or even keep the current text in 9.4, > no references are needed, right? Right no need to list references you don=92t reference. I bring them up so = that if you may see what is usually added=20 and then you determine if needed or not. Mike MacFaden From nobody Thu Feb 26 02:09:24 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8D1A01CB for ; Wed, 25 Feb 2015 20:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HE_sskRUb9Y for ; Wed, 25 Feb 2015 20:27:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48EA71A0067 for ; Wed, 25 Feb 2015 20:27:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ69611; Thu, 26 Feb 2015 04:27:05 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 04:27:04 +0000 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.71]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 12:27:02 +0800 From: Youjianjie To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-you-opsawg-capwap-separation-for-mp-00.txt Thread-Index: AQHQUXh4jDd8HtAyJkmLajyDUpqBYJ0CTnAw Date: Thu, 26 Feb 2015 04:27:01 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 02:09:23 -0800 Subject: [OPSAWG] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-you-opsawg-capwap-separation-for-mp-00=2Etxt?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 04:27:09 -0000 SGkgYWxsLA0KDQpXZSd2ZSBzdWJtaXR0ZWQgYSBkcmFmdCBhYm91dCBDQVBXQVAgZm9yIHN1cHBv cnRpbmcgbXVsdGktcHJvdmlkZXIgc2NlbmFyaW8uDQpZb3VyIGNvbW1lbnRzIGFyZSBhcHByZWNp YXRlZC4gDQoNClJlZ2FyZHMsDQpKaWFuamllDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWP keS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxNeW5tDLmnIgyNuaXpSAxMTo1OA0K5pS25Lu2 5Lq6OiBTb25naGFpYmluIChBKTsgWW91amlhbmppZTsgU29uZ2hhaWJpbiAoQSk7IFJvbmcgWmhh bmc7IFJvbmcgWmhhbmc7IFlvdWppYW5qaWUNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC15b3Utb3BzYXdnLWNhcHdhcC1zZXBhcmF0aW9uLWZvci1tcC0wMC50eHQN Cg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteW91LW9wc2F3Zy1jYXB3YXAtc2VwYXJh dGlvbi1mb3ItbXAtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEpp YW5qaWUgWW91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wDQpSZXZpc2lvbjoJMDANClRp dGxlOgkJQ0FQV0FQIENvbnRyb2wgYW5kIERhdGEgQ2hhbm5lbCBTZXBhcmF0aW9uIGZvciBNdWx0 aS1wcm92aWRlciBTY2VuYXJpbw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMi0yNQ0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNw0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFy YXRpb24tZm9yLW1wLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS1vcHNhd2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXlvdS1vcHNh d2ctY2Fwd2FwLXNlcGFyYXRpb24tZm9yLW1wLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgQ0FQ V0FQIGNvbnRyb2wgY2hhbm5lbCBhbmQgZGF0YSBjaGFubmVsIHNwbGl0IGFyY2hpdGVjdHVyZSBo YXMNCiAgIHNvbWUgYmVuZWZpdHMsIHN1Y2ggYXMgcmVsaWV2aW5nIHRoZSBjYXBhY2l0eSBwcmVz c3VyZSBvZiB0aGUgQUMsDQogICB3aGljaCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gW0ktRC5pZXRm LW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5lbF0gYW5kDQogICBbSS1ELnh1ZS1vcHNhd2ctY2Fwd2Fw LXNlcGFyYXRpb24tY2FwYWJpbGl0eV0uICBIb3dldmVyLCBvbmx5IHNpbmdsZS0NCiAgIHByb3Zp ZGVyIHNjZW5hcmlvIGlzIGNvbnNpZGVyZWQgc28gZmFyLiAgVGhpcyBkb2N1bWVudCBkaXNjdXNz ZXMgdGhlDQogICB0aGlyZC1wYXJ0eSBXTEFOIHNlcnZpY2UgcHJvdmlkZXIgc2NlbmFyaW8gKGku ZS4gIG11bHRpLXByb3ZpZGVyKSwNCiAgIGFuZCBwcm9wb3NlcyB0byBleHRlbmQgQ0FQV0FQIGZv ciBzdXBwb3J0aW5nIHRoaXMgdXNlIGNhc2UuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0K From nobody Thu Feb 26 12:10:24 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1731A19FE; Thu, 26 Feb 2015 12:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTMOn6bSwQ3n; Thu, 26 Feb 2015 12:10:15 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4DB1A1B0E; Thu, 26 Feb 2015 12:10:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AA5816DA; Thu, 26 Feb 2015 21:10:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CyBCHi_0Tngp; Thu, 26 Feb 2015 21:09:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Feb 2015 21:10:12 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB39320036; Thu, 26 Feb 2015 21:10:12 +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 uC5nB4mqwkf5; Thu, 26 Feb 2015 21:10:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C78CE20031; Thu, 26 Feb 2015 21:10:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 80E073246EC1; Thu, 26 Feb 2015 21:10:08 +0100 (CET) Date: Thu, 26 Feb 2015 21:10:07 +0100 From: Juergen Schoenwaelder To: Kathleen Moriarty Message-ID: <20150226201007.GA32537@elstar.local> Mail-Followup-To: Kathleen Moriarty , The IESG , opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org, opsawg-chairs@ietf.org References: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, The IESG , draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 20:10:19 -0000 Hi, I am not sure what to do about this comment. My take is that the document is primarily scoped on the management interface and 6.003 talks about access control towards the managing system and access control towards the managed device. I certainly agree that devices should be robust, bug free, have no backdoors, be tamper resitant, etc. but then this is, in an ideal world, true for any device. That said, there is already text in the security considerations that devices should make sure credentials are properly protected. Perhaps if we can address this discuss by expanding this sentence: OLD As a consequence, it is crucial to properly protect any security credentials that may be stored on the device (e.g., by using hardware protection mechanisms). NEW As a consequence, it is crucial that devices are robust and tamper resistant, have no backdoors, do not provide services that are not essential for the primary function, and properly protect any security credentials that may be stored on the device (e.g., by using hardware protection mechanisms). /js On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-opsawg-coman-probstate-reqs-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have not had time to read the full draft, but do see a gap in the > security requirements that I'd like to see if we can address. The > section on access controls for management systems and devices reads as > follows: > > Req-ID: 6.003 > > Title: Access control on management system and devices > > Description: Systems acting in a management role must provide an > access control mechanism that allows the security administrator to > restrict which devices can access the managing system (e.g., using > an access control white list of known devices). On the other hand > managed constrained devices must provide an access control > mechanism that allows the security administrator to restrict how > systems in a management role can access the device (e.g., no- > access, read-only access, and read-write access). > > Source: Basic security requirement for use cases where access > control is essential. > > The way I read this, there is no statement about general access > protections to the device outside of what is designated by a security > administrator. I would think a statement on access controls on the > device would be very important in consideration of safety concerns that > put a strong need for security on such devices (medical, environmental > monitors, etc.). Are there additional access mechanisms to the device > besides what is possible by the management connection? Could there be > factory defaults in place with local access work-arounds or even wireless > int he even that there are issues accessing devices from management > stations? Do these cause security problems? Are there ports other than > those for management open that could lead to security breaches? Or are > these out-of-scope because the discussion is about management > connections? If it's out-of-scope, it would be good to state that it is > even though that would be a concern. Text on this should be added to the > security considerations section as a general discussion if it's a > concern, but not in scope, similar to what was done for privacy. > > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 26 12:10:25 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5A3001A1B48; Thu, 26 Feb 2015 12:10:19 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1731A19FE; Thu, 26 Feb 2015 12:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTMOn6bSwQ3n; Thu, 26 Feb 2015 12:10:15 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4DB1A1B0E; Thu, 26 Feb 2015 12:10:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AA5816DA; Thu, 26 Feb 2015 21:10:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CyBCHi_0Tngp; Thu, 26 Feb 2015 21:09:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 26 Feb 2015 21:10:12 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB39320036; Thu, 26 Feb 2015 21:10:12 +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 uC5nB4mqwkf5; Thu, 26 Feb 2015 21:10:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C78CE20031; Thu, 26 Feb 2015 21:10:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 80E073246EC1; Thu, 26 Feb 2015 21:10:08 +0100 (CET) Date: Thu, 26 Feb 2015 21:10:07 +0100 From: Juergen Schoenwaelder To: Kathleen Moriarty Message-ID: <20150226201007.GA32537@elstar.local> Mail-Followup-To: Kathleen Moriarty , The IESG , opsawg@ietf.org, warren@kumari.net, draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org, opsawg-chairs@ietf.org References: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: opsawg-chairs@ietf.org, opsawg@ietf.org, The IESG , draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 20:10:19 -0000 Hi, I am not sure what to do about this comment. My take is that the document is primarily scoped on the management interface and 6.003 talks about access control towards the managing system and access control towards the managed device. I certainly agree that devices should be robust, bug free, have no backdoors, be tamper resitant, etc. but then this is, in an ideal world, true for any device. That said, there is already text in the security considerations that devices should make sure credentials are properly protected. Perhaps if we can address this discuss by expanding this sentence: OLD As a consequence, it is crucial to properly protect any security credentials that may be stored on the device (e.g., by using hardware protection mechanisms). NEW As a consequence, it is crucial that devices are robust and tamper resistant, have no backdoors, do not provide services that are not essential for the primary function, and properly protect any security credentials that may be stored on the device (e.g., by using hardware protection mechanisms). /js On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-opsawg-coman-probstate-reqs-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have not had time to read the full draft, but do see a gap in the > security requirements that I'd like to see if we can address. The > section on access controls for management systems and devices reads as > follows: > > Req-ID: 6.003 > > Title: Access control on management system and devices > > Description: Systems acting in a management role must provide an > access control mechanism that allows the security administrator to > restrict which devices can access the managing system (e.g., using > an access control white list of known devices). On the other hand > managed constrained devices must provide an access control > mechanism that allows the security administrator to restrict how > systems in a management role can access the device (e.g., no- > access, read-only access, and read-write access). > > Source: Basic security requirement for use cases where access > control is essential. > > The way I read this, there is no statement about general access > protections to the device outside of what is designated by a security > administrator. I would think a statement on access controls on the > device would be very important in consideration of safety concerns that > put a strong need for security on such devices (medical, environmental > monitors, etc.). Are there additional access mechanisms to the device > besides what is possible by the management connection? Could there be > factory defaults in place with local access work-arounds or even wireless > int he even that there are issues accessing devices from management > stations? Do these cause security problems? Are there ports other than > those for management open that could lead to security breaches? Or are > these out-of-scope because the discussion is about management > connections? If it's out-of-scope, it would be good to state that it is > even though that would be a concern. Text on this should be added to the > security considerations section as a general discussion if it's a > concern, but not in scope, similar to what was done for privacy. > > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 26 12:13:55 2015 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42701A1ADC; Thu, 26 Feb 2015 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0PG1469g_dM; Thu, 26 Feb 2015 12:13:47 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2111A03A2; Thu, 26 Feb 2015 12:13:46 -0800 (PST) Received: by ierx19 with SMTP id x19so20558730ier.3; Thu, 26 Feb 2015 12:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ywKfl48oyv7TZCw2V2dbJdrkHoGWBpjxPVsECJo29as=; b=erpx8Rjp9imR4UTYKUrYfKPVImFtySuSc4dWFeZRD9NZ4IkRY7CrhsUu0pRw8HkZ7O TE6jW6AFqSE5F9K3nod15c/WPZPU312j7qHVgeIlKk2awhPLntl5BWmwMUGB2qYvOxIe +d8OEiwD0cEOBYHnna+g7ISz0pmOJYl/BLVAHiVIt42zV8FLCSQWkLlsDXaJ/3KAVAlT QOhEuwZddLHoYUvneEBvftP4xIcvImHA/VAZ7SIN4yZjaaVfVmmFReZMOBo39t78f9mY mJS2BJhGWV0yDseaUuCDROyfjr48kC6jwKpON7XWjkEH4S8F9y6nhhogpRl0vZ1zL5Cw hd3g== MIME-Version: 1.0 X-Received: by 10.43.0.138 with SMTP id nm10mr1782635icb.56.1424981626094; Thu, 26 Feb 2015 12:13:46 -0800 (PST) Received: by 10.107.12.34 with HTTP; Thu, 26 Feb 2015 12:13:46 -0800 (PST) In-Reply-To: <20150226201007.GA32537@elstar.local> References: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> <20150226201007.GA32537@elstar.local> Date: Thu, 26 Feb 2015 15:13:46 -0500 Message-ID: From: Kathleen Moriarty To: Juergen Schoenwaelder , Kathleen Moriarty , The IESG , "opsawg@ietf.org" , Warren Kumari , draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org, "opsawg-chairs@ietf.org" Content-Type: multipart/alternative; boundary=bcaec50fe3ada28a0e05100363bf Archived-At: Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 20:13:50 -0000 --bcaec50fe3ada28a0e05100363bf Content-Type: text/plain; charset=UTF-8 Hi, On Thu, Feb 26, 2015 at 3:10 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I am not sure what to do about this comment. My take is that the > document is primarily scoped on the management interface and 6.003 > talks about access control towards the managing system and access > control towards the managed device. > > I certainly agree that devices should be robust, bug free, have no > backdoors, be tamper resitant, etc. but then this is, in an ideal > world, true for any device. That said, there is already text in the > security considerations that devices should make sure credentials are > properly protected. Perhaps if we can address this discuss by > expanding this sentence: > > OLD > > As a > consequence, it is crucial to properly protect any security > credentials that may be stored on the device (e.g., by using hardware > protection mechanisms). > > NEW > > As a consequence, it is crucial that devices are robust and tamper > resistant, have no backdoors, do not provide services that are not > essential for the primary function, and properly protect any > security credentials that may be stored on the device (e.g., by > using hardware protection mechanisms). > Yes, that works for me in combination with the updates to the use case draft. Please let me know when the updated draft has been posted. Thank you, Kathleen > > /js > > On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-opsawg-coman-probstate-reqs-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have not had time to read the full draft, but do see a gap in the > > security requirements that I'd like to see if we can address. The > > section on access controls for management systems and devices reads as > > follows: > > > > Req-ID: 6.003 > > > > Title: Access control on management system and devices > > > > Description: Systems acting in a management role must provide an > > access control mechanism that allows the security administrator to > > restrict which devices can access the managing system (e.g., using > > an access control white list of known devices). On the other hand > > managed constrained devices must provide an access control > > mechanism that allows the security administrator to restrict how > > systems in a management role can access the device (e.g., no- > > access, read-only access, and read-write access). > > > > Source: Basic security requirement for use cases where access > > control is essential. > > > > The way I read this, there is no statement about general access > > protections to the device outside of what is designated by a security > > administrator. I would think a statement on access controls on the > > device would be very important in consideration of safety concerns that > > put a strong need for security on such devices (medical, environmental > > monitors, etc.). Are there additional access mechanisms to the device > > besides what is possible by the management connection? Could there be > > factory defaults in place with local access work-arounds or even wireless > > int he even that there are issues accessing devices from management > > stations? Do these cause security problems? Are there ports other than > > those for management open that could lead to security breaches? Or are > > these out-of-scope because the discussion is about management > > connections? If it's out-of-scope, it would be good to state that it is > > even though that would be a concern. Text on this should be added to the > > security considerations section as a general discussion if it's a > > concern, but not in scope, similar to what was done for privacy. > > > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- Best regards, Kathleen --bcaec50fe3ada28a0e05100363bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, Feb 26, 2015 at 3:10 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

I am not sure what to do about this comment. My take is that the
document is primarily scoped on the management interface and 6.003
talks about access control towards the managing system and access
control towards the managed device.

I certainly agree that devices should be robust, bug free, have no
backdoors, be tamper resitant, etc. but then this is, in an ideal
world, true for any device. That said, there is already text in the
security considerations that devices should make sure credentials are
properly protected. Perhaps if we can address this discuss by
expanding this sentence:

OLD

=C2=A0 =C2=A0As a
=C2=A0 =C2=A0consequence, it is crucial to properly protect any security =C2=A0 =C2=A0credentials that may be stored on the device (e.g., by using h= ardware
=C2=A0 =C2=A0protection mechanisms).

NEW

=C2=A0 =C2=A0As a consequence, it is crucial that devices are robust and ta= mper
=C2=A0 =C2=A0resistant, have no backdoors, do not provide services that are= not
=C2=A0 =C2=A0essential for the primary function, and properly protect any =C2=A0 =C2=A0security credentials that may be stored on the device (e.g., b= y
=C2=A0 =C2=A0using hardware protection mechanisms).
Yes, that works for me in combination with the updates to the = use case draft.=C2=A0 Please let me know when the updated draft has been po= sted.

Thank you,
Kathleen=C2=A0

/js

On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-opsawg-coman-probstate-reqs-04: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-= opsawg-coman-probstate-reqs/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I have not had time to read the full draft, but do see a gap in the > security requirements that I'd like to see if we can address.=C2= =A0 The
> section on access controls for management systems and devices reads as=
> follows:
>
>=C2=A0 =C2=A0Req-ID:=C2=A0 6.003
>
>=C2=A0 =C2=A0 Title:=C2=A0 Access control on management system and devi= ces
>
>=C2=A0 =C2=A0 Description:=C2=A0 Systems acting in a management role mu= st provide an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0access control mechanism that allows the sec= urity administrator to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0restrict which devices can access the managi= ng system (e.g., using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an access control white list of known device= s).=C2=A0 On the other hand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0managed constrained devices must provide an = access control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism that allows the security administr= ator to restrict how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0systems in a management role can access the = device (e.g., no-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0access, read-only access, and read-write acc= ess).
>
>=C2=A0 =C2=A0 Source:=C2=A0 Basic security requirement for use cases wh= ere access
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control is essential.
>
> The way I read this, there is no statement about general access
> protections to the device outside of what is designated by a security<= br> > administrator.=C2=A0 I would think a statement on access controls on t= he
> device would be very important in consideration of safety concerns tha= t
> put a strong need for security on such devices (medical, environmental=
> monitors, etc.).=C2=A0 Are there additional access mechanisms to the d= evice
> besides what is possible by the management connection?=C2=A0 Could the= re be
> factory defaults in place with local access work-arounds or even wirel= ess
> int he even that there are issues accessing devices from management > stations?=C2=A0 Do these cause security problems?=C2=A0 Are there port= s other than
> those for management open that could lead to security breaches?=C2=A0 = Or are
> these out-of-scope because the discussion is about management
> connections?=C2=A0 If it's out-of-scope, it would be good to state= that it is
> even though that would be a concern.=C2=A0 Text on this should be adde= d to the
> security considerations section as a general discussion if it's a<= br> > concern, but not in scope, similar to what was done for privacy.
>
>
>
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>



--

Best regards,
Kathleen
--bcaec50fe3ada28a0e05100363bf-- From nobody Thu Feb 26 12:13:56 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1D7511A03A2; Thu, 26 Feb 2015 12:13:50 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42701A1ADC; Thu, 26 Feb 2015 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0PG1469g_dM; Thu, 26 Feb 2015 12:13:47 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2111A03A2; Thu, 26 Feb 2015 12:13:46 -0800 (PST) Received: by ierx19 with SMTP id x19so20558730ier.3; Thu, 26 Feb 2015 12:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ywKfl48oyv7TZCw2V2dbJdrkHoGWBpjxPVsECJo29as=; b=erpx8Rjp9imR4UTYKUrYfKPVImFtySuSc4dWFeZRD9NZ4IkRY7CrhsUu0pRw8HkZ7O TE6jW6AFqSE5F9K3nod15c/WPZPU312j7qHVgeIlKk2awhPLntl5BWmwMUGB2qYvOxIe +d8OEiwD0cEOBYHnna+g7ISz0pmOJYl/BLVAHiVIt42zV8FLCSQWkLlsDXaJ/3KAVAlT QOhEuwZddLHoYUvneEBvftP4xIcvImHA/VAZ7SIN4yZjaaVfVmmFReZMOBo39t78f9mY mJS2BJhGWV0yDseaUuCDROyfjr48kC6jwKpON7XWjkEH4S8F9y6nhhogpRl0vZ1zL5Cw hd3g== MIME-Version: 1.0 X-Received: by 10.43.0.138 with SMTP id nm10mr1782635icb.56.1424981626094; Thu, 26 Feb 2015 12:13:46 -0800 (PST) Received: by 10.107.12.34 with HTTP; Thu, 26 Feb 2015 12:13:46 -0800 (PST) In-Reply-To: <20150226201007.GA32537@elstar.local> References: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> <20150226201007.GA32537@elstar.local> Date: Thu, 26 Feb 2015 15:13:46 -0500 Message-ID: From: Kathleen Moriarty To: Juergen Schoenwaelder , Kathleen Moriarty , The IESG , "opsawg@ietf.org" , Warren Kumari , draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org, "opsawg-chairs@ietf.org" Content-Type: multipart/alternative; boundary=bcaec50fe3ada28a0e05100363bf Archived-At: Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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 Feb 2015 20:13:50 -0000 --bcaec50fe3ada28a0e05100363bf Content-Type: text/plain; charset=UTF-8 Hi, On Thu, Feb 26, 2015 at 3:10 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I am not sure what to do about this comment. My take is that the > document is primarily scoped on the management interface and 6.003 > talks about access control towards the managing system and access > control towards the managed device. > > I certainly agree that devices should be robust, bug free, have no > backdoors, be tamper resitant, etc. but then this is, in an ideal > world, true for any device. That said, there is already text in the > security considerations that devices should make sure credentials are > properly protected. Perhaps if we can address this discuss by > expanding this sentence: > > OLD > > As a > consequence, it is crucial to properly protect any security > credentials that may be stored on the device (e.g., by using hardware > protection mechanisms). > > NEW > > As a consequence, it is crucial that devices are robust and tamper > resistant, have no backdoors, do not provide services that are not > essential for the primary function, and properly protect any > security credentials that may be stored on the device (e.g., by > using hardware protection mechanisms). > Yes, that works for me in combination with the updates to the use case draft. Please let me know when the updated draft has been posted. Thank you, Kathleen > > /js > > On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-opsawg-coman-probstate-reqs-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have not had time to read the full draft, but do see a gap in the > > security requirements that I'd like to see if we can address. The > > section on access controls for management systems and devices reads as > > follows: > > > > Req-ID: 6.003 > > > > Title: Access control on management system and devices > > > > Description: Systems acting in a management role must provide an > > access control mechanism that allows the security administrator to > > restrict which devices can access the managing system (e.g., using > > an access control white list of known devices). On the other hand > > managed constrained devices must provide an access control > > mechanism that allows the security administrator to restrict how > > systems in a management role can access the device (e.g., no- > > access, read-only access, and read-write access). > > > > Source: Basic security requirement for use cases where access > > control is essential. > > > > The way I read this, there is no statement about general access > > protections to the device outside of what is designated by a security > > administrator. I would think a statement on access controls on the > > device would be very important in consideration of safety concerns that > > put a strong need for security on such devices (medical, environmental > > monitors, etc.). Are there additional access mechanisms to the device > > besides what is possible by the management connection? Could there be > > factory defaults in place with local access work-arounds or even wireless > > int he even that there are issues accessing devices from management > > stations? Do these cause security problems? Are there ports other than > > those for management open that could lead to security breaches? Or are > > these out-of-scope because the discussion is about management > > connections? If it's out-of-scope, it would be good to state that it is > > even though that would be a concern. Text on this should be added to the > > security considerations section as a general discussion if it's a > > concern, but not in scope, similar to what was done for privacy. > > > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- Best regards, Kathleen --bcaec50fe3ada28a0e05100363bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, Feb 26, 2015 at 3:10 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
Hi,

I am not sure what to do about this comment. My take is that the
document is primarily scoped on the management interface and 6.003
talks about access control towards the managing system and access
control towards the managed device.

I certainly agree that devices should be robust, bug free, have no
backdoors, be tamper resitant, etc. but then this is, in an ideal
world, true for any device. That said, there is already text in the
security considerations that devices should make sure credentials are
properly protected. Perhaps if we can address this discuss by
expanding this sentence:

OLD

=C2=A0 =C2=A0As a
=C2=A0 =C2=A0consequence, it is crucial to properly protect any security =C2=A0 =C2=A0credentials that may be stored on the device (e.g., by using h= ardware
=C2=A0 =C2=A0protection mechanisms).

NEW

=C2=A0 =C2=A0As a consequence, it is crucial that devices are robust and ta= mper
=C2=A0 =C2=A0resistant, have no backdoors, do not provide services that are= not
=C2=A0 =C2=A0essential for the primary function, and properly protect any =C2=A0 =C2=A0security credentials that may be stored on the device (e.g., b= y
=C2=A0 =C2=A0using hardware protection mechanisms).
Yes, that works for me in combination with the updates to the = use case draft.=C2=A0 Please let me know when the updated draft has been po= sted.

Thank you,
Kathleen=C2=A0

/js

On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-opsawg-coman-probstate-reqs-04: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-= opsawg-coman-probstate-reqs/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I have not had time to read the full draft, but do see a gap in the > security requirements that I'd like to see if we can address.=C2= =A0 The
> section on access controls for management systems and devices reads as=
> follows:
>
>=C2=A0 =C2=A0Req-ID:=C2=A0 6.003
>
>=C2=A0 =C2=A0 Title:=C2=A0 Access control on management system and devi= ces
>
>=C2=A0 =C2=A0 Description:=C2=A0 Systems acting in a management role mu= st provide an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0access control mechanism that allows the sec= urity administrator to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0restrict which devices can access the managi= ng system (e.g., using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an access control white list of known device= s).=C2=A0 On the other hand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0managed constrained devices must provide an = access control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism that allows the security administr= ator to restrict how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0systems in a management role can access the = device (e.g., no-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0access, read-only access, and read-write acc= ess).
>
>=C2=A0 =C2=A0 Source:=C2=A0 Basic security requirement for use cases wh= ere access
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control is essential.
>
> The way I read this, there is no statement about general access
> protections to the device outside of what is designated by a security<= br> > administrator.=C2=A0 I would think a statement on access controls on t= he
> device would be very important in consideration of safety concerns tha= t
> put a strong need for security on such devices (medical, environmental=
> monitors, etc.).=C2=A0 Are there additional access mechanisms to the d= evice
> besides what is possible by the management connection?=C2=A0 Could the= re be
> factory defaults in place with local access work-arounds or even wirel= ess
> int he even that there are issues accessing devices from management > stations?=C2=A0 Do these cause security problems?=C2=A0 Are there port= s other than
> those for management open that could lead to security breaches?=C2=A0 = Or are
> these out-of-scope because the discussion is about management
> connections?=C2=A0 If it's out-of-scope, it would be good to state= that it is
> even though that would be a concern.=C2=A0 Text on this should be adde= d to the
> security considerations section as a general discussion if it's a<= br> > concern, but not in scope, similar to what was done for privacy.
>
>
>
>

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49= 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>



--

Best regards,
Kathleen
--bcaec50fe3ada28a0e05100363bf-- From nobody Sat Feb 28 06:07:00 2015 Return-Path: X-Original-To: expand-draft-ietf-opsawg-coman-probstate-reqs.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 433AA1A037D; Sat, 28 Feb 2015 05:52:20 -0800 (PST) X-Original-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-opsawg-coman-probstate-reqs.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253831A0155 for ; Sat, 28 Feb 2015 05:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6L9oZOEKTbk for ; Sat, 28 Feb 2015 05:52:16 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983131A00E9 for ; Sat, 28 Feb 2015 05:52:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1EDEBF78; Sat, 28 Feb 2015 14:52:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id cCTyQxt7dwcw; Sat, 28 Feb 2015 14:51:42 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 28 Feb 2015 14:52:13 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8D8420036; Sat, 28 Feb 2015 14:52:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jxPc8ejolHul; Sat, 28 Feb 2015 14:52:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B5F920031; Sat, 28 Feb 2015 14:52:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9460132483AF; Sat, 28 Feb 2015 14:52:10 +0100 (CET) Date: Sat, 28 Feb 2015 14:52:09 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (Nokia - DE/Munich)" Message-ID: <20150228135209.GA36283@elstar.local> References: <20150219161002.7059.28113.idtracker@ietfa.amsl.com> <20150226201007.GA32537@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: X-Mailman-Approved-At: Sat, 28 Feb 2015 06:06:59 -0800 Cc: "draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org" Subject: Re: [OPSAWG] Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 28 Feb 2015 13:52:20 -0000 There were the other edits that Dan proposed for this document. I do not know who holds the pen and where the latest .xml of this document is. /js On Sat, Feb 28, 2015 at 01:22:17PM +0000, Ersue, Mehmet (Nokia - DE/Munich) wrote: > Is the only AI now uploading an update? > > Then pls go ahead. > > Cheers, > Mehmet > > From: ext Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] > Sent: Thursday, February 26, 2015 9:14 PM > To: Juergen Schoenwaelder; Kathleen Moriarty; The IESG; opsawg@ietf.org; Warren Kumari; draft-ietf-opsawg-coman-probstate-reqs.all@ietf.org; opsawg-chairs@ietf.org > Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS) > > Hi, > > On Thu, Feb 26, 2015 at 3:10 PM, Juergen Schoenwaelder > wrote: > Hi, > > I am not sure what to do about this comment. My take is that the > document is primarily scoped on the management interface and 6.003 > talks about access control towards the managing system and access > control towards the managed device. > > I certainly agree that devices should be robust, bug free, have no > backdoors, be tamper resitant, etc. but then this is, in an ideal > world, true for any device. That said, there is already text in the > security considerations that devices should make sure credentials are > properly protected. Perhaps if we can address this discuss by > expanding this sentence: > > OLD > > As a > consequence, it is crucial to properly protect any security > credentials that may be stored on the device (e.g., by using hardware > protection mechanisms). > > NEW > > As a consequence, it is crucial that devices are robust and tamper > resistant, have no backdoors, do not provide services that are not > essential for the primary function, and properly protect any > security credentials that may be stored on the device (e.g., by > using hardware protection mechanisms). > > Yes, that works for me in combination with the updates to the use case draft. Please let me know when the updated draft has been posted. > > Thank you, > Kathleen > > /js > > On Thu, Feb 19, 2015 at 08:10:02AM -0800, Kathleen Moriarty wrote: > > Kathleen Moriarty has entered the following ballot position for > > draft-ietf-opsawg-coman-probstate-reqs-04: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have not had time to read the full draft, but do see a gap in the > > security requirements that I'd like to see if we can address. The > > section on access controls for management systems and devices reads as > > follows: > > > > Req-ID: 6.003 > > > > Title: Access control on management system and devices > > > > Description: Systems acting in a management role must provide an > > access control mechanism that allows the security administrator to > > restrict which devices can access the managing system (e.g., using > > an access control white list of known devices). On the other hand > > managed constrained devices must provide an access control > > mechanism that allows the security administrator to restrict how > > systems in a management role can access the device (e.g., no- > > access, read-only access, and read-write access). > > > > Source: Basic security requirement for use cases where access > > control is essential. > > > > The way I read this, there is no statement about general access > > protections to the device outside of what is designated by a security > > administrator. I would think a statement on access controls on the > > device would be very important in consideration of safety concerns that > > put a strong need for security on such devices (medical, environmental > > monitors, etc.). Are there additional access mechanisms to the device > > besides what is possible by the management connection? Could there be > > factory defaults in place with local access work-arounds or even wireless > > int he even that there are issues accessing devices from management > > stations? Do these cause security problems? Are there ports other than > > those for management open that could lead to security breaches? Or are > > these out-of-scope because the discussion is about management > > connections? If it's out-of-scope, it would be good to state that it is > > even though that would be a concern. Text on this should be added to the > > security considerations section as a general discussion if it's a > > concern, but not in scope, similar to what was done for privacy. > > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > -- > > Best regards, > Kathleen -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103