Subject: [Isms] RADIUS/VACM - do we need to talk about tmStateReference?

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 6 Mar 2010 11:50:50 -0800

Hi -

I've posted an update to the document.  There are a few (IMO) very
minor points left to resolve.  I'll send out a separate message for
each issue.  I think the first and second ones are closely linked:

  1.  Is there really any need to talk about the tmStateReference
       cache?

  2.  Is there a need for the RFC 5590 reference to be normative?  Is
      it needed at all?

Currently, tmStateReference is introduced in 4.2, but not used anywhere
else.  I don't think it is needed or even helpful, and would propose
removing it.

RFC 5590 is mentioned twice in the document.  The first is in a list
of "important" documents in the introduction, and the second is as
the point of reference for tmStateReference.  If we get rid of the
talk about tmStateReference, I don't see why the reference to RFC 5590
would need to be normative, but I'm willing to be convinced otherwise.

The MIB module mentions tmSessionID in an example in a DESCRIPTION,
but we don't have a good way to make references for things like this.
I think that RFC 5590 should at least be in the informative references
for this reason, but would like (a) confirmation from the group that
this makes sense, and (b) suggestions on how to make the reference so
the id-nits tools don't complain.

Randy

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 08:59:20 -0500

Resending from my enrolled email address.

> On Mar 6, 2010, at 2:50 PM, Randy Presuhn wrote:
>
> Not strictly speaking.  It is necessary to bind the session in the  
> Transport Model to the dynamically created rows in the  
> extVacmSecurityToGropTable and the vacmSecurityToGroupTable.   Such  
> a session identifier is described in Section 7.2, et seq.  The  
> mention of tmStateReference was originally added to suggest one way  
> of maintaining that required binding.  Specifying the requirements  
> of the binding, without suggesting a specific implementation is  
> sufficient.
>
> It probably doesn't need to be normative.  On the other hand, the  
> methods described in this document are *only* applicable when a  
> Secure Transport Model is also in use, so it would seem reasonable  
> to keep it as an informative reference.
>
> Regards,
>
> Dave
>
> David B. Nelson
>
> Elbrys Networks, Inc.
> 282 Corporate Drive, Unit 1
> Portsmouth, NH 03801
>
> +1.603.570.2636
> www.elbrys.com
> [email-masked]

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 8 Mar 2010 08:46:46 -0500

Not strictly speaking.  It is necessary to bind the session in the  
Transport Model to the dynamically created rows in the  
extVacmSecurityToGropTable and the vacmSecurityToGroupTable.   Such a  
session identifier is described in Section 7.2, et seq.  The mention  
of tmStateReference was originally added to suggest one way of  
maintaining that required binding.  Specifying the requirements of the  
binding, without suggesting a specific implementation is sufficient.

It probably doesn't need to be normative.  On the other hand, the  
methods described in this document are *only* applicable when a Secure  
Transport Model is also in use, so it would seem reasonable to keep it  
as an informative reference.

Regards,

Dave

David B. Nelson

Elbrys Networks, Inc.

+1.603.570.2636
www.elbrys.com
[email-masked]