Subject: [ipcdn] "Optional" in the description of objects from the rfmibv2

From: Murwin William-LWM008 <[email-masked]>
Date: Mon, 5 May 2003 15:07:30 -0400

David,

	I was reading the description for the following objects:

docsIfCmtsUpChnlCtrCollCntnMslots              
docsIfCmtsUpChnlCtrTotalCntnReqMslots          
docsIfCmtsUpChnlCtrUsedCntnReqMslots           
docsIfCmtsUpChnlCtrCollCntnReqMslots           
docsIfCmtsUpChnlCtrTotalCntnReqDataMslots      
docsIfCmtsUpChnlCtrUsedCntnReqDataMslots       
docsIfCmtsUpChnlCtrCollCntnReqDataMslots       
docsIfCmtsUpChnlCtrTotalCntnInitMaintMslots    
docsIfCmtsUpChnlCtrUsedCntnInitMaintMslots     
docsIfCmtsUpChnlCtrCollCntnInitMaintMslots     
docsIfCmtsUpChnlCtrExtCollCntnMslots           
docsIfCmtsUpChnlCtrExtTotalCntnReqMslots       
docsIfCmtsUpChnlCtrExtUsedCntnReqMslots        
docsIfCmtsUpChnlCtrExtCollCntnReqMslots        
docsIfCmtsUpChnlCtrExtTotalCntnReqDataMslots   
docsIfCmtsUpChnlCtrExtUsedCntnReqDataMslots    
docsIfCmtsUpChnlCtrExtCollCntnReqDataMslots    
docsIfCmtsUpChnlCtrExtTotalCntnInitMaintMslots 
docsIfCmtsUpChnlCtrExtUsedCntnInitMaintMslots  
docsIfCmtsUpChnlCtrExtCollCntnInitMaintMslots

All contain the following description:

"...Support for this object is optional. If the object is not supported, a value of zero is returned." 
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2 
Which is described as:
-- conditionally mandatory group 
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable Modem Termination Systems, not in Cable Modems." 
This description with the key word "optional" is confusing! If these objects are truly optional then they need not be implemented by the agent. 

rfc2580:
=======================================================================
	3.  Mapping of the OBJECT-GROUP macro

   For conformance purposes, it is useful to define a collection of
   related managed objects.  The OBJECT-GROUP macro is used to define
   each such collection of related objects.  It should be noted that the
   expansion of the OBJECT-GROUP macro is something which conceptually
   happens during implementation and not during run-time.

   To "implement" an object, an agent must return a reasonably accurate
   value for management protocol retrieval operations; similarly, if the
   object is writable, then in response to a management protocol set
   operation, an agent must accordingly be able to reasonably influence
   the underlying managed entity.  If an agent can not implement an
   object, the management protocol provides for it to return an
   exception or error, e.g, noSuchObject [4].  Under no circumstances
<----- NOTE
   shall an agent return a value for objects which it does not implement
<-----
   -- it must always return the appropriate exception or error, as
<------
   described in the protocol specification [4].  
========================================================================

I believe your intent is for these objects to be implemented by a CMTS agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these objects and change the text to read "If statistics are not maintained by the agent, a value of zero is returned for this object."  or something to that nature.
But what really is need is a change to the description for the docsIfCmtsGroupV2, the comment above the group should be include in the description. I would go as far as to say these objects are "mandatory" for a CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS, then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where trying to take. Any clarification is greatly appreciated.
Thanks,
Will Murwin

_____________________________
William Murwin
Broadband Communications Sector
Motorola Inc.
Email: [email-masked]
Tel: (508) 851-8385

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Raftus, David" <[email-masked]>
Date: Mon, 5 May 2003 12:18:52 -0700

Hi Will,

Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is mandatory
implementation of the objects, but optional counting of the statistics
represented by the objects. I will make your suggested changes in v7.

Thanks,
Dave

************************************
David Raftus
Terayon Canada Ltd
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2

[email-masked]           
613.592.1052  ext 222
************************************               

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:08 PM
To: [email-masked]'
Cc: IPCDN (E-mail) (E-mail)
Subject: "Optional" in the description of objects from the rfmibv2

David,

"...Support for this object is optional. If the object is not supported, a
value of zero is returned."
Yet in the compliance statement these object belong to the docsIfCmtsGroupV2
Which is described as:
-- conditionally mandatory group
GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in Cable
Modem Termination Systems, not in Cable Modems."
This description with the key word "optional" is confusing! If these objects
are truly optional then they need not be implemented by the agent.

rfc2580:

I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of these
objects and change the text to read "If statistics are not maintained by the
agent, a value of zero is returned for this object."  or something to that
nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory" for a
CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the CMTS,
then a new optional group is needed for the CMTS, just for these objects.
>From the current descriptions, am just not sure which approach you where
trying to take. Any clarification is greatly appreciated.
Thanks,
Will Murwin

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 28 May 2003 14:07:41 -0600

David and William,
 
I've been meaning to ask this for some time, but... what is the management
value of implementing objects if they don't report "valid" statistics?
Instead, why not make the objects completely optional for the CMTS (from a
specification point of view)?
 
If a management station receives a value of 0 for one of these objects as
specified now, it is not clear whether or not the CMTS is keeping track of
the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is
clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich

-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2

Hi Will, 

Thanks, 
Dave 

[email-masked]           
613.592.1052  ext 222 

-----Original Message----- 
From: Murwin William-LWM008 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: [email-masked]' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 

David, 

Which is described as: 

rfc2580: 

Thanks, 
Will Murwin

---

From: Michael StJohns <[email-masked]>
Date: Wed, 28 May 2003 16:25:55 -0400

Rich is exactly correct.  Remove the "...Support for this object is 
optional. If the object is not supported, a value of zero is returned." 
language everywhere it occurs - it won't make it past the mib 
doctors..  Place the objects in the appropriate conformance statement which 
indicates that its optional.  Return noSuchObject if the object isn't 
implemented.

Mike

At 16:07 5/28/2003, Woundy, Richard wrote:
>Subject: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2
>
>Hi Will,
>
>From: Murwin William-LWM008 
>[<mailto:[email-masked]>mailto:[email-masked]]
>GROUP docsIfCmtsGroupV2 DESCRIPTION "This group is implemented only in 
>Cable Modem Termination Systems, not in Cable Modems."
>
>This description with the key word "optional" is confusing! If these 
>objects are truly optional then they need not be implemented by the agent.
>
>rfc2580:
>I would remove the "optional" comment from the description of each of 
>these objects and change the text to read "If statistics are not 
>maintained by the agent, a value of zero is returned for this object."  or 
>something to that nature.
>
>description. I would go as far as to say these objects are "mandatory" for 
>a CMTS agent, even though this is not a mandatory-group.
>
>If I have mis-interrupted that these objects are not mandatory for the 
>CMTS, then a new optional group is needed for the CMTS, just for these objects.
>

---

From: Murwin William-LWM008 <[email-masked]>
Date: Wed, 28 May 2003 16:33:11 -0400

Rich,
 
        You make a great point. 
        
        I was looking at it from a implementer point of view and saw the manadtory group comment in the compliance statement. I.e. the reason for the email.
        But now that I see it from your point of view, I agree if these objects are truely "optional" then why must the agent support these objects. I hinted to that in the earlier email,
        I guess I didn't raise the question because because I truely didn't understand the context of "optional" in the description of these objects.
 
        Can I make a suggestion that a new table be created for the optional objects that aguments the table with the manadtory objects so that 
        as user using an SNMP Manager does not have figure out the hard way that some objects are "optional", if the CMTS does not support the optional objects.
        And in the compliance statement for the CMTS this is clearly explained.
 
Thanks,
Will Murwin

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; Murwin William-LWM008
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2

David and William,
 
I've been meaning to ask this for some time, but... what is the management value of implementing objects if they don't report "valid" statistics? Instead, why not make the objects completely optional for the CMTS (from a specification point of view)?
 
If a management station receives a value of 0 for one of these objects as specified now, it is not clear whether or not the CMTS is keeping track of the actual value of the object.
 
If a management station receives a 'noSuchObject' indication, then it is clear that the CMTS is not keeping track of the object's value. ;^)
 
-- Rich

-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the rfmibv2

Hi Will, 

Thanks for the note. It's always surprising to see how well intentioned words can be seen in another light. As you state, the intent is mandatory implementation of the objects, but optional counting of the statistics represented by the objects. I will make your suggested changes in v7.

Thanks, 
Dave 

[email-masked]           
613.592.1052  ext 222 

-----Original Message----- 
From: Murwin William-LWM008 [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, May 05, 2003 3:08 PM 
To: [email-masked]' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 

David, 

rfc2580: 

Thanks, 
Will Murwin

---

From: "Raftus, David" <[email-masked]>
Date: Wed, 28 May 2003 13:55:25 -0700

-----Original Message-----
From: Raftus, David 
Sent: Wednesday, May 28, 2003 4:28 PM
To: 'Woundy, Richard'; Raftus, David; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
Rich,
 
It has been my laymen's understanding of snmp that objects in a table must
all be present - ie can't pick and choose individual tabular objects to
appear in a mib walk. Perhaps I am incorrect in this understanding. There
does seem to be precedent for assigning a value of zero to tabular objects
that are present, but not functionally supported.
 
Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
David and William,

 
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
 
-----Original Message----- 

Which is described as:

---

From: "Raftus, David" <[email-masked]>
Date: Wed, 28 May 2003 13:27:37 -0700

Rich,

Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
David and William,

 
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
 
-----Original Message----- 

Which is described as:

---

From: "Raftus, David" <[email-masked]>
Date: Thu, 29 May 2003 05:32:41 -0700

Hi,
 
The suggestions to improve the efficiency and order of this mib are
definitely appreciated. Unfortunately we also need to consider that the
present mib is already supported by existing field Docsis implementations.
Is it really possible to move objects from one table to a new one at this
stage? 
 
It is too bad that folks from the IPCDN list can't review mib structure at
the same time changes are being debated functionally on other lists - in
this case it was Nov/Dec 2002 on the 2.0 and oss lists. I really don't know
how to balance the two views, except to have them done simultaneously. 
 
Very interested to hear opinions both on whether this mib structure can be
adjusted now, and how future mib development can accommodate both
syntactical and functional concerns at once.
 
Thanks,
Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:33 PM
To: 'Woundy, Richard'; 'Raftus, David'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
Rich,
 
        You make a great point. 
        
        I was looking at it from a implementer point of view and saw the
manadtory group comment in the compliance statement. I.e. the reason for the
email.
        But now that I see it from your point of view, I agree if these
objects are truely "optional" then why must the agent support these objects.
I hinted to that in the earlier email,
        I guess I didn't raise the question because because I truely didn't
understand the context of "optional" in the description of these objects.
 
        Can I make a suggestion that a new table be created for the optional
objects that aguments the table with the manadtory objects so that 
        as user using an SNMP Manager does not have figure out the hard way
that some objects are "optional", if the CMTS does not support the optional
objects.
        And in the compliance statement for the CMTS this is clearly
explained.
 
Thanks,
Will Murwin

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; Murwin William-LWM008
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
David and William,

 
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
 
-----Original Message----- 

Which is described as:

---

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 29 May 2003 13:40:28 -0600

Hi, 

I agree in making this objects truly OPTIONAL, 

The cleanest option I believe is the table extension as AUGMENTS as
William suggested, now two augment tables ? 32 and 64 ? Or just one ?

As today, an NMS should do two checks, Optional counters exists? Then 32
or 64 ?

From
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines
-01.txt

"
Now that SNMPv3 is an Internet Standard and SNMPv1
is Historic (see http://www.rfc-editor.org/rfcxx00.html for status
and [RFC3410] for rationale) there is no reason to continue enforcing
this restriction.  Henceforth "standard" MIB modules MAY use the
Counter64 type when it makes sense to do so, and MUST use Counter64
if the information being modelled would wrap in less than one hour if
the Counter32 type was used instead.
"

so either, NoSuchObject or "0" are two indications of not support of the
counters for either implementation (truly OPTIONAL or OPTIONAL reporting
zero). The only meaningful information is "> 0"

If is the case of moving the optional counters as an extension table,
would it be OK just to port only the 64 Counters?
 
Probably a question for Rich as IETF co-chair, and MSOs out here to see
if still v1 is the core tool for CMTS operations with no getBulk. 

Either case, leaving the table truly optional (32 or 32/64) or splitting
in basic and extension,  there is no much difference in the snmp
toolkit.

Just my thoughts....

Eduardo 
 
-----Original Message-----
From: Raftus, David [mailto:[email-masked]] 
Sent: Thursday, May 29, 2003 6:33 AM
To: 'Murwin William-LWM008'; 'Woundy, Richard'; Raftus, David
Cc: IPCDN (E-mail) (E-mail); DOCSIS OSS Majordomo List; Greg White;
Eduardo Cardona
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
the rfmibv2

Hi,
 
The suggestions to improve the efficiency and order of this mib are
definitely appreciated. Unfortunately we also need to consider that the
present mib is already supported by existing field Docsis
implementations. Is it really possible to move objects from one table to
a new one at this stage? 
 
It is too bad that folks from the IPCDN list can't review mib structure
at the same time changes are being debated functionally on other lists -
in this case it was Nov/Dec 2002 on the 2.0 and oss lists. I really
don't know how to balance the two views, except to have them done
simultaneously. 
 
Very interested to hear opinions both on whether this mib structure can
be adjusted now, and how future mib development can accommodate both
syntactical and functional concerns at once.
 
Thanks,
Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:33 PM
To: 'Woundy, Richard'; 'Raftus, David'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
the rfmibv2
 
Rich,
 
        You make a great point. 
        
        I was looking at it from a implementer point of view and saw the
manadtory group comment in the compliance statement. I.e. the reason for
the email.
        But now that I see it from your point of view, I agree if these
objects are truely "optional" then why must the agent support these
objects. I hinted to that in the earlier email,
        I guess I didn't raise the question because because I truely
didn't understand the context of "optional" in the description of these
objects.
 
        Can I make a suggestion that a new table be created for the
optional objects that aguments the table with the manadtory objects so
that 
        as user using an SNMP Manager does not have figure out the hard
way that some objects are "optional", if the CMTS does not support the
optional objects.
        And in the compliance statement for the CMTS this is clearly
explained.
 
Thanks,
Will Murwin

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; Murwin William-LWM008
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from
the rfmibv2
David and William,
 
I've been meaning to ask this for some time, but... what is the
management value of implementing objects if they don't report "valid"
statistics? Instead, why not make the objects completely optional for
the CMTS (from a specification point of view)?
 
If a management station receives a value of 0 for one of these objects
as specified now, it is not clear whether or not the CMTS is keeping
track of the actual value of the object.

-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
Thanks for the note. It's always surprising to see how well intentioned
words can be seen in another light. As you state, the intent is
mandatory implementation of the objects, but optional counting of the
statistics represented by the objects. I will make your suggested
changes in v7.
Thanks, 
Dave 
************************************ 
David Raftus 
Terayon Canada Ltd 
340 Terry Fox Drive, Suite 202 
Ottawa Canada  K2K 3A2 
[email-masked]           
613.592.1052  ext 222 
************************************               
 
-----Original Message----- 
From: Murwin William-LWM008 [mailto:[email-masked]] 
Sent: Monday, May 05, 2003 3:08 PM 
To: [email-masked]' 
Cc: IPCDN (E-mail) (E-mail) 
Subject: "Optional" in the description of objects from the rfmibv2 
David, 
"...Support for this object is optional. If the object is not supported,
a value of zero is returned." 
Yet in the compliance statement these object belong to the
docsIfCmtsGroupV2 
objects are truly optional then they need not be implemented by the
agent.

<----- 

I believe your intent is for these objects to be implemented by a CMTS
agent, but not mandatory for the agent count these statistics.
I would remove the "optional" comment from the description of each of
these objects and change the text to read "If statistics are not
maintained by the agent, a value of zero is returned for this object."
or something to that nature.
But what really is need is a change to the description for the
docsIfCmtsGroupV2, the comment above the group should be include in the
description. I would go as far as to say these objects are "mandatory"
for a CMTS agent, even though this is not a mandatory-group.
If I have mis-interrupted that these objects are not mandatory for the
CMTS, then a new optional group is needed for the CMTS, just for these
objects.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 30 May 2003 13:59:56 -0600

David,
 
Looking at the RFCs, I don't see the same restriction -- that is, i see no
guidance to force an agent to implement all (or none) of the columns of a
conceptual table.
 
In fact, I found a relevant counter-example: ifXTable in the Interfaces
Group MIB (RFC 2863). This table includes ifName and ifHCInOctets, among
other objects. ifName belongs to the ifGeneralInformationGroup conformance
group (which is mandatory to implement in all conforming implementations),
and ifHCInOctets belongs to the ifHCFixedLengthGroup and ifHCPacketGroup
(which are only conditionally mandatory). A conforming agent with only low
speed interfaces must implement the ifName column but not the ifHCInOctets
column.
 
Going further, you might consider the following section from RFC 2863:
 
3.1.18.  All Values Must be Known
 
   There are a number of situations where an agent does not know the
   value of one or more objects for a particular interface.  In all such
   circumstances, an agent MUST NOT instantiate an object with an
   incorrect value; rather, it MUST respond with the appropriate
   error/exception condition (e.g., noSuchInstance or noSuchName).
 
   One example is where an agent is unable to count the occurrences
   defined by one (or more) of the ifTable counters.  In this
   circumstance, the agent MUST NOT instantiate the particular counter
   with a value of, say, zero.  To do so would be to provide mis-
   information to a network management application reading the zero
   value, and thereby assuming that there have been no occurrences of
   the event (e.g., no input errors because ifInErrors is always zero).
 
   Sometimes the lack of knowledge of an object's value is temporary.
   For example, when the MTU of an interface is a configured value and a
   device dynamically learns the configured value through (after)
   exchanging messages over the interface (e.g., ATM LAN-Emulation
   [20]).  In such a case, the value is not known until after the
   ifTable entry has already been created.  In such a case, the ifTable
   entry should be created without an instance of the object whose value
   is unknown; later, when the value becomes known, the missing object
   can then be instantiated (e.g., the instance of ifMtu is only
   instantiated once the interface's MTU becomes known).
 
   As a result of this "known values" rule, management applications MUST
   be able to cope with the responses to retrieving the object instances
   within a conceptual row of the ifTable revealing that some of the
   row's columnar objects are missing/not available.
 
So, wouldn't we only need to change the MIB conformance statements/groups???
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:28 PM
To: Woundy, Richard; Raftus, David; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2

Rich,

Dave

[email-masked]           
613.592.1052  ext 222

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 4:08 PM
To: 'Raftus, David'; 'Murwin William-LWM008'
Cc: IPCDN (E-mail) (E-mail)
Subject: RE: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
 
David and William,

 
 
-- Rich
-----Original Message-----
From: Raftus, David [mailto:[email-masked]]
Sent: Monday, May 05, 2003 3:19 PM
To: 'Murwin William-LWM008'; Raftus, David
Cc: IPCDN (E-mail) (E-mail)
Subject: [ipcdn] RE: "Optional" in the description of objects from the
rfmibv2
Hi Will, 
 
-----Original Message----- 

Which is described as: