Subject: Apparent duplication of TCs in draft-ietf-ipsec-flowmon-mib-tc-00.txt

From: "C. M. Heard" <[email-masked]>
Date: Thu, 17 Apr 2003 09:24:36 -0700 (PDT)

Howdy,

John Shriver has already pointed this out but there has been
no response, and the question is an important one.

It appears to me that the IPSEC-FLOW-MIB-TC MIB module in
<draft-ietf-ipsec-flowmon-mib-tc-00.txt> is mostly a duplication of
functionality that's already in the IPSEC-ISAKMP-IKE-DOI-TC MIB
module in <draft-ietf-ipsec-doi-tc-mib-07.txt>.  The table below
lists the TCs in IPSEC-FLOW-MIB-TC and shows the functionally
equivalent TC in IPSEC-ISAKMP-IKE-DOI-TC where one exists:

IPSEC-FLOW-MIB-TC       IPSEC-ISAKMP-IKE-DOI-TC

ControlProtocol         -- no equivalent --
Phase1PeerIdentityType  IpsecDoiIdentType (*)
IkeNegoMode             IkeExchangeType
IkeHashAlgo             IkeHashAlgorithm
IkeAuthMethod           IkeAuthMethod
DiffHellmanGrp          IkeGroupDescription
EncapMode               IpsecDoiEncapsulationMode
EncryptAlgo             IpsecDoiEspTransform
Spi                     -- no equivalent --
AuthAlgo                IpsecDoiAuthAlgorithm
CompAlgo                IpsecDoiIpcompTransform
EndPtType               IpsecDoiIdentType

(*) for some reason Phase1PeerIdentityType reshuffles the enum
values as compared to EndPtType.  The latter has the same enum
values as IpsecDoiIdentType, which in turn uses the IANA-assigned
Ident Type values.

My question to the authors of the flow mon MIB module is:  why is
there this apparent duplication?  Why doesn't the flow mon MIB use
the TCs from the DOI TC MIB module instead?  Note that the other
three IPsec MIB modules do so, as does the IPSP MIB module.

I do hope that the authors of the flow mon TC draft have been
following the discussion on the thread entitled
``Important question about draft-ietf-ipsec-doi-tc-mib-07.txt''
because the same criticisms that I have made about that draft
apply equally to the flow mon TC draft.  I do not want to have
to go through the same review process for two TC MIB modules
that have substantially similar capabilities;  it would be
much better from my perspective to consolidate the two efforts
and publish only one TC MIB module.  Is there a compelling
reason not to do so?

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 17 Apr 2003 09:24:36 -0700 (PDT)

Howdy,

Mike Heard