Subject: draft-ietf-ipsec-doi-tc-mib-07.txt and friends

From: Barbara Fraser <[email-masked]>
Date: Fri, 06 Jun 2003 18:30:50 -0700

Hi John,

Ted and I have been, once again, digging back into the status of 5 of the 
MIB documents and would like to see us once and for all get these documents 
put to bed.  We've seen and read the thread concerning 
draft-ietf-ipsec-doi-tc-mib-07.txt. Everything seems to have come to a halt 
after Mike Heard posted his summary MIB doctor comments on April 28. This 
document is referenced in the an IPSP document so we need to somehow 
resolve the issues surrounding it,  which is why there is such a wide 
distribution on this message.  First question is, are you willing to 
continue to work on this document as the editor? Second, it seems there has 
been some difference of opinion between you and Mike. One comment made was 
that some of the difficulties arose from this document being looked at in 
isolation of the other related documents. This brings me to a question. 
Every time Ted and I have asked if anyone is implementing these MIBs, there 
has been total silence leading us to believe nobody is implementing them. 
Paul Hoffman has kindly resubmitted 
draft-ietf-ipsec-ike-monitor-mib-04.txt, 
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and 
draft-ietf-ipsec-monitor-mib-06.txt for us in the new format, and if he, or 
someone else is willing to take them on, we could continue to progress all 
of them.  If that's what folks want to do. On the other hand, we could also 
choose to progress only the document that Hilary's group needs and drop the 
other three due to lack of interest/implementation.  It's also fair to 
remind folks that these are all IKEv1 MIB docs.

All this boils down to the following:
1. Are you willing to continue to edit draft-ietf-ipsec-doi-tc-mib-07.txt?
2. We need to come to agreement on what changes are needed, that is we must 
address the MIB doctor comments.
3. Are we going to continue to support 
draft-ietf-ipsec-ike-monitor-mib-04.txt, 
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and 
draft-ietf-ipsec-monitor-mib-06.txt? If so, who's willing to take on the 
document editor job? And, more importantly, how do we decide what changes 
are needed to them.

I feel like we're living in Ground Day with these MIB docs. We keep living 
the same thing over and over. Let's please get to the end :-)

thanks,
Barb and Ted

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Mon, 9 Jun 2003 13:11:27 -0600

Wes Hardaker has had implementations that use this, and he has made similar changes
to his IPSP MIB document in order to appease the MIB powers.  You and Wes should
coordinate changes and resubmit ASAP.

Hilarie

>  Date: Mon, 09 Jun 2003 09:51:35 -0400
>  From: John Shriver <[email-masked]>
>  Organization: Sockeye Networks

>  > Hi John,
>  > 
>  > Ted and I have been, once again, digging back into the status of 5 of 
>  > the MIB documents and would like to see us once and for all get these 
>  > documents put to bed.  We've seen and read the thread concerning 
>  > draft-ietf-ipsec-doi-tc-mib-07.txt. Everything seems to have come to a 
>  > halt after Mike Heard posted his summary MIB doctor comments on April 
>  > 28. This document is referenced in the an IPSP document so we need to 
>  > somehow resolve the issues surrounding it,  which is why there is such a 
>  > wide distribution on this message.  First question is, are you willing 
>  > to continue to work on this document as the editor? 

>  Absolutely.  The problem is that we lack a consensus on what to do about 
>  Mike Heard's comments.  Honestly, nobody but Mike and I appear to give a 
>  darn, at least on the IPsec mailing list!  Even if I do decide to agree 
>  with the change from enumerations to simple typedefs, is an agreement of 
>  two people out of the entire IPsec list really a consensus?  Maybe it 
>  is, in the absence of any dissenting opinion!

>  Myself, I think the MIB is far more useful if we ignore Mike's comments. 
>    But, realistically, it would _never_ get through last call, and it 
>  would be futile to proceeed in that direction.

>  > Second, it seems 
>  > there has been some difference of opinion between you and Mike. One 
>  > comment made was that some of the difficulties arose from this document 
>  > being looked at in isolation of the other related documents. This brings 
>  > me to a question. Every time Ted and I have asked if anyone is 
>  > implementing these MIBs, there has been total silence leading us to 
>  > believe nobody is implementing them. 

>  I suspect that nobody is implementing the related MIBs.  I may remember 
>  one vendor implementing the drafts, but I wouldn't be surprised if 
>  they've been swept away by the dot-com meltdown of the last two years.

>  > draft-ietf-ipsec-monitor-mib-06.txt for us in the new format, and if he, 
>  > or someone else is willing to take them on, we could continue to 
>  > progress all of them.  

>  I think that IKEv2 is rendering much of the content of these MIBs as 
>  obsolete.  Plus the competiting IPsec Flow Monitoring MIB effort from 
>  Cisco & Tivoli people, which has the advantadge of being implemented. 
>  (You can't get through the standards track without implementations...) 
>  Hopefully the folks authoring the Flow Monitoring MIB will continue to 
>  pick up some of the good points from the earlier set of MIBs, I will 
>  concede that later versions were improved.  But I've seen little 
>  standards effort there, they may have decided to abandon the standards 
>  track, and just publish the MIBs under their trees?

>  > If that's what folks want to do. On the other 
>  > hand, we could also choose to progress only the document that Hilary's 
>  > group needs and drop the other three due to lack of 
>  > interest/implementation.  It's also fair to remind folks that these are 
>  > all IKEv1 MIB docs.
>  > 

>  Yes.

>  > 2. We need to come to agreement on what changes are needed, that is we 
>  > must address the MIB doctor comments.

>  Well, I can make the changes from enumerations to simple typedefs.  The 
>  real question is whether the IPSP folks are still interested in using 
>  this MIB if it doesn't have the enumerations in it.  To me, that was the 
>  primary value of the MIB, and why I convinced Tim to let me do it.  He 
>  was just exporting the variables as INTEGERs, which I found unfriendly. 
>    At least with any of the tools inheriting from the CMU ones, the 
>  enumerations are much more useful.

>  So, IPSP folks (you are on the CC: list, right?), do you still want this 
>  MIB without the enumerations?  If so, I'll make Mike's changes, and ship 
>  it out again.

>  > draft-ietf-ipsec-monitor-mib-06.txt? 

>  I think we can let them die, unless someone someone is wanting them.

>  > If so, who's willing to take on the 
>  > document editor job? And, more importantly, how do we decide what 
>  > changes are needed to them.
>  > 
>  > I feel like we're living in Groundhog Day with these MIB docs. We keep 
>  > living the same thing over and over. Let's please get to the end :-)

>  Yeah, it would have been _easier_ if there had been some controversy, 
>  rather than stunning silence all the way...

---

From: John Shriver <[email-masked]>
Date: Mon, 09 Jun 2003 09:51:35 -0400

Yes.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 13 Jun 2003 09:29:05 -0700

>>>>> On Mon, 09 Jun 2003 09:51:35 -0400, John Shriver <[email-masked]> said:

John> Absolutely.  The problem is that we lack a consensus on what to
John> do about Mike Heard's comments.

I'm pretty sure I remember posting quite a few posts about it (on your
side of things).

Also, there were a lot of other discussions (off-list) held by the MIB
experts that sided with Mike...

John> I suspect that nobody is implementing the related MIBs.

The IPSEC-POLICY-MIB has already been implemented (see the net-policy
project on sourceforge for details), which does depend on your draft
to date.  Specifically, I really need to know if your going to publish
a new draft or not and send it through last call.  If you don't, I'll
need to remove the dependencies from the IPSEC-POLICY-MIB.

>> 2. We need to come to agreement on what changes are needed, that is
>> we must address the MIB doctor comments.

John> Well, I can make the changes from enumerations to simple typedefs.
John> The real question is whether the IPSP folks are still interested in
John> using this MIB if it doesn't have the enumerations in it.  To me, that
John> was the primary value of the MIB, and why I convinced Tim to let me do
John> it.  He was just exporting the variables as INTEGERs, which I found
John> unfriendly. At least with any of the tools inheriting from the CMU
John> ones, the enumerations are much more useful.

John> So, IPSP folks (you are on the CC: list, right?), do you still want
John> this MIB without the enumerations?  If so, I'll make Mike's changes,
John> and ship it out again.

I'd do it just because it still provides a standard convention for the
datatypes and a standard place where the documentation about them
can be listed.  However, I agree it's less useful with the enums removed.

>> draft-ietf-ipsec-monitor-mib-06.txt?

John> I think we can let them die, unless someone someone is wanting them.

I think they'd be useful, but I haven't read them recently.  The
concepts in them are definitely needed and I've spoken to various
people lately about them and they agree that they'd be useful to put
into their products.  However, that doesn't mean they will.

-- 
Wes Hardaker
Network Associates Laboratories

---

From: John Shriver <[email-masked]>
Date: Fri, 13 Jun 2003 13:59:19 -0400

> experts that sided with Mike...

Yes.  But only a very small percentage of the WG has anything to say. 
Perhaps the absence of dissent counts as consensus...

> need to remove the dependencies from the IPSEC-POLICY-MIB.

I meant the three IPSec MIB that Tim and I did.  I know that the policy 
MIB has legs.

> can be listed.  However, I agree it's less useful with the enums removed.

Well, I will go ahead and do those changes.  I've even been working on 
MIBs in my paying job recently.

> into their products.  However, that doesn't mean they will.

If we were to keep them alive, they would need to migrate to IKEv2, 
which is no small project.  I don't see any point in MIB-ing IKEv1.

There would need to be authors who were committed to implementing it.

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 13 Jun 2003 15:19:12 -0700 (PDT)

[ Discussion moved to IPsec list at Barbare Fraser's request. ]

On Fri, 13 Jun 2003, John Shriver wrote:
JS> Wes Hardaker wrote:
JS> > John> So, IPSP folks (you are on the CC: list, right?), do you
JS> > John> still want this MIB without the enumerations?  If so,
JS> > John> I'll make Mike's changes, and ship it out again.
JS> > 
JS> > I'd do it just because it still provides a standard convention
JS> > for the datatypes and a standard place where the documentation
JS> > about them can be listed.  However, I agree it's less useful
JS> > with the enums removed.
JS> > 
JS> 
JS> Well, I will go ahead and do those changes.  I've even been working
JS> on MIBs in my paying job recently.

Sounds good.

JS> >>>draft-ietf-ipsec-ike-monitor-mib-04.txt,
JS> >>>draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and
JS> >>>draft-ietf-ipsec-monitor-mib-06.txt?
JS> >>
JS> > 
JS> > John> I think we can let them die, unless someone someone is
JS> > John> wanting them.
JS> > 
JS> > I think they'd be useful, but I haven't read them recently.  The
JS> > concepts in them are definitely needed and I've spoken to various
JS> > people lately about them and they agree that they'd be useful to put
JS> > into their products.  However, that doesn't mean they will.
JS> > 
JS> 
JS> If we were to keep them alive, they would need to migrate to IKEv2,
JS> which is no small project.  I don't see any point in MIB-ing IKEv1.
JS> 
JS> There would need to be authors who were committed to implementing it.

On the other hand, there is an author committed to finishing off
the IPsec Flow Monitor MIB module:

>>>>> On Fri, 13 Jun 2003 [email-masked] wrote:
RKS> We are still pursuing the IPsec Flow Monitor for standard track.
RKS> Could you please list the TopN good points of the drafts listed
RKS> above which may be incoprorated into the Flow Monitor MIB?
RKS>
RKS> I know you dissected at length the Flow Monitor MIB in 2001.
RKS> While I have read that (and addressed many of those criticisms
RKS> in the latest draft), I am hoping you could identify what features
RKS> of the MIBs listed above we could borrow into the Flow Monitor MIB.

Currently there is a flow monitor TC MIB that duplicates a lot of
the functionality of John's DOI TC MIB, which would be hard to
accept, but the flow mon mib author has indicated that he's willing
to switch:

>>>>> On Mon, 9 Jun 2003 [email-masked] wrote:
RKS> All that is of course irrelevant in addressing your comment about
RKS> duplication. I am quite willing to base the Flow Monitor MIB on the
RKS> textual conventions defined in draft-ietf-ipsec-doi-tc-mib-07.txt
RKS> provided it accomodates the textual convention defining the Control
RKS> Protocol: the IPsec Flow MIB can support different keying protocols
RKS> based on ISAKMP (termed 'control protocol') and uses a distinct TC
RKS> to type this value.

Actually, there are two TCs in the flow monitor TC MIB that are not
accounted for.  One is ControlProtocol, mentioned above, and the
other is Spi.  After looking over the Flow Monitor MIB in more
detail, I see that ControlProtocol (formerly named KeyType) does not
represent an actual field in a PDU whose value is defined in an IANA
registry -- which is the case for everything currently defined in
the DOI TC MIB -- but instead just serves to identify keying and
control protocols in the flow monitor MIB.  In my opinion a TC local
to the IPsec Flow monitor MIB (preferably with a less generic a name
like IPsecFlowMonControlProto) would suffice for that purpose.  If
it is really supposed to reflect the content of an IANA registry,
then there is already such a TC in the DOI TC MIB;  it is called
IpsecDoiTransformIdent, and it represents values recorded the
"IPSEC ISAKMP Transform Identifiers" entry in the IANA registry
http://www.iana.org//assignments/isakmp-registry

Now, the Spi TC (as I understand it) is supposed to represent possible
SPI values for AH (RFC 2402), ESP (RFC 2406), and IPComp (RFC 3173).
The IANA registry http://www.iana.org//assignments/spi-numbers
captures the special values for AH and ESP.  For IPComp the special
values are different:  they are "IPCOMP Transform identifiers" and
are recorded in http://www.iana.org//assignments/isakmp-registry
(and represented in MIBs by DOI TC IpsecDoiIpcompTransform).  However,
the SYNTAX of Spi is Unsigned32 (256..4294967295) which excludes
all the special values.  So, again, this TC is unaffected by the
contents of IANA registries it seems to me that it would be more
appropriate to use a TC that is local to the IPsec Flow Monitor MIB
rather than putting it in the DOI TC MIB.

In other words, I don't think that the DOI TC MIB should have to change
to accomodate these two TCs because (unlike all the stuff currently in
the DOI TC MIB) these things aren't linked 1-for-1 with something in
one of the IPsec-related IANA registries.

RKS, can you live with these two TCs being defined locally in the
IPsec Flow Monitor MIB?

>>>>> On Mon, 9 Jun 2003, C. M. Heard wrote (off-list):
CMH> John --
[ ... ]
CMH> If the decision is made to abandon the following three drafts:
CMH>
CMH>   draft-ietf-ipsec-ike-monitor-mib-04.txt,
CMH>   draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
CMH>   draft-ietf-ipsec-monitor-mib-06.txt
CMH>
CMH> then you should consider removing the TCs that are not used by
CMH> either the IPSP MIB or the IPsec Flow MIB.  Those would be:
CMH>
CMH> IpsecDoiSituation
CMH> IpsecDoiTransformIdent
CMH> IpsecDoiAhTransform
CMH> IsakmpDOI
CMH> IsakmpCertificateEncoding
CMH> IsakmpExchangeType
CMH> IsakmpNotifyMessageType
CMH> IkeGroupType
CMH> IkePrf
CMH> IkeNotifyMessageType

Because of some stuff I've found in the client MIBs I am going to
back-pedal a little bit on this advice.  Specifically, in the
IPSP MIB I see:

ipspAhTransformTable OBJECT-TYPE
    SYNTAX      SEQUENCE OF IpspAhTransformEntry
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "This table lists all the AH transforms which can be used to
         build IPsec proposals."
[ ... ]
ipspAhTranAlgorithm OBJECT-TYPE
    SYNTAX      IpsecDoiAuthAlgorithm
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object specifies the AH algorithm for this transform."

Based on the followind DESCRIPTION clause, it seems to me that the
SYNTAX value of ipspAhTranAlgorithm should probably be
IpsecDoiAhTransform:

   IpsecDoiAhTransform ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION "The values of the IPsec DOI AH Transform Identifier
                   which identify a particular algorithm to be
                   used to provide integrity protection for AH.  It is
                   used in the Tranform-ID field of a ISAKMP Transform
                   Payload for the IPsec DOI, when the Protocol-Id of
                   the associated Proposal Payload is 2 (AH).

(I also notices that the IPSP object ipspEspTranIntegrityAlgorithmId
has a SYNTAX value of IpsecDoiAuthAlgorithm, but that seems to be
correct.)

So before anything actually gets removed, I would like to suggest that
the authors of the IPSP MIB and IPsec flow monitoring MIB check their
stuff very carefully for errors like this.

Finally, I noticed something in the DOI TC MIB that appears to be
erroneous, and which I did not flag in the previous MIB doctor
review:

   IpsecDoiEspTransform ::= TEXTUAL-CONVENTION
       STATUS      current
       DESCRIPTION "The values of the IPsec DOI ESP Transform Identifier
                   which identify a particular algorithm to be used to
                   provide secrecy protection for ESP.  It is used in
                   the Tranform-ID field of a ISAKMP Transform Payload
                   for the IPsec DOI, when the Protocol-Id of the
                   associated Proposal Payload is 2 (AH), 3 (ESP),
                   and 4 (IPCOMP).                ^^^^^^
                                                  bug???

Since this and IpsecDoiAhTransform have different values, they can't
both apply then the Protocol-Id of the associated Proposal Payload is
2 (AH).

Thanks,

Mike Heard