Skip to main content

IPsec Security Policy Database Configuration MIB
draft-ietf-ipsp-spd-mib-07

Revision differences

Document history

Date Rev. By Action
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2007-01-03
07 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-01-03
07 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2007-01-03
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-01-02
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-12-18
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2006-12-07
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-12-03
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2006-11-21
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-11-21
07 (System) IANA Action state changed to In Progress from Waiting on Authors
2006-11-15
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-11-14
07 Amy Vezza IESG state changed to Approved-announcement sent
2006-11-14
07 Amy Vezza IESG has approved the document
2006-11-14
07 Amy Vezza Closed "Approve" ballot
2006-11-08
07 Russ Housley State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley
2006-11-08
07 (System) Request for Early review by SECDIR Completed. Reviewer: Stephen Kent.
2006-11-08
07 (System) Request for Early review by SECDIR is assigned to Ran Canetti
2006-11-08
07 (System) Request for Early review by SECDIR is assigned to Ran Canetti
2006-10-19
07 (System) New version available: draft-ietf-ipsp-spd-mib-07.txt
2006-10-19
07 Sam Hartman Cleared based on text that is or will be included in the draft.
2006-10-19
07 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2006-10-14
07 (System) IANA Action state changed to Waiting on Authors from In Progress
2006-05-11
07 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-05-11
07 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2006-05-11
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund
2006-05-11
07 Cullen Jennings
[Ballot discuss]
I don't understand the need for CALEA style rules for packet intercept or the need for full firewall control. I don't think this …
[Ballot discuss]
I don't understand the need for CALEA style rules for packet intercept or the need for full firewall control. I don't think this was in scope for the WG.
2006-05-11
07 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Undefined by Cullen Jennings
2006-05-11
07 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Undefined from Discuss by Cullen Jennings
2006-05-11
07 Cullen Jennings
[Ballot discuss]
I don't understand the need for CALEA style rules for packet intercept or the need for full firewall control. I don't think this …
[Ballot discuss]
I don't understand the need for CALEA style rules for packet intercept or the need for full firewall control. I don't think this was in scope for the WG.
2006-05-11
07 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to Discuss from Undefined by Cullen Jennings
2006-05-11
07 Cullen Jennings
[Ballot comment]
I suspect the title to this document is misleading, it seems like it is
actually a Firewall configuration protocol. In fact, the one …
[Ballot comment]
I suspect the title to this document is misleading, it seems like it is
actually a Firewall configuration protocol. In fact, the one thing you can't
do with what is defined in this document is set up any IPSEC or IKE
parameters. Those are in separate documents which are informational
references.

My concern with this is that this seems to be more or less what we chartered
MIDCOM to go do - they also have a MIB to do this and when you compare the
two, it certainly makes one wonder if a) could we do something common b) is
this one missing some things.

Do you actually need filters with deep packet inspection where you can do
arithmetic operations on any byte in the packet to configure IPsec? Sounds
hard for everyone doing line rate filters with custom VLSI to support.
2006-05-11
07 Cullen Jennings [Ballot Position Update] New position, Undefined, has been recorded for Cullen Jennings by Cullen Jennings
2006-05-10
07 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon
2006-05-10
07 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2006-04-28
07 (System) Removed from agenda for telechat - 2006-04-27
2006-04-27
07 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-04-27
07 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-04-27
07 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation by Cullen Jennings
2006-04-27
07 Jari Arkko [Ballot comment]
> to have executed sucessfully.

Typo above.
2006-04-27
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-04-27
07 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2006-04-27
07 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2006-04-26
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2006-04-26
07 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2006-04-26
07 Lars Eggert
[Ballot comment]
Add RFC editor note from Section 1 to write-up.

Section 4.1: "In this table, the interface is specified using its assigned address." First, …
[Ballot comment]
Add RFC editor note from Section 1 to write-up.

Section 4.1: "In this table, the interface is specified using its assigned address." First, an interface may have multiple IP addresses. Second, RFC1122 Section 3.3.4 allows multiple interfaces to share an IP address. Identifying interfaces by IP address is hence a bit more tricky.

Section 4.1.1, step 4: Maybe I'm dense, but the example and the text above it appear to be out of sync - what about column_value1 and 2?

Section 6.2: what is "in-authentic access?"

Needs a serious cycle of copyediting and spell-checking. RFC2119 terms used inconsistently.
2006-04-25
07 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Undefined by Dan Romascanu
2006-04-25
07 Dan Romascanu
[Ballot comment]
These are not show stoppers, but should rather be corrected before the publication of the RFC:

1. There is one commented mention of …
[Ballot comment]
These are not show stoppers, but should rather be corrected before the publication of the RFC:

1. There is one commented mention of RFC 3291 which was obsoleted by RFC 4001.
2. There is no RFC 2119 text, despite massive use of keywords. Actually this use of keywords is not consistent enough, I would suggest another pass through the MIB module, there are a few more places that need capitalization.
3. spdTimeFiltDayOfWeekMask OBJECT-TYPE
      SYNTAX      BITS { sunday(0), monday(1), tuesday(2),
                          wednesday(3), thursday(4), friday(5),
                          saturday(6) }
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "A bit mask which defines which days of the week the current
          time is valid for.  This column evaluates to 'true' if the
          current day of the week's bit is set."
      DEFVAL { { monday, tuesday, wednesday, thursday, friday,
                  saturday, sunday } }
      ::= { spdTimeFilterEntry 5 }

The DEFVAL values seem to be out of order, sunday should be first. No real impact if somebody already did an implementation because it's all ones, but ...
4. In the DESCRIPTION clause of spdPacketNotification the following text seems redundant, taking into account the previous paragraph:

          An action notification should be limited to a maximum of
          one notification sent per minute for any action
          notifications that do not have any other configuration
          controlling their send rate.

This can be taken out
2006-04-25
07 Dan Romascanu [Ballot Position Update] New position, Undefined, has been recorded for Dan Romascanu by Dan Romascanu
2006-04-24
07 Sam Hartman
[Ballot discuss]
Some of this is prompted by a review by Steve Kent.


This document appears well written and describes a reasonable
configuration architecture.  However …
[Ballot discuss]
Some of this is prompted by a review by Steve Kent.


This document appears well written and describes a reasonable
configuration architecture.  However the architecture that is
described does not match IPsec as described in either RFC 2401 or RFC
4301
.  As an example, this MIB allows SPD rules to include arbitrary
boolean expressions as traffic selectors.  IKE can only negotiate IP
address ranges (IKE V2 is more flexible but still not this flexible).
It would be very difficult to describe how to get from an SPD entry in
this MIB to something you could actually negotiate with IKE.
In addition, many more filters are supported than are actually
permitted by traffic selectors.  For example, there is a filter type
for examining arbitrary contents of a packet or examining diffserv
information. 

I'm afraid I'd need two things in order to really evaluate this
document.  First, I'd need a statement of what IPsec architecture was
targeted (2401 or 4301) and how extensions beyond this architecture
are intended to be handled if they exist.  Then I would need a review
that evaluated the MIB against the target architecture; I've done
enough evaluation to confirm there is a serious mismatch, but not
enough to enumerate all variances from the IPsec architecture.  This
review would need to show that the intended policy for handling
extensions had actually been met.
I do not (and should not have to) have time to conduct this review
myself; I am not sure I am qualified without studying fine details
IPsec  that I am not fully familiar with.

Finally, some document would need to explain how to map SPD entries in
this form into something that you could actually use to negotiate IKE.


I note that we're in kind of an unfortunate process situation.  This
MIB is compatible with RFC 3585.  However that RFC is not actually
compatible with IPsec.  I think that producing implementable standards
is a sufficiently high priority that even if RFC 3585 slipped through
the cracks and proposes a model that does not actually work, this
document  should not be able to slip through the cracks.

Note also, I'm not opposed to extending (as an optional extension) the
SPD to allow for all the items in this spec.  That would need a strong
IETF consensus.  We would also need to clearly deal with issues where
the SPD and IKE do not align and explain how implementations would
deal with SPD rules that cannot be expressed in IKE.  I expect doing
so might cause sufficient interoperability challenges that we drop the
approach.
2006-04-24
07 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded for Sam Hartman by Sam Hartman
2006-04-24
07 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Undefined by Lars Eggert
2006-04-24
07 Lars Eggert
[Ballot comment]
Add RFC editor note from Section 1 to write-up.

Section 4.1: "In this table, the interface is specified using its assigned address." First, …
[Ballot comment]
Add RFC editor note from Section 1 to write-up.

Section 4.1: "In this table, the interface is specified using its assigned address." First, an interface may have multiple IP addresses. Second, RFC1122 Section 3.3.4 allows multiple interfaces to share an IP address. Identifying interfaces by IP address is hence a bit more tricky.

Section 4.1.1, step 4: Maybe I'm dense, but the example and the text above it appear to be out of sync - what about column_value1 and 2?

Section 6.2: what is "in-authentic access?"

Throughout the document, I'd be nice if the examples used RFC1918 private subnets instead of 192.0.2/24.

Needs a serious cycle of copyediting and spell-checking. RFC2119 terms used inconsistently.
2006-04-24
07 Lars Eggert [Ballot comment]
Needs a serious cycle of copyediting and spell-checking. RFC2119 terms used inconsistently.
2006-04-24
07 Lars Eggert [Ballot Position Update] New position, Undefined, has been recorded for Lars Eggert by Lars Eggert
2006-04-24
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-04-24
07 (System) IANA Action state changed to In Progress from RFC-Ed-Ack
2006-04-21
07 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2006-04-21
07 Russ Housley Ballot has been issued by Russ Housley
2006-04-21
07 Russ Housley Created "Approve" ballot
2006-04-21
07 Russ Housley Placed on agenda for telechat - 2006-04-27 by Russ Housley
2006-04-21
07 Russ Housley State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley
2006-04-20
07 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-04-10
06 (System) New version available: draft-ietf-ipsp-spd-mib-06.txt
2006-04-08
07 Michelle Cotton
IANA Last Call Comments:
Upon approval of this document the IANA will assign a mib-2 number for the spdMIB in the Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) at …
IANA Last Call Comments:
Upon approval of this document the IANA will assign a mib-2 number for the spdMIB in the Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1) at the following location:
http://www.iana.org/assignments/smi-numbers

For the second part of the IANA Considerations section:

  The IPSEC-SPD-MIB also allows for extension action MIB's.  Although
  additional actions are not required to use it, the node spdActions is
  allocated for any additional actions that wish to use it.  IANA would
  be responsible for allocating any values under this node.

Does the IANA need to do something upon approval of this document or is would a new document need to create extensions?  If this document does create a new registry, are there initial registrations?  What would the registration procedures be?  Would it be located within another existing registry or would a new location be needed?
2006-04-08
07 (System) IANA Action state changed to In Progress
2006-04-06
07 Amy Vezza Last call sent
2006-04-06
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-04-06
07 Russ Housley Last Call was requested by Russ Housley
2006-04-06
07 (System) Ballot writeup text was added
2006-04-06
07 (System) Last call text was added
2006-04-06
07 (System) Ballot approval text was added
2006-04-06
07 Russ Housley State Changes to Last Call Requested from Expert Review by Russ Housley
2006-03-10
07 Bert Wijnen
gt;    Bert>            support for other filter tables or scalars as
>    Bert>            well: …
gt;    Bert>            support for other filter tables or scalars as
>    Bert>            well:
>
>    Bert>                    diffServMultiFieldClfrTable
>    Bert>                    spdIpOffsetFilterTable
>    Bert>                    spdTimeFilterTable
>    Bert>                    spdCompoundFilterTable spdTrueFilter
>    Bert>                    spdIpsoHeaderFilterTable
>
>    Bert>            If this column is set to a VariablePointer
>    Bert>            value which references a non-existent row in
>    Bert>            an otherwise supported table, the
>    Bert>            inconsistentName exception should be returned.
>    Bert>            If the table or scalar pointed to by the
>    Bert>            VariablePointer is not supported at all, then
>    Bert>            an inconsistentValue exception should be
>    Bert>            returned."
>    Bert>        DEFVAL { spdTrueFilter } ::= {
>    Bert>        spdGroupContentsEntry 3 }
>
>    Bert>  You use the SYNTAX of VariablePointer, so you can point
>    Bert>  to a scalar as well as to a row in a table (or so I
>    Bert>  suspect because of "tables and scalars may be pointed to
>    Bert>  by this column"). 
> yes
>

OK, so I understood it even though it was not clearly stated that way.

>    Bert<  So here are my questions:
>    Bert> - In principle I think this is fine.
>    Bert> - But can you be more specific about pointing to a table?
>    Bert>    Pls be clear that the VariablePointer MUST point to
>    Bert>    the first accessible column in a specific row (as per
>    Bert>    RFC2579).  So in the case of
>    Bert>    diffServMultiFieldClfrTable the VariablePointer must
>    Bert>    point to an instance of
>    Bert>    diffServMultiFieldClfrAddrType.
>    Bert> - The suggestion to return a inconsistentName is in
>    Bert>    conflict with a similar case in for example
>    Bert>    diffServClfrElementNext in the DIFFSERV-MIB which
>    Bert>    suggests to return an inconsistentValue (and that one
>    Bert>    is correct according to rfc3416 I think).  I think
>    Bert>    that means to switch the use of inconsistentValue and
>    Bert>    inconsistentName. In fact, I think that
>    Bert>    inconsistentName is totally impossible given the list
>    Bert>    of error codes in RFC3416 sect 4.2.5. If you want to
>    Bert>    pass back a value for the case described in the last
>    Bert>    sentence, then maybe resourceUnavailable could be
>    Bert>    used, but I can't say that I like that either.  I
>    Bert>    think I don't see how you can properly differentiate
>    Bert>    the two cases with an errorCode.
>
> I changed to the text to indicate inconsistentValue for a
> non-existent row in an existent table and genErr for a non-existent
> table.
>

I do not think that returning a genErr is acceptable.
Such an error can be retunred for any undefined reasons (i.e. the
genErr is used when we see not other way to specify details of the
error). And so if a genErr comes back to the manager, it cannot
assume that the error was what you describe in this DESCRIPTION
clause. It could be many other things.
So I repeat, you cannot differentiate, and I would suggest you
just return an inconsistentValue in both cases and leave it the manager
software to go figure what is the exact reason.

>    Bert> - W.r.t. the above.
>    Bert>  Now a more DESIGN type question is if it is wise to make
>    Bert>  all these tables so dependent on persistency behaviour
>    Bert>  in the different MIB modules. For example, in DIFFSERV,
>    Bert>  the rows each have their own StorageType and so each of
>    Bert>  them can or cannot survive a reboot, same in your MIB
>    Bert>  module.  So what happens then if such persistency
>    Bert>  behaviour is different? In other words, how do you keep
>    Bert>  referential integrity. And if it gets violated (because
>    Bert>  of conflicting persistency attributes of connected rows
>    Bert>  in different tables; or because of implementation
>    Bert>  errors), then what will happen. Because you do not tell
>    Bert>  (in DESCRIPTION clauses) what should happen in that
>    Bert>  case. You just tell people they should not cause it but
>    Bert>  do not give guidance as to what to do if it happens (for
>    Bert>  whatever reason).
>
>    Bert>  Would it not be much better to prescribe what happens if
>    Bert>  at execution time a row no longer exists, what to do
>    Bert>  then?  Similar as is done in the DIFFSERV-MIB for for
>    Bert>  example the diffServClfrElementNext object:

>    Bert>      A value of zeroDotZero in this attribute indicates
>    Bert>      no further Differentiated Services treatment is
>    Bert>      performed on traffic of this data path. The use of
>    Bert>      zeroDotZero is the normal usage for the last
>    Bert>      functional data path element of the current data
>    Bert>      path.
>
>    Bert>      Setting this to point to a target that does not
>    Bert>      exist results in an inconsistentValue error.  If the
>    Bert>      row pointed to is removed or becomes inactive by
>    Bert>      other means, the treatment is as if this attribute
>    Bert>      contains a value of zeroDotZero."
>
>    Bert>  You also might want to read the sect 4.3 in the
>    Bert>  DIFF-SERV MIB document (RFC3289).
>
>    Bert>  I very well understand that this should have been
>    Bert>  brought to your attention earlier on in the process. So
>    Bert>  I do not want to force a new design on you. But I do
>    Bert>  recommend you seriously think about this.  Because I
>    Bert>  think that the current design you have chosen can work
>    Bert>  in theory, but in practice it will be very difficult to
>    Bert>  get it right/correctly implemeted.
>
>    Bert> - The same story for several other tables that use
>    Bert>  VariablePointer.
>
> We had assumed that this wouldn't happen given other restrictions,
> but I've after some discussion of how to handle this situation,
> we've added the following packet handling description to the various
> filter and action variable pointers.
>
>        "If during packet processing this column has a value that
>          references a non-existent or non-supported object, the
>          packet should be dropped."
>
That is good. Thanks

>
>    Bert> - I see two objects that seem to (nearly) duplicate each
>    Bert>  other:
>    Bert>    spdCompFiltName OBJECT-TYPE
>    Bert>        SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS
>    Bert>        not-accessible STATUS current DESCRIPTION
>    Bert>            "A user definable string.  You may use this
>    Bert>            field for
>    Bert>            your administrative tracking purposes."
>    Bert>        ::= { spdCompoundFilterEntry 1 }
>
>    Bert>    spdCompFiltDescription OBJECT-TYPE
>    Bert>        SYNTAX SnmpAdminString MAX-ACCESS read-create
>    Bert>        STATUS current DESCRIPTION
>    Bert>            "A user definable string.  You may use this
>    Bert>            field for
>    Bert>            your administrative tracking purposes."
>    Bert>        DEFVAL { "" } ::= { spdCompoundFilterEntry 2 }
>
>    Bert>  I suspect that the first one needs a different
>    Bert>  DESCRIPTION clause?
>
> Yes, spdCompFiltName's description has been changed to:
>
>        "A user definable string.  This value is used as an index
>        into this table."
>

good

>    Bert> - spdTrueFilter OBJECT-TYPE
>    Bert>            SYNTAX Integer32 MAX-ACCESS read-only STATUS
>    Bert>            current DESCRIPTION
>    Bert>                "This scalar indicates a (automatic) true
>    Bert>                result for
>    Bert>                a filter.  I.e. this is a filter that is
>    Bert>                always true, useful for adding as a
>    Bert>                default filter for a default action or a
>    Bert>                set of actions."
>    Bert>            ::= { spdStaticFilters 1 }
>
>    Bert>    It is totally unclear what the value of this object is
>    Bert>    at any point in time. Probably it does not matter. But
>    Bert>    maybe it is better to define it as:
>
>    Bert>            SYNTAX Integer32 (1)
>
>    Bert>    So that we all know what the value is in case it is
>    Bert>    read.
>
> added
>
thanks

>    Bert> - In object: spdIpOffFiltType
>    Bert>            equal:
>    Bert> - Tests if the OCTET STRING, 'spdIpOffFiltValue', matches
>    Bert>                a value in the packet starting at the given
>    Bert>                offset in the packet and comparing the
>    Bert>                entire OCTET STRING of 'spdIpOffFiltValue'.
>    Bert>                Any numeric values compared this way are
>    Bert>                assumed to be unsigned integer values in
>    Bert>                network byte order of the same length as
>    Bert>                'spdIpOffFiltValue'.
>
>    Bert>  How does one determine if "the OCTET STRING" is a
>    Bert>  numeric value that is being compared? And why does it
>    Bert>  make a difference in an octet string?
>
>    Bert> - Same for the other type of comaprison inside
>    Bert>  spdIpOffFiltType
>
> For equal and notEqual, it doesn't make a difference.  But for the
> other comparisons,
> arithmetic(Less/Greater/LessOrEqual/GreaterOrEqual), we wanted to be
> clear as to what was meant by an 'arithmetic' comparison so no one
> would wonder about byte order, signed/unsigned, or real/integer.
>

OK. I still find it a bit weird, but can live with it.
Implementation/deployment experience will show if it works interoperably.

>    Bert> - spdIpOffFiltValue OBJECT-TYPE
>    Bert>        SYNTAX OCTET STRING (SIZE(1..1024)) MAX-ACCESS
>    Bert>        read-create STATUS current DESCRIPTION
>    Bert>            "spdIpOffFiltValue is used for match
>    Bert>            comparisons of a
>    Bert>            packet at spdIpOffFiltOffset.  This object is
>    Bert>            only used if one of the match types is chosen
>    Bert>            in spdIpOffFiltType."
>
>    Bert>  I am getting confused by the last sentence. How do you
>    Bert>  NOT choose one of the match types in spdIpOffFiltType ??
>    Bert>  Or do you mean that only 'equal' and 'notEqual' are
>    Bert>  match types?  That would contrafdict text in the
>    Bert>  spdIpOffFiltType DESCRIPTION clause though. So I do not
>    Bert>  understand.  You migth want to be clearer here.
>
> That text is left over from a previous design.  I deleted the last
> sentence from the description.
>
OK

>    Bert> - With regard to your spdTimeFilterTable I worry about
>    Bert>  consistency with other (already published MIB modules
>    Bert>  that use similar (but a little bit different) tables and
>    Bert>  OBJECTs to specify time filters, days of week, months in
>    Bert>  a year etc.  I use RFC3060 (Policy Core Information
>    Bert>  Model) as a guideline.  For example, look at
>    Bert>  pmSchedTable in RFC4011.  A look at schedTable in
>    Bert>  RFC3231 also heps, but it is not specifically policy
>    Bert>  related material.
>
>    Bert>  I think that in your mIB module you sync up with the
>    Bert>  other RFCs for
>    Bert>      spdTimeFiltMonthOfYearMask
>    Bert>          It is also in sync with RFC3060, Sect 7.5.2.
>
>    Bert>  but not for:
>    Bert>      spdTimeFiltDayOfMonthMask
>    Bert>          other RFCs are both using BITS as SYNTAX and have
>    Bert>          boht forward (starting at beginning of month) and
>    Bert>          backward (starting at end of month) day values.
>    Bert>          RFC3060, sect 6.5.3 also tells you to use that
>    Bert>          format.
>
> changed
>

good

>    Bert>      spdTimeFiltDayOfWeekMask
>    Bert>          other RFCs are starting Sunday as day zero, you
>    Bert>          use Monday as day zero. In fact RFC3060, sect
>    Bert>          6.5.4 tells you to do so.
>
> changed
>

good

>    Bert>      spdTimeFiltTimeOfDayMaskStart/End
>    Bert>      spdTimeFiltPeriodStart/End
>    Bert>          You use DateAndTime syntax.  RFC3231 is from
>    Bert>          before RFC3060 and also is not policy related
>    Bert>          that much.  RFC4011 and xxx use Utf8String and
>    Bert>          format as per RFC2445, Which is also what RFC3060
>    Bert>          (Policy Core Information Model) prescribes (or so
>    Bert>          I think) for TimePeriods, see sect 6.5.1. of
>    Bert>          RFC3060.
>
> We decided to use the DateAndTime TC because we believed it was a
> more heavily used and understood TC and serves the same function as
> the iCalender's period value.  This did conflict with the PCIM, but
> we thought it would make a more implementable MIB with little real
> difference.  That said, if you still prefer we use the iCalender
> period value, let me know, and I will change the table to use it.
>

Well, I personally find it pretty weird that you woul dfollow RFC3060
for some time-related objects but not for others. So I certainly
think it is MUCH better to do them all im a PCIM compliant manner.

If you do NOT want to change it, then I would recommend to do an
explicit check for WG consensus on that (but you do not have a WG anymore...
mmm...). The least I would want to see is that you would explicitly
spell out WHY you are not following RFC3060. And personally I find
you arguments very weak. The PCIM datatypes have been used in other
places, so I do not see why that would be difficult for implementations.


>    Bert> - The previous point actually raises the question if the
>    Bert>  WG (or whoever worked on this) have carefully checked
>    Bert>  all the definitions agains the Information Model as
>    Bert>  composed by RFC3060 plus RFC3585?  Can someone pls
>    Bert>  confirm lest I do not have to go and check that in
>    Bert>  detail?
>
> Yes, an ongoing comparison was done heavily by the authors while
> creating the MIB and by multiple other people for consistency.  This
> doesn't guarantee no errors, of course, but it has been checked. 
>

OK, thanks. I accept and trust that you did as good a job as you could.
Maybe you (or Russ) could ask one of the authors of PCIM/PCIMe to
do a review?

>    Bert> - spdDropAction OBJECT-TYPE
>    Bert>        SYNTAX Integer32 MAX-ACCESS read-only STATUS
>    Bert>        current DESCRIPTION
>    Bert>            "This scalar indicates that a packet should be
>    Bert>            dropped
>    Bert>            WITHOUT action/packet logging.  This object
>    Bert>            returns a value of 1 for IPsec policy
>    Bert>            implementations that support the drop static
>    Bert>            action."
>
>    Bert>    At least this one is clearer on what to return on a GET
>    Bert>    (while spdTrueFilter was not). Now, the question comes
>    Bert>    up: what gets returned if it is not supported? Any
>    Bert>    other value? 
>
> If it is not supported, an snmp get should return 'noSuchObject'.
>

That would be fine. But then the object should be in an optional
OBJECT-GROUP and not in a MANDATORY-GROUP in the MODULE-COMPLIANCE.

I would then also add some text to the DESCRIPTION clause to explain
this, so that an implementer knows what to do.

>    Bert>    And what happens if it is not supported
>    Bert>    and some rule points to this action? 
>
> If the object is not supported, a rule shouldn't be settable to it.
> But see above for added text in case an object disappears after a
> rule points to it.
>
yep, thanks

>    Bert>    So why not define the syntax as:
>    Bert>        SYNTAX Integer32 (1)
>    Bert>    Or if 2 values are possible, maybe
>    Bert>        SYNTAX INTEGER {
>    Bert>                      dropActionSupported (1),
>    Bert>                      dropActionNotSupported (2)
>    Bert>                    }
>    Bert>    And add in description clause what happens in each case
>    Bert>    if a rule points to this action.
>

The above suggestion from me is probably/possibly easier than doing a
noSuchObject.

>    Bert> - same question for: spdDropActionLog, spdAcceptAction,
>    Bert>  spdAcceptActionLog
>

So pls make sure to do whatever you do (optional object instead
of manadatory; add text to description clause to explain) for
each of those objects.

>    Bert> - For your NOTIFICATION, I think you MUST add some text
>    Bert>  (or maybe a throttle object) to explain (and allow
>    Bert>  control of) how an implemetation is to behave in the
>    Bert>  case of congestion on the network and to prevent itself
>    Bert>  from causing congestion.
>

I do not see an answer nor any change in the new revision w.r.t. the
above comment. I do not know how the new transport ADs will react,
but I can assure you that current transport ADs will take a DISCUSS
on this. So you better address it. It could be as simple as adding
some text that an agent should not send more than x notifications
per minute (or 1 per x seconds). Not sure what an acceptable value
would be. But certainly no more than 1 a second I think. Probably better
to do at most one every 3 or 5 seconds or so.

>
>    Bert> -------- minor/nits/editorial/clarifications -------
>
>    Bert> So the below are not blocking at all.  If you do do a new
>    Bert> rev anyway, you might want to consider them though.
>
>    Bert> - spdMIB MODULE-IDENTITY
>    Bert>      LAST-UPDATED "200502170000Z" -- 17 January 2005
>    Bert>  seems you did not update the date. But in any event, the
>    Bert>  comment does not match the dat itself, it is 17 feb
>    Bert>  2005.  Same for REVISION clause
>
> fixed
>
>    Bert> - I do think that spdEndGroupIdentType would be better
>    Bert>  named spdEndGroupAddressType.
>
> yes, changed.
>
>    Bert> - spdGroupContPriority OBJECT-TYPE
>    Bert>        SYNTAX Integer32 (0..65535) MAX-ACCESS
>    Bert>        not-accessible STATUS current DESCRIPTION
>    Bert>            "The priority (sequence number) of the
>    Bert>            sub-component in
>    Bert>            this group."
>    Bert>        ::= { spdGroupContentsEntry 2 }
>
>    Bert>    spdGroupContFilter OBJECT-TYPE
>    Bert>        SYNTAX VariablePointer MAX-ACCESS read-create
>    Bert>        STATUS current DESCRIPTION
>    Bert>            "spdGroupContFilter points to a filter which is
>    Bert>            evaluated
>    Bert>            to determine whether the
>    Bert>            spdGroupContComponentName within this row
>    Bert>            should be exercised.  Managers can use this
>    Bert>            object to classify groups of rules or
>    Bert>            subgroups together in order to achieve a
>    Bert>            greater degree of control and optimization
>    Bert>            over the execution order of the items within
>    Bert>            the group.  If
>
>    Bert>    That sentence about "control and optiomization of
>    Bert>    execution order" does that not better belong in the
>    Bert>    DESCRIPTION clasue of the spdGroupContPriority ?? In
>    Bert>    any event, I would like to see added text to explain
>    Bert>    that priority zero gets exectuted first and priority 1
>    Bert>    gets exteuted after that and so on (assuming I have it
>    Bert>    right).
>
> You do.  I added the following to the spdGroupContPriority
> DESCRIPTION clause,
>          "This value indicates the order that each row of this table
>          should be processed from low to high.  For example, a row
>          with a priority of 0 is processed before a row with a
>          priority of 1, a 1 before a 2, etc...."
>

great

>    Bert> - spdSubFiltPriority OBJECT-TYPE
>    Bert>        SYNTAX Integer32 (0..65535) MAX-ACCESS
>    Bert>        not-accessible STATUS current DESCRIPTION
>    Bert>            "The priority of a given filter within a set of
>    Bert>            filters.  The order of execution should be from
>    Bert>            lowest to highest priority value.
>    Bert>            Implementations MAY choose to follow this
>    Bert>            ordering as set by the manager that created the
>    Bert>            rows.  This can allow a manager to
>    Bert>            intelligently construct filter lists such that
>    Bert>            faster filters are evaluated first."
>    Bert>        ::= { spdSubfiltersEntry 1 }
>   
>    Bert>    So I aklways wonder in the range (0..65K) what it means
>    Bert>    "from lowest to highest". I expect 0 to be the best
>    Bert>    priority. The best way to describe it is that I would
>    Bert>    say something like: "priority 0 gets executed first,
>    Bert>    then priority 1, and so on".  You may claim this is
>    Bert>    obvious, but over my career in the ICT industry I have
>    Bert>    seen both 0 being first or last.  I am confused by the
>    Bert>    "Implementations MAY choose...". DOes that mean that
>    Bert>    they can ignore it as well? So how the hell do I as a
>    Bert>    manager then know what is happening?
>
>    Bert> - Same for other priority fields
>
> Added an example to the descriptions clauses of the various priority
> columns along the lines of, '(i.e., priority 0 before priority 1, 1
> before 2, etc...)'
>

good
>    Bert> - spdIpOffFiltOffset OBJECT-TYPE
>    Bert>        SYNTAX Integer32 (0..65535) MAX-ACCESS read-create
>    Bert>        STATUS current DESCRIPTION
>    Bert>            "This is the byte offset from the front of the
>    Bert>            IP packet
>    Bert>            where the value or arithmetic comparison is
>    Bert>            done.  A value of '0' indicates the first byte
>    Bert>            in the packet."

>    Bert>  So I guess you mean offset from the start of IP-header?
>    Bert>  Or is it the payload of an IP packet? May want to be
>    Bert>  very explicit about that.
>
> changed to:
>
>        "This is the byte offset from the front of the entire IP
>        packet where the value or arithmetic comparison is done.  A
>        value of '0' indicates the first byte of the packet header."
>
thanks

>    Bert> - For consistency, I would rename spdRuleFilterCompliance
>    Bert>  to spdRuleFilterFullCompliance as we have done in other
>    Bert>  MIB modules.  I would add some text to the DESCRIPTION
>    Bert>  clause aka:
>
>    Bert>      When this MIB is implemented with support for
>    Bert>      read-create, then such an implementation can claim
>    Bert>      full compliance. Such devices can then be both
>    Bert>      monitored and configured with this MIB.
>
> done and done.
>
thanks

>    Bert>  It would also sync up better with the ReadOnly
>    Bert>  Compliance DESCRIPTION clause.
>
>

Bert
>
> --
> Michael Baer
> baerm@tislabs.com
> Sparta
>
>
2006-03-03
05 (System) New version available: draft-ietf-ipsp-spd-mib-05.txt
2006-02-23
07 Bert Wijnen
Mmm... I (Bert) probably should have recorded my MIB doctor review
on the same day that I did send it top authors and interested people. …
Mmm... I (Bert) probably should have recorded my MIB doctor review
on the same day that I did send it top authors and interested people.

Up to now I have not received any response from the authors.
Russ did react to my questuion to him on the Security COnsiderations.
So, as far as I know, I am still waiting for reponses and a new revision.

So here the review email (for the record):

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Tuesday, February 07, 2006 23:42
To: Michael Baer
Cc: Harrie Hazewinkel; Wes Hardaker; Robert Story; Russ Housley; Ricky
Charlet; Cliff Wang
Subject: MIB Doctor review for: draft-ietf-ipsp-spd-mib-04.txt


Russ,
there is one specific comment from me on the Security Considerations
Section. Can you check and comment on my comment?

Michael (and others),
I think we're getting closer.
At the other hand, I still have many comments (some more severe than
others, some just nits) below. I would think one more rev makes sense,
and I don't think that such would be too difficult to do.

Here we go.

- Smicng tells me:
    W: f(ipsec-spd.mi2), (202,4) Row "spdEndpointToGroupEntry" has indexing that may
    create variables with more than 128 sub-ids
  the above warning is OK. You have put a warning in DESCRIPTION clause of the
  InetAddress index object. Normally we put that in the DESCRIPTION of the xxxEntry
  So if you do a rev, you may want to consider that.

    E: f(ipsec-spd.mi2), (951,4) Item "spdTrueFilter" must not have items registered
    below it
  I understand why you are doing it. I saw your answer.
  I have checked this (again) with MIB doctors what we think of this.
  It is OK. We ignore this error.
    W: f(ipsec-spd.mi2), (2136,25) MIN-ACCESS value identical to access specified fo
    r "spdAcceptAction"
    W: f(ipsec-spd.mi2), (2141,25) MIN-ACCESS value identical to access specified fo
    r "spdAcceptActionLog"
    W: f(ipsec-spd.mi2), (2151,25) MIN-ACCESS value identical to access specified fo
    r "spdCompActLastChanged"
    W: f(ipsec-spd.mi2), (2173,25) MIN-ACCESS value identical to access specified fo
    r "spdCompFiltLastChanged"
    W: f(ipsec-spd.mi2), (2194,25) MIN-ACCESS value identical to access specified fo
    r "spdDropAction"
    W: f(ipsec-spd.mi2), (2199,25) MIN-ACCESS value identical to access specified fo
    r "spdDropActionLog"
    W: f(ipsec-spd.mi2), (2209,25) MIN-ACCESS value identical to access specified fo
    r "spdEndGroupLastChanged"
    W: f(ipsec-spd.mi2), (2246,25) MIN-ACCESS value identical to access specified fo
    r "spdGroupContLastChanged"
    W: f(ipsec-spd.mi2), (2267,25) MIN-ACCESS value identical to access specified fo
    r "spdIpOffFiltLastChanged"
    W: f(ipsec-spd.mi2), (2303,25) MIN-ACCESS value identical to access specified fo
    r "spdIpsoHeadFiltLastChanged"
    W: f(ipsec-spd.mi2), (2355,25) MIN-ACCESS value identical to access specified fo
    r "spdRuleDefLastChanged"
    W: f(ipsec-spd.mi2), (2372,25) MIN-ACCESS value identical to access specified fo
    r "spdSubActLastChanged"
    W: f(ipsec-spd.mi2), (2393,25) MIN-ACCESS value identical to access specified fo
    r "spdSubFiltLastChanged"
    W: f(ipsec-spd.mi2), (2429,25) MIN-ACCESS value identical to access specified fo
    r "spdTimeFiltLastChanged"
    W: f(ipsec-spd.mi2), (2471,25) MIN-ACCESS value identical to access specified fo
    r "spdTrueFilter"
  All the MIN-ACCESS clauses in the MODULE-COMPLIANCE can be removed for the above,
  becasue they are the same as the MAX-ACCESS. So no need to have them.

    W: f(ipsec-spd.mi2), (118,4) Textual convention "SpdIPPacketLogging" defined but
    not used
  So why is it needed if it is not used? I saw your answer, but that does not
  make sense to me. How can it be used if it is only a TC and nowhere is there
  an OBJECT that uses that SYNTAX. An object (read-write I would assume) can
  have a value as you indicate in the TC, but without using the syntax,
  I can't see how it helps you.
  You do refer to it in some DESCRIPTION clauses as if it were an OBJECT-TYPE
  instead of a TEXTUAL-CONVENTION. It says:
          enable sending a variable sized part of the front of the
          packet with size dependent on the value of
          SpdIPPacketLogging."
  So WHERE is that value??

- smilint does not bark about any of the above (or anythings else)

- Since you IMPORT from RFC3411, that rfc must be a normative ref instead of
  informative.

- RFC3291 has been obsoleted (quite a while ago already) by RFC4001.
  If you do a revision, pls update to use the new RFC

- Your change to section 2 has made it different from the std MIB boiler
  plate that we say must be present. I personally can live with it,
  although would rather see the standard boilerplate.

- The Security Considerations section does NOT list all the various
  objects and what their specific sensitivities are. And that is what
  we normally REQUIRE for MIB modules, and Russ as Security AD is
  looking for that in MIB modules too.
  You only have a generic story about the whole set of objects.
  So I'd like to understand from Russ if what you did is sufficient in
  this case.

Since the syntax and references and all that are now in MUCH better shape
I have also looked in detail at the contents of the MIB module itself.
So here are my comments:

- spdIngressPolicyGroupName and spdEgressPolicyGroupName are read-write
  objects,  but the description clauses do not say what the expected
  persistence behaviour is. I would think that you want to say something aka
    This object MUST be persistent.

-  spdEndGroupIdentType OBJECT-TYPE
      SYNTAX      InetAddressType
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The Internet Protocol version of the address associated
          with a given endpoint.  All addresses are represented as an
          array of octets in network byte order.  When combined with
          the spdEndGroupAddress these objects can be used to
          uniquely identify an endpoint that a set of policy groups
          should be applied to.  Devices supporting IPv4 MUST support
          the ipv4 value, and devices supporting IPv6 MUST support
          the ipv6 value.

          Values of unknown, ipv4z, ipv6z and dns are not legal
          values for this object."
      ::= { spdEndpointToGroupEntry 2 }

  The language about MUST support IPv4 and IPv6 does not belong here
  but rather in the MODULE-COMPLIANCE. Same for the last sentence.
  And I would only list what needs to be supported, not the things that
  do not need to be supported. Because if next year the InetAddressType
  TC gets extended with yet more values, then what?
  You have an InetAddressType/InetAddress pair used as an index.
  The way we normally describe that only IPv4/v6 support is required
  is in a comment in the DESCRIPTION clause of a MODULE-COMPLIANCE
  (since these are index objects, you cannot do them as an OBJECT
  clause) as follows:

  Your OLD (current) text:
  spdRuleFilterCompliance MODULE-COMPLIANCE
      STATUS      current
      DESCRIPTION
          "The compliance statement for SNMP entities that include
            an IPsec MIB implementation with Endpoint, Rules, and
            filters support."
  Propose new text:
  spdRuleFilterCompliance MODULE-COMPLIANCE
      STATUS      current
      DESCRIPTION
          "The compliance statement for SNMP entities that include
            an IPsec MIB implementation with Endpoint, Rules, and
            filters support.

            There are a number of INDEX objects that cannot be
            represented in the form of OBJECT clauses in SMIv2, but
            for which we have the following compliance requirements,
            expressed in OBJECT clause form in this description
            clause:

            -- OBJECT      spdEndGroupIdentType
            -- SYNTAX      InetAddressType { ipv4(1), ipv6(2) }
            -- DESCRIPTION
            --    Only support for global IPv4 and IPv6 address
            --    types is required.
            --
            -- OBJECT      spdEndGroupAddress
            -- SYNTAX      InetAddress (SIZE(4|16))
            -- DESCRIPTION
            --    Only support for global IPv4 and IPv6 address
            --    types is required.
            --
          "

  I think the same is needed for the other MODULE-COMPLIANCE statement(s).

  For the spdIPEndpointAddType and spdIPEndpointAddress objkects you can
  actually add the OBJECT clauses to the MODULE-COMPLAINCE.

-    spdIPEndpointAddress OBJECT-TYPE
      SYNTAX      InetAddress
      MAX-ACCESS  accessible-for-notify
      STATUS      current
      DESCRIPTION
          "Contains the interface address for the interface that
            the packet which triggered the notification is passing
            through."

  You must include text in the DESCRIPTION clause as to which object
  of syntax InetAddressType specifies/determines the format of this
  object. Same as you did it for: spdEndGroupAddress

  Same for spdIPSourceAddress and spdIPDestinationAddress.


- In various RowStatus objects, you have text aka:
            The value of this object has no effect on whether other
            objects in this conceptual row can be modified.
  That is goodness. There are some tables though where you do NOT do that
  and so one is left wondering if objects can or cannot be changed while
  the row is active.

-  spdGroupContFilter OBJECT-TYPE
      SYNTAX      VariablePointer
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "spdGroupContFilter points to a filter which is evaluated
            to determine whether the spdGroupContComponentName within
            this row should be exercised.  Managers can use this object
            to classify groups of rules or subgroups together in order
            to achieve a greater degree of control and optimization
            over the execution order of the items within the group.  If
            the filter evaluates to false, the rule or subgroup will be
            skipped and the next rule or subgroup will be evaluated
            instead.

            An example usage of this object would be to limit a
            group of rules to executing only when the IP packet
            being process is designated to be processed by IKE.
            This effectively creates a group of IKE specific rules.

            This MIB defines the following tables and scalars which
            may be pointed to by this column.  Implementations may
            choose to provide support for other filter tables or
            scalars as well:

                  diffServMultiFieldClfrTable
                  spdIpOffsetFilterTable
                  spdTimeFilterTable
                  spdCompoundFilterTable
                  spdTrueFilter
                  spdIpsoHeaderFilterTable

            If this column is set to a VariablePointer value which
            references a non-existent row in an otherwise supported
            table, the inconsistentName exception should be
            returned.  If the table or scalar pointed to by the
            VariablePointer is not supported at all, then an
            inconsistentValue exception should be returned."
      DEFVAL { spdTrueFilter }
      ::= { spdGroupContentsEntry 3 }

  You use the SYNTAX of VariablePointer, so you can point to a scalar
  as well as to a row in a table (or so I suspect because of "tables
  and scalars may be pointed to by this column").
  So here are my questions:
  - In principle I think this is fine.
  - But can you be more specific about pointing to a table?
    Pls be clear that the VariablePointer MUST point to the
    first accessible column in a specific row (as per RFC2579).
    So in the case of diffServMultiFieldClfrTable the
    VariablePointer must point to an instance of
    diffServMultiFieldClfrAddrType.
  - The suggestion to return a inconsistentName is in conflict
    with a similar case in for example diffServClfrElementNext
    in the DIFFSERV-MIB which suggests to return an
    inconsistentValue (and that one is correct according
    to rfc3416 I think).
    I think that means to switch the use of inconsistentValue
    and inconsistentName. In fact, I think that inconsistentName
    is totally impossible given the list of error codes in
    RFC3416 sect 4.2.5. If you want to pass back a value for
    the case described in the last sentence, then maybe
    resourceUnavailable could be used, but I can't say that
    I like that either.
    I think I don't see how you can properly differentiate the
    two cases with an errorCode.

- W.r.t. the above.
  Now a more DESIGN type question is if it is wise to make all
  these tables so dependent on persistency behaviour in the
  different MIB modules. For example, in DIFFSERV, the rows
  each have their own StorageType and so each of them can
  or cannot survive a reboot, same in your MIB module.
  So what happens then if such persistency behaviour is
  different? In other words, how do you keep referential
  integrity. And if it gets violated (because of conflicting
  persistency attributes of connected rows in different
  tables; or because of implementation errors), then what
  will happen. Because you do not tell (in DESCRIPTION
  clauses) what should happen in that case. You just tell
  people they should not cause it but do not give guidance
  as to what to do if it happens (for whatever reason).

  Would it not be much better to prescribe what happens if
  at execution time a row no longer exists, what to do then?
  Similar as is done in the DIFFSERV-MIB for for example the
  diffServClfrElementNext object:
 
      A value of zeroDotZero in this attribute indicates no further
      Differentiated Services treatment is performed on traffic of this
      data path. The use of zeroDotZero is the normal usage for the
      last functional data path element of the current data path.

      Setting this to point to a target that does not exist results in
      an inconsistentValue error.  If the row pointed to is removed or
      becomes inactive by other means, the treatment is as if this
      attribute contains a value of zeroDotZero."

  You also might want to read the sect 4.3 in the DIFF-SERV MIB document
  (RFC3289).

  I very well understand that this should have been brought to your
  attention earlier on in the process. So I do not want to force a new
  design on you. But I do recommend you seriously think about this.
  Because I think that the current design you have chosen can work
  in theory, but in practice it will be very difficult to get it
  right/correctly implemeted.

- The same story for several other tables that use VariablePointer.

- I see two objects that seem to (nearly) duplicate each other:
  spdCompFiltName OBJECT-TYPE
      SYNTAX      SnmpAdminString (SIZE(1..32))
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "A user definable string.  You may use this field for
            your administrative tracking purposes."
      ::= { spdCompoundFilterEntry 1 }

  spdCompFiltDescription OBJECT-TYPE
      SYNTAX      SnmpAdminString
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "A user definable string.  You may use this field for
            your administrative tracking purposes."
      DEFVAL { "" }
      ::= { spdCompoundFilterEntry 2 }

  I suspect that the first one needs a different DESCRIPTION clause?

-    spdTrueFilter OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
              "This scalar indicates a (automatic) true result for
                a filter.  I.e. this is a filter that is always
                true, useful for adding as a default filter for a
                default action or a set of actions."
          ::= { spdStaticFilters 1 }

  It is totally unclear what the value of this object is at any
  point in time. Probably it does not matter. But maybe it is better
  to define it as:

          SYNTAX      Integer32 (1)

  So that we all know what the value is in case it is read.

- In object: spdIpOffFiltType
          equal:
            - Tests if the OCTET STRING, 'spdIpOffFiltValue', matches
              a value in the packet starting at the given offset in
              the packet and comparing the entire OCTET STRING of
              'spdIpOffFiltValue'.  Any numeric values compared this
              way are assumed to be unsigned integer values in
              network byte order of the same length as
              'spdIpOffFiltValue'.

  How does one determine if "the OCTET STRING" is a numeric value
  that is being compared? And why does it make a difference in an
  octet string?

- Same for the other type of comaprison inside spdIpOffFiltType

-  spdIpOffFiltValue OBJECT-TYPE
      SYNTAX      OCTET STRING (SIZE(1..1024))
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "spdIpOffFiltValue is used for match comparisons of a
            packet at spdIpOffFiltOffset.  This object is only used
            if one of the match types is chosen in
            spdIpOffFiltType."

  I am getting confused by the last sentence. How do you NOT choose
  one of the match types in spdIpOffFiltType ??
  Or do you mean that only 'equal' and 'notEqual' are match types?
  That would contrafdict text in the spdIpOffFiltType DESCRIPTION
  clause though. So I do not understand.
  You migth want to be clearer here.

- With regard to your spdTimeFilterTable I worry about consistency
  with other (already published MIB modules that use similar (but
  a little bit different) tables and OBJECTs to specify time
  filters, days of week, months in a year etc.
  I use RFC3060 (Policy Core Information Model) as a guideline.
  For example, look at pmSchedTable in RFC4011.
  A look at schedTable in RFC3231 also heps, but it is not
  specifically policy related material.

  I think that in your mIB module 
  you sync up with the other RFCs for
    spdTimeFiltMonthOfYearMask
        It is also in sync with RFC3060, Sect 7.5.2.

  but not for:
    spdTimeFiltDayOfMonthMask
        other RFCs are both using BITS as SYNTAX and have boht
        forward (starting at beginning of month) and backward
        (starting at end of month) day values.
        RFC3060, sect 6.5.3 also tells you to use that format.
    spdTimeFiltDayOfWeekMask
        other RFCs are starting Sunday as day zero,
        you use Monday as day zero. In fact RFC3060, sect 6.5.4
        tells you to do so.
    spdTimeFiltTimeOfDayMaskStart/End
    spdTimeFiltPeriodStart/End
        You use DateAndTime syntax.
        RFC3231 is from before RFC3060 and also is not policy
        related that much.
        RFC4011 and xxx use Utf8String and format as per RFC2445,
        Which is also what RFC3060 (Policy Core Information Model)
        prescribes (or so I think) for TimePeriods, see sect
        6.5.1. of RFC3060.
 
- The previous point actually raises the question if the WG (or
  whoever worked on this) have carefully checked all the definitions
  agains the Information Model as composed by RFC3060 plus RFC3585?
  Can someone pls confirm lest I do not have to go and check that
  in detail?

-  spdDropAction    OBJECT-TYPE
      SYNTAX      Integer32
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "This scalar indicates that a packet should be dropped
            WITHOUT action/packet logging.  This object returns a
            value of 1 for IPsec policy implementations that support
            the drop static action."

  At least this one is clearer on what to return on a GET (while
  spdTrueFilter was not). Now, the question comes up:
  what gets returned if it is not supported? Any other value?
  And what happens if it is not supported and some rule points
  to this action?
  So why not define the syntax as:
      SYNTAX      Integer32 (1)
  Or if 2 values are possible, maybe
      SYNTAX      INTEGER {
                      dropActionSupported (1),
                      dropActionNotSupported (2)
                  }
  And add in description clause what happens in each case if a
  rule points to this action.

- same question for: spdDropActionLog, spdAcceptAction,
  spdAcceptActionLog

- For your NOTIFICATION, I think you MUST add some text (or maybe
  a throttle object) to explain (and allow control of) how an
  implemetation is to behave in the case of congestion on the
  network and to prevent itself from causing congestion.


-------- minor/nits/editorial/clarifications -------

So the below are not blocking at all.
If you do do a new rev anyway, you might want to consider them though.

-  spdMIB MODULE-IDENTITY
      LAST-UPDATED "200502170000Z"            -- 17 January 2005
  seems you did not update the date. But in any event, the comment
  does not match the dat itself, it is 17 feb 2005.
  Same for REVISION clause

- I do think that spdEndGroupIdentType would be better named
  spdEndGroupAddressType.

-  spdGroupContPriority OBJECT-TYPE
      SYNTAX      Integer32 (0..65535)
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The priority (sequence number) of the sub-component in
            this group."
      ::= { spdGroupContentsEntry 2 }

  spdGroupContFilter OBJECT-TYPE
      SYNTAX      VariablePointer
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "spdGroupContFilter points to a filter which is evaluated
            to determine whether the spdGroupContComponentName within
            this row should be exercised.  Managers can use this object
            to classify groups of rules or subgroups together in order
            to achieve a greater degree of control and optimization
            over the execution order of the items within the group.  If

  That sentence about "control and optiomization of execution order"
  does that not better belong in the DESCRIPTION clasue of the
  spdGroupContPriority ?? In any event, I would like to see added text
  to explain that priority zero gets exectuted first and priority 1
  gets exteuted after that and so on (assuming I have it right).

-  spdSubFiltPriority OBJECT-TYPE
      SYNTAX      Integer32 (0..65535)
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The priority of a given filter within a set of filters.
          The order of execution should be from lowest to highest
          priority value.  Implementations MAY choose to follow this
          ordering as set by the manager that created the rows.  This
          can allow a manager to intelligently construct filter lists
          such that faster filters are evaluated first."
      ::= { spdSubfiltersEntry 1 }
 
  So I aklways wonder in the range (0..65K) what it means "from lowest
  to highest". I expect 0 to be the best priority. The best way to
  describe it is that I would say something like: "priority 0 gets
  executed first, then priority 1, and so on".  You may claim this is
  obvious, but over my career in the ICT industry I have seen both
  0 being first or last.
  I am confused by the "Implementations MAY choose...". DOes that
  mean that they can ignore it as well? So how the hell do I as
  a manager then know what is happening?

- Same for other priority fields

-  spdIpOffFiltOffset OBJECT-TYPE
      SYNTAX      Integer32 (0..65535)
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "This is the byte offset from the front of the IP packet
            where the value or arithmetic comparison is done.  A
            value of '0' indicates the first byte in the packet."

  So I guess you mean offset from the start of IP-header? Or is it the
  payload of an IP packet? May want to be very explicit about that.

- For consistency, I would rename spdRuleFilterCompliance to
  spdRuleFilterFullCompliance as we have done in other MIB modules.
  I would add some text to the DESCRIPTION clause aka:

      When this MIB is implemented with support for read-create, then
      such an implementation can claim full compliance. Such devices
      can then be both monitored and configured with this MIB.

  It would also sync up better with the ReadOnly Compliance DESCRIPTION
  clause.

Bert
2006-02-06
07 Russ Housley Intended Status has been changed to Proposed Standard from None
2006-01-31
04 (System) New version available: draft-ietf-ipsp-spd-mib-04.txt
2005-10-21
03 (System) New version available: draft-ietf-ipsp-spd-mib-03.txt
2005-09-20
07 Russ Housley State Changes to Expert Review from AD Evaluation::External Party by Russ Housley
2005-09-06
07 Russ Housley State Changes to AD Evaluation::External Party from Dead by Russ Housley
2005-09-06
07 (System) This document has been resurrected per RFC Editor's request
2005-09-02
07 Russ Housley I-D Resurrection was requested by Russ Housley
2005-09-02
07 (System) Document has expired
2005-03-14
07 Russ Housley State Changes to Dead from AD is watching::External Party by Russ Housley
2005-02-22
02 (System) New version available: draft-ietf-ipsp-spd-mib-02.txt
2004-11-12
07 Russ Housley Shepherding AD has been changed to Russ Housley from Steve Bellovin
2004-10-21
01 (System) New version available: draft-ietf-ipsp-spd-mib-01.txt
2004-10-20
07 Dinara Suleymanova This document has been resurrected by Dinara Suleymanova
2004-10-20
00 (System) New version available: draft-ietf-ipsp-spd-mib-00.txt
2004-10-18
07 Bert Wijnen I-D Resurrection was requested by Bert Wijnen
2004-03-03
07 Steven Bellovin waiting for MIB doctor review
2004-03-03
07 Steven Bellovin Draft Added by Steve Bellovin