Subject: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Aug 2010 09:54:54 +0200

Hi,

I think the changes generally look good. There is one thing I like to
mention though. In the definition of vacmAaaSessionID, I like to
suggest the following change:

OLD

    REFERENCE   "The abstract service interface parameter tmSessionID
                 is defined in RFC 5590 section 5.2.4 and RFC 5592
                 section 4.1.2"

NEW

    REFERENCE   "The abstract service interface parameter tmSessionID
                 is defined in RFC 5590 section 5.2.4."

It is my understanding that the definition of tmSessionID is in RFC
5590 and RFC 5592 merely uses tmSessionID. By avoiding a reference to
RFC 5592 in this REFERENCE clause, I think RFC 5592 can be moved from
a normative reference to an informative reference (since all other
references to RFC 5592 are in the "for example" context).

I also found two editorial nits:

- s/IsAccessAllowed/isAccessAllowed/
- replace the final ',' with a '.' in section 6.3

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Aug 2010 10:32:03 +0200

> - replace the final ',' with a '.' in section 6.3

Two more things:

The REFERENCE clause in the definition of vacmAaaSecurityToGroupEntry
must be moved in front of the INDEX clause, see RFC 2578 pages 8 and
9. Smilint freaks out with a parse error on the current version.

As stated before, I personally dislike the module name change from
SNMP-VACM-AAA-MIB to VACM-AAA-MIB. I believe it is a valuable feature
that all core SNMP modules start with SNMP-. Concerning consistency
with RFC 4181, I like to point out that Appendix C is titled
"Suggested Naming Conventions" and not REQUIRED Naming Conventions.
In this particular case, I believe consistency with SNMP module naming
style (the SNMP- prefix) and consistency with the way VACM identifiers
are constructed is way more important than consistency with the
"Suggested Naming Conventions" of RFC 4181. Hence I suggest the
following change:

OLD

VACM-AAA-MIB DEFINITIONS ::= BEGIN

NEW

SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 31 Aug 2010 08:38:57 -0400

Hi,
Hi,

I tend to go the other direction on this issue.
Maybe this is because I come from the NMS side, not the agent side.

I think it tremendously helpful to have consistent naming of objects;
an operator looking at the naming prefix for an object, such as
vacmAaaSecurityToGroupEntry, can tell that the full definition is
likely to be in the VACM-AAA-MIB. It would not be at all intuitive to
me that vacmAaaSecurityToGroupEntry would be in the SNMP-VACM-AAA-MIB.

I don't see any real benefit to the SNMP- prefix if the object names
are not consistent with that module name.
What benefits do you see?

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, August 31, 2010 4:32 AM
> To: [email-masked]
> Subject: Re: [Isms] js review of 
> draft-ietf-isms-radius-vacm-10 changes
> 

> The REFERENCE clause in the definition of 
> vacmAaaSecurityToGroupEntry must be moved in front of the 
> INDEX clause, see RFC 2578 pages 8 and 9. Smilint freaks out 
> with a parse error on the current version.
> 
> As stated before, I personally dislike the module name change 
> from SNMP-VACM-AAA-MIB to VACM-AAA-MIB. I believe it is a 
> valuable feature that all core SNMP modules start with SNMP-. 
> Concerning consistency with RFC 4181, I like to point out 
> that Appendix C is titled "Suggested Naming Conventions" and 
> not REQUIRED Naming Conventions.
> In this particular case, I believe consistency with SNMP 
> module naming style (the SNMP- prefix) and consistency with 
> the way VACM identifiers are constructed is way more 
> important than consistency with the "Suggested Naming 
> Conventions" of RFC 4181. Hence I suggest the following change:
> 
> OLD
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Aug 2010 15:32:17 +0200

> What benefits do you see?

I prefer consistency. So far, all core SNMP modules have an SNMP-
prefix and this really is nice if you have to look for files. And yes,
module names are commonly translated to implementation file names;
probably I am just too much a coder. Perhaps the choice of the core
SNMP module names was just a major historic accident.

/js (who never ever guessed a module name from a descriptor,
     probably because some brave soul gave me grep)

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 Aug 2010 10:33:50 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, August 31, 2010 12:54 AM
> Subject: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes
...
> references to RFC 5592 are in the "for example" context).
...

Actually, what I really should have referenced from RFC 5592 is in section 5.1.
It specifies:

          tmSessionID = an implementation-dependent value that can be
          used to detect when a session has closed and been replaced by
          another session.  The value in tmStateReference MUST uniquely
          identify the session over which the message was received.
          This session identifier MUST NOT be reused until there are no
          references to it remaining.

This is an important constraint, not spelled out in RFC 5590.  The more
I look at the tmSessionID material in RFC 5590 and 5592, the more
convinced I am that we should probably not mention it, even though I
still think it would be the right thing to use (at least if I were implementing
it.  :-)

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 Aug 2010 10:38:00 -0700

Hi -

...
> - replace the final ',' with a '.' in section 6.3

Fixed!  Thanks.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 Aug 2010 10:43:20 -0700

Hi -

> Sent: Tuesday, August 31, 2010 1:32 AM
> Subject: Re: [Isms] js review of draft-ietf-isms-radius-vacm-10 changes
...
...

Fixed!

Do we also need to add REFERENCE material here for SnmpSecurityModel
and for the Session-Timeout attribute?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 Aug 2010 11:18:05 -0700

Hi -

 
>      probably because some brave soul gave me grep)

As a technical contributor...

No matter what we do, there will be a consistency or a usability problem.

   (1) consistency of the "DEFINITIONS" module name with the other SNMP
         infrastructure MIB modules (i.e., all start with "SNMP-"

   (2) MIB review guidelines suggestions relating the DEFINITIONS descriptor to
         the MODULE-IDENTITY module name (appendix C of RFC 4181,
         second bullet)

   (3) suggestions relating other descriptors in the module to the MODULE-IDENTITY
         (RFC 4181 appendix C, third bullet)

RFC 4181 says "Authors and reviewers of IETF MIB modules have often found the
following naming conventions to be helpful in the past, and authors of new IETF MIB
modules are urged to consider following them."  Not a terribly forceful statement.  :-)

The current text satisfies (2) and (3).  (1) is what I'd characterize as an "oral
history" requirement - while there may be some truth to it, it's not written down.
Glenn's proposed change (add prefixes to all the definitions to satisfy (3)) would
meet all three of these objectives, but would bring the downsides of requiring
*lots* of editing (yes, I know that's not a valid objection) and, more importantly,
the descriptors start becoming awkwardly long (yes, this is a somewhat
subjective assessment) producing a solution that, in my opinion, is worse
than the problem.

I'd be perfectly happy with the naming as it is, or as it was.  I can see a *slight*
advantage to how it was in that an alphabetical list of modules would put this
module and VACM close to each other.  But I don't find it particularly persuasive.

As editor...

I await guidance from the chairs regarding the consensus of the WG.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Tue, 31 Aug 2010 16:23:15 -0400

Hi,

RFC5590 defines the tmSessionID. It defines it without many
constraints because the content is model-specific. 
   o  tmSessionID: in order to verify whether the session has changed,
      the Transport Model must be able to compare the session used to
      receive the original request with the one to be used to send the
      response.  This typically needs some form of session identifier.
      This value is only ever used by the Transport Model, so the
format
      and interpretation of this field are model-specific and
      implementation-dependent.

RFC5592 defines the SSHTM model-specific constraints.
          tmSessionID = an implementation-dependent value that can be
          used to detect when a session has closed and been replaced
by
          another session.  The value in tmStateReference MUST
uniquely
          identify the session over which the message was received.
          This session identifier MUST NOT be reused until there are
no
          references to it remaining.

It might make sense for most models to use the same constraints, but
it is not a requirement to do so. If somebody defines a model where
tmSessionID is not necessarly unique, that would be legal. And neither
RFC5590 nor RFC5592 mandates uniqueness across all transport models,
only within the SSHTM model.

If the current doc references tmSessionID as a worthy candidate for
vacmAaaSessionID, it should be pointed out that the scope of
uniqueness between tmSessionID and vacmAaaSessionID might differ, and
the implementation might need to address that problem if it supports
multiple concurrent transport models.

dbh

> Behalf Of Randy Presuhn
> Sent: Tuesday, August 31, 2010 1:34 PM
> To: [email-masked]
> Subject: [Isms] tmSessionID (was: js review 
> ofdraft-ietf-isms-radius-vacm-10 changes)
> 
> Hi -
> 

> This is an important constraint, not spelled out in RFC 5590. 
>  The more I look at the tmSessionID material in RFC 5590 and 
> 5592, the more convinced I am that we should probably not 
> mention it, even though I still think it would be the right 
> thing to use (at least if I were implementing it.  :-)
> 
> Randy
>

---

From: Robert Story <[email-masked]>
Date: Tue, 31 Aug 2010 16:49:13 -0400

On Tue, 31 Aug 2010 11:18:05 -0700 Randy wrote:
RP> more importantly,
RP> the descriptors start becoming awkwardly long (yes, this is a somewhat
RP> subjective assessment) producing a solution that, in my opinion, is worse
RP> than the problem.

I agree with Randy. I intensely dislike prefixes just for the sake of
prefixing. 

I also agree with Juergen that it would be nice for a core module mib
name to include SNMP, but *not* if that means prefixing every object in
the mib with snmp.

-- 
Robert Story
Senior Software Engineer
SPARTA (dba Cobham Analytic Soloutions)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Aug 2010 23:11:09 +0200

> multiple concurrent transport models.

Here is the text:

    DESCRIPTION "An implementation-dependent identifier of the session.

                 This value MUST be unique among all currently open
                 sessions of all of this SNMP engine's transport models.
                 The value has no particular significance other than to
                 distinguish sessions.

                 Implementations in which tmSessionID has a compatible
                 syntax and is unique across all transport models MAY
                 use that value."

Do you think there is anything wrong with it?

Do you think it requires a reference to RFC 5592?

/js

---

From: "David Harrington" <[email-masked]>
Date: Tue, 31 Aug 2010 19:09:24 -0400

I think that is fine.

dbh 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Tuesday, August 31, 2010 5:11 PM
> To: David Harrington
> Cc: 'Randy Presuhn'; [email-masked]
> Subject: Re: [Isms] tmSessionID (was: js review

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 Aug 2010 16:31:23 -0700

Hi -

Ok, so it sounds like there is mostly agreement to

>                  is defined in RFC 5590 section 5.2.4."

I'll apply this edit.
This will have two side-effects:
  - remove 5592 from the list of RFCs needed for REFERENCE clauses
  - move 5592 from the list of normative references to the list of informative ones

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 31 Aug 2010 16:42:14 -0700

Hi -

Based on the discussion so far, I sense a *slight* collective preference for

> SNMP-VACM-AAA-MIB DEFINITIONS ::= BEGIN

I'll apply this change.

Randy