From adonati@motorola.com Sun Nov 1 06:58:07 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84C63A6889 for ; Sun, 1 Nov 2009 06:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K00kDaPMcNy2 for ; Sun, 1 Nov 2009 06:58:07 -0800 (PST) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 2AA903A6875 for ; Sun, 1 Nov 2009 06:58:07 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: adonati@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1257087496!27166090!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 15904 invoked from network); 1 Nov 2009 14:58:16 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-14.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Nov 2009 14:58:16 -0000 Received: from il27exr04.cig.mot.com (il27exr04.mot.com [10.17.196.73]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id nA1EwCqe015272 for ; Sun, 1 Nov 2009 07:58:16 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id nA1EwBnh018562 for ; Sun, 1 Nov 2009 08:58:11 -0600 (CST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id nA1EwBtJ018556 for ; Sun, 1 Nov 2009 08:58:11 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Nov 2009 09:57:49 -0500 Message-ID: In-Reply-To: <20091029111229.GA20307@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] wg last call on the (d)tls transport model Thread-Index: AcpYiODHCnENnEukRAetovx4V3A/YwB1KMDA References: <20091029111229.GA20307@elstar.local> From: "Donati Andrew-MGIA0477" To: "Juergen Schoenwaelder" X-CFilter-Loop: Reflected Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 14:58:08 -0000 JS >Please do review the documents and post your comments on this list until November 14, 2009. Please also post to the list if you JS >have read the documents and you are fine with them. It is very useful to know how many people have read the documents. I read the (d)tls transport model document and here is the full summary of my comments: (The first 3 items were posted to the list previously)=20 1. tlstmServerAuthFailure notification. Will it be helpful for network administrators to know the current count of how many times the presented server certificate is invalid in each tlstmServerAuthFailure notification? If so, it may be useful to have tlstmSessionInvalidServerCertificates as an additional binding, especially if this object is the trigger. 2. Standard authentication failure notification. There may have been some previous discussions about possibly using the standard authenticationFailure trap for tlstm (client) authentication failures. Will this be used or mentioned in the document? 3. tlstmServerCertNotFound Will it be feasible to have a scalar object that serves as a counter for this event?=20 If implemented, it can be added to this notification. 4. Section 6.4 Configuration Tables There is double verb, (is are), in the 2nd sentence. 5. Section 6.4.1 Notifications This section mentions a notification (tlstmServerAuthFailure) that alerts management stations when the server's presented certificate does not meet the expected value but does not appear to have a statement that directly refers to the tlstmServerCertNotFound notification. -Andy Donati From Pasi.Eronen@nokia.com Fri Nov 6 03:15:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F3493A68AA for ; Fri, 6 Nov 2009 03:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.216 X-Spam-Level: X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[AWL=-2.317, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAmjuelXwyFr for ; Fri, 6 Nov 2009 03:15:36 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 46AC03A689E for ; Fri, 6 Nov 2009 03:15:35 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA6BFtWX031797 for ; Fri, 6 Nov 2009 13:15:56 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 13:15:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 13:15:36 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 6 Nov 2009 12:15:18 +0100 From: To: Date: Fri, 6 Nov 2009 12:15:14 +0100 Thread-Topic: [Isms] wg last call on the (d)tls transport model Thread-Index: AcpYiMAzsIkGQPMRQ1qHp8jCzwTAEAGSThRQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F81BEAD@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091029111229.GA20307@elstar.local> In-Reply-To: <20091029111229.GA20307@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Nov 2009 11:15:36.0022 (UTC) FILETIME=[76A61760:01CA5ED2] X-Nokia-AV: Clean Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 11:15:38 -0000 Some random comments scribbled on printout during my flight earlier today (or yesterday, depending on your point of view :-): - How the notification originator authenticates the other end (TLS server) when fingerprints are not used is very unclear (the fingerprint case is clear). Section 5.3, step 3b, suggests we could use path validation, but it doesn't e.g. say what the "reference identity" (in draft-saintandre-tls-server-id-check terminology) would be. Perhaps the MIB should allow specifying that reference identity. (MIB, tlstmAddrTable, is relevant here.) (I guess this applies to command generators, too, to some degree at least -- they also act as TLS clients, and have to authenticate the server somehow.) - While TLS supports several different authentication mechanism (X.509 certs, OpenPGP certs, pre-shared keys, Kerberos, SRP, ...), TLSTM supports only one of them (X.509 certs). This should be mentioned in e.g. Section 1 and Section 4.1. - Section 1.1, 2nd to last paragraph, and Section 3.1.3: These parts should probably explicitly say that the concept of "session" here is totally unrelated to TLS sessions in RFC 5246 (which are TLS-internal optimization detail not visible to TLSTM). But the name "tlsSessionID" is very poorly chosen, since it's very different from the TLS SessionID in RFC 5246. - Section 5.3 (last para) and Section 8.2: (D)TLS does have the "server_name" extension that does allow doing this. - MIB, Snmp*Address TCs: do we need four pages worth of new TCs to just describe (IPv4 address/IPv6 address/hostname)+port?=20 Surely many existing MIBs use address+port, too, and we could import from somewhere? - MIB, Fingerprint TC, last paragraph: this is not really consistent with how certificate fingerprints are used in many other protocols -- usually we compare just the fingerprint (not the whole certificate), and assume it's produced by a good hash function. - MIB, tlstmCertToSNSANType: is SecurityName case sensitive? If it is, you need to specify the case for IPv6 address, and probably normalize the dNSName and domain part of rfc822name (e.g., convert to lower case). - MIB, tlstmCertToSNSANType: how would othername be converted to SnmpAdminString? (which is UTF-8, so "take the raw DER" does not work -- and it would be very administator-unfriendly, too) - Sections 3.3 and others: the document has snmpTLSDomain, snmpDTLSUDPDomain and snmpDTLSSCTPDomain. Probably for consistency, the first should be snmpTLSTCPDomain, since SCTP would also normally use TLS, not DTLS (there's a draft proposing how to run DTLS over SCTP, but it's just work in progress, not something that can be done today). - Section 2.1: if the CG/NO is always the (D)TLS client, and it MUST be authenticated (2nd bullet), then why is authenticating the client only SHOULD? (1st bullet) - The openSession ASI in Section 4.4.1 looks very different from the SSHTM ASI -- is this intentional? - Section 4.4.1: "this restriction is not needed for TLS or DTLS over SCTP": this restriction is present in TLS-over-TCP/SCTP, too, but TCP/SCTP take care of ensuring that is unique. - Section 4.4.2 and 4.4.3: I think these sections should be just deleted -- these are TLS internal details. Furthermore, for normal TLS (or DTLS, when a single datagram contains multiple DTLS records), TLSTM cannot even determine "wholeTlsMsgLength", since that would require parsing the TLS messages (which would be a layering violation). Section 5.1.1 is also a bit questionable; it also seems to suggest parsing DTLS records by TLSTM. And the details aren't quite right: the same demultiplexing (mapping incoming UDP packet, based on tuple, to the right DTLS connection/context) has to happen for DTLS handshake messages, too, not just DTLS application data messages. - Section 8.1, 1st paragraph: the last sentence of this paragraph is very confusing, since the sessions this document talks about are totally unrelated to TLS sessions (and TLS session resumption). Besides, all TLS implementations support session resumption, so this SHOULD is not really needed in this document. - Section 8.1, 2nd paragraph: Separate ports might be a reasonable idea, but I don't understand what the rest of the paragraph is saying... - Section 10: SSHTM uses ports >1023 -- should be good enough for TLSTM, too (the criteria for allocating ports <1023 is much stricter). - In normal SNMP-over-UDP, if e.g. the notification receiver restarts, that's not a problem: at least if the notification generator didn't send anything exactly when the restart was ongoing, everything will continue just fine after the restart. But when using DTLS-over-UDP, if the notification receiver restarts, the notification generator has to know that it needs to start a new DTLS "connection" (because otherwise the receiver will just silently drop all the packets it gets). The same problem has been discussed for syslog-over-DTLS recently, and draft-seggelmann-tls-dtls-heartbeat proposes one possible solution. In SNMP most requests result in a response, so if no response is seen, *some* component will know there's something wrong. But since TLSTM isn't supposed to know about PDU types, it might be architecturally slightly tricky how opening a new DTLS "connection" should be triggered here. But the document should probably say something about this issue. - Should the document say something about MTU/avoiding fragmentation for DTLS-over-UDP? - DTLS allows multiple DTLS records in a single datagram -- should the document say something about this? - Should the document say something about SCTP Partial Reliability, or use of SCTP streams? Minor editorial comments: - The document title should have the acronym "TLS" in it. - Section 4.1.1: While the actual details of how self-signed certificates can be used in TLSTM (in the rest of the spec) look mostly OK, I would recommend against using the term "trust anchor" to refer to self-signed end-entity certificates. - Section 3.1.1, item 4, 2nd paragraph: this is quite unclear, and goes into details that are IMHO not relevant for TLSTM. Perhaps something like "Most TLS cipher suites do encryption" ? - Section 3.1.1, item 5,: the sentence about "amplification" is quite unclear; the main purpose of DTLS cookie exchange is to limit server-side resource consumption, not amplification (and "detecting" amplification could be tricky). - Section 3.1.2: This text should probably mention that TLS=20 does not have any NULL integrity cipher suites. - MIB, tlstmParamsEntry: should "usable" be "unusable"? - Section 9, "DTLS is more vulnerable to denial of service attacks". Well, a hypothetical version of DTLS that didn't include the cookie exchange might be more vulnerable, but since we don't have such a version, this isn't really true. - Global: s/US-US-ASCII/US-ASCII/; - The reference [x509] looks wrong. - Appendix A and B: I would suggest deleting these.=20 - Appendix C: "blueberry" is not a valid rfc822Name ("blueberry@example.com" would be) Best regards, Pasi From wjhns1@hardakers.net Fri Nov 6 06:28:47 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CEA328C155 for ; Fri, 6 Nov 2009 06:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRNC8gJeRbh6 for ; Fri, 6 Nov 2009 06:28:46 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 74B1A3A69CD for ; Fri, 6 Nov 2009 06:28:46 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A1C9898279; Fri, 6 Nov 2009 06:29:09 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <20091029111229.GA20307@elstar.local> <808FD6E27AD4884E94820BC333B2DB774E7F81BEAD@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 06 Nov 2009 06:29:09 -0800 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F81BEAD@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Fri, 6 Nov 2009 12:15:14 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] wg last call on the (d)tls transport model X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:28:47 -0000 >>>>> On Fri, 6 Nov 2009 12:15:14 +0100, said: PE> Some random comments scribbled on printout during my flight earlier PE> today (or yesterday, depending on your point of view :-): Thanks for the comments Pasi. I'll responding to them in greater detail shortly. (Quite possibly after *my* plane ride). -- Wes Hardaker Cobham Analytic Solutions From mundy@tislabs.com Mon Nov 9 09:42:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CA228C15E for ; Mon, 9 Nov 2009 09:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqpFWagAQB+s for ; Mon, 9 Nov 2009 09:42:49 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3B75728C105 for ; Mon, 9 Nov 2009 09:42:49 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nA9HhEQI018283 for ; Mon, 9 Nov 2009 11:43:14 -0600 Received: from worf.ads.sparta.com (worf.sparta.com [157.185.61.21]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nA9HhFaM016847 for ; Mon, 9 Nov 2009 11:43:15 -0600 Received: from calvin.travel.tislabs.com ([133.93.160.63]) by worf.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 11:43:12 -0600 Received: from [10.0.1.4] (localhost [127.0.0.1]) by calvin.travel.tislabs.com (Postfix) with ESMTP id 018661064735; Tue, 10 Nov 2009 02:43:24 +0900 (JST) Mime-Version: 1.0 Message-Id: Date: Tue, 10 Nov 2009 02:43:22 +0900 To: isms@ietf.org From: Russ Mundy Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 09 Nov 2009 17:43:12.0585 (UTC) FILETIME=[1BE13B90:01CA6164] Subject: [Isms] IETF76 WG Meeting Reminder & Request X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 17:42:50 -0000 I wanted to remind folks that our meeting at IETF76 will begin in about half day. Juergen has posted the agenda as well as the slide sets that we currently have so please take a look. The material is available in the ISMS section at: https://datatracker.ietf.org/meeting/76/materials.html I'd also like to remind folks that cannot attend the meeting in person that remote participation is possible and encouraged. Jabber and audio is available by clicking on the 'right' icons on the isms line on the following page: http://tools.ietf.org/agenda/76/#2009-11-09_1500 (Warning - Requests comes next :-) I would like to have volunteers identified before the meeting begins to do jabber scribe duty and minute taker duty. These are both very important things that we as a WG need to do to meet our Charter deliverables. It's also a chance for people to make an important contribution to the WG that doesn't require a long-term time commitment. If you can volunteer for either of these, please send mail to the list (or if you prefer, directly to me). Hope to see & hear from many of you later today. Russ From j.schoenwaelder@jacobs-university.de Mon Nov 16 12:00:29 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87BA13A6AFB for ; Mon, 16 Nov 2009 12:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlAD+u-iK-6g for ; Mon, 16 Nov 2009 12:00:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2C9BC28C20A for ; Mon, 16 Nov 2009 12:00:20 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6FF3C001D for ; Mon, 16 Nov 2009 21:00:18 +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 JTLu9SD-hica; Mon, 16 Nov 2009 21:00:18 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26DFFC001C; Mon, 16 Nov 2009 21:00:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 00355E26105; Mon, 16 Nov 2009 21:00:16 +0100 (CET) Date: Mon, 16 Nov 2009 21:00:16 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20091116200016.GA3721@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] dtls wg last call - more reviews needed X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:00:29 -0000 Hi, I like to remind WG members that we need more reviews of the DTLS transport model to move it along. So far, I have seen three reviews: - Andrew Donati - Pasi Eronen - Juergen Schoenwaelder More reviews are need to move this document forward. If you have read the document and you do not have comments, please let the chairs know. Without sufficient WG review, the document is not going to move to the IESG. Thanks, /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Mon Nov 16 13:16:53 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCCC3A688A for ; Mon, 16 Nov 2009 13:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqF9Md8Vxjlo for ; Mon, 16 Nov 2009 13:16:53 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BB4F03A69B5 for ; Mon, 16 Nov 2009 13:16:52 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 56BEA982DA for ; Mon, 16 Nov 2009 13:16:51 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20091116200016.GA3721@elstar.local> Date: Mon, 16 Nov 2009 13:16:51 -0800 In-Reply-To: <20091116200016.GA3721@elstar.local> (Juergen Schoenwaelder's message of "Mon, 16 Nov 2009 21:00:16 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsdtls wg last call - more reviews needed X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:16:53 -0000 >>>>> On Mon, 16 Nov 2009 21:00:16 +0100, Juergen Schoenwaelder said: JS> More reviews are need to move this document forward. It should be worth noting that the list is missing people that have already reviewed the draft and provide comments before the last call. Are you requesting past participants to re-read the document? If so, you should make that explicitly clear. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Nov 16 13:28:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F37B3A68AC for ; Mon, 16 Nov 2009 13:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TCZozoqcXUb for ; Mon, 16 Nov 2009 13:28:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3EBE73A66B4 for ; Mon, 16 Nov 2009 13:28:20 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17C2EC001D; Mon, 16 Nov 2009 22:28:19 +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 RWuMjGAVrQUH; Mon, 16 Nov 2009 22:28:18 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 199CAC0012; Mon, 16 Nov 2009 22:28:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AAF29E26293; Mon, 16 Nov 2009 22:28:16 +0100 (CET) Date: Mon, 16 Nov 2009 22:28:16 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20091116212816.GA3846@elstar.local> Mail-Followup-To: Wes Hardaker , "isms@ietf.org" References: <20091116200016.GA3721@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] Ismsdtls wg last call - more reviews needed X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 21:28:21 -0000 On Mon, Nov 16, 2009 at 10:16:51PM +0100, Wes Hardaker wrote: > >>>>> On Mon, 16 Nov 2009 21:00:16 +0100, Juergen Schoenwaelder said: > > JS> More reviews are need to move this document forward. > > It should be worth noting that the list is missing people that have > already reviewed the draft and provide comments before the last call. > Are you requesting past participants to re-read the document? If so, > you should make that explicitly clear. I prefer that WG members review and comment on the latest version. If participants have reviewed earlier versions, it should not be too much effort to check the deltas using the tools pages: http://tools.ietf.org/html/draft-ietf-isms-dtls-tm-01 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jsalowey@cisco.com Thu Nov 19 12:09:16 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5143A67D3 for ; Thu, 19 Nov 2009 12:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qayzgzBjBXnE for ; Thu, 19 Nov 2009 12:09:15 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AC13E3A67AF for ; Thu, 19 Nov 2009 12:09:15 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACI1BUurRN+K/2dsb2JhbAC+IYkjCY5IAoJPgWoE X-IronPort-AV: E=Sophos;i="4.44,772,1249257600"; d="scan'208";a="106820514" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 19 Nov 2009 20:09:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAJK9DtH017368; Thu, 19 Nov 2009 20:09:13 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 12:09:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 12:09:11 -0800 Message-ID: In-Reply-To: <20091116200016.GA3721@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] dtls wg last call - more reviews needed Thread-Index: Acpm94daH8KlS0KDT/Sh+0nRqiWybwCXIGag References: <20091116200016.GA3721@elstar.local> From: "Joseph Salowey (jsalowey)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 19 Nov 2009 20:09:13.0461 (UTC) FILETIME=[29E65250:01CA6954] Subject: Re: [Isms] dtls wg last call - more reviews needed X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 20:09:16 -0000 Hi Juergen, I intend to review the document, but I will probably not get to it until later next week. =20 Cheers, Joe =20 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of Juergen Schoenwaelder > Sent: Monday, November 16, 2009 12:00 PM > To: isms@ietf.org > Subject: [Isms] dtls wg last call - more reviews needed >=20 > Hi, >=20 > I like to remind WG members that we need more reviews of the=20 > DTLS transport model to move it along. So far, I have seen=20 > three reviews: >=20 > - Andrew Donati > - Pasi Eronen > - Juergen Schoenwaelder >=20 > More reviews are need to move this document forward. If you=20 > have read the document and you do not have comments, please=20 > let the chairs know. > Without sufficient WG review, the document is not going to=20 > move to the IESG. >=20 > Thanks, >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms >=20 From j.schoenwaelder@jacobs-university.de Fri Nov 20 05:47:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA3B3A6A98 for ; Fri, 20 Nov 2009 05:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlM2Qt-HALpu for ; Fri, 20 Nov 2009 05:47:40 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4B5C53A6A70 for ; Fri, 20 Nov 2009 05:47:40 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54881C0014; Fri, 20 Nov 2009 14:47:33 +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 hrJzSnRg6Evj; Fri, 20 Nov 2009 14:47:32 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F2C9C0008; Fri, 20 Nov 2009 14:47:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 78453E2E120; Fri, 20 Nov 2009 14:47:31 +0100 (CET) Date: Fri, 20 Nov 2009 14:47:31 +0100 From: Juergen Schoenwaelder To: "Joseph Salowey (jsalowey)" Message-ID: <20091120134731.GD3973@elstar.local> Mail-Followup-To: "Joseph Salowey (jsalowey)" , "isms@ietf.org" References: <20091116200016.GA3721@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] dtls wg last call - more reviews needed X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:47:41 -0000 On Thu, Nov 19, 2009 at 09:09:11PM +0100, Joseph Salowey (jsalowey) wrote: > Hi Juergen, > > I intend to review the document, but I will probably not get to it until > later next week. Great. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Nov 20 05:54:32 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1AD93A6ACA for ; Fri, 20 Nov 2009 05:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmEjR1VwU14u for ; Fri, 20 Nov 2009 05:54:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F35B83A6AD1 for ; Fri, 20 Nov 2009 05:54:31 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DFB2C0014 for ; Fri, 20 Nov 2009 14:54:29 +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 MC-Tz+hNu3Gs; Fri, 20 Nov 2009 14:54:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A511C0008; Fri, 20 Nov 2009 14:54:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 35EF8E2E15F; Fri, 20 Nov 2009 14:54:27 +0100 (CET) Date: Fri, 20 Nov 2009 14:54:27 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20091120135427.GE3973@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] new radius vacm document editor X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:54:33 -0000 Hi, Randy Presuhn has agreed to take the pen for the RADIUS/VACM document so that we can move this work item forward. Randy has been one of the editors of the VACM document (RFC3415) adn this should help with getting the SNMP side align well with VACM. The current plan is to get a -00 version of a WG document out soon based on David Nelson's / Kaushik Narayan's individual draft, which likely contains a number of open issues that we then try to resolve here on the mailing list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dnelson@elbrysnetworks.com Fri Nov 20 08:13:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4213A68AF for ; Fri, 20 Nov 2009 08:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg9TEFyg2nW2 for ; Fri, 20 Nov 2009 08:13:18 -0800 (PST) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id A97413A67A6 for ; Fri, 20 Nov 2009 08:13:17 -0800 (PST) Received: (qmail 28347 invoked from network); 20 Nov 2009 16:13:13 -0000 Received: from dbn-imac.elbrysnetworks.com (172.22.19.12) by gumby.elbrysnetworks.com with SMTP; 20 Nov 2009 16:13:13 -0000 Message-Id: From: "David B. Nelson" To: isms@ietf.org In-Reply-To: <20091120135427.GE3973@elstar.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 11:13:13 -0500 References: <20091120135427.GE3973@elstar.local> X-Mailer: Apple Mail (2.936) Subject: Re: [Isms] new radius vacm document editor X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:13:19 -0000 > Randy Presuhn has agreed to take the pen for the RADIUS/VACM document > so that we can move this work item forward. Thanks to Randy for offering his assistance. > Randy has been one of the editors of the VACM document (RFC3415) > adn this should help with getting the SNMP side align well with VACM. Indeed. Kaushik and I were a bit stuck waiting for some expert consultation on the "SNMP side", as you say. > The current plan is to get a -00 version of a WG document out soon > based on David Nelson's / Kaushik Narayan's individual draft, which > likely contains a number of open issues that we then try to resolve > here on the mailing list. I will shortly publish a -01 of the individual draft, representing the state of the document as it was presented to Randy, to create a snapshot of the work. The WG should not be confused that is is intended to be the version that gets WG review and comment. It's primarily for short-term archival purposes. From luchuk@snmp.com Fri Nov 20 12:38:49 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241B728C0E1 for ; Fri, 20 Nov 2009 12:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIZPTM1QC2Jn for ; Fri, 20 Nov 2009 12:38:47 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by core3.amsl.com (Postfix) with ESMTP id 7DE463A67DD for ; Fri, 20 Nov 2009 12:38:46 -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 PAA15539; Fri, 20 Nov 2009 15:38:41 -0500 (EST) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id PAA05533; Fri, 20 Nov 2009 15:38:37 -0500 (EST) Date: Fri, 20 Nov 2009 15:38:37 -0500 (EST) From: Alan Luchuk Message-Id: <200911202038.PAA05533@adminfs.snmp.com> To: isms@ietf.org X-Mailman-Approved-At: Fri, 20 Nov 2009 14:21:46 -0800 Cc: luchuk@snmp.com Subject: [Isms] Review of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 20:38:49 -0000 Hello, I have reviewed draft-ietf-isms-dtls-tm-01.txt; my comments are included below. My apology for my late review of this document. My overall comment is that the document is in generally good shape, could be advanced, and that my company is interested in it advancing. My thanks to the author and reviewers; their hard work shows! I reviewed a much earlier draft, and appreciate the additional technical completeness and clarification in this latest version. I especially appreciate the "implementation hints" and the well-thought-out and thorough specification of mapping X.509 certficates to SNMP security names. The engineering effort shows. Most of what I noted were minor typograpical errors and possible wording changes. There are a places where more clarification might be helpful. I suggest changes to the MIB that are NOT ESSENTIAL to the correct opera- tion or implementability of SNMP over (D)TLS, but the presence or absence of the suggested changes may affect the utility of othe MIB objects. My company has not implemented SNMP over (D)TLS, but we are interested in doing so. We have customer demand for SNMP over (D)TLS. The specific suggestions are listed in the order in which they appear in the draft. I've catagorized the changes below as "typo", "wording", "formatting", "clarification", or "content error" changes. Section 1: Page 6, only sentence: (wording) --------------------------------------------- Suggest changing "equally as legitimate." to "equally valid." Section 2.1 Page 8, first bulleted item: (clarification) --------------------------------------------------------- The text reads: The TLS Transport Model SHOULD always use authentication of both the server and the client. An explanation of why this is true would be helpful for implementors who do not understand security as thoroughly as those on the ISMS WG. Section 2.1 Page 8: (formatting/typo) -------------------------------------- There is a straggling item number 3 that appears to be the heading "How the TLSTM fits into the Transport Subsystem". Suggest fixing this. Section 2.1 Page 9: (formatting) --------------------------------- If possible, fixing the page breaks so that the diagram appears on a single page. This applies to other diagrams as well. Section 3.1.1 Page 10, item number 1: (wording) ------------------------------------------------ The text reads: 1. Modification of Information - The modification threat is the danger that some unauthorized entity may alter in-transit SNMP ^^^^ Suggest change: 1. Modification of Information - The modification threat is the danger that an unauthorized entity may alter in-transit SNMP ^^ Section 3.1.1 Page 12, item number 5, second to last paragraph: (typo) ----------------------------------------------------------------------- The text reads: Implementations are not required to perform the stateless cookie exchange for every DTLS handshakes but in environments where ^ Suggest removing the "s" from "handshakes". Section 4.1.1 Page 15, second bulleted text, fourth paragraph: (typo) ---------------------------------------------------------------------- The text reads: o Identifies a certificate issuer's fingerprint and allows a child certificate's subjectAltName or CommonName to be mapped to the tmSecurityNome." ^ Suggest changing "tmSecurityNome." to "tmSecurityName." Section 4.3.1 Page 17, first paragraph, last sentence: (wording) ----------------------------------------------------------------- The text reads: This document specifies three TLS and DTLS based Transport Domains for use: the snmpTLSDomain, the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain. Suggested text change: This document specifies the snmpTLSDomain, the snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains. There are a few other places in the document where this suggested change could be made. Section 4.3.1 Page 17, second paragraph: (wording) --------------------------------------------------- The text reads: destTransportAddress: The transport address of the destination TLS Transport Model in a format specified by the SnmpTLSAddress, the SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTIONs. Question: Does the format into the API really matter? Would omitting the format clause be better, or suggesting the intended format? Section 4.3.2 Page 17: (content error) --------------------------------------- The text reads: statusInformation = receiveMessage( IN transportDomain -- origin transport domain IN transportAddress -- origin transport address IN incomingMessage -- the message received IN incomingMessageLength -- its length IN tmStateReference -- reference to transport state ) I _think_ the ASI arguments all specify items that are returned to the ASI caller, so I _think_ it should be: statusInformation = receiveMessage( OUT transportDomain -- origin transport domain OUT transportAddress -- origin transport address OUT incomingMessage -- the message received OUT incomingMessageLength -- its length OUT tmStateReference -- reference to transport state ) Now, in a programming language, one would pass pointers into an API, which would then be populated by the API, then returned to the caller. Thus, if receiveMessage() specified an _API_ (not an _ASI_), then the original _might_ be correct. But the original obscures the fact that the informa- tion items specified by the arguments are _returned_ by the ASI. Thus, the original seems to obscure the information flow. I note that this diagram comes from RFC 5590, section 6.3, on page 25, which I _think_ is incorrect also. Am I missing something here? Section 4.3.2 Page 18, first paragraph: (wording) -------------------------------------------------- The text reads: transportAddress: The transport address of the source of the received message in a format specified by the SnmpTLSAddress, the SnmpDTLSUDPAddress or the SnmpDTLSSCTPAddress TEXTUAL-CONVENTION. Question: Does the format into the API really matter? Would omitting the format clause be better, or suggesting the intended format? Section 4.4 Page 18, first paragraph: (typo/content error) ----------------------------------------------------------- The text reads: This section describes the services provided by the (D)TLS Transport Model with their inputs and outputs." ^^^ Suggested change: This section describes the services provided by the TLS Transport Model with their inputs and outputs. Section 4.4 Page 18, first paragraph: (clarification) ------------------------------------------------------ The text reads: The following sections describe services for establishing and closing a session and for passing messages between the (D)TLS transport Suggested change: The following sections describe services for establishing and closing a (D)TLS session and for passing messages between the (D)TLS transport ^^^^^^ Section 4.4.1 Page 19, sixth paragraph: (clarification/wording) ---------------------------------------------------------------- The text reads: Neither DTLS or UDP provides a session de-multiplexing mechanism and it is possible that implementations will only be able to identify a unique session based on a unique combination of source address, destination address, source UDP port number and destination UDP port number. Because of this, when establishing a new sessions implementations MUST use a different UDP source port number for each connection to a given remote destination IP-address/port-number combination to ensure the remote entity can properly disambiguate between multiple sessions from a host to the same port on a server. TLS and DTLS over SCTP provide session de-multiplexing so this restriction is not needed for TLS or DTLS over SCTP implementations. Suggested changes: Neither DTLS or UDP provides a session de-multiplexing mechanism and it is possible that implementations will only be able to identify a unique DTLS session based on a unique combination of source address, ^^^^ destination address, source UDP port number and destination UDP port number. Because of this, when establishing a new sessions with different security parameters, ^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementations MUST use a different UDP source port number for each connection to a given remote destination IP-address/port-number combination to ensure the remote entity can properly differentiate ^^^^^^^^^^^^^ between multiple sessions from a host to the same port on a server. TLS and DTLS over SCTP provide session de-multiplexing so this restriction is not needed for TLS or DTLS over SCTP implementations. I _think_ "disambiguate" is jargon, not a real word. Section 4.4.1 Page 19, last paragraph, second line: (typo) ----------------------------------------------------------- Add a comma after the clause "if the process was successful". Section 4.4.2 Page 19, first paragraph: (clarification) -------------------------------------------------------- The text reads: When the TLS Transport Model invokes the (D)TLS record layer to verify proper security for the incoming message, it must use the following ASI: Suggested change: The TLS Transport Model invokes the tlsRead ASI to verify proper security for the incoming message: Section 4.4.2 Page 20, third paragraph: (attaboy) -------------------------------------------------- Thanks for the implementation hint in the paragraph about the "tlsSessionID"! Section 5.1.1 Page 22, second paragraph: (typo) ------------------------------------------------ Add a hyphen between "implementation dependent" in the fourth line. Section 5.1.1 Page 22, second paragraph: (wording) --------------------------------------------------- The text reads: accomplish this, although any implementation dependent method should be suitable as long as the results are consistently deterministic. Suggested change: accomplish this, although any implementation dependent method should be suitable as long as the results are consistent. The phrase "consistently deterministic" is redundant. Section 5.1.1 Page 23, item 5: (typo) -------------------------------------- Change "tlsWholeMsg" to "wholeTlsMsg". Section 5.1.2 Page 23, heading: (clarification) ------------------------------------------------ The text reads: 5.1.2. Transport Processing for Incoming Messages Should it read: 5.1.2. Transport Processing for Incoming SNMP Messages There are a few other places in the text of this section where adding a clue about whether the message is SNMP might clarify the text. Section 5.1.2 Page 24, third paragraph: (wording) -------------------------------------------------- The text reads: tmTransportAddress = The address the message originated from, determined in an implementation dependent way. Suggested change: tmTransportAddress = The address the message originated from. Does the phrase "determined in an implementation dependent way" matter? Section 5.2 Page 25, heading: (clarification) ---------------------------------------------- The text reads: 5.2. Procedures for an Outgoing Message Should it read: 5.2. Procedures for an Outgoing SNMP Message There are a few other places in the text of this section where adding a clue about the message is SNMP might clarify the text. Section 5.2 Page 25, bulleted item 4b: (typo) ---------------------------------------------- The text reads: same cache entry. If an error is returned from OpenSession(), then discard the message, increment the ^ Suggested change: same cache entry. If an error is returned from openSession(), then discard the message, increment the ^ I _think_ this refers to the "openSession() ASI. Section 5.3 Page 27, bulleted item 3: (wording) ------------------------------------------------ The text reads: 3) Once a (D)TLS secured session is established and both sides have performed any appropriate certificate authentication verification Suggested change: 3) Once a (D)TLS secured session is established and both sides have verified the authenticity of the peer's certificate The original phrase "certificate authentication verification" sounds confusing. Section 5.4 Page 28, bulleted item 2: (wording) ------------------------------------------------ The text reads: 2) If there is no session open associated with the tmStateReference, ^^^^^^^^^^^^ then closeSession processing is completed. Suggested change: 2) If there is no open session associated with the tmStateReference, ^^^^^^^^^^^^ then closeSession processing is completed. Section 6.3 Page 29: (typo) ---------------------------- Change "statical" to "statistical". Section 6.3 Page 29: (wording) ------------------------------- Change "feedback" to "information". Section 7 Page 34 sixth paragraph under "SnmpTLSAddress": (typo) ----------------------------------------------------------------- Change the case of "snmpTLSAddress" to "SnmpTLSAddress". Section 7 Page 36 sixth paragraph under "SnmpDTLSUDPAddress": (typo) --------------------------------------------------------------------- Change the case of "snmpDTLSUDPAddress" to "SnmpDTLSUDPAddress". Section 7 Page 37 sixth paragraph under "SnmpDTLSSCTPAddress": (typo) ---------------------------------------------------------------------- Change the case of "snmpDTLSSCTPAddress" to "SnmpDTLSSCTPAddress". Section 7 Page 39 under tlstmSessionInvalidClientCertificates: (wording) ------------------------------------------------------------------------- The text reads: DESCRIPTION "The number of times an incoming session was not established on an (D)TLS server because the presented client certificate was invalid. Reasons for invalidation includes, but is not ^ ^^ limited to, cryptographic validation failures and lack of a ^^^ suitable mapping row in the tlstmCertToSNTable." Suggested change: DESCRIPTION "The number of times an incoming session was not established on an (D)TLS server because the presented client certificate was invalid. Reasons for invalidation include, but are not ^^^ limited to, cryptographic validation failures, or a lack of a ^ ^^ suitable mapping row in the tlstmCertToSNTable." Section 7 Page 39 under tlstmSessionInvalidServerCertificates: (wording) ------------------------------------------------------------------------- Same change in the DESCRIPTION clause as described above for the tlstmSessionInvalidClientCertificates DESCRIPTION clause. Section 7 Page 40: (technical) ------------------------------- I suggest adding: tlstmCertToSNTableLastChangedEngineBoots OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The value of snmpEngineBoots.0 when the tlstmCertToSNTable was last modified through any means." just above the "tlstmCertToSNTableLastChanged" object. Having an engine boots and "tlstmCertToSNTableLastChanged" values would simplify the reliable detection of changes to the tlstmCertToSNTable. Without an engine boots value, one cannot reliably detect changes to the tlstmCertToSNTable. I also suggest adding analogous engine boots values before the "tlstmParamsTableLastChanged" and "tlstmAddrTableLastChanged" objects. Section 7 Page 42 under "tlstmCertToSNFingerprint": (clarification) -------------------------------------------------------------------- How is the actual Fingerprint of a certificate generated, and how is this MIB object populated? I _assume_ the Fingerprint is generated by reading in, then hashing, the certificate. Or is the Fingerprint already _in_ the certificate and just needs to be extracted? A similar clarification under "tlstmParamsClientFingerprint", and "tlstmAddrServerFingerprint" would be nice. Or just providing the clarification under the "Fingerprint" TEXTUAL-CONVENTION might be sufficient. Section 8.1 Page 54 first paragraph: (clarification) ------------------------------------------------------ The text reads: use separate ports for Notification sessions and for Command sessions. If this implementation recommendation is followed, (D)TLS Are these "listen" ports, or "connect" ports? Section 8.1 Page 54 first paragraph: (typo) -------------------------------------------- Should REQUEST and RESPONSE be in lowercase? Change "Request- Response" to "request-response" Section 8.2 Page 54: (attaboy) ------------------------------- Thanks for the nice explanation! Section 9.1 Page 56 second paragraph: (clarification) ------------------------------------------------------ The text reads: The instructions found in the DESCRIPTION clause of the tlstmCertToSNTable object must be followed exactly. It is also important that the rows of the table be searched in prioritized order starting with the row containing the lowest numbered tlstmCertToSNID value. Why _must_ the procedure be followed exactly, and why is it important that the rows of the table be searched in prioritized order? Section 11 Page 59 second paragraph: (typo) -------------------------------------------- Add a second space after the colon after the phrase "(in alphabetical order):" Section A.1 Page 62 third bulleted item: (typo/clarification) -------------------------------------------------------------- The text reads: o Messages are protected against replay. (D)TLS uses explicit sequence numbers and integrity checks. DTLS uses a sliding window to protect against replay of messages within a session. Are (D)TLS and DTLS used properly here? Section B Page 63 first paragraph: (typo) ------------------------------------------ Jettison the extra space between "challenge- response". Section B Page 64 last two paragraphs: (clarification) ------------------------------------------------------- The very last paragraph discusses "decrypted information", but no explan- ation of where the "encrypted information" originated. I _believe_ I understand this, but persons new to PKIX might not. The understanding of how/where the certificate hashes are encrypted and stored, then decrypted and compared, is critical to the understanding of PKIX. Section C.1 Page 65 first paragraph: (typo) -------------------------------------------- Change "Notification Generator's" to "Notification Generators". Section C.2 Page 66 second to the last paragraph: (typo) --------------------------------------------------------- Change "issuing certificate" to "issuing certificate". Change "1 to 1" to "one-to-one". Hope this review and comments are useful to the WG. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk@snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ From wjhns1@hardakers.net Fri Nov 20 14:25:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D311C3A6953 for ; Fri, 20 Nov 2009 14:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5q6lN7G6YFi for ; Fri, 20 Nov 2009 14:25:40 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D59EF3A67D3 for ; Fri, 20 Nov 2009 14:25:39 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 83B6D9830E; Fri, 20 Nov 2009 14:25:36 -0800 (PST) From: Wes Hardaker To: Alan Luchuk Organization: Sparta References: <200911202038.PAA05533@adminfs.snmp.com> Date: Fri, 20 Nov 2009 14:25:36 -0800 In-Reply-To: <200911202038.PAA05533@adminfs.snmp.com> (Alan Luchuk's message of "Fri, 20 Nov 2009 15:38:37 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] IsmsReview of draft-ietf-isms-dtls-tm-01.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 22:25:40 -0000 AL> I have reviewed draft-ietf-isms-dtls-tm-01.txt; my comments are included AL> below. My apology for my late review of this document. Alan, I greatly appreciate the review and will respond later at length about your questions and concerned as I process through the list. AL> My company has not implemented SNMP over (D)TLS, but we are AL> interested in doing so. We have customer demand for SNMP over AL> (D)TLS. I'm certainly glad to hear that! -- Wes Hardaker Cobham Analytic Solutions From d.b.nelson@comcast.net Fri Nov 20 20:23:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE71F3A6829 for ; Fri, 20 Nov 2009 20:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IN6gX0T1tlF for ; Fri, 20 Nov 2009 20:23:45 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id DA7163A67A4 for ; Fri, 20 Nov 2009 20:23:44 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 7gLv1d0010xGWP851gPLGN; Sat, 21 Nov 2009 04:23:21 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA12.westchester.pa.mail.comcast.net with comcast id 7gPg1d00U4H2mdz3YgPh4b; Sat, 21 Nov 2009 04:23:41 +0000 From: "Dave Nelson" To: References: <20091120135427.GE3973@elstar.local> Date: Fri, 20 Nov 2009 23:23:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acpp/GKTx1AXqEtSTFudwhoVwPrV7gAZY6Eg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] new radius vacm document editor X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 04:23:45 -0000 > I will shortly publish a -01 of the individual draft, representing the > state of the document as it was presented to Randy, to create a > snapshot of the work. The WG should not be confused that is is > intended to be the version that gets WG review and comment. It's > primarily for short-term archival purposes. This revision has now been posted as: http://www.ietf.org/internet-drafts/draft-nelson-isms-extended-vacm-01.txt The open issues in this (last) revision of the individual submission document are as follows: (1) Is this document an amendment or update to RFC 3514? Or is it simply a standalone document that describes how to provision certain MIB Objects defined in RFC 3514, along with an extended set of augmenting table columns? (2) Does this document need to make any reference to the Elements of Procedure in RFC 3514, or does is simply need its own Elements of Procedure for updating the group mapping table? (3) Where should the MIB Module defined in this document be rooted? (4) Dave Harrington had issued a summary email after IETF75 containing apparently contradictory statements about whether the additional columns should be in the *same* table that VACM uses or in another, separate table that augments the VACM table. Basically, we need some help in actually structuring the new MIB Module. (5) The Groups and Conformance sections of the new MIB Module are missing. (6) Make sure that the new Elements of Procedure make sense and cover all the corner cases correctly. (7) Generally make the document look like an "SNMP document". :-) From j.schoenwaelder@jacobs-university.de Sun Nov 22 13:46:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BEBF3A6961 for ; Sun, 22 Nov 2009 13:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLjEoWaikBje for ; Sun, 22 Nov 2009 13:46:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7ACB13A6993 for ; Sun, 22 Nov 2009 13:46:32 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 300D7C0011 for ; Sun, 22 Nov 2009 22:46:28 +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 5Xq91vB5uHlz; Sun, 22 Nov 2009 22:46:27 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16F63C0003; Sun, 22 Nov 2009 22:46:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9EE3EE3191A; Sun, 22 Nov 2009 22:46:25 +0100 (CET) Date: Sun, 22 Nov 2009 22:46:25 +0100 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20091122214625.GA7766@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] ietf76 meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 21:46:34 -0000 Hi, I have compiled the minutes of the IETF 76 WG meeting: http://www.ietf.org/proceedings/09nov/minutes/isms.txt Please let me know if anything needs fixing. Please check carefully the resolution of open issues and speak up if you do not agree. Some issues require concrete text proposals and subsequent review while a few issues (in particular #9, #12) seem to need further discussion on the mailing list. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Mon Nov 23 03:52:06 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941053A68F6 for ; Mon, 23 Nov 2009 03:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.625 X-Spam-Level: X-Spam-Status: No, score=-0.625 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A64QaQ8AzTHc for ; Mon, 23 Nov 2009 03:52:05 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 6A3C23A67EF for ; Mon, 23 Nov 2009 03:52:05 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 8bTA1d0041HzFnQ55bs114; Mon, 23 Nov 2009 11:52:01 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 8bs01d009284sdk3abs0mZ; Mon, 23 Nov 2009 11:52:01 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20091122214625.GA7766@elstar.local> Date: Mon, 23 Nov 2009 06:52:00 -0500 Message-ID: <08c301ca6c33$5de71e40$a1135d85@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20091122214625.GA7766@elstar.local> Thread-Index: AcprvUJfvNGhukzVTdKfrGwQMsDyxgAdgi+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] ietf76 meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:52:06 -0000 The minutes match my general memory of the meeting. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Sunday, November 22, 2009 4:46 PM > To: isms@ietf.org > Subject: [Isms] ietf76 meeting minutes > > Hi, > > I have compiled the minutes of the IETF 76 WG meeting: > > http://www.ietf.org/proceedings/09nov/minutes/isms.txt > > Please let me know if anything needs fixing. Please check carefully > the resolution of open issues and speak up if you do not agree. Some > issues require concrete text proposals and subsequent review while a > few issues (in particular #9, #12) seem to need further discussion on > the mailing list. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Mon Nov 23 09:16:35 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87453A6801 for ; Mon, 23 Nov 2009 09:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+1WQbB2oSlo for ; Mon, 23 Nov 2009 09:16:35 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id E14BB3A67DF for ; Mon, 23 Nov 2009 09:16:34 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A914A991E0 for ; Mon, 23 Nov 2009 09:16:30 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20091122214625.GA7766@elstar.local> Date: Mon, 23 Nov 2009 09:16:30 -0800 In-Reply-To: <20091122214625.GA7766@elstar.local> (Juergen Schoenwaelder's message of "Sun, 22 Nov 2009 22:46:25 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsietf76 meeting minutes X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:16:35 -0000 >>>>> On Sun, 22 Nov 2009 22:46:25 +0100, Juergen Schoenwaelder said: JS> Some issues require concrete text proposals and subsequent review JS> while a few issues (in particular #9, #12) seem to need further JS> discussion on the mailing list. I'll be posting responses to all the outstanding last call comments at the end of next week (12/4), if all goes according to plan. I'll be sure to include text changes as well. -- Wes Hardaker Cobham Analytic Solutions