Subject: RE: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt

From: "Edward Beili" <[email-masked]>
Date: Wed, 18 Oct 2006 00:54:43 +0200

Clay,
 
The reason I changed the syntax of ifCapStackStatus and ifInvCapStackStatus objects from a new enum to the RowStatus was to emphasize the similarity between the ifCapStackTable/ifInvCapStackTable and ifStackTable/ifInvStackTable as well as to try to reuse an existing textual convention instead of inventing yet another enum.
 
I don't think making the ifCapStackStatus/ifInvCapStackStatus to be read-only is illegal or problematic - the ifInvStackStatus object from IF-INV-STACK-MIB with a RowStatus syntax is read-only as well.
 
I would also argue that overloading of NotInService value is ok - this value is defined as:
"- 'NotInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device".
Since these tables are static (read-only) there is no question of resource consumption - these rows are never deleted and thus can stay in NotInService state indefinitely. RFC2579 states that "It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be." I can add a sentence in the DESCRIPTION clause saying that an ifCapStackStatus/ifInvCapStackStatus may be in the NotInService state indefinitely, formally complying with RFC2579.
 
However I'm not bent on staying with RowStatus - I'll move back to the enum if the group feels it is best.
 
Regards,
-E.

  _____  

	From: Clay Sikes [mailto:[email-masked]] 
	Sent: Tuesday, October 17, 2006 23:11
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt

	Hi,
	
	I have run into an issue with the ifCapStackStatus and ifInvCapStackStatus objects.  Although the ifCapStackMIB passes smilint, I have seen compilation issues with these objects.  It seems that the root cause is the combination RowStatus  syntax and the read-only max-access (A RowStatus that is read-only seems a bit strange to me).  The compiler does not generate all the code that is required.  Although there may or may not be an issue with the compiler, I would beg that the objects be changed from a RowStatus syntax to a enumeration like what was in the -05 version of the ID.  This may resolve Keith's issue as well.
	
	Thoughts?
	
	Thanks,
	Clay
	
	On 10/17/2006 12:09 PM, Keith McCloghrie wrote: 

			This is a formal WG Last Call for 
			  http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-06.txt

		      ifCapStackStatus  OBJECT-TYPE
		        SYNTAX      RowStatus
		        MAX-ACCESS  read-only
		        STATUS      current
		        DESCRIPTION
		          "The status of the 'cross-connect capability' relationship
		          between two sub-layers. The following values can be returned:
		            active(1)       - indicates that the sub-layer interface,
		                              identified by the ifStackLowerLayer MAY
		                              be connected to run 'below' the sub-layer
		                              interface, identified by the
		                              ifStackHigherLayer index.
		            notInService(2) - the sub-layer interfaces cannot be
		                              connected temporarily due to
		                              unavailability of the interface(s), e.g.
		                              one of the interfaces is located on a
		                              pluggable module which is absent.
		
		I suggest this is an ill-advised overloading of 'notInService'.
		RFC 2579 says:
		
		            If the management station is prevented from setting the
		            status column to `active' (e.g., due to management station
		            or network failure) the conceptual row will be left in the
		            `notInService' or `notReady' state, consuming resources
		            indefinitely.  The agent must detect conceptual rows that
		            have been in either state for an abnormally long period of
		            time and remove them.  It is the responsibility of the
		            DESCRIPTION clause of the status column to indicate what an
		            abnormally long period of time would be.  This period of
		            time should be long enough to allow for human response time
		            (including `think time') between the creation of the
		            conceptual row and the setting of the status to `active'.
		            In the absence of such information in the DESCRIPTION
		            clause, it is suggested that this period be approximately 5
		            minutes in length.  This removal action applies not only to
		            newly-created rows, but also to previously active rows which
		            are set to, and left in, the notInService state for a
		            prolonged period exceeding that which is considered normal
		            for such a conceptual row.
		
		In other words, the 'notInService' of RowStatus is for a temporary
		delay in a management station setting it to `active'.  The "temporary"
		situation of a "pluggable module which is absent" is liable to be
		much longer than the 5 minutes before the agent is required to delete
		the row.
		
		Keith.
		
		_______________________________________________
		Hubmib mailing list
		[email-masked]
		https://www1.ietf.org/mailman/listinfo/hubmib

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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 18 Oct 2006 14:47:00 +0200

I hve not completely studied this specific RowStatus issue yet.
But I tend to agree that the way it is used here is not as was (in my view)
intended in RFC2579. The intetion is to control row creation/modification/deletion.
And clearly that is not the way it is used here.
 
I am checking with the MIB doctors team as to what their view is... so bear with
me for a little while, after which I will come back to this topic.
 
Bert

-----Original Message-----
From: Clay Sikes [mailto:[email-masked]]
Sent: Tuesday, October 17, 2006 23:11
To: [email-masked]
Cc: Keith McCloghrie; [email-masked]
Subject: Re: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt

Hi,

Thoughts?

Thanks,
Clay

   http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-06.txt <http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-06.txt> 

        SYNTAX      RowStatus

        MAX-ACCESS  read-only

        STATUS      current

        DESCRIPTION

RFC 2579 says:

the row.

Keith.

Hubmib mailing list

[email-masked] <mailto:[email-masked]> 

https://www1.ietf.org/mailman/listinfo/hubmib <https://www1.ietf.org/mailman/listinfo/hubmib>

---

From: "Edward Beili" <[email-masked]>
Date: Wed, 18 Oct 2006 14:56:32 +0200

Moti,
I agree with your comments. Thanks for catching it.
Regards,
-E. 

> From: Moti Morgenstern [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2006 7:07 PM
> To: Wijnen, Bert (Bert); Hubmib Mailing List (E-mail)
> Subject: RE: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt
> 
> 
> Hi,
> 
> 1) A minor issue regarding to 'on top of'
>     - In the ifCapStackTable's description 
>       = It first appears as: ...possible 'on top of'...
>       = then: ...run 'on top of'... (which is same as the first)
>       = but then: ...run on top of... (should be: run 'on top of')
> 2) Again, regarding to 'on top of' but this time more important
>     - In the ifCapStackEntry's description 
>       = It appears as: ...runs on 'top' of
>          which I assume should be changed to: MAY run 'on top of'...
> 3) In the ifCapStackEntry's description, shouldn't the sentence in 
>     parentheses be "(interface index for higher- and lower-layer
> respectively)?
> 4) Explaining the value 'active' for ifCapStatusStack 
>     = The MINIMUM change required is using the term 
> 'underneath' isntead
>        of 'below'.
>     =  It is recommended, however, to perform a deeper change, because
> the
>         ifCapStackTable is actually from the p.o.v. of the 
> HIGHER layer.
> The
>         proposed text would be "indicates that the sub-layer 
> interface,
>         identified by the ifStackHigherLayer MAY be connected to run
>         'on top of' the sub-layer interface, identified by the
> ifStackLowerLayer index."
>  
> Regards,
> Moti M
>

---

From: "Edward Beili" <[email-masked]>
Date: Wed, 18 Oct 2006 17:53:10 +0200

Bert,
I would like to have 2 values - one for possibility and the other, for "possible but not available", e.g. if the interface is unplugged.
I guess I would return back to the way it was done in the -05 version - a new enum with 2 values.

Regards,
-E.

> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 5:45 PM
> To: Edward Beili
> Cc: [email-masked]; Keith McCloghrie; [email-masked]
> Having looked at the MIB itself now, it seems to me that
> the object
> would be much better represented by 
>       ifCapStackPossible  OBJECT-TYPE
>         SYNTAX      TruthValue
> where 'true' means it CAN be stacked this way and 'false' means
> it cannot. That way you re-use an existing TC, and you can 
> exactly represent what you need, no?
> 
> Same for ifInvCapStackStatus
> 
> Bert
> 
> 
> > From: Keith McCloghrie [mailto:[email-masked]]
> > Sent: Wednesday, October 18, 2006 16:41
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]
> > > The reason I changed the syntax of ifCapStackStatus and 
> > > ifInvCapStackStatus objects from a new enum to the 
> RowStatus was to 
> > > emphasize the similarity between the 
> > ifCapStackTable/ifInvCapStackTable 
> > > and ifStackTable/ifInvStackTable as well as to try to reuse 
> > an existing 
> > > textual convention instead of inventing yet another enum.
> >  
> > The motivation is good but it's only valid if the semantics match.
> > 
> > > I don't think making the 
> ifCapStackStatus/ifInvCapStackStatus to be 
> > > read-only is illegal or problematic - the ifInvStackStatus 
> > object from 
> > > IF-INV-STACK-MIB with a RowStatus syntax is read-only as well.
> >  
> > The ifInvStackTable table has exactly the same structure 
> and content,
> > and exactly the same number of rows as the ifStackTable.  
> > Semantically,
> > ifInvStackStatus *could* be read-create, but if it were, a 
> SetRequest
> > to ifStackStatus and a SetRequest to ifInvStackStatus would have
> > exactly the same result, i.e., to make it read-create would be
> > redundant because it would provide two means of achieving the same
> > behaviour.  So, making it read-only is a simplification.
> > 
> > > I would also argue that overloading of NotInService value 
> > is ok - this 
> > > value is defined as:
> > > "- 'NotInService', which indicates that the conceptual row 
> > exists in the 
> > > agent, but is unavailable for use by the managed device".
> > 
> > 'notInService' is "unavailable for use by the managed 
> device" because
> > it normally requires an SNMP operation on a RowStatus object 
> > to make it
> > available.  Normally, the necessary operation is on the 
> same RowStatus
> > object but in the case of ifInvStackStatus (see above comment on
> > simplification), the operation needs to be on ifStackStatus.  In
> > contrast,
> > 
> >                               unavailability of the interface(s), 
> > 
> > The semantics are different here.  It is not an SNMP operation on a
> > RowStatus object which prevents this row from being 
> "available for use
> > by the managed device".
> > 
> > > Since these tables are static (read-only) there is no question of 
> > > resource consumption - these rows are never deleted and 
> > thus can stay in 
> > > NotInService state indefinitely. RFC2579 states that "It is the 
> > > responsibility of the DESCRIPTION clause of the status column to 
> > > indicate what an abnormally long period of time would be." 
> > I can add a 
> > > sentence in the DESCRIPTION clause saying that an 
> > > ifCapStackStatus/ifInvCapStackStatus may be in the 
> > NotInService state 
> > > indefinitely, formally complying with RFC2579.
> >  
> > ifInvStackStatus *could* semantically be read-create, but 
> is read-only
> > so as to remove redundancy.  In contrast, it is the semantics of
> > ifCapStackStatus and ifInvCapStackStatus which prevent them 
> from being
> > read-create.
> > 
> > Keith.
> > 
> > > However I'm not bent on staying with RowStatus - I'll move 
> > back to the 
> > > enum if the group feels it is best.
> > > 
> > > Regards,
> > > -E.
> > > 
> > >   _____ 
> > > 
> > > > I have run into an issue with the ifCapStackStatus and 
> > > ifInvCapStackStatus objects.  Although the ifCapStackMIB 
> > passes smilint, 
> > > I have seen compilation issues with these objects.  It 
> > seems that the 
> > > root cause is the combination RowStatus  syntax and the read-only 
> > > max-access (A RowStatus that is read-only seems a bit 
> > strange to me).  
> > > The compiler does not generate all the code that is 
> > required.  Although 
> > > there may or may not be an issue with the compiler, I would 
> > beg that the 
> > > objects be changed from a RowStatus syntax to a enumeration 
> > like what 
> > > was in the -05 version of the ID.  This may resolve Keith's 
> > issue as 
> > > well.
> > > 
> > > > Thoughts?
> > > 
> > > > Thanks,
> > > > Clay
> > >

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 18 Oct 2006 17:44:48 +0200

Bert

> > ifInvCapStackStatus objects from a new enum to the RowStatus was to 
> > I don't think making the ifCapStackStatus/ifInvCapStackStatus to be 
> The ifInvStackTable table has exactly the same structure and content,
> ifInvStackStatus *could* be read-create, but if it were, a SetRequest
> 'notInService' is "unavailable for use by the managed device" because
> available.  Normally, the necessary operation is on the same RowStatus
> RowStatus object which prevents this row from being "available for use
> by the managed device".
> 
> ifInvStackStatus *could* semantically be read-create, but is read-only
> ifCapStackStatus and ifInvCapStackStatus which prevent them from being
> read-create.
> 
> Keith.
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 31 Oct 2006 20:24:22 +0200

Section 3.1.3 refers to 'SNMP agent' and Table 2 has a columns named
'SNMP objects. In reality this document defines SMIv2 MIB modules that
could be used in theory with other protocols, not only with SNMP. I
would suggest more neutral terminology to be used ('management agent',
'SMIv2 objects'). 

Dan

> Sent: Tuesday, October 17, 2006 5:12 PM
> To: Hubmib Mailing List (E-mail)
> Subject: [Hubmib] WGLC for: draft-ietf-hubmib-efm-cu-mib-06.txt
> 
> [bcc to adslmib wg. Pls comment on the hubmib WG mailing list.
>  if needed, the adslmib wg chairs can collect and summarize  
> comments as well and then post it to the HUBMIB WG list.]
> 
> WG LC ends on October 31st, any timezone.
> 
> Following WGLC of revision 05, a set of changes was required, 
> including moving the ifAvailableStackTable to a distinct MIB 
> module (say IF-AVAILABLE-STACK-MIB, seating directly under
> MIB-2) and adding an inverse table ifInvAvailableStackTable, 
> which would allow the ADSL MIB WG to refer and re-use them. 
> I suggested that after a revised I-D is available the WG 
> would do a fast track LC to approve the changes. 
> 
> Revision 6 was posted on Oct 12th to address the above.
> 
> Bert
>