From owner-malloc@catarina.usc.edu Fri Nov 2 22:28:27 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24438 for ; Fri, 2 Nov 2001 22:28:27 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA97841 for malloc-list; Fri, 2 Nov 2001 19:05:50 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA97835 for ; Fri, 2 Nov 2001 19:05:49 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 18:39:48 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Nov 2001 19:05:18 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 19:05:18 -0800 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, 2 Nov 2001 19:05:10 -0800 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.3562.0); Fri, 2 Nov 2001 19:04:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [malloc] FW: [Malloc] RE: MALLOC MIB comments Date: Fri, 2 Nov 2001 19:04:23 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290EABC@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [Malloc] RE: MALLOC MIB comments thread-index: AcElCCR05wunqiAKRKqAfW6QVRdIOwExkewgDpFuOhA= From: "Dave Thaler" To: X-OriginalArrivalTime: 03 Nov 2001 03:04:23.0408 (UTC) FILETIME=[3D535700:01C16414] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id TAA97836 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Looks like the actions in response to Steve Hanna's comments were posted earlier. The changes indicated in the email below have been made. -Dave -----Original Message----- From: Dave Thaler Sent: Monday, August 20, 2001 4:31 PM To: Steve Hanna Cc: malloc@ietf.org Subject: [Malloc] RE: MALLOC MIB comments Steve, thanks for reviewing! > Comments on draft-ietf-malloc-mib-04.txt > > 1) Some objects seems to have incorrect MAX-ACCESS values. > This is more likely due to my misunderstanding of how > this value is used, but here are my concerns: > > mallocScopeFirstAddress and mallocScopeFirstAddressType > are marked as not-accessible. I think they should be > read-create, so that you can read their values and create > new entries in the Scope table (if allowed). Any objects that appear in the INDEX clause of the table are not-accessible, since one can read their values by reading any other object in the table, since their value comes back in the OID of the object read. Hence, the status is correct (but thanks for asking). > mallocAllocRangeFirstAddress and mallocAllocRangeFirstAddressType > are also marked as not-accessible. I would expect these > to be read-create. Same reason. > 2) The description of mallocAllocRangeAdvertisable says > "The default value is true if the scope is divisible, > and is false otherwise." What do you mean by default? If you create a new row in the table via SNMP and don't specify a value for this object. > Do you mean that some program will set the value > to these values unless overridden by a human being? Yes. > I suspect you just mean that most people will want to > set the value to true when the scope is divisible and > false otherwise. If that's what you mean, you should > say that. It's not what I meant. In MIBs, there's a DEFVAL clause that you can put in the default value to be used during row creation (it's just informative to humans, the clause isn't used by the management station to do anything differently). Here, we can't use a DEFVAL clause since there's not a single default value for all cases, and hence the DESCRIPTION specifies the default instead. > 3) The description of mallocAllocRangeTotalRequestedAddrs > says "The approximate number of addresses in the range > which there is potential demand for among MAASs, as > determined by a Prefix Coordinator." I think that would > be more grammatically correct if it read "The approximate > number of addresses in the range for which there is > potential demand among MAASs, as determined by a Prefix > Coordinator." Agree. > 4) In the mallocServerGroup, there are several objects > missing that I would expect to find there. > > mallocScopeFirstAddress and mallocScopeFirstAddressType > are missing, as are mallocAllocRangeFirstAddress and > mallocAllocRangeFirstAddressType and > mallocScopeExclusionFirstAddress and > mallocScopeExclusionFirstAddressType and > mallocScopeNameLangName. I suspect that these are not > errors, but due to some strange MIB feature that > automatically includes them because they're indexes > of their tables and other elements of the tables are > included in this group. I dunno. Yep, that's exactly right. Objects which are not-accessible don't appear in conformance groups. > mallocScopeLastAddressType is missing, but > mallocScopeLastAddress is there. I suspect that's an > error. I think you're right. Will fix. > 5) In the mallocClientScopeGroup, mallocScopeSSM seems to > be missing. Yep, will fix. > 6) The description of mallocPrefixCoordinatorGroup says > that it is a "collection of notifications". I think > it's just a "collection of objects". Isn't that right? Yep, will fix. > 7) In the IANA-MALLOC-MIB, IANAmallocRangeSource still > includes an aap value. I don't think that's needed, > since development of AAP has been abandoned. If it is > later resuscitated, we can always ask IANA to assign > an IANAmallocRangeSource value to it. Sounds reasonable. Thanks again! -Dave _______________________________________________ Malloc mailing list Malloc@ietf.org http://www1.ietf.org/mailman/listinfo/malloc From owner-malloc@catarina.usc.edu Fri Nov 2 22:28:27 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24439 for ; Fri, 2 Nov 2001 22:28:27 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA97848 for malloc-list; Fri, 2 Nov 2001 19:05:58 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA97838 for ; Fri, 2 Nov 2001 19:05:49 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 18:39:48 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Nov 2001 19:05:18 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 19:05:18 -0800 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, 2 Nov 2001 19:02:40 -0800 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.3562.0); Fri, 2 Nov 2001 19:01:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C16413.E3C9A9A0" Subject: [malloc] RE: FW: MALLOC MIB comments Date: Fri, 2 Nov 2001 19:01:53 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290EABB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-TNEF-Correlator: <2E33960095B58E40A4D3345AB9F65EC10290EABB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: FW: MALLOC MIB comments thread-index: AcEsl+qW9RuzC878Qt6+8e950MuyDA3e9Fqg From: "Dave Thaler" To: "Brian Haberman" Cc: X-OriginalArrivalTime: 03 Nov 2001 03:01:53.0440 (UTC) FILETIME=[E3F00A00:01C16413] Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C16413.E3C9A9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm acting on the last call comments received from Brian Haberman, Bill Fenner, and Steve Hanna. Here's the responses to Brian's comments. I'll include the other two in separate emails. > 1. The DESCRIPTION of mallocScopeDivisible seems to allow ranges > in the mallocScopeTable to be disjoint. If it is true, it means > that the entire range between the first and last address is not > usable? ACTION: None. Right. For example, the IPv6 global scope is divisible. The range of IPv6 unicast-prefix based addresses for each of your global IPv6 unicast addresses would be rows in the mallocAllocRangeTable. > 2. mallocScopeNameScopeName defines a default value for v4, but not > v6. Shouldn't the v6 default be, at a minimum, the generic scope > name defined in RFC 2373 (and its update)? ACTION: Changed as suggested. > 3. Should the DESCRIPTION of mallocAllocRangeLifetime mention where > that lifetime came from? In unicast-prefix based v6 mcast > addresses, the associated prefix lifetime from the RA should be > used as the maximum lifetime of that prefix. ACTION: None. The lifetime for unicast-prefix based mcast addresses is debatable, and I don't want this draft to be dependent on that rule (or any other rules specified by other mechanisms). > 4. I am confused on why the Request Table and the Address Table are > separate entities. It seems like it should be possible to use > the Request Table to represent the same info that is being put > in the Address Table. ACTION: None. No, the Request Table can contain entries for which no addresses are allocated, and hence cannot be represented in the Address Table. > 5. madcapTotalErrors gives a total error count which, I assume, is > the sum of the specific error counters. Would a total message > counter be useful as well (e.g. mapcapTotalMessage)? ACTION: None. Since this was just a question, not a justification, the default answer should be not to add such an object. The rationale for "no" is that it's trivially derivable from other objects if needed, and so there's no need to make agents implement it. -Dave ------_=_NextPart_001_01C16413.E3C9A9A0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjYDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAHAAAAFJFOiBGVzogTUFMTE9DIE1J QiBjb21tZW50cwAeCAEFgAMADgAAANEHCwACABMAAQA1AAUAMwEBIIADAA4AAADRBwsAAgATAAEA NQAFADMBAQmAAQAhAAAAMTc5NzJFMkJCMTA1OTc0MTgzNDNGN0FFOTM4ODJENjQAAQcBA5AGAMAL AAA0AAAACwACAAEAAAADACYAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAoKnJ4xNkwQEeAD0AAQAA AAUAAABSRTogAAAAAAIBRwABAAAAPAAAAGM9VVM7YT13aW5kb3dzO3A9TWljcm9zb2Z0O2w9V0lO LU1TRy0wMS0wMTExMDMwMzAxNTNaLTEzMDY2AB4AcAABAAAAGAAAAEZXOiBNQUxMT0MgTUlCIGNv bW1lbnRzAAIBcQABAAAAGwAAAAHBLJfqlvUbswvO/ELevvHvedDLsgwN3vRaoAAeABoMAQAAAAwA AABEYXZlIFRoYWxlcgAeAB0OAQAAABgAAABGVzogTUFMTE9DIE1JQiBjb21tZW50cwACAQkQAQAA AMoFAADGBQAAdQoAAExaRnUw8ya1AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP 8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREi DGBjAFAzCwkBZDM2FlALpiBJKCdtIADQdAuAZyBBAiAgdGhlIAtgc90FQGMHQAMgBaBtB4ACMEME IBggY2VpdgmAILcDUgqiCoBCByEDoEgBoGMEkAOBLCBCAxADIEa9CfBuBJAhUABwH7BTDrBnH5Ag wSHgYS4gFCAUSDkEkGUnBCAd0hggc3D3AiAUECRRbyFgIIIkQR623C4gHOEegQuAYwpAAQCbIBQd 0m8d0QXAdHclYC0LgCAUEAqxYQ6wIGWPAMADECZwI0o+IDEmgAJUHeFERVNDUkkgUFRJT04dkGYg IwDAHoBvY1MFoHBl9kQfgAQAaQJgHfAUEClw/yUzLDIH4CkgHXAHkCpGLzH3KLEd0iwpVAGgLUEl USDwpCBkBABqbwuAdCaC3SwAaQVABAAdwHIKUCFQ/zIxB4AAcS7JHdApMB3DHvF+aRggLlQxEShw CeEdw2aPNOAeMSJCHhNhZGQksZsEIDJhbigQLsl1czCi0j8jSkFDK6I6B7ACIEJlIztSaWdoMcJG 8wWxDsBhbQtQMsEd0iuA0HY2IGcXsGIHQCjQ/yySMlIxUCz1IzUq8jUkK/GdPRN1AwAeYB4wLXAY IP02QHgxEB4gH6E3NQeRAhDrPCEA0Ggr4nkIYSAUPWXnQDpBySiAdWwfsDEhA2DWdzeRL4pBLEJS LnIwk60p3TImgCwpTjxgZUnXrzFAQSEh8AQgYUryYUXQnQVAdgdAClBCY3Y0IVA8YnUFQDfsPTAm gVNo/0XCJcA0VD0xS6Yg8CIhNoHnLBALgAdwdW08tC6QIfF/DeA9xC7JIxBK1x+wKLFSBEZDSTAz NzMgKEciQjIwBCB1cGQpMSl7OS86MkMT4C6BQbEEIHOsdWcukQ6wZCndMyaA7050HcMrP0csTAaQ FCAHcXczETTBHaF3KDFSKjQjbO9b1h5gStEDUj8mkQOgQI/7QZI9MW1f0i7JQdc8tB4g7nMsYAcw V9EgQQVeJwNS+R3DUkEo0Fk0IPA4G1cU/S+keFDCXhgr8TQjQQQjO/85/yOGKvJkOAWxX69BkmEj +0HJPjJlPZABkTyRIBQiQu5JMUACIE7hdwBwNFI+Mv8pIAGAMOYo8AnwAQBxQR2jtzRBMqAtQSgF sQBweSgEfyAUc6JXUSywY1A2QB+hYq90VTMRE9EDAHMtoCkp3Z40JoBwoDxgHqFuZmbD51yjdFBl E2VxClAeMTCU+yJCHdJBN0V6lV0LKOg0wb8dUAeQJoIFQC10XiBrPhH3foFllmOwbwQQLSMlUWbB /zN7ef4lURggQQEUEHFDLVF/SsILgAIQNBQyYSDwHWJw/00QLs97bGl/ao8gMojgPLT/ehweYAOg eNEBkCixHvEIgf9CVFzQDeBC4DfgQchwBTTx/ywzY3IiJB3gJxCLMzfhRgOvgyZThIaPKd01SVJk HmDMcFQoEAdARXIDYBQA/z1QH4FLYiVQlCEpYJRiHqH/bOBxAYziIVB4gQQQUOAywv8zbC1RZ9Fo ky1RdZRRwJWp+wSQJnJXRcOVJgeBONAukP+FqZolMRJmwXkAAyBXQTWwVR6BKDqgZ0lScJPWTe+b xFVviJ8gI1MnATDRcYL7cSAEIGo4wFBSejNckSFQ/5ASS4CjUplyKTCkEx3SS6b/AHE1sENlf4iQ Ei3SN0BXYfdC0QORPYBqBZAxwj9kXILrB0BMZCI34CIyUzQxIBT/MjAkQgUQLPAecXRQBIEfgP8w o2TDKBSpBDeRLAAh8AmA/48GYzAdwiQiIBSNMa7CJUL/AMB/IZvxHwIHcDyBHuIyIbEjOy1EYR+Q IBR9tEAAAB4ANRABAAAAXQAAADwyRTMzOTYwMDk1QjU4RTQwQTREMzM0NUFCOUY2NUVDMTAyOTBF QUJCQHdpbi1tc2ctMDEud2luZ3JvdXAud2luZGVwbG95Lm50ZGV2Lm1pY3Jvc29mdC5jb20+AAAA AB4AQhABAAAAJwAAADwzQjg2NDdBMC5DODUzQTA3OEBhbWVyaWNhc20wNi5udC5jb20+AAADAIAQ /////wMAkhABAAAAHwDzEAEAAABIAAAAUgBFACUAMwBBACAARgBXACUAMwBBACAATQBBAEwATABP AEMAIABNAEkAQgAgAGMAbwBtAG0AZQBuAHQAcwAuAEUATQBMAAAACwD2EAAAAABAAAcwESo2oBNk wQFAAAgwVm7O4xNkwQEDAN4/n04AAAMA8T8JBAAAHgD4PwEAAAAMAAAARGF2ZSBUaGFsZXIAAgH5 PwEAAABgAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPU1JQ1JPU09GVC9PVT1GSVJT VCBBRE1JTklTVFJBVElWRSBHUk9VUC9DTj1SRUNJUElFTlRTL0NOPURUSEFMRVIAHgD6PwEAAAAV AAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv 4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAAeADBAAQAAAAgAAABEVEhBTEVS AB4AMUABAAAACAAAAERUSEFMRVIAHgA4QAEAAAAIAAAARFRIQUxFUgAeADlAAQAAAAIAAAAuAAAA AwAJWQEAAAALAGaBCCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAfoEIIAYAAAAAAMAAAAAA AABGAAAAAFKFAADNkgEAHgB/gQggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAMTAuMAAA AAADAMKBCCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAEAAxIEIIAYAAAAAAMAAAAAAAABGAAAA AGCFAAAAQCMOQwAAAAsAx4EIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwDRgQggBgAAAAAA wAAAAAAAAEYAAAAAEIUAAAAAAAADANiBCCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsA54EI IAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwDogQggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAAA AAALACkAAAAAAAsAIwAAAAAAAwAGEMW186sDAAcQhAYAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAA AGUAAABJTUFDVElOR09OVEhFTEFTVENBTExDT01NRU5UU1JFQ0VJVkVERlJPTUJSSUFOSEFCRVJN QU4sQklMTEZFTk5FUixBTkRTVEVWRUhBTk5BSEVSRVNUSEVSRVNQT05TRVNUT0JSAAAAAAIBfwAB AAAAXQAAADwyRTMzOTYwMDk1QjU4RTQwQTREMzM0NUFCOUY2NUVDMTAyOTBFQUJCQHdpbi1tc2ct MDEud2luZ3JvdXAud2luZGVwbG95Lm50ZGV2Lm1pY3Jvc29mdC5jb20+AAAAACoc ------_=_NextPart_001_01C16413.E3C9A9A0-- From owner-malloc@catarina.usc.edu Fri Nov 2 23:14:41 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25834 for ; Fri, 2 Nov 2001 23:14:40 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id TAA97978 for malloc-list; Fri, 2 Nov 2001 19:54:39 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id TAA97973 for ; Fri, 2 Nov 2001 19:54:37 -0800 (PST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 19:54:04 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Nov 2001 19:54:03 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 19:54:03 -0800 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, 2 Nov 2001 19:09:20 -0800 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.3562.0); Fri, 2 Nov 2001 19:34:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [malloc] RE: More MALLOC-MIB comments Date: Fri, 2 Nov 2001 19:34:03 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290EABD@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: More MALLOC-MIB comments thread-index: AcEp3ts3cokAjS3/ShmbL+wEiGEwVg6OVZHg From: "Dave Thaler" To: "Bill Fenner" Cc: X-OriginalArrivalTime: 03 Nov 2001 03:34:04.0021 (UTC) FILETIME=[62A75250:01C16418] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id TAA97974 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Response to one of Bill's two sets of comments: > The Guid TC seems out of place here; a Guid isn't a MALLOC concept, > right? Also, the DESCRIPTION seems a little inadequate (like, how > do you ensure that it's globablly unique, etc.) ACTION: Changed as described below. Changed mallocRequestGuid to mallocRequestLeaseIdentifier, with syntax of OCTET STRING (SIZE (0..255)). Removed the Guid TC, since that's the only place it was used. > Comments describing TABLEs should probably be in the DESCRIPTION of > either the Table or the Entry. This applies to the mallocScopeTable, > mallocScopeNameTable, mallocScopeExclusionTable, mallocRequestTable. ACTION: Changed as suggested. > Can there be overlapping ranges in the mallocScopeTable? The > DESCRIPTION of mallocScopeDivisible almost implies that there can, > by saying that if it's divisible it must only allocate addresses > out of a subrange; perhaps that subrange would also be in this table? > The INDEX can't represent overlapping ranges if the overlap is at the > beginning of the range. If overlap is possible, adding the last > address to the INDEX is probably wise (and adding it to the other > tables that refer to rows of this one). Alternately, an integer > instance-of-this-first- address-value element could prevent the > OID from getting too long. ACTION: Updated DESCRIPTION of Table. No, ranges cannot overlap. ScopeDivisible only indicates whether the range of the scope is divided up among multiple independent organizations to allocate from. IPv6 unicast-prefix-based addresses, and IPv4 GLOP are examples of why the global ASM scopes are divisible. ZMAAP is an example of why the IPv6 link-local multicast scope is not divisible. > I'd rename FirstAddressType to AddressType and get rid of > LastAddressType, since the INET-ADDRESS-MIB has relaxed these > restrictions. Similarly you can get rid of mallocAllocRange{First, > Last}AddressType, mallocScopeExclusion{First,Last}AddressType. ACTION: Changed as suggested. > The INDEX of mallocRequestEntry can't be a GUID, since GUID's can > be too long to represent in an OID. I dunno what makes sense > here -- an arbitrary integer as the index, maybe. ACTION: Changed as suggested. Added an arbitrary integer as the index and moved GUID to read-only (mallocRequestLeaseIdentifier) and added it to the madcapClientGroup, since MADCAP uses a Lease Identifier, as do some other protocols (like ZMAAP), but not all mechanisms do (e.g., SSM may not). Also changed mallocAddressRequestGuid to mallocAddressRequestId, since its main purpose is to identify the row in the mallocRequestTable. -Dave From owner-malloc@catarina.usc.edu Mon Nov 5 20:31:42 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12107 for ; Mon, 5 Nov 2001 20:31:39 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id RAA10478 for malloc-list; Mon, 5 Nov 2001 17:04:01 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id RAA10473 for ; Mon, 5 Nov 2001 17:03:58 -0800 (PST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 5 Nov 2001 17:03:11 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Nov 2001 17:03:15 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 5 Nov 2001 17:03:24 -0800 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.2966); Mon, 5 Nov 2001 17:03:07 -0800 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.3562.0); Mon, 5 Nov 2001 17:02:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [malloc] RE: FW: MALLOC MIB comments Date: Mon, 5 Nov 2001 17:02:29 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB7E08@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: FW: MALLOC MIB comments thread-index: AcEp2h6YB+wFzmYdQTOGKi+VbswYhQ8hDBag From: "Dave Thaler" To: "Bill Fenner" , X-OriginalArrivalTime: 06 Nov 2001 01:02:28.0317 (UTC) FILETIME=[B46E48D0:01C1665E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by catarina.usc.edu id RAA10474 Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit Here's the changes in response to the final set of comments received during WG last call. I submitted -05 today, and if you don't want to wait, the document is currently available at http://www.aciri.org/malloc/draft-ietf-malloc-malloc-mib-05.txt -Dave ---------------------------------- > - Index length limits. The OID length limit is 128 identifiers, > so the root plus the lengths of the encoded objects in the INDEX > has to be limited to make sure you don't end up with unrepresentable > rows. ACTION: Fixed. Added (SIZE(4..20)) to the InetAddress objects used in indexes, which range covers the sizes of IPv4 addresses through scoped IPv6 addresses. Also added (SIZE(1..92)) to the LanguageTag object used in an INDEX, so the total OID length will be < 128 in the mallocScopeNameTable. > - Unconditionally optional groups. There's no conformance statement > referring to mallocClientScopeGroup or mallocPrefixCoordinatorGroup, > so these are optional even on MADCAP clients or Prefix Coordinators. ACTION: Fixed. Added mallocClientScopeGroup to mallocClientCompliance as mandatory for clients which maintain a list of multicast scopes. Added mallocPrefixCoordinatorCompliance for prefix coordinators, which contains the mallocBasicGroup and the mallocPrefixCoordinatorGroup. I also noticed that a number of newer writable objects didn't have MIN-ACCESS statements of read-only in the compliances, and added them to be consistent. From owner-malloc@catarina.usc.edu Wed Nov 7 13:28:27 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19347 for ; Wed, 7 Nov 2001 13:28:25 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id KAA20337 for malloc-list; Wed, 7 Nov 2001 10:05:23 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA20332 for ; Wed, 7 Nov 2001 10:05:22 -0800 (PST) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id fA7I5MZ89696 for malloc@catarina.usc.edu; Wed, 7 Nov 2001 10:05:22 -0800 (PST) (envelope-from pavlin) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id EAA18979 for ; Wed, 7 Nov 2001 04:06:45 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01565; Wed, 7 Nov 2001 07:06:41 -0500 (EST) Message-Id: <200111071206.HAA01565@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-05.txt Date: Wed, 07 Nov 2001 07:06:41 -0500 Sender: owner-malloc@catarina.usc.edu Precedence: bulk --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-05.txt Pages : 40 Date : 06-Nov-01 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-05.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-05.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-05.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: <20011106143137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-malloc-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-malloc-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011106143137.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Mon Nov 12 17:39:53 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21654 for ; Mon, 12 Nov 2001 17:39:53 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA40832 for malloc-list; Mon, 12 Nov 2001 14:18:06 -0800 (PST) Received: from possum.aciri.org (possum.aciri.org [192.150.187.67]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA40827 for ; Mon, 12 Nov 2001 14:18:05 -0800 (PST) Received: (from pavlin@localhost) by possum.aciri.org (8.11.3/8.11.1) id fACMI4q86086 for malloc@catarina.usc.edu; Mon, 12 Nov 2001 14:18:04 -0800 (PST) (envelope-from pavlin) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.33]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA40817 for ; Mon, 12 Nov 2001 14:17:17 -0800 (PST) Received: from hansa.ibr.cs.tu-bs.de (root@hansa.ibr.cs.tu-bs.de [134.169.34.81]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id XAA24976; Mon, 12 Nov 2001 23:13:46 +0100 (MET) Received: from hansa.ibr.cs.tu-bs.de (strauss@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id fACMDjTU013643; Mon, 12 Nov 2001 23:13:45 +0100 Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) id fACMDg3q013637; Mon, 12 Nov 2001 23:13:42 +0100 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: dthaler@MICROSOFT.com, dthaler@dthaler.microsoft.com Cc: Allison Mankin , malloc@catarina.usc.edu Cc: "Wijnen, Bert (Bert)" Cc: Juergen Schoenwaelder Subject: [malloc] Re: FW: Request for MIB Doctor review before IETF Last Call - malloc mib References: <2413FED0DFE6D111B3F90008C7FA61FB0DE83C01@nl0006exch002u.nl.lucent.com> Date: 12 Nov 2001 23:13:42 +0100 In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0DE83C01@nl0006exch002u.nl.lucent.com> Message-ID: Lines: 48 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hi! Bert> Could one of you do you SMIlint checks and report back to Bert> the authors and WG? Pls cc: myself and Allison Mankin too. Please note that I just did a plain smilint check. I did not look into any semantics. I even don't know what the purpose of this MIB is other than known from it's name. ;-) You can use smilint without installing it yourself by sending the MIB(s) as plain text without any header and trailers to smilint@ibr.cs.tu-bs.de. If there are non-RFC MIBs imported, simply concatenate them in the appropriate order, e.g. cat IANA-MALLOC-MIB MALLOC-MIB | Mail smilint@ibr.cs.tu-bs.de ./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. ./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. ./MALLOC-MIB:404: `InetAddress' object should have an accompanied preceding `InetAdressType' object ./MALLOC-MIB:638: `InetAddress' object should have an accompanied preceding `InetAdressType' object I'd suggest to read draft-ietf-ops-rfc2851-update-05 for the details. I did not delve into the semantics of the MALLOC-MIB, but I think the usage of InetAdress does not conform to the intentions of draft-ietf-ops-rfc2851-update-05, e.g. the SIZE(4..20) restrictions in some cases. -frank PS: Dave, 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. From owner-malloc@catarina.usc.edu Mon Nov 12 20:20:53 2001 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26319 for ; Mon, 12 Nov 2001 20:20:52 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id QAA41230 for malloc-list; Mon, 12 Nov 2001 16:57:08 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id QAA41225 for ; Mon, 12 Nov 2001 16:57:07 -0800 (PST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.195]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 12 Nov 2001 16:56:19 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 12 Nov 2001 16:56:19 -0800 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.2966); Mon, 12 Nov 2001 16:56:18 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 12 Nov 2001 16:55:28 -0800 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.3562.0); Mon, 12 Nov 2001 16:54:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C16BDD.C9ACA1EE" Subject: [malloc] RE: FW: Request for MIB Doctor review before IETF Last Call - malloc mib Date: Mon, 12 Nov 2001 16:54:45 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290EB58@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: yes Thread-Topic: FW: Request for MIB Doctor review before IETF Last Call - malloc mib thread-index: AcFrxzQlKj8Wzt99RlqIUhB9RQ7w/AAFcv8w From: "Dave Thaler" To: "Frank Strauss" Cc: "Allison Mankin" , , "Wijnen, Bert (Bert)" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 13 Nov 2001 00:54:46.0170 (UTC) FILETIME=[C9DC7FA0:01C16BDD] Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C16BDD.C9ACA1EE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below... Frank Strauss writes: > ./MALLOC-MIB:169: use Integer32 instead of INTEGER in SMIv2 > ./MALLOC-MIB:987: use Integer32 instead of INTEGER in SMIv2 >=20 > This is just a suggestion, not a MUST. It affects mallocScopeHopLimit > and madcapConfigResponseCacheInterval. I can change this, but I think it can be fixed after IESG/IETF last call, since it's just a suggestion. > ./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 >=20 > These macros and type should be removed from the IMPORTS > statement. However, this is again not a syntacical MUST. Likewise. =20 > ./MALLOC-MIB:404: `InetAddress' object should have an accompanied > preceding `InetAdressType' object > ./MALLOC-MIB:638: `InetAddress' object should have an accompanied > preceding `InetAdressType' object >=20 > I'd suggest to read draft-ietf-ops-rfc2851-update-05 for the details. > I did not delve into the semantics of the MALLOC-MIB, but I think the > usage of InetAdress does not conform to the intentions of > draft-ietf-ops-rfc2851-update-05, e.g. the SIZE(4..20) restrictions > in some cases. Per the attached email thread, the MALLOC-MIB is correct and the rfc2851-update draft needs to be fixed. > PS: Dave, 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. Both are valid, one forwards to the other. (However, I'll probably change one after IETF last call just to be consistent.) Thanks, -Dave=20 ------_=_NextPart_001_01C16BDD.C9ACA1EE Content-Type: message/rfc822 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by win-msg-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3562.0); Tue, 6 Nov 2001 02:37:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3562.0); Tue, 6 Nov 2001 02:37:55 -0800 Received: from inet-hub-05.redmond.corp.microsoft.com ([157.54.6.150]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 6 Nov 2001 02:38:44 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 6 Nov 2001 02:38:45 -0800 Received: from 157.54.8.21 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Nov 2001 02:38:35 -0800 Received: from dthaler.microsoft.com ([131.107.152.20]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 6 Nov 2001 02:38:34 -0800 Received: from psg.com (exim@psg.com [147.28.0.62]) by dthaler.microsoft.com (8.8.7/8.8.7) with ESMTP id DAA04551 for ; Tue, 6 Nov 2001 03:46:39 -0800 (PST) (envelope-from owner-mibs@ops.ietf.org) Received: from lserv by psg.com with local (Exim 3.33 #1) id 1613ZT-00022t-00 for mibs-data@psg.com; Tue, 06 Nov 2001 02:35:07 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.33 #1) id 160vCw-000IuY-00 for mibs@ops.ietf.org; Mon, 05 Nov 2001 17:39:18 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 5 Nov 2001 17:39:05 -0800 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Nov 2001 17:39:16 -0800 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.2966); Mon, 5 Nov 2001 17:39:16 -0800 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.2966); Mon, 5 Nov 2001 17:39:04 -0800 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.3562.0); Mon, 5 Nov 2001 17:38:23 -0800 Content-Class: urn:content-classes:message Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 X-OriginalArrivalTime: 06 Nov 2001 01:38:23.0891 (UTC) FILETIME=[B940C630:01C16663] Subject: FW: Comments on draft-ietf-ops-rfc2851-update-05.txt Date: Mon, 5 Nov 2001 17:38:26 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290EADE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ops-rfc2851-update-05.txt thread-index: AcFmDQIxXutRIojHSdCIKYzZFX7yjgAU6/rQAADIPXA= From: "Dave Thaler" To: Content-Transfer-Encoding: quoted-printable [correcting the email alias] -----Original Message----- From: Dave Thaler=20 Sent: Monday, November 05, 2001 5:34 PM To: 'mibs@ietf.org'; 'iesg@ietf.org' Subject: Comments on draft-ietf-ops-rfc2851-update-05.txt Background: > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: Monday, November 05, 2001 3:11 PM > > Dave> Situation: a table INDEX'ed by an InetAddressType object and an > Dave> InetAddress object that are not in the table itself. >=20 > Dave> My reading of the section 4 is that if an InetAddressType object > Dave> occurs in the INDEX, but that object does not have an OID in the > Dave> table itself, then the table MUST still have another > Dave> InetAddressType column before any InetAddress columns in the > Dave> table. (And presumably its DESCRIPTION would typically say the > Dave> value MUST be equal to the value of the InetAddressType object > Dave> in the INDEX.) >=20 > Dave> Is this the intent? >=20 > Not really. For me, the INDEX components are kind of "logically > registered" before any other columns of a table. The big question is > how to describe this in an understandable way. >=20 > Since we are in IETF last call mode, I would like to ask you to bring > this issue up on the and the or > mailing lists. The problematic text is (from Sect 4, 3rd para): > The InetAddressType object must be registered before the InetAddress > object(s) or InetAddressPrefixLength object(s). In other words, the > object identifiers for the InetAddressType object and the InetAddress > object MUST have the same length and the last sub-identifier of the > InetAddressType object MUST be less than the last sub-identifier of > the InetAddress object. Here's some suggested replacement text: The InetAddressType object must be registered before the InetAddress object(s) or InetAddressPrefixLength object(s). In other words, either: a) the object identifiers for the InetAddressType object and the InetAddress object MUST have the same length and the last sub-identifier of the InetAddressType object MUST be less than the last sub-identifier of the InetAddress object, or b) the InetAddress object MUST be a columnar object in a table with an InetAddressType object in the INDEX (preceding the InetAddress object if it is also in the INDEX). Furthermore, when an InetAddress object appears in the INDEX of another table, it MUST be preceded in the INDEX of that table by an InetAddressType object. (I believe the above text covers all the cases where an INDEX can contain a Type from the same or a different table, and perhaps an Address from the same or a different table.) -Dave ------_=_NextPart_001_01C16BDD.C9ACA1EE--