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 |