IPsec Security Policy Database Configuration MIB
RFC 4807

Note: This ballot was opened for revision 07 and is now closed.

(Russ Housley) Yes

(Jari Arkko) No Objection

Comment (2006-04-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
 > to have executed sucessfully.

Typo above.

(Ross Callon) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2006-04-26 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss) No Objection

(Cullen Jennings) (was Discuss, No Record, Discuss) No Objection

Comment (2006-05-11)
No email
send info
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.

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

Comment (2006-04-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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

(Mark Townsley) No Objection

Magnus Westerlund No Objection