Subject: [Isms] status of draft-ietf-radius-vacm-10.txt

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 8 Sep 2010 11:31:05 -0700

Hi -

I think all the issues from the MIB doctor review have
been resolved except the request to add more text to
the DESCRIPTION of vacmAaaSecurityToGroupEntry.

As editor, I'm awaiting direction from the working
group on this item.  Below is my summary of where I think
the issue stands.
---------------------------------------

The current editor's copy says:

vacmAaaSecurityToGroupEntry OBJECT-TYPE
    SYNTAX       VacmAaaSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table maps the combination of a
                 SnmpSecurityModel and securityName into the name
                 of a VACM group defining the access control policy
                 which is to govern a particular session.

                 Each entry corresponds to a session.

                 Entries do not persist across reboots.

                 An entry is created whenever an indication occurs
                 that a new session has been established that would
                 not have the same index values as an existing entry.

                 When a session is torn down, disconnected, timed out
                 (e.g., following the RADIUS Session-Timeout Attribute),
                 or otherwise terminated for any reason, the
                 corresponding vacmAaaSecurityToGroupEntry is deleted."
    REFERENCE   "RFC 3411 section 3.2.2 defines securityName"
    INDEX       {
                  vacmAaaSecurityModel,
                  vacmAaaSecurityName,
                  vacmAaaSessionID
                }
    ::= { vacmAaaSecurityToGroupTable 1 }

The requirement from RFC 4181 cited by the reviewer is:

     - If the agent itself may also create and/or delete rows, then the
       conditions under which this can occur MUST be clearly documented
       in the row object DESCRIPTION clause.

If one were in hair-splitting mode, one might argue that the requirement
does not apply in this case for two reasons.  First, it is subordinate
to the condition "[i]f dynamic row creation and/or deletion by management
applications is supported", and this is clearly not the case here.  (I do
agree with the general notion that the DESCRIPTION of a row should
provide the conditions under which those entries come into and go out
of existence, and the current text does so.)  Secondly, the changes requested
by the reviewer are to supply information about *another* table in a
different MIB module.

The issue is that the operation of the specification which happens to
contain this MIB module also entails the creation, modification, and
deletion of entries in the vacmSecurityToGroupTable.  The mechanism
by which these changes happen is not specified, but the conditions
may be described in terms of when certain changes would happen to the
vacmAaaSecurityToGroupTable, and the changes themselves are described
in terms readily translated to a management interface.  The question, as
I see it, is whether the DESCRIPTION of vacmAaaSecurityToGroupTable
is the appropriate place to replicate the description of how the
normal operation of the AAA/VACM spec would update VACM's
vacmSecurityToGroupTable.  My own opinion is that this would be
confusing rather than enlightening, and is not required by the
guidelines.

Opinions, and more importantly, ACTUAL TEXT, would be welcome!
As far as I know, this is the only issue preventing us
from returning the document to the IESG for approval.

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 09 Sep 2010 14:54:41 +0900

Hi,
  There are actually two issues that need to be addressed.

Issue-1:
(2010/09/04 15:58), Glenn M. Keeni wrote:
>    I have noted that conditions for creation have been added to the
> DESCRIPTION clause in the -10.draft. But, the DESCRIPTION still does
> not capture the semantics of the table and the entry as is given in
> Sec 7. Particularly what may be called the side-effects. To be
> specific-
> a. When an entry is created in vacmAaaSecurityToGroupTable there are
>     side-effects on vacmSecurityToGroupTable. This is specified in
>     Sec 7.2.3 but does not appear in the DESCRIPTION and may be lost
>     to the MIB reader/user/implementer.
> b. When an entry is deleted from vacmAaaSecurityToGroupTable there
>     may be side-effects on vacmSecurityToGroupTable. This is specified
>     in Sec. 7.3.2 but does not appear anywhere in the DESCRIPTION.
>
> Please add corresponding text to the DESCRIPTION.

I think that the general idea is that the MIB module should by itself
provide the reader with all the information about the creation/update
/deletion of objects and related side-effects, if any.

Issue-2:
In Section 7 the text says-
   On receipt of indication
      a. create/update/delete entry in vacmAaaSecurityToGroupTable
           7.2.2.  Creation of Entries in vacmAaaSecurityToGroupTable
             Whenever an indication arrives  determine whether a
             corresponding entry exists in the
             vacmAaaSecurityToGroupTable. If one does not, create a
             new row......
             Otherwise, if the row already exists, update the
             vacmAaaGroupName
      b. create/update/delete entry in vacmSecurityToGroupTable
          7.2.3.  Creation of Entries in vacmSecurityToGroupTable
            Whenever an entry is created in the
            vacmAaaSecurityToGroupTable, the vacmSecurityToGroupTable
            is examined to determine whether corresponding entry
            exists there.  If no corresponding entry
            exists, create one, using the vacmAaaGroupName of the newly
            created entry to fill in vacmGroupName......

It is clear that only if a vacmAaaSecurityToGroupEntry creation in (a)
succeeds (b) will attempted. [(b) will not be attempted if (a) fails.]
But it does not say what will be the effect if (b) fails. It appears
that there are 2 options for an implementer
      b-1. if (b) fails - rollback changes in (a)
      b-2. if (b) fails - do not rollback changes done in (a).
Is it clear from the text which option,  b-1 or b-2, should be taken
by an implementer? If it is not clear a fix is needed here.

Glenn

> Hi,
>    Please see inline.

(2010/09/09 3:31), Randy Presuhn wrote:
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Sep 2010 09:59:31 +0200

> /deletion of objects and related side-effects, if any.

Is your proposal to cut'n'paste 7.2.3 and 7.3.2 into the DESCRIPTION
clause? Or is your proposal to add an explicit reference to the
DESCRIPTION clause to sections 7.2.3 and 7.3.2? Or is your proposal to
completely inline section 7 into the DESCRIPTION clauses of the MIB
module, causing a major rewrite?

Looking at the flow of the discussion, I believe the WG does not
really care about this change since the specification overall is
considered clear enough to implement it.

> by an implementer? If it is not clear a fix is needed here.

Since there is no concrete text proposal and given the lack of WG
support for adding more text detailing the handling of error
situations, I believe we should close this issue with no change.  Note
that once you look at why (b) can fail in real implementations, you
likely can convince yourself that the actions to take might also be
implementation specific.

/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: "David B. Nelson" <[email-masked]>
Date: Thu, 9 Sep 2010 09:46:19 -0400

> /deletion of objects and related side-effects, if any.

With all due respect, this seems to relegate the normative text of the RFC that contains the MIB module to the status of little more than introductory fluff.  Sometimes there are important points that can only be found in the normative text, and in my opinion that's as it should be.  Implementers need to read all that text.  While the DESCRIPTION clauses should be as fully descriptive as practical, attempting to shoe-horn *all* the normative behavior into these clauses can in some cases be a mistake. I think this is one of them.

> by an implementer?

It doesn't matter.   Action (b) only "fails" if statically configured information in the local configuration data store over-rides AAA-provisioned information.  In that event, it matters not what happens to the AAA-provisioned information in (a).

> If it is not clear a fix is needed here.

With due respect, I don't think so.

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 10 Sep 2010 14:17:30 +0900

> module, causing a major rewrite?
A gist of section 7  should do. E.g.
OLD:
    DESCRIPTION "An entry in this table maps the combination of a
                 SnmpSecurityModel and securityName into a the name
                 of a VACM group defining the access control policy
                 which is to govern a particular session.

NEW:

                 If an entry with the same index values exists then
                 the vacmAaaGroupName is updated.

                 Whenever an entry is created, if no corresponding entry
                 exists in the vacmSecurityToGroupTable, an entry
                 will be created in that table.

                 If a corresponding entry exists in the
                 vacmSecurityToGroupTable, and that entry's StorageType
                 is 'volatile' and its RowStatus is 'active', the value
                 of vacmGroupName in that entry will be updated with
                 the value from vacmAaaGroupName.

                 When a session is torn down, disconnected, timed out
                 (e.g., following the RADIUS Session-Timeout Attribute),
                 or otherwise terminated for any reason, the
                 corresponding vacmAaaSecurityToGroupEntry is deleted.

                 Whenever the last remaining row bearing a particular
                 (vacmAaaSecurityModel, vacmAaaSecurityName) pair is
                 deleted from the vacmAaaSecurityToGroupTable, the
                 vacmSecurityToGroupTable is examined for a
                 corresponding row. If one exists, and if its
                 StorageType is 'volatile' and its RowStatus is
                 'active', that row will be deleted as well."

> Since there is no concrete text proposal and given the lack of WG
A sentence, at the end of section 7, should fix this problem. E.g.

     Failure to carry out the actions on vacmSecurityToGroupTable,
     specified in 7.2.3, 7.2.4 and 7.3.2, for whatever reason, will not
     impact the actions specified in 7.2.2 and 7.3.1, carried out on
     vacmAaaSecurityToGroupTable.

Glenn

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 10 Sep 2010 10:36:46 -0700

Hi -

As a technical contributor...

> From: "Glenn M. Keeni" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Thursday, September 09, 2010 10:17 PM
> Subject: Re: [Isms] [IETFMIBS] status of draft-ietf-radius-vacm-10.txt
....
>                  the vacmAaaGroupName is updated.

I think this does not belong here, and is only confusing in this context.
Saying "an entry [in this table] with the same index values exists" in an
entry's DESCRIPTION makes no sense from an SMI point of view, since
such a situation is impossible.

>                  the value from vacmAaaGroupName.

If we mention this at all, it doesn't belong here, but rather would make more
sense as part of the DESCRIPTION of vacmAaaGroupName, since this
applies whenever vacmAaaGroupName is assigned a value; creation is just
a special case of that.

>                  'active', that row will be deleted as well."

I think this does not belong here.  If we mention it at all, it would belong in the
DESCRIPTION of the table, rather than the entry, since the conditions
described require knowledge of more than just the entry to evaluate.
 
...
> >> Issue-2:
...
>      vacmAaaSecurityToGroupTable.

If I encountered a sentence like this in a specification, and did not have
the benefit of all this discussion, I would be left totally baffled, wondering
"why on earth did they put this here?"  If there is a dependency between
elements of procedure, we say so.  It makes no sense to me to point out
imaginary dependencies only to say that they don't apply.

The *only* way I could support doing something like this was if
(1) implementation experience showed that implementors tended to
get it "wrong" and (2) this actually caused interoperability problems.

I very much doubt that either of these will prove true, and strongly oppose
adding this language.  I think it would set a terrible precedent.

Randy

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 11 Sep 2010 15:58:58 +0900

Hi,
(2010/09/11 2:36), Randy Presuhn wrote:
>> From: "Glenn M. Keeni"<[email-masked]>
>> To:<[email-masked]>;<[email-masked]>
I agree that some portions of the proposed text will need to be moved
to more appropriate DESCRIPTIONs. We are making progress here.

> adding this language.  I think it would set a terrible precedent.
Please reword/rephrase/relocate the text as is appropriate. But the
relationship (dependence or independence) between the elements of
procedure needs to be clear to the implementer. We have two elements:
element-a and element-b.  It is possible that element-a succeeds
and element-b fails. Without further clarity, the outcome will be
unpredictable.

Glenn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 Sep 2010 11:46:31 +0200

> and element-b fails. Without further clarity, the outcome will be

Glenn, as far as I recall, nobody in the WG supported your position
that this is a problem. In other words, I do not see WG concensus to
make a change. I consider this issue closed with no change needed.

/js

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 11 Sep 2010 19:50:00 +0900

(2010/09/11 18:46), Juergen Schoenwaelder wrote:
>> procedure needs to be clear to theI have tried  implementer. We have two elements:
OK. I understand your position. There is a disagreement. I guess that
it is the AD's call now :-)

Glenn

---

From: "Dave Nelson" <[email-masked]>
Date: Sat, 11 Sep 2010 08:51:59 -0400

> OK. I understand your position. There is a disagreement.
> I guess that it is the AD's call now :-)

Glenn, I think you understand that in the IETF tradition all Last Call
comments have equal weight.  Expert reviews are treated the same as WG
member commentary.  The only individuals who have extraordinary influence
are the IESG members.  A corollary of this is that not all comments require
changes to the draft document.

Too often these days I see what amounts to a negotiation between a single
reviewer requesting specific changes and the document sheppard representing
the consensus of the WG.  The review process is supposed to be about
highlighting possible errors, omission, points of confusion, and so forth,
and then letting IETF *consensus* dictate the changes to be made, if any.

Thanks for listening.

Regards,

Dave Nelson

---

From: "David Harrington" <[email-masked]>
Date: Sat, 11 Sep 2010 09:46:56 -0400

Hi,

Even the IESG has limited influence. We are constrained in when we can
apply a DISCUSS.
See http://www.ietf.org/iesg/statement/discuss-criteria.html 

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Nelson
> Sent: Saturday, September 11, 2010 8:52 AM
> To: 'Glenn M. Keeni'
> Cc: [email-masked]; [email-masked]
> Glenn, I think you understand that in the IETF tradition all 
> Last Call comments have equal weight.  Expert reviews are 
> treated the same as WG member commentary.  The only 
> individuals who have extraordinary influence are the IESG 
> members.  A corollary of this is that not all comments 
> require changes to the draft document.
> 
> Too often these days I see what amounts to a negotiation 
> between a single reviewer requesting specific changes and the 
> document sheppard representing the consensus of the WG.  The 
> review process is supposed to be about highlighting possible 
> errors, omission, points of confusion, and so forth, and then 
> letting IETF *consensus* dictate the changes to be made, if any.
> 
> Thanks for listening.
> 
> Regards,
> 
> Dave Nelson
> 
>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 11 Sep 2010 23:55:56 +0900

Dave,
> changes to the draft document.
No disagreement here.
> the consensus of the WG.  

> The review process is supposed to be about
No disagreement here too. This is all part of the IETF process. And,
I think it is working well. I have no doubt that the results have been
good.

Cheers,

Glenn