From bgmp-admin@catarina.usc.edu Wed May 1 08:12:56 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23916 for ; Wed, 1 May 2002 08:12:56 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g41CCS425201 for ; Wed, 1 May 2002 05:12:28 -0700 (PDT) (envelope-from bgmp-admin@catarina.usc.edu) Date: Wed, 1 May 2002 05:12:28 -0700 (PDT) Message-Id: <200205011212.g41CCS425201@catarina.usc.edu> Subject: catarina.usc.edu mailing list memberships reminder From: mailman-owner@catarina.usc.edu To: malloc-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: bgmp-admin@catarina.usc.edu Errors-To: bgmp-admin@catarina.usc.edu X-BeenThere: bgmp@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your catarina.usc.edu mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, malloc-request@catarina.usc.edu) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@catarina.usc.edu. Thanks! Passwords for malloc-archive@lists.ietf.org: List Password // URL ---- -------- malloc@catarina.usc.edu kukaen http://catarina.usc.edu/mailman/options/malloc/malloc-archive%40lists.ietf.org From malloc-admin@catarina.usc.edu Wed May 15 22:27:51 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29804 for ; Wed, 15 May 2002 22:27:51 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4G2R6414021; Wed, 15 May 2002 19:27:06 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4G2QT414000 for ; Wed, 15 May 2002 19:26:29 -0700 (PDT) (envelope-from dthaler@windows.microsoft.com) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 15 May 2002 19:26:24 -0700 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 15 May 2002 19:26:23 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 15 May 2002 19:26:23 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 15 May 2002 19:26:23 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 15 May 2002 19:26:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840A2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: MALLOC MIB Thread-Index: AcH8gQma1nYh1P4CQ3uyuAWF+yd07g== From: "Dave Thaler" To: X-OriginalArrivalTime: 16 May 2002 02:26:10.0021 (UTC) FILETIME=[0A7FC150:01C1FC81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id g4G2QT414000 Subject: [malloc] MALLOC MIB Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 May 2002 19:26:09 -0700 Content-Transfer-Encoding: 8bit I have addressed all but one of the comments of the "MIB doctor", and the last comment made me think a bit. We have an "exclusion" table in the MIB right now, that I believe originated from AAP. I'd like to propose removing the table. As far as I can tell, nothing in the MALLOC architecture (RFC 2908) or the MADCAP protocol (RFC 2730) requires implementing any such concept, and those are what this MIB instruments. As a reminder, the MIB currently contains 3 tables that are relevant to this question: Scope Table : contains the scope ranges known (e.g. Global, LinkLocal, IPv4 Local Scope, etc.) Allocation Range Table : contains the subranges legal to allocate from (e.g. the piece of LinkLocal Erik Guttman asked IANA for, all of IPv4 Local Scope except the scope-relative addresses, your own GLOP range, etc). Exclusion Table : "contains sub-ranges which are excluded from being allocated". The wording implies these are subranges of the scope, disjoint from subranges in the allocation range table. The description also used to say entries may be dynamically discovered via some protocol such as AAP (which we already removed from the MIB). I believe that the Exclusion Table should have been removed when AAP was removed, and that for today's uses, exclusions are unnecessary (since the Allocation Ranges are manually configured without needing to have a concept of exclusions, or are acquired as part of experimental protocols outside the scope of this MIB). Any objections? (Positive acknowledgements from any of Mark, Steve, and Pavlin would be greatly appreciated :) -Dave _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Thu May 16 14:23:59 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05202 for ; Thu, 16 May 2002 14:23:59 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GINE427415; Thu, 16 May 2002 11:23:14 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GHMS426564 for ; Thu, 16 May 2002 10:22:28 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.11.6/8.11.3) with ESMTP id g4GHMH309053; Thu, 16 May 2002 10:22:18 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200205161722.g4GHMH309053@possum.icir.org> To: "Dave Thaler" cc: malloc@catarina.usc.edu Subject: Re: [malloc] MALLOC MIB In-Reply-To: Message from "Dave Thaler" of "Wed, 15 May 2002 19:26:09 PDT." <2E33960095B58E40A4D3345AB9F65EC1073840A2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> From: Pavlin Radoslavov Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 16 May 2002 10:22:17 -0700 > I have addressed all but one of the comments of the "MIB > doctor", and the last comment made me think a bit. > We have an "exclusion" table in the MIB right now, that > I believe originated from AAP. I'd like to propose removing > the table. > > As far as I can tell, nothing in the MALLOC architecture > (RFC 2908) or the MADCAP protocol (RFC 2730) requires > implementing any such concept, and those are what this MIB > instruments. > > As a reminder, the MIB currently contains 3 tables that are > relevant to this question: > Scope Table : contains the scope ranges known (e.g. > Global, LinkLocal, IPv4 Local Scope, etc.) > Allocation Range Table : contains the subranges legal > to allocate from (e.g. the piece of LinkLocal > Erik Guttman asked IANA for, all of IPv4 Local > Scope except the scope-relative addresses, > your own GLOP range, etc). > Exclusion Table : "contains sub-ranges which are excluded > from being allocated". The wording implies > these are subranges of the scope, disjoint > from subranges in the allocation range table. > The description also used to say entries may > be dynamically discovered via some protocol > such as AAP (which we already removed from the > MIB). > > I believe that the Exclusion Table should have been removed > when AAP was removed, and that for today's uses, exclusions > are unnecessary (since the Allocation Ranges are manually > configured without needing to have a concept of exclusions, > or are acquired as part of experimental protocols outside > the scope of this MIB). > > Any objections? (Positive acknowledgements from any of > Mark, Steve, and Pavlin would be greatly appreciated :) It seems to me that the allocatable address ranges can be expressed only by the information in the "Allocation Range Table" instead of (AllocRangeTable - ExclTable). If we have both AllocRangeTable and ExclTable, it may be easier for practical purpose to express the allocatable range(s); it may also make simpler the interfacing with protocols/mechanisms that originate/create those ranges (I guess the simplicity of such interface was probably the primary motivation to have the ExclTable added to the MIB). However, my guess is that the MIB doesn't have to deal with such practical issues. Further, having ExclTable adds the complexity that anyone who reads the MIB MUST take into account the ExclTable as well to figure-out the address ranges that are valid for allocation. Now that the AAP has been removed, I don't see a reason to keep the Exclusion Table, so removing it is fine with me. Pavlin P.S. FWIW, MASC doesn't have the equivalent of excluding sub-ranges. _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Thu May 16 14:25:42 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05276 for ; Thu, 16 May 2002 14:25:42 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GIPB427469; Thu, 16 May 2002 11:25:11 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GHdH426787 for ; Thu, 16 May 2002 10:39:17 -0700 (PDT) (envelope-from steve.hanna@sun.com) Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17262; Thu, 16 May 2002 11:39:16 -0600 (MDT) Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id NAA06905; Thu, 16 May 2002 13:39:14 -0400 (EDT) Message-ID: <3CE3EDFF.8ADA4D13@sun.com> From: Steve Hanna X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: malloc@catarina.usc.edu Subject: Re: [malloc] MALLOC MIB References: <2E33960095B58E40A4D3345AB9F65EC1073840A2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 16 May 2002 13:35:59 -0400 Content-Transfer-Encoding: 7bit If people use some protocol or technique to coordinate the efforts of several MAAS's allocating from a single address range, each MAAS will need to exclude addresses allocated by the other MAAS's (and maybe some addresses reserved for future allocations by the other MAAS's). This could be done by dividing each allocation range into several allocation ranges and ensuring that each MAAS only knows about one of these. But this will prevent the ability for a MAAS to report (via the Allocation Range Table) on the overall status of an allocation range: how full is scope X? and are requests being met? Instead, the status will be fragmented into separate allocation ranges for each MAAS. If the MAAS's aren't communicating, then this is probably the best thing to do. But if they are communicating (through a directory, an experimental protocol, or whatever), then I think we want to retain the ability for a MAAS to say "I'm allocating out of this range, but excluding these subranges." So I think we should leave the Exclusion table in the MIB. People who don't use it can always leave it empty. I welcome any further discussion, though. Thanks, Steve Dave Thaler wrote: > > I have addressed all but one of the comments of the "MIB > doctor", and the last comment made me think a bit. > We have an "exclusion" table in the MIB right now, that > I believe originated from AAP. I'd like to propose removing > the table. > > As far as I can tell, nothing in the MALLOC architecture > (RFC 2908) or the MADCAP protocol (RFC 2730) requires > implementing any such concept, and those are what this MIB > instruments. > > As a reminder, the MIB currently contains 3 tables that are > relevant to this question: > Scope Table : contains the scope ranges known (e.g. > Global, LinkLocal, IPv4 Local Scope, etc.) > Allocation Range Table : contains the subranges legal > to allocate from (e.g. the piece of LinkLocal > Erik Guttman asked IANA for, all of IPv4 Local > Scope except the scope-relative addresses, > your own GLOP range, etc). > Exclusion Table : "contains sub-ranges which are excluded > from being allocated". The wording implies > these are subranges of the scope, disjoint > from subranges in the allocation range table. > The description also used to say entries may > be dynamically discovered via some protocol > such as AAP (which we already removed from the > MIB). > > I believe that the Exclusion Table should have been removed > when AAP was removed, and that for today's uses, exclusions > are unnecessary (since the Allocation Ranges are manually > configured without needing to have a concept of exclusions, > or are acquired as part of experimental protocols outside > the scope of this MIB). > > Any objections? (Positive acknowledgements from any of > Mark, Steve, and Pavlin would be greatly appreciated :) > > -Dave > _______________________________________________ > malloc mailing list > malloc@catarina.usc.edu > http://catarina.usc.edu/mailman/listinfo/malloc _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Thu May 16 18:25:05 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12361 for ; Thu, 16 May 2002 18:25:05 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GMO5430741; Thu, 16 May 2002 15:24:05 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GMNm430728 for ; Thu, 16 May 2002 15:23:48 -0700 (PDT) (envelope-from dthaler@windows.microsoft.com) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 16 May 2002 15:23:40 -0700 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 May 2002 15:23:40 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 16 May 2002 15:23:40 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 16 May 2002 15:23:39 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 16 May 2002 15:23:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [malloc] MALLOC MIB Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840A9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [malloc] MALLOC MIB Thread-Index: AcH9AJv85edS1DOeS/Suu1P7CWMyJwAJq0iA From: "Dave Thaler" To: "Steve Hanna" Cc: X-OriginalArrivalTime: 16 May 2002 22:23:39.0739 (UTC) FILETIME=[5444AAB0:01C1FD28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id g4GMNm430728 Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 16 May 2002 15:23:39 -0700 Content-Transfer-Encoding: 8bit Steve Hanna wrote: > If people use some protocol or technique to coordinate the > efforts of several MAAS's allocating from a single address > range, each MAAS will need to exclude addresses allocated > by the other MAAS's (and maybe some addresses reserved for > future allocations by the other MAAS's). > > This could be done by dividing each allocation range into > several allocation ranges and ensuring that each MAAS only > knows about one of these. But this will prevent the ability > for a MAAS to report (via the Allocation Range Table) on > the overall status of an allocation range: how full is > scope X? and are requests being met? Instead, the status > will be fragmented into separate allocation ranges for > each MAAS. If the MAAS's aren't communicating, then this is > probably the best thing to do. Agree. > But if they are communicating > (through a directory, an experimental protocol, or whatever), > then I think we want to retain the ability for a MAAS to say > "I'm allocating out of this range, but excluding these > subranges." The semantics of the existing AllocRange table (and counters) are currently specific to a single MAAS. So ranges listed are ranges in which the device is itself allocating from. Without the exclusion table, a MAAS can say "I'm allocating out of this scope, but excluding all subranges that aren't in the AllocRange table." which sounds pretty close to what you said except that it does not report the overall status of an allocation range. > So I think we should leave the Exclusion table in the MIB. > People who don't use it can always leave it empty. I welcome > any further discussion, though. The argument for removing it is that without an experimental/ proprietary protocol, there is no use for the exclusion table. With an experimental/proprietary method, you already have experimental/proprietary stuff so it seems reasonable to get "overall status" the same way. (E.g. from a directory you mention, or from a MIB specific to the experimental protocol, or whatever). Hence, I'd still like to remove it. Do you have a strong objection to doing this? -Dave _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Thu May 16 19:10:02 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13503 for ; Thu, 16 May 2002 19:10:02 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GN92431371; Thu, 16 May 2002 16:09:02 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4GN8G431356 for ; Thu, 16 May 2002 16:08:16 -0700 (PDT) (envelope-from bkhabs@nc.rr.com) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 16 May 2002 19:08:03 -0400 Message-ID: <3CE43B20.FC61F8E1@nc.rr.com> From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: Steve Hanna , malloc@catarina.usc.edu Subject: Re: [malloc] MALLOC MIB References: <2E33960095B58E40A4D3345AB9F65EC1073840A9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 16 May 2002 19:05:04 -0400 Content-Transfer-Encoding: 7bit Dave Thaler wrote: > The argument for removing it is that without an experimental/ > proprietary protocol, there is no use for the exclusion table. > With an experimental/proprietary method, you already have > experimental/proprietary stuff so it seems reasonable to > get "overall status" the same way. (E.g. from a directory > you mention, or from a MIB specific to the experimental > protocol, or whatever). Dave, I agree with you. Whenever someone comes up with a new protocol, they can define the ways to get the information out of it. So, I vote to remove the exclusion table. Brian _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Fri May 17 17:03:49 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04942 for ; Fri, 17 May 2002 17:03:48 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4HL37c06871; Fri, 17 May 2002 14:03:08 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4HDN8c02850 for ; Fri, 17 May 2002 06:23:08 -0700 (PDT) (envelope-from steve.hanna@sun.com) Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01197; Fri, 17 May 2002 07:23:41 -0600 (MDT) Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id JAA12740; Fri, 17 May 2002 09:23:08 -0400 (EDT) Message-ID: <3CE50377.90DBCB49@sun.com> From: Steve Hanna X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: malloc@catarina.usc.edu Subject: Re: [malloc] MALLOC MIB References: <2E33960095B58E40A4D3345AB9F65EC1073840A9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 09:19:51 -0400 Content-Transfer-Encoding: 7bit Yes, I guess you could always define a MIB or other management technique to go along with any mechanism for coordinating multiple MAAS's. OK, I'm convinced. I agree that you should remove the exclusion table from the MIB. -Steve Dave Thaler wrote: > > Steve Hanna wrote: > > If people use some protocol or technique to coordinate the > > efforts of several MAAS's allocating from a single address > > range, each MAAS will need to exclude addresses allocated > > by the other MAAS's (and maybe some addresses reserved for > > future allocations by the other MAAS's). > > > > This could be done by dividing each allocation range into > > several allocation ranges and ensuring that each MAAS only > > knows about one of these. But this will prevent the ability > > for a MAAS to report (via the Allocation Range Table) on > > the overall status of an allocation range: how full is > > scope X? and are requests being met? Instead, the status > > will be fragmented into separate allocation ranges for > > each MAAS. If the MAAS's aren't communicating, then this is > > probably the best thing to do. > > Agree. > > > But if they are communicating > > (through a directory, an experimental protocol, or whatever), > > then I think we want to retain the ability for a MAAS to say > > "I'm allocating out of this range, but excluding these > > subranges." > > The semantics of the existing AllocRange table (and counters) > are currently specific to a single MAAS. > So ranges listed are ranges in which the device is itself > allocating from. > Without the exclusion table, a MAAS can say > "I'm allocating out of this scope, but excluding all subranges > that aren't in the AllocRange table." > which sounds pretty close to what you said except that > it does not report the overall status of an allocation range. > > > So I think we should leave the Exclusion table in the MIB. > > People who don't use it can always leave it empty. I welcome > > any further discussion, though. > > The argument for removing it is that without an experimental/ > proprietary protocol, there is no use for the exclusion table. > With an experimental/proprietary method, you already have > experimental/proprietary stuff so it seems reasonable to > get "overall status" the same way. (E.g. from a directory > you mention, or from a MIB specific to the experimental > protocol, or whatever). > > Hence, I'd still like to remove it. > Do you have a strong objection to doing this? > > -Dave _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Fri May 17 17:05:59 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05137 for ; Fri, 17 May 2002 17:05:58 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4HL5Mc06957; Fri, 17 May 2002 14:05:22 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4HItAc05589 for ; Fri, 17 May 2002 11:55:10 -0700 (PDT) (envelope-from dthaler@windows.microsoft.com) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 17 May 2002 11:55:07 -0700 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 May 2002 11:55:07 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 17 May 2002 11:55:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 17 May 2002 11:55:06 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 17 May 2002 11:55:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840AD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Submitted MALLOC MIB -06 Thread-Index: AcHxfJ/64xmMtacATR+xAlq4uxeNOAMVdsqA From: "Dave Thaler" To: , , Cc: "C. M. Heard" , "Frank Strauss" , , , "Bill Fenner" , X-OriginalArrivalTime: 17 May 2002 18:55:06.0157 (UTC) FILETIME=[5C0155D0:01C1FDD4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id g4HItAc05589 Subject: [malloc] Submitted MALLOC MIB -06 Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 17 May 2002 11:55:04 -0700 Content-Transfer-Encoding: 8bit I just submitted draft -06. Until it appears in the repository, it can be found on the MALLOC site at http://www.icir.org/malloc/draft-ietf-malloc-malloc-mib-06.txt Detailed responses to MIB doctor review comments below. -Dave ---------- 1) Frank Strauss: > ./MALLOC-MIB:169: use Integer32 instead of INTEGER in SMIv2 > ./MALLOC-MIB:987: use Integer32 instead of INTEGER in SMIv2 > > This is just a suggestion, not a MUST. It affects mallocScopeHopLimit > and madcapConfigResponseCacheInterval. Bert Wijnen: > - For integer-valued objects, if the value range is > between 0..2147483647 (inclusive) then: > - we prefer to use Unsigned32 Changed to Unsigned32. 2) Frank Strauss (also Mike Heard): > ./MALLOC-MIB:11: identifier `NOTIFICATION-TYPE' imported from module > `SNMPv2-SMI' is never used > ./MALLOC-MIB:14: identifier `DisplayString' imported from module `SNMPv2- > TC' is never used > ./MALLOC-MIB:15: identifier `TEXTUAL-CONVENTION' imported from module > `SNMPv2-TC' is never used > ./MALLOC-MIB:18: identifier `NOTIFICATION-GROUP' imported from module > `SNMPv2-CONF' is never used > > These macros and type should be removed from the IMPORTS statement. > However, this is again not a syntacical MUST. Done. 3) Frank Strauss: > there are different email addresses in the document's Author > Section and in the MIB's CONTACT-INFO, just in case one of them is > not valid. Done. 4) Mike Heard: > Security Considerations -- References to "RFC 2274 [12]" and > "RFC 2275 [15]" need to be changed to "RFC 2574 [RFC2574]" and > "RFC 2575 [RFC2575]", respectively. Done. 5) Mike Heard: > IPR Notices -- The notices required by RFC 2026 > Section 10.4 (A) and (B) are MISSING and need to be added. Done. 6) Mike Heard: > Copyrights -- There are two typos in the Full > Copyright Statement. (Note that these typos were present in > RFC 2026 Section 10.4 (C) but have been corrected in RFC 2223 > Section 11.) Done. 7) Mike Heard: > References -- authors for RFC 2571 are listed > in the wrong order. Fixed. The wrong order was copied from rfc-index.txt, which still contains the wrong order. 8) Mike Heard: > E: f(malloc~1.mi2), (610,18) Index item "mallocRequestId" must be > defined with syntax that includes a range [...] > The smicng warning about the index item mallocRequestId defined > with a syntax that does not includes a range concerns an object > whose syntax is Unsigned32. In this case all of the possible > values from 0 to 4294967295 inclusive are allowable index values. > As long as the MIB module author agrees that zero is a valid index > value for this table, then no correction is needed. However, if > the author intended to disallow zero-valued indices for > mallocRequestEntry, as is usually done, then the SYNTAX for should > be changed to include a range. In either case the DESCRIPTION > clause should be changed to say "arbitrary value" instead of > "arbitrary integer". [...] > + -- REVIEWER's note: suggest that the words "arbitrary > + -- integer" be changed to "arbitrary value" (integers > + -- are usually signed) Added range (1..4294967295). Changed "integer" to "value" since I really don't care either way. 9) Mike Heard: (comments about apparent conflicts between the MALLOC MIB and the draft -05 update to RFC 2851) Draft -05 of the 2851 update was in error. The specific cases in the MALLOC MIB had been previously discussed with the authors of that draft and they agreed that they would update that draft. Indeed, these changes have since appeared in draft -06, which is now RFC 3291. In fact, an earlier draft of the MALLOC MIB was in fact conformant to draft -05, and the changes were made in part as a result of pointing out how bad it looked. To respond to > + -- This may not be necessary if the the usage rules in > + -- are relaxed; > + -- in that case, it is suggested that the DESCRIPTION > + -- clauses for mallocAllocRangeFirstAddress and > + -- mallocAllocRangeLastAddress state that > + -- mallocScopeAddressType is the type discriminator. Draft -06 of the 2851 update implies this is a MUST as well, even if the suggestions therein are followed (which the MALLOC MIB does). Updated all relevant DESCRIPTION clauses as a result of the new "must", to make it explicit which object is the type discriminator. 10) Mike Heard: > the xyzFirstAddress objects in the mallocScopeTable, > mallocAllocRangeTable, and mallocScopeExclusionTable all have > size restrictions but the corresponding xyzLastAddress objects > don't. Unless the two endpoints of an address range can > legitimately have difference sizes, please put the same size > restrictions on both. Done. It was previously the way it way since xyzFirstAddress is in the INDEX and hence had to have it, whereas xyzLastAddress didn't. 11) Mike Heard: > mallocScopeFirstAddress OBJECT-TYPE > SYNTAX InetAddress (SIZE(4..20)) > + -- REVIEWER's note: beware that this SIZE restriction cannot be > + -- changed in future revisions of this MIB module. That's OK if > + -- you are sure that SIZE(4..20) will not prevent you from doing > + -- something later that you want to be able to do. It is understood and is okay. No change. 12) Mike Heard: > + -- REVIEWER's note: Presumably, deleting a scope which _is_ divisible > + -- has the side effect of deleting the corresponding entries in the > + -- mallocAllocRangeTable and in the mallocScopeExclusionTable. If that > + -- is true, please say so in the DESCRIPTION clause above. Agree. Updated DESCRIPTION clause of mallocScopeDivisible. Also done for similar issue of deleting an entry in the mallocRangeTable having the side effect of deleting corresponding entries in the mallocAddressTable. 13) Mike Heard: > mallocScopeNameLangName OBJECT-TYPE > SYNTAX LanguageTag (SIZE(1..92)) > + -- REVIEWER's note: if I have counted correctly, this restriction > + -- results in a maximum OID length of 126 sub-identifiers for the > + -- accessible object instances in this table. OK if that's as intended. Actually I count 125, am I missing something? mib-2 = 6 subids (.1.3.6.1.2.1) malloc = 9 subids (mib-2.mallocMIB.mallocMIBObjects.1) mallocScopeNameLangName = 12 (malloc.ScopeNameTable.mallocScopeNameEntry.1) The INDEX contains mallocScopeAddressType : 1 mallocScopeFirstAddress : 20 max mallocScopeNameLangName : 92 max --- 125 I think this was left over from when the root was under something other than mib-2 and hence the oid was longer. Changed 92 to 95. 14) Mike Heard: > mallocAllocRangeTable OBJECT-TYPE [...] > + -- REVIEWER's note: please add some text in the above DESCRIPTION > + -- clause stating that address ranges for different rows must be > + -- disjoint, must not overlap with address ranges covered by rows > + -- in the mallocScopeExclusionTable, and must be contained within > + -- the address range of the corresponding row of the mallocScopeTable. [...] > mallocScopeExclusionTable OBJECT-TYPE > + -- REVIEWER's note: please add some text in the above DESCRIPTION > + -- clause stating that address ranges for different rows must be > + -- disjoint and must not overlap with address ranges covered by rows > + -- in the mallocAllocRangeTable, and must be contained within the > + -- address range of the corresponding row of the mallocScopeTable. > + -- Also, please state either that there are no rows in this table > + -- corresponding to indivisible scopes or else state what an excluded > + -- range signifies in that case. Done. Updated with text almost verbatim from above. 15) Mike Heard: > DESCRIPTION [...] > + -- REVIEWER's note: it might be better style for values such as > "allocated", > + -- "offered", etc. to be written as "allocated(1)", "offered(2), etc. Done. 16) Mike Heard: > mallocRequestClientAddressType OBJECT-TYPE [...] > "The type of the address of the client to which this > allocation was (last) granted." > + -- REVIEWER's note: the description suggests to me that this object > + -- applies only after an allocation is final, i.e., only after the > + -- request state transitions to allocated(1). If that's not what is > + -- intended, then perhaps the text should read "The type of the address > + -- of the client that (last) requested this allocation." (and same for mallocRequestClientAddress) Accepted proposed replacement text. 17) Mike Heard: > mallocClientGroup OBJECT-GROUP [...] > "The basic collection of objects providing management of IP > multicast address allocation." > + -- REVIEWER's note: this is a verbatim copy of the mallocBasicGroup > + -- description. I think what was intended was someting like this: > + -- "A collection of objects providing management of multicast > + -- address allocation in clients." [...] > mallocClientScopeGroup OBJECT-GROUP [...] > "A collection of objects providing management of multicast > scope information." > + -- REVIEWER's note: should be "... scope information in clients." Right. Changed as suggested. 18) Bert Wijnen: > - The MODULE-IDENTITY macro has a CONTACT-INFORMATION clause > that now lists the author. These days, we prefer to also list > the WG chair(s) and the mailing list and archive information. > That way, it is easier for people to locate people and or > discussions about the MIB. You can take RFC2571 as an example. Done. (RFC2571 doesn't list the archive information, but I added it anyway.) 19) Bert Wijnen: > - The MODULE-IDENTITY macro has a revision clause: > > REVISION "200111051200Z" -- November 5, 2001 > DESCRIPTION > "Initial version." > Where I would prefer to see: > > -- revision log > > REVISION "200111051200Z" -- November 5, 2001 > DESCRIPTION > "Initial version, published as RFC xxxx." > -- RFC-Editor assigns xxxx > > Please also add a revision clause to the ianaMallocMIB Done. 20) Bert Wijnen: > - I see the use of IMPLIED. As you may know, in the SMIng WG, the > consensus seems to be that IMPLIED was a bad idea. There is > the feeling that we should deprecate or obsolete the use of > the IMPLIED keyword. So maybe you want to consider to not use > it...!! I do understand the sorting issue. Not sure how > important the sorting issue is. The sorting issue is that with IMPLIED, strings appear in alphabetical order, which is how humans expect things to look. Without IMPLIED, strings appear in order by length, and then alphabetically within a given length. I don't understand why it's a bad idea. No change, since you didn't seem adamant about it. 21) Bert Wijnen: > - Pointer to RFC 1766 probably should be changed to reference > to RFC 3066 (which obsoletes 1766). WOuld it be good to add > a reference too? I understand that the RFC2932 (from whihc > you import the LanguageTag TC) was before 3066 and so it uses > 1766. But that should be updated next time around too!. > Or maybe you just do not refer to 1766, since the TC in RFC > 2932 already refers to it? Changed mention of 1766 to 3066. Didn't add a REFERENCE, since it really belongs in the TC in 2932. 22) Bert Wijnen: > - I see that you want to limit the InetAddressType values > to IPv4, IPv6, IPv4z and IPv6z (or so I think to understand). > In that case, you MUST specify this in the compliance specs > (see for example draft-ietf-diffserv-mib-16.txt where they > do the same thing). Mike Heard: > Many of the InetAddressType items are inaccessible INDEX items. > SMIv2, unfortunately, does not allow those to be mentioned in > compliance statements, nor does > provide any guidance. Suggestions? Juergen Schoenwaelder: > Yep, this is very unfortunate. The best thing you can do is to > put text into a DESCRIPTION clause (and to hope that a future SMI > does not have this problem). Bert Wijnen: > So then it seems that the only place we can do it is in the > object definition itself (as is done with the size for firstaddress). > I guess we should then also subtype the InetAddressType in the > object definition. > > And as Juergen suggests, yes add something to the DESCRIPTION clause > as well. > > I wonder... if we get into this situation what we should do for the > second occurance of InetAddress, which is not an index item. Juergen? Juergen: > I think the implementation requirements wrt. > address types should be defined in the conformance statement and not > in the object type definition. So what I suggested was to add text > to a suitable DESCRIPTION clause in the conformance statement - not > in the DESCRIPTION clause of the object type (or even sub-typing in > the object type clause). Bill Fenner: > RFC 2851 discourages subtyping, since that closes the door for > evolution (e.g. something that subtyped RFC 2851's InetAddressType to > allow only ipv4(1) or ipv6(2) would not be able to use addresses with > associated zones (i.e. ipv4z(3) or ipv6z(4)) from > draft-ietf-ops-rfc2851-update-05 ). Bert: > So you are are suggesting to use DESCRIPTION clause > in CONFORMANCE statement instead of doing anything machine readable..... > > Well.. they have now define a size limit on an InetAddress object. > It is an INDEX object, so they must do that. They then used a size of > 4..20, so that is the IPv4, IPV6 and IPv4z and IPv6z types basically. > But no subtyping on the InetAddresType, which is also an INDEX object > just before the InetAddress INDEX object. Mike: > Actually, I think that Mr. Thaler has already this covered. Each > InetAddressType INDEX object includes the following proviso in its > DESCRIPTION clause: > > Legal values correspond to the subset of address families > for which multicast address allocation is supported. Bill: > The argument against subtyping in the object definition is also an > argument against SIZE(4..20), which is why I was suggesting simply > restricting to (0..N) where N is enough to ensure that the OID doesn't > get too long. Mike: > Right now one of the tables (the mallocScopeNameTable) only has two > sub-ids worth of headroom. If the SIZE restriction on the InetAddress > index components is relaxed, then mallocScopeNameLangName will need a > to have is SYNTAX changed from LanguageTag (SIZE(1..92)) to something > more restrictive. I would recomment against having different size > restrictions for different InetAddress index objects. Mike already answered this the same way I would have. The DESCRIPTION clauses already contain the statement Mike quotes, and there is no longer 2 sub-ids of headroom as mentioned earlier. 23) Bert Wijnen: > - I see that you specify a size limit of (4..20) for various > InetAddress type objects. I think you do so because they are > index objects, and RFC2851 (and also the revision that is > in Last Call now) tell you to do so in case you use it in > an index. But I wonder if the values 4..20 are the proper > values to use here. The 4..30 seems appropriate in the > compliance specs, but not in at the point where the objects > are being defined. Probably a better limit here would be > something like (0..32) or (0..64). I think this is explained > in the update to RFC2851. Since it's limited to IPv4, IPv6, IPv4z and IPv6z, 20 is indeed the max value, and it affects the max size of mallocScopeNameLangName as discussed under #13 above. The example in the update to 2851 also imposes a size restriction where the objects are being defined, and it uses 64 only because dns is legal in the example. No change. 24) Bert Wijnen: > - In the MODULE COMPLAINCEs part... > We have started to ask people to specify two sets of > compliances, that is if you want to allow for a read-only > implementation of the MIB. [...] > (see for example draft-ietf-diffserv-mib-16.txt where they > do the same thing). This sounds like a good idea. Done. 25) Bert Wijnen: > - You might want to split references in normative and informative > references. It is coming... and by the time this gets to IETF > Last Call.. it probably is needed/or seriously wanted. > See: http://www.rfc-editor.org/policy.html towards the bottom I think the official MIB boilerplate at http://www.ops.ietf.org/mib-boilerplate.html should be updated first, so the rest of us don't have to guess at what the correct breakdown is among those. I just checked and the latest RFC (the long awaited RFC 3291 Textual Conventions for Internet Network Addresses) does not split references, so no change yet. I can do so after the new boilerplate is agreed upon (during the 48 hour author check period if not before). 26) Bert Wijnen: > Any additions or changes to the contents of this MIB module > require either publication of an RFC, or Designated Expert > Review as defined in the Guidelines for Writing IANA > Considerations Section document. The Designated Expert will > be selected by the IESG Area Director(s) of the Transport > Area." > > "publication of an RFC" is the piece that bothers me a bit. It > allows for Informational, Experimental, April-1st RFCs to > be sufficient. I would rather see something like: > "publication of a standards track or BCP RFC" It is worded as the WG agreed (I believe the intent was to allow Experimental, etc., especially since AAP, if published, would be Experimental). If you're saying you or the IESG find that unacceptable, then I can change the text accordingly, since there's still the Designated Expert Review provision which could be used for such cases. 27) Bert Wijnen: > I do not see anything about the presistency of the MIB objects and > table entries. Either we need StorageType objects or we need to > describe in the table DESCRIPTION clauses what the persistency > characterisctics are. Added StorageType objects to all writable tables. 28) Dave Thaler: > Exclusion Table should have been removed when AAP was removed. Issue discussed on mailing list. Consensus was to remove it. Done. _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Sun May 19 13:34:44 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15010 for ; Sun, 19 May 2002 13:34:44 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4JHX3c34907; Sun, 19 May 2002 10:33:07 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4J2e3c26376 for ; Sat, 18 May 2002 19:40:04 -0700 (PDT) (envelope-from heard@pobox.com) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id TAA17306; Sat, 18 May 2002 19:39:59 -0700 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Dave Thaler cc: mankin@ISI.EDU, bwijnen@lucent.com, sob@harvard.edu, Frank Strauss , steve.hanna@sun.com, schoenw@ibr.cs.tu-bs.de, Bill Fenner , malloc@catarina.usc.edu In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1073840AD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [malloc] Re: Submitted MALLOC MIB -06 Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 18 May 2002 19:39:59 -0700 (PDT) On Fri, 17 May 2002, Dave Thaler wrote: > I just submitted draft -06. > > Until it appears in the repository, it can be found on the > MALLOC site at > http://www.icir.org/malloc/draft-ietf-malloc-malloc-mib-06.txt > > Detailed responses to MIB doctor review comments below. [ ... ] I believe that there is an error in the following response: > 13) Mike Heard: > > mallocScopeNameLangName OBJECT-TYPE > > SYNTAX LanguageTag (SIZE(1..92)) > > + -- REVIEWER's note: if I have counted correctly, this restriction > > + -- results in a maximum OID length of 126 sub-identifiers for the > > + -- accessible object instances in this table. OK if that's as > intended. > > Actually I count 125, am I missing something? > > mib-2 = 6 subids (.1.3.6.1.2.1) > malloc = 9 subids (mib-2.mallocMIB.mallocMIBObjects.1) > mallocScopeNameLangName = 12 > (malloc.ScopeNameTable.mallocScopeNameEntry.1) OK so far both by my count and that of smidump. > The INDEX contains > mallocScopeAddressType : 1 > mallocScopeFirstAddress : 20 max But I think that this should be 21, since the index component is a variable length OCTET STRING (and is not IMPLIED) ... > mallocScopeNameLangName : 92 max > --- > 125 ... so I come up with 126. > I think this was left over from when the root was under something other > than mib-2 and hence the oid was longer. > > Changed 92 to 95. I think this should be 94. Note that libsmi-0.3.1 complains that the index may overflow: % ./libsmi-0.3.1/tools/smilint -l 9 -s ./MALLOC-MIB |& grep -v '32 characters$' ./MALLOC-MIB:259: [5] index of row `mallocScopeNameEntry' can exceed OID size limit by 1 subidentifier(s) ./MALLOC-MIB:397: [5] `InetAddress' object should have an accompanied preceding `InetAdressType' object ./MALLOC-MIB:407: [5] `InetAddress' object should have an accompanied preceding `InetAdressType' object Mike _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc From malloc-admin@catarina.usc.edu Mon May 20 07:58:34 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08736 for ; Mon, 20 May 2002 07:58:33 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4KBv1c45880; Mon, 20 May 2002 04:57:02 -0700 (PDT) (envelope-from malloc-admin@catarina.usc.edu) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g4KBu2c45857 for ; Mon, 20 May 2002 04:56:06 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08586; Mon, 20 May 2002 07:56:09 -0400 (EDT) Message-Id: <200205201156.HAA08586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: malloc@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [malloc] I-D ACTION:draft-ietf-malloc-malloc-mib-06.txt Sender: malloc-admin@catarina.usc.edu Errors-To: malloc-admin@catarina.usc.edu X-BeenThere: malloc@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 20 May 2002 07:56:09 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast-Address Allocation Working Group of the IETF. Title : Multicast Address Allocation MIB Author(s) : D. Thaler Filename : draft-ietf-malloc-malloc-mib-06.txt Pages : 42 Date : 17-May-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-malloc-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-malloc-malloc-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-malloc-malloc-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020517151207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-malloc-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-malloc-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020517151207.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ malloc mailing list malloc@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/malloc