From wwwrun@rfc-editor.org Fri Aug 20 11:13:56 2010 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 01B8A3A6B30; Fri, 20 Aug 2010 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 jn5T8+A3vMlA; Fri, 20 Aug 2010 11:13:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id DDCDA3A6B2A; Fri, 20 Aug 2010 11:13:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B1FD3E06DF; Fri, 20 Aug 2010 11:14:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100820181428.B1FD3E06DF@rfc-editor.org> Date: Fri, 20 Aug 2010 11:14:28 -0700 (PDT) Cc: isms@ietf.org, rfc-editor@rfc-editor.org Subject: [Isms] RFC 5953 on Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) 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 Aug 2010 18:13:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5953 Title: Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) Author: W. Hardaker Status: Standards Track Stream: IETF Date: August 2010 Mailbox: ietf@hardakers.net Pages: 65 Characters: 147393 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isms-dtls-tm-14.txt URL: http://www.rfc-editor.org/rfc/rfc5953.txt This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. [STANDARDS TRACK] This document is a product of the Integrated Security Model for SNMP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://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 turners@ieca.com Sun Aug 22 15:28:12 2010 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 805963A693A for ; Sun, 22 Aug 2010 15:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.951 X-Spam-Level: X-Spam-Status: No, score=-101.951 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 lOsShjMAUeVz for ; Sun, 22 Aug 2010 15:28:11 -0700 (PDT) Received: from smtp112.biz.mail.re2.yahoo.com (smtp112.biz.mail.re2.yahoo.com [66.196.116.97]) by core3.amsl.com (Postfix) with SMTP id 73EA13A67D9 for ; Sun, 22 Aug 2010 15:28:11 -0700 (PDT) Received: (qmail 17079 invoked from network); 22 Aug 2010 22:28:42 -0000 Received: from thunderfish.local (turners@96.241.3.13 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 22 Aug 2010 15:28:42 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: girN3UYVM1n8AVMbQ_4E4Zoedzu4gCMI4zOXtUpeKjnDB9W YhcBXQCYWbGqqCG5epcQ0rcbutqha2lYAGzts5GmeC2apuhRUrErZwFohR0D kiGRsNxC25GVBaA3uiMtQbavH4GYSMLe3ZvZKaCLMOa3BE6RtCh5nqspFXTO 0X4MMsNsMeAycaqUKgE7.O6f6KAT5Q8I58KpOi04xMFMfNUU1r3InzdqN5DK 4K.oYb2gwADS2uwkIFQpNIH6gEacdlyBttuScU_A4H38dr8i3fv4mZ2wvHB9 d49fIjGeBz6w60qwDt11EYBD5jvD0Ls4u04Hr0mKJh_MRXc343fBJ6D0BS_w MmOLM7clR9kVDzfYhZ0PDLjwWHV4XDHm5OxgTdEDatEXkmzsswWCyM.sm4Dz k8PcNTwXwtICMPeVBjoOGO7zF9lkTLOY9SE6cpmsRty4hej3EV2Y- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C71A498.3040807@ieca.com> Date: Sun, 22 Aug 2010 18:28:40 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: isms@ietf.org References: <20100820181428.B1FD3E06DF@rfc-editor.org> In-Reply-To: <20100820181428.B1FD3E06DF@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Isms] RFC 5953 on Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) 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, 22 Aug 2010 22:28:12 -0000 Congratulations! spt rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 5953 > > Title: Transport Layer Security (TLS) Transport > Model for the Simple Network Management > Protocol (SNMP) > Author: W. Hardaker > Status: Standards Track > Stream: IETF > Date: August 2010 > Mailbox: ietf@hardakers.net > Pages: 65 > Characters: 147393 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-isms-dtls-tm-14.txt > > URL: http://www.rfc-editor.org/rfc/rfc5953.txt > > This document describes a Transport Model for the Simple Network > Management Protocol (SNMP), that uses either the Transport Layer > Security protocol or the Datagram Transport Layer Security (DTLS) > protocol. The TLS and DTLS protocols provide authentication and > privacy services for SNMP applications. This document describes how > the TLS Transport Model (TLSTM) implements the needed features of a > SNMP Transport Subsystem to make this protection possible in an > interoperable way. > > This Transport Model is designed to meet the security and operational > needs of network administrators. It supports the sending of SNMP > messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of > TCP's improved support for larger packet sizes and the DTLS mode > provides potentially superior operation in environments where a > connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS > integrate well into existing public keying infrastructures. > > This document also defines a portion of the Management Information > Base (MIB) for use with network management protocols. In particular, > it defines objects for managing the TLS Transport Model for SNMP. > [STANDARDS TRACK] > > This document is a product of the Integrated Security Model for SNMP Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://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 > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From glenn@cysols.com Mon Aug 23 06:27:51 2010 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 EE3063A6A38; Mon, 23 Aug 2010 06:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.673 X-Spam-Level: * X-Spam-Status: No, score=1.673 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 eyjWhA79AZ7R; Mon, 23 Aug 2010 06:27:49 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id CFC7A3A6A1A; Mon, 23 Aug 2010 06:27:48 -0700 (PDT) Received: from [127.0.0.1] (cysvpn03.priv.cysol.co.jp [192.168.0.90]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7NDSK80043669 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 22:28:21 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C727773.5060703@cysols.com> Date: Mon, 23 Aug 2010 22:28:19 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: isms@ietf.org, Glenn Mansfield Keeni References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ietfmibs@ietf.org Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I 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 Aug 2010 13:27:51 -0000 Hi, I have volunteered to do a MIB Doctor review of . I have completed Part-I the more-or-less mechanical checklist aspects. I will work on and send a Part-II of comments on the remaining aspects of the memo. The document is well written and has gone through several revisions. I appreciate the compactness of the MIB. The comments below follow the checklist from Appendix A of rfc4181.txt. Please send comments/responses to the isms mailing list with cc to me and ietfmibs@ietf.org. Glenn +--------------------------------------------------------------+ 1. I-D Boilerplate -- OK. 2. Abstract -- OK. Please move the "Comments are solicited ... org" part to Status of this Memo section or any other more appropriate place. 3. MIB Boilerplate -- OK. Body of the boilerplate is verbatim. References are not not exact copies. For RFC2578, RFC2579, there is an additional "Ed.," for each author which is not there in the boilerplate. But this is not a problem. It accurately reflects the actual RFCs. 4. Security Considerations Section -- OK. The Sensitive objects are listed but the risk/vulnerability is not mentioned. I would recommend adding something like These objects may reveal that User X has logged on with Security privileges Y in session Z . This raises atleast two issues. o Revealing the information may amount to breaching the privacy of the User. o The information may be misused by an attacker. E.g. he/she may focus/narrow down his/her attack by making informed guesses about the target system. 5. IANA Considerations Section -- OK. 6. References -- NOK. 6.1 RFC 5590 to be added | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | ::= { vacmAaaSecurityToGroupEntry 3 } A reference to RFC 5590 where the object "tmSessionID" is probably defined, is required. [I note that the reference was there in the earlier versions of this memo but then it got removed along with "tmStateReference" http://www.ietf.org/mail-archive/web/isms/current/msg04177.html] Please put it back. Also, please note that this will be a normative reference. 6.2 A reference to AAA service architecture/Framework will be in order if this document does target generic AAA services (as the title suggests). 7. Copyright notices -- OK. Not in accordance with rfc3978 as reqd by rfc4181 but follows the latest requirements as in http://www.ietf.org/ietf-ftp/1id-guidelines.txt. 8. IPR notices -- OK. Not in accordance with rfc3978 as reqd by rfc4181 but follows the latest requirements as in http://www.ietf.org/ietf-ftp/1id-guidelines.txt. 9. Other Issues: a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to the list of imperatives (although the standard boilerplate in RFC 2119 does not include it, it is used in the Security Considerations section and it is defined in RFC 2119). 10.Technical content -- review of actual technical content for compliance with rfc4181 10.1 MIB compilation using smilint -- OK. 10.2 MIB issues 10.2.1 In the MODULE-IDENTITY | REVISION "201007150000Z" | DESCRIPTION "Initial version, published as RFC XXXX." | ::= { mib-2 XXX } the note to the RFC-Editor to handle the literal XXX is missing. I suggest- OLD: | REVISION "201007150000Z" | DESCRIPTION "Initial version, published as RFC XXXX." | ::= { mib-2 XXX } NEW: | REVISION "201007150000Z" | DESCRIPTION "Initial version, published as RFC XXXX." | ::= { mib-2 XXX } | -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 10.2.2 the naming of the objects: In the MIB module the naming hierarchy uses the following prefixes snmpVacmAaaMIB | +-- vacmAaaMIBObjects | +-- vacmAaaMIBCompliance This does not follow the recommended naming conventions given in Appendix C of RFC 4181 which urges the pattern snmpVacmAaaMIB | +-- snmpVacmAaaMIBObjects | +-- snmpVacmAaaMIBCompliance Please note, I have not found any opinions strong or weak about the naming in the ISMS-WG mailing list archives. [I have not looked at the archives in detail] If the naming in the document is the result of deliberations in the WG, please ignore this comment. Otherwise, please consider the usage of the naming convention recommended in RFC 4181. 10.2.3 In the DESCRIPTION vacmAaaSecurityToGroupEntry row object. | vacmAaaSecurityToGroupEntry OBJECT-TYPE | SYNTAX VacmAaaSecurityToGroupEntry | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "An entry in this table maps the combination of a | SnmpSecurityModel and SecurityName into a GroupName for | a particular session. | | Each entry corresponds to a session. | | Entries do not persist across reboots. | | When a session is torn down, disconnected, timed out | (e.g. following the RADIUS Session-Timeout Attribute), | or otherwise terminated for any reason, the | corresponding vacmAaaSecurityToGroupEntry is deleted." There is a need to mention the conditions under which the row is created. According to RFC 4181 "If the agent itself may also create and/or delete rows, then the conditions under which this can occur MUST be clearly documented in the row object DESCRIPTION clause." The details are present in Section 7.2.1. Please add the relevant part to the DESCRIPTION clause of this object. (That includes the row update protocol.) It will be useful to have the term "AAA binding" mentioned here (see 10.2.4, 10.2.5 below). E.g. OLD: | DESCRIPTION "An entry in this table maps the combination of a NEW: | DESCRIPTION "An entry in this table represents a AAA binding | which maps the combination of a The terms "SnmpSecurityModel" and "SecurityName" are confusing as they represent TEXTUAL CONVENTIONS which in turn represent the SYNTAX and to some extent the semantics of objects. These are not objects. I recommend using "Security Model" and "Security Name". These terms are used (not defined) in subsequent object DESCRIPTIONS. 10.2.4 | vacmAaaSecurityModel OBJECT-TYPE | SYNTAX SnmpSecurityModel(1..2147483647) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Model associated with the AAA binding | represented by this entry. | | This object cannot take the 'any' (0) value." | ::= { vacmAaaSecurityToGroupEntry 1 } The term "AAA binding" appears for the first time here. (And in subsequent Object DESCRIPTIONs.). This term needs to be defined. [This will be remedied if the recommendation in 10.2.3 is implemented.] The term "Security Model" appears for the first time here. Presumably it is the term defined in RFC3411. A REFERENCE clause would be appropriate here. E.g. OLD: | vacmAaaSecurityModel OBJECT-TYPE | SYNTAX SnmpSecurityModel(1..2147483647) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Model associated with the AAA binding | represented by this entry. | | This object cannot take the 'any' (0) value." | ::= { vacmAaaSecurityToGroupEntry 1 } NEW: | vacmAaaSecurityModel OBJECT-TYPE | SYNTAX SnmpSecurityModel(1..2147483647) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Model associated with the AAA binding | represented by this entry. | | This object cannot take the 'any' (0) value." | REFERENCE "RFC 3411; Section 3.1.1.4.1" | ::= { vacmAaaSecurityToGroupEntry 1 } 10.2.5 | vacmAaaSecurityName OBJECT-TYPE | SYNTAX SnmpAdminString (SIZE(1..32)) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Name of the principal associated with the | AAA binding represented by this entry. In RADIUS | environments, this corresponds to the User-Name | Attribute." | ::= { vacmAaaSecurityToGroupEntry 2 } The term "AAA binding" appears for the first time here. A clear description of this term should be given. [This will be remedied if the recommendation in 10.2.3 is implemented.] The term "Security Name" is used here. It is first used in Section 7.1 in the context "SNMP Security Name [RFC3411]". RFC 3411 does NOT have the term Security Name. It has a "securityName" object, though. In this memo there is no other reference to "Security Name". The DESCRIPTION says "In RADIUS environments, this corresponds to the User-Name Attribute." To me it appears that in the AAA/RADIUS context this is the "User-Name" (RFC 2865 section 5.1) and in VACM context it is "securityName" (RFC 3411 section 3.2.2). Please o fix the DESCRIPTION; o add a REFERENCE clause citing the appropriate document(s). 10.2.6 | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | ::= { vacmAaaSecurityToGroupEntry 3 } the object tmSessionID appears in this DESCRIPTION clause for the first time in this memo. Presumably this refers to the tmSessionID object in RFC 5590. Please add a REFERENCE clause citing the appropriate section in RFC 5590. E.g. OLD: | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | ::= { vacmAaaSecurityToGroupEntry 3 } NEW: | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | REFERENCE "RFC 5590: Section 4.1.2" | ::= { vacmAaaSecurityToGroupEntry 3 } 10.3 Document issues TBD From wjhns1@hardakers.net Mon Aug 23 06:52:21 2010 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 3E8283A69F0 for ; Mon, 23 Aug 2010 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xno6OPUQ1a0l for ; Mon, 23 Aug 2010 06:52:20 -0700 (PDT) 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 327AB3A69D8 for ; Mon, 23 Aug 2010 06:52:20 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 9C599980F1; Mon, 23 Aug 2010 06:52:52 -0700 (PDT) From: Wes Hardaker To: Sean Turner Organization: Sparta References: <20100820181428.B1FD3E06DF@rfc-editor.org> <4C71A498.3040807@ieca.com> Date: Mon, 23 Aug 2010 06:52:52 -0700 In-Reply-To: <4C71A498.3040807@ieca.com> (Sean Turner's message of "Sun, 22 Aug 2010 18:28:40 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] RFC 5953 on Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) 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 Aug 2010 13:52:21 -0000 >>>>> On Sun, 22 Aug 2010 18:28:40 -0400, Sean Turner said: ST> Congratulations! I'd especially like to thank everyone that helped contribute to the document, either through participating in the discussions or through direct text contribution. The document is complete and solid because of the people that contributed text, ideas and guidance. Thank you! -- Wes Hardaker Cobham Analytic Solutions From randy_presuhn@mindspring.com Mon Aug 23 14:12:59 2010 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 B01BA3A6B1E; Mon, 23 Aug 2010 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 cEg7hwXX6eVd; Mon, 23 Aug 2010 14:12:56 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 2459D3A6B40; Mon, 23 Aug 2010 14:12:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hd2Clsx+x/o2wxiTVsBmoE+Y3SSpuueXNVP7WIGbeaqNVK/zlwl9LvIw7V+gChXs; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.54.203] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OneKE-0003y9-Ln; Mon, 23 Aug 2010 17:13:03 -0400 Message-ID: <002f01cb4307$f3867b20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Glenn M. Keeni" , , "Glenn Mansfield Keeni" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> Date: Mon, 23 Aug 2010 14:12:49 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe4634f0d08086e1fd11587ce006d23894350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.203 Cc: ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I 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 Aug 2010 21:12:59 -0000 Hi - Thanks for the detailed review. Comments in-line below. > From: "Glenn M. Keeni" > To: ; "Glenn Mansfield Keeni" > Cc: > Sent: Monday, August 23, 2010 6:28 AM > Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I > > Hi, > I have volunteered to do a MIB Doctor review of > . I have completed Part-I > the more-or-less mechanical checklist aspects. I will work on > and send a Part-II of comments on the remaining aspects of the > memo. > > The document is well written and has gone through several > revisions. I appreciate the compactness of the MIB. > > The comments below follow the checklist from Appendix A of > rfc4181.txt. Please send comments/responses to the isms > mailing list with cc to me and ietfmibs@ietf.org. > > Glenn > > +--------------------------------------------------------------+ > > 1. I-D Boilerplate -- OK. > 2. Abstract -- OK. > Please move the "Comments are solicited ... org" part to > Status of this Memo section or any other more appropriate > place. If this sentence is a problem, then I propose just deleting it. > 3. MIB Boilerplate -- OK. > Body of the boilerplate is verbatim. > References are not not exact copies. > For RFC2578, RFC2579, there is an additional "Ed.," for > each author which is not there in the boilerplate. But > this is not a problem. It accurately reflects the actual > RFCs. The references are what is generated by the current xml2rfc. If this is a problem, then I suggest that either the boilerplate or xml2rfc's citation library should be fixed. I propose that no changes be made to this document here. > 4. Security Considerations Section -- OK. > The Sensitive objects are listed but the risk/vulnerability > is not mentioned. > I would recommend adding something like > These objects may reveal that User X has logged on with > Security privileges Y in session Z . > This raises atleast two issues. > o Revealing the information may amount to breaching the > privacy of the User. > o The information may be misused by an attacker. E.g. > he/she may focus/narrow down his/her attack by making > informed guesses about the target system. I'm not sure how useful it is to enumerate specific ways in which information already identified as potentially sensitive might be misused. Since the security considerations section was quite contentious during the development of this document, I'd like to see some indication from the WG / Chairs whether the proposed text is actually necessary. I assume you want the suggested text inserted immediately prior to the paragraph beginning "SNMP versions". > 5. IANA Considerations Section -- OK. > 6. References -- NOK. > 6.1 RFC 5590 to be added > | vacmAaaSessionID OBJECT-TYPE > | SYNTAX Unsigned32 > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "A specific identifier of the session. > | > | This value MUST be unique among all currently open > | sessions of all of this SNMP engine's transport > models. > | The value has no particular significance other > than to > | distinguish sessions. Implementations in which > | tmSessionID is unique across all transport > models MAY > | use the tmSessionID value." > | ::= { vacmAaaSecurityToGroupEntry 3 } > A reference to RFC 5590 where the object "tmSessionID" is > probably defined, is required. > [I note that the reference was there in the earlier versions > of this memo but then it got removed along with "tmStateReference" > http://www.ietf.org/mail-archive/web/isms/current/msg04177.html] > Please put it back. Also, please note that this will be a > normative reference. Given the contentiousness of this item, instead I would propose deleting the sentence "Implementations in which tmSessionID is unique across all transport models MAY use the tmSessionID value" and NOT adding a reference, and NOT adding a REFERENCE. > 6.2 A reference to AAA service architecture/Framework will be > in order if this document does target generic AAA services > (as the title suggests). Where would we need to reference such a reference? Text please. > 7. Copyright notices -- OK. > Not in accordance with rfc3978 as reqd by rfc4181 but follows > the latest requirements as in > http://www.ietf.org/ietf-ftp/1id-guidelines.txt. > 8. IPR notices -- OK. > Not in accordance with rfc3978 as reqd by rfc4181 but follows > the latest requirements as in > http://www.ietf.org/ietf-ftp/1id-guidelines.txt. > 9. Other Issues: > a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to > the list of imperatives (although the standard boilerplate in > RFC 2119 does not include it, it is used in the Security > Considerations section and it is defined in RFC 2119). OK. Should I also remove from the list the ones that are not used? Will any of these changes cause idnits to freak out? > 10.Technical content -- review of actual technical content for > compliance with rfc4181 > 10.1 MIB compilation using smilint -- OK. > > 10.2 MIB issues > 10.2.1 In the MODULE-IDENTITY > | REVISION "201007150000Z" > | DESCRIPTION "Initial version, published as RFC XXXX." > | ::= { mib-2 XXX } > the note to the RFC-Editor to handle the literal XXX is > missing. I suggest- > OLD: > | REVISION "201007150000Z" > | DESCRIPTION "Initial version, published as RFC XXXX." > | ::= { mib-2 XXX } > NEW: > | REVISION "201007150000Z" > | DESCRIPTION "Initial version, published as RFC XXXX." > | ::= { mib-2 XXX } > | -- RFC Ed.: replace XXX with IANA-assigned number & remove > this note The complete instructions are already present in the IANA considerations section. Do we really want the same instructions in multiple locations? > 10.2.2 the naming of the objects: > In the MIB module the naming hierarchy uses the following > prefixes > snmpVacmAaaMIB > | > +-- vacmAaaMIBObjects > | > +-- vacmAaaMIBCompliance > > This does not follow the recommended naming conventions > given in Appendix C of RFC 4181 which urges the pattern > > snmpVacmAaaMIB > | > +-- snmpVacmAaaMIBObjects > | > +-- snmpVacmAaaMIBCompliance > > Please note, I have not found any opinions strong or weak > about the naming in the ISMS-WG mailing list archives. > [I have not looked at the archives in detail] > If the naming in the document is the result of deliberations > in the WG, please ignore this comment. Otherwise, please > consider the usage of the naming convention recommended in > RFC 4181. Given the large number of changes to both the MIB module and the text that this would entail, I'd like to make a counter-proposal: SNMP-VACM-AAA-MIB -> VACM-AAA-MIB snmpVacmAaaMIB -> vacmAaaMIB These two (relatively isolated) changes would satisfy the naming guideline consistency request, with much lower risk of screwing something up in the editing process. > 10.2.3 In the DESCRIPTION vacmAaaSecurityToGroupEntry row object. > | vacmAaaSecurityToGroupEntry OBJECT-TYPE > | SYNTAX VacmAaaSecurityToGroupEntry > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "An entry in this table maps the combination of a > | SnmpSecurityModel and SecurityName into a > GroupName for > | a particular session. > | > | Each entry corresponds to a session. > | > | Entries do not persist across reboots. > | > | When a session is torn down, disconnected, timed out > | (e.g. following the RADIUS Session-Timeout > Attribute), > | or otherwise terminated for any reason, the > | corresponding vacmAaaSecurityToGroupEntry is > deleted." > > There is a need to mention the conditions under which the row is > created. > According to RFC 4181 > "If the agent itself may also create and/or delete rows, then the > conditions under which this can occur MUST be clearly documented > in the row object DESCRIPTION clause." > > The details are present in Section 7.2.1. Please add the relevant > part to the DESCRIPTION clause of this object. (That includes the > row update protocol.) Ok. My understanding is the proposal is to clone the content of section 7.2.1 within the DESCRIPTION of vacmAaaSecurityToGroupEntry. > It will be useful to have the term "AAA binding" mentioned here > (see 10.2.4, 10.2.5 below). E.g. > OLD: > | DESCRIPTION "An entry in this table maps the combination of a > NEW: > | DESCRIPTION "An entry in this table represents a AAA binding > | which maps the combination of a I'm not wild about the way "AAA binding" is turning into a term in this document. It just crept in in June to address DBH's comments. I'd rather find a way to get rid of the phrase, rather than turn it into a technical term. As a counter-proposal, I suggest eliminating "AAA binding" from the two places where it appears. > The terms "SnmpSecurityModel" and "SecurityName" are confusing as > they represent TEXTUAL CONVENTIONS which in turn represent the > SYNTAX and to some extent the semantics of objects. These are not > objects. I recommend using "Security Model" and "Security Name". These terms > are used (not defined) in subsequent object DESCRIPTIONS. Just in the MIB module or throughout the document? In terms of mimizing the number of changes to the document, I think it might be better to get rid of "Security Model" (appearing only once) and "Security Name" (appearing only twice). > 10.2.4 > | vacmAaaSecurityModel OBJECT-TYPE > | SYNTAX SnmpSecurityModel(1..2147483647) > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "The Security Model associated with the AAA binding > | represented by this entry. > | > | This object cannot take the 'any' (0) value." > | ::= { vacmAaaSecurityToGroupEntry 1 } > > The term "AAA binding" appears for the first time here. > (And in subsequent Object DESCRIPTIONs.). This term needs > to be defined. > [This will be remedied if the recommendation in 10.2.3 is > implemented.] > > The term "Security Model" appears for the first time here. > Presumably it is the term defined in RFC3411. > A REFERENCE clause would be appropriate here. E.g. > OLD: > | vacmAaaSecurityModel OBJECT-TYPE > | SYNTAX SnmpSecurityModel(1..2147483647) > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "The Security Model associated with the AAA binding > | represented by this entry. > | > | This object cannot take the 'any' (0) value." > | ::= { vacmAaaSecurityToGroupEntry 1 } > NEW: > | vacmAaaSecurityModel OBJECT-TYPE > | SYNTAX SnmpSecurityModel(1..2147483647) > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "The Security Model associated with the AAA binding > | represented by this entry. > | > | This object cannot take the 'any' (0) value." > | REFERENCE "RFC 3411; Section 3.1.1.4.1" > | ::= { vacmAaaSecurityToGroupEntry 1 } Suggest deleting "the AAA binding represented by" to satisty earlier comments. It's not clear to me how this REFERENCE clause would be helpful, since the relevant semantics come with the textual convention itself. > 10.2.5 > | vacmAaaSecurityName OBJECT-TYPE > | SYNTAX SnmpAdminString (SIZE(1..32)) > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "The Security Name of the principal associated > with the > | AAA binding represented by this entry. In RADIUS > | environments, this corresponds to the User-Name > | Attribute." > | ::= { vacmAaaSecurityToGroupEntry 2 } > > The term "AAA binding" appears for the first time here. > A clear description of this term should be given. > [This will be remedied if the recommendation in 10.2.3 is > implemented.] I think it might be simpler to just delete "the AAA binding represented by". > The term "Security Name" is used here. It is first used in > Section 7.1 in the context "SNMP Security Name [RFC3411]". > RFC 3411 does NOT have the term Security Name. It has a > "securityName" object, though. In this memo there is no > other reference to "Security Name". "securityName" is used fairly consistently in the rest of the document, so that would be my first choice for a replacement. "SNMP Security Name" would be a close second. > The DESCRIPTION says "In RADIUS environments, this corresponds > to the User-Name Attribute." > To me it appears that in the AAA/RADIUS context this is the > "User-Name" (RFC 2865 section 5.1) and in VACM context it is > "securityName" (RFC 3411 section 3.2.2). > > Please > o fix the DESCRIPTION; > o add a REFERENCE clause citing the appropriate > document(s). Ok. However, as a technical contributor this use of REFERENCE does not seem terribly helpful to me, and I would like to hear from others before I go ahead as editor and make this and similar changes. > 10.2.6 > | vacmAaaSessionID OBJECT-TYPE > | SYNTAX Unsigned32 > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "A specific identifier of the session. > | > | This value MUST be unique among all currently open > | sessions of all of this SNMP engine's transport > models. > | The value has no particular significance other > than to > | distinguish sessions. Implementations in which > | tmSessionID is unique across all transport > models MAY > | use the tmSessionID value." > | ::= { vacmAaaSecurityToGroupEntry 3 } > the object tmSessionID appears in this DESCRIPTION clause for > the first time in this memo. Presumably this refers to the > tmSessionID object in RFC 5590. > Please add a REFERENCE clause citing the appropriate section > in RFC 5590. E.g. > OLD: > | vacmAaaSessionID OBJECT-TYPE > | SYNTAX Unsigned32 > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "A specific identifier of the session. > | > | This value MUST be unique among all currently open > | sessions of all of this SNMP engine's transport > models. > | The value has no particular significance other > than to > | distinguish sessions. Implementations in which > | tmSessionID is unique across all transport models MAY > | use the tmSessionID value." > | ::= { vacmAaaSecurityToGroupEntry 3 } > NEW: > | vacmAaaSessionID OBJECT-TYPE > | SYNTAX Unsigned32 > | MAX-ACCESS not-accessible > | STATUS current > | DESCRIPTION "A specific identifier of the session. > | > | This value MUST be unique among all currently open > | sessions of all of this SNMP engine's transport > models. > | The value has no particular significance other > than to > | distinguish sessions. Implementations in which > | tmSessionID is unique across all transport models MAY > | use the tmSessionID value." > | REFERENCE "RFC 5590: Section 4.1.2" > | ::= { vacmAaaSecurityToGroupEntry 3 } I think it's better to remove all reference to tmSessionID. Providing any hints to implementors has been contentious. REQUIRing this to be tmSessionID would make this table more useful, but tmSessionID is so under-specified as to preclude this possibility. This also avoids any need to reference RFC 5590. > 10.3 Document issues > TBD When? Randy From j.schoenwaelder@jacobs-university.de Tue Aug 24 00:10:33 2010 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 1505C3A691B; Tue, 24 Aug 2010 00:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.833 X-Spam-Level: X-Spam-Status: No, score=-101.833 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 Bam29tAXQsLO; Tue, 24 Aug 2010 00:10:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CEBB23A6884; Tue, 24 Aug 2010 00:10:29 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4571C0014; Tue, 24 Aug 2010 09:11:02 +0200 (CEST) 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 5qP+1cwsSPrP; Tue, 24 Aug 2010 09:10:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27A2FC0006; Tue, 24 Aug 2010 09:10:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C3E9214604A8; Tue, 24 Aug 2010 09:10:35 +0200 (CEST) Date: Tue, 24 Aug 2010 09:10:35 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100824071035.GB67749@elstar.local> Mail-Followup-To: Randy Presuhn , "Glenn M. Keeni" , "isms@ietf.org" , Glenn Mansfield Keeni , "ietfmibs@ietf.org" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <002f01cb4307$f3867b20$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002f01cb4307$f3867b20$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Glenn Mansfield Keeni , "ietfmibs@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I 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: Tue, 24 Aug 2010 07:10:33 -0000 On Mon, Aug 23, 2010 at 11:12:49PM +0200, Randy Presuhn wrote: > > From: "Glenn M. Keeni" > > To: ; "Glenn Mansfield Keeni" > > Cc: > > Sent: Monday, August 23, 2010 6:28 AM > > Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I [...] > > 2. Abstract -- OK. > > Please move the "Comments are solicited ... org" part to > > Status of this Memo section or any other more appropriate > > place. > > If this sentence is a problem, then I propose just deleting it. I suggest we delete this sentence. The WG contact information is in the MIB module and that should be sufficient. > > 3. MIB Boilerplate -- OK. > > Body of the boilerplate is verbatim. > > References are not not exact copies. > > For RFC2578, RFC2579, there is an additional "Ed.," for > > each author which is not there in the boilerplate. But > > this is not a problem. It accurately reflects the actual > > RFCs. > > > The references are what is generated by the current xml2rfc. > If this is a problem, then I suggest that either the boilerplate > or xml2rfc's citation library should be fixed. > > I propose that no changes be made to this document here. I agree that no change is needed. > > 4. Security Considerations Section -- OK. > > The Sensitive objects are listed but the risk/vulnerability > > is not mentioned. > > I would recommend adding something like > > These objects may reveal that User X has logged on with > > Security privileges Y in session Z . > > This raises atleast two issues. > > o Revealing the information may amount to breaching the > > privacy of the User. > > o The information may be misused by an attacker. E.g. > > he/she may focus/narrow down his/her attack by making > > informed guesses about the target system. > > I'm not sure how useful it is to enumerate specific ways in which > information already identified as potentially sensitive might be misused. > Since the security considerations section was quite contentious during the > development of this document, I'd like to see some indication > from the WG / Chairs whether the proposed text is actually necessary. > I assume you want the suggested text inserted immediately prior to the > paragraph beginning "SNMP versions". The current text does a good job spelling out which information can leak and I do not think we need to explain the many possible usages of this information. I do not think a change is needed here. > > 6.1 RFC 5590 to be added > > | vacmAaaSessionID OBJECT-TYPE > > | SYNTAX Unsigned32 > > | MAX-ACCESS not-accessible > > | STATUS current > > | DESCRIPTION "A specific identifier of the session. > > | > > | This value MUST be unique among all currently open > > | sessions of all of this SNMP engine's transport > > models. > > | The value has no particular significance other > > than to > > | distinguish sessions. Implementations in which > > | tmSessionID is unique across all transport > > models MAY > > | use the tmSessionID value." > > | ::= { vacmAaaSecurityToGroupEntry 3 } > > A reference to RFC 5590 where the object "tmSessionID" is > > probably defined, is required. > > [I note that the reference was there in the earlier versions > > of this memo but then it got removed along with "tmStateReference" > > http://www.ietf.org/mail-archive/web/isms/current/msg04177.html] > > Please put it back. Also, please note that this will be a > > normative reference. > > Given the contentiousness of this item, instead I would propose deleting > the sentence "Implementations in which tmSessionID is unique across > all transport models MAY use the tmSessionID value" and NOT adding > a reference, and NOT adding a REFERENCE. I think the WG settled on the current text so I do not see why we now should remove it. Adding a REFERENCE to the document defining tmSessionID does not seem to hurt, or does it? > > 6.2 A reference to AAA service architecture/Framework will be > > in order if this document does target generic AAA services > > (as the title suggests). > > Where would we need to reference such a reference? Text please. Since it is unclear to me which document should be referenced, I think we should not make a change. > > 9. Other Issues: > > a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to > > the list of imperatives (although the standard boilerplate in > > RFC 2119 does not include it, it is used in the Security > > Considerations section and it is defined in RFC 2119). > > OK. Should I also remove from the list the ones that are not used? > Will any of these changes cause idnits to freak out? The text is the boilerplate coming from RFC 2119 and RFC 2119 has an errata pending that indeed NOT RECOMMENDED is missing in the boilerplate. There are recent RFCs that use NOT RECOMMENDED with the RFC 2119 boilerplate. Also note that the NOT RECOMMENDED comes from the SNMP security considerations boilerplate text - so likely every RFC containing a MIB module published in the last few years has the problem. In short, there is a general conflict here between boilerplate texts that the IESG should sort out. Until this has happened, I suggest we do what we have always done so far, namely using RFC 2119 boilerplate text literally. > > 10.2 MIB issues > > 10.2.1 In the MODULE-IDENTITY > > | REVISION "201007150000Z" > > | DESCRIPTION "Initial version, published as RFC XXXX." > > | ::= { mib-2 XXX } > > the note to the RFC-Editor to handle the literal XXX is > > missing. I suggest- > > OLD: > > | REVISION "201007150000Z" > > | DESCRIPTION "Initial version, published as RFC XXXX." > > | ::= { mib-2 XXX } > > NEW: > > | REVISION "201007150000Z" > > | DESCRIPTION "Initial version, published as RFC XXXX." > > | ::= { mib-2 XXX } > > | -- RFC Ed.: replace XXX with IANA-assigned number & remove > > this note > > The complete instructions are already present in the IANA > considerations section. Do we really want the same instructions in > multiple locations? I do not think we need to respin this document for this reason. But if we do so, adding this hint to IANA also won't hurt. > > 10.2.2 the naming of the objects: > > In the MIB module the naming hierarchy uses the following > > prefixes > > snmpVacmAaaMIB > > | > > +-- vacmAaaMIBObjects > > | > > +-- vacmAaaMIBCompliance > > > > This does not follow the recommended naming conventions > > given in Appendix C of RFC 4181 which urges the pattern > > > > snmpVacmAaaMIB > > | > > +-- snmpVacmAaaMIBObjects > > | > > +-- snmpVacmAaaMIBCompliance > > > > Please note, I have not found any opinions strong or weak > > about the naming in the ISMS-WG mailing list archives. > > [I have not looked at the archives in detail] > > If the naming in the document is the result of deliberations > > in the WG, please ignore this comment. Otherwise, please > > consider the usage of the naming convention recommended in > > RFC 4181. > > Given the large number of changes to both the MIB module and the > text that this would entail, I'd like to make a counter-proposal: > > SNMP-VACM-AAA-MIB -> VACM-AAA-MIB > snmpVacmAaaMIB -> vacmAaaMIB > > These two (relatively isolated) changes would satisfy the naming guideline > consistency request, with much lower risk of screwing something up in > the editing process. The current naming scheme is consistent with the naming scheme used in the SNMP-VIEW-BASED-ACM-MIB and thus I think we should not make changes at this point in time. I also do not like the counter proposal. > > 10.2.3 In the DESCRIPTION vacmAaaSecurityToGroupEntry row object. > > | vacmAaaSecurityToGroupEntry OBJECT-TYPE > > | SYNTAX VacmAaaSecurityToGroupEntry > > | MAX-ACCESS not-accessible > > | STATUS current > > | DESCRIPTION "An entry in this table maps the combination of a > > | SnmpSecurityModel and SecurityName into a > > GroupName for > > | a particular session. > > | > > | Each entry corresponds to a session. > > | > > | Entries do not persist across reboots. > > | > > | When a session is torn down, disconnected, timed out > > | (e.g. following the RADIUS Session-Timeout > > Attribute), > > | or otherwise terminated for any reason, the > > | corresponding vacmAaaSecurityToGroupEntry is > > deleted." > > > > There is a need to mention the conditions under which the row is > > created. > > According to RFC 4181 > > "If the agent itself may also create and/or delete rows, then the > > conditions under which this can occur MUST be clearly documented > > in the row object DESCRIPTION clause." > > > > The details are present in Section 7.2.1. Please add the relevant > > part to the DESCRIPTION clause of this object. (That includes the > > row update protocol.) > > Ok. My understanding is the proposal is to clone the content of section 7.2.1 > within the DESCRIPTION of vacmAaaSecurityToGroupEntry. Can we just have a pointer to 7.2.1? Keeping redundant text consistent is always a pain. > > It will be useful to have the term "AAA binding" mentioned here > > (see 10.2.4, 10.2.5 below). E.g. > > OLD: > > | DESCRIPTION "An entry in this table maps the combination of a > > NEW: > > | DESCRIPTION "An entry in this table represents a AAA binding > > | which maps the combination of a > > I'm not wild about the way "AAA binding" is turning into a term in this > document. It just crept in in June to address DBH's comments. I'd rather > find a way to get rid of the phrase, rather than turn it into a technical term. > As a counter-proposal, I suggest eliminating "AAA binding" from the two > places where it appears. I agree with the idea behind the counter proposal, although I have to see the replacement text... > > The terms "SnmpSecurityModel" and "SecurityName" are confusing as > > they represent TEXTUAL CONVENTIONS which in turn represent the > > SYNTAX and to some extent the semantics of objects. These are not > > objects. I recommend using "Security Model" and "Security Name". These terms > > are used (not defined) in subsequent object DESCRIPTIONS. > > Just in the MIB module or throughout the document? In terms of > mimizing the number of changes to the document, I think it might be > better to get rid of "Security Model" (appearing only once) and > "Security Name" (appearing only twice). I think Glenn's comment concerns "SnmpSecurityModel" and "SecurityName", not "Security Model" and "Security Name". In some places the usage of the TC names seems quite appropriate while in some other cases this might be less appropriate. That said, I do not see any confusion that can be caused. Or lets put it different, replacing "SnmpSecurityModel" generally with "Security Model" and "SecurityName" "Security Name" will lead to other odd usages of "Security Model" and "Security Name". > > The DESCRIPTION says "In RADIUS environments, this corresponds > > to the User-Name Attribute." > > To me it appears that in the AAA/RADIUS context this is the > > "User-Name" (RFC 2865 section 5.1) and in VACM context it is > > "securityName" (RFC 3411 section 3.2.2). > > > > Please > > o fix the DESCRIPTION; > > o add a REFERENCE clause citing the appropriate > > document(s). > > Ok. However, as a technical contributor this use of REFERENCE does > not seem terribly helpful to me, and I would like to hear from > others before I go ahead as editor and make this and similar > changes. I tend to agree that adding REFERENCE clauses to any term that shows up in a DESCRIPTION clause is likely adding a lot of noise. In this case, adding a reference to RFC 2865 section 5.1 might be appropriate since SNMP implementors less likely know RADIUS attributes by heart. But I assume that securityName is something SNMP access control implementors will be rather familiar with. [skipping issues that pop up multiple times] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Tue Aug 24 05:04:19 2010 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 700143A6830 for ; Tue, 24 Aug 2010 05:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.539 X-Spam-Level: X-Spam-Status: No, score=-101.539 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 O9rwe+IzdvwG for ; Tue, 24 Aug 2010 05:04:18 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by core3.amsl.com (Postfix) with ESMTP id 64CBB3A672E for ; Tue, 24 Aug 2010 05:04:18 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id yBTP1e0040cZkys5FC4sEy; Tue, 24 Aug 2010 12:04:52 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta10.westchester.pa.mail.comcast.net with comcast id yC4f1e00D0yip6Y3WC4gHb; Tue, 24 Aug 2010 12:04:41 +0000 From: "Dave Nelson" To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <4C527775.3000007@ieca.com><4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local><4C69411E.8050907@cysols.com><4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><002f01cb4307$f3867b20$6801a8c0@oemcomputer> <20100824071035.GB67749@elstar.local> Date: Tue, 24 Aug 2010 08:04:47 -0400 Message-ID: <1DFEDE1E2BE84A00A39669FCCC656DD0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100824071035.GB67749@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: ActDW4hrN9c53zyAQb6VJ0ipSPpLEwAJ32iA Cc: 'Glenn Mansfield Keeni' , ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I 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: Tue, 24 Aug 2010 12:04:19 -0000 Juergen Schoenwaelder writes... > > > 6.2 A reference to AAA service architecture/Framework will > > > be in order if this document does target generic AAA > > > services (as the title suggests). > > > > Where would we need to reference such a reference? Text > > please. > > Since it is unclear to me which document should be referenced, > I think we should not make a change. I am equally unaware of anything resembling an "AAA Framework" document. It's possible that some requirements document written by members of the AAA WG when they were attempting to find a successor to RADIUS (which became Diameter) might be characterized as a "framework". Still, we have nothing in the AAA space equivalent to RFC 3410 for SNMP. From d.b.nelson@comcast.net Tue Aug 24 05:13:30 2010 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 3D5D53A6874 for ; Tue, 24 Aug 2010 05:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.963 X-Spam-Level: X-Spam-Status: No, score=-101.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HGqKhUr2QPK8 for ; Tue, 24 Aug 2010 05:13:29 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id C9A813A685C for ; Tue, 24 Aug 2010 05:13:28 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta07.westchester.pa.mail.comcast.net with comcast id yBEe1e0051YDfWL57CE2bE; Tue, 24 Aug 2010 12:14:02 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta20.westchester.pa.mail.comcast.net with comcast id yCE11e0060yip6Y3gCE1MX; Tue, 24 Aug 2010 12:14:02 +0000 From: "Dave Nelson" To: "'Randy Presuhn'" , "'Glenn M. Keeni'" , , "'Glenn Mansfield Keeni'" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com> <002f01cb4307$f3867b20$6801a8c0@oemcomputer> Date: Tue, 24 Aug 2010 08:14:09 -0400 Message-ID: <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002f01cb4307$f3867b20$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: ActDCBMiucEbHz9OStm3ndO39kv1hQAfJEzg Cc: ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 12:13:30 -0000 Randy Presuhn writes... > > It will be useful to have the term "AAA binding" mentioned here > > (see 10.2.4, 10.2.5 below). E.g. > > OLD: > > | DESCRIPTION "An entry in this table maps the combination of a > > NEW: > > | DESCRIPTION "An entry in this table represents a AAA binding > > | which maps the combination of a > > I'm not wild about the way "AAA binding" is turning into a term in this > document. It just crept in in June to address DBH's comments. I'd rather > find a way to get rid of the phrase, rather than turn it into a technical > term. > > As a counter-proposal, I suggest eliminating "AAA binding" from the two > places where it appears. Well, "AAA binding" is just short-cut notation for "The SNMP SecurityName that has been authenticated by RADIUS as a RADIUS User-Name Attribute". It seems we can either have accuracy or conciseness, but not both. I don't think that coming up with a short-form notational device, for use within the scope of a single document is such a bad idea. On the other hand, simply deleting text is worse, if we actually lose the fully nuanced meaning of the concept being referenced. From dromasca@avaya.com Tue Aug 24 05:18:45 2010 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 267F03A672E; Tue, 24 Aug 2010 05:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 699DbBOB70un; Tue, 24 Aug 2010 05:18:44 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id AB6E83A6874; Tue, 24 Aug 2010 05:18:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,263,1280721600"; d="scan'208";a="204191442" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Aug 2010 08:19:15 -0400 X-IronPort-AV: E=Sophos;i="4.56,263,1280721600"; d="scan'208";a="507254621" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Aug 2010 08:19:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Aug 2010 14:18:48 +0200 Message-ID: In-Reply-To: <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I Thread-Index: ActDCBMiucEbHz9OStm3ndO39kv1hQAfJEzgAABtmSA= References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><002f01cb4307$f3867b20$6801a8c0@oemcomputer> <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> From: "Romascanu, Dan (Dan)" To: "Dave Nelson" , "Randy Presuhn" , "Glenn M. Keeni" , , "Glenn Mansfield Keeni" Cc: ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 12:18:45 -0000 =20 > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of Dave Nelson > Sent: Tuesday, August 24, 2010 3:14 PM > To: 'Randy Presuhn'; 'Glenn M. Keeni'; isms@ietf.org; 'Glenn=20 > Mansfield Keeni' > Cc: ietfmibs@ietf.org > Subject: Re: [Isms] MIB Doctor=20 > Review:draft-ietf-isms-radius-vacm-09.txtPart-I >=20 > Randy Presuhn writes... >=20 > > > It will be useful to have the term "AAA binding"=20 > mentioned here > > > (see 10.2.4, 10.2.5 below). E.g. > > > OLD: > > > | DESCRIPTION "An entry in this table maps the=20 > combination=20 > > > | of a > > > NEW: > > > | DESCRIPTION "An entry in this table represents=20 > a AAA binding > > > | which maps the combination of a > >=20 > > I'm not wild about the way "AAA binding" is turning into a term in=20 > > this document. It just crept in in June to address DBH's comments. =20 > > I'd rather find a way to get rid of the phrase, rather than turn it=20 > > into a technical term. > > > > As a counter-proposal, I suggest eliminating "AAA binding" from the=20 > > two places where it appears. >=20 > Well, "AAA binding" is just short-cut notation for "The SNMP=20 > SecurityName that has been authenticated by RADIUS as a=20 > RADIUS User-Name Attribute". It seems we can either have=20 > accuracy or conciseness, but not both. I don't think that=20 > coming up with a short-form notational device, for use within=20 > the scope of a single document is such a bad idea. On the=20 > other hand, simply deleting text is worse, if we actually=20 > lose the fully nuanced meaning of the concept being referenced. >=20 So why not define the usage of the term in this document in the 'Conventions' section?=20 Dan >=20 From j.schoenwaelder@jacobs-university.de Tue Aug 24 06:20:35 2010 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 6BC013A69D9; Tue, 24 Aug 2010 06:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.839 X-Spam-Level: X-Spam-Status: No, score=-101.839 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 953-icIYX8lH; Tue, 24 Aug 2010 06:20:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F108F3A69E0; Tue, 24 Aug 2010 06:20:33 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33395C0002; Tue, 24 Aug 2010 15:21:06 +0200 (CEST) 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 pcxqBWJPRRiY; Tue, 24 Aug 2010 15:21:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2ACC4C0010; Tue, 24 Aug 2010 15:21:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C9B131461022; Tue, 24 Aug 2010 15:20:48 +0200 (CEST) Date: Tue, 24 Aug 2010 15:20:48 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100824132048.GA68910@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Dave Nelson , Randy Presuhn , "Glenn M. Keeni" , "isms@ietf.org" , Glenn Mansfield Keeni , "ietfmibs@ietf.org" References: <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <002f01cb4307$f3867b20$6801a8c0@oemcomputer> <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> 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" , Glenn Mansfield Keeni , "ietfmibs@ietf.org" Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 13:20:35 -0000 On Tue, Aug 24, 2010 at 02:18:48PM +0200, Romascanu, Dan (Dan) wrote: > > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Dave Nelson > > Sent: Tuesday, August 24, 2010 3:14 PM > > To: 'Randy Presuhn'; 'Glenn M. Keeni'; isms@ietf.org; 'Glenn > > Mansfield Keeni' > > Cc: ietfmibs@ietf.org > > Subject: Re: [Isms] MIB Doctor > > Review:draft-ietf-isms-radius-vacm-09.txtPart-I > > > > Randy Presuhn writes... > > > > > > It will be useful to have the term "AAA binding" > > mentioned here > > > > (see 10.2.4, 10.2.5 below). E.g. > > > > OLD: > > > > | DESCRIPTION "An entry in this table maps the > > combination > > > > | of a > > > > NEW: > > > > | DESCRIPTION "An entry in this table represents > > a AAA binding > > > > | which maps the combination of a > > > > > > I'm not wild about the way "AAA binding" is turning into a term in > > > this document. It just crept in in June to address DBH's comments. > > > I'd rather find a way to get rid of the phrase, rather than turn it > > > into a technical term. > > > > > > As a counter-proposal, I suggest eliminating "AAA binding" from the > > > two places where it appears. > > > > Well, "AAA binding" is just short-cut notation for "The SNMP > > SecurityName that has been authenticated by RADIUS as a > > RADIUS User-Name Attribute". It seems we can either have > > accuracy or conciseness, but not both. I don't think that > > coming up with a short-form notational device, for use within > > the scope of a single document is such a bad idea. On the > > other hand, simply deleting text is worse, if we actually > > lose the fully nuanced meaning of the concept being referenced. > > > > So why not define the usage of the term in this document in the > 'Conventions' section? I would rather expand the term - it only pops up in two places if I recall correctly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Aug 24 06:39:47 2010 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 3EE3C3A67ED; Tue, 24 Aug 2010 06:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YgXV7ApGUUpL; Tue, 24 Aug 2010 06:39:47 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 993883A69F7; Tue, 24 Aug 2010 06:30:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,263,1280721600"; d="scan'208";a="234410915" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Aug 2010 09:30:53 -0400 X-IronPort-AV: E=Sophos;i="4.56,263,1280721600"; d="scan'208";a="500860789" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Aug 2010 09:30:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Aug 2010 15:30:49 +0200 Message-ID: In-Reply-To: <20100824132048.GA68910@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IETFMIBS] [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I Thread-Index: ActDj0kkphInvHuGSzWBp09lFcO0UgAATg9A References: <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <002f01cb4307$f3867b20$6801a8c0@oemcomputer> <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> <20100824132048.GA68910@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: isms@ietf.org, Glenn Mansfield Keeni , ietfmibs@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 13:39:47 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > >=20 > > So why not define the usage of the term in this document in the=20 > > 'Conventions' section? >=20 > I would rather expand the term - it only pops up in two=20 > places if I recall correctly. >=20 Either way is fine with me.=20 Dan From glenn@cysols.com Tue Aug 24 07:28:51 2010 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 8C2A13A6B11; Tue, 24 Aug 2010 07:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.777 X-Spam-Level: X-Spam-Status: No, score=0.777 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_83=0.6] 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 WhVbgyMei5XK; Tue, 24 Aug 2010 07:28:50 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id B542C3A6AFC; Tue, 24 Aug 2010 07:28:49 -0700 (PDT) Received: from [127.0.0.1] (cysvpn03.priv.cysol.co.jp [192.168.0.90]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7OET38Q085071 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Aug 2010 23:29:10 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C73D72D.8070902@cysols.com> Date: Tue, 24 Aug 2010 23:29:01 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: isms@ietf.org, Glenn Mansfield Keeni References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> In-Reply-To: <4C727773.5060703@cysols.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ietfmibs@ietf.org Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Tue, 24 Aug 2010 14:28:51 -0000 Hi, Thanks for waiting. This is the Part-II of the MIB Doctor Review of draft-ietf-isms-radius-vacm-09.txt. It focuses on the Document issues. Glenn +--------------------------------------------------------------------+ 10.3 Document issues a. Terminology: I suggest that a Terminology section be added. Several terms used in this document are open to mis-interpretation. E.g. "group": This is a generic term. But, in this document it probably, without exception, refers to a group as in the VACM document[RFC 3415; Sec 2.1]. I would recommend stating early in the document that the term "group" refers to the term defined in [RFC 3415; Sec 2.1] or, defining a "VACM-group" and replacing all occurrences of "group" by "VACM-group" "authenticated user": This is a generic term. It would be good to make it clear in the document that the term "authenticated user" refers to a user authenticated by the AAA services. Or, define a "AAA-authenticated user" and use that term consistently for the rest of the document. [The terms "AAA-authenticated" and "AAA-authorized" are used in the document but sporadically.] The terms "Security Name", "Security Model", "Group Name" should be defined/referred and used consistently in the document. Else, the terms securityName, securityModel, groupName should be used with appropriate pointers [RFC 3415]. b. Page 4. Sec 4.1 | The use case assumption here is that roles within an organization, | which are reflected in VACM as groups and rules, change infrequently, I presume "rules" refer to the "access control policy" defined in the VACM ? If that is the case I would suggest OLD: | The use case assumption here is that roles within an organization, | which are reflected in VACM as groups and rules, change infrequently, NEW: | The use case assumption here is that roles within an organization, | which are reflected in VACM as groups and associated access control | policies", change infrequently, c. Page 5. Sec 5.2 Suggested change- OLD: This table is indexed by the integer assigned to each security model NEW: This table is indexed by the identifier assigned to the Security Model [Note: Security Model needs to have a pointer/definition early in the document.] d. Page 6. Sec 7.1 | They also assume that the User-Name [RFC2865] from the RADIUS Access- | Request message (or equivalent) corresponds to an SNMP Security Name | [RFC3411]. The term "SNMP Security Name" does not appear in RFC 3411. securityName is defined in RFC 3411 section 3.2.2. Suggested change- OLD: | They also assume that the User-Name [RFC2865] from the RADIUS Access- | Request message (or equivalent) corresponds to an SNMP Security Name | [RFC3411]. NEW: | They also assume that the User-Name [RFC2865] from the RADIUS Access- | Request message (or equivalent) corresponds to an SNMP securityName | [RFC3411]. e. Page 7. Sec 7.2 SnmpSecurityModel is not defined in RFC 3411 I suggest OLD: | o the SnmpSecurityModel [RFC3411] needed as an index into the | vacmSecurityToGroupTable; NEW: | o the SNMP Security Model, vacmSecurityModel [RFC3411], needed as an | index into the vacmSecurityToGroupTable; [Note: Security Model needs to have a pointer/definition early in the document.] f. Page 7. Sec 7.2 the RADIUS User-Name Attribute or equivalent is also needed as an index into the vacmSecurityToGroupTable. I suggest OLD: | o the RADIUS User-Name Attribute or equivalent; NEW: | o the RADIUS User-Name Attribute or equivalent which will be used as | the index, vacmSecurityName, into the vacmSecurityToGroupTable; g. Page 7. Sec 7.2 | In particular, if either the User-Name or Management-Policy-Id is | absent, invalid, or a zero-length string, no further processing of | the session establishment indication is undertaken. If the SNMP Security Model has value 'any' (0) then no further processing will be undertaken; is that correct? If that is that is the case I suggest OLD: | In particular, if either the User-Name or Management-Policy-Id is | absent, invalid, or a zero-length string, no further processing of | the session establishment indication is undertaken. NEW: | In particular, if either the User-Name or Management-Policy-Id is | absent, invalid, or a zero-length string, or, if the SNMP Security Model | has value 'any' (0), no further processing of | the session establishment indication is undertaken. h. Page 7. Sec 7.2.1 Along the lines of the change in (e) OLD: | o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to | the security model in use NEW: | o vacmAaaSecurityModel = value of SNMP Security Model corresponding to | the security model in use i. Page 7. Sec 7.2.1 | o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, | the securityName that will be used in invocations of the | isAccessAllowed() abstract service interface; "isAccessAllowed() abstract service interface" appears for the first time. Please provide a pointer/reference. j. Page 7. Sec 7.2.1 The requirements for the vacmAaaSessionID are not explicit. I suggest using text from the DESCRIPTION of vacmAaaSessionID in the MIB module. OLD: | o vacmAaaSessionID = unique session identifier NEW: | o vacmAaaSessionID = session identifier. This value MUST be unique | among all currently open sessions of all of this SNMP engine's | transport models. k. Page 7. Sec 7.2.1 | Otherwise, if the row already exists, update the vacmAaaGroupName | with the value supplied. It will be helpful to be explicit about "value supplied". I would suggest OLD: | Otherwise, if the row already exists, update the vacmAaaGroupName | with the value supplied. NEW: | Otherwise, if the row already exists, update the vacmAaaGroupName | with the RADIUS Management-Policy-Id Attribute or equivalent. l. Page 7. Sec 7.2.2 Suggested change- OLD: | If a corresponding entry already exists in the | vacmSecurityToGroupTable, and the row's StorageType is anything other | than "volatile", or the RowStatus is anything other than "active", NEW: | If a corresponding entry already exists in the | vacmSecurityToGroupTable, and the row's vacmSecurityToGroupStorageType | is anything other than "volatile", or the vacmSecurityToGroupStatus is | anything other than "active", m. Page 7. Sec 7.2.2 The second paragraph does not belong to this subsection. After making the change suggested in (l) move the paragraph (para-2) to section 7.2.3 after the 1st paragraph. n. Page 7. Sec 7.2.3 Suggested change: OLD: | The operational assumption here is that if the row's StorageType is | "volatile", then this entry was probably dynamically created; an | entry created by a security administrator would not normally be given | a StorageType of "volatile". If value being provided by RADIUS (or NEW: | The operational assumption here is that if the row's | vacmSecurityToGroupStorageType is "volatile", then this entry was | probably dynamically created; an entry created by a security | administrator would not normally be given a | vacmSecurityToGroupStorageType of "volatile". If the value being | provided by RADIUS (or o. Page 7. Sec 7.3.2 s/StorageType/vacmSecurityToGroupStorageType/g; p. An overview describing the relevant parts of the AAA service and the VACM may be helpful to make the memo more easily understandable. The other option which I will not recommend will be to include a statement as terse as "the reader of this memo is expected to have read and understood the AAA service document RFC XXX1, the RADIUS document RFC XXX2 and the View-Based Access Control Model document RFC XXX3." q. AAA and RADIUS. I see that this has been discussed in the mailing list before. But I am afraid that the problem persists. Editorial nits. a. Page 12 Sec 9 OLD: | could also occur if the SNMP security administrator had mistakenly | created these non-volatile entries in error. NEW: | could also occur if the SNMP security administrator had mistakenly | created these non-volatile entries. From ietfdbh@comcast.net Tue Aug 24 07:34:53 2010 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 02A1B3A6AFC for ; Tue, 24 Aug 2010 07:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.124 X-Spam-Level: X-Spam-Status: No, score=-102.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ACjvRP5mt54K for ; Tue, 24 Aug 2010 07:34:51 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 47CC03A6B24 for ; Tue, 24 Aug 2010 07:34:50 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id yEBC1e0041GhbT85BEbQSv; Tue, 24 Aug 2010 14:35:24 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta07.westchester.pa.mail.comcast.net with comcast id yEbH1e0052JQnJT3TEbHuU; Tue, 24 Aug 2010 14:35:22 +0000 From: "David Harrington" To: "'Dave Nelson'" , "'Randy Presuhn'" , "'Glenn M. Keeni'" , , "'Glenn Mansfield Keeni'" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><002f01cb4307$f3867b20$6801a8c0@oemcomputer> <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> Date: Tue, 24 Aug 2010 10:34:07 -0400 Message-ID: <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> Thread-Index: ActDCBMiucEbHz9OStm3ndO39kv1hQAfJEzgAAPBJiA= Cc: ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 14:34:53 -0000 Hi, (as a technical contributor) I think that's an incomplete description of "AAA binding". If you go back to my June(?) analysis, I started using that term because SSH has certain security assumptions, RADIUS has certain security assumptions, and SNMP has certain security assumptions, and those assumptions differ and conflict. The assumptions ended up being met by following the elements of procedure in the correct order. Off the top of my head, I don't remember the specifics. It's in my June(?) email. As I recall, processing SSH and RADIUS concepts as per the EOP led to a "binding" that satisfied the SSH security assumptions and the RADIUS security assumptions, and then additional processing took the result of that binding and bound it to SNMP elements (modularity and the ASI parameters I think) that ended up meeting SNMP security assumptions. I think it is important to explain how the current document's EOP allows these conflicting assumptions to be satisfied while still maintaining RFC3411 modularity. The term "AAA binding" refers to this binding of concepts in a specific manner to provide the correct security properties. Randy, do you have the email where I used that term? Can you post it or point to it? I can't locate it. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Dave Nelson > Sent: Tuesday, August 24, 2010 8:14 AM > To: 'Randy Presuhn'; 'Glenn M. Keeni'; isms@ietf.org; 'Glenn > Mansfield Keeni' > Cc: ietfmibs@ietf.org > Subject: Re: [Isms] MIB Doctor > Review:draft-ietf-isms-radius-vacm-09.txtPart-I > > Randy Presuhn writes... > > > > It will be useful to have the term "AAA binding" > mentioned here > > > (see 10.2.4, 10.2.5 below). E.g. > > > OLD: > > > | DESCRIPTION "An entry in this table maps the > combination > > > | of a > > > NEW: > > > | DESCRIPTION "An entry in this table represents > a AAA binding > > > | which maps the combination of a > > > > I'm not wild about the way "AAA binding" is turning into a term in > > this document. It just crept in in June to address DBH's comments. > > I'd rather find a way to get rid of the phrase, rather than turn it > > into a technical term. > > > > As a counter-proposal, I suggest eliminating "AAA binding" from the > > two places where it appears. > > Well, "AAA binding" is just short-cut notation for "The SNMP > SecurityName that has been authenticated by RADIUS as a > RADIUS User-Name Attribute". It seems we can either have > accuracy or conciseness, but not both. I don't think that > coming up with a short-form notational device, for use within > the scope of a single document is such a bad idea. On the > other hand, simply deleting text is worse, if we actually > lose the fully nuanced meaning of the concept being referenced. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfdbh@comcast.net Tue Aug 24 08:11:54 2010 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 A2C1D3A6B6C for ; Tue, 24 Aug 2010 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 x4-Ey-TSUr+T for ; Tue, 24 Aug 2010 08:11:52 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 225C73A6B56 for ; Tue, 24 Aug 2010 08:11:51 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id yF8v1e00C17dt5G53FCRfD; Tue, 24 Aug 2010 15:12:25 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta13.westchester.pa.mail.comcast.net with comcast id yFCD1e00E2JQnJT3ZFCDyD; Tue, 24 Aug 2010 15:12:22 +0000 From: "David Harrington" To: "'David Harrington'" , "'Dave Nelson'" , "'Randy Presuhn'" , "'Glenn M. Keeni'" , , "'Glenn Mansfield Keeni'" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><002f01cb4307$f3867b20$6801a8c0@oemcomputer><09FF2324BC5A4B4090D803B81EA84523@NEWTON603> <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> Date: Tue, 24 Aug 2010 11:11:01 -0400 Message-ID: <8D73F6E66A8B442AAAC27330A1BED193@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> Thread-Index: ActDCBMiucEbHz9OStm3ndO39kv1hQAfJEzgAAPBJiAAAb+UIA== Cc: ietfmibs@ietf.org Subject: [Isms] AAA binding 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: Tue, 24 Aug 2010 15:11:55 -0000 Hi, The text in the document actually provides details about what gets bound in the "AAA binding": An implementation-specific identifier is needed for each AAA- authorized "session", corresponding to a communication channel, such as a transport session, for which a principal has been AAA- authenticated and which is authorized to offer SNMP service. When a RADIUS-Management-Policy-ID Attribute (or equivalent) is bound to such a session and principal authentication, this binding provides sufficient information to compute dynamic updates to VACM. How this information is communicated within an implementation is implementation-dependent; this memo is only concerned with externally-observable behaviour. A "AAA binding" binds 1) a communications channel 2) an authenticated principal 3) service authorization 4) an access control policy name some of the binding is actually done via other standards. A transport model, such as sshtm, provides a binding between 1) and 2) and 3) - a securityName et al AAA provides a binding between (1+2+3) and 4) - MGMT-Policy-ID This document extends that further, to create a binding between (1+2+3+4) and the local (VACM MIB) definition of the named policy (group) - The binding between 1+2 satisfies assumptions of SSH or TLS The SSHTM binding between 1+2+3 satisfies assumptions of SSH subsystems (I'm not sure how TLSTM does this) These 1+2+3 bindings also satisfy AAA assumptions about the channel, the principal and the service authorization being bound together. By keeping these inside a transport model, the 1+2+3 bindings also meet SNMP modularity and secruity assumptions. MGMT-Policy-ID satisfies the AAA assumption that authorization and authentication are bound together, since the MGMT-Policy-ID is AAA-bound to (1+2+3). This is the complete "AAA binding" (1+2+3+4) (channel+authn+service+authz). By doing it in "implementation-dependent in-the-background" manner, we cheated to meet SNMP modularity assumptions, but this way allows for other models to be developed that won't be forced to implement a one-size-fits-all mechanism for this, and we didn't have to redesign the ASIs, so we met the objectives of SNMP modularity. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David Harrington > Sent: Tuesday, August 24, 2010 10:34 AM > To: 'Dave Nelson'; 'Randy Presuhn'; 'Glenn M. Keeni'; > isms@ietf.org; 'Glenn Mansfield Keeni' > Cc: ietfmibs@ietf.org > Subject: Re: [Isms] MIB > DoctorReview:draft-ietf-isms-radius-vacm-09.txtPart-I > > Hi, > > (as a technical contributor) > > I think that's an incomplete description of "AAA binding". > > If you go back to my June(?) analysis, I started using that > term because SSH has certain security assumptions, RADIUS has > certain security assumptions, and SNMP has certain security > assumptions, and those assumptions differ and conflict. > > The assumptions ended up being met by following the elements > of procedure in the correct order. Off the top of my head, I > don't remember the specifics. It's in my June(?) email. As I > recall, processing SSH and RADIUS concepts as per the EOP led > to a "binding" > that satisfied the SSH security assumptions and the RADIUS > security assumptions, and then additional processing took the > result of that binding and bound it to SNMP elements > (modularity and the ASI parameters I think) that ended up > meeting SNMP security assumptions. I think it is important to > explain how the current document's EOP allows these > conflicting assumptions to be satisfied while still maintaining > RFC3411 modularity. > > The term "AAA binding" refers to this binding of concepts in > a specific manner to provide the correct security properties. > > Randy, do you have the email where I used that term? Can you > post it or point to it? I can't locate it. > > dbh > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] > On Behalf > > Of Dave Nelson > > Sent: Tuesday, August 24, 2010 8:14 AM > > To: 'Randy Presuhn'; 'Glenn M. Keeni'; isms@ietf.org; > 'Glenn Mansfield > > Keeni' > > Cc: ietfmibs@ietf.org > > Subject: Re: [Isms] MIB Doctor > > Review:draft-ietf-isms-radius-vacm-09.txtPart-I > > > > Randy Presuhn writes... > > > > > > It will be useful to have the term "AAA binding" > > mentioned here > > > > (see 10.2.4, 10.2.5 below). E.g. > > > > OLD: > > > > | DESCRIPTION "An entry in this table maps the > > combination > > > > | of a > > > > NEW: > > > > | DESCRIPTION "An entry in this table represents > > a AAA binding > > > > | which maps the combination of a > > > > > > I'm not wild about the way "AAA binding" is turning into a term in > > > > this document. It just crept in in June to address DBH's comments. > > > > I'd rather find a way to get rid of the phrase, rather than turn > it > > > into a technical term. > > > > > > As a counter-proposal, I suggest eliminating "AAA binding" from > the > > > two places where it appears. > > > > Well, "AAA binding" is just short-cut notation for "The SNMP > > SecurityName that has been authenticated by RADIUS as a RADIUS > > User-Name Attribute". It seems we can either have accuracy or > > conciseness, but not both. I don't think that coming up with a > > short-form notational device, for use within the scope of a single > > document is such a bad idea. On the other hand, simply > deleting text > > is worse, if we actually lose the fully nuanced meaning of > the concept > > being referenced. > > > > > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From dnelson@elbrys.com Tue Aug 24 08:40:35 2010 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 ECA203A6896; Tue, 24 Aug 2010 08:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ua9t4eQRI6yj; Tue, 24 Aug 2010 08:40:23 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 3452C3A6A35; Tue, 24 Aug 2010 08:40:23 -0700 (PDT) Received: from source ([209.85.216.174]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTHPoB3DmxxdcGPjzLfbjetgNeSdf0woT@postini.com; Tue, 24 Aug 2010 08:40:56 PDT Received: by mail-qy0-f174.google.com with SMTP id 9so3837021qyk.19 for ; Tue, 24 Aug 2010 08:40:55 -0700 (PDT) Received: by 10.229.189.143 with SMTP id de15mr4985096qcb.35.1282664454045; Tue, 24 Aug 2010 08:40:54 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id t4sm234019qcs.16.2010.08.24.08.40.52 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 08:40:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "David B. Nelson" In-Reply-To: <8D73F6E66A8B442AAAC27330A1BED193@23FX1C1> Date: Tue, 24 Aug 2010 11:40:46 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><002f01cb4307$f3867b20$6801a8c0@oemcomputer><09FF2324BC5A4B4090D803B81EA84523@NEWTON603> <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> <8D73F6E66A8B442AAAC27330A1BED193@23FX1C1> To: "David Harrington" X-Mailer: Apple Mail (2.1081) Cc: isms@ietf.org, 'Glenn Mansfield Keeni' , ietfmibs@ietf.org Subject: Re: [Isms] AAA binding 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: Tue, 24 Aug 2010 15:40:35 -0000 On Aug 24, 2010, at 11:11 AM, David Harrington wrote: > A "AAA binding" binds > 1) a communications channel > 2) an authenticated principal > 3) service authorization > 4) an access control policy name +1 From dnelson@elbrys.com Tue Aug 24 08:57:03 2010 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 E8EE03A6894; Tue, 24 Aug 2010 08:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AUTbaywdBRB; Tue, 24 Aug 2010 08:56:56 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 098CA3A6887; Tue, 24 Aug 2010 08:56:51 -0700 (PDT) Received: from source ([209.85.216.180]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTHPr5Il5U2Ui48CIdvM2WWmeYZ/MTK01@postini.com; Tue, 24 Aug 2010 08:57:25 PDT Received: by mail-qy0-f180.google.com with SMTP id 31so5893187qyk.11 for ; Tue, 24 Aug 2010 08:57:24 -0700 (PDT) Received: by 10.229.235.65 with SMTP id kf1mr4978737qcb.42.1282665444437; Tue, 24 Aug 2010 08:57:24 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id t4sm246626qcs.28.2010.08.24.08.57.23 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Aug 2010 08:57:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "David B. Nelson" In-Reply-To: <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> Date: Tue, 24 Aug 2010 11:57:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><002f01cb4307$f3867b20$6801a8c0@oemcomputer> <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> To: "David Harrington" X-Mailer: Apple Mail (2.1081) Cc: isms@ietf.org, 'Glenn Mansfield Keeni' , ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 15:57:03 -0000 On Aug 24, 2010, at 10:34 AM, David Harrington wrote: > I think that's an incomplete description of "AAA binding". Agreed. I like the description in your follow up message. My primary = point was that we should not attempt to remove this term, but rather = make sure it's properly defined in the front-matter of the document. From randy_presuhn@mindspring.com Tue Aug 24 10:33:11 2010 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 D6CB83A67F4; Tue, 24 Aug 2010 10:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 CddPGSZZBspn; Tue, 24 Aug 2010 10:33:11 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id DEFC03A67DA; Tue, 24 Aug 2010 10:33:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=mw4ryJoSfeTl2Lekf/hu/o2b1h9Qtpfo3yuZBKzOQfZPMKTa+RwsxSx98HnusEdp; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.54.49] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OnxNU-0004fT-70; Tue, 24 Aug 2010 13:33:40 -0400 Message-ID: <007601cb43b2$7cdba440$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "David Harrington" , "'Dave Nelson'" , "'Glenn M. Keeni'" , , "'Glenn Mansfield Keeni'" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><002f01cb4307$f3867b20$6801a8c0@oemcomputer> <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> Date: Tue, 24 Aug 2010 10:33:36 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fecfedeb8f5073a9deaaf3c7a263b6c4c1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.54.49 Cc: ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 17:33:12 -0000 Hi - > From: "David Harrington" > To: "'Dave Nelson'" ; "'Randy Presuhn'" ; "'Glenn M. Keeni'" ; ; "'Glenn Mansfield Keeni'" > Cc: > Sent: Tuesday, August 24, 2010 7:34 AM > Subject: RE: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I ... > The term "AAA binding" refers to this binding of concepts in a > specific manner to provide the correct security properties. > > Randy, do you have the email where I used that term? Can you post it > or point to it? I can't locate it. June 8. Link: http://www.ietf.org/mail-archive/web/isms/current/msg04321.html Randy From j.schoenwaelder@jacobs-university.de Tue Aug 24 14:17:54 2010 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 1A4143A6952; Tue, 24 Aug 2010 14:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.845 X-Spam-Level: X-Spam-Status: No, score=-101.845 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 o+hp4gCKKkiI; Tue, 24 Aug 2010 14:17:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 877A53A690F; Tue, 24 Aug 2010 14:17:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10196C0009; Tue, 24 Aug 2010 23:18:24 +0200 (CEST) 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 Z-B7dQmW5ELw; Tue, 24 Aug 2010 23:18:22 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70EE3C0007; Tue, 24 Aug 2010 23:18:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A23B14618C3; Tue, 24 Aug 2010 23:18:03 +0200 (CEST) Date: Tue, 24 Aug 2010 23:18:03 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100824211803.GA69465@elstar.local> Mail-Followup-To: David Harrington , 'Dave Nelson' , 'Randy Presuhn' , "'Glenn M. Keeni'" , "isms@ietf.org" , 'Glenn Mansfield Keeni' , "ietfmibs@ietf.org" References: <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <002f01cb4307$f3867b20$6801a8c0@oemcomputer> <09FF2324BC5A4B4090D803B81EA84523@NEWTON603> <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EFD8C84A9484026A29E40CE000A6F4D@23FX1C1> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" , 'Glenn Mansfield Keeni' , "ietfmibs@ietf.org" Subject: Re: [Isms] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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: Tue, 24 Aug 2010 21:17:54 -0000 On Tue, Aug 24, 2010 at 04:34:07PM +0200, David Harrington wrote: > Hi, > > (as a technical contributor) > > I think that's an incomplete description of "AAA binding". > > If you go back to my June(?) analysis, I started using that term > because SSH has certain security assumptions, RADIUS has certain > security assumptions, and SNMP has certain security assumptions, and > those assumptions differ and conflict. > > The assumptions ended up being met by following the elements of > procedure in the correct order. Off the top of my head, I don't > remember the specifics. It's in my June(?) email. As I recall, > processing SSH and RADIUS concepts as per the EOP led to a "binding" > that satisfied the SSH security assumptions and the RADIUS security > assumptions, and then additional processing took the result of that > binding and bound it to SNMP elements (modularity and the ASI > parameters I think) that ended up meeting SNMP security assumptions. I > think it is important to explain how the current document's EOP allows > these conflicting assumptions to be satisfied while still maintaining > RFC3411 modularity. > > The term "AAA binding" refers to this binding of concepts in a > specific manner to provide the correct security properties. > > Randy, do you have the email where I used that term? Can you post it > or point to it? I can't locate it. I am still trying to understand what is unclear that an implementor won't do the right thing... /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 Tue Aug 24 14:24:06 2010 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 525513A695E; Tue, 24 Aug 2010 14:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 FzEDnLAYrAgJ; Tue, 24 Aug 2010 14:24:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 440A93A690F; Tue, 24 Aug 2010 14:24:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09A9BC000D; Tue, 24 Aug 2010 23:24:38 +0200 (CEST) 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 3-jw4fP+gfo4; Tue, 24 Aug 2010 23:24:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF3DDC0007; Tue, 24 Aug 2010 23:24:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 22554146190F; Tue, 24 Aug 2010 23:24:23 +0200 (CEST) Date: Tue, 24 Aug 2010 23:24:23 +0200 From: Juergen Schoenwaelder To: "Glenn M. Keeni" Message-ID: <20100824212423.GB69465@elstar.local> Mail-Followup-To: "Glenn M. Keeni" , "isms@ietf.org" , Glenn Mansfield Keeni , "ietfmibs@ietf.org" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C73D72D.8070902@cysols.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Glenn Mansfield Keeni , "ietfmibs@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Tue, 24 Aug 2010 21:24:06 -0000 On Tue, Aug 24, 2010 at 04:29:01PM +0200, Glenn M. Keeni wrote: > Thanks for waiting. This is the Part-II of the MIB Doctor Review > of draft-ietf-isms-radius-vacm-09.txt. It focuses on the Document > issues. [...] I am wondering whether we are preparing for a beauty contest here or whether there is really something so fundamentally unclear that people can't implement things correctly. Some of the suggested changes IMHO make the document more difficult to read; while trying to improve purity of the terminology, we loose clarity of the sentences. /js (speaking as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From glenn@cysols.com Tue Aug 24 19:07:59 2010 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 85DBE3A6968; Tue, 24 Aug 2010 19:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.448 X-Spam-Level: X-Spam-Status: No, score=0.448 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 hZNR83ad9Pkj; Tue, 24 Aug 2010 19:07:57 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id 4BD353A67FB; Tue, 24 Aug 2010 19:07:57 -0700 (PDT) Received: from [127.0.0.1] (Bert.win2004.cysol.co.jp [192.168.0.198]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7P28IgH050946 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 11:08:19 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C747B0F.3020206@cysols.com> Date: Wed, 25 Aug 2010 11:08:15 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Randy Presuhn References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <002f01cb4307$f3867b20$6801a8c0@oemcomputer> In-Reply-To: <002f01cb4307$f3867b20$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-I 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: Wed, 25 Aug 2010 02:07:59 -0000 Hi, >> 2. Abstract -- OK. >> Please move the "Comments are solicited ... org" part to >> Status of this Memo section or any other more appropriate >> place. > > If this sentence is a problem, then I propose just deleting it. OK. > >> 3. MIB Boilerplate -- OK. >> Body of the boilerplate is verbatim. >> References are not not exact copies. >> For RFC2578, RFC2579, there is an additional "Ed.," for >> each author which is not there in the boilerplate. But >> this is not a problem. It accurately reflects the actual >> RFCs. > > > The references are what is generated by the current xml2rfc. > If this is a problem, then I suggest that either the boilerplate > or xml2rfc's citation library should be fixed. > > I propose that no changes be made to this document here. There is no issue here. It is mentioned above - "this is not a problem.". > >> 4. Security Considerations Section -- OK. >> The Sensitive objects are listed but the risk/vulnerability >> is not mentioned. >> I would recommend adding something like >> These objects may reveal that User X has logged on with >> Security privileges Y in session Z . >> This raises atleast two issues. >> o Revealing the information may amount to breaching the >> privacy of the User. >> o The information may be misused by an attacker. E.g. >> he/she may focus/narrow down his/her attack by making >> informed guesses about the target system. > > I'm not sure how useful it is to enumerate specific ways in which > information already identified as potentially sensitive might be misused. > Since the security considerations section was quite contentious during the > development of this document, I'd like to see some indication > from the WG / Chairs whether the proposed text is actually necessary. OK. > I assume you want the suggested text inserted immediately prior to the > paragraph beginning "SNMP versions". Correct. > >> 5. IANA Considerations Section -- OK. >> 6. References -- NOK. >> 6.1 RFC 5590 to be added >> | vacmAaaSessionID OBJECT-TYPE >> | SYNTAX Unsigned32 >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "A specific identifier of the session. >> | >> | This value MUST be unique among all currently open >> | sessions of all of this SNMP engine's transport >> models. >> | The value has no particular significance other >> than to >> | distinguish sessions. Implementations in which >> | tmSessionID is unique across all transport >> models MAY >> | use the tmSessionID value." >> | ::= { vacmAaaSecurityToGroupEntry 3 } >> A reference to RFC 5590 where the object "tmSessionID" is >> probably defined, is required. >> [I note that the reference was there in the earlier versions >> of this memo but then it got removed along with "tmStateReference" >> http://www.ietf.org/mail-archive/web/isms/current/msg04177.html] >> Please put it back. Also, please note that this will be a >> normative reference. > > Given the contentiousness of this item, instead I would propose deleting > the sentence "Implementations in which tmSessionID is unique across > all transport models MAY use the tmSessionID value" and NOT adding > a reference, and NOT adding a REFERENCE. If the WG agrees with that change - this is acceptable. > >> 6.2 A reference to AAA service architecture/Framework will be >> in order if this document does target generic AAA services >> (as the title suggests). > > Where would we need to reference such a reference? Text please. The right place would be in the Introduction section where Authorization, and Accounting (AAA) service is mentioned for the first time. OLD: | Model (VACM) [RFC3415] MIB objects, based on information received | from an Authentication, Authorization, and Accounting (AAA) service, | such as RADIUS [RFC2865]. NEW: | Model (VACM) [RFC3415] MIB objects, based on information received | from an Authentication, Authorization, and Accounting (AAA) service | [RFC2903, RFC2904], such as RADIUS [RFC2865]. > >> 7. Copyright notices -- OK. >> Not in accordance with rfc3978 as reqd by rfc4181 but follows >> the latest requirements as in >> http://www.ietf.org/ietf-ftp/1id-guidelines.txt. >> 8. IPR notices -- OK. >> Not in accordance with rfc3978 as reqd by rfc4181 but follows >> the latest requirements as in >> http://www.ietf.org/ietf-ftp/1id-guidelines.txt. >> 9. Other Issues: >> a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to >> the list of imperatives (although the standard boilerplate in >> RFC 2119 does not include it, it is used in the Security >> Considerations section and it is defined in RFC 2119). > > OK. Should I also remove from the list the ones that are not used? > Will any of these changes cause idnits to freak out? No idea. > >> 10.Technical content -- review of actual technical content for >> compliance with rfc4181 >> 10.1 MIB compilation using smilint -- OK. >> >> 10.2 MIB issues >> 10.2.1 In the MODULE-IDENTITY >> | REVISION "201007150000Z" >> | DESCRIPTION "Initial version, published as RFC XXXX." >> | ::= { mib-2 XXX } >> the note to the RFC-Editor to handle the literal XXX is >> missing. I suggest- >> OLD: >> | REVISION "201007150000Z" >> | DESCRIPTION "Initial version, published as RFC XXXX." >> | ::= { mib-2 XXX } >> NEW: >> | REVISION "201007150000Z" >> | DESCRIPTION "Initial version, published as RFC XXXX." >> | ::= { mib-2 XXX } >> | -- RFC Ed.: replace XXX with IANA-assigned number& remove >> this note > > The complete instructions are already present in the IANA considerations section. > Do we really want the same instructions in multiple locations? That will make it comply with RFC 4181 section 4.5. > >> 10.2.2 the naming of the objects: >> In the MIB module the naming hierarchy uses the following >> prefixes >> snmpVacmAaaMIB >> | >> +-- vacmAaaMIBObjects >> | >> +-- vacmAaaMIBCompliance >> >> This does not follow the recommended naming conventions >> given in Appendix C of RFC 4181 which urges the pattern >> >> snmpVacmAaaMIB >> | >> +-- snmpVacmAaaMIBObjects >> | >> +-- snmpVacmAaaMIBCompliance >> >> Please note, I have not found any opinions strong or weak >> about the naming in the ISMS-WG mailing list archives. >> [I have not looked at the archives in detail] >> If the naming in the document is the result of deliberations >> in the WG, please ignore this comment. Otherwise, please >> consider the usage of the naming convention recommended in >> RFC 4181. > > Given the large number of changes to both the MIB module and the > text that this would entail, I'd like to make a counter-proposal: > > SNMP-VACM-AAA-MIB -> VACM-AAA-MIB > snmpVacmAaaMIB -> vacmAaaMIB > > These two (relatively isolated) changes would satisfy the naming guideline > consistency request, with much lower risk of screwing something up in > the editing process. No disagreement, if WG agrees with that change - this is acceptable. > >> 10.2.3 In the DESCRIPTION vacmAaaSecurityToGroupEntry row object. >> | vacmAaaSecurityToGroupEntry OBJECT-TYPE >> | SYNTAX VacmAaaSecurityToGroupEntry >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "An entry in this table maps the combination of a >> | SnmpSecurityModel and SecurityName into a >> GroupName for >> | a particular session. >> | >> | Each entry corresponds to a session. >> | >> | Entries do not persist across reboots. >> | >> | When a session is torn down, disconnected, timed out >> | (e.g. following the RADIUS Session-Timeout >> Attribute), >> | or otherwise terminated for any reason, the >> | corresponding vacmAaaSecurityToGroupEntry is >> deleted." >> >> There is a need to mention the conditions under which the row is >> created. >> According to RFC 4181 >> "If the agent itself may also create and/or delete rows, then the >> conditions under which this can occur MUST be clearly documented >> in the row object DESCRIPTION clause." >> >> The details are present in Section 7.2.1. Please add the relevant >> part to the DESCRIPTION clause of this object. (That includes the >> row update protocol.) > > Ok. My understanding is the proposal is to clone the content of section 7.2.1 > within the DESCRIPTION of vacmAaaSecurityToGroupEntry. Yes. I will also go on to add that since the intent given RFC 4181 sec 4.6.2 says 4.6.2. DESCRIPTION and REFERENCE Clauses It is hard to overemphasize the importance of an accurate and unambiguous DESCRIPTION clause for all objects and TCs. The DESCRIPTION clause contains the instructions that implementors will use to implement an object, and if they are inadequate or ambiguous, then implementation quality will suffer. Probably the single most important job of a MIB reviewer is to ensure that DESCRIPTION clauses are sufficiently clear and unambiguous to allow interoperable implementations to be created. you must add the specifications given in of 7.2.1, 7.2.2, 7.2.3, 7.3.1, 7.3.2 to the DESCRIPTION of the Table. The present DESCRIPTION does not capture the specifications. > >> It will be useful to have the term "AAA binding" mentioned here >> (see 10.2.4, 10.2.5 below). E.g. >> OLD: >> | DESCRIPTION "An entry in this table maps the combination of a >> NEW: >> | DESCRIPTION "An entry in this table represents a AAA binding >> | which maps the combination of a > > I'm not wild about the way "AAA binding" is turning into a term in this > document. It just crept in in June to address DBH's comments. I'd rather > find a way to get rid of the phrase, rather than turn it into a technical term. > As a counter-proposal, I suggest eliminating "AAA binding" from the two > places where it appears. No disagreement. > >> The terms "SnmpSecurityModel" and "SecurityName" are confusing as >> they represent TEXTUAL CONVENTIONS which in turn represent the >> SYNTAX and to some extent the semantics of objects. These are not >> objects. I recommend using "Security Model" and "Security Name". These terms >> are used (not defined) in subsequent object DESCRIPTIONS. > > Just in the MIB module or throughout the document? In terms of mimizing the number > of changes to the document, I think it might be better to get rid of "Security Model" > (appearing only once) and "Security Name" (appearing only twice). For consistency - this needs to be done throughout the document, I am afraid. > >> 10.2.4 >> | vacmAaaSecurityModel OBJECT-TYPE >> | SYNTAX SnmpSecurityModel(1..2147483647) >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "The Security Model associated with the AAA binding >> | represented by this entry. >> | >> | This object cannot take the 'any' (0) value." >> | ::= { vacmAaaSecurityToGroupEntry 1 } >> >> The term "AAA binding" appears for the first time here. >> (And in subsequent Object DESCRIPTIONs.). This term needs >> to be defined. >> [This will be remedied if the recommendation in 10.2.3 is >> implemented.] >> >> The term "Security Model" appears for the first time here. >> Presumably it is the term defined in RFC3411. >> A REFERENCE clause would be appropriate here. E.g. >> OLD: >> | vacmAaaSecurityModel OBJECT-TYPE >> | SYNTAX SnmpSecurityModel(1..2147483647) >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "The Security Model associated with the AAA binding >> | represented by this entry. >> | >> | This object cannot take the 'any' (0) value." >> | ::= { vacmAaaSecurityToGroupEntry 1 } >> NEW: >> | vacmAaaSecurityModel OBJECT-TYPE >> | SYNTAX SnmpSecurityModel(1..2147483647) >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "The Security Model associated with the AAA binding >> | represented by this entry. >> | >> | This object cannot take the 'any' (0) value." >> | REFERENCE "RFC 3411; Section 3.1.1.4.1" >> | ::= { vacmAaaSecurityToGroupEntry 1 } > > Suggest deleting "the AAA binding represented by" to satisty earlier comments. > > It's not clear to me how this REFERENCE clause would be helpful, > since the relevant semantics come with the textual convention itself. The REFERENCE is needed to nail down the term "Security Model" used in the DESCRIPTION. > >> 10.2.5 >> | vacmAaaSecurityName OBJECT-TYPE >> | SYNTAX SnmpAdminString (SIZE(1..32)) >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "The Security Name of the principal associated >> with the >> | AAA binding represented by this entry. In RADIUS >> | environments, this corresponds to the User-Name >> | Attribute." >> | ::= { vacmAaaSecurityToGroupEntry 2 } >> >> The term "AAA binding" appears for the first time here. >> A clear description of this term should be given. >> [This will be remedied if the recommendation in 10.2.3 is >> implemented.] > > I think it might be simpler to just delete "the AAA binding represented by". I do not disagree. > >> The term "Security Name" is used here. It is first used in >> Section 7.1 in the context "SNMP Security Name [RFC3411]". >> RFC 3411 does NOT have the term Security Name. It has a >> "securityName" object, though. In this memo there is no >> other reference to "Security Name". > > "securityName" is used fairly consistently in the rest of the document, so > that would be my first choice for a replacement. "SNMP Security Name" > would be a close second. Sounds reasonable. > >> The DESCRIPTION says "In RADIUS environments, this corresponds >> to the User-Name Attribute." >> To me it appears that in the AAA/RADIUS context this is the >> "User-Name" (RFC 2865 section 5.1) and in VACM context it is >> "securityName" (RFC 3411 section 3.2.2). >> >> Please >> o fix the DESCRIPTION; >> o add a REFERENCE clause citing the appropriate >> document(s). > > Ok. However, as a technical contributor this use of REFERENCE > does not seem terribly helpful to me, and I would like to hear > from others before I go ahead as editor and make this and similar changes. > Lets hear. I will respect your opinion that it is not "terribly helpful". Some may find it useful. I would like to hear the REFERENCE is a problem- noisy or whatever. >> 10.2.6 >> | vacmAaaSessionID OBJECT-TYPE >> | SYNTAX Unsigned32 >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "A specific identifier of the session. >> | >> | This value MUST be unique among all currently open >> | sessions of all of this SNMP engine's transport >> models. >> | The value has no particular significance other >> than to >> | distinguish sessions. Implementations in which >> | tmSessionID is unique across all transport >> models MAY >> | use the tmSessionID value." >> | ::= { vacmAaaSecurityToGroupEntry 3 } >> the object tmSessionID appears in this DESCRIPTION clause for >> the first time in this memo. Presumably this refers to the >> tmSessionID object in RFC 5590. >> Please add a REFERENCE clause citing the appropriate section >> in RFC 5590. E.g. >> OLD: >> | vacmAaaSessionID OBJECT-TYPE >> | SYNTAX Unsigned32 >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "A specific identifier of the session. >> | >> | This value MUST be unique among all currently open >> | sessions of all of this SNMP engine's transport >> models. >> | The value has no particular significance other >> than to >> | distinguish sessions. Implementations in which >> | tmSessionID is unique across all transport models MAY >> | use the tmSessionID value." >> | ::= { vacmAaaSecurityToGroupEntry 3 } >> NEW: >> | vacmAaaSessionID OBJECT-TYPE >> | SYNTAX Unsigned32 >> | MAX-ACCESS not-accessible >> | STATUS current >> | DESCRIPTION "A specific identifier of the session. >> | >> | This value MUST be unique among all currently open >> | sessions of all of this SNMP engine's transport >> models. >> | The value has no particular significance other >> than to >> | distinguish sessions. Implementations in which >> | tmSessionID is unique across all transport models MAY >> | use the tmSessionID value." >> | REFERENCE "RFC 5590: Section 4.1.2" >> | ::= { vacmAaaSecurityToGroupEntry 3 } > > I think it's better to remove all reference to tmSessionID. Providing any > hints to implementors has been contentious. REQUIRing this > to be tmSessionID would make this table more useful, but tmSessionID > is so under-specified as to preclude this possibility. This also avoids > any need to reference RFC 5590. No disagreement. > >> 10.3 Document issues >> TBD > > When? Done. > > Randy > Glenn From glenn@cysols.com Tue Aug 24 19:52:04 2010 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 948CC3A6A7B; Tue, 24 Aug 2010 19:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 smxvRx7i+9AF; Tue, 24 Aug 2010 19:52:03 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id 7EE283A67FB; Tue, 24 Aug 2010 19:52:03 -0700 (PDT) Received: from [127.0.0.1] (Bert.win2004.cysol.co.jp [192.168.0.198]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7P2qRVM055288 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 11:52:31 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C74856B.8050007@cysols.com> Date: Wed, 25 Aug 2010 11:52:27 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "isms@ietf.org" , Glenn Mansfield Keeni , "ietfmibs@ietf.org" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com> <20100824212423.GB69465@elstar.local> In-Reply-To: <20100824212423.GB69465@elstar.local> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 02:52:04 -0000 On 2010/08/25 6:24, Juergen Schoenwaelder wrote: > On Tue, Aug 24, 2010 at 04:29:01PM +0200, Glenn M. Keeni wrote: > >> Thanks for waiting. This is the Part-II of the MIB Doctor Review >> of draft-ietf-isms-radius-vacm-09.txt. It focuses on the Document >> issues. > > [...] > > I am wondering whether we are preparing for a beauty contest here or > whether there is really something so fundamentally unclear that people > can't implement things correctly. Some of the suggested changes IMHO > make the document more difficult to read; while trying to improve > purity of the terminology, we loose clarity of the sentences. The present activity is part of the process to bring the quality of the document to the level of an IETF Standard. Compliance to processes and guidelines (e.g. RFC 4181) and, unambiguous and consistent terminology is a requirement. I agree that there maybe exceptional cases. We have the flexibility to handle exceptions. Lets discuss the specific issues. > > /js (speaking as contributor) > Glenn From randy_presuhn@mindspring.com Tue Aug 24 20:48:36 2010 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 7CF9D3A697B; Tue, 24 Aug 2010 20:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.583 X-Spam-Level: X-Spam-Status: No, score=-100.583 tagged_above=-999 required=5 tests=[AWL=1.417, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] 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 HLBnuB4Q6YqX; Tue, 24 Aug 2010 20:48:34 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 61A3E3A6A3F; Tue, 24 Aug 2010 20:48:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tb1UwzT8zt9csxq8iiKgxT8I6A8lmme4uGn56ceNXQzYN86KxMjGeCRd5jCfLuaa; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.48.120] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Oo6yZ-00032Z-Sc; Tue, 24 Aug 2010 23:48:36 -0400 Message-ID: <017201cb4408$64797660$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Glenn M. Keeni" , , "Glenn Mansfield Keeni" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com> Date: Tue, 24 Aug 2010 20:48:32 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5feb4e34933e9193787aa424dbda325b6cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.48.120 Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 03:48:36 -0000 Hi - > From: "Glenn M. Keeni" > To: ; "Glenn Mansfield Keeni" > Cc: > Sent: Tuesday, August 24, 2010 7:29 AM > Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II > > Hi, > > Thanks for waiting. This is the Part-II of the MIB Doctor Review > of draft-ietf-isms-radius-vacm-09.txt. It focuses on the Document > issues. > > Glenn > > +--------------------------------------------------------------------+ > > 10.3 Document issues > > a. Terminology: > I suggest that a Terminology section be added. Several terms used > in this document are open to mis-interpretation. E.g. > "group": > This is a generic term. But, in this document it probably, without > exception, refers to a group as in the VACM document[RFC 3415; Sec 2.1]. > I would recommend > stating early in the document that the term "group" refers to the > term defined in [RFC 3415; Sec 2.1] or, > defining a "VACM-group" and replacing all occurrences of "group" by > "VACM-group" Ok, I will add a list of tautologies in a new "Terminology" section. However, as a technical contributor, I think the tendency to elevate each English word or phrase to the status of "term" is most unfortunate, and seriously detracts from the clarity of the document. > "authenticated user": > This is a generic term. It would be good to make it clear in the > document that the term "authenticated user" refers to a user > authenticated by the AAA services. Or, > define a "AAA-authenticated user" and use that term consistently for > the rest of the document. > [The terms "AAA-authenticated" and "AAA-authorized" are used in the > document but sporadically.] I will add these to the tautology list > The terms "Security Name", "Security Model", "Group Name" should be > defined/referred and used consistently in the document. Else, > the terms securityName, securityModel, groupName should be used > with appropriate pointers [RFC 3415]. Ok. > b. Page 4. Sec 4.1 > | The use case assumption here is that roles within an organization, > | which are reflected in VACM as groups and rules, change infrequently, > I presume "rules" refer to the "access control policy" defined in the > VACM ? If that is the case I would suggest > OLD: > | The use case assumption here is that roles within an organization, > | which are reflected in VACM as groups and rules, change infrequently, > NEW: > | The use case assumption here is that roles within an organization, > | which are reflected in VACM as groups and associated access control > | policies", change infrequently, Ok. > c. Page 5. Sec 5.2 > Suggested change- > OLD: > This table is indexed by the integer assigned to each security model > NEW: > This table is indexed by the identifier assigned to the Security Model > > [Note: Security Model needs to have a pointer/definition early in the > document.] I's like to hear others' opinions on this one. As a technical contributor, I think the proposed change of "integer" to "identifier" is misleading and potentially confusing. I will add "security model" to the list of tautologies. > d. Page 6. Sec 7.1 > | They also assume that the User-Name [RFC2865] from the RADIUS Access- > | Request message (or equivalent) corresponds to an SNMP Security Name > | [RFC3411]. > The term "SNMP Security Name" does not appear in RFC 3411. > securityName is defined in RFC 3411 section 3.2.2. > Suggested change- > OLD: > | They also assume that the User-Name [RFC2865] from the RADIUS Access- > | Request message (or equivalent) corresponds to an SNMP Security Name > | [RFC3411]. > NEW: > | They also assume that the User-Name [RFC2865] from the RADIUS Access- > | Request message (or equivalent) corresponds to an SNMP securityName > | [RFC3411]. I'll accomodate this by adding "security name" to the list of tautologies. > e. Page 7. Sec 7.2 > SnmpSecurityModel is not defined in RFC 3411 > I suggest > OLD: > | o the SnmpSecurityModel [RFC3411] needed as an index into the > | vacmSecurityToGroupTable; > NEW: > | o the SNMP Security Model, vacmSecurityModel [RFC3411], needed as an > | index into the vacmSecurityToGroupTable; > [Note: Security Model needs to have a pointer/definition early in the > document.] I think dragging in vacmSecurityModel in this way confuses rather than enlightens. Instead, the TC would make sense here, providing the syntax of the formal parameter. > f. Page 7. Sec 7.2 > the RADIUS User-Name Attribute or equivalent is also needed as an index > into the vacmSecurityToGroupTable. > I suggest > OLD: > | o the RADIUS User-Name Attribute or equivalent; > NEW: > | o the RADIUS User-Name Attribute or equivalent which will be used as > | the index, vacmSecurityName, into the vacmSecurityToGroupTable; Ok, though I think this is not helpful. > g. Page 7. Sec 7.2 > | In particular, if either the User-Name or Management-Policy-Id is > | absent, invalid, or a zero-length string, no further processing of > | the session establishment indication is undertaken. > If the SNMP Security Model has value 'any' (0) then no further > processing will be undertaken; is that correct? If that is that is > the case I suggest > OLD: > | In particular, if either the User-Name or Management-Policy-Id is > | absent, invalid, or a zero-length string, no further processing of > | the session establishment indication is undertaken. > NEW: > | In particular, if either the User-Name or Management-Policy-Id is > | absent, invalid, or a zero-length string, or, if the SNMP Security Model > | has value 'any' (0), no further processing of > | the session establishment indication is undertaken. As a technical contributor: The distinction here is between information from sources external to the implementation, and implementation-internal sources. Pointing out bad stuff that might come from an external source is probably helpful to an implementor. Identifying things that might happen if an implementation is *itself* broken seems like an endless and counter-productive path. As Editor: no action taken, pending comments from others. > h. Page 7. Sec 7.2.1 > Along the lines of the change in (e) > OLD: > | o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to > | the security model in use > NEW: > | o vacmAaaSecurityModel = value of SNMP Security Model corresponding to > | the security model in use Ok. > i. Page 7. Sec 7.2.1 > | o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, > | the securityName that will be used in invocations of the > | isAccessAllowed() abstract service interface; > "isAccessAllowed() abstract service interface" appears for the first > time. Please provide a pointer/reference. Ok. > j. Page 7. Sec 7.2.1 > The requirements for the vacmAaaSessionID are not explicit. I suggest > using text from the DESCRIPTION of vacmAaaSessionID in the MIB module. > OLD: > | o vacmAaaSessionID = unique session identifier > NEW: > | o vacmAaaSessionID = session identifier. This value MUST be unique > | among all currently open sessions of all of this SNMP engine's > | transport models. Ok. > k. Page 7. Sec 7.2.1 > | Otherwise, if the row already exists, update the vacmAaaGroupName > | with the value supplied. > It will be helpful to be explicit about "value supplied". I would > suggest > OLD: > | Otherwise, if the row already exists, update the vacmAaaGroupName > | with the value supplied. > NEW: > | Otherwise, if the row already exists, update the vacmAaaGroupName > | with the RADIUS Management-Policy-Id Attribute or equivalent. Ok. > l. Page 7. Sec 7.2.2 > Suggested change- > OLD: > | If a corresponding entry already exists in the > | vacmSecurityToGroupTable, and the row's StorageType is anything other > | than "volatile", or the RowStatus is anything other than "active", > NEW: > | If a corresponding entry already exists in the > | vacmSecurityToGroupTable, and the row's vacmSecurityToGroupStorageType > | is anything other than "volatile", or the vacmSecurityToGroupStatus is > | anything other than "active", Ok, though as a technical contributor I think this change makes the document much harder to read / understand. > m. Page 7. Sec 7.2.2 > The second paragraph does not belong to this subsection. > After making the change suggested in (l) move the paragraph (para-2) > to section 7.2.3 after the 1st paragraph. No. The paragraph belongs here - it spells out conditions under which an entry MUST NOT be created. > n. Page 7. Sec 7.2.3 > Suggested change: > OLD: > | The operational assumption here is that if the row's StorageType is > | "volatile", then this entry was probably dynamically created; an > | entry created by a security administrator would not normally be given > | a StorageType of "volatile". If value being provided by RADIUS (or > NEW: > | The operational assumption here is that if the row's > | vacmSecurityToGroupStorageType is "volatile", then this entry was > | probably dynamically created; an entry created by a security > | administrator would not normally be given a > | vacmSecurityToGroupStorageType of "volatile". If the value being > | provided by RADIUS (or Ok, though I think this is a huge step backwards in terms of readability. > o. Page 7. Sec 7.3.2 > s/StorageType/vacmSecurityToGroupStorageType/g; Ok, though I think this is a huge step backwards in terms of readability. > p. An overview describing the relevant parts of the AAA service and the > VACM may be helpful to make the memo more easily understandable. The > other option which I will not recommend will be to include a statement > as terse as "the reader of this memo is expected to have read and > understood the AAA service document RFC XXX1, the RADIUS document RFC > XXX2 and the View-Based Access Control Model document RFC XXX3." I'll take the latter option. The document is already far too long as it is, considering how little it actually does. > q. AAA and RADIUS. > I see that this has been discussed in the mailing list before. But I > am afraid that the problem persists. > > Editorial nits. > > a. Page 12 Sec 9 > OLD: > | could also occur if the SNMP security administrator had mistakenly > | created these non-volatile entries in error. > NEW: > | could also occur if the SNMP security administrator had mistakenly > | created these non-volatile entries. Ok Randy From randy_presuhn@mindspring.com Tue Aug 24 21:12:23 2010 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 BF2BA3A6A7F; Tue, 24 Aug 2010 21:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.991 X-Spam-Level: X-Spam-Status: No, score=-99.991 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_50=0.001, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100] 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 qEgJcNakDEEj; Tue, 24 Aug 2010 21:12:17 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id C4B663A6947; Tue, 24 Aug 2010 21:12:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=f1MX2KNi+OkLozHJUmlnL2vpUAv7q/hZkkF5s/Q0mS3ub/SK1kOkRILaNkw9mGde; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.48.120] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Oo7Lf-0007iG-Vy; Wed, 25 Aug 2010 00:12:29 -0400 Message-ID: <01b501cb440b$baae3860$6801a8c0@oemcomputer> From: "Randy Presuhn" To: , Date: Tue, 24 Aug 2010 21:12:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5febb7c76c57e4868d0a8a399ca484bf2b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.48.120 Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, IESG Subject: [Isms] Proposed resolution of comments on draft-ietf-isms-radius-vacm-09.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: Wed, 25 Aug 2010 04:12:24 -0000 Hi - Since the comments have been arriving for over three weeks, here's a summary of where I think we stand with the comments on draft-ietf-isms-radius-vacm-09.txt Please note that in a few cases there are potential conflicts / interactions between the comments. Due to the extensive nature of the changes needed to accommodate the MIB review, in my personal opinion this document should go back to the working group for another last call to make sure these changes haven't broken something. Comment from Amanda Baber, July 30, 2010: IANA has reviewed draft-ietf-isms-radius-vacm-09.txt, which is currently in Last Call, and has the following comments: We understand that, upon publication of this document, IANA will be expected to register the following MIB-2 number at http://www.iana.org/assignments/smi-numbers Decimal Name Description References ------- ---- ----------- ---------- [TBD] snmpVacmAaaMIB SNMP-VACM-AAA-MIB [RFC-ietf-isms-radius-vacm-09.txt] Action: None Notes: This interacts with the MIB review comment on naming Comment from Joel Jaeggli, August 8, 2010: ... The security considerations section (9) goes far beyond the ordinary enumeration of limitations and recommendations in order proscribe procedural behaviors that should be in force in an implementation of VACM. I'm of two minds on the contnent of the security considerations section. Either it should be sub-divided to seperately deal with the identity/access control considerations and the sensitivity of exposure of various mib elements or the access control considerations should be moved to the procedural section (7) since the following section of (9) is essentially an implementation detail. ... Action: security considerations section split accordingly, with new subsection headings "Principal Identity Naming" and "Management Information Considerations". Notes: No substantive changes here. Comment from Magnus Nyström, August 16, 2010: 1. (Editorial:) Suggest letting the first paragraph form a new sub-subsection 7.2.1: "Required Information". Easier to reference. Action: done Comment from Magnus Nyström, August 16, 2010: 2. In the current subsection 7.2, please clarify if all items are required for "further processing" or not. The current text just states that User-Name and Management-Policy-ID are. Action: done. Added "All four of these pieces of information are REQUIRED" after the list. Comment from Magnus Nyström, August 16, 2010: 3. Current sub-subsection 7.2.1 seems to indicate that neither the User-Name nor the Management-Policy-ID are required (says "or equivalent"). Please clarify if this is inconsistent with the text in 7.2 or not (maybe I'm missing something here). Action: none Notes: Dave Nelson sent Magnus a detailed explanation on the future- proofing rationale behind the language. My understanding is that no specific change has been requested here. Comment from Magnus Nyström, August 16, 2010: 4. In Section 7.2.3, how many groups can a user be a member of for a given securityModel in this design? Only one? Action: clarify by adding this sentence at the end of 7.2.3: The structure of the vacmSecurityToGroupTable makes it impossible for a vacmSecurityModel, vacmSecurityName tuple to map to more than one group. Comment from Francis Dupont, August 17, 2010: - 1 page 3: perhaps (because it is in the 'well known' list) you should put again the definition of the "MIB" abbrev? - 4.1 page 4: the user-to-role (group) mapping -> mappings? - 4.1 page 4 (last word): behaviour -> behavior - 7.1 page 6: They rely critically -> They critically rely? - 7.2.1 page 7: in use -> in use; and identifier -> identifier; (the ; at the end of list items is the French typo rule, I don't know the English one, nor the RFC one if there is one :-) - 7.2.3 page 8 (last line): supercede -> supersede - 8 page 9: LAST-UPDATED "201007150000Z" -- 14 July, 2010 -> 15 July - 8 page 10 vacmAaaSecurityToGroupTable: used for the -> used for the - 8 page 10 vacmAaaSecurityToGroupEntry: e.g. -> e.g., - 9 page 13: dangling ')'? in 'RADIUS User-Name).' Action: all comments accommodated, except the change from "mapping" to "mappings" which could be potentially misleading. Comment from Glenn M. Keeni, August 23, 2010: 1. I-D Boilerplate -- OK. Action: none needed Comment from Glenn M. Keeni, August 23, 2010: 2. Abstract -- OK. Please move the "Comments are solicited ... org" part to Status of this Memo section or any other more appropriate place. Action: offending text deleted Comment from Glenn M. Keeni, August 23, 2010: 3. MIB Boilerplate -- OK. Body of the boilerplate is verbatim. References are not not exact copies. For RFC2578, RFC2579, there is an additional "Ed.," for each author which is not there in the boilerplate. But this is not a problem. It accurately reflects the actual RFCs. Action: none Comment from Glenn M. Keeni, August 23, 2010: 4. Security Considerations Section -- OK. The Sensitive objects are listed but the risk/vulnerability is not mentioned. I would recommend adding something like These objects may reveal that User X has logged on with Security privileges Y in session Z . This raises atleast two issues. o Revealing the information may amount to breaching the privacy of the User. o The information may be misused by an attacker. E.g. he/she may focus/narrow down his/her attack by making informed guesses about the target system. Action: none Notes: comment discussed, consensus that sufficient information is already present Comment from Glenn M. Keeni, August 23, 2010: 5. IANA Considerations Section -- OK. Action: none Notes: This section may need to change, depending on how the comments on naming are resolved. Comment from Glenn M. Keeni, August 23, 2010: 6. References -- NOK. 6.1 RFC 5590 to be added | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | ::= { vacmAaaSecurityToGroupEntry 3 } A reference to RFC 5590 where the object "tmSessionID" is probably defined, is required. [I note that the reference was there in the earlier versions of this memo but then it got removed along with "tmStateReference" http://www.ietf.org/mail-archive/web/isms/current/msg04177.html] Please put it back. Also, please note that this will be a normative reference. Action: Add a REFERENCE clause to this OBJECT-TYPE, pointing to RFC 5590 Add RFC 5590 to the list of normative references. Notes: I believe we'll also need to cite this reference somewhere outside the MIB module to satisfy idnits. We need proposed text. Note well that the WG consensus was to DELETE the only bit of text referring to RFC 5590. As a technical contributor, I'm not sure this is really a normative reference, since it's really only an example of what may be done - it's not really "OPTIONAL" in the normal sense of MAY. Comment from Glenn M. Keeni, August 23, 2010: 6.2 A reference to AAA service architecture/Framework will be in order if this document does target generic AAA services (as the title suggests). Action: add citations suggested by reviewer in followup message OLD: | Model (VACM) [RFC3415] MIB objects, based on information received | from an Authentication, Authorization, and Accounting (AAA) service, | such as RADIUS [RFC2865]. NEW: | Model (VACM) [RFC3415] MIB objects, based on information received | from an Authentication, Authorization, and Accounting (AAA) service | [RFC2903, RFC2904], such as RADIUS [RFC2865]. Comment from Glenn M. Keeni, August 23, 2010: 7. Copyright notices -- OK. Not in accordance with rfc3978 as reqd by rfc4181 but follows the latest requirements as in http://www.ietf.org/ietf-ftp/1id-guidelines.txt. Action: none Comment from Glenn M. Keeni, August 23, 2010: 8. IPR notices -- OK. Not in accordance with rfc3978 as reqd by rfc4181 but follows the latest requirements as in http://www.ietf.org/ietf-ftp/1id-guidelines.txt. Action: none Comment from Glenn M. Keeni, August 23, 2010: 9. Other Issues: a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to the list of imperatives (although the standard boilerplate in RFC 2119 does not include it, it is used in the Security Considerations section and it is defined in RFC 2119). Action: none Notes: this is a long-standing RFC 2119 problem to be sorted out by the IESG. This document uses the standard boilerplate. Comment from Glenn M. Keeni, August 23, 2010: 10.Technical content -- review of actual technical content for compliance with rfc4181 10.1 MIB compilation using smilint -- OK. Action: none Notes: due to other extensive changes recommended by this reviewer, the MIB will need to be re-checked Comment from Glenn M. Keeni, August 23, 2010: 10.2 MIB issues 10.2.1 In the MODULE-IDENTITY | REVISION "201007150000Z" | DESCRIPTION "Initial version, published as RFC XXXX." | ::= { mib-2 XXX } the note to the RFC-Editor to handle the literal XXX is missing. I suggest- OLD: | REVISION "201007150000Z" | DESCRIPTION "Initial version, published as RFC XXXX." | ::= { mib-2 XXX } NEW: | REVISION "201007150000Z" | DESCRIPTION "Initial version, published as RFC XXXX." | ::= { mib-2 XXX } | -- RFC Ed.: replace XXX with IANA-assigned number & remove this note Action: add the RFC editor note Notes: this new text is redundant with the RFC editor note already present in the IANA considerations section Comment from Glenn M. Keeni, August 23, 2010: 10.2.2 the naming of the objects: In the MIB module the naming hierarchy uses the following prefixes snmpVacmAaaMIB | +-- vacmAaaMIBObjects | +-- vacmAaaMIBCompliance This does not follow the recommended naming conventions given in Appendix C of RFC 4181 which urges the pattern snmpVacmAaaMIB | +-- snmpVacmAaaMIBObjects | +-- snmpVacmAaaMIBCompliance Please note, I have not found any opinions strong or weak about the naming in the ISMS-WG mailing list archives. [I have not looked at the archives in detail] If the naming in the document is the result of deliberations in the WG, please ignore this comment. Otherwise, please consider the usage of the naming convention recommended in RFC 4181. Action: currently "c" Notes: three proposals discussed as a result of this comment: (a) do nothing (i.e., be consistent with VACM) (b) the changes suggested by Glenn (which would arguably ripple to all the MIB objects) (c) the counter-proposal suggested by Randy (changing just the module and module-identity) Comment from Glenn M. Keeni, August 23, 2010: 10.2.3 In the DESCRIPTION vacmAaaSecurityToGroupEntry row object. | vacmAaaSecurityToGroupEntry OBJECT-TYPE | SYNTAX VacmAaaSecurityToGroupEntry | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "An entry in this table maps the combination of a | SnmpSecurityModel and SecurityName into a GroupName for | a particular session. | | Each entry corresponds to a session. | | Entries do not persist across reboots. | | When a session is torn down, disconnected, timed out | (e.g. following the RADIUS Session-Timeout Attribute), | or otherwise terminated for any reason, the | corresponding vacmAaaSecurityToGroupEntry is deleted." There is a need to mention the conditions under which the row is created. According to RFC 4181 "If the agent itself may also create and/or delete rows, then the conditions under which this can occur MUST be clearly documented in the row object DESCRIPTION clause." The details are present in Section 7.2.1. Please add the relevant part to the DESCRIPTION clause of this object. (That includes the row update protocol.) Action: since reviewer is adamant on this point, clone section 7.2.1 into the DESCRIPTION Notes: this will be a headache if the document is ever revised. Comment from Glenn M. Keeni, August 23, 2010: It will be useful to have the term "AAA binding" mentioned here (see 10.2.4, 10.2.5 below). E.g. OLD: | DESCRIPTION "An entry in this table maps the combination of a NEW: | DESCRIPTION "An entry in this table represents a AAA binding | which maps the combination of a Action: accommodated, in conjunction with other "AAA binding" comments Comment from Glenn M. Keeni, August 23, 2010: The terms "SnmpSecurityModel" and "SecurityName" are confusing as they represent TEXTUAL CONVENTIONS which in turn represent the SYNTAX and to some extent the semantics of objects. These are not objects. I recommend using "Security Model" and "Security Name". These terms are used (not defined) in subsequent object DESCRIPTIONS. Action: Comment from Glenn M. Keeni, August 23, 2010: 10.2.4 | vacmAaaSecurityModel OBJECT-TYPE | SYNTAX SnmpSecurityModel(1..2147483647) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Model associated with the AAA binding | represented by this entry. | | This object cannot take the 'any' (0) value." | ::= { vacmAaaSecurityToGroupEntry 1 } The term "AAA binding" appears for the first time here. (And in subsequent Object DESCRIPTIONs.). This term needs to be defined. [This will be remedied if the recommendation in 10.2.3 is implemented.] Action: Accommodated as part of "AAA binding" comment bundle Comment from Glenn M. Keeni, August 23, 2010: The term "Security Model" appears for the first time here. Presumably it is the term defined in RFC3411. A REFERENCE clause would be appropriate here. E.g. OLD: | vacmAaaSecurityModel OBJECT-TYPE | SYNTAX SnmpSecurityModel(1..2147483647) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Model associated with the AAA binding | represented by this entry. | | This object cannot take the 'any' (0) value." | ::= { vacmAaaSecurityToGroupEntry 1 } NEW: | vacmAaaSecurityModel OBJECT-TYPE | SYNTAX SnmpSecurityModel(1..2147483647) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Model associated with the AAA binding | represented by this entry. | | This object cannot take the 'any' (0) value." | REFERENCE "RFC 3411; Section 3.1.1.4.1" | ::= { vacmAaaSecurityToGroupEntry 1 } Action: done Comment from Glenn M. Keeni, August 23, 2010: 10.2.5 | vacmAaaSecurityName OBJECT-TYPE | SYNTAX SnmpAdminString (SIZE(1..32)) | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "The Security Name of the principal associated with the | AAA binding represented by this entry. In RADIUS | environments, this corresponds to the User-Name | Attribute." | ::= { vacmAaaSecurityToGroupEntry 2 } The term "AAA binding" appears for the first time here. A clear description of this term should be given. [This will be remedied if the recommendation in 10.2.3 is implemented.] The term "Security Name" is used here. It is first used in Section 7.1 in the context "SNMP Security Name [RFC3411]". RFC 3411 does NOT have the term Security Name. It has a "securityName" object, though. In this memo there is no other reference to "Security Name". The DESCRIPTION says "In RADIUS environments, this corresponds to the User-Name Attribute." To me it appears that in the AAA/RADIUS context this is the "User-Name" (RFC 2865 section 5.1) and in VACM context it is "securityName" (RFC 3411 section 3.2.2). Please o fix the DESCRIPTION; o add a REFERENCE clause citing the appropriate document(s). Action: "AAA binding" handled with that comment bundle "Security Name" and "SNMP Security Name" to be replaced with securityName throughout. REFERENCE clause to be added. Comment from Glenn M. Keeni, August 23, 2010: 10.2.6 | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | ::= { vacmAaaSecurityToGroupEntry 3 } the object tmSessionID appears in this DESCRIPTION clause for the first time in this memo. Presumably this refers to the tmSessionID object in RFC 5590. Please add a REFERENCE clause citing the appropriate section in RFC 5590. E.g. OLD: | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | ::= { vacmAaaSecurityToGroupEntry 3 } NEW: | vacmAaaSessionID OBJECT-TYPE | SYNTAX Unsigned32 | MAX-ACCESS not-accessible | STATUS current | DESCRIPTION "A specific identifier of the session. | | This value MUST be unique among all currently open | sessions of all of this SNMP engine's transport models. | The value has no particular significance other than to | distinguish sessions. Implementations in which | tmSessionID is unique across all transport models MAY | use the tmSessionID value." | REFERENCE "RFC 5590: Section 4.1.2" | ::= { vacmAaaSecurityToGroupEntry 3 } Action: accepted Notes: if RFC 5590 is added to the normative references section, we will need to cite it in the text of the document somewhere. No text has been suggested. Comment from Jari Arkko, August 23, 2010: I had a question about the scope of the document. The document says: It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-Based Access Control Model (VACM). ... This memo specifies a way to simplify the administration of the access rights granted to users of network management data. I'm certainly not at all an expert on VACM but I thought that RFC 5607 already enabled dynamic updates of user-to-group mappings. As far as I can determine, *this* document only creates a MIB view of those mappings, so that they can be monitored or debugged externally. Or at least there are no new rules regarding Management- Policy-Id attribute treatment beyond RFC 5607 that would have an effect beyond a change in the new MIB. As a result, I do not understand how the document enables "dynamic updates of user-to-group mappings" or "simplify administration". What am I missing? If I have understood the scope correctly, then perhaps the two sentences that I quoted should be toned down. Action: elide first and second sentences, removing offending material OLD: This memo specifies a way to simplify the administration of the access rights granted to users of network management data. It functions to dynamically provision NEW: This memo specifies a way to dynamically provision Comment from Glenn M. Keeni, August 24, 2010: 10.3 Document issues a. Terminology: I suggest that a Terminology section be added. Several terms used in this document are open to mis-interpretation. E.g. "group": This is a generic term. But, in this document it probably, without exception, refers to a group as in the VACM document[RFC 3415; Sec 2.1]. I would recommend stating early in the document that the term "group" refers to the term defined in [RFC 3415; Sec 2.1] or, defining a "VACM-group" and replacing all occurrences of "group" by "VACM-group" "authenticated user": This is a generic term. It would be good to make it clear in the document that the term "authenticated user" refers to a user authenticated by the AAA services. Or, define a "AAA-authenticated user" and use that term consistently for the rest of the document. [The terms "AAA-authenticated" and "AAA-authorized" are used in the document but sporadically.] The terms "Security Name", "Security Model", "Group Name" should be defined/referred and used consistently in the document. Else, the terms securityName, securityModel, groupName should be used with appropriate pointers [RFC 3415]. Action: add new terminology section, reference citations to other uses Comment from Glenn M. Keeni, August 24, 2010: b. Page 4. Sec 4.1 | The use case assumption here is that roles within an organization, | which are reflected in VACM as groups and rules, change infrequently, I presume "rules" refer to the "access control policy" defined in the VACM ? If that is the case I would suggest OLD: | The use case assumption here is that roles within an organization, | which are reflected in VACM as groups and rules, change infrequently, NEW: | The use case assumption here is that roles within an organization, | which are reflected in VACM as groups and associated access control | policies", change infrequently, Action: accepted Comment from Glenn M. Keeni, August 24, 2010: c. Page 5. Sec 5.2 Suggested change- OLD: This table is indexed by the integer assigned to each security model NEW: This table is indexed by the identifier assigned to the Security Model [Note: Security Model needs to have a pointer/definition early in the document.] Action: no change from "integer" to "identifier", "term" added to Terminology section. Comment from Glenn M. Keeni, August 24, 2010: d. Page 6. Sec 7.1 | They also assume that the User-Name [RFC2865] from the RADIUS Access- | Request message (or equivalent) corresponds to an SNMP Security Name | [RFC3411]. The term "SNMP Security Name" does not appear in RFC 3411. securityName is defined in RFC 3411 section 3.2.2. Suggested change- OLD: | They also assume that the User-Name [RFC2865] from the RADIUS Access- | Request message (or equivalent) corresponds to an SNMP Security Name | [RFC3411]. NEW: | They also assume that the User-Name [RFC2865] from the RADIUS Access- | Request message (or equivalent) corresponds to an SNMP securityName | [RFC3411]. Action: accomodated with Terminology changes Comment from Glenn M. Keeni, August 24, 2010: e. Page 7. Sec 7.2 SnmpSecurityModel is not defined in RFC 3411 I suggest OLD: | o the SnmpSecurityModel [RFC3411] needed as an index into the | vacmSecurityToGroupTable; NEW: | o the SNMP Security Model, vacmSecurityModel [RFC3411], needed as an | index into the vacmSecurityToGroupTable; [Note: Security Model needs to have a pointer/definition early in the document.] Action: accommodated with Terminology changes Comment from Glenn M. Keeni, August 24, 2010: f. Page 7. Sec 7.2 the RADIUS User-Name Attribute or equivalent is also needed as an index into the vacmSecurityToGroupTable. I suggest OLD: | o the RADIUS User-Name Attribute or equivalent; NEW: | o the RADIUS User-Name Attribute or equivalent which will be used as | the index, vacmSecurityName, into the vacmSecurityToGroupTable; Action: done Comment from Glenn M. Keeni, August 24, 2010: g. Page 7. Sec 7.2 | In particular, if either the User-Name or Management-Policy-Id is | absent, invalid, or a zero-length string, no further processing of | the session establishment indication is undertaken. If the SNMP Security Model has value 'any' (0) then no further processing will be undertaken; is that correct? If that is that is the case I suggest OLD: | In particular, if either the User-Name or Management-Policy-Id is | absent, invalid, or a zero-length string, no further processing of | the session establishment indication is undertaken. NEW: | In particular, if either the User-Name or Management-Policy-Id is | absent, invalid, or a zero-length string, or, if the SNMP Security Model | has value 'any' (0), no further processing of | the session establishment indication is undertaken. Action: none Comment from Glenn M. Keeni, August 24, 2010: h. Page 7. Sec 7.2.1 Along the lines of the change in (e) OLD: | o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to | the security model in use NEW: | o vacmAaaSecurityModel = value of SNMP Security Model corresponding to | the security model in use Action: accommodated with terminology section Comment from Glenn M. Keeni, August 24, 2010: i. Page 7. Sec 7.2.1 | o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, | the securityName that will be used in invocations of the | isAccessAllowed() abstract service interface; "isAccessAllowed() abstract service interface" appears for the first time. Please provide a pointer/reference. Action: reference added Comment from Glenn M. Keeni, August 24, 2010: j. Page 7. Sec 7.2.1 The requirements for the vacmAaaSessionID are not explicit. I suggest using text from the DESCRIPTION of vacmAaaSessionID in the MIB module. OLD: | o vacmAaaSessionID = unique session identifier NEW: | o vacmAaaSessionID = session identifier. This value MUST be unique | among all currently open sessions of all of this SNMP engine's | transport models. Action: done Comment from Glenn M. Keeni, August 24, 2010: k. Page 7. Sec 7.2.1 | Otherwise, if the row already exists, update the vacmAaaGroupName | with the value supplied. It will be helpful to be explicit about "value supplied". I would suggest OLD: | Otherwise, if the row already exists, update the vacmAaaGroupName | with the value supplied. NEW: | Otherwise, if the row already exists, update the vacmAaaGroupName | with the RADIUS Management-Policy-Id Attribute or equivalent. Action: done Comment from Glenn M. Keeni, August 24, 2010: l. Page 7. Sec 7.2.2 Suggested change- OLD: | If a corresponding entry already exists in the | vacmSecurityToGroupTable, and the row's StorageType is anything other | than "volatile", or the RowStatus is anything other than "active", NEW: | If a corresponding entry already exists in the | vacmSecurityToGroupTable, and the row's vacmSecurityToGroupStorageType | is anything other than "volatile", or the vacmSecurityToGroupStatus is | anything other than "active", Action: done Comment from Glenn M. Keeni, August 24, 2010: m. Page 7. Sec 7.2.2 The second paragraph does not belong to this subsection. After making the change suggested in (l) move the paragraph (para-2) to section 7.2.3 after the 1st paragraph. Action: None Comment from Glenn M. Keeni, August 24, 2010: n. Page 7. Sec 7.2.3 Suggested change: OLD: | The operational assumption here is that if the row's StorageType is | "volatile", then this entry was probably dynamically created; an | entry created by a security administrator would not normally be given | a StorageType of "volatile". If value being provided by RADIUS (or NEW: | The operational assumption here is that if the row's | vacmSecurityToGroupStorageType is "volatile", then this entry was | probably dynamically created; an entry created by a security | administrator would not normally be given a | vacmSecurityToGroupStorageType of "volatile". If the value being | provided by RADIUS (or Action: done Comment from Glenn M. Keeni, August 24, 2010: o. Page 7. Sec 7.3.2 s/StorageType/vacmSecurityToGroupStorageType/g; Action: done Comment from Glenn M. Keeni, August 24, 2010: p. An overview describing the relevant parts of the AAA service and the VACM may be helpful to make the memo more easily understandable. The other option which I will not recommend will be to include a statement as terse as "the reader of this memo is expected to have read and understood the AAA service document RFC XXX1, the RADIUS document RFC XXX2 and the View-Based Access Control Model document RFC XXX3." Action: latter sentence added to introduction Comment from Glenn M. Keeni, August 24, 2010: q. AAA and RADIUS. I see that this has been discussed in the mailing list before. But I am afraid that the problem persists. Action: included with "AAA binding" bundle. Comment from Glenn M. Keeni, August 24, 2010: Editorial nits. a. Page 12 Sec 9 OLD: | could also occur if the SNMP security administrator had mistakenly | created these non-volatile entries in error. NEW: | could also occur if the SNMP security administrator had mistakenly | created these non-volatile entries. Action: done Comment from Glenn M. Keeni, August 24, 2010: you must add the specifications given in of 7.2.1, 7.2.2, 7.2.3, 7.3.1, 7.3.2 to the DESCRIPTION of the Table. The present DESCRIPTION does not capture the specifications. Action: clone text from 7.2.1, 7.2.2, 7.2.3, 7.3.1, and 7.3.2 to the table description The "AAA Binding" bundle: Many comments Action: add "AAA Binding" to the terminology section, using extracted text from David Harrington's post of August 24th. Randy From ietfdbh@comcast.net Tue Aug 24 22:42:09 2010 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 68D673A68DF for ; Tue, 24 Aug 2010 22:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DQWNdUfVk52i for ; Tue, 24 Aug 2010 22:42:05 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id DC7D33A6817 for ; Tue, 24 Aug 2010 22:42:04 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id yVhu1e0020SCNGk5AViebV; Wed, 25 Aug 2010 05:42:38 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta09.westchester.pa.mail.comcast.net with comcast id yVid1e0042JQnJT3VVidNb; Wed, 25 Aug 2010 05:42:38 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'Glenn M. Keeni'" , , "'Glenn Mansfield Keeni'" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><4C73D72D.8070902@cysols.com> <017201cb4408$64797660$6801a8c0@oemcomputer> Date: Wed, 25 Aug 2010 01:41:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <017201cb4408$64797660$6801a8c0@oemcomputer> Thread-Index: ActECHvwA+WajCDMTlGO/eRQsLsegQAA4sEQ Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 05:42:09 -0000 Hi, I welcome Glenn to the MIB Doctors directorate. **welcome, glenn!!** I think he may have gone overboard on some points, as is common with new reviewers. I am concerned that the wordsmithing of this document has been very difficult, and a reviewer that has not been involved in the wordsmithing negotiations to this point will not understand some of the implications involved in changing the wordings. As the editor of many of the architectural documents in the RFC34xx and ISMS series, I think that moving from securityModel to Security Model is not helpful in most cases. I don't think that moving from securityName to Security Name is helpful in most cases. We use securityModel and securityName in the RFC3411 and ISMS architectural interfaces between models (in the ASIs), so the data flow is well defined. If the document is discussing a parameter value being passed between subsystems of models, then the ASI parameter name is most appropriate (e.g., securityName). If the document is discussing a generic model of a particular subsystem, such as "each security model" that fits into the security subsystem, then "security model" (not capitalized) is most appropriate. (In early documents, we capitalized these, but moved away from that in later docs on advice from the RFC editor.) We use capitalized Security Model when referring to a specific security model, such as the Transport Security Model (TSM) or the User Security Model (USM). I am fairly sensitive to these conventions, and while I have not done a new review to check for this usage, this was not something I noticed as a problem when I did my previous thorough reviews for compliance to the modularity conventions. and as juergen points out, this might have little impact on implementers being able to interpret the text. > > > "authenticated user": > > This is a generic term. It would be good to make it clear in the > > document that the term "authenticated user" refers to a user > > authenticated by the AAA services. Or, > > define a "AAA-authenticated user" and use that term > consistently for > > the rest of the document. > > [The terms "AAA-authenticated" and "AAA-authorized" are > used in the > > document but sporadically.] > > I will add these to the tautology list "authenticated user" is only used three times, and each time I think the purpose is clear. I don't think this needs to be put into a tautology section. Trying to come up with a clear and unambiguous definition of this would likely be difficult given that we are mapping multiple security protocols together that have slightly different concepts for user and for authentication; and not running into SNMP modularity issues when defining such a term would likely be difficult. I only found "AAA-authenticated" once in the text, and its usage was very specific and appropriate. My search didn't find any use of "AAA-authorized" or "AAA authorized" in the document, which I consider very appropriate since there are two unrelated levels of AAA-authorization - the service authorization and the management-policy-id authorization - and referring to something as AAA-authorized would likely be confusing. > > > b. Page 4. Sec 4.1 > > | The use case assumption here is that roles within an > organization, > > | which are reflected in VACM as groups and rules, change > > | infrequently, > > I presume "rules" refer to the "access control policy" > defined in the > > VACM ? If that is the case I would suggest > > OLD: > > | The use case assumption here is that roles within an > organization, > > | which are reflected in VACM as groups and rules, change > > | infrequently, > > NEW: > > | The use case assumption here is that roles within an > organization, > > | which are reflected in VACM as groups and associated > access control > > | policies", change infrequently, > > Ok. I think the assignments of users to groups (or management policies) may change frequently, as the result of adds/drops/changes of an employee role; that's why centralized mappings for this relation via AAA is important. However, I think the access control policy (the MIB configuration) associated with a specific group is not likely to change frequently. Which wildcarded MIB info an administrator is allowed to access as compared to helpdesk personnel or as compared to a general user is not likely to change often. So I think the OLD text is more accurate (although I personally would have preferred roles "are reflected in VACM groups" without the "and rules"). I'm satisfied with the OLD text. > > > > c. Page 5. Sec 5.2 > > Suggested change- > > OLD: > > This table is indexed by the integer assigned to each security > > model > > NEW: > > This table is indexed by the identifier assigned to the > Security > > Model > > > > [Note: Security Model needs to have a > pointer/definition early in the > > document.] > > I's like to hear others' opinions on this one. > As a technical contributor, I think the proposed change of > "integer" to "identifier" is misleading and potentially confusing. I prefer integer. I prefer "each security model" to "the Security Model" > > > e. Page 7. Sec 7.2 > > SnmpSecurityModel is not defined in RFC 3411 > > I suggest > > OLD: > > | o the SnmpSecurityModel [RFC3411] needed as an index into the > > | vacmSecurityToGroupTable; > > NEW: > > | o the SNMP Security Model, vacmSecurityModel [RFC3411], > needed as an > > | index into the vacmSecurityToGroupTable; > > [Note: Security Model needs to have a > pointer/definition early in the > > document.] > > I think dragging in vacmSecurityModel in this way confuses > rather than enlightens. > Instead, the TC would make sense here, providing the syntax > of the formal parameter. agreed. > > > > f. Page 7. Sec 7.2 > > the RADIUS User-Name Attribute or equivalent is also > needed as an index > > into the vacmSecurityToGroupTable. > > I suggest > > OLD: > > | o the RADIUS User-Name Attribute or equivalent; > > NEW: > > | o the RADIUS User-Name Attribute or equivalent which > will be used as > > | the index, vacmSecurityName, into the > vacmSecurityToGroupTable; > > Ok, though I think this is not helpful. I agree this is not helpful. > > > > g. Page 7. Sec 7.2 > > | In particular, if either the User-Name or > Management-Policy-Id is > > | absent, invalid, or a zero-length string, no further > processing of > > | the session establishment indication is undertaken. > > If the SNMP Security Model has value 'any' (0) then no further > > processing will be undertaken; is that correct? If that > is that is > > the case I suggest > > OLD: > > | In particular, if either the User-Name or > Management-Policy-Id is > > | absent, invalid, or a zero-length string, no further > processing of > > | the session establishment indication is undertaken. > > NEW: > > | In particular, if either the User-Name or > Management-Policy-Id is > > | absent, invalid, or a zero-length string, or, if the SNMP > Security > > | Model has value 'any' (0), no further processing of the session > > | establishment indication is undertaken. > > As a technical contributor: > The distinction here is between information from sources > external to the implementation, and implementation-internal > sources. Pointing out bad stuff that might come from an > external source is probably helpful to an implementor. > Identifying things that might happen if an implementation is > *itself* broken seems like an endless and counter-productive path. > > As Editor: no action taken, pending comments from others. agreed. > > > > h. Page 7. Sec 7.2.1 > > Along the lines of the change in (e) > > OLD: > > | o vacmAaaSecurityModel = value of SnmpSecurityModel > corresponding to > > | the security model in use > > NEW: > > | o vacmAaaSecurityModel = value of SNMP Security Model > corresponding to > > | the security model in use > > Ok. unnecessary, and I am not sure it is as accurate as the original statement. > > > > l. Page 7. Sec 7.2.2 > > Suggested change- > > OLD: > > | If a corresponding entry already exists in the > > | vacmSecurityToGroupTable, and the row's StorageType is anything > > | other than "volatile", or the RowStatus is anything other than > > | "active", > > NEW: > > | If a corresponding entry already exists in the > > | vacmSecurityToGroupTable, and the row's > > | vacmSecurityToGroupStorageType is anything other than > "volatile", > > | or the vacmSecurityToGroupStatus is anything other than "active", > > Ok, though as a technical contributor I think this change > makes the document much harder to read / understand. I agree. I think it is widely understood that StoargeType and RwStatus refer to the row they are in, so it is not necessary to spell out the row's fuill object name. > > > > m. Page 7. Sec 7.2.2 > > The second paragraph does not belong to this subsection. > > After making the change suggested in (l) move the > paragraph (para-2) > > to section 7.2.3 after the 1st paragraph. > > No. The paragraph belongs here - it spells out conditions > under which an entry MUST NOT be created. agreed. this will likely go through iesg review easier if you changed the "will not" to "MUST NOT" be overridden. > > > > n. Page 7. Sec 7.2.3 > > Suggested change: > > OLD: > > | The operational assumption here is that if the row's > StorageType is > > | "volatile", then this entry was probably dynamically created; an > > | entry created by a security administrator would not normally be > > | given a StorageType of "volatile". If value being provided by > > | RADIUS (or > > NEW: > > | The operational assumption here is that if the row's > > | vacmSecurityToGroupStorageType is "volatile", then this > entry was > > | probably dynamically created; an entry created by a security > > | administrator would not normally be given a > > | vacmSecurityToGroupStorageType of "volatile". If the value being > > | provided by RADIUS (or > > Ok, though I think this is a huge step backwards in terms of > readability. agreed. I recommend not making this change. > > > > o. Page 7. Sec 7.3.2 > > s/StorageType/vacmSecurityToGroupStorageType/g; > > Ok, though I think this is a huge step backwards in terms of > readability. agreed. I recommend not making this chnage. > > > > p. An overview describing the relevant parts of the AAA > service and the > > VACM may be helpful to make the memo more easily > understandable. The > > other option which I will not recommend will be to > include a statement > > as terse as "the reader of this memo is expected to have read and > > understood the AAA service document RFC XXX1, the RADIUS > document RFC > > XXX2 and the View-Based Access Control Model document RFC XXX3." > > I'll take the latter option. The document is already far too > long as it is, considering how little it actually does. As a person who needs to review lots of documents, I understand the reviewer's desire to have a succinct intro to make things easier to understand, but implementers will need to understand the RADIUS and VACM specs, so I think it appropriate to say "the reader is expected to have read ..." > > > q. AAA and RADIUS. > > I see that this has been discussed in the mailing list > before. But I > > am afraid that the problem persists. > > > > Editorial nits. > > > > a. Page 12 Sec 9 > > OLD: > > | could also occur if the SNMP security administrator had > mistakenly > > | created these non-volatile entries in error. > > NEW: > > | could also occur if the SNMP security administrator had > mistakenly > > | created these non-volatile entries. > > Ok how about "mistakenly created these entries as non-volatile."? that is the error under consideration here, right? but it is a nit. > > Randy > > > _______________________________________________ > IETFMIBS mailing list > IETFMIBS@ietf.org > https://www.ietf.org/mailman/listinfo/ietfmibs From j.schoenwaelder@jacobs-university.de Tue Aug 24 23:17:31 2010 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 725173A6AA4; Tue, 24 Aug 2010 23:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.856 X-Spam-Level: X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 q4umM0G2naQG; Tue, 24 Aug 2010 23:17:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2CA993A67E3; Tue, 24 Aug 2010 23:17:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56A9FC000F; Wed, 25 Aug 2010 08:18:02 +0200 (CEST) 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 avyNvjFfyqrb; Wed, 25 Aug 2010 08:18:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63B2CC0007; Wed, 25 Aug 2010 08:17:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8D8331462205; Wed, 25 Aug 2010 08:17:39 +0200 (CEST) Date: Wed, 25 Aug 2010 08:17:39 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100825061739.GA70169@elstar.local> Mail-Followup-To: Randy Presuhn , "Glenn M. Keeni" , "isms@ietf.org" , Glenn Mansfield Keeni , "draft-ietf-isms-radius-vacm@tools.ietf.org" , "ietfmibs@ietf.org" References: <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com> <017201cb4408$64797660$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017201cb4408$64797660$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Glenn Mansfield Keeni , "draft-ietf-isms-radius-vacm@tools.ietf.org" , "ietfmibs@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 06:17:31 -0000 On Wed, Aug 25, 2010 at 05:48:32AM +0200, Randy Presuhn wrote: > Ok, I will add a list of tautologies in a new "Terminology" section. > However, as a technical contributor, I think the tendency to elevate > each English word or phrase to the status of "term" is most > unfortunate, and seriously detracts from the clarity of the document. As a technical contributor, I do not support this change. /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 Tue Aug 24 23:36:02 2010 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 C2AA83A68DF for ; Tue, 24 Aug 2010 23:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1qG4yvXult1l for ; Tue, 24 Aug 2010 23:36:01 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id CAF0D3A67F7 for ; Tue, 24 Aug 2010 23:36:00 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id yWca1e0020cZkys57WcatG; Wed, 25 Aug 2010 06:36:34 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta10.westchester.pa.mail.comcast.net with comcast id yWcZ1e0032JQnJT3WWcZlt; Wed, 25 Aug 2010 06:36:34 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <4C65D27F.30006@ieca.com> <20100816132904.GA75407@elstar.local><4C69411E.8050907@cysols.com><4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com><017201cb4408$64797660$6801a8c0@oemcomputer> <20100825061739.GA70169@elstar.local> Date: Wed, 25 Aug 2010 02:35:38 -0400 Message-ID: <0A3C925E2C8C4F8C8C5E65314D6C90B9@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <20100825061739.GA70169@elstar.local> Thread-Index: ActEHUo2ryUWZ30OSLeZ8Bd7p89ONwAAiaAw Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 06:36:02 -0000 as technical contributor, I have not seen solid enough reasons to add such a section at this late point in the process. If it were really needed, I think we would have added it long ago. dbh > -----Original Message----- > From: ietfmibs-bounces@ietf.org > [mailto:ietfmibs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, August 25, 2010 2:18 AM > To: Randy Presuhn > Cc: draft-ietf-isms-radius-vacm@tools.ietf.org; > ietfmibs@ietf.org; isms@ietf.org > Subject: Re: [IETFMIBS] [Isms] MIB Doctor Review: > draft-ietf-isms-radius-vacm-09.txt Part-II > > On Wed, Aug 25, 2010 at 05:48:32AM +0200, Randy Presuhn wrote: > > > Ok, I will add a list of tautologies in a new "Terminology" section. > > However, as a technical contributor, I think the tendency > to elevate > > each English word or phrase to the status of "term" is most > > unfortunate, and seriously detracts from the clarity of the > document. > > As a technical contributor, I do not support this change. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > IETFMIBS mailing list > IETFMIBS@ietf.org > https://www.ietf.org/mailman/listinfo/ietfmibs From d.b.nelson@comcast.net Wed Aug 25 03:48:23 2010 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 973083A6AD6 for ; Wed, 25 Aug 2010 03:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 sdaspAfSxl1V for ; Wed, 25 Aug 2010 03:48:22 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 9F9FA3A6981 for ; Wed, 25 Aug 2010 03:48:22 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id yanp1e0071ZXKqc54aowGt; Wed, 25 Aug 2010 10:48:56 +0000 Received: from NEWTON603 ([24.218.90.45]) by omta21.westchester.pa.mail.comcast.net with comcast id yaov1e0070yip6Y3haovkm; Wed, 25 Aug 2010 10:48:56 +0000 From: "Dave Nelson" To: "'Randy Presuhn'" , , References: <01b501cb440b$baae3860$6801a8c0@oemcomputer> Date: Wed, 25 Aug 2010 06:49:05 -0400 Message-ID: <0922D7EA0E1B41FDB6B6F3BD35B429EF@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <01b501cb440b$baae3860$6801a8c0@oemcomputer> thread-index: ActEC9BJIFpObiQbTFagsaQsw85VBAANojYQ Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, 'IESG' Subject: Re: [Isms] Proposed resolution of comments ondraft-ietf-isms-radius-vacm-09.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: Wed, 25 Aug 2010 10:48:23 -0000 > Comment from Glenn M. Keeni, August 23, 2010: > 6.2 A reference to AAA service architecture/Framework will be > in order if this document does target generic AAA services > (as the title suggests). > Action: add citations suggested by reviewer in followup message > OLD: > | Model (VACM) [RFC3415] MIB objects, based on information received > | from an Authentication, Authorization, and Accounting (AAA) service, > | such as RADIUS [RFC2865]. > NEW: > | Model (VACM) [RFC3415] MIB objects, based on information received > | from an Authentication, Authorization, and Accounting (AAA) service > | [RFC2903, RFC2904], such as RADIUS [RFC2865]. I object to this issue resolution. With all due respect to the reviewer, RFC 2903 and RFC 2904 are the work product of the IRTF AAA Architecture Research Group (AAAarch RG). As far as I know, these documents have not formed the basis of any AAA protocols or systems in current deployment. I believe that adding these references may in fact confuse the reader. From j.schoenwaelder@jacobs-university.de Wed Aug 25 04:02:16 2010 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 92C6C3A6858; Wed, 25 Aug 2010 04:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.866 X-Spam-Level: X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 vrNLnPmL02hT; Wed, 25 Aug 2010 04:02:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7080E3A6971; Wed, 25 Aug 2010 04:02:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02E08C0007; Wed, 25 Aug 2010 13:02:48 +0200 (CEST) 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 81pkAbL-qqv7; Wed, 25 Aug 2010 13:02:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45CF0C000D; Wed, 25 Aug 2010 13:02:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B0C11462AD9; Wed, 25 Aug 2010 13:02:22 +0200 (CEST) Date: Wed, 25 Aug 2010 13:02:22 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20100825110221.GA318@elstar.local> Mail-Followup-To: Dave Nelson , 'Randy Presuhn' , "isms@ietf.org" , "ietfmibs@ietf.org" , "draft-ietf-isms-radius-vacm@tools.ietf.org" , 'IESG' References: <01b501cb440b$baae3860$6801a8c0@oemcomputer> <0922D7EA0E1B41FDB6B6F3BD35B429EF@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0922D7EA0E1B41FDB6B6F3BD35B429EF@NEWTON603> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "draft-ietf-isms-radius-vacm@tools.ietf.org" , "ietfmibs@ietf.org" , "isms@ietf.org" , 'IESG' Subject: Re: [Isms] Proposed resolution of comments ondraft-ietf-isms-radius-vacm-09.txt 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: Wed, 25 Aug 2010 11:02:16 -0000 On Wed, Aug 25, 2010 at 12:49:05PM +0200, Dave Nelson wrote: > > > Comment from Glenn M. Keeni, August 23, 2010: > > 6.2 A reference to AAA service architecture/Framework will be > > in order if this document does target generic AAA services > > (as the title suggests). > > Action: add citations suggested by reviewer in followup message > > OLD: > > | Model (VACM) [RFC3415] MIB objects, based on information received > > | from an Authentication, Authorization, and Accounting (AAA) service, > > | such as RADIUS [RFC2865]. > > NEW: > > | Model (VACM) [RFC3415] MIB objects, based on information received > > | from an Authentication, Authorization, and Accounting (AAA) service > > | [RFC2903, RFC2904], such as RADIUS [RFC2865]. > > I object to this issue resolution. With all due respect to the reviewer, > RFC 2903 and RFC 2904 are the work product of the IRTF AAA Architecture > Research Group (AAAarch RG). As far as I know, these documents have not > formed the basis of any AAA protocols or systems in current deployment. I > believe that adding these references may in fact confuse the reader. I agree (speaking as technical contributor). No change needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From glenn@cysols.com Wed Aug 25 05:31:27 2010 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 DCDC13A683A; Wed, 25 Aug 2010 05:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 nxnmBsniQDSI; Wed, 25 Aug 2010 05:31:26 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id 9AD593A6874; Wed, 25 Aug 2010 05:31:25 -0700 (PDT) Received: from [127.0.0.1] (cysvpn03.priv.cysol.co.jp [192.168.0.90]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7PCVNa4011486 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 21:31:25 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C750D1A.3080204@cysols.com> Date: Wed, 25 Aug 2010 21:31:22 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: David Harrington References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><4C73D72D.8070902@cysols.com> <017201cb4408$64797660$6801a8c0@oemcomputer> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 'Glenn Mansfield Keeni' , draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 12:31:28 -0000 Hi, On 2010/08/25 14:41, David Harrington wrote: > Hi, > > > > I welcome Glenn to the MIB Doctors directorate. **welcome, glenn!!** Honored. Thanks. > > I think he may have gone overboard on some points, as is common with > new reviewers. No comments :-) > I am concerned that the wordsmithing of this document has been very > difficult, and a reviewer that has not been involved in the > wordsmithing negotiations to this point will not understand some of > the implications involved in changing the wordings. I admit I was not involved in the WG discussions. I have pored over the WG-mailing list archives, all of them related to this document to try to understand the arguments and lines of thought. > > As the editor of many of the architectural documents in the RFC34xx > and ISMS series, I think that moving from securityModel to Security > Model is not helpful in most cases. > I don't think that moving from securityName to Security Name is > helpful in most cases. > > We use securityModel and securityName in the RFC3411 and ISMS > architectural interfaces between models (in the ASIs), so the data > flow is well defined. > If the document is discussing a parameter value being passed between > subsystems of models, then the ASI parameter name is most appropriate > (e.g., securityName). > If the document is discussing a generic model of a particular > subsystem, such as "each security model" that fits into the security > subsystem, then "security model" (not capitalized) is most > appropriate. (In early documents, we capitalized these, but moved away > from that in later docs on advice from the RFC editor.) > We use capitalized Security Model when referring to a specific > security model, such as the Transport Security Model (TSM) or the User > Security Model (USM). > > I am fairly sensitive to these conventions, and while I have not done > a new review to check for this usage, this was not something I noticed > as a problem when I did my previous thorough reviews for compliance to > the modularity conventions. I am sensitive too :-) And that is the issue. The above conventions are not followed in the document. The usage is inconsistent. It has | DESCRIPTION "The Security Name of the principal associated with the | AAA binding represented by this entry. In RADIUS which contravenes what you have said above. I will be happy with the usage of securityName. But I will find SecurityName unacceptable as in | o provide an indication of the start of a session for a particular | authenticated principal, identified using a SecurityName, and This does not come under any of the allowed usage categories mentioned above. > > and as juergen points out, this might have little impact on > implementers being able to interpret the text. > >> >>> "authenticated user": >>> This is a generic term. It would be good to make it clear in > the >>> document that the term "authenticated user" refers to a user >>> authenticated by the AAA services. Or, >>> define a "AAA-authenticated user" and use that term >> consistently for >>> the rest of the document. >>> [The terms "AAA-authenticated" and "AAA-authorized" are >> used in the >>> document but sporadically.] >> >> I will add these to the tautology list > > "authenticated user" is only used three times, and each time I think > the purpose is clear. > I don't think this needs to be put into a tautology section. Trying to > come up with a clear and unambiguous definition of this would likely > be difficult given that we are mapping multiple security protocols > together that have slightly different concepts for user and for > authentication; and not running into SNMP modularity issues when > defining such a term would likely be difficult. > > I only found "AAA-authenticated" once in the text, and its usage was > very specific and appropriate. > > My search didn't find any use of "AAA-authorized" or "AAA authorized" > in the document, which I consider very appropriate since there are two > unrelated levels of AAA-authorization - the service authorization and > the management-policy-id authorization - and referring to something as > AAA-authorized would likely be confusing. There is at least one "AAA authentication and authorization" and several "AAA authorization" in the document. (Page 6 sec 7.1, Page 7 sec 7.2, Page 8 sec 7.3). > >> >>> b. Page 4. Sec 4.1 >>> | The use case assumption here is that roles within an >> organization, >>> | which are reflected in VACM as groups and rules, change >>> | infrequently, >>> I presume "rules" refer to the "access control policy" >> defined in the >>> VACM ? If that is the case I would suggest >>> OLD: >>> | The use case assumption here is that roles within an >> organization, >>> | which are reflected in VACM as groups and rules, change >>> | infrequently, >>> NEW: >>> | The use case assumption here is that roles within an >> organization, >>> | which are reflected in VACM as groups and associated >> access control >>> | policies", change infrequently, >> >> Ok. > > I think the assignments of users to groups (or management policies) > may change frequently, as the result of adds/drops/changes of an > employee role; that's why centralized mappings for this relation via > AAA is important. > > However, I think the access control policy (the MIB configuration) > associated with a specific group is not likely to change frequently. > Which wildcarded MIB info an administrator is allowed to access as > compared to helpdesk personnel or as compared to a general user is not > likely to change often. > > So I think the OLD text is more accurate (although I personally would > have preferred roles "are reflected in VACM groups" without the "and > rules"). > > I'm satisfied with the OLD text. > >> >> >>> c. Page 5. Sec 5.2 >>> Suggested change- >>> OLD: >>> This table is indexed by the integer assigned to each security > >>> model >>> NEW: >>> This table is indexed by the identifier assigned to the >> Security >>> Model >>> >>> [Note: Security Model needs to have a >> pointer/definition early in the >>> document.] >> >> I's like to hear others' opinions on this one. >> As a technical contributor, I think the proposed change of >> "integer" to "identifier" is misleading and potentially confusing. > > I prefer integer. > I prefer "each security model" to "the Security Model" > >> >>> e. Page 7. Sec 7.2 >>> SnmpSecurityModel is not defined in RFC 3411 >>> I suggest >>> OLD: >>> | o the SnmpSecurityModel [RFC3411] needed as an index into the >>> | vacmSecurityToGroupTable; >>> NEW: >>> | o the SNMP Security Model, vacmSecurityModel [RFC3411], >> needed as an >>> | index into the vacmSecurityToGroupTable; >>> [Note: Security Model needs to have a >> pointer/definition early in the >>> document.] >> >> I think dragging in vacmSecurityModel in this way confuses >> rather than enlightens. >> Instead, the TC would make sense here, providing the syntax >> of the formal parameter. > > agreed. > > >> >> >>> f. Page 7. Sec 7.2 >>> the RADIUS User-Name Attribute or equivalent is also >> needed as an index >>> into the vacmSecurityToGroupTable. >>> I suggest >>> OLD: >>> | o the RADIUS User-Name Attribute or equivalent; >>> NEW: >>> | o the RADIUS User-Name Attribute or equivalent which >> will be used as >>> | the index, vacmSecurityName, into the >> vacmSecurityToGroupTable; >> >> Ok, though I think this is not helpful. > I agree this is not helpful. > >> >> >>> g. Page 7. Sec 7.2 >>> | In particular, if either the User-Name or >> Management-Policy-Id is >>> | absent, invalid, or a zero-length string, no further >> processing of >>> | the session establishment indication is undertaken. >>> If the SNMP Security Model has value 'any' (0) then no further >>> processing will be undertaken; is that correct? If that >> is that is >>> the case I suggest >>> OLD: >>> | In particular, if either the User-Name or >> Management-Policy-Id is >>> | absent, invalid, or a zero-length string, no further >> processing of >>> | the session establishment indication is undertaken. >>> NEW: >>> | In particular, if either the User-Name or >> Management-Policy-Id is >>> | absent, invalid, or a zero-length string, or, if the SNMP >> Security >>> | Model has value 'any' (0), no further processing of the > session >>> | establishment indication is undertaken. >> >> As a technical contributor: >> The distinction here is between information from sources >> external to the implementation, and implementation-internal >> sources. Pointing out bad stuff that might come from an >> external source is probably helpful to an implementor. >> Identifying things that might happen if an implementation is >> *itself* broken seems like an endless and counter-productive path. >> >> As Editor: no action taken, pending comments from others. > > agreed. > >> >> >>> h. Page 7. Sec 7.2.1 >>> Along the lines of the change in (e) >>> OLD: >>> | o vacmAaaSecurityModel = value of SnmpSecurityModel >> corresponding to >>> | the security model in use >>> NEW: >>> | o vacmAaaSecurityModel = value of SNMP Security Model >> corresponding to >>> | the security model in use >> >> Ok. > > unnecessary, and I am not sure it is as accurate as the original > statement. > >> >> >>> l. Page 7. Sec 7.2.2 >>> Suggested change- >>> OLD: >>> | If a corresponding entry already exists in the >>> | vacmSecurityToGroupTable, and the row's StorageType is anything >>> | other than "volatile", or the RowStatus is anything other than >>> | "active", >>> NEW: >>> | If a corresponding entry already exists in the >>> | vacmSecurityToGroupTable, and the row's >>> | vacmSecurityToGroupStorageType is anything other than >> "volatile", >>> | or the vacmSecurityToGroupStatus is anything other than > "active", >> >> Ok, though as a technical contributor I think this change >> makes the document much harder to read / understand. > > I agree. I think it is widely understood that StoargeType and RwStatus > refer to the row they are in, so it is not necessary to spell out the > row's fuill object name. > >> >> >>> m. Page 7. Sec 7.2.2 >>> The second paragraph does not belong to this subsection. >>> After making the change suggested in (l) move the >> paragraph (para-2) >>> to section 7.2.3 after the 1st paragraph. >> >> No. The paragraph belongs here - it spells out conditions >> under which an entry MUST NOT be created. > > agreed. > this will likely go through iesg review easier if you changed the > "will not" to "MUST NOT" be overridden. > >> >> >>> n. Page 7. Sec 7.2.3 >>> Suggested change: >>> OLD: >>> | The operational assumption here is that if the row's >> StorageType is >>> | "volatile", then this entry was probably dynamically created; an > >>> | entry created by a security administrator would not normally be >>> | given a StorageType of "volatile". If value being provided by >>> | RADIUS (or >>> NEW: >>> | The operational assumption here is that if the row's >>> | vacmSecurityToGroupStorageType is "volatile", then this >> entry was >>> | probably dynamically created; an entry created by a security >>> | administrator would not normally be given a >>> | vacmSecurityToGroupStorageType of "volatile". If the value being > >>> | provided by RADIUS (or >> >> Ok, though I think this is a huge step backwards in terms of >> readability. > > agreed. I recommend not making this change. > >> >> >>> o. Page 7. Sec 7.3.2 >>> s/StorageType/vacmSecurityToGroupStorageType/g; >> >> Ok, though I think this is a huge step backwards in terms of >> readability. > > agreed. I recommend not making this chnage. > >> >> >>> p. An overview describing the relevant parts of the AAA >> service and the >>> VACM may be helpful to make the memo more easily >> understandable. The >>> other option which I will not recommend will be to >> include a statement >>> as terse as "the reader of this memo is expected to have read > and >>> understood the AAA service document RFC XXX1, the RADIUS >> document RFC >>> XXX2 and the View-Based Access Control Model document RFC > XXX3." >> >> I'll take the latter option. The document is already far too >> long as it is, considering how little it actually does. > > As a person who needs to review lots of documents, I understand the > reviewer's desire to have a succinct intro to make things easier to > understand, but implementers will need to understand the RADIUS and > VACM specs, so I think it appropriate to say "the reader is expected > to have read ..." > >> >>> q. AAA and RADIUS. >>> I see that this has been discussed in the mailing list >> before. But I >>> am afraid that the problem persists. >>> >>> Editorial nits. >>> >>> a. Page 12 Sec 9 >>> OLD: >>> | could also occur if the SNMP security administrator had >> mistakenly >>> | created these non-volatile entries in error. >>> NEW: >>> | could also occur if the SNMP security administrator had >> mistakenly >>> | created these non-volatile entries. >> >> Ok > > how about "mistakenly created these entries as non-volatile."? > that is the error under consideration here, right? > but it is a nit. > >> >> Randy >> >> >> _______________________________________________ >> IETFMIBS mailing list >> IETFMIBS@ietf.org >> https://www.ietf.org/mailman/listinfo/ietfmibs > Glenn From glenn@cysols.com Wed Aug 25 06:05:22 2010 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 EE2EB3A6876; Wed, 25 Aug 2010 06:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_83=0.6] 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 EPEBi3iyaBFD; Wed, 25 Aug 2010 06:05:21 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id 177993A69A6; Wed, 25 Aug 2010 06:05:16 -0700 (PDT) Received: from [127.0.0.1] (cysvpn03.priv.cysol.co.jp [192.168.0.90]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7PD5ElO014691 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 22:05:16 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C75150A.6050909@cysols.com> Date: Wed, 25 Aug 2010 22:05:14 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Randy Presuhn References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com> <017201cb4408$64797660$6801a8c0@oemcomputer> In-Reply-To: <017201cb4408$64797660$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 13:05:23 -0000 Hi, > >> m. Page 7. Sec 7.2.2 >> The second paragraph does not belong to this subsection. >> After making the change suggested in (l) move the paragraph (para-2) >> to section 7.2.3 after the 1st paragraph. > > No. The paragraph belongs here - it spells out conditions under which > an entry MUST NOT be created. > That is interesting. If this paragraph | If a corresponding entry already exists in the | vacmSecurityToGroupTable, and the row's StorageType is anything other | than "volatile", or the RowStatus is anything other than "active", | then a role (group) mapping for this user (principal) has already | been put in place on this system, and will not be overridden. spells out conditions under which an entry MUST NOT be created. Then you are implying that if the above condition is not met i.e. If a corresponding entry already exists in the vacmSecurityToGroupTable, and the row's StorageType is "volatile", or the RowStatus is "active", an entry will be/may be/must be created? Am I missing something? Glenn On 2010/08/25 12:48, Randy Presuhn wrote: > Hi - > >> From: "Glenn M. Keeni" >> To:; "Glenn Mansfield Keeni" >> Cc: >> Sent: Tuesday, August 24, 2010 7:29 AM >> Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II >> >> Hi, >> >> Thanks for waiting. This is the Part-II of the MIB Doctor Review >> of draft-ietf-isms-radius-vacm-09.txt. It focuses on the Document >> issues. >> >> Glenn >> >> +--------------------------------------------------------------------+ >> >> 10.3 Document issues >> >> a. Terminology: >> I suggest that a Terminology section be added. Several terms used >> in this document are open to mis-interpretation. E.g. >> "group": >> This is a generic term. But, in this document it probably, without >> exception, refers to a group as in the VACM document[RFC 3415; Sec 2.1]. >> I would recommend >> stating early in the document that the term "group" refers to the >> term defined in [RFC 3415; Sec 2.1] or, >> defining a "VACM-group" and replacing all occurrences of "group" by >> "VACM-group" > > Ok, I will add a list of tautologies in a new "Terminology" section. > However, as a technical contributor, I think the tendency to elevate > each English word or phrase to the status of "term" is most > unfortunate, and seriously detracts from the clarity of the document. > >> "authenticated user": >> This is a generic term. It would be good to make it clear in the >> document that the term "authenticated user" refers to a user >> authenticated by the AAA services. Or, >> define a "AAA-authenticated user" and use that term consistently for >> the rest of the document. >> [The terms "AAA-authenticated" and "AAA-authorized" are used in the >> document but sporadically.] > > I will add these to the tautology list > > >> The terms "Security Name", "Security Model", "Group Name" should be >> defined/referred and used consistently in the document. Else, >> the terms securityName, securityModel, groupName should be used >> with appropriate pointers [RFC 3415]. > > Ok. > > >> b. Page 4. Sec 4.1 >> | The use case assumption here is that roles within an organization, >> | which are reflected in VACM as groups and rules, change infrequently, >> I presume "rules" refer to the "access control policy" defined in the >> VACM ? If that is the case I would suggest >> OLD: >> | The use case assumption here is that roles within an organization, >> | which are reflected in VACM as groups and rules, change infrequently, >> NEW: >> | The use case assumption here is that roles within an organization, >> | which are reflected in VACM as groups and associated access control >> | policies", change infrequently, > > Ok. > > >> c. Page 5. Sec 5.2 >> Suggested change- >> OLD: >> This table is indexed by the integer assigned to each security model >> NEW: >> This table is indexed by the identifier assigned to the Security Model >> >> [Note: Security Model needs to have a pointer/definition early in the >> document.] > > I's like to hear others' opinions on this one. > As a technical contributor, I think the proposed change of "integer" to > "identifier" is misleading and potentially confusing. > > I will add "security model" to the list of tautologies. > > >> d. Page 6. Sec 7.1 >> | They also assume that the User-Name [RFC2865] from the RADIUS Access- >> | Request message (or equivalent) corresponds to an SNMP Security Name >> | [RFC3411]. >> The term "SNMP Security Name" does not appear in RFC 3411. >> securityName is defined in RFC 3411 section 3.2.2. >> Suggested change- >> OLD: >> | They also assume that the User-Name [RFC2865] from the RADIUS Access- >> | Request message (or equivalent) corresponds to an SNMP Security Name >> | [RFC3411]. >> NEW: >> | They also assume that the User-Name [RFC2865] from the RADIUS Access- >> | Request message (or equivalent) corresponds to an SNMP securityName >> | [RFC3411]. > > I'll accomodate this by adding "security name" to the list of tautologies. > > >> e. Page 7. Sec 7.2 >> SnmpSecurityModel is not defined in RFC 3411 >> I suggest >> OLD: >> | o the SnmpSecurityModel [RFC3411] needed as an index into the >> | vacmSecurityToGroupTable; >> NEW: >> | o the SNMP Security Model, vacmSecurityModel [RFC3411], needed as an >> | index into the vacmSecurityToGroupTable; >> [Note: Security Model needs to have a pointer/definition early in the >> document.] > > I think dragging in vacmSecurityModel in this way confuses rather than enlightens. > Instead, the TC would make sense here, providing the syntax of the formal parameter. > > >> f. Page 7. Sec 7.2 >> the RADIUS User-Name Attribute or equivalent is also needed as an index >> into the vacmSecurityToGroupTable. >> I suggest >> OLD: >> | o the RADIUS User-Name Attribute or equivalent; >> NEW: >> | o the RADIUS User-Name Attribute or equivalent which will be used as >> | the index, vacmSecurityName, into the vacmSecurityToGroupTable; > > Ok, though I think this is not helpful. > > >> g. Page 7. Sec 7.2 >> | In particular, if either the User-Name or Management-Policy-Id is >> | absent, invalid, or a zero-length string, no further processing of >> | the session establishment indication is undertaken. >> If the SNMP Security Model has value 'any' (0) then no further >> processing will be undertaken; is that correct? If that is that is >> the case I suggest >> OLD: >> | In particular, if either the User-Name or Management-Policy-Id is >> | absent, invalid, or a zero-length string, no further processing of >> | the session establishment indication is undertaken. >> NEW: >> | In particular, if either the User-Name or Management-Policy-Id is >> | absent, invalid, or a zero-length string, or, if the SNMP Security Model >> | has value 'any' (0), no further processing of >> | the session establishment indication is undertaken. > > As a technical contributor: > The distinction here is between information from sources external > to the implementation, and implementation-internal sources. Pointing > out bad stuff that might come from an external source is probably helpful > to an implementor. Identifying things that might happen if an implementation > is *itself* broken seems like an endless and counter-productive path. > > As Editor: no action taken, pending comments from others. > > >> h. Page 7. Sec 7.2.1 >> Along the lines of the change in (e) >> OLD: >> | o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to >> | the security model in use >> NEW: >> | o vacmAaaSecurityModel = value of SNMP Security Model corresponding to >> | the security model in use > > Ok. > > >> i. Page 7. Sec 7.2.1 >> | o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, >> | the securityName that will be used in invocations of the >> | isAccessAllowed() abstract service interface; >> "isAccessAllowed() abstract service interface" appears for the first >> time. Please provide a pointer/reference. > > Ok. > > >> j. Page 7. Sec 7.2.1 >> The requirements for the vacmAaaSessionID are not explicit. I suggest >> using text from the DESCRIPTION of vacmAaaSessionID in the MIB module. >> OLD: >> | o vacmAaaSessionID = unique session identifier >> NEW: >> | o vacmAaaSessionID = session identifier. This value MUST be unique >> | among all currently open sessions of all of this SNMP engine's >> | transport models. > > Ok. > > >> k. Page 7. Sec 7.2.1 >> | Otherwise, if the row already exists, update the vacmAaaGroupName >> | with the value supplied. >> It will be helpful to be explicit about "value supplied". I would >> suggest >> OLD: >> | Otherwise, if the row already exists, update the vacmAaaGroupName >> | with the value supplied. >> NEW: >> | Otherwise, if the row already exists, update the vacmAaaGroupName >> | with the RADIUS Management-Policy-Id Attribute or equivalent. > > Ok. > > >> l. Page 7. Sec 7.2.2 >> Suggested change- >> OLD: >> | If a corresponding entry already exists in the >> | vacmSecurityToGroupTable, and the row's StorageType is anything other >> | than "volatile", or the RowStatus is anything other than "active", >> NEW: >> | If a corresponding entry already exists in the >> | vacmSecurityToGroupTable, and the row's vacmSecurityToGroupStorageType >> | is anything other than "volatile", or the vacmSecurityToGroupStatus is >> | anything other than "active", > > Ok, though as a technical contributor I think this change makes the document much > harder to read / understand. > > >> m. Page 7. Sec 7.2.2 >> The second paragraph does not belong to this subsection. >> After making the change suggested in (l) move the paragraph (para-2) >> to section 7.2.3 after the 1st paragraph. > > No. The paragraph belongs here - it spells out conditions under which > an entry MUST NOT be created. > > >> n. Page 7. Sec 7.2.3 >> Suggested change: >> OLD: >> | The operational assumption here is that if the row's StorageType is >> | "volatile", then this entry was probably dynamically created; an >> | entry created by a security administrator would not normally be given >> | a StorageType of "volatile". If value being provided by RADIUS (or >> NEW: >> | The operational assumption here is that if the row's >> | vacmSecurityToGroupStorageType is "volatile", then this entry was >> | probably dynamically created; an entry created by a security >> | administrator would not normally be given a >> | vacmSecurityToGroupStorageType of "volatile". If the value being >> | provided by RADIUS (or > > Ok, though I think this is a huge step backwards in terms of readability. > > >> o. Page 7. Sec 7.3.2 >> s/StorageType/vacmSecurityToGroupStorageType/g; > > Ok, though I think this is a huge step backwards in terms of readability. > > >> p. An overview describing the relevant parts of the AAA service and the >> VACM may be helpful to make the memo more easily understandable. The >> other option which I will not recommend will be to include a statement >> as terse as "the reader of this memo is expected to have read and >> understood the AAA service document RFC XXX1, the RADIUS document RFC >> XXX2 and the View-Based Access Control Model document RFC XXX3." > > I'll take the latter option. The document is already far too long as it is, > considering how little it actually does. > >> q. AAA and RADIUS. >> I see that this has been discussed in the mailing list before. But I >> am afraid that the problem persists. >> >> Editorial nits. >> >> a. Page 12 Sec 9 >> OLD: >> | could also occur if the SNMP security administrator had mistakenly >> | created these non-volatile entries in error. >> NEW: >> | could also occur if the SNMP security administrator had mistakenly >> | created these non-volatile entries. > > Ok > > Randy > > From ietfc@btconnect.com Wed Aug 25 10:25:08 2010 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 559433A6AFC; Wed, 25 Aug 2010 10:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 F1INRsOxYSmT; Wed, 25 Aug 2010 10:25:06 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id C9A3C3A6A43; Wed, 25 Aug 2010 10:25:05 -0700 (PDT) Received: from pc6 (host81-153-11-67.range81-153.btcentralplus.com [81.153.11.67]) by c2bthomr13.btconnect.com with SMTP id FVK12834; Wed, 25 Aug 2010 18:24:47 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C7551DF.01D8, actions=tag Message-ID: <002401cb4471$5f8c1400$4001a8c0@gateway.2wire.net> From: "t.petch" To: "David Harrington" , "'Randy Presuhn'" , "'Glenn M. Keeni'" , , "'Glenn Mansfield Keeni'" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><4C73D72D.8070902@cysols.com><017201cb4408$64797660$6801a8c0@oemcomputer> Date: Wed, 25 Aug 2010 18:15:37 +0200 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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B020A.4C7551F8.00FA,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB DoctorReview:draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 17:25:08 -0000 Just picking up on two technical points .... Tom Petch ----- Original Message ----- From: "David Harrington" To: "'Randy Presuhn'" ; "'Glenn M. Keeni'" ; ; "'Glenn Mansfield Keeni'" Cc: ; Sent: Wednesday, August 25, 2010 7:41 AM > > > > I welcome Glenn to the MIB Doctors directorate. **welcome, glenn!!** Yes, good to see another volunteer > I think he may have gone overboard on some points, as is common with > new reviewers. > I am concerned that the wordsmithing of this document has been very > difficult, and a reviewer that has not been involved in the > wordsmithing negotiations to this point will not understand some of > the implications involved in changing the wordings. > > As the editor of many of the architectural documents in the RFC34xx > and ISMS series, I think that moving from securityModel to Security > Model is not helpful in most cases. > I don't think that moving from securityName to Security Name is > helpful in most cases. > > We use securityModel and securityName in the RFC3411 and ISMS > architectural interfaces between models (in the ASIs), so the data > flow is well defined. > If the document is discussing a parameter value being passed between > subsystems of models, then the ASI parameter name is most appropriate > (e.g., securityName). > If the document is discussing a generic model of a particular > subsystem, such as "each security model" that fits into the security > subsystem, then "security model" (not capitalized) is most > appropriate. (In early documents, we capitalized these, but moved away > from that in later docs on advice from the RFC editor.) > We use capitalized Security Model when referring to a specific > security model, such as the Transport Security Model (TSM) or the User > Security Model (USM). > > I am fairly sensitive to these conventions, and while I have not done Yup, me too. But this I-D does have securityName, SecurityName and Security Name which I do not think that the usage justifies. Rather securityName where the RFC3415 concept is intended, and security name anywhere else. I cannot recall a TC for SecurityName so would say that that is an error Tom Petch > a new review to check for this usage, this was not something I noticed > as a problem when I did my previous thorough reviews for compliance to > the modularity conventions. > > and as juergen points out, this might have little impact on > implementers being able to interpret the text. > > > > > > "authenticated user": > > > This is a generic term. It would be good to make it clear in > the > > > document that the term "authenticated user" refers to a user > > > authenticated by the AAA services. Or, > > > define a "AAA-authenticated user" and use that term > > consistently for > > > the rest of the document. > > > [The terms "AAA-authenticated" and "AAA-authorized" are > > used in the > > > document but sporadically.] > > > > I will add these to the tautology list > > "authenticated user" is only used three times, and each time I think > the purpose is clear. > I don't think this needs to be put into a tautology section. Trying to > come up with a clear and unambiguous definition of this would likely > be difficult given that we are mapping multiple security protocols > together that have slightly different concepts for user and for > authentication; and not running into SNMP modularity issues when > defining such a term would likely be difficult. > > I only found "AAA-authenticated" once in the text, and its usage was > very specific and appropriate. > > My search didn't find any use of "AAA-authorized" or "AAA authorized" > in the document, which I consider very appropriate since there are two > unrelated levels of AAA-authorization - the service authorization and > the management-policy-id authorization - and referring to something as > AAA-authorized would likely be confusing. > > > > > > b. Page 4. Sec 4.1 > > > | The use case assumption here is that roles within an > > organization, > > > | which are reflected in VACM as groups and rules, change > > > | infrequently, > > > I presume "rules" refer to the "access control policy" > > defined in the > > > VACM ? If that is the case I would suggest > > > OLD: > > > | The use case assumption here is that roles within an > > organization, > > > | which are reflected in VACM as groups and rules, change > > > | infrequently, > > > NEW: > > > | The use case assumption here is that roles within an > > organization, > > > | which are reflected in VACM as groups and associated > > access control > > > | policies", change infrequently, > > > > Ok. > > I think the assignments of users to groups (or management policies) > may change frequently, as the result of adds/drops/changes of an > employee role; that's why centralized mappings for this relation via > AAA is important. > > However, I think the access control policy (the MIB configuration) > associated with a specific group is not likely to change frequently. > Which wildcarded MIB info an administrator is allowed to access as > compared to helpdesk personnel or as compared to a general user is not > likely to change often. > > So I think the OLD text is more accurate (although I personally would > have preferred roles "are reflected in VACM groups" without the "and > rules"). > > I'm satisfied with the OLD text. > > > > > > c. Page 5. Sec 5.2 > > > Suggested change- > > > OLD: > > > This table is indexed by the integer assigned to each security > > > > model > > > NEW: > > > This table is indexed by the identifier assigned to the > > Security > > > Model > > > > > > [Note: Security Model needs to have a > > pointer/definition early in the > > > document.] > > > > I's like to hear others' opinions on this one. > > As a technical contributor, I think the proposed change of > > "integer" to "identifier" is misleading and potentially confusing. > > I prefer integer. > I prefer "each security model" to "the Security Model" Since SnmpSecurityModel has a SYNTAX of INTEGER, I would see integer as right and anything else as less than right. Tom Petch > > > e. Page 7. Sec 7.2 > > > SnmpSecurityModel is not defined in RFC 3411 > > > I suggest > > > OLD: > > > | o the SnmpSecurityModel [RFC3411] needed as an index into the > > > | vacmSecurityToGroupTable; > > > NEW: > > > | o the SNMP Security Model, vacmSecurityModel [RFC3411], > > needed as an > > > | index into the vacmSecurityToGroupTable; > > > [Note: Security Model needs to have a > > pointer/definition early in the > > > document.] > > > > I think dragging in vacmSecurityModel in this way confuses > > rather than enlightens. > > Instead, the TC would make sense here, providing the syntax > > of the formal parameter. > > agreed. > > > > > > > > > f. Page 7. Sec 7.2 > > > the RADIUS User-Name Attribute or equivalent is also > > needed as an index > > > into the vacmSecurityToGroupTable. > > > I suggest > > > OLD: > > > | o the RADIUS User-Name Attribute or equivalent; > > > NEW: > > > | o the RADIUS User-Name Attribute or equivalent which > > will be used as > > > | the index, vacmSecurityName, into the > > vacmSecurityToGroupTable; > > > > Ok, though I think this is not helpful. > I agree this is not helpful. > > > > > > > > g. Page 7. Sec 7.2 > > > | In particular, if either the User-Name or > > Management-Policy-Id is > > > | absent, invalid, or a zero-length string, no further > > processing of > > > | the session establishment indication is undertaken. > > > If the SNMP Security Model has value 'any' (0) then no further > > > processing will be undertaken; is that correct? If that > > is that is > > > the case I suggest > > > OLD: > > > | In particular, if either the User-Name or > > Management-Policy-Id is > > > | absent, invalid, or a zero-length string, no further > > processing of > > > | the session establishment indication is undertaken. > > > NEW: > > > | In particular, if either the User-Name or > > Management-Policy-Id is > > > | absent, invalid, or a zero-length string, or, if the SNMP > > Security > > > | Model has value 'any' (0), no further processing of the > session > > > | establishment indication is undertaken. > > > > As a technical contributor: > > The distinction here is between information from sources > > external to the implementation, and implementation-internal > > sources. Pointing out bad stuff that might come from an > > external source is probably helpful to an implementor. > > Identifying things that might happen if an implementation is > > *itself* broken seems like an endless and counter-productive path. > > > > As Editor: no action taken, pending comments from others. > > agreed. > > > > > > > > h. Page 7. Sec 7.2.1 > > > Along the lines of the change in (e) > > > OLD: > > > | o vacmAaaSecurityModel = value of SnmpSecurityModel > > corresponding to > > > | the security model in use > > > NEW: > > > | o vacmAaaSecurityModel = value of SNMP Security Model > > corresponding to > > > | the security model in use > > > > Ok. > > unnecessary, and I am not sure it is as accurate as the original > statement. > > > > > > > > l. Page 7. Sec 7.2.2 > > > Suggested change- > > > OLD: > > > | If a corresponding entry already exists in the > > > | vacmSecurityToGroupTable, and the row's StorageType is anything > > > | other than "volatile", or the RowStatus is anything other than > > > | "active", > > > NEW: > > > | If a corresponding entry already exists in the > > > | vacmSecurityToGroupTable, and the row's > > > | vacmSecurityToGroupStorageType is anything other than > > "volatile", > > > | or the vacmSecurityToGroupStatus is anything other than > "active", > > > > Ok, though as a technical contributor I think this change > > makes the document much harder to read / understand. > > I agree. I think it is widely understood that StoargeType and RwStatus > refer to the row they are in, so it is not necessary to spell out the > row's fuill object name. > > > > > > > > m. Page 7. Sec 7.2.2 > > > The second paragraph does not belong to this subsection. > > > After making the change suggested in (l) move the > > paragraph (para-2) > > > to section 7.2.3 after the 1st paragraph. > > > > No. The paragraph belongs here - it spells out conditions > > under which an entry MUST NOT be created. > > agreed. > this will likely go through iesg review easier if you changed the > "will not" to "MUST NOT" be overridden. > > > > > > > > n. Page 7. Sec 7.2.3 > > > Suggested change: > > > OLD: > > > | The operational assumption here is that if the row's > > StorageType is > > > | "volatile", then this entry was probably dynamically created; an > > > > | entry created by a security administrator would not normally be > > > | given a StorageType of "volatile". If value being provided by > > > | RADIUS (or > > > NEW: > > > | The operational assumption here is that if the row's > > > | vacmSecurityToGroupStorageType is "volatile", then this > > entry was > > > | probably dynamically created; an entry created by a security > > > | administrator would not normally be given a > > > | vacmSecurityToGroupStorageType of "volatile". If the value being > > > > | provided by RADIUS (or > > > > Ok, though I think this is a huge step backwards in terms of > > readability. > > agreed. I recommend not making this change. > > > > > > > > o. Page 7. Sec 7.3.2 > > > s/StorageType/vacmSecurityToGroupStorageType/g; > > > > Ok, though I think this is a huge step backwards in terms of > > readability. > > agreed. I recommend not making this chnage. > > > > > > > > p. An overview describing the relevant parts of the AAA > > service and the > > > VACM may be helpful to make the memo more easily > > understandable. The > > > other option which I will not recommend will be to > > include a statement > > > as terse as "the reader of this memo is expected to have read > and > > > understood the AAA service document RFC XXX1, the RADIUS > > document RFC > > > XXX2 and the View-Based Access Control Model document RFC > XXX3." > > > > I'll take the latter option. The document is already far too > > long as it is, considering how little it actually does. > > As a person who needs to review lots of documents, I understand the > reviewer's desire to have a succinct intro to make things easier to > understand, but implementers will need to understand the RADIUS and > VACM specs, so I think it appropriate to say "the reader is expected > to have read ..." > > > > > > q. AAA and RADIUS. > > > I see that this has been discussed in the mailing list > > before. But I > > > am afraid that the problem persists. > > > > > > Editorial nits. > > > > > > a. Page 12 Sec 9 > > > OLD: > > > | could also occur if the SNMP security administrator had > > mistakenly > > > | created these non-volatile entries in error. > > > NEW: > > > | could also occur if the SNMP security administrator had > > mistakenly > > > | created these non-volatile entries. > > > > Ok > > how about "mistakenly created these entries as non-volatile."? > that is the error under consideration here, right? > but it is a nit. > > > > > Randy > > > > > > _______________________________________________ > > IETFMIBS mailing list > > IETFMIBS@ietf.org > > https://www.ietf.org/mailman/listinfo/ietfmibs > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfc@btconnect.com Wed Aug 25 10:25:10 2010 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 963DD3A6B54; Wed, 25 Aug 2010 10:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 zJ0x0xm0HB-o; Wed, 25 Aug 2010 10:25:09 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 09A3C3A6B4B; Wed, 25 Aug 2010 10:25:08 -0700 (PDT) Received: from pc6 (host81-153-11-67.range81-153.btcentralplus.com [81.153.11.67]) by c2bthomr13.btconnect.com with SMTP id FVK12927; Wed, 25 Aug 2010 18:25:02 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C7551DF.01D8, actions=tag Message-ID: <002501cb4471$6019fc20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "David Harrington" , "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local><4C69411E.8050907@cysols.com><4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><4C73D72D.8070902@cysols.com><017201cb4408$64797660$6801a8c0@oemcomputer><20100825061739.GA70169@elstar.local> <0A3C925E2C8C4F8C8C5E65314D6C90B9@23FX1C1> Date: Wed, 25 Aug 2010 18:19:18 +0200 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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0206.4C7551F2.0327,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 17:25:10 -0000 ----- Original Message ----- From: "David Harrington" To: "'Juergen Schoenwaelder'" ; "'Randy Presuhn'" Cc: ; ; Sent: Wednesday, August 25, 2010 8:35 AM > as technical contributor, I have not seen solid enough reasons to add > such a section at this late point in the process. If it were really > needed, I think we would have added it long ago. > Broadly I agree, but would probably have made an exception for securityModel and securityName briefly referring to the relevant RFC - the definitions can be hard to find amongst the RFC341x series in a Definitions section; I would not include anything else. Tom Petch > dbh > > > -----Original Message----- > > From: ietfmibs-bounces@ietf.org > > [mailto:ietfmibs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > > Sent: Wednesday, August 25, 2010 2:18 AM > > To: Randy Presuhn > > Cc: draft-ietf-isms-radius-vacm@tools.ietf.org; > > ietfmibs@ietf.org; isms@ietf.org > > Subject: Re: [IETFMIBS] [Isms] MIB Doctor Review: > > draft-ietf-isms-radius-vacm-09.txt Part-II > > > > On Wed, Aug 25, 2010 at 05:48:32AM +0200, Randy Presuhn wrote: > > > > > Ok, I will add a list of tautologies in a new "Terminology" > section. > > > However, as a technical contributor, I think the tendency > > to elevate > > > each English word or phrase to the status of "term" is most > > > unfortunate, and seriously detracts from the clarity of the > > document. > > > > As a technical contributor, I do not support this change. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > IETFMIBS mailing list > > IETFMIBS@ietf.org > > https://www.ietf.org/mailman/listinfo/ietfmibs > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfc@btconnect.com Wed Aug 25 10:35:31 2010 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 8B3143A6892; Wed, 25 Aug 2010 10:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PyaILk6yTnBr; Wed, 25 Aug 2010 10:35:28 -0700 (PDT) Received: from c2bthomr10.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id 681F83A6826; Wed, 25 Aug 2010 10:35:27 -0700 (PDT) Received: from pc6 (host81-153-11-67.range81-153.btcentralplus.com [81.153.11.67]) by c2bthomr10.btconnect.com with SMTP id GAU12039; Wed, 25 Aug 2010 18:35:57 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C75547C.0313, actions=tag Message-ID: <009e01cb4472$e5d9ae40$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><4C73D72D.8070902@cysols.com><017201cb4408$64797660$6801a8c0@oemcomputer> <002401cb4471$5f8c1400$4001a8c0@gateway.2wire.net> Date: Wed, 25 Aug 2010 18:30:53 +0200 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-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0207.4C75547F.00A8,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: ietfmibs@ietf.org Subject: [Isms] Bounce was Re: [IETFMIBS] MIBDoctorReview:draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 17:35:31 -0000 Uh huh, I just got bounce messages for glenn@cysols.com and randy_presuhn@mindspring.com Hopefully they will see messages via the list, or via someone's response to mine:-) Tom Petch ----- Original Message ----- From: "t.petch" To: "David Harrington" ; "'Randy Presuhn'" ; "'Glenn M. Keeni'" ; ; "'Glenn Mansfield Keeni'" Cc: ; Sent: Wednesday, August 25, 2010 6:15 PM Subject: Re: [Isms] [IETFMIBS] MIBDoctorReview:draft-ietf-isms-radius-vacm-09.txt Part-II > Just picking up on two technical points .... > > Tom Petch > > ----- Original Message ----- > From: "David Harrington" > To: "'Randy Presuhn'" ; "'Glenn M. Keeni'" > ; ; "'Glenn Mansfield Keeni'" > > Cc: ; > Sent: Wednesday, August 25, 2010 7:41 AM > > > > > > > > > I welcome Glenn to the MIB Doctors directorate. **welcome, glenn!!** > > Yes, good to see another volunteer > > > I think he may have gone overboard on some points, as is common with > > new reviewers. > > I am concerned that the wordsmithing of this document has been very > > difficult, and a reviewer that has not been involved in the > > wordsmithing negotiations to this point will not understand some of > > the implications involved in changing the wordings. > > > > As the editor of many of the architectural documents in the RFC34xx > > and ISMS series, I think that moving from securityModel to Security > > Model is not helpful in most cases. > > I don't think that moving from securityName to Security Name is > > helpful in most cases. > > > > We use securityModel and securityName in the RFC3411 and ISMS > > architectural interfaces between models (in the ASIs), so the data > > flow is well defined. > > If the document is discussing a parameter value being passed between > > subsystems of models, then the ASI parameter name is most appropriate > > (e.g., securityName). > > If the document is discussing a generic model of a particular > > subsystem, such as "each security model" that fits into the security > > subsystem, then "security model" (not capitalized) is most > > appropriate. (In early documents, we capitalized these, but moved away > > from that in later docs on advice from the RFC editor.) > > We use capitalized Security Model when referring to a specific > > security model, such as the Transport Security Model (TSM) or the User > > Security Model (USM). > > > > I am fairly sensitive to these conventions, and while I have not done > > Yup, me too. But this I-D does have securityName, SecurityName and Security > Name which I do not think that the usage justifies. Rather securityName where > the RFC3415 concept is intended, and security name anywhere else. I cannot > recall a TC for SecurityName so would say that that is an error > > Tom Petch > > > > a new review to check for this usage, this was not something I noticed > > as a problem when I did my previous thorough reviews for compliance to > > the modularity conventions. > > > > and as juergen points out, this might have little impact on > > implementers being able to interpret the text. > > > > > > > > > "authenticated user": > > > > This is a generic term. It would be good to make it clear in > > the > > > > document that the term "authenticated user" refers to a user > > > > authenticated by the AAA services. Or, > > > > define a "AAA-authenticated user" and use that term > > > consistently for > > > > the rest of the document. > > > > [The terms "AAA-authenticated" and "AAA-authorized" are > > > used in the > > > > document but sporadically.] > > > > > > I will add these to the tautology list > > > > "authenticated user" is only used three times, and each time I think > > the purpose is clear. > > I don't think this needs to be put into a tautology section. Trying to > > come up with a clear and unambiguous definition of this would likely > > be difficult given that we are mapping multiple security protocols > > together that have slightly different concepts for user and for > > authentication; and not running into SNMP modularity issues when > > defining such a term would likely be difficult. > > > > I only found "AAA-authenticated" once in the text, and its usage was > > very specific and appropriate. > > > > My search didn't find any use of "AAA-authorized" or "AAA authorized" > > in the document, which I consider very appropriate since there are two > > unrelated levels of AAA-authorization - the service authorization and > > the management-policy-id authorization - and referring to something as > > AAA-authorized would likely be confusing. > > > > > > > > > b. Page 4. Sec 4.1 > > > > | The use case assumption here is that roles within an > > > organization, > > > > | which are reflected in VACM as groups and rules, change > > > > | infrequently, > > > > I presume "rules" refer to the "access control policy" > > > defined in the > > > > VACM ? If that is the case I would suggest > > > > OLD: > > > > | The use case assumption here is that roles within an > > > organization, > > > > | which are reflected in VACM as groups and rules, change > > > > | infrequently, > > > > NEW: > > > > | The use case assumption here is that roles within an > > > organization, > > > > | which are reflected in VACM as groups and associated > > > access control > > > > | policies", change infrequently, > > > > > > Ok. > > > > I think the assignments of users to groups (or management policies) > > may change frequently, as the result of adds/drops/changes of an > > employee role; that's why centralized mappings for this relation via > > AAA is important. > > > > However, I think the access control policy (the MIB configuration) > > associated with a specific group is not likely to change frequently. > > Which wildcarded MIB info an administrator is allowed to access as > > compared to helpdesk personnel or as compared to a general user is not > > likely to change often. > > > > So I think the OLD text is more accurate (although I personally would > > have preferred roles "are reflected in VACM groups" without the "and > > rules"). > > > > I'm satisfied with the OLD text. > > > > > > > > > c. Page 5. Sec 5.2 > > > > Suggested change- > > > > OLD: > > > > This table is indexed by the integer assigned to each security > > > > > > model > > > > NEW: > > > > This table is indexed by the identifier assigned to the > > > Security > > > > Model > > > > > > > > [Note: Security Model needs to have a > > > pointer/definition early in the > > > > document.] > > > > > > I's like to hear others' opinions on this one. > > > As a technical contributor, I think the proposed change of > > > "integer" to "identifier" is misleading and potentially confusing. > > > > I prefer integer. > > I prefer "each security model" to "the Security Model" > > Since SnmpSecurityModel has a SYNTAX of INTEGER, I would see integer as right > and anything else as less than right. > > Tom Petch > > > > > > > e. Page 7. Sec 7.2 > > > > SnmpSecurityModel is not defined in RFC 3411 > > > > I suggest > > > > OLD: > > > > | o the SnmpSecurityModel [RFC3411] needed as an index into the > > > > | vacmSecurityToGroupTable; > > > > NEW: > > > > | o the SNMP Security Model, vacmSecurityModel [RFC3411], > > > needed as an > > > > | index into the vacmSecurityToGroupTable; > > > > [Note: Security Model needs to have a > > > pointer/definition early in the > > > > document.] > > > > > > I think dragging in vacmSecurityModel in this way confuses > > > rather than enlightens. > > > Instead, the TC would make sense here, providing the syntax > > > of the formal parameter. > > > > agreed. > > > > > > > > > > > > > > f. Page 7. Sec 7.2 > > > > the RADIUS User-Name Attribute or equivalent is also > > > needed as an index > > > > into the vacmSecurityToGroupTable. > > > > I suggest > > > > OLD: > > > > | o the RADIUS User-Name Attribute or equivalent; > > > > NEW: > > > > | o the RADIUS User-Name Attribute or equivalent which > > > will be used as > > > > | the index, vacmSecurityName, into the > > > vacmSecurityToGroupTable; > > > > > > Ok, though I think this is not helpful. > > I agree this is not helpful. > > > > > > > > > > > > g. Page 7. Sec 7.2 > > > > | In particular, if either the User-Name or > > > Management-Policy-Id is > > > > | absent, invalid, or a zero-length string, no further > > > processing of > > > > | the session establishment indication is undertaken. > > > > If the SNMP Security Model has value 'any' (0) then no further > > > > processing will be undertaken; is that correct? If that > > > is that is > > > > the case I suggest > > > > OLD: > > > > | In particular, if either the User-Name or > > > Management-Policy-Id is > > > > | absent, invalid, or a zero-length string, no further > > > processing of > > > > | the session establishment indication is undertaken. > > > > NEW: > > > > | In particular, if either the User-Name or > > > Management-Policy-Id is > > > > | absent, invalid, or a zero-length string, or, if the SNMP > > > Security > > > > | Model has value 'any' (0), no further processing of the > > session > > > > | establishment indication is undertaken. > > > > > > As a technical contributor: > > > The distinction here is between information from sources > > > external to the implementation, and implementation-internal > > > sources. Pointing out bad stuff that might come from an > > > external source is probably helpful to an implementor. > > > Identifying things that might happen if an implementation is > > > *itself* broken seems like an endless and counter-productive path. > > > > > > As Editor: no action taken, pending comments from others. > > > > agreed. > > > > > > > > > > > > h. Page 7. Sec 7.2.1 > > > > Along the lines of the change in (e) > > > > OLD: > > > > | o vacmAaaSecurityModel = value of SnmpSecurityModel > > > corresponding to > > > > | the security model in use > > > > NEW: > > > > | o vacmAaaSecurityModel = value of SNMP Security Model > > > corresponding to > > > > | the security model in use > > > > > > Ok. > > > > unnecessary, and I am not sure it is as accurate as the original > > statement. > > > > > > > > > > > > l. Page 7. Sec 7.2.2 > > > > Suggested change- > > > > OLD: > > > > | If a corresponding entry already exists in the > > > > | vacmSecurityToGroupTable, and the row's StorageType is anything > > > > | other than "volatile", or the RowStatus is anything other than > > > > | "active", > > > > NEW: > > > > | If a corresponding entry already exists in the > > > > | vacmSecurityToGroupTable, and the row's > > > > | vacmSecurityToGroupStorageType is anything other than > > > "volatile", > > > > | or the vacmSecurityToGroupStatus is anything other than > > "active", > > > > > > Ok, though as a technical contributor I think this change > > > makes the document much harder to read / understand. > > > > I agree. I think it is widely understood that StoargeType and RwStatus > > refer to the row they are in, so it is not necessary to spell out the > > row's fuill object name. > > > > > > > > > > > > m. Page 7. Sec 7.2.2 > > > > The second paragraph does not belong to this subsection. > > > > After making the change suggested in (l) move the > > > paragraph (para-2) > > > > to section 7.2.3 after the 1st paragraph. > > > > > > No. The paragraph belongs here - it spells out conditions > > > under which an entry MUST NOT be created. > > > > agreed. > > this will likely go through iesg review easier if you changed the > > "will not" to "MUST NOT" be overridden. > > > > > > > > > > > > n. Page 7. Sec 7.2.3 > > > > Suggested change: > > > > OLD: > > > > | The operational assumption here is that if the row's > > > StorageType is > > > > | "volatile", then this entry was probably dynamically created; an > > > > > > | entry created by a security administrator would not normally be > > > > | given a StorageType of "volatile". If value being provided by > > > > | RADIUS (or > > > > NEW: > > > > | The operational assumption here is that if the row's > > > > | vacmSecurityToGroupStorageType is "volatile", then this > > > entry was > > > > | probably dynamically created; an entry created by a security > > > > | administrator would not normally be given a > > > > | vacmSecurityToGroupStorageType of "volatile". If the value being > > > > > > | provided by RADIUS (or > > > > > > Ok, though I think this is a huge step backwards in terms of > > > readability. > > > > agreed. I recommend not making this change. > > > > > > > > > > > > o. Page 7. Sec 7.3.2 > > > > s/StorageType/vacmSecurityToGroupStorageType/g; > > > > > > Ok, though I think this is a huge step backwards in terms of > > > readability. > > > > agreed. I recommend not making this chnage. > > > > > > > > > > > > p. An overview describing the relevant parts of the AAA > > > service and the > > > > VACM may be helpful to make the memo more easily > > > understandable. The > > > > other option which I will not recommend will be to > > > include a statement > > > > as terse as "the reader of this memo is expected to have read > > and > > > > understood the AAA service document RFC XXX1, the RADIUS > > > document RFC > > > > XXX2 and the View-Based Access Control Model document RFC > > XXX3." > > > > > > I'll take the latter option. The document is already far too > > > long as it is, considering how little it actually does. > > > > As a person who needs to review lots of documents, I understand the > > reviewer's desire to have a succinct intro to make things easier to > > understand, but implementers will need to understand the RADIUS and > > VACM specs, so I think it appropriate to say "the reader is expected > > to have read ..." > > > > > > > > > q. AAA and RADIUS. > > > > I see that this has been discussed in the mailing list > > > before. But I > > > > am afraid that the problem persists. > > > > > > > > Editorial nits. > > > > > > > > a. Page 12 Sec 9 > > > > OLD: > > > > | could also occur if the SNMP security administrator had > > > mistakenly > > > > | created these non-volatile entries in error. > > > > NEW: > > > > | could also occur if the SNMP security administrator had > > > mistakenly > > > > | created these non-volatile entries. > > > > > > Ok > > > > how about "mistakenly created these entries as non-volatile."? > > that is the error under consideration here, right? > > but it is a nit. > > > > > > > > Randy > > > > > > > > > _______________________________________________ > > > IETFMIBS mailing list > > > IETFMIBS@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietfmibs > > > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From randy_presuhn@mindspring.com Wed Aug 25 10:53:44 2010 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 9C8FE3A6899; Wed, 25 Aug 2010 10:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.525 X-Spam-Level: X-Spam-Status: No, score=-101.525 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_20=-0.74, USER_IN_WHITELIST=-100] 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 VOdMg983GZwt; Wed, 25 Aug 2010 10:53:43 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 667CE3A6805; Wed, 25 Aug 2010 10:53:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XHy0QQLod62MQBMlZiDPIr1ImpkpCCld2g8TczvDGthIdqv9UiNUjMLl94L7M2DS; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.92.248] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OoKAd-0002Hz-6d; Wed, 25 Aug 2010 13:53:55 -0400 Message-ID: <002d01cb447e$7c411840$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Adrian Farrel" , References: <20100825093455.65EF63A696E@core3.amsl.com> Date: Wed, 25 Aug 2010 10:53:53 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fef0db5235259c7b2794938ab7d02415b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.92.248 Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] COMMENT: draft-ietf-isms-radius-vacm 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: Wed, 25 Aug 2010 17:53:44 -0000 Hi - > From: "Adrian Farrel" > To: > Cc: ; > Sent: Wednesday, August 25, 2010 2:34 AM > Subject: COMMENT: draft-ietf-isms-radius-vacm > > Comment: > > Thanks for this I-D. I have no objection to its publication as an RFC. > > Section 4.1 > > I found the following sentence somewhat tricky. > > An implementation-specific identifier is needed for each AAA- > authorized "session", corresponding to a communication channel, such > as a transport session, for which a principal has been AAA- > authenticated and which is authorized to offer SNMP service. > > The problem is around "implementation-specific" which implies that > there is a single identifier for all communication channels from any > Company-X Product-Y device. Not what you mean! > > If you have time to tweak this a little, that would be good. I'm not able to parse the sentence in a way that yields the reading you found problematic. However, would something like this address your concern? A unique identifier is needed for each AAA-authorized "session", corresponding to a communication channel, such as a transport session, for which a principal has been AAA-authenticated and which is authorized to offer SNMP service. How these identifiers are assigned is implementation-specific. N.B. - there are ongoing discussions in the WG about whether "AAA-authorized" and "AAA-authenticated" might be open to misinterpretation, which might result in other tweaks to this text. > --- > > Section 4.2 > > Not sure that the two uses of "MAY" in this section really need to be > upper case, but it is not very important. I agree that these might be border cases. If the objection isn't a strong one, I'll leave them as-is, since this is what the WG agreed to. FWIW, I *think* the usage is defensible in the context of specifying conformance to an applicability statement, but I wouldn't put up much of a fight if folks think it's important to change this to lower case. > --- > > Section 5.1 > > Would be nice to give a reference for the TCs mentioned. Consider it done! Randy From randy_presuhn@mindspring.com Wed Aug 25 11:21:54 2010 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 D01283A6839; Wed, 25 Aug 2010 11:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 98Mnto0+WfKu; Wed, 25 Aug 2010 11:21:52 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 6E9C63A687E; Wed, 25 Aug 2010 11:21:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AMOl4FDsaA4rbKNWDOYiF3299/34xG+OWlbpY1BqABajKFSn63dJQpOmrHtnHnPW; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.33.92.248] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OoKbP-00057n-1v; Wed, 25 Aug 2010 14:21:35 -0400 Message-ID: <006c01cb4482$59bbaca0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Glenn M. Keeni" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com> <017201cb4408$64797660$6801a8c0@oemcomputer> <4C75150A.6050909@cysols.com> Date: Wed, 25 Aug 2010 11:21:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe98b1821f1c422db541e9bbf162d14646350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.92.248 Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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: Wed, 25 Aug 2010 18:21:55 -0000 Hi - > From: "Glenn M. Keeni" > To: "Randy Presuhn" > Cc: ; ; > Sent: Wednesday, August 25, 2010 6:05 AM > Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II > > Hi, > > > >> m. Page 7. Sec 7.2.2 > >> The second paragraph does not belong to this subsection. > >> After making the change suggested in (l) move the paragraph (para-2) > >> to section 7.2.3 after the 1st paragraph. > > > > No. The paragraph belongs here - it spells out conditions under which > > an entry MUST NOT be created. > > > That is interesting. If this paragraph > | If a corresponding entry already exists in the > | vacmSecurityToGroupTable, and the row's StorageType is anything other > | than "volatile", or the RowStatus is anything other than "active", > | then a role (group) mapping for this user (principal) has already > | been put in place on this system, and will not be overridden. > spells out conditions under which an entry MUST NOT be created. > > Then you are implying that if the above condition is not met i.e. > If a corresponding entry already exists in the > vacmSecurityToGroupTable, and the row's StorageType is > "volatile", or the RowStatus is "active", > an entry will be/may be/must be created? Am I missing something? I see your point. This paragraph is redundant tutorial material and can safely be deleted. I'm now persuaded that we should just delete the second paragraph in section 7.2.2, since it doesn't add anything that doesn't follow from what is specified in the following section. Randy From ietfdbh@comcast.net Wed Aug 25 17:45:48 2010 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 512463A68CC for ; Wed, 25 Aug 2010 17:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 q25REJC5OLeY for ; Wed, 25 Aug 2010 17:45:47 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 334D93A68D2 for ; Wed, 25 Aug 2010 17:45:47 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta02.westchester.pa.mail.comcast.net with comcast id yaEF1e0011ei1Bg52omLXJ; Thu, 26 Aug 2010 00:46:20 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id yomK1e00F2JQnJT3komKog; Thu, 26 Aug 2010 00:46:20 +0000 From: "David Harrington" To: "'Randy Presuhn'" , "'Adrian Farrel'" , References: <20100825093455.65EF63A696E@core3.amsl.com> <002d01cb447e$7c411840$6801a8c0@oemcomputer> Date: Wed, 25 Aug 2010 20:45:29 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <002d01cb447e$7c411840$6801a8c0@oemcomputer> Thread-Index: ActEfourlSY2dB0jS4qJfSoV6Fe+PwAOSJhg Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] COMMENT: draft-ietf-isms-radius-vacm 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, 26 Aug 2010 00:45:48 -0000 Hi Randy, I think we usually use implementation-dependent rather than implementation-specific. That's how I interpreted Adrian's comment. my $.02 dbh > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, August 25, 2010 1:54 PM > To: Adrian Farrel; iesg@ietf.org > Cc: draft-ietf-isms-radius-vacm@tools.ietf.org; > isms@ietf.org; isms-chairs@tools.ietf.org > Subject: Re: COMMENT: draft-ietf-isms-radius-vacm > > Hi - > > > From: "Adrian Farrel" > > To: > > Cc: ; > > > > Sent: Wednesday, August 25, 2010 2:34 AM > > Subject: COMMENT: draft-ietf-isms-radius-vacm > > > > Comment: > > > > Thanks for this I-D. I have no objection to its publication > as an RFC. > > > > Section 4.1 > > > > I found the following sentence somewhat tricky. > > > > An implementation-specific identifier is needed for each AAA- > > authorized "session", corresponding to a communication > channel, such > > as a transport session, for which a principal has been AAA- > > authenticated and which is authorized to offer SNMP service. > > > > The problem is around "implementation-specific" which implies that > > there is a single identifier for all communication channels > from any > > Company-X Product-Y device. Not what you mean! > > > > If you have time to tweak this a little, that would be good. > > I'm not able to parse the sentence in a way that yields the > reading you found problematic. However, would something like > this address your concern? > > A unique identifier is needed for each AAA-authorized "session", > corresponding to a communication channel, such as a transport > session, for which a principal has been AAA-authenticated and > which is authorized to offer SNMP service. How these identifiers > are assigned is implementation-specific. > > N.B. - there are ongoing discussions in the WG about whether > "AAA-authorized" > and "AAA-authenticated" might be open to misinterpretation, > which might result in other tweaks to this text. > > > --- > > > > Section 4.2 > > > > Not sure that the two uses of "MAY" in this section really > need to be > > upper case, but it is not very important. > > I agree that these might be border cases. If the objection > isn't a strong one, I'll leave them as-is, since this is what > the WG agreed to. FWIW, I *think* the usage is defensible in > the context of specifying conformance to an applicability > statement, but I wouldn't put up much of a fight if folks > think it's important to change this to lower case. > > > > --- > > > > Section 5.1 > > > > Would be nice to give a reference for the TCs mentioned. > > Consider it done! > > Randy > From randy_presuhn@mindspring.com Wed Aug 25 18:35:37 2010 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 3E8153A68D0; Wed, 25 Aug 2010 18:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.394 X-Spam-Level: X-Spam-Status: No, score=-101.394 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tyWhZnaOxMSf; Wed, 25 Aug 2010 18:35:33 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id ABC723A6A94; Wed, 25 Aug 2010 18:35:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CLLwXoQQlAyJ9ym9L2FfTS18sNoVXSrlXVu9tShVikk3XGU2+MkKnp70wzebKB9z; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.53.142] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OoRNs-0004z9-KG; Wed, 25 Aug 2010 21:36:04 -0400 Message-ID: <001901cb44bf$0d48aca0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "David Harrington" , "'Adrian Farrel'" , References: <20100825093455.65EF63A696E@core3.amsl.com> <002d01cb447e$7c411840$6801a8c0@oemcomputer> Date: Wed, 25 Aug 2010 18:36:04 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe931502ddd6f8386280da6e1987ef6b73350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.53.142 Cc: draft-ietf-isms-radius-vacm@tools.ietf.org, isms@ietf.org, isms-chairs@tools.ietf.org Subject: Re: [Isms] COMMENT: draft-ietf-isms-radius-vacm 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, 26 Aug 2010 01:35:37 -0000 Hi - Ok, I'll do a global replacement of implementation-specific with implementation-dependent, as well as the change in phrasing. Randy ----- Original Message ----- > From: "David Harrington" > To: "'Randy Presuhn'" ; "'Adrian Farrel'" ; > Cc: ; ; > Sent: Wednesday, August 25, 2010 5:45 PM > Subject: RE: COMMENT: draft-ietf-isms-radius-vacm > > Hi Randy, > > I think we usually use implementation-dependent rather than > implementation-specific. > That's how I interpreted Adrian's comment. > > my $.02 > dbh > > > -----Original Message----- > > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > > Behalf Of Randy Presuhn > > Sent: Wednesday, August 25, 2010 1:54 PM > > To: Adrian Farrel; iesg@ietf.org > > Cc: draft-ietf-isms-radius-vacm@tools.ietf.org; > > isms@ietf.org; isms-chairs@tools.ietf.org > > Subject: Re: COMMENT: draft-ietf-isms-radius-vacm > > > > Hi - > > > > > From: "Adrian Farrel" > > > To: > > > Cc: ; > > > > > > Sent: Wednesday, August 25, 2010 2:34 AM > > > Subject: COMMENT: draft-ietf-isms-radius-vacm > > > > > > Comment: > > > > > > Thanks for this I-D. I have no objection to its publication > > as an RFC. > > > > > > Section 4.1 > > > > > > I found the following sentence somewhat tricky. > > > > > > An implementation-specific identifier is needed for each AAA- > > > authorized "session", corresponding to a communication > > channel, such > > > as a transport session, for which a principal has been AAA- > > > authenticated and which is authorized to offer SNMP service. > > > > > > The problem is around "implementation-specific" which implies that > > > > there is a single identifier for all communication channels > > from any > > > Company-X Product-Y device. Not what you mean! > > > > > > If you have time to tweak this a little, that would be good. > > > > I'm not able to parse the sentence in a way that yields the > > reading you found problematic. However, would something like > > this address your concern? > > > > A unique identifier is needed for each AAA-authorized "session", > > corresponding to a communication channel, such as a transport > > session, for which a principal has been AAA-authenticated and > > which is authorized to offer SNMP service. How these identifiers > > are assigned is implementation-specific. > > > > N.B. - there are ongoing discussions in the WG about whether > > "AAA-authorized" > > and "AAA-authenticated" might be open to misinterpretation, > > which might result in other tweaks to this text. > > > > > --- > > > > > > Section 4.2 > > > > > > Not sure that the two uses of "MAY" in this section really > > need to be > > > upper case, but it is not very important. > > > > I agree that these might be border cases. If the objection > > isn't a strong one, I'll leave them as-is, since this is what > > the WG agreed to. FWIW, I *think* the usage is defensible in > > the context of specifying conformance to an applicability > > statement, but I wouldn't put up much of a fight if folks > > think it's important to change this to lower case. > > > > > > > --- > > > > > > Section 5.1 > > > > > > Would be nice to give a reference for the TCs mentioned. > > > > Consider it done! > > > > Randy > > > From glenn@cysols.com Wed Aug 25 20:55:01 2010 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 86C3E3A68EA; Wed, 25 Aug 2010 20:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 V6VD3uH7AwZd; Wed, 25 Aug 2010 20:55:00 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id 662923A688E; Wed, 25 Aug 2010 20:55:00 -0700 (PDT) Received: from [127.0.0.1] (Bert.win2004.cysol.co.jp [192.168.0.198]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7Q3tMRh098194 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 12:55:29 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C75E5A6.4010206@cysols.com> Date: Thu, 26 Aug 2010 12:55:18 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: ietfmibs@ietf.org, "isms@ietf.org" References: <01b501cb440b$baae3860$6801a8c0@oemcomputer> <0922D7EA0E1B41FDB6B6F3BD35B429EF@NEWTON603> <20100825110221.GA318@elstar.local> In-Reply-To: <20100825110221.GA318@elstar.local> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [Isms] [IETFMIBS] Proposed resolution of comments ondraft-ietf-isms-radius-vacm-09.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: Thu, 26 Aug 2010 03:55:01 -0000 Hi, If RFC 2903 and RFC 2904 are unacceptable as pointers to the "Authentication, Authorization, and Accounting services" that we are referring to in this document I am afraid the issue of a definition/pointer to the phrase remains open. I will seek the AD's guidance on this issue. Glenn On 2010/08/25 20:02, Juergen Schoenwaelder wrote: > On Wed, Aug 25, 2010 at 12:49:05PM +0200, Dave Nelson wrote: >> >>> Comment from Glenn M. Keeni, August 23, 2010: >>> 6.2 A reference to AAA service architecture/Framework will be >>> in order if this document does target generic AAA services >>> (as the title suggests). >>> Action: add citations suggested by reviewer in followup message >>> OLD: >>> | Model (VACM) [RFC3415] MIB objects, based on information received >>> | from an Authentication, Authorization, and Accounting (AAA) service, >>> | such as RADIUS [RFC2865]. >>> NEW: >>> | Model (VACM) [RFC3415] MIB objects, based on information received >>> | from an Authentication, Authorization, and Accounting (AAA) service >>> | [RFC2903, RFC2904], such as RADIUS [RFC2865]. >> >> I object to this issue resolution. With all due respect to the reviewer, >> RFC 2903 and RFC 2904 are the work product of the IRTF AAA Architecture >> Research Group (AAAarch RG). As far as I know, these documents have not >> formed the basis of any AAA protocols or systems in current deployment. I >> believe that adding these references may in fact confuse the reader. > > I agree (speaking as technical contributor). No change needed. > > /js > From glenn@cysols.com Wed Aug 25 21:08:41 2010 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 D55513A6832; Wed, 25 Aug 2010 21:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.577 X-Spam-Level: X-Spam-Status: No, score=0.577 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_83=0.6] 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 kc5SdzC4Jkna; Wed, 25 Aug 2010 21:08:40 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id EC9DE3A688E; Wed, 25 Aug 2010 21:08:39 -0700 (PDT) Received: from [127.0.0.1] (Bert.win2004.cysol.co.jp [192.168.0.198]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7Q49BmF099199 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 13:09:12 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C75E8E5.4020106@cysols.com> Date: Thu, 26 Aug 2010 13:09:09 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: isms@ietf.org References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com> <4C73D72D.8070902@cysols.com> <017201cb4408$64797660$6801a8c0@oemcomputer> In-Reply-To: <017201cb4408$64797660$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ietfmibs@ietf.org Subject: Re: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II 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, 26 Aug 2010 04:08:42 -0000 Hi, >> 10.3 Document issues >> >> a. Terminology: >> I suggest that a Terminology section be added. Several terms used >> in this document are open to mis-interpretation. E.g. >> "group": >> This is a generic term. But, in this document it probably, without >> exception, refers to a group as in the VACM document[RFC 3415; Sec 2.1]. >> I would recommend >> stating early in the document that the term "group" refers to the >> term defined in [RFC 3415; Sec 2.1] or, >> defining a "VACM-group" and replacing all occurrences of "group" by >> "VACM-group" > > Ok, I will add a list of tautologies in a new "Terminology" section. > However, as a technical contributor, I think the tendency to elevate > each English word or phrase to the status of "term" is most > unfortunate, and seriously detracts from the clarity of the document. > Please use the Conventions section. We can do without a new "Terminology" section. Thanks, Glenn On 2010/08/25 12:48, Randy Presuhn wrote: > Hi - > >> From: "Glenn M. Keeni" >> To:; "Glenn Mansfield Keeni" >> Cc: >> Sent: Tuesday, August 24, 2010 7:29 AM >> Subject: [Isms] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txt Part-II >> >> Hi, >> >> Thanks for waiting. This is the Part-II of the MIB Doctor Review >> of draft-ietf-isms-radius-vacm-09.txt. It focuses on the Document >> issues. >> >> Glenn >> >> +--------------------------------------------------------------------+ >> >> 10.3 Document issues >> >> a. Terminology: >> I suggest that a Terminology section be added. Several terms used >> in this document are open to mis-interpretation. E.g. >> "group": >> This is a generic term. But, in this document it probably, without >> exception, refers to a group as in the VACM document[RFC 3415; Sec 2.1]. >> I would recommend >> stating early in the document that the term "group" refers to the >> term defined in [RFC 3415; Sec 2.1] or, >> defining a "VACM-group" and replacing all occurrences of "group" by >> "VACM-group" > > Ok, I will add a list of tautologies in a new "Terminology" section. > However, as a technical contributor, I think the tendency to elevate > each English word or phrase to the status of "term" is most > unfortunate, and seriously detracts from the clarity of the document. > >> "authenticated user": >> This is a generic term. It would be good to make it clear in the >> document that the term "authenticated user" refers to a user >> authenticated by the AAA services. Or, >> define a "AAA-authenticated user" and use that term consistently for >> the rest of the document. >> [The terms "AAA-authenticated" and "AAA-authorized" are used in the >> document but sporadically.] > > I will add these to the tautology list > > >> The terms "Security Name", "Security Model", "Group Name" should be >> defined/referred and used consistently in the document. Else, >> the terms securityName, securityModel, groupName should be used >> with appropriate pointers [RFC 3415]. > > Ok. > > >> b. Page 4. Sec 4.1 >> | The use case assumption here is that roles within an organization, >> | which are reflected in VACM as groups and rules, change infrequently, >> I presume "rules" refer to the "access control policy" defined in the >> VACM ? If that is the case I would suggest >> OLD: >> | The use case assumption here is that roles within an organization, >> | which are reflected in VACM as groups and rules, change infrequently, >> NEW: >> | The use case assumption here is that roles within an organization, >> | which are reflected in VACM as groups and associated access control >> | policies", change infrequently, > > Ok. > > >> c. Page 5. Sec 5.2 >> Suggested change- >> OLD: >> This table is indexed by the integer assigned to each security model >> NEW: >> This table is indexed by the identifier assigned to the Security Model >> >> [Note: Security Model needs to have a pointer/definition early in the >> document.] > > I's like to hear others' opinions on this one. > As a technical contributor, I think the proposed change of "integer" to > "identifier" is misleading and potentially confusing. > > I will add "security model" to the list of tautologies. > > >> d. Page 6. Sec 7.1 >> | They also assume that the User-Name [RFC2865] from the RADIUS Access- >> | Request message (or equivalent) corresponds to an SNMP Security Name >> | [RFC3411]. >> The term "SNMP Security Name" does not appear in RFC 3411. >> securityName is defined in RFC 3411 section 3.2.2. >> Suggested change- >> OLD: >> | They also assume that the User-Name [RFC2865] from the RADIUS Access- >> | Request message (or equivalent) corresponds to an SNMP Security Name >> | [RFC3411]. >> NEW: >> | They also assume that the User-Name [RFC2865] from the RADIUS Access- >> | Request message (or equivalent) corresponds to an SNMP securityName >> | [RFC3411]. > > I'll accomodate this by adding "security name" to the list of tautologies. > > >> e. Page 7. Sec 7.2 >> SnmpSecurityModel is not defined in RFC 3411 >> I suggest >> OLD: >> | o the SnmpSecurityModel [RFC3411] needed as an index into the >> | vacmSecurityToGroupTable; >> NEW: >> | o the SNMP Security Model, vacmSecurityModel [RFC3411], needed as an >> | index into the vacmSecurityToGroupTable; >> [Note: Security Model needs to have a pointer/definition early in the >> document.] > > I think dragging in vacmSecurityModel in this way confuses rather than enlightens. > Instead, the TC would make sense here, providing the syntax of the formal parameter. > > >> f. Page 7. Sec 7.2 >> the RADIUS User-Name Attribute or equivalent is also needed as an index >> into the vacmSecurityToGroupTable. >> I suggest >> OLD: >> | o the RADIUS User-Name Attribute or equivalent; >> NEW: >> | o the RADIUS User-Name Attribute or equivalent which will be used as >> | the index, vacmSecurityName, into the vacmSecurityToGroupTable; > > Ok, though I think this is not helpful. > > >> g. Page 7. Sec 7.2 >> | In particular, if either the User-Name or Management-Policy-Id is >> | absent, invalid, or a zero-length string, no further processing of >> | the session establishment indication is undertaken. >> If the SNMP Security Model has value 'any' (0) then no further >> processing will be undertaken; is that correct? If that is that is >> the case I suggest >> OLD: >> | In particular, if either the User-Name or Management-Policy-Id is >> | absent, invalid, or a zero-length string, no further processing of >> | the session establishment indication is undertaken. >> NEW: >> | In particular, if either the User-Name or Management-Policy-Id is >> | absent, invalid, or a zero-length string, or, if the SNMP Security Model >> | has value 'any' (0), no further processing of >> | the session establishment indication is undertaken. > > As a technical contributor: > The distinction here is between information from sources external > to the implementation, and implementation-internal sources. Pointing > out bad stuff that might come from an external source is probably helpful > to an implementor. Identifying things that might happen if an implementation > is *itself* broken seems like an endless and counter-productive path. > > As Editor: no action taken, pending comments from others. > > >> h. Page 7. Sec 7.2.1 >> Along the lines of the change in (e) >> OLD: >> | o vacmAaaSecurityModel = value of SnmpSecurityModel corresponding to >> | the security model in use >> NEW: >> | o vacmAaaSecurityModel = value of SNMP Security Model corresponding to >> | the security model in use > > Ok. > > >> i. Page 7. Sec 7.2.1 >> | o vacmAaaSecurityName = RADIUS User-Name Attribute or equivalent, >> | the securityName that will be used in invocations of the >> | isAccessAllowed() abstract service interface; >> "isAccessAllowed() abstract service interface" appears for the first >> time. Please provide a pointer/reference. > > Ok. > > >> j. Page 7. Sec 7.2.1 >> The requirements for the vacmAaaSessionID are not explicit. I suggest >> using text from the DESCRIPTION of vacmAaaSessionID in the MIB module. >> OLD: >> | o vacmAaaSessionID = unique session identifier >> NEW: >> | o vacmAaaSessionID = session identifier. This value MUST be unique >> | among all currently open sessions of all of this SNMP engine's >> | transport models. > > Ok. > > >> k. Page 7. Sec 7.2.1 >> | Otherwise, if the row already exists, update the vacmAaaGroupName >> | with the value supplied. >> It will be helpful to be explicit about "value supplied". I would >> suggest >> OLD: >> | Otherwise, if the row already exists, update the vacmAaaGroupName >> | with the value supplied. >> NEW: >> | Otherwise, if the row already exists, update the vacmAaaGroupName >> | with the RADIUS Management-Policy-Id Attribute or equivalent. > > Ok. > > >> l. Page 7. Sec 7.2.2 >> Suggested change- >> OLD: >> | If a corresponding entry already exists in the >> | vacmSecurityToGroupTable, and the row's StorageType is anything other >> | than "volatile", or the RowStatus is anything other than "active", >> NEW: >> | If a corresponding entry already exists in the >> | vacmSecurityToGroupTable, and the row's vacmSecurityToGroupStorageType >> | is anything other than "volatile", or the vacmSecurityToGroupStatus is >> | anything other than "active", > > Ok, though as a technical contributor I think this change makes the document much > harder to read / understand. > > >> m. Page 7. Sec 7.2.2 >> The second paragraph does not belong to this subsection. >> After making the change suggested in (l) move the paragraph (para-2) >> to section 7.2.3 after the 1st paragraph. > > No. The paragraph belongs here - it spells out conditions under which > an entry MUST NOT be created. > > >> n. Page 7. Sec 7.2.3 >> Suggested change: >> OLD: >> | The operational assumption here is that if the row's StorageType is >> | "volatile", then this entry was probably dynamically created; an >> | entry created by a security administrator would not normally be given >> | a StorageType of "volatile". If value being provided by RADIUS (or >> NEW: >> | The operational assumption here is that if the row's >> | vacmSecurityToGroupStorageType is "volatile", then this entry was >> | probably dynamically created; an entry created by a security >> | administrator would not normally be given a >> | vacmSecurityToGroupStorageType of "volatile". If the value being >> | provided by RADIUS (or > > Ok, though I think this is a huge step backwards in terms of readability. > > >> o. Page 7. Sec 7.3.2 >> s/StorageType/vacmSecurityToGroupStorageType/g; > > Ok, though I think this is a huge step backwards in terms of readability. > > >> p. An overview describing the relevant parts of the AAA service and the >> VACM may be helpful to make the memo more easily understandable. The >> other option which I will not recommend will be to include a statement >> as terse as "the reader of this memo is expected to have read and >> understood the AAA service document RFC XXX1, the RADIUS document RFC >> XXX2 and the View-Based Access Control Model document RFC XXX3." > > I'll take the latter option. The document is already far too long as it is, > considering how little it actually does. > >> q. AAA and RADIUS. >> I see that this has been discussed in the mailing list before. But I >> am afraid that the problem persists. >> >> Editorial nits. >> >> a. Page 12 Sec 9 >> OLD: >> | could also occur if the SNMP security administrator had mistakenly >> | created these non-volatile entries in error. >> NEW: >> | could also occur if the SNMP security administrator had mistakenly >> | created these non-volatile entries. > > Ok > > Randy > > From randy_presuhn@mindspring.com Wed Aug 25 21:56:45 2010 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 5E22C3A6902; Wed, 25 Aug 2010 21:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.695 X-Spam-Level: X-Spam-Status: No, score=-101.695 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zNyUOdH09kKF; Wed, 25 Aug 2010 21:56:44 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 619BD3A6831; Wed, 25 Aug 2010 21:56:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T/s/Sa0QWVhhOn3/+RHUHiuOYmIdWIUy0MV1DsDjSwXPdbHaon1lvYwKa83FnSlL; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.53.142] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OoUWH-0001rw-T1; Thu, 26 Aug 2010 00:56:58 -0400 Message-ID: <006a01cb44db$1b50d540$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Glenn M. Keeni" , , "Glenn Mansfield Keeni" References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> Date: Wed, 25 Aug 2010 21:56:52 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe689d246b36de05ba9c44b3f1984b2d8b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.53.142 Cc: ietfmibs@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I 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, 26 Aug 2010 04:56:45 -0000 Hi - > From: "Glenn M. Keeni" > To: ; "Glenn Mansfield Keeni" > Cc: > Sent: Monday, August 23, 2010 6:28 AM > Subject: [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I ... > 9. Other Issues: > a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to > the list of imperatives (although the standard boilerplate in > RFC 2119 does not include it, it is used in the Security > Considerations section and it is defined in RFC 2119). ... I've verified that idnits rejects this sort of boilerplate change, flagging it as an error. Consequently, I will *NOT* add "NOT RECOMMENDED" to the list. Randy From ietfdbh@comcast.net Wed Aug 25 22:12:41 2010 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 F03CD3A6A6A for ; Wed, 25 Aug 2010 22:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AuNBzgnty8-B for ; Wed, 25 Aug 2010 22:12:39 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 2465A3A690D for ; Wed, 25 Aug 2010 22:12:39 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id ytAn1e00216LCl054tDCHP; Thu, 26 Aug 2010 05:13:12 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta06.westchester.pa.mail.comcast.net with comcast id ytDB1e0032JQnJT3StDBzN; Thu, 26 Aug 2010 05:13:12 +0000 From: "David Harrington" To: "'Glenn M. Keeni'" , References: <01b501cb440b$baae3860$6801a8c0@oemcomputer> <0922D7EA0E1B41FDB6B6F3BD35B429EF@NEWTON603><20100825110221.GA318@elstar.local> <4C75E5A6.4010206@cysols.com> Date: Thu, 26 Aug 2010 01:13:09 -0400 Message-ID: <68B848405DB04E508ECD51749B5C0D1F@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <4C75E5A6.4010206@cysols.com> Thread-Index: ActE0ovU/1zjB1kMTk+50gUfNcjT+wACUuWQ Subject: Re: [Isms] [IETFMIBS] Proposed resolution of commentsondraft-ietf-isms-radius-vacm-09.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: Thu, 26 Aug 2010 05:12:41 -0000 Dave Nelson would be my AAA expert of choice to answer that question ;-) He used to be co-chair of RADIUS Extensions WG or you could ask the AAA Doctors Directorate, of which Dave is a member. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Glenn M. Keeni > Sent: Wednesday, August 25, 2010 11:55 PM > To: ietfmibs@ietf.org; isms@ietf.org > Subject: Re: [Isms] [IETFMIBS] Proposed resolution of > commentsondraft-ietf-isms-radius-vacm-09.txt > > Hi, > If RFC 2903 and RFC 2904 are unacceptable as pointers to > the "Authentication, Authorization, and Accounting services" > that we are referring to in this document I am afraid the > issue of a definition/pointer to the phrase remains open. > > I will seek the AD's guidance on this issue. > Glenn > > On 2010/08/25 20:02, Juergen Schoenwaelder wrote: > > On Wed, Aug 25, 2010 at 12:49:05PM +0200, Dave Nelson wrote: > >> > >>> Comment from Glenn M. Keeni, August 23, 2010: > >>> 6.2 A reference to AAA service architecture/Framework will be > >>> in order if this document does target generic AAA services > >>> (as the title suggests). > >>> Action: add citations suggested by reviewer in followup message > >>> OLD: > >>> | Model (VACM) [RFC3415] MIB objects, based on > information received > >>> | from an Authentication, Authorization, and Accounting (AAA) > >>> | service, such as RADIUS [RFC2865]. > >>> NEW: > >>> | Model (VACM) [RFC3415] MIB objects, based on > information received > >>> | from an Authentication, Authorization, and Accounting (AAA) > >>> | service [RFC2903, RFC2904], such as RADIUS [RFC2865]. > >> > >> I object to this issue resolution. With all due respect to the > >> reviewer, RFC 2903 and RFC 2904 are the work product of > the IRTF AAA > >> Architecture Research Group (AAAarch RG). As far as I know, these > >> documents have not formed the basis of any AAA protocols > or systems > >> in current deployment. I believe that adding these > references may in fact confuse the reader. > > > > I agree (speaking as technical contributor). No change needed. > > > > /js > > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From dromasca@avaya.com Thu Aug 26 02:16:00 2010 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 0038D3A6A9D for ; Thu, 26 Aug 2010 02:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AFgtVi7ZpIek for ; Thu, 26 Aug 2010 02:15:58 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C6ECD3A6884 for ; Thu, 26 Aug 2010 02:15:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,272,1280721600"; d="scan'208";a="234776685" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Aug 2010 05:16:29 -0400 X-IronPort-AV: E=Sophos;i="4.56,272,1280721600"; d="scan'208";a="502009978" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Aug 2010 05:16:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Aug 2010 11:16:08 +0200 Message-ID: In-Reply-To: <68B848405DB04E508ECD51749B5C0D1F@23FX1C1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] [IETFMIBS] Proposed resolution ofcommentsondraft-ietf-isms-radius-vacm-09.txt Thread-Index: ActE0ovU/1zjB1kMTk+50gUfNcjT+wACUuWQAAjQhNA= References: <01b501cb440b$baae3860$6801a8c0@oemcomputer> <0922D7EA0E1B41FDB6B6F3BD35B429EF@NEWTON603><20100825110221.GA318@elstar.local><4C75E5A6.4010206@cysols.com> <68B848405DB04E508ECD51749B5C0D1F@23FX1C1> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Glenn M. Keeni" , Subject: Re: [Isms] [IETFMIBS] Proposed resolution ofcommentsondraft-ietf-isms-radius-vacm-09.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: Thu, 26 Aug 2010 09:16:00 -0000 Directing the question to AAA-Doctors seems to me the right thing to do. Dan > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On=20 > Behalf Of David Harrington > Sent: Thursday, August 26, 2010 8:13 AM > To: 'Glenn M. Keeni'; isms@ietf.org > Subject: Re: [Isms] [IETFMIBS] Proposed resolution=20 > ofcommentsondraft-ietf-isms-radius-vacm-09.txt >=20 > Dave Nelson would be my AAA expert of choice to answer that question > ;-) > He used to be co-chair of RADIUS Extensions WG or you could=20 > ask the AAA Doctors Directorate, of which Dave is a member. >=20 > dbh=20 >=20 > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org]=20 > On Behalf=20 > > Of Glenn M. Keeni > > Sent: Wednesday, August 25, 2010 11:55 PM > > To: ietfmibs@ietf.org; isms@ietf.org > > Subject: Re: [Isms] [IETFMIBS] Proposed resolution of=20 > > commentsondraft-ietf-isms-radius-vacm-09.txt > >=20 > > Hi, > > If RFC 2903 and RFC 2904 are unacceptable as pointers to the=20 > > "Authentication, Authorization, and Accounting services" > > that we are referring to in this document I am afraid the=20 > issue of a=20 > > definition/pointer to the phrase remains open. > >=20 > > I will seek the AD's guidance on this issue. > > Glenn > >=20 > > On 2010/08/25 20:02, Juergen Schoenwaelder wrote: > > > On Wed, Aug 25, 2010 at 12:49:05PM +0200, Dave Nelson wrote: > > >> > > >>> Comment from Glenn M. Keeni, August 23, 2010: > > >>> 6.2 A reference to AAA service architecture/Framework will be > > >>> in order if this document does target generic AAA services > > >>> (as the title suggests). > > >>> Action: add citations suggested by reviewer in followup message > > >>> OLD: > > >>> | Model (VACM) [RFC3415] MIB objects, based on > > information received > > >>> | from an Authentication, Authorization, and Accounting (AAA)=20 > > >>> | service, such as RADIUS [RFC2865]. > > >>> NEW: > > >>> | Model (VACM) [RFC3415] MIB objects, based on > > information received > > >>> | from an Authentication, Authorization, and Accounting (AAA)=20 > > >>> | service [RFC2903, RFC2904], such as RADIUS [RFC2865]. > > >> > > >> I object to this issue resolution. With all due respect to the=20 > > >> reviewer, RFC 2903 and RFC 2904 are the work product of > > the IRTF AAA > > >> Architecture Research Group (AAAarch RG). As far as I know, > these=20 > > >> documents have not formed the basis of any AAA protocols > > or systems > > >> in current deployment. I believe that adding these > > references may in fact confuse the reader. > > >=20 > > > I agree (speaking as technical contributor). No change needed. > > >=20 > > > /js > > >=20 > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms >=20 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms >=20 From glenn@cysols.com Thu Aug 26 03:04:09 2010 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 C3E0E3A6828; Thu, 26 Aug 2010 03:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.273 X-Spam-Level: X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 w8z7tnwHv5Gr; Thu, 26 Aug 2010 03:04:09 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id A90CE3A6359; Thu, 26 Aug 2010 03:04:08 -0700 (PDT) Received: from [127.0.0.1] (Bert.win2004.cysol.co.jp [192.168.0.198]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7QA4SmO015327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 19:04:29 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C763C2C.2000307@cysols.com> Date: Thu, 26 Aug 2010 19:04:28 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: isms@ietf.org References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <006a01cb44db$1b50d540$6801a8c0@oemcomputer> In-Reply-To: <006a01cb44db$1b50d540$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ietfmibs@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I 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, 26 Aug 2010 10:04:09 -0000 On 2010/08/26 13:56, Randy Presuhn wrote: > Hi - > >> From: "Glenn M. Keeni" >> To:; "Glenn Mansfield Keeni" >> Cc: >> Sent: Monday, August 23, 2010 6:28 AM >> Subject: [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I > ... >> 9. Other Issues: >> a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to >> the list of imperatives (although the standard boilerplate in >> RFC 2119 does not include it, it is used in the Security >> Considerations section and it is defined in RFC 2119). > ... > > I've verified that idnits rejects this sort of boilerplate change, flagging > it as an error. > > Consequently, I will *NOT* add "NOT RECOMMENDED" to the list. OK. I will leave that as an issue to be handled by the RFC editor. [Lets hope that someone is watching and will fix this conflict of requirements in the IETF documents process.] Glenn From ietfc@btconnect.com Thu Aug 26 04:57:33 2010 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 967A23A6A96; Thu, 26 Aug 2010 04:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKUIKSJZoJve; Thu, 26 Aug 2010 04:57:32 -0700 (PDT) Received: from c2beaomr09.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by core3.amsl.com (Postfix) with ESMTP id 577683A698C; Thu, 26 Aug 2010 04:57:32 -0700 (PDT) Received: from pc6 (host81-153-11-67.range81-153.btcentralplus.com [81.153.11.67]) by c2beaomr09.btconnect.com with SMTP id FFT25733; Thu, 26 Aug 2010 12:57:51 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C7656BF.026C, actions=tag Message-ID: <01c301cb450c$d48fa960$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Glenn M. Keeni" , References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><006a01cb44db$1b50d540$6801a8c0@oemcomputer> <4C763C2C.2000307@cysols.com> Date: Thu, 26 Aug 2010 12:52:42 +0200 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-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4C7656C9.005F,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: ietfmibs@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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, 26 Aug 2010 11:57:33 -0000 ----- Original Message ----- From: "Glenn M. Keeni" To: Cc: Sent: Thursday, August 26, 2010 12:04 PM > On 2010/08/26 13:56, Randy Presuhn wrote: > >> From: "Glenn M. Keeni" > >> To:; "Glenn Mansfield Keeni" > >> Cc: > >> Sent: Monday, August 23, 2010 6:28 AM > > ... > >> 9. Other Issues: > >> a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to > >> the list of imperatives (although the standard boilerplate in > >> RFC 2119 does not include it, it is used in the Security > >> Considerations section and it is defined in RFC 2119). > > ... > > I've verified that idnits rejects this sort of boilerplate change, flagging > > it as an error. > > > > Consequently, I will *NOT* add "NOT RECOMMENDED" to the list. > OK. I will leave that as an issue to be handled by the RFC editor. > [Lets hope that someone is watching and will fix this conflict > of requirements in the IETF documents process.] The issue has been around for a long time and I had always taken it as gospel that RFC2119 meant what it said ie NOT RECOMMENDED must not (MUST NOT?) be used and I saw I-Ds edited to avoid using it. Recently there was an exchange along the lines that this was all a mistake and that NOT RECOMMENDED would be added retrospectively; uh huh, I think Randy has got it right. Tom Petch > > Glenn > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From turners@ieca.com Thu Aug 26 04:58:03 2010 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 B15BD3A6ADB for ; Thu, 26 Aug 2010 04:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 KPTcN3u3GaCl for ; Thu, 26 Aug 2010 04:58:03 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id 88DB93A698C for ; Thu, 26 Aug 2010 04:58:03 -0700 (PDT) Received: (qmail 67710 invoked from network); 26 Aug 2010 11:58:30 -0000 Received: from thunderfish.local (turners@71.191.11.133 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 26 Aug 2010 04:58:29 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: D5699ZcVM1kB_9i6CgCRrLUCbF7aiSIs4LveNX3quMceXTG B3zdC.4a2oJKPz9KFX84SMqdlUczbQYXlv3_oBiUQty2fNHFxXGkmK0Sd9VD KA1aVU6tY3B7U6U_ZiufHQEp.3IXbiRcaospBC11nFANzu_qFNZhKlIa.DyO 7ILvEg3ynz42SpyHnBFINjEDCP8yB6qU8qZZGKvlhYSKq47qETze1h_k_Y12 eX_ysV9cfF9j.CDC2XvcW0xBYhcvRyS8SI.d470ugIjWP4hLGVyYen3wKZd. Cfx3nR7xUwg5QyYhBINczSLK3XAoM8bHp7Ql7d64KlgkJg5odxwU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C7656E1.8050603@ieca.com> Date: Thu, 26 Aug 2010 07:58:25 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Randy Presuhn References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <006a01cb44db$1b50d540$6801a8c0@oemcomputer> In-Reply-To: <006a01cb44db$1b50d540$6801a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Glenn Mansfield Keeni , ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I 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, 26 Aug 2010 11:58:03 -0000 Randy Presuhn wrote: > Hi - > >> From: "Glenn M. Keeni" >> To: ; "Glenn Mansfield Keeni" >> Cc: >> Sent: Monday, August 23, 2010 6:28 AM >> Subject: [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I > ... >> 9. Other Issues: >> a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to >> the list of imperatives (although the standard boilerplate in >> RFC 2119 does not include it, it is used in the Security >> Considerations section and it is defined in RFC 2119). > ... > > I've verified that idnits rejects this sort of boilerplate change, flagging > it as an error. > > Consequently, I will *NOT* add "NOT RECOMMENDED" to the list. I've done it on other IDs, but you have to have it in a specific order: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. spt From ietfdbh@comcast.net Thu Aug 26 05:28:38 2010 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 25C6B3A6955 for ; Thu, 26 Aug 2010 05:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 klKN2zYWyfzz for ; Thu, 26 Aug 2010 05:28:37 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 2273C3A6873 for ; Thu, 26 Aug 2010 05:28:37 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id yzur1e0041ap0As540VA0D; Thu, 26 Aug 2010 12:29:10 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta22.westchester.pa.mail.comcast.net with comcast id z0V91e00H2JQnJT3i0V9kD; Thu, 26 Aug 2010 12:29:10 +0000 From: "David Harrington" To: "'Glenn M. Keeni'" , References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com><4C727773.5060703@cysols.com><006a01cb44db$1b50d540$6801a8c0@oemcomputer> <4C763C2C.2000307@cysols.com> Date: Thu, 26 Aug 2010 08:28:45 -0400 Message-ID: <2173272F9863436F9F8957167B41F0C5@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 In-Reply-To: <4C763C2C.2000307@cysols.com> Thread-Index: ActFBh0RXJZFMfsyQnaX8Umxh/43mQAE+8Pw Cc: ietfmibs@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review:draft-ietf-isms-radius-vacm-09.txtPart-I 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, 26 Aug 2010 12:28:38 -0000 The IESG and RFC Editor are well aware. Errata exist for this. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Glenn M. Keeni > Sent: Thursday, August 26, 2010 6:04 AM > To: isms@ietf.org > Cc: ietfmibs@ietf.org > Subject: Re: [Isms] [IETFMIBS] MIB Doctor > Review:draft-ietf-isms-radius-vacm-09.txtPart-I > > On 2010/08/26 13:56, Randy Presuhn wrote: > > Hi - > > > >> From: "Glenn M. Keeni" > To:; "Glenn > >> Mansfield Keeni" Cc: > >> Sent: Monday, August 23, 2010 6:28 AM > >> Subject: [IETFMIBS] MIB Doctor Review: > >> draft-ietf-isms-radius-vacm-09.txtPart-I > > ... > >> 9. Other Issues: > >> a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to > >> the list of imperatives (although the standard boilerplate in > >> RFC 2119 does not include it, it is used in the Security > >> Considerations section and it is defined in RFC 2119). > > ... > > > > I've verified that idnits rejects this sort of boilerplate change, > > flagging it as an error. > > > > Consequently, I will *NOT* add "NOT RECOMMENDED" to the list. > OK. I will leave that as an issue to be handled by the RFC editor. > [Lets hope that someone is watching and will fix this > conflict of requirements in the IETF documents process.] > > Glenn > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From glenn@cysols.com Thu Aug 26 05:28:42 2010 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 CD0BA3A682F; Thu, 26 Aug 2010 05:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.25 X-Spam-Level: X-Spam-Status: No, score=0.25 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 z51U7VJ7lYzs; Thu, 26 Aug 2010 05:28:42 -0700 (PDT) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) by core3.amsl.com (Postfix) with ESMTP id C1B453A68B9; Thu, 26 Aug 2010 05:28:41 -0700 (PDT) Received: from [127.0.0.1] (cysvpn03.priv.cysol.co.jp [192.168.0.90]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.4/8.14.4) with ESMTP id o7QCT3Pi028717 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 21:29:06 +0900 (JST) (envelope-from glenn@cysols.com) Message-ID: <4C765E0F.6090901@cysols.com> Date: Thu, 26 Aug 2010 21:29:03 +0900 From: "Glenn M. Keeni" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sean Turner References: <4C527775.3000007@ieca.com> <4C65D27F.30006@ieca.com><20100816132904.GA75407@elstar.local> <4C69411E.8050907@cysols.com> <4C694E1C.5070804@cysols.com> <4C727773.5060703@cysols.com> <006a01cb44db$1b50d540$6801a8c0@oemcomputer> <4C7656E1.8050603@ieca.com> In-Reply-To: <4C7656E1.8050603@ieca.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: ietfmibs@ietf.org, isms@ietf.org Subject: Re: [Isms] [IETFMIBS] MIB Doctor Review: draft-ietf-isms-radius-vacm-09.txtPart-I 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, 26 Aug 2010 12:28:42 -0000 On 2010/08/26 20:58, Sean Turner wrote: > Randy Presuhn wrote: >> Hi - >> >>> From: "Glenn M. Keeni" >>> To: ; "Glenn Mansfield Keeni" >>> Cc: >>> Sent: Monday, August 23, 2010 6:28 AM >>> Subject: [IETFMIBS] MIB Doctor Review: >>> draft-ietf-isms-radius-vacm-09.txtPart-I >> ... >>> 9. Other Issues: >>> a. in Section 3, "Conventions", please add "NOT RECOMMENDED" to >>> the list of imperatives (although the standard boilerplate in >>> RFC 2119 does not include it, it is used in the Security >>> Considerations section and it is defined in RFC 2119). >> ... >> >> I've verified that idnits rejects this sort of boilerplate change, >> flagging >> it as an error. >> >> Consequently, I will *NOT* add "NOT RECOMMENDED" to the list. > > I've done it on other IDs, but you have to have it in a specific order: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > [RFC2119]. > Excellent. Then we can close this issue. > spt Glenn From root@core3.amsl.com Mon Aug 30 20:15:07 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3AD813A68EC; Mon, 30 Aug 2010 20:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100831031507.3AD813A68EC@core3.amsl.com> Date: Mon, 30 Aug 2010 20:15:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-10.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: Tue, 31 Aug 2010 03:15:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Using Authentication, Authorization, and Accounting services to Dynamically Provision View-based Access Control Model User-to-Group Mappings Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-10.txt Pages : 19 Date : 2010-08-30 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting (AAA) services, such as the Remote Authentication Dial-In User Service (RADIUS), to dynamically update user-to-group mappings in the View-Based Access Control Model (VACM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-30201349.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Mon Aug 30 20:28:02 2010 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 1FCE93A68B3; Mon, 30 Aug 2010 20:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.696 X-Spam-Level: X-Spam-Status: No, score=-100.696 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, USER_IN_WHITELIST=-100] 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 MGWgxBejYmkW; Mon, 30 Aug 2010 20:28:01 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 3B18C3A6452; Mon, 30 Aug 2010 20:28:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZwbuBKKxXfWrv0GLlky+6PjJDl52YnjYW0J/lz6+GD/e3+0YSPlJOJsT+IHqz9Pl; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.48.248] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqHWR-0001Jt-Du; Mon, 30 Aug 2010 23:28:31 -0400 Message-ID: <000701cb48bc$9b53c100$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Mon, 30 Aug 2010 20:28:30 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe3551af7476f6009242110428b40b0660350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.48.248 Cc: IESG Subject: [Isms] Updated version of draft-ietf-isms-radius-vacm 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: Tue, 31 Aug 2010 03:28:02 -0000 Hi - I've posted an update to the radius vacm draft. Due to the large number of (conflicting) comments and responses, I think this version needs close inspection. I've tried to balance the various comments, but in some cases I could not see a middle ground. In other cases, I've tried to balance conflicting comments, and made changes different from what were suggested by either side. In several cases, this text differs substantially from the "proposed resolution" sent a few days ago, due to the fervent responses triggered by that message. Diffs are available at http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-radius-vacm-10 Please look to see whether your concerns have been addressed, and, more importantly, to verify that I haven't broken something in the course of attempting to address the comments. Randy From j.schoenwaelder@jacobs-university.de Tue Aug 31 00:48:30 2010 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 BA29E3A6926; Tue, 31 Aug 2010 00:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.948 X-Spam-Level: X-Spam-Status: No, score=-101.948 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 XYz4lZB+P7Ev; Tue, 31 Aug 2010 00:48:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8A9D53A6832; Tue, 31 Aug 2010 00:48:29 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14BC7C001D; Tue, 31 Aug 2010 09:49:00 +0200 (CEST) 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 XksZ8i-HODj6; Tue, 31 Aug 2010 09:48:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC4F6C001A; Tue, 31 Aug 2010 09:48:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4464E1491FBE; Tue, 31 Aug 2010 09:48:39 +0200 (CEST) Date: Tue, 31 Aug 2010 09:48:39 +0200 From: Juergen Schoenwaelder To: "isms@ietf.org" , "Glenn M. Keeni" Message-ID: <20100831074839.GA80776@elstar.local> Mail-Followup-To: "isms@ietf.org" , "Glenn M. Keeni" , IESG References: <000701cb48bc$9b53c100$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701cb48bc$9b53c100$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: IESG Subject: Re: [Isms] Updated version of draft-ietf-isms-radius-vacm 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: Tue, 31 Aug 2010 07:48:30 -0000 On Tue, Aug 31, 2010 at 05:28:30AM +0200, Randy Presuhn wrote: > I've posted an update to the radius vacm draft. Due to the large > number of (conflicting) comments and responses, I think this version > needs close inspection. I've tried to balance the various > comments, but in some cases I could not see a middle ground. > In other cases, I've tried to balance conflicting comments, and > made changes different from what were suggested by either side. > In several cases, this text differs substantially from the > "proposed resolution" sent a few days ago, due to the fervent > responses triggered by that message. > > Diffs are available at > http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-radius-vacm-10 > > Please look to see whether your concerns have been addressed, and, > more importantly, to verify that I haven't broken something in the > course of attempting to address the comments. Thanks Randy for getting this update posted. I like to ask people to review the changes and to send any concerns to this list by Friday September 3rd. In case you find any issues, please provide detailed editing instructions. Note that we are only closing the issues that were raised during the IESG process and silence will be read as agreement with the edits made by Randy. /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 Tue Aug 31 00:54:43 2010 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 D98593A67A7 for ; Tue, 31 Aug 2010 00:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.651 X-Spam-Level: X-Spam-Status: No, score=-100.651 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_50=0.001, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 OupXWkfSFa-n for ; Tue, 31 Aug 2010 00:54:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 842D03A691D for ; Tue, 31 Aug 2010 00:54:42 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 119B6C001A for ; Tue, 31 Aug 2010 09:55:13 +0200 (CEST) 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 ZftMkX2eugM4; Tue, 31 Aug 2010 09:55:12 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A9E7C0006; Tue, 31 Aug 2010 09:55:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3F7CF149200D; Tue, 31 Aug 2010 09:54:54 +0200 (CEST) Date: Tue, 31 Aug 2010 09:54:54 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100831075454.GB80776@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] js review of draft-ietf-isms-radius-vacm-10 changes 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: Tue, 31 Aug 2010 07:54:43 -0000 Hi, I think the changes generally look good. There is one thing I like to mention though. In the definition of vacmAaaSessionID, I like to suggest the following change: OLD REFERENCE "The abstract service interface parameter tmSessionID is defined in RFC 5590 section 5.2.4 and RFC 5592 section 4.1.2" NEW REFERENCE "The abstract service interface parameter tmSessionID is defined in RFC 5590 section 5.2.4." It is my understanding that the definition of tmSessionID is in RFC 5590 and RFC 5592 merely uses tmSessionID. By avoiding a reference to RFC 5592 in this REFERENCE clause, I think RFC 5592 can be moved from a normative reference to an informative reference (since all other references to RFC 5592 are in the "for example" context). I also found two editorial nits: - s/IsAccessAllowed/isAccessAllowed/ - replace the final ',' with a '.' in section 6.3 /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 Tue Aug 31 01:32:14 2010 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 111523A696D for ; Tue, 31 Aug 2010 01:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.733 X-Spam-Level: X-Spam-Status: No, score=-100.733 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_40=-0.185, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 mBCK3suXrHQ8 for ; Tue, 31 Aug 2010 01:32:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A38853A6926 for ; Tue, 31 Aug 2010 01:31:54 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AE79C001A for ; Tue, 31 Aug 2010 10:32:25 +0200 (CEST) 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 QaxngfLW8zWL; Tue, 31 Aug 2010 10:32:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BDF8C0006; Tue, 31 Aug 2010 10:32:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2D99A14921CE; Tue, 31 Aug 2010 10:32:03 +0200 (CEST) Date: Tue, 31 Aug 2010 10:32:03 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100831083203.GC80776@elstar.local> Mail-Followup-To: isms@ietf.org References: <20100831075454.GB80776@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100831075454.GB80776@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes 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: Tue, 31 Aug 2010 08:32:14 -0000 On Tue, Aug 31, 2010 at 09:54:54AM +0200, Juergen Schoenwaelder wrote: > Hi, > > I think the changes generally look good. There is one thing I like to > mention though. In the definition of vacmAaaSessionID, I like to > suggest the following change: > > OLD > > REFERENCE "The abstract service interface parameter tmSessionID > is defined in RFC 5590 section 5.2.4 and RFC 5592 > section 4.1.2" > > NEW > > REFERENCE "The abstract service interface parameter tmSessionID > is defined in RFC 5590 section 5.2.4." > > It is my understanding that the definition of tmSessionID is in RFC > 5590 and RFC 5592 merely uses tmSessionID. By avoiding a reference to > RFC 5592 in this REFERENCE clause, I think RFC 5592 can be moved from > a normative reference to an informative reference (since all other > references to RFC 5592 are in the "for example" context). > > I also found two editorial nits: > > - s/IsAccessAllowed/isAccessAllowed/ > - replace the final ',' with a '.' in section 6.3 Two more things: The REFERENCE clause in the definition of vacmAaaSecurityToGroupEntry must be moved in front of the INDEX clause, see RFC 2578 pages 8 and 9. Smilint freaks out with a parse error on the current version. As stated before, I personally dislike the module name change from SNMP-VACM-AAA-MIB to VACM-AAA-MIB. I believe it is a valuable feature that all core SNMP modules start with SNMP-. Concerning consistency with RFC 4181, I like to point out that Appendix C is titled "Suggested Naming Conventions" and not REQUIRED Naming Conventions. In this particular case, I believe consistency with SNMP module naming style (the SNMP- prefix) and consistency with the way VACM identifiers are constructed is way more important than consistency with the "Suggested Naming Conventions" of RFC 4181. Hence I suggest the following change: OLD VACM-AAA-MIB DEFINITIONS ::= BEGIN NEW SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Tue Aug 31 03:55:16 2010 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 6A7D13A696A for ; Tue, 31 Aug 2010 03:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 v2qMy3KjT6Xw for ; Tue, 31 Aug 2010 03:55:15 -0700 (PDT) Received: from c2beaomr02.btconnect.com (c2beaomr02.btconnect.com [213.123.26.180]) by core3.amsl.com (Postfix) with ESMTP id 411DD3A68E6 for ; Tue, 31 Aug 2010 03:55:14 -0700 (PDT) Received: from pc6 (host81-153-11-67.range81-153.btcentralplus.com [81.153.11.67]) by c2beaomr02.btconnect.com with SMTP id EBY57679; Tue, 31 Aug 2010 11:55:40 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C7CDFAC.0189, actions=tag Message-ID: <019501cb48f1$f4f66de0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Randy Presuhn" , References: <000701cb48bc$9b53c100$6801a8c0@oemcomputer> Date: Tue, 31 Aug 2010 11:45:01 +0200 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-Junkmail-Status: score=10/50, host=c2beaomr02.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4C7CDFAF.035A,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Isms] Updated version of draft-ietf-isms-radius-vacm 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: Tue, 31 Aug 2010 10:55:16 -0000 Good stuff! 4.1 still has a lingering SecurityName which I would think better securityName since that is what is used in RFC5592 as cited there. And I echo Juergen that RFC5590 is the correct reference for tmSessionID in vacmAaaSessionID Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Cc: "IESG" Sent: Tuesday, August 31, 2010 5:28 AM Subject: [Isms] Updated version of draft-ietf-isms-radius-vacm > Hi - > > I've posted an update to the radius vacm draft. Due to the large > number of (conflicting) comments and responses, I think this version > needs close inspection. I've tried to balance the various > comments, but in some cases I could not see a middle ground. > In other cases, I've tried to balance conflicting comments, and > made changes different from what were suggested by either side. > In several cases, this text differs substantially from the > "proposed resolution" sent a few days ago, due to the fervent > responses triggered by that message. > > Diffs are available at > http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-radius-vacm-10 > > Please look to see whether your concerns have been addressed, and, > more importantly, to verify that I haven't broken something in the > course of attempting to address the comments. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From ietfc@btconnect.com Tue Aug 31 04:23:05 2010 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 6DEB13A6A34 for ; Tue, 31 Aug 2010 04:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74] 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 rCLYF2NZmwRx for ; Tue, 31 Aug 2010 04:23:04 -0700 (PDT) Received: from c2beaomr05.btconnect.com (c2beaomr05.btconnect.com [213.123.26.183]) by core3.amsl.com (Postfix) with ESMTP id 2F2193A693D for ; Tue, 31 Aug 2010 04:23:03 -0700 (PDT) Received: from pc6 (host81-153-11-67.range81-153.btcentralplus.com [81.153.11.67]) by c2beaomr05.btconnect.com with SMTP id FJK77959; Tue, 31 Aug 2010 12:23:24 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C7CE62C.02B5, actions=tag Message-ID: <020701cb48f5$d50edea0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Randy Presuhn" , References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> Date: Tue, 31 Aug 2010 12:17:46 +0200 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-Junkmail-Status: score=10/50, host=c2beaomr05.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0209.4C7CE634.03F2,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: [Isms] PS 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: Tue, 31 Aug 2010 11:23:05 -0000 Just noticed two quirks vacmAaaSecurityToGroupTable OBJECT-TYPE .... DESCRIPTION "This table provides a listing of all currently active sessions for which a mapping of the combination of ** SnmpSecurityModel and securityName into a the name of vacmAaaSecurityToGroupEntry OBJECT-TYPE ... DESCRIPTION "An entry in this table maps the combination of a ** SnmpSecurityModel and securityName into a the name In both cases, I prefer /a the/the/ Tom Petch From ietfdbh@comcast.net Tue Aug 31 05:39:30 2010 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 4DC953A690E for ; Tue, 31 Aug 2010 05:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.434 X-Spam-Level: X-Spam-Status: No, score=-101.434 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_05=-1.11, USER_IN_WHITELIST=-100] 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 So2TNHl++ehE for ; Tue, 31 Aug 2010 05:39:29 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id E19073A6861 for ; Tue, 31 Aug 2010 05:39:28 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id 0zww1f0031GhbT85E0g0Sr; Tue, 31 Aug 2010 12:40:00 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta07.westchester.pa.mail.comcast.net with comcast id 10fz1f00C2JQnJT3T0fzBK; Tue, 31 Aug 2010 12:40:00 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , References: <20100831075454.GB80776@elstar.local> <20100831083203.GC80776@elstar.local> Date: Tue, 31 Aug 2010 08:38:57 -0400 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: <20100831083203.GC80776@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: ActI5xqI+OK5QH9SQqyNbln0ZpLl2AAIXdow Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes 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: Tue, 31 Aug 2010 12:39:30 -0000 Hi, Hi, I tend to go the other direction on this issue. Maybe this is because I come from the NMS side, not the agent side. I think it tremendously helpful to have consistent naming of objects; an operator looking at the naming prefix for an object, such as vacmAaaSecurityToGroupEntry, can tell that the full definition is likely to be in the VACM-AAA-MIB. It would not be at all intuitive to me that vacmAaaSecurityToGroupEntry would be in the SNMP-VACM-AAA-MIB. I don't see any real benefit to the SNMP- prefix if the object names are not consistent with that module name. What benefits do you see? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, August 31, 2010 4:32 AM > To: isms@ietf.org > Subject: Re: [Isms] js review of > draft-ietf-isms-radius-vacm-10 changes > > On Tue, Aug 31, 2010 at 09:54:54AM +0200, Juergen Schoenwaelder wrote: > > Hi, > > > > I think the changes generally look good. There is one thing > I like to > > mention though. In the definition of vacmAaaSessionID, I like to > > suggest the following change: > > > > OLD > > > > REFERENCE "The abstract service interface parameter > tmSessionID > > is defined in RFC 5590 section 5.2.4 and RFC 5592 > > section 4.1.2" > > > > NEW > > > > REFERENCE "The abstract service interface parameter > tmSessionID > > is defined in RFC 5590 section 5.2.4." > > > > It is my understanding that the definition of tmSessionID is in RFC > > 5590 and RFC 5592 merely uses tmSessionID. By avoiding a > reference to > > RFC 5592 in this REFERENCE clause, I think RFC 5592 can be > moved from > > a normative reference to an informative reference (since all other > > references to RFC 5592 are in the "for example" context). > > > > I also found two editorial nits: > > > > - s/IsAccessAllowed/isAccessAllowed/ > > - replace the final ',' with a '.' in section 6.3 > > Two more things: > > The REFERENCE clause in the definition of > vacmAaaSecurityToGroupEntry must be moved in front of the > INDEX clause, see RFC 2578 pages 8 and 9. Smilint freaks out > with a parse error on the current version. > > As stated before, I personally dislike the module name change > from SNMP-VACM-AAA-MIB to VACM-AAA-MIB. I believe it is a > valuable feature that all core SNMP modules start with SNMP-. > Concerning consistency with RFC 4181, I like to point out > that Appendix C is titled "Suggested Naming Conventions" and > not REQUIRED Naming Conventions. > In this particular case, I believe consistency with SNMP > module naming style (the SNMP- prefix) and consistency with > the way VACM identifiers are constructed is way more > important than consistency with the "Suggested Naming > Conventions" of RFC 4181. Hence I suggest the following change: > > OLD > > VACM-AAA-MIB DEFINITIONS ::= BEGIN > > NEW > > SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN > > /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 j.schoenwaelder@jacobs-university.de Tue Aug 31 06:32:10 2010 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 0EFCF3A693F for ; Tue, 31 Aug 2010 06:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.186 X-Spam-Level: X-Spam-Status: No, score=-101.186 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_05=-1.11, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 o+AnDVLsUwB9 for ; Tue, 31 Aug 2010 06:32:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 517183A690E for ; Tue, 31 Aug 2010 06:32:08 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5D2DC000F; Tue, 31 Aug 2010 15:32:38 +0200 (CEST) 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 mI-4f7GQHHtr; Tue, 31 Aug 2010 15:32:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66E65C0004; Tue, 31 Aug 2010 15:32:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66C4014932C7; Tue, 31 Aug 2010 15:32:18 +0200 (CEST) Date: Tue, 31 Aug 2010 15:32:17 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100831133216.GC83821@elstar.local> Mail-Followup-To: David Harrington , "isms@ietf.org" References: <20100831075454.GB80776@elstar.local> <20100831083203.GC80776@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] js review of draft-ietf-isms-radius-vacm-10 changes 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: Tue, 31 Aug 2010 13:32:10 -0000 On Tue, Aug 31, 2010 at 02:38:57PM +0200, David Harrington wrote: > I tend to go the other direction on this issue. > Maybe this is because I come from the NMS side, not the agent side. > > I think it tremendously helpful to have consistent naming of objects; > an operator looking at the naming prefix for an object, such as > vacmAaaSecurityToGroupEntry, can tell that the full definition is > likely to be in the VACM-AAA-MIB. It would not be at all intuitive to > me that vacmAaaSecurityToGroupEntry would be in the SNMP-VACM-AAA-MIB. > > I don't see any real benefit to the SNMP- prefix if the object names > are not consistent with that module name. > What benefits do you see? I prefer consistency. So far, all core SNMP modules have an SNMP- prefix and this really is nice if you have to look for files. And yes, module names are commonly translated to implementation file names; probably I am just too much a coder. Perhaps the choice of the core SNMP module names was just a major historic accident. /js (who never ever guessed a module name from a descriptor, probably because some brave soul gave me grep) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Tue Aug 31 10:33:10 2010 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 D8FE23A699A for ; Tue, 31 Aug 2010 10:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.045 X-Spam-Level: X-Spam-Status: No, score=-102.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 d8OTf4CfovYc for ; Tue, 31 Aug 2010 10:33:09 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id D142A3A68DC for ; Tue, 31 Aug 2010 10:33:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UPTHE0dUydM0vIVC+E0W1JBiK5qJzOwBgXJ+Yb3bf3Mn4sg6dQ6TcJgaWAOLP6Uq; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.94] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqUiJ-0000G7-36 for isms@ietf.org; Tue, 31 Aug 2010 13:33:39 -0400 Message-ID: <005001cb4932$adde2380$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100831075454.GB80776@elstar.local> Date: Tue, 31 Aug 2010 10:33:50 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe8dec433c4255e6f30d6c56387fdda9dc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.94 Subject: [Isms] tmSessionID (was: js review of draft-ietf-isms-radius-vacm-10 changes) 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: Tue, 31 Aug 2010 17:33:11 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, August 31, 2010 12:54 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes ... > I think the changes generally look good. There is one thing I like to > mention though. In the definition of vacmAaaSessionID, I like to > suggest the following change: > > OLD > > REFERENCE "The abstract service interface parameter tmSessionID > is defined in RFC 5590 section 5.2.4 and RFC 5592 > section 4.1.2" > > NEW > > REFERENCE "The abstract service interface parameter tmSessionID > is defined in RFC 5590 section 5.2.4." > > It is my understanding that the definition of tmSessionID is in RFC > 5590 and RFC 5592 merely uses tmSessionID. By avoiding a reference to > RFC 5592 in this REFERENCE clause, I think RFC 5592 can be moved from > a normative reference to an informative reference (since all other > references to RFC 5592 are in the "for example" context). ... Actually, what I really should have referenced from RFC 5592 is in section 5.1. It specifies: tmSessionID = an implementation-dependent value that can be used to detect when a session has closed and been replaced by another session. The value in tmStateReference MUST uniquely identify the session over which the message was received. This session identifier MUST NOT be reused until there are no references to it remaining. This is an important constraint, not spelled out in RFC 5590. The more I look at the tmSessionID material in RFC 5590 and 5592, the more convinced I am that we should probably not mention it, even though I still think it would be the right thing to use (at least if I were implementing it. :-) Randy From randy_presuhn@mindspring.com Tue Aug 31 10:37:18 2010 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 E5D2E3A69E5 for ; Tue, 31 Aug 2010 10:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.091 X-Spam-Level: X-Spam-Status: No, score=-102.091 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 kuleqlXptoOY for ; Tue, 31 Aug 2010 10:37:16 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 660B23A6838 for ; Tue, 31 Aug 2010 10:37:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eo7WwbxBzAlJpe4uIgXIXZYere/K7U/XjU6ztj9fodFIP0dB84nvS6BXtgZHlSj3; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.94] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqUmI-0006fR-NT for isms@ietf.org; Tue, 31 Aug 2010 13:37:47 -0400 Message-ID: <005501cb4933$4277d360$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100831075454.GB80776@elstar.local> Date: Tue, 31 Aug 2010 10:38:00 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe6b78cba41dabd0ca5287410051de065d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.94 Subject: [Isms] Editorial nits (was: js review of draft-ietf-isms-radius-vacm-10 changes) 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: Tue, 31 Aug 2010 17:37:18 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, August 31, 2010 12:54 AM > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes ... > I also found two editorial nits: > > - s/IsAccessAllowed/isAccessAllowed/ > - replace the final ',' with a '.' in section 6.3 Fixed! Thanks. Randy From randy_presuhn@mindspring.com Tue Aug 31 10:42:38 2010 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 4C55D3A699A for ; Tue, 31 Aug 2010 10:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 o84-AZMAcLrW for ; Tue, 31 Aug 2010 10:42:37 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id DC2FD3A6842 for ; Tue, 31 Aug 2010 10:42:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RUWOpDYpyoxIFdYVzasUC0dhTyrjAiWQxJ/jlO0LatCbYB6IC0ezanR2iSd27qm0; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.94] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqUrT-0000VJ-CA for isms@ietf.org; Tue, 31 Aug 2010 13:43:07 -0400 Message-ID: <005a01cb4934$017eb800$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100831075454.GB80776@elstar.local> <20100831083203.GC80776@elstar.local> Date: Tue, 31 Aug 2010 10:43:20 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fedce3f44cfac68a422007eb24d9d65edf350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.94 Subject: [Isms] REFERENCE clause for vacmAaaSecurityToGroupEntry (was: js review of draft-ietf-isms-radius-vacm-10 changes) 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: Tue, 31 Aug 2010 17:42:38 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Tuesday, August 31, 2010 1:32 AM > Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes ... > The REFERENCE clause in the definition of vacmAaaSecurityToGroupEntry > must be moved in front of the INDEX clause, see RFC 2578 pages 8 and > 9. Smilint freaks out with a parse error on the current version. ... Fixed! Do we also need to add REFERENCE material here for SnmpSecurityModel and for the Session-Timeout attribute? Randy From randy_presuhn@mindspring.com Tue Aug 31 10:45:14 2010 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 A7CEF3A69C2 for ; Tue, 31 Aug 2010 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.163 X-Spam-Level: X-Spam-Status: No, score=-102.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 g8ZZG5MAqDge for ; Tue, 31 Aug 2010 10:45:13 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 66F583A6A7A for ; Tue, 31 Aug 2010 10:45:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UfZrW54mz5Kv6T0Z+QD3p1zrPvcD4owi4Na1gNA7whaFmc/kfjQLaceeURCQbWuJ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.94] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqUtz-00030B-Qy for isms@ietf.org; Tue, 31 Aug 2010 13:45:44 -0400 Message-ID: <005f01cb4934$5ec3ac00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000701cb48bc$9b53c100$6801a8c0@oemcomputer> <019501cb48f1$f4f66de0$4001a8c0@gateway.2wire.net> Date: Tue, 31 Aug 2010 10:45:57 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fec078e9163e32a0a680342414afc22336350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.94 Subject: [Isms] Lingering SecurityName (was: Updated version of draft-ietf-isms-radius-vacm) 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: Tue, 31 Aug 2010 17:45:14 -0000 Hi - > From: "t.petch" > To: "Randy Presuhn" ; > Sent: Tuesday, August 31, 2010 2:45 AM > Subject: Re: [Isms] Updated version of draft-ietf-isms-radius-vacm ... > 4.1 still has a lingering SecurityName which I would think better securityName > since that is what is used in RFC5592 as cited there. ... Fixed. (actually, this wasn't "lingering" - it was new text added as a result of the "AAA binding" discussion.) Randy From randy_presuhn@mindspring.com Tue Aug 31 10:46:46 2010 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 80F983A69C2 for ; Tue, 31 Aug 2010 10:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.192 X-Spam-Level: X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 M2AlvlXzt2CS for ; Tue, 31 Aug 2010 10:46:45 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 95D3A3A699A for ; Tue, 31 Aug 2010 10:46:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NfTcQDfojjV+MEzyLgBrxJ8TtuSUiIS4sRioCLa3JQaIdxhrA9VX0Y2B28kHUjv2; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.94] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqUvT-00039w-S2 for isms@ietf.org; Tue, 31 Aug 2010 13:47:16 -0400 Message-ID: <006401cb4934$95bb53c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001001cb02e2$ce654980$6801a8c0@oemcomputer> <020701cb48f5$d50edea0$4001a8c0@gateway.2wire.net> Date: Tue, 31 Aug 2010 10:47:29 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fea2bc4fa8ce38bece608133ef90f1a44f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.94 Subject: Re: [Isms] PS 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: Tue, 31 Aug 2010 17:46:46 -0000 Hi - > From: "t.petch" > To: "Randy Presuhn" ; > Sent: Tuesday, August 31, 2010 3:17 AM > Subject: PS > > Just noticed two quirks > > vacmAaaSecurityToGroupTable OBJECT-TYPE > .... > DESCRIPTION "This table provides a listing of all currently active > sessions for which a mapping of the combination of > ** SnmpSecurityModel and securityName into a the name of > > vacmAaaSecurityToGroupEntry OBJECT-TYPE > ... > DESCRIPTION "An entry in this table maps the combination of a > ** SnmpSecurityModel and securityName into a the name > > In both cases, I prefer /a the/the/ I agree, in both cases. Fixed, in both cases. Thanks! (in both cases :-) Randy From randy_presuhn@mindspring.com Tue Aug 31 11:17:23 2010 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 14C9F3A69E9 for ; Tue, 31 Aug 2010 11:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.288 X-Spam-Level: X-Spam-Status: No, score=-101.288 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_20=-0.74, USER_IN_WHITELIST=-100] 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 PoIgBCCXNhqM for ; Tue, 31 Aug 2010 11:17:22 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id E4F9B3A69E5 for ; Tue, 31 Aug 2010 11:17:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AnPe4bUfJGXulwJ9rXgZy2ySsN1w7HfH89MJRLDKjQB/ncy39i+hAJos0UdlKx33; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.60.5.94] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqVP6-0005RD-3v for isms@ietf.org; Tue, 31 Aug 2010 14:17:52 -0400 Message-ID: <008d01cb4938$dc1a52e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100831075454.GB80776@elstar.local><20100831083203.GC80776@elstar.local> <20100831133216.GC83821@elstar.local> Date: Tue, 31 Aug 2010 11:18:05 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe6b92872b677327e1f232abded5fe3190350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.5.94 Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes 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: Tue, 31 Aug 2010 18:17:23 -0000 Hi - Juergen schrieb: > As stated before, I personally dislike the module name change from > SNMP-VACM-AAA-MIB to VACM-AAA-MIB. I believe it is a valuable feature > that all core SNMP modules start with SNMP-. Concerning consistency > with RFC 4181, I like to point out that Appendix C is titled > "Suggested Naming Conventions" and not REQUIRED Naming Conventions. > In this particular case, I believe consistency with SNMP module naming > style (the SNMP- prefix) and consistency with the way VACM identifiers > are constructed is way more important than consistency with the > "Suggested Naming Conventions" of RFC 4181. Hence I suggest the > following change: > > OLD > > VACM-AAA-MIB DEFINITIONS ::= BEGIN > > NEW > > SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN David Harrington replied: > I tend to go the other direction on this issue. > Maybe this is because I come from the NMS side, not the agent side. > > I think it tremendously helpful to have consistent naming of objects; > an operator looking at the naming prefix for an object, such as > vacmAaaSecurityToGroupEntry, can tell that the full definition is > likely to be in the VACM-AAA-MIB. It would not be at all intuitive to > me that vacmAaaSecurityToGroupEntry would be in the SNMP-VACM-AAA-MIB. > > I don't see any real benefit to the SNMP- prefix if the object names > are not consistent with that module name. > What benefits do you see? Juergen replied: > I prefer consistency. So far, all core SNMP modules have an SNMP- > prefix and this really is nice if you have to look for files. And yes, > module names are commonly translated to implementation file names; > probably I am just too much a coder. Perhaps the choice of the core > SNMP module names was just a major historic accident. > > /js (who never ever guessed a module name from a descriptor, > probably because some brave soul gave me grep) As a technical contributor... No matter what we do, there will be a consistency or a usability problem. (1) consistency of the "DEFINITIONS" module name with the other SNMP infrastructure MIB modules (i.e., all start with "SNMP-" (2) MIB review guidelines suggestions relating the DEFINITIONS descriptor to the MODULE-IDENTITY module name (appendix C of RFC 4181, second bullet) (3) suggestions relating other descriptors in the module to the MODULE-IDENTITY (RFC 4181 appendix C, third bullet) RFC 4181 says "Authors and reviewers of IETF MIB modules have often found the following naming conventions to be helpful in the past, and authors of new IETF MIB modules are urged to consider following them." Not a terribly forceful statement. :-) The current text satisfies (2) and (3). (1) is what I'd characterize as an "oral history" requirement - while there may be some truth to it, it's not written down. Glenn's proposed change (add prefixes to all the definitions to satisfy (3)) would meet all three of these objectives, but would bring the downsides of requiring *lots* of editing (yes, I know that's not a valid objection) and, more importantly, the descriptors start becoming awkwardly long (yes, this is a somewhat subjective assessment) producing a solution that, in my opinion, is worse than the problem. I'd be perfectly happy with the naming as it is, or as it was. I can see a *slight* advantage to how it was in that an alphabetical list of modules would put this module and VACM close to each other. But I don't find it particularly persuasive. As editor... I await guidance from the chairs regarding the consensus of the WG. Randy From ietfdbh@comcast.net Tue Aug 31 13:23:28 2010 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 270453A6AF7 for ; Tue, 31 Aug 2010 13:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1sA547-ieUmC for ; Tue, 31 Aug 2010 13:23:26 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 4BA693A6AA5 for ; Tue, 31 Aug 2010 13:23:26 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id 12ay1f0020vyq2s5A8PxYM; Tue, 31 Aug 2010 20:23:57 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta05.westchester.pa.mail.comcast.net with comcast id 18Px1f00H2JQnJT3R8PxZk; Tue, 31 Aug 2010 20:23:57 +0000 From: "David Harrington" To: "'Randy Presuhn'" , References: <20100831075454.GB80776@elstar.local> <005001cb4932$adde2380$6801a8c0@oemcomputer> Date: Tue, 31 Aug 2010 16:23:15 -0400 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: <005001cb4932$adde2380$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: ActJMqoHILdF44GDTxC/Or7AeKxndAAFepZA Subject: Re: [Isms] tmSessionID (was: js review ofdraft-ietf-isms-radius-vacm-10 changes) 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: Tue, 31 Aug 2010 20:23:28 -0000 Hi, RFC5590 defines the tmSessionID. It defines it without many constraints because the content is model-specific. o tmSessionID: in order to verify whether the session has changed, the Transport Model must be able to compare the session used to receive the original request with the one to be used to send the response. This typically needs some form of session identifier. This value is only ever used by the Transport Model, so the format and interpretation of this field are model-specific and implementation-dependent. RFC5592 defines the SSHTM model-specific constraints. tmSessionID = an implementation-dependent value that can be used to detect when a session has closed and been replaced by another session. The value in tmStateReference MUST uniquely identify the session over which the message was received. This session identifier MUST NOT be reused until there are no references to it remaining. It might make sense for most models to use the same constraints, but it is not a requirement to do so. If somebody defines a model where tmSessionID is not necessarly unique, that would be legal. And neither RFC5590 nor RFC5592 mandates uniqueness across all transport models, only within the SSHTM model. If the current doc references tmSessionID as a worthy candidate for vacmAaaSessionID, it should be pointed out that the scope of uniqueness between tmSessionID and vacmAaaSessionID might differ, and the implementation might need to address that problem if it supports multiple concurrent transport models. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Tuesday, August 31, 2010 1:34 PM > To: isms@ietf.org > Subject: [Isms] tmSessionID (was: js review > ofdraft-ietf-isms-radius-vacm-10 changes) > > Hi - > > > From: "Juergen Schoenwaelder" > > To: > > Sent: Tuesday, August 31, 2010 12:54 AM > > Subject: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes > ... > > I think the changes generally look good. There is one thing > I like to > > mention though. In the definition of vacmAaaSessionID, I like to > > suggest the following change: > > > > OLD > > > > REFERENCE "The abstract service interface parameter > tmSessionID > > is defined in RFC 5590 section 5.2.4 and RFC 5592 > > section 4.1.2" > > > > NEW > > > > REFERENCE "The abstract service interface parameter > tmSessionID > > is defined in RFC 5590 section 5.2.4." > > > > It is my understanding that the definition of tmSessionID is in RFC > > 5590 and RFC 5592 merely uses tmSessionID. By avoiding a > reference to > > RFC 5592 in this REFERENCE clause, I think RFC 5592 can be > moved from > > a normative reference to an informative reference (since all other > > references to RFC 5592 are in the "for example" context). > ... > > Actually, what I really should have referenced from RFC 5592 > is in section 5.1. > It specifies: > > tmSessionID = an implementation-dependent value that can be > used to detect when a session has closed and been > replaced by > another session. The value in tmStateReference > MUST uniquely > identify the session over which the message was received. > This session identifier MUST NOT be reused until > there are no > references to it remaining. > > This is an important constraint, not spelled out in RFC 5590. > The more I look at the tmSessionID material in RFC 5590 and > 5592, the more convinced I am that we should probably not > mention it, even though I still think it would be the right > thing to use (at least if I were implementing it. :-) > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From Robert.Story@cobham.com Tue Aug 31 13:48:50 2010 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 EDA323A6AFB for ; Tue, 31 Aug 2010 13:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 g3zeLDsFlKSB for ; Tue, 31 Aug 2010 13:48:49 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id E08563A6A76 for ; Tue, 31 Aug 2010 13:48:48 -0700 (PDT) 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 o7VKnI4A004528; Tue, 31 Aug 2010 15:49:18 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o7VKnJ6L032388; Tue, 31 Aug 2010 15:49:19 -0500 Received: from sparta.com ([216.27.162.138]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Aug 2010 16:49:18 -0400 Date: Tue, 31 Aug 2010 16:49:13 -0400 From: Robert Story To: Randy Presuhn Message-ID: <20100831164913.59e1514b@sparta.com> In-Reply-To: <008d01cb4938$dc1a52e0$6801a8c0@oemcomputer> References: <20100831075454.GB80776@elstar.local> <20100831083203.GC80776@elstar.local> <20100831133216.GC83821@elstar.local> <008d01cb4938$dc1a52e0$6801a8c0@oemcomputer> Organization: SPARTA X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/jOl34tx+ZANCa3Pt7L3sIFY"; protocol="application/pgp-signature" X-OriginalArrivalTime: 31 Aug 2010 20:49:18.0170 (UTC) FILETIME=[FAF28BA0:01CB494D] Cc: isms@ietf.org Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes 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: Tue, 31 Aug 2010 20:48:50 -0000 --Sig_/jOl34tx+ZANCa3Pt7L3sIFY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 31 Aug 2010 11:18:05 -0700 Randy wrote: RP> more importantly, RP> the descriptors start becoming awkwardly long (yes, this is a somewhat RP> subjective assessment) producing a solution that, in my opinion, is wor= se RP> than the problem. I agree with Randy. I intensely dislike prefixes just for the sake of prefixing.=20 I also agree with Juergen that it would be nice for a core module mib name to include SNMP, but *not* if that means prefixing every object in the mib with snmp. --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/jOl34tx+ZANCa3Pt7L3sIFY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkx9as0ACgkQ7/fVLLY1mngeKwCgn1X2QnoCDYLBrTl/khLDaop2 nJgAn2UAcq/FySg62E5e4DO/sZfgNaic =V2Lv -----END PGP SIGNATURE----- --Sig_/jOl34tx+ZANCa3Pt7L3sIFY-- From j.schoenwaelder@jacobs-university.de Tue Aug 31 14:11:10 2010 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 489C43A6B1D for ; Tue, 31 Aug 2010 14:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.926 X-Spam-Level: X-Spam-Status: No, score=-101.926 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] 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 8N422A60hfZh for ; Tue, 31 Aug 2010 14:11:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 698673A6B17 for ; Tue, 31 Aug 2010 14:11:02 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69278C000F; Tue, 31 Aug 2010 23:11:31 +0200 (CEST) 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 BtaqgU8e44y0; Tue, 31 Aug 2010 23:11:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59261C0009; Tue, 31 Aug 2010 23:11:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5BB721494339; Tue, 31 Aug 2010 23:11:10 +0200 (CEST) Date: Tue, 31 Aug 2010 23:11:09 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100831211109.GA86737@elstar.local> Mail-Followup-To: David Harrington , 'Randy Presuhn' , "isms@ietf.org" References: <20100831075454.GB80776@elstar.local> <005001cb4932$adde2380$6801a8c0@oemcomputer> 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] tmSessionID (was: js review ofdraft-ietf-isms-radius-vacm-10 changes) 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: Tue, 31 Aug 2010 21:11:10 -0000 On Tue, Aug 31, 2010 at 10:23:15PM +0200, David Harrington wrote: > Hi, > > RFC5590 defines the tmSessionID. It defines it without many > constraints because the content is model-specific. > o tmSessionID: in order to verify whether the session has changed, > the Transport Model must be able to compare the session used to > receive the original request with the one to be used to send the > response. This typically needs some form of session identifier. > This value is only ever used by the Transport Model, so the > format > and interpretation of this field are model-specific and > implementation-dependent. > > RFC5592 defines the SSHTM model-specific constraints. > tmSessionID = an implementation-dependent value that can be > used to detect when a session has closed and been replaced > by > another session. The value in tmStateReference MUST > uniquely > identify the session over which the message was received. > This session identifier MUST NOT be reused until there are > no > references to it remaining. > > It might make sense for most models to use the same constraints, but > it is not a requirement to do so. If somebody defines a model where > tmSessionID is not necessarly unique, that would be legal. And neither > RFC5590 nor RFC5592 mandates uniqueness across all transport models, > only within the SSHTM model. > > If the current doc references tmSessionID as a worthy candidate for > vacmAaaSessionID, it should be pointed out that the scope of > uniqueness between tmSessionID and vacmAaaSessionID might differ, and > the implementation might need to address that problem if it supports > multiple concurrent transport models. Here is the text: DESCRIPTION "An implementation-dependent identifier of the session. This value MUST be unique among all currently open sessions of all of this SNMP engine's transport models. The value has no particular significance other than to distinguish sessions. Implementations in which tmSessionID has a compatible syntax and is unique across all transport models MAY use that value." Do you think there is anything wrong with it? Do you think it requires a reference to RFC 5592? /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 Tue Aug 31 16:09:45 2010 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 1C33F3A68A5 for ; Tue, 31 Aug 2010 16:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yi5+WyvxIHjf for ; Tue, 31 Aug 2010 16:09:43 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 6F3653A67DB for ; Tue, 31 Aug 2010 16:09:42 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id 12mc1f00K0ldTLk5EBADHX; Tue, 31 Aug 2010 23:10:13 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta04.westchester.pa.mail.comcast.net with comcast id 1BAD1f00A2JQnJT3QBAD95; Tue, 31 Aug 2010 23:10:13 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" References: <20100831075454.GB80776@elstar.local> <005001cb4932$adde2380$6801a8c0@oemcomputer> <20100831211109.GA86737@elstar.local> Date: Tue, 31 Aug 2010 19:09:24 -0400 Message-ID: <5EDBDF3B5E4143BBBE5A69E231096DA8@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100831211109.GA86737@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: ActJURjzNi+R3waORuafu6yZrDT/pwAEG4aw Cc: isms@ietf.org Subject: Re: [Isms] tmSessionID (was: js review ofdraft-ietf-isms-radius-vacm-10 changes) 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: Tue, 31 Aug 2010 23:09:45 -0000 I think that is fine. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, August 31, 2010 5:11 PM > To: David Harrington > Cc: 'Randy Presuhn'; isms@ietf.org > Subject: Re: [Isms] tmSessionID (was: js review > ofdraft-ietf-isms-radius-vacm-10 changes) > > On Tue, Aug 31, 2010 at 10:23:15PM +0200, David Harrington wrote: > > Hi, > > > > RFC5590 defines the tmSessionID. It defines it without many > > constraints because the content is model-specific. > > o tmSessionID: in order to verify whether the session > has changed, > > the Transport Model must be able to compare the > session used to > > receive the original request with the one to be used > to send the > > response. This typically needs some form of session > identifier. > > This value is only ever used by the Transport Model, so the > > format > > and interpretation of this field are model-specific and > > implementation-dependent. > > > > RFC5592 defines the SSHTM model-specific constraints. > > tmSessionID = an implementation-dependent value > that can be > > used to detect when a session has closed and been > replaced > > by > > another session. The value in tmStateReference MUST > > uniquely > > identify the session over which the message was received. > > This session identifier MUST NOT be reused until > there are > > no > > references to it remaining. > > > > It might make sense for most models to use the same > constraints, but > > it is not a requirement to do so. If somebody defines a model where > > tmSessionID is not necessarly unique, that would be legal. > And neither > > RFC5590 nor RFC5592 mandates uniqueness across all > transport models, > > only within the SSHTM model. > > > > If the current doc references tmSessionID as a worthy candidate for > > vacmAaaSessionID, it should be pointed out that the scope of > > uniqueness between tmSessionID and vacmAaaSessionID might > differ, and > > the implementation might need to address that problem if it > supports > > multiple concurrent transport models. > > Here is the text: > > DESCRIPTION "An implementation-dependent identifier of > the session. > > This value MUST be unique among all currently open > sessions of all of this SNMP engine's > transport models. > The value has no particular significance > other than to > distinguish sessions. > > Implementations in which tmSessionID has a compatible > syntax and is unique across all transport models MAY > use that value." > > Do you think there is anything wrong with it? > > Do you think it requires a reference to RFC 5592? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Tue Aug 31 16:30:42 2010 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 26C773A6858 for ; Tue, 31 Aug 2010 16:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 glVXVbOdn5FF for ; Tue, 31 Aug 2010 16:30:41 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id D88363A6814 for ; Tue, 31 Aug 2010 16:30:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=i1mVTHkmPD19uW6QsMZlHj7xXTTsqgGLBNAmUBhXp2t6NzFN+ZxSbkcgsiDFFFFm; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.51.81] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqaIJ-0005pT-26 for isms@ietf.org; Tue, 31 Aug 2010 19:31:11 -0400 Message-ID: <000c01cb4964$a0dd3540$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100831075454.GB80776@elstar.local> <005001cb4932$adde2380$6801a8c0@oemcomputer> <20100831211109.GA86737@elstar.local> <5EDBDF3B5E4143BBBE5A69E231096DA8@23FX1C1> Date: Tue, 31 Aug 2010 16:31:23 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fef50d62c673e26fd21d29b2e5453a9653350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.51.81 Subject: Re: [Isms] tmSessionID (was: js review ofdraft-ietf-isms-radius-vacm-10 changes) 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: Tue, 31 Aug 2010 23:30:42 -0000 Hi - Ok, so it sounds like there is mostly agreement to > OLD > > REFERENCE "The abstract service interface parameter tmSessionID > is defined in RFC 5590 section 5.2.4 and RFC 5592 > section 4.1.2" > > NEW > > REFERENCE "The abstract service interface parameter tmSessionID > is defined in RFC 5590 section 5.2.4." > I'll apply this edit. This will have two side-effects: - remove 5592 from the list of RFCs needed for REFERENCE clauses - move 5592 from the list of normative references to the list of informative ones Randy From randy_presuhn@mindspring.com Tue Aug 31 16:41:30 2010 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 722CF3A6852 for ; Tue, 31 Aug 2010 16:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 SMx5Y6MjXBA2 for ; Tue, 31 Aug 2010 16:41:29 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 8A07E3A6814 for ; Tue, 31 Aug 2010 16:41:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=URH2wv4SLYSPoFVS/l+OMgBId+h21f85YgnIhefWzAXDVpvsrkFNikFFZwOH53AZ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.51.81] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OqaSl-0007CQ-RF for isms@ietf.org; Tue, 31 Aug 2010 19:42:00 -0400 Message-ID: <002001cb4966$249dbc00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100831075454.GB80776@elstar.local><20100831083203.GC80776@elstar.local><20100831133216.GC83821@elstar.local><008d01cb4938$dc1a52e0$6801a8c0@oemcomputer> <20100831164913.59e1514b@sparta.com> Date: Tue, 31 Aug 2010 16:42:14 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe99ad1a50ec5a31f78ec314cc599a105e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.51.81 Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes 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: Tue, 31 Aug 2010 23:41:30 -0000 Hi - Based on the discussion so far, I sense a *slight* collective preference for > OLD > > VACM-AAA-MIB DEFINITIONS ::= BEGIN > > NEW > > SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN I'll apply this change. Randy