Subject: [eman] FW: New Version Notification for draft-chandramouli-eman-rfc4133bis-00.txt

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 3 Jul 2012 05:15:25 +0000

Hello all, 

Based on the discussions at the last IETF on the possible extension to ENTITY MIB given the requirements from EMAN WG, 
a new draft has been submitted. 

http://www.ietf.org/id/draft-chandramouli-eman-rfc4133bis-00.txt

The modifications are:  

 - entPhysicalClass to be an IANA controlled list   
 - a smaller set of ENTITY MIB objects for compliance with  ENTITY-MIB 
 - entPhysicalUris to be read-only object  
 
Please refer to the discussion   

http://www.ietf.org/mail-archive/web/eman/current/msg01372.html

There are two MIB modules. 
The first MIB module is an extension of the Entity MIB and the second MIB module - IANA-ENTITY-MIB has the enumeration for the entPhysicalClass TC.

Please let us know your comments. 

Thanks
Andy, Dan, Juergen and Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2012 10:32 AM
To: Mouli Chandramouli (moulchan)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-chandramouli-eman-rfc4133bis-00.txt

A new version of I-D, draft-chandramouli-eman-rfc4133bis-00.txt
has been successfully submitted by Mouli Chandramouli and posted to the
IETF repository.

Filename:	 draft-chandramouli-eman-rfc4133bis
Revision:	 00
Title:		 Entity MIB (Version 4)
Creation date:	 2012-07-03
WG ID:		 Individual Submission
Number of pages: 65
URL:             http://www.ietf.org/internet-drafts/draft-chandramouli-eman-rfc4133bis-00.txt
Status:          http://datatracker.ietf.org/doc/draft-chandramouli-eman-rfc4133bis
Htmlized:        http://tools.ietf.org/html/draft-chandramouli-eman-rfc4133bis-00

Abstract:
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 multiple
logical and physical entities managed by a single SNMP agent. This
document specifies version of the Entity MIB, which obsoletes version 3
(RFC 4133).

The IETF Secretariat

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jul 2012 08:24:28 +0200

>  - entPhysicalUris to be read-only object  

Why is the initial IANA-ENTITY-MIB not in the I-D? The name change
ENTITY-MIB -> ENTITY-v4-MIB seems to work against how we do versioning
in SNMP land. Furthermore, you can't simply change entPhysicalClass to
entIANAPhysicalClass. And what is the point of compliance statements
like this:

        OBJECT entPhysicalMfgDate
        MIN-ACCESS   not-accessible
        DESCRIPTION
            "Read and write access is not required for agents that
            implement version 4 of the Entity MIB on devices with
            constrained resources."

Note that entPhysicalMfgDate is read-only anyway, so the description
text does not make sense. (This applies to multiple definitions in the
new conformance definition.) If your idea is to make the object
optional, do not include in the groups you require. Furthermore, the
entity mib version should not be in the description clause. And
finally, what is "constrained resources" (given that we talk about a
static read-only object). I am also not sure the size restriction for
entPhysicalUris is meaningful in the way it is described:

        OBJECT entPhysicalUris
        SYNTAX Uri  (SIZE (0 | 45))
        MIN-ACCESS   read-only
        DESCRIPTION
            "Write access is not required for agents that
            implement version 4 of the Entity MIB on devices with
            constrained resources.

            Size is constrained to 45 to allow only for RFC 4122
            [RFC4122] compliant values and 0 for cases when the
            object is not instantiated."

You seem to imply "constrained resources" -> the only value of
entPhysicalUris is a UUID. I am not sure this is a valid assumption.

Have your co-authors who are MIB aware reviewed this document?

/js

PS: If this MIB gets revised, I personally would rather add an
    entPhysicalUUID object with a compact UUID representation instead
    of using the verbose URI format.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 3 Jul 2012 08:28:17 +0000

Hello Juergen,

Thanks for the immediate response. I have some replies now. More later. 

Thanks
Mouli 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2012 11:54 AM
To: Mouli Chandramouli (moulchan)
Cc: [email-masked]
Subject: Re: [eman] FW: New Version Notification for draft-chandramouli-eman-rfc4133bis-00.txt

>  - entPhysicalUris to be read-only object  

Why is the initial IANA-ENTITY-MIB not in the I-D? 

[ycm] I had included IANA-ENTITY-MIB as an attachment to the email. I was not sure if that MIB should be part of this ID ? 
[ycm] Looking at an example like  http://www.iana.org/assignments/ianaiftype-mib/ is a separate module 

The name change
ENTITY-MIB -> ENTITY-v4-MIB seems to work against how we do versioning
in SNMP land. 
[ycm] ok, I see your point. 

Furthermore, you can't simply change entPhysicalClass to
entIANAPhysicalClass. 
[ycm] Instead of a fixed list, an IANA controlled list would make it flexible to add new objects (sub-compoents) in the containment of a device ? 

And what is the point of compliance statements
like this:

Note that entPhysicalMfgDate is read-only anyway, so the description
text does not make sense. (This applies to multiple definitions in the
new conformance definition.) If your idea is to make the object
optional, do not include in the groups you require. 
[ycm] let me respond later. 

Furthermore, the

        OBJECT entPhysicalUris

You seem to imply "constrained resources" -> the only value of
entPhysicalUris is a UUID. I am not sure this is a valid assumption.
[ycm]  I thought one of things we (EMAN) wanted was a read-only UUID and this was a solution. 

Have your co-authors who are MIB aware reviewed this document?
[ycm] Yes. We wanted to get a first draft before the deadline for discussion.  

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jul 2012 11:04:11 +0200

Hi Juergen,

A few questions/responses in-line. 

Thanks and Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Juergen Schoenwaelder
> Sent: Tuesday, July 03, 2012 9:24 AM
> Subject: Re: [eman] FW: New Version Notification for
draft-chandramouli-
> eman-rfc4133bis-00.txt
> 
> On Tue, Jul 03, 2012 at 05:15:25AM +0000, Mouli Chandramouli
(moulchan)
> wrote:
> > Hello all,
> >
> > Based on the discussions at the last IETF on the possible extension
to
> ENTITY MIB given the requirements from EMAN WG,

[[DR]] Our mistake, it should have been included. No reason for separate
I-D for the new TC. 

[[DR]] > The name change
> ENTITY-MIB -> ENTITY-v4-MIB seems to work against how we do versioning

[[DR]] OK. 

> Furthermore, you can't simply change entPhysicalClass to

[[DR]] Why? We replace in the SYNTAX of the respective objects a TC with
another TC which is an enumeration superset. There is no backwards
incompatibility problem. 

> optional, do not include in the groups you require. 

[[DR]] Is there anything wrong or not working with the way the
compliance are written now, or just a style issue? The compliance
statements seem much simpler expressed this way instead of defining new
groups, actually it seems to me that we would need to break and re-build
existing groups and the compliance statements for previous versions of
the MIB module. 

> Furthermore, the
> entity mib version should not be in the description clause. 
[[DR]] OK. 

> And
> static read-only object). 
> I am also not sure the size restriction for
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jul 2012 11:32:23 +0200

> another TC which is an enumeration superset. There is no backwards

I wrote entPhysicalClass and this is the name (aka descriptor) of a
published object. This got changed to entIANAPhysicalClass.
 
> existing groups and the compliance statements for previous versions of

Exactly, you define new groups. Its cheap.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jul 2012 11:37:47 +0200

> Exactly, you define new groups. Its cheap.

[[DR]] I am not sure what 'cheap' means, and especially for whom -
changing the compliance clauses for the previous and hopefully deployed
versions of the MIB module may be a problem for people already using it.

And you did not answer my question :-) is there anything wrong or not
working with the way the compliance clauses are written in this version
of the draft? 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jul 2012 14:04:30 +0200

> versions of the MIB module may be a problem for people already using it.

I wrote "new groups" - adding groups hardly has an impact on any old
definitions. Sorry if I have not been clear enough.
 
> working with the way the compliance clauses are written in this version

For me, there is a difference in stating "to be compliant, you have to
implement a certain object but not provide any access to it" and "to
be compliant, you do not need to implement a certain object". The
second statement is clear and fits the RFC 2580 model of objects
listed in mandatory groups and optional groups.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jul 2012 14:08:39 +0200

> Sent: Tuesday, July 03, 2012 3:05 PM
> To: Romascanu, Dan (Dan)
> Cc: Mouli Chandramouli (moulchan); [email-masked]
draft-chandramouli-
> > > > statements seem much simpler expressed this way instead of
> defining
> > > new
> > > > groups, actually it seems to me that we would need to break and
> re-
> > > build
> > > > existing groups and the compliance statements for previous
> versions
> > of
> > > > the MIB module.
> > >

[[DR]] This would lead to some MIB objects showing up in two conformance
groups (they are already in the old compliance group, and we want to
support them also in the groups for v4). Is this allowed? 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jul 2012 14:18:33 +0200

> support them also in the groups for v4). Is this allowed? 

Sure, we do that all the time (I think). See for example ifDescr in
both ifGeneralInformationGroup and ifGeneralGroup of the IF-MIB (the
status has no impact and there really is nothing in RFC putting any
constraints there).

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jul 2012 18:43:44 +0200

OK, thanks Juergen for the comments, I think that I understand now the
edits based on them for the MIB module. 

Are there other comments beside Juergen's? I suggest that we wait a few
more days. 

Dan

> Sent: Tuesday, July 03, 2012 3:19 PM
> To: Romascanu, Dan (Dan)
draft-chandramouli-

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 Jul 2012 19:04:13 +0200

> Are there other comments beside Juergen's? I suggest that we wait a few

Please also read the text. There is a section where the title starts
into the first sentence of the paragraph or something like
that. Juergen Quittek also once wrote that there is lots of work he
already started to make the text comply with the latest SNMP
terminology.  Has any of this been incorporated?

/js