Subject: [MIB-DOCTORS] rwn for MIB specifications?

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 11:51:05 +0100

Dear all,

Is there some standard text to explain what  "rwn" (read, write, notify) 
for object trees mean?
For example:

   +- eoTable(2)
            |
            +- eoEntry(1) [entPhysicalIndex]
            |  |
            |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
            |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
            |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
            |  +-- rwn MacAddress                   eoMgmtMacAddress(4)
            |  +-- r-n InetAddressType              eoMgmtAddressType(5)
            |  +-- r-n InetAddress                  eoMgmtAddress(6)
            |  +-- r-n SnmpAdminString              eoMgmtDNSName(7)
            |  +-- rwn SnmpAdminString              eoDomainName(8)
            |  +-- rwn SnmpAdminString              eoRoleDescription(9)
            |  +-- rwn EnergyObjectKeywordList      eoKeywords(10)
            |  +-- rwn Integer32                    eoImportance(11)
            |  +-- r-n INTEGER                      eoPowerCategory(12)
            |  +-- rwn SnmpAdminString              eoAlternateKey(13)
            |  +-- r-n INTEGER                   eoPowerInterfaceType(14)

Regards, Benoit

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 24 Jan 2014 11:14:12 +0000

Hi Benoit, 
I have not seen any text documenting this format in a standards document, yet.
The obvious meaning of the three symbols is a compressed representation of the object's MAX-ACCESS clause which may have the following values: 
    "not-accessible"->"---"
    "accessible-for-notify"->"--n"
    "read-only"->"r-n"
    "read-write"->"rwn"
    "read-create"->"rwn" (why not "rcn"?)
Juergen

> -----Original Message-----
> From: Benoit Claise [mailto:[email-masked]]
> Sent: Freitag, 24. Januar 2014 11:51
> To: MIB Doctors (E-mail)
> Cc: [email-masked]; draft-ietf-eman-
> [email-masked]
> Subject: rwn for MIB specifications?
> 
> Dear all,
> 
> Is there some standard text to explain what  "rwn" (read, write, notify) for
> object trees mean?
> For example:
> 
>   +- eoTable(2)
>            |

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 12:27:40 +0100

Hi Jürgen,
>      "read-create"->"rwn" (why not "rcn"?)
Maybe that's all that we need to explain.

Regards, Benoit
> .

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Jan 2014 10:25:25 -0500

I think that it is useful to put that into the draft to avoid any confusion.

	--Tom

On Jan 24, 2014:6:14 AM, at 6:14 AM, Juergen Quittek <[email-masked]> wrote:

> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 24 Jan 2014 16:06:29 +0000

There are several MIB modules out in RFCs using the tree format of smidump. None of them had a clear documentation of the format and I have not yet seen any full documentation of that format anywhere. 

I think it is the right way to describe it and be clear about what is meant. But if we do so, we should document the entire tree format including things such as the index in brackets ("[entPhysicalIndex]").

An alternative would be to label the figure as "smidump-style" tree presentation of a MIB module or a table within a MIB module.

    Juergen

> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Freitag, 24. Januar 2014 16:25
> To: Juergen Quittek
> Cc: Benoit Claise; MIB Doctors (E-mail); draft-ietf-eman-energy-monitoring-
> [email-masked]; [email-masked]
> Subject: Re: [MIB-DOCTORS] rwn for MIB specifications?
> 
> 
> > The obvious meaning of the three symbols is a compressed representation of
> the object's MAX-ACCESS clause which may have the following values:
> >    "not-accessible"->"---"
> >    "read-create"->"rwn" (why not "rcn"?) Juergen
> >
> >> Cc: [email-masked];
> >> draft-ietf-eman- [email-masked]
> >> Is there some standard text to explain what  "rwn" (read, write,
> >> notify) for object trees mean?
> >> For example:
> >>
> >>  +- eoTable(2)
> >>           |

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 24 Jan 2014 11:10:30 -0500

but again you would have to explain what "smidump format" is or provide a reference to somewhere where one could look it up.

Tom 

> On Jan 24, 2014, at 11:06 AM, Juergen Quittek <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jan 2014 18:17:27 +0100

>     "read-create"->"rwn" (why not "rcn"?)

The libsmi internally has the 'create' bit on the conceptual row and
not on all conceptual columns like the SMIv2 syntax has it. And as a
consequence, the read-create objects get marked "rwn". And since 'row'
and 'table' nodes do not have access bits in the tree format, the
'create' bit somehow is not shown. From an SMIv2 viewpoint, this
surely looks surprising and "read-create"->"rcn" would likely be a
better solution.

... tak tak tak ...

Turns out it is a two line change to make libsmi generate "rcn"
instead of "rwn". I can be convinced to commit this change if people
think this is a good idea.

There really is no definition of the tree format (but there probably
should be). I also changed it a while ago the format so that it lines
up with the YANG tree format we use (which again was inspired by
smidump's tree format). Smidump's output right now looks like this:

---- snmpCommunityMIB(1.3.6.1.6.3.18)
  +---- snmpCommunityMIBObjects(1)
     +---- snmpCommunityTable(1)
        +---- snmpCommunityEntry(1) [*snmpCommunityIndex]
           +---- snmpCommunityIndex(1)           SnmpAdminString
           +-rcn snmpCommunityName(2)            OctetString
           +-rcn snmpCommunitySecurityName(3)    SnmpAdminString
           +-rcn snmpCommunityContextEngineID(4) SnmpEngineID
           +-rcn snmpCommunityContextName(5)     SnmpAdminString
           +-rcn snmpCommunityTransportTag(6)    SnmpTagValue
           +-rcn snmpCommunityStorageType(7)     StorageType
           +-rcn snmpCommunityStatus(8)          RowStatus

Note that the object descriptor is now always at the same place. One
could consider also consider dropping the OID numbers - for an
overview, these numbers are not really important and they clutter
things up quite a bit. Compare to this:

---- snmpCommunityMIB
  +---- snmpCommunityMIBObjects
     +---- snmpCommunityTable
        +---- snmpCommunityEntry [*snmpCommunityIndex]
           +---- snmpCommunityIndex           SnmpAdminString
           +-rcn snmpCommunityName            OctetString
           +-rcn snmpCommunitySecurityName    SnmpAdminString
           +-rcn snmpCommunityContextEngineID SnmpEngineID
           +-rcn snmpCommunityContextName     SnmpAdminString
           +-rcn snmpCommunityTransportTag    SnmpTagValue
           +-rcn snmpCommunityStorageType     StorageType
           +-rcn snmpCommunityStatus          RowStatus

Should we have such a discussion here?

/js

-- 
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: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Jan 2014 12:22:58 -0500

> Should we have such a discussion here?

	That is cool. I think its a good idea to recommend that such trees be included in the documents.  

	--Tom

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 24 Jan 2014 09:49:07 -0800

I think it's great to have summary/overview tables like this up front to 
help people visualize the MIB.

I think the 'notify' flag could be misleading. It implies that notify 
access could be removed and that it's a separate concept from read access.

Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jan 2014 19:37:11 +0100

On Fri, Jan 24, 2014 at 09:49:07AM -0800, Steve Waldbusser wrote:
> I think it's great to have summary/overview tables like this up
> front to help people visualize the MIB.
> 
> I think the 'notify' flag could be misleading. It implies that
> notify access could be removed and that it's a separate concept from
> read access.

The n flag allows to represent accessible-for-notify: --n

/js

---

From: Steve Waldbusser <[email-masked]>
Date: Fri, 24 Jan 2014 10:53:33 -0800

> The n flag allows to represent accessible-for-notify: --n

Yes, I understand that. It's just a poor way to denote it because it is 
not, in fact, independent of read access. For example r-- can never 
happen. Having the extra flag implies it can happen. I don't want people 
thinking it could possible make protocol sense to have an object that 
could be read but couldn't be included in a notification.

We could delete the last flag and have:
    "not-accessible"->"---"
    "accessible-for-notify"->"n-"
    "read-only"->"r-"
    "read-write"->"rw"
    "read-create"->"rc"

Steve

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 24 Jan 2014 22:40:27 +0100

On Fri, Jan 24, 2014 at 10:53:33AM -0800, Steve Waldbusser wrote:
> Yes, I understand that. It's just a poor way to denote it because it
> is not, in fact, independent of read access. For example r-- can
> never happen. Having the extra flag implies it can happen. I don't
> want people thinking it could possible make protocol sense to have
> an object that could be read but couldn't be included in a
> notification.
> 

>From an SMIv2 perspective, this may make sense. Note that libsmi also
implements support for SPPI and SPPI has a slightly different
PIB-ACCESS and I would have to find two flag notations for PIB-ACCESS
values as well (e.g., install "i-", notify "n-", install-notify "in",
report "-r"). Well, since nobody really seems to use SPPI (measured in
terms of the bug reports we received for the SPPI frontend), this
likely does not matter much to anyone.

/js

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 23:39:22 +0100

This format below makes a lot of sense.
And I find Steve proposal to remove is an improvement.
Now, we would need some standard text to explain the format. We could 
put on the MIB doctors WIKI.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Jan 2014 23:53:01 +0100

> And I find Steve proposal to remove is an improvement.
And I find Steve's proposal to remove  "n" an improvement.
>> On Jan 24, 2014:12:17 PM, at 12:17 PM, Juergen Schoenwaelder<[email-masked]>  wrote:
>>
>>> Fax:   +49 421 200 3103<http://www.jacobs-university.de/>