[Ips] RE: IPS Auth MIB 07 changes
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Thu, 03 November 2005 16:21 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhpl-0006oF-4q; Thu, 03 Nov 2005 11:21:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXhpj-0006oA-UC for ips@megatron.ietf.org; Thu, 03 Nov 2005 11:21:00 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10125 for <ips@ietf.org>; Thu, 3 Nov 2005 11:20:38 -0500 (EST)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXi4X-0001AV-2F for ips@ietf.org; Thu, 03 Nov 2005 11:36:19 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jA3GKMfL010464; Thu, 3 Nov 2005 10:20:22 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <SQW9C501>; Thu, 3 Nov 2005 17:20:20 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550872475A@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Mark Bakke <mbakke@cisco.com>, David Black <Black_David@emc.com>, David B Harrington <dbharrington@comcast.net>, Keith McCloghrie <kzm@cisco.com>, Jim Muchow <jamesdmuchow@yahoo.com>
Date: Thu, 03 Nov 2005 17:20:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: "Ipswg (E-mail)" <ips@ietf.org>
Subject: [Ips] RE: IPS Auth MIB 07 changes
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Sender: ips-bounces@ietf.org
Errors-To: ips-bounces@ietf.org
I will let David Harrington respond to your answers on his comments. After he responds I'll see what I think the total status is of MIB Doctor Review. I have comments on your answers to my earlier comments below. But first some other comments - Section 4 end of 1st para within the IPv4 [RFC2011] or IPv6 [RFC2465] MIB modules. RFC2011 has an 2011bis close to being Published (see RFC-Editor queue) and it obsoletes both 2011 and 2465. Maybe better to cite and reference draft-ietf-ipv6-rfc2011-update-10.txt - I would change: REVISION "200510180000Z" -- October 18, 2005 DESCRIPTION "Initial version of the IP Storage Authentication MIB module" into REVISION "200510180000Z" -- October 18, 2005 DESCRIPTION "Initial version of the IP Storage Authentication MIB module, published as RFCyyyy" -- RFC-Editor fill in yyyy - comments/qeustions about IpsAuthAddress In IpsAuthAddress TC I see reference to RFC2851, which has been obsoleted by RFC4001. I also wonder if it is clear for people how the address represented by the TC is being formatted. Why do you not do a IpsAuthAddressType TC in additoon to a IpsAuthAddress TC. The TeHopAddressType and TeHopAddress in RFC3811 are a good example how it can be done in a much cleaner manner than what you are doing. But maybe you only use AddressFamilyNumbers, because that seems to be the discriminator in the 2 cases where you use the TC. Mmm... I need to spend more time on this module/document. I don't have untill after the upcoming IETF. W.r.t. your answers on my earlier comments: > Comments from Bert Wijnen 2/1/2005 > > >So this is hwta I get: > > > > C:\bwijnen\smicng\work>smicng ipsauth.inc > > E: f(ipsauth.mi2), (53,7) Leading sub-Id "mib-2" is not known in > > current module > > W: f(ipsauth.mi2), (5,5) "experimental" imported but not used > > *** 1 error and 1 warning in parsing > > > > > Fixed. > Yep, thanks Compiles clean now. > >When I fix that, then it passes SYNTAX checking with SMIXng > >It also passes smilint syntax checking then. > >It also passes idnits checking. > > Syntax checking clean now. idnits checking clean now. > >I think I would change: > > > > ipsAuthDescriptors OBJECT IDENTIFIER ::= { ipsAuthObjects 1 } > > > > ipsAuthMethodTypes OBJECT IDENTIFIER ::= { ipsAuthDescriptors 1 } > > > > into something like: > > > > ipsAuthDescriptors OBJECT IDENTIFIER ::= { ipsAuthObjects 1 } > > > > ipsAuthMethodTypes OBJECT-IDENTITY > > STATUS current > > DESCRIPTION "Registration point for iSCSI Method Types". > > REFERENCE "iSCSI Protocol Specification." > > ::= { ipsAuthDescriptors 1 } > > > > It lets you say some more about what this is. > > Not a blocking comment though. > > > > > Done. > Thanks > >I see in DESCRIPTION of ipsAuthInstIndex (which is a > not-accessible index) > >that values do not need to be preserved over reboot. > >Does that also mean that ipsAuthInstDescr values do not need to be > >preserved over reboot? > > > > > Fixed *Index to recomment preserving across reboots. Also added > a StorageType to this row (same as for the Node in the iSCSI MIB) > to address the ipsAuthInstDescr values. > thanks > >A similar (not need to be preserved over reboot) is present for: > >ipsAuthIdentIndex, and yet there is a StorageType object in that > >table. So what if the StorageType syas "permanent" ?? > >Or what if it says "nonVolatile"? > > > > > Fixed. > thanks > >By the way, for a STorageType object you MUST specify which columns > >(or none) of the writable columns must be writable for permanent > >objects. > > > > > Fixed for ipsAuthInstDescr; all other objects are read-only > or read-create. > A read-create object is also a "writable" object. SO you must say it for those too. > >You also need to describe if any (writable) objects in row can > >be changed when the row is in "active" state. > > > > > Fixed for ipsAuthInstDescr; all other objects are read-only > or read-create. > A read-create object is also a "writable" object. SO you must say it for those too. > >This is all described in RFC2579 and in the mib-review-guidelines. > > > > Other Modifications: > > Changed "octet string" to "character string" in > SnmpAdminString object > descriptions. > > Updated references. > > Updated boilerplate text to match RFC 3978/3979. > > Moved Acknowledgements section to the end to match other RFCs. > Great Bert > -- > Mark > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
- [Ips] RE: IPS Auth MIB 07 changes Wijnen, Bert (Bert)