Subject: Re: [Isms] my review of:

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Sep 2007 09:22:36 +0200

On Wed, Aug 08, 2007 at 04:57:57PM +0200, Wijnen, Bert (Bert) wrote:
> Just nits I think.
> 
> 
> - Sect 2.4, 5th line
>    to the appropriate Transport Model through a series of APIs, as
>   s/API/ASI/ !!??
> 
>   also one but last line in sect 2.4
>    a series of APIs, as described in "Transport Subsystem for the Simple
>   s/API/ASI/ !!??

Yes, seems an editorial fix to me.
 
> - section 6:     6.  Overview
> 
>   Maybe change that section title to MIB Module Overview?
> 
> -        ::= { snmpModules xxxx }
> 
>   Is there a good reason to put this underneath that snmpModules branch?
>   I do understand we have the snmpUsmMIB (so to be consistent this one
>   should be named snmpTsmMIB) and related MIB modules under snmpModules.
>   So from that point it makes sense.
> 
>   But we have stated (in RFC4181) that an OID is just an OID and
>   MIB modules should go under mib-2. 
>   And we have no-where specified IANA guidelines as to how/when to
>   assign new values under snmpModules.
> 
>   I know that some other WG wants to put their MIB modules under a 
>   common branch of their own as well... and they are (as we speak)
>   getting push-back from our AD.

The question is why we have snmpModules in the first place and whether
we continue to root SNMP modules under snmpModules or treat them as
all other modules. The SNMP-USM-AES-MIB was probably the last one
rooted under snmpModules - so SNMP addons have been rooted in the not
too distant past. I suggest Dan provides advise whether we continue to
use snmpModules or declare that we declare snmpModules was a bad idea
and we stop assigning things below snmpModules (and perhaps this can
then be documented in the IANA documents so we don't forget about this
and we can make tools to check for this).

I am fine with changing tsmMIB to snmpTsmMIB.

> -    tsmInvalidCache OBJECT-TYPE
>        SYNTAX       Counter32
>        MAX-ACCESS   read-only
>        STATUS       current
>        DESCRIPTION "The number of messages dropped because the
>                     tmStateReference referred to an invalid cache.
> 
>                     This value is not persistent across reboots.
>                    "
>        ::= { tsmStats 1 }

Perhaps rename to tsmInvalidCacheReferences?

>      tsmInadequateSecurity OBJECT-TYPE
>        SYNTAX       Counter32
>        MAX-ACCESS   read-only
>        STATUS       current
>        DESCRIPTION "The number of incoming messages dropped because
>                     the actual securityLevel provided was less than
>                     the requested securityLevel.
> 
>                     This value is not persistent across reboots.
>                    "
>        ::= { tsmStats 2 }

Perhaps rename to tsmInadequateSecurityLevels?

>   According to our CLRs, the names/descriptors should express plurality.
>   Not that I cannot live with them being named as is? Just that we as
>   MIB doctors should probably follow our own CLRs.
> 
>   I do not understand why we need to say something about "persistency"?
>   We May want to state that discontinuties only can occur at a reboot
>   or restart of the agent?

I suggest to simply drop the sentences about persistence since the
default in SNMP land is that counters do not persist across reboots
(or at least sysUpTime will indicate a discontinuity).

> - I also see:
> 
>   tsmGroups OBJECT IDENTIFIER ::= { tsmConformance 1 }
>   tsmCompliances OBJECT IDENTIFIER ::= { tsmConformance 2 }
> 
> 
>   While RFC4181 suggests:
> 
>        xxxMIB
>        |
>        +-- xxxNotifications(0)
>        +-- xxxObjects(1)
>        +-- xxxConformance(2)
>            |
>            +-- xxxCompliances(1)
>            +-- xxxGroups(2)
> 
>   So first compliances, then groups.

OK, lets just flip the two things.

> - I get somehwat worried when following (In IANA Considerations
> section):
> 
>   2.  a value, preferably 4, to identify the Transport Security Model,
>       in the Security Models registry at
>       http://www.iana.org/assignments/snmp-number-spaces.  This should
> 
>    Because if you go to http://www.iana.org/assignments/smi-numbers and
>    search for "SNMP Management Architecture:" you will find that the
> number
>    space is listed there as well. So for now I guess IANA should update
>    both locations. But probably it is best if theu only maintain it in
> one
>    place.
> 
>    The  http://www.iana.org/assignments/snmp-number-spaces uses current
>    RFCs as references. The http://www.iana.org/assignments/smi-numbers
> uses
>    old RFC226x as references.
> 
>    I will report this "duplicate registry" issue to IANA seperately.

The duplicate registry needs to be worked out with IANA.

/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/>

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Tue, 11 Sep 2007 10:52:13 +0200

Inline

Bert Wijnen  

> -----Original Message-----
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 9:23 AM
> To: Wijnen, Bert (Bert)
> Cc: David Harrington; [email-masked]
> Subject: Re: [Isms] my review of:
> 

yep

> The question is why we have snmpModules in the first place 
> and whether we continue to root SNMP modules under 
> snmpModules or treat them as all other modules. The 
> SNMP-USM-AES-MIB was probably the last one rooted under 
> snmpModules - so SNMP addons have been rooted in the not too 
> distant past. I suggest Dan provides advise whether we 
> continue to use snmpModules or declare that we declare 
> snmpModules was a bad idea and we stop assigning things below 
> snmpModules (and perhaps this can then be documented in the 
> IANA documents so we don't forget about this and we can make 
> tools to check for this).
> 

I am OK with leaving it up to Dan.
As I stated, I can live with it.
It only seems we are not consistent with the messages we give in
RFC4181.

> I am fine with changing tsmMIB to snmpTsmMIB.

Thanks. Adds to our consistency I think.

> Perhaps rename to tsmInvalidCacheReferences?

sounds good

> Perhaps rename to tsmInadequateSecurityLevels?

sounds good

> I suggest to simply drop the sentences about persistence 
> since the default in SNMP land is that counters do not 
> persist across reboots (or at least sysUpTime will indicate a 
> discontinuity).
> 

THanks. That solves it for me.

> OK, lets just flip the two things.

Yes please. That would make us in accodance with rfc4181 and would
be more consistent with other such definitions.

> >    Because if you go to 
> http://www.iana.org/assignments/smi-numbers and
> >    RFCs as references. The 
> http://www.iana.org/assignments/smi-numbers
> > uses

I have been in discussion with IANA, and they fixed it.
Iirc, then MIB doctors list was copied on the conversations.

Bert

---

From: "David Harrington" <[email-masked]>
Date: Thu, 13 Sep 2007 16:57:54 -0400

comments inline

dbh

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 4:52 AM
> 

> It only seems we are not consistent with the messages we give in

Lte's see, what should we consider?
Does putting it under snmpModules or mib-2 make it easier to manage a
network?
Does putting it under snmpModules or mib-2 make it easier to
implement?
Does putting it under either one make it easier for IANA?
Does putting it under one or the other make it easier for application
developers?

I think the major argument from my point of view is I am tired of
having to change this back and forth. It makes no difference where we
root it. Let's call it done so we can get the document submitted to
the IESG and encourage people to implement and deploy it. 

> Thanks. Adds to our consistency I think.

consistency with what? the sshtmMib does not have an snmp prefix.
The RFC341x MIB modules all start with SNMP- and the module identities
start with snmp,  and all their objects start with snmpXXX, and they
root under snmpModules. That is consistency.

If we root this under mib-2 rather than an snmp-specific registration
point, as per 4181, then I recommend we rename SNMP-SSH-TM-MIB to
simply SSHTM-MIB to make it consistent with 4181 naming conventions,
and to make it consistent with the module identity and the naming used
throughout the module, which follows the naming conventions described
in 4181. That would be consistent with RRFC4181.

> > Perhaps rename to tsmInvalidCacheReferences?

The reference may be perfectly valid; it is the cache that is invalid.

How should a manager interpret this counter? Is it better for the NMS
to have us count the number of bad references to caches, or the number
of good references to bad caches, or does the NMS need to monitor both
of these error conditions?

Note that having a counter for this implementation-specific error
condition, whether we count bad references or bad caches, is adding
DEBUG information to the NM information. I just edited the OPS&Mgmt
draft where it was pointed out that debug info should NOT be part of
the NM data.

How will instrumenting this information and making it available to my
NMS make the Internet run better?

> > Perhaps rename to tsmInadequateSecurityLevels?

done. Wow! my network runs much better now.

> > >   MIB doctors should probably follow our own CLRs.

done. Wow! my network runs much better now. That 's' on the end acts
like grease on my data.

> THanks. That solves it for me.

Sigh. Bert, you are the AD that compained when people didn't discuss
persistence. When I add a discussion of persistence, you want it
removed.

done. Now it is implicit rather than explicit; I hope that improves
interoperability.

> be more consistent with other such definitions.

Doh! That's why my network kept crashing! good catch.

> Iirc, then MIB doctors list was copied on the conversations.

Am I supposed to change something in the TSM document?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2007 12:00:51 +0200

> The reference may be perfectly valid; it is the cache that is invalid.

I do not want to distinguish between these two. So perhaps a better
name for the counter is needed. What about tsmInvalidCaches with the
description:

	"The number of messages dropped because the tmStateReference
         referred was invalid or pointed to an invalid cache."
 
> of these error conditions?

As I said, I do not want to distinguish between them. (Probably
because in our implementation, there is not much of a difference
between the two or lets say we can't really detect all cases where the
reference is invalid.)

> NMS make the Internet run better?

It allows to detect and identify errors that may have security
implications.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Sep 2007 12:25:33 +0200

> in 4181. That would be consistent with RRFC4181.

I hoped we get away with rough concensus to pick snmpModules and to
align descriptor naming styles to other core SNMP MIB modules so that
we can move forward. Bert already worked on the IANA issues.

Do you really want to make this a major discussion point which will
waste time and energy without being in any way relevant for getting
technology defined and interoperability?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 14 Sep 2007 12:36:18 +0200

> Sent: Friday, September 14, 2007 1:26 PM
> To: David Harrington
> Cc: [email-masked]
> > > > >   And we have no-where specified IANA guidelines as 
> to how/when
> > to
> > > > The question is why we have snmpModules in the first place and 
> > > > whether we continue to root SNMP modules under snmpModules or 
> > > > treat them as all other modules. The SNMP-USM-AES-MIB 
> was probably 
> > > > the last one rooted under snmpModules - so SNMP addons 
> have been 
> > > > rooted in the not too distant past. I suggest Dan 
> provides advise 
> > > > whether we continue to use snmpModules or declare that 
> we declare 
> > > > snmpModules (and perhaps this can then be documented in 
> the IANA 
> > > > documents so we don't forget about this and we can make 
> tools to 
> > > > check for this).
> > > > 
> > > 
> I hoped we get away with rough concensus to pick snmpModules 
> and to align descriptor naming styles to other core SNMP MIB 
> modules so that we can move forward. Bert already worked on 
> the IANA issues.
> 
> Do you really want to make this a major discussion point 
> which will waste time and energy without being in any way 
> relevant for getting technology defined and interoperability?
> 
> /js
> 

In principle it is better to try to be consistent and when the question
is 'consistent to what' use RFC 4181 as a reference whenever possible.
This being said I agree that we should not turn this into a major
discussion point, and would agree with any of the solutions that is
being picked by the editor. 

Dan