Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB

From: Margaret Wasserman <[email-masked]>
Date: Sat, 07 Feb 2004 08:06:48 -0500

Hi All,

Could others please express their opinions on this issue?  Who
believes that these TCs should use a prefix (e.g. EntityOperStatus)
and why?  Who think that they should not include a prefix, and why?

Since we are not planning to meet in Seoul, it is important to
close this issue on the mailing list.

Thanks,
Margaret

At 02:34 PM 2/6/2004 -0500, Sharon Chisholm wrote:
>Hi
>
>I've created issue 322 to track this.
>
>The intention in creating the textual conventions was that they could be
>used in other MIBs that wanted to define state/status objects. Prefixing
>them with Entity makes this less obvious.
>
>Sharon
>
>-----Original Message-----
>From: Andy Bierman [mailto:[email-masked]]
>Sent: Friday, February 06, 2004 12:26 PM
>To: Wijnen, Bert (Bert)
>Cc: 'Margaret Wasserman'; [email-masked]
>Subject: RE: REMINDER: [Entmib] WG Last Call: Entity State MIB
>
>
>At 03:30 AM 2/6/2004, Wijnen, Bert (Bert) wrote:
> >> Given that this is a second WG Last Call for this document, that
> >> several people reviewed it during the previous WG Last Call, and that
> >> Sharon did a great job of maintaining an issue list and documenting
> >> the resolution of each issue, I am planning to interpret silence as
> >> agreement to send this document to the IESG.
> >>
> >I do not want to step on the toes of our WG chair, but yet... I would
> >actually appreciate if the people who spoke up (a while ago) that the
> >MIB was too complex, that they do state if they are now OK with this
> >version!
> >
> >PLEASE PARTICIPATE and express your opinion.
>
>comment on the MIB itself...
>
>the TCs should be named with a prefix. E.g.,
>OperState -> EntityOperState.  This applies to
>all the TCs in the draft.
>
>Andy
>
>
>_______________________________________________
>Entmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/entmib
>
>_______________________________________________
>Entmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/entmib

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

---

From: Subrahmanya Hegde <[email-masked]>
Date: Sat, 07 Feb 2004 06:52:26 -0800

Hi

Following comments were sent on 1/11/2004: But it is not taken care in 
the latest draft.
Hoping some one is carrying as part of Editorial fix
******
a Minor Suggestion:

Instead of having these OID definitions:

-- Notifications

  entStateTraps      OBJECT IDENTIFIER ::= { entityStateMIB 2 }
  entStateTrapPrefix OBJECT IDENTIFIER ::= { entStateTraps 0 }

We can have
entStateNotifs OBJECT IDENTIFIER ::= { entityStateMIB 0 }

and use 'entStateNotifs' in the corresponding NOTIFICATION-TYPE

Reason we would like to avoid name 'Traps' is: Latest RFCs refer them
as Notifications

Also, above OID tree structure will be inline with mib review guidelines 
document:
draft-ietf-ops-mib-review-guidelines-02.txt

**** 1/11/2004 comment ends

2. Regarding TC Names:
I would like to see TC with prefix  (for example: EntityOperStatus, 
EntityUsage state etc)

Reason(s) are :
  * It is obivious it is related to Entities
  * I don't think having a Generic TC 'OperState' automatically means it 
can be used outside the context of  Entity. Reason being other MIBs 
might need more than what is defined in this TC or most of them may not 
be applicable in some cases

TC name from 'review guideline draft says"
**
- Names of TCs that are specific to the MIB module and names of
     SEQUENCE types that are used in conceptual table definitions should
     start with a prefix Xxx that is the same as xxx but with the
     initial letter changed to upper case.  OPT-IF-MIB uses the prefix
     OptIf on the names of TCs and SEQUENCE types.
***

3. As per the MIB convention : We should define a OID under 
'entStateObjects'
  and use that in the xxxTable.
For example:
   entStateObjects OBJECT IDENTIFIER ::= { entityStateMIB 1}

add:
    entityState OBJECT IDENTIFIER ::= { entStateObjects 1}
use this 'entityState'(or whatever else makes sense) for entStateTable 
in the mib

4. entStateConformance must be under { entityStateMIB 2}

3.  I think OID definition for 'entityStateGroups' is missing
it should be
  entStateGroups OBJECT IDENTIFIER ::= { entStateConformance 2}

Thanks
Subra

---

From: Subrahmanya Hegde <[email-masked]>
Date: Sat, 07 Feb 2004 06:52:26 -0800

Hi

-- Notifications

We can have

2. Regarding TC Names:

Reason(s) are :

add:

Thanks
Subra