RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt
Juergen Quittek <quittek@ccrle.nec.de> Fri, 18 June 2004 22:20 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27602 for <disman-archive@lists.ietf.org>; Fri, 18 Jun 2004 18:20:28 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRX2-0004E6-Vd; Fri, 18 Jun 2004 18:08:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRT4-0002M8-G6 for disman@megatron.ietf.org; Fri, 18 Jun 2004 18:04:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25756 for <disman@ietf.org>; Fri, 18 Jun 2004 18:04:11 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbRT2-0006P3-UX for disman@ietf.org; Fri, 18 Jun 2004 18:04:13 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbRS9-000634-00 for disman@ietf.org; Fri, 18 Jun 2004 18:03:20 -0400
Received: from tokyo.netlab.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1BbRRF-0005Jp-00; Fri, 18 Jun 2004 18:02:21 -0400
Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 972912C916; Sat, 19 Jun 2004 00:01:46 +0200 (CEST)
Received: from [192.168.1.6] (unknown [192.168.1.6]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D1713FECD7; Sat, 19 Jun 2004 00:01:39 +0200 (CEST)
Date: Sat, 19 Jun 2004 00:01:40 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Randy Presuhn <randy_presuhn@mindspring.com>, disman@ietf.org
Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt
Message-ID: <2147483647.1087603299@[192.168.1.6]>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F056B2FE5@is0004avexu1.global.avaya.com>
References: <AAB4B3D3CF0F454F98272CBE187FDE2F056B2FE5@is0004avexu1.global.avaya.com>
X-Mailer: Mulberry/3.0.3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Cc: ipcdn@ietf.org
X-BeenThere: disman@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Distributed Management <disman.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/disman>
List-Post: <mailto:disman@ietf.org>
List-Help: <mailto:disman-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/disman>, <mailto:disman-request@ietf.org?subject=subscribe>
Sender: disman-bounces@ietf.org
Errors-To: disman-bounces@ietf.org
Content-Transfer-Encoding: 7bit
Dan, Please find the list of changes at the end of this message. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 17.06.2004 22:41 Uhr +0300 Romascanu, Dan (Dan) wrote: > Randy, > > Would it be possible for the authors to provide a log of changes relative to RFC 2925? > > Regards, > > Dan > > > >> -----Original Message----- >> From: disman-bounces@ietf.org >> [mailto:disman-bounces@ietf.org]On Behalf Of Randy Presuhn >> Sent: 17 June, 2004 9:55 PM >> To: disman@ietf.org >> Cc: ipcdn@ietf.org >> Subject: [Disman] Disman WG last call >> ondraft-ietf-disman-remops-mib-v2-02.txt >> >> >> Hi - >> >> As disman WG chair, I'm announcing the start of a two-week >> working group >> last call on the Remote Operations MIBs. The latest version >> is available at >> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-m >> ib-v2-02.txt >> Our objective is to advance to Draft Standard. Off-line I've received >> word that that we will have at least two implementation reports. I'm >> fairly sure there are more out there, so please speak up if >> you know of >> an implementation. >> >> I'm CC:ing the ipcdn WG mailing list, since we've incorporated some >> additional conformance material to meet (I hope) their needs. Please >> send any comments, including "I've read it and don't object" comments, >> to the disman WG mailing list at disman@ietf.org. >> >> The last call will end on Friday, July second, 2004. If >> anyone is committed >> to reviewing it but would need additional time, let me know >> and I'll see what >> we can work out. >> >> Randy >> >> ====================================================================== Changes in draft-ietf-disman-remops-mib-v2-00.txt compared to RFC 2925 ====================================================================== ======================================================================== 1. typo in description of pingTestCompleted ======================================================================== Problem Description: ------------------------------------------------------------------------ >From RFC Errata web page Reported by: Randy Presuhn; rpresuhn@dorothy.bmc.com Date: Tue, 26 Mar 2002 15:16:54 -0800 In Section 4.1: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(4)." Should be: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(2)." ======================================================================== Suggested solution: ------------------------------------------------------------------------ obvious ======================================================================== Status: solution committed ======================================================================== ======================================================================== 2. description of pingCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. A ping request is usually an ICMP message encoded into an IP packet. An IP packet has a maximum size of 65535 octets. Subtracting the size of the ICMP or UDP header (both 8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets." DEFVAL { 0 } ::= { pingCtlEntry 5 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion to be transmitted in a ping operation in octets. Whether or not this value can be applied depends on the selected implementation method for performing a ping operation indicated by pingCtlType in the same conceptual row. If the method used allows applying the value contained in this object, then it MUST be applied. If the specified size is not appropriate for the chosen ping method, the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 3. description of traceRouteCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: traceRouteCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion of a traceroute request in octets. A traceroute request is essentially transmitted by encoding a UDP datagram into a IP packet. So subtracting the size of a UDP header (8 octets) and the size of a IP header (20 octets) yields a maximum of 65507 octets." DEFVAL { 0 } ::= { traceRouteCtlEntry 6 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion of a traceroute request in octets. If the RECOMMENDED traceroute method (UDP datagrams as probes) is used, then the value contained in this object MUST be applied. If another traceroute method is used for which the specified size is not appropriate, then the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 4. SNMP boilerplate outdated ======================================================================== Problem Description: ------------------------------------------------------------------------ Section 2 on "The Internet-Standard Management Framework" is outdated. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace with new one. This implies an update of the reference section. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 5. References need to be split in normative and informational ones. ======================================================================== Problem Description: ------------------------------------------------------------------------ clear ======================================================================== Suggested solution: ------------------------------------------------------------------------ 7. Normative References [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 8. Informative References [RFC2119] S. Bradner "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC862] J. Postel "Echo Protocol", STD 20, RFC 862, May 1983. [RFC792] J. Postel "Internet Control Message Protocol", RFC 792, September 1981. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3415] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 6. clarify structure of Section 1 "Introduction" ======================================================================== Problem Description: ------------------------------------------------------------------------ The structure of the introduction would be clearer if subsections were used. ======================================================================== Suggested solution: ------------------------------------------------------------------------ insert subsection headers 1.1. Ping 1.2. Traceroute 1.3. Lookup 1.4. Remote Operations ======================================================================== Status: solution committed ======================================================================== ======================================================================== 7. context of remote operations explanation not clear ======================================================================== Problem Description: ------------------------------------------------------------------------ At the end of Section 1 "Introduction" the remote operations scenario is described. The description starts without explaining the context. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "Consider the following diagram:" by "The MIB modules defined in this document allow a management station to initiate ping, traceroute and lookup operations remotely. The basic scenario is illustrated by the following diagram." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 8. diagram explaining remote operations scenario ======================================================================== Problem Description: ------------------------------------------------------------------------ The diagram at the end of Section 1 "Introduction" +--------------------------------------------------------------------+ | | | Remote ping, traceroute, Actual ping, traceroute, | | +-----+or Lookup op. +------+or Lookup op. +------+ | | |Local|---------------->|Remote|---------------->|Target| | | | Host| | Host | | Host | | | +-----+ +------+ +------+ | | | | | +--------------------------------------------------------------------+ uses "local host" and "remote host". In order to align it with the SNMP management framework, these terms should be replaced by "management station" or "managed node", respectively. also it would increase clarity if the remote initiation of operations was separated from reciving results. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace diagram by +-------+ +-------+ +-------+ | |---------->| | | | | | initiate | |---------->| | | Mgmt. | operation |Managed| perform |Target | |Station| remotely | Node | operation | Host | | | | | | | | |<----------| | | | +-------+ receive +-------+ +-------+ result of operation and update text in following paragraph accordingly. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 9. RFC 2575 (VACM) obsoleted ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2575 (VACM) is referenced several times in the document. RFC 2575 has been obsoleted by RFC 3415. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace RFC 2575 by RFC 3415 in text, MIBs and reference sections. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 10. obsoleted RFCs metioned in IPORT sections ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2571 imported by DISMAN-PING-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3411. RFC 2851 imported by DISMAN-PING-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3291. ======================================================================== Suggested solution: ------------------------------------------------------------------------ The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 11. Update contact info in MIB modules ======================================================================== Problem Description: ------------------------------------------------------------------------ So far Kenneth served as contact. Now Juergen edits the docuemnt and takes over. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace Kenneth by Juergen in all three MIB modules. ======================================================================== Status: solution committed ======================================================================== ======================================= changes from version -00 to version -01 ======================================= ======================================================================== 12. clarification required for pingMaxConcurrentRequests and lookupMaxConcurrentRequests ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object pingMaxConcurrentRequests does not explain how to deal with the case that its value is reduced to a number smaller than the number of active requests. The same applies to the DESCRIPTION clause of object lookupMaxConcurrentRequests. ======================================================================== Suggested solution: ------------------------------------------------------------------------ append "The limit applies only to new requests being activated. When a new value is set, the agent will continue processing all the requests already active, even if their number exceed the limit just imposed." to DESCRIPTION clause of object pingMaxConcurrentRequests and to DESCRIPTION clause of object lookupMaxConcurrentRequests ======================================================================== Status: solution committed ======================================================================== ======================================================================== 13. No default value for pingCtlTrapGeneration ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object pingCtlTrapGeneration suggests that the object "defaults to zero", but there is no DEFVAL clause. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace in DESCRIPTION clause "The value of this object defaults to zero, indicating that none of the above options have been selected." with "By default, no bits are set, indicating that none of the above options are selected." and add "DEFVAL { {} } -- no bits set." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 14. Re-initialization of entries in ping/tracerouteResultsTable unclear ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of objects pingResultsTable and traceRouteResultsTable do not describe the semantics of re-initialization. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to DESCRIPTION clause of object pingResultsTable "If object pingCtlAdminStatus already has value enabled(1) and if the corresponding pingResultsOperStatus object has value completed(3), then successfully writing enabled(1) to object pingCtlAdminStatus re-initializes the already existing entry in the pingResultsTable. The values of objects in the re-initialized entry are the same than the values of objects in a new entry would be." add to DESCRIPTION clause of object traceRouteResultsTable "If object traceRouteCtlAdminStatus already has value enabled(1) and if the corresponding traceRouteResultsOperStatus object has value completed(3), then successfully writing enabled(1) to object traceRouteCtlAdminStatus re-initializes the already existing entry in the traceRouteResultsTable. The values of objects in the re-initialized entry are the same than the values of objects in a new entry would be." add value completed(3) to SYNTAX clause of pingResultsOperStatus add value completed(3) to SYNTAX clause of traceRouteResultsOperStatus ======================================================================== Status: solution committed ======================================================================== ======================================================================== 15. Some objects have syntax Unsigned32 but should be Gauge32 ======================================================================== Problem Description: ------------------------------------------------------------------------ Some counters have syntax Unsigned32. Gauge32 fits better. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Change SYNTAX clause from Unsigned32 to Gauge32 for objects pingResultsProbeResponses, pingResultsSentProbes, traceRouteResultsTestAttempts, traceRouteResultsTestSuccesses ======================================================================== Status: solution committed ======================================================================== ======================================================================== 16. Typo in DESCRIPTION clause of pingTestCompleted ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of pingTestCompleted refers to value testCompletion(4) of object pingCtlTrapGeneration. Correct is testCompletion(2). ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "corresponding pingCtlTrapGeneration object is set to testCompletion(4)." with "corresponding pingCtlTrapGeneration object has the testCompletion(2) bit set." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 17. Value of 0 does not make sense for traceRouteCtlInitialTtl ======================================================================== Problem Description: ------------------------------------------------------------------------ The SYNTAX clause of object traceRouteCtlInitialTtl includes 0. This is not a useful value. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "SYNTAX Unsigned32 (0..255)" with "SYNTAX Unsigned32 (1..255)" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 18. Irritating description of traceRouteCtlFrequency ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object traceRouteCtlFrequency contains an irritating sentence referring to the number of hops per single traceroute test. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "The number of hops in a single traceroute test is determined by the value of the corresponding traceRouteCtlProbesPerHop object. After a single test completes the number of seconds as defined by the value of traceRouteCtlFrequency MUST elapse before the next traceroute test is started." with "After a single test completes the number of seconds as defined by the value of traceRouteCtlFrequency MUST elapse before the next traceroute test is started." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 19. What is a good path? ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object traceRouteResultsLastGoodPath does not clearly describe the term 'good' or 'complete' path. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace DESCRIPTION clause "The date and time when the last complete path was determined." with "The date and time when the last complete path was determined. A path is complete if responses were received or timeout occurred for each hop on the path, i.e. for each TTL value from the value of the corresponding traceRouteCtlInitialTtl object up to the end of the path or - if no reply from the target IP address was received - up to the value of the corresponding traceRouteCtlMaxTtl object." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 20. Fixing bug in SYNTAX clause of lookupCtlOperStatus ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object lookupCtlOperStatus defines values notStarted(2) and completed(3), but enabled(1) is missing, although enabled(1) is defined in the DESCRIPTION clause. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to SYNTAX clause "enabled(1), -- operation is active" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 21. Missing references ======================================================================== Problem Description: ------------------------------------------------------------------------ Some RFCs are mentioned in DESCRIPTION clauses of the MIB definition, but not referenced in the Reference section. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to Normative References [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. add to Normative References [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. ======================================================================== Status: solution committed ======================================================================== ======================================= changes from version -01 to version -02 ======================================= ======================================================================== 22. The compliance ststements are not well suited for small devices ======================================================================== Problem Description: ------------------------------------------------------------------------ For small devices it might be desirable to support just a single test per MIB module. Then creating and deleting table entries is not required anymore. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Add new MODULE-COMPLIANCY statements pingMinimumCompliance, traceRouteMinimumCompliance, lookupMinimumCompliance. The already existing MODULE-COMPLIANCY statements pingCompliance and traceRouteCompliance are syntactically modified, but semantically unchanged. For the following objects pingCompliance and pingMinimumCompliance differ: pingCtlDataFill pingCtlFrequency pingCtlMaxRows pingCtlTrapGeneration pingCtlProbeFailureFilter pingCtlTestFailureFilter pingCtlDescr pingCtlByPassRouteTable pingProbeHistoryTime For the following objects traceRouteCompliance and traceRouteMinimumCompliance differ: traceRouteCtlByPassRouteTable traceRouteCtlDontFragment traceRouteCtlInitialTtl traceRouteCtlFrequency traceRouteCtlDescr traceRouteCtlMaxRows traceRouteCtlTrapGeneration traceRouteCtlCreateHopsEntries traceRouteCtlRowStatus traceRouteHopsLastGoodProbe For the following objects lookupCompliance and lookupMinimumCompliance differ: lookupCtlRowStatus Add new section "3.4. Conformance Each of the three MIB modules defined in this document has two compliancy statements, one for full compliancy and one for minimum compliancy. The minimum compliancy statements are intended to be applied to implementation for devices with very limited resources. The main difference between full and minimum compliancy is that for minimum compliancy dynamic creation and deletion of table entries is not required while it is required for full compliancy." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 23. disabling of lookupPurgeTime ======================================================================== Problem Description: ------------------------------------------------------------------------ There is no value defined for object lookupPurgeTime that disables the function of automatich entry deletion. Also, the use of value 0 is questionable. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Add to DESCRIPTION clause "A value of 0 indicates that automatic deletion of entries is disabled." ======================================================================== Status: solution committed ========================================================================
- RE: [Disman] Disman WG last call ondraft-ietf-dis… Romascanu, Dan (Dan)
- Re: [Disman] Disman WG last call ondraft-ietf-dis… Randy Presuhn
- Re: [ipcdn] RE: [Disman] Disman WG last callondra… Randy Presuhn
- RE: [Disman] Disman WG last call ondraft-ietf-dis… Juergen Quittek
- Re: [Disman] Disman WG last call ondraft-ietf-dis… Randy Presuhn
- RE: [Disman] Disman WG last call ondraft-ietf-dis… Romascanu, Dan (Dan)
- RE: [Disman] Disman WG last call ondraft-ietf-dis… Juergen Quittek