Re: MTA MIB draft06 - AD comment #4

Thomas Anders <[email protected]> Tue, 06 Sep 2005 16:15:26 +0200
Newsgroups gmane.ietf.ipcdn
Message-ID <[email protected]>
Jean-Francois Mule wrote:
> Thomas Anders wrote:
>>i) Generally speaking: can the RFC-to-be say "MUST be compliant with
>>[xxx]" if
>>- [xxx] says "MUST be compliant with [yyy]" *and*
>>- [yyy] contradicts the RFC-to-be ?
> If what you are implying is that the current MTA MIB Internet Draft cannot be compatible with the PacketCable PROV spec ("contradicts"), or, that the 2 MIB modules mentioned above "contradict" each other, please elaborate and provide specific references as we certainly need to look at these.

xxx==PKT-SP-PROV and yyy==PKT-SP-MIB-MTA. Sorry if this wasn't clear.

> If what you are reacting to is in fact that there are 2 MIB modules that may co-exist (the RFC version of the MTA MIB to be registered under IANA mib-2 and the original CableLabs MTA MIB under the CableLabs private OID), then so it be it. I don't see any issues there, a compliant device can technically implement both.

I'm not sure I agree. For example, [PKT-SP-PROV], section 7.2, requires 
the MTA in provisioning step MTA-15 to send an SNMP-INFORM that "MUST 
contain a PktcMtaDevProvisioningEnrollment object as defined in [2]" 
([2]==[PKT-SP-MIB-MTA]). At the same time, the RFC-to-be (IPCDN MTA MIB) 
says:

    pktcMtaDevProvisioningEnrollment  NOTIFICATION-TYPE
        OBJECTS { ... }
        STATUS   current
        DESCRIPTION
            " This INFORM notification is issued by the MTA to initiate
              the PacketCable provisioning process when the MTA SNMP
              enrollment mechanism is used. ... "

AFAICS, the MTA can only send *either* the [PKT-SP-MIB-MTA] *or* the 
RFC-to-be notification. There may be other examples as well.

Now, I tend to agree with your modified proposal:

> Proposed resolution for AD Comment 4 (pending Eugene's ok):
> 	- add "-- [RFC2863]" to mib module.

This would leave us with the question above on what we can do about the 
potential contradictions (to be discussed) between the RFC-to-be and its 
normative references [PKT-SP-PROV] and (transitively) [PKT-SP-MIB-MTA].

Feel free to open a separate thread on this if appropriate.

WG comments appreciated.


+Thomas

-- 
Thomas Anders (thomas.anders at blue-cable.de)