[ipcdn] Compliance statement in RF MIBv2 draft 08

["Jean-Francois Mule" <jf.mule@cablelabs.com>]

Folks,

Reviewing the RFI mib draft08, we have 2 module compliance statements, one for v1 (RFC 2670) and one for v2 (new RFC which will obsolete RFC 2670 - not update but obsolete per RFC2233).
-- RFC 2670
docsIfCompliances  OBJECT IDENTIFIER     ::= { docsIfConformance 1 } 
docsIfGroups       OBJECT IDENTIFIER     ::= { docsIfConformance 2 } 
-- new RFC
docsIfCompliancesV2  OBJECT IDENTIFIER     ::= { docsIfConformance 3 }
docsIfGroupsV2       OBJECT IDENTIFIER     ::= { docsIfConformance 4 }

The docsIfCompliancesV2 compliance statement defines the groups of objects for v2 (the v1 objects plus the new v2 ones minus some deprecated ones like the docsIfCmtsCmStatusIpAddress which used the old IpAddress type for e.g.). 3 objects in total are deprecated from v1 -> v2.

Is there any good reason why both the v1 RFC2670 and v2 statements have a STATUS of current? Isn't the intent was to deprecate the v1 compliance statement along with the v1 groups. 

If the intent of draft08 is to mandate some v1 deprecated objects in the v2 implementation, I believe the right way to do this is to actually put a deprecated object in a mandatory v2 group as described in the mib guidelines:
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-02.txt
   - The status of a conformance group is independent of the status of
     its members.  Thus, a current group MAY refer to deprecated objects
     or notifications.  This may be desirable in certain cases, e.g., a
     set of widely-deployed objects or notifications may be deprecated
     when they are replaced by a more up-to-date set of definitions, but
     the conformance groups that contain them may remain current in
     order to encourage continued implementation of the deprecated
     objects and notifications.

Jean-François 


_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn