RE: Re: MTA MIB draft06 - AD comment #4

We will note your agreement on how we propose to address comment #4 which includes your feedback.

See more inline but I believe this thread is now departing in a different direction that has not much to do with IETF IPCDN. 

Before we can discuss what it means to mandate the MTA MIB RFC, we should have one. Like with the DOCSIS mibs, folks tend to get "concerned" about what it means to have the RFC and how migration and co-existence will work. Let's get the RFC out which is this wg focus and then, participate in the various organizations that mandate variants of the RFC MIB to define how to best cope with it.

Thank you for your input,
Jean-François
Responding as co-author of the IPCDN MTA MIB

I wrote:
> > 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.

Thomas Anders wrote:
> 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. 
Well I would clearly disagree. See below. A "compliant" device means:
	- compliant with the IETF RFC MIB module, and/or,
	- compliant with whatever specifications define an MTA, and its provisioning and management requirements. In our case, given the title of the ID, it is about IPcablecom (ETSI) and PacketCable(tm) MTAs (CableLabs).

 
> 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.
You have 2 different OIDs, a device can send notifications with one, or the other, or both. Ideally, you want the exclusive OR (XOR) but theoretically, there is not technical issue for sending both.

But that is not even the point. A PacketCable compliant device, complying with the current version I11 of the PROV spec will have to comply with the MUST statement in that spec and send the proper notification and send the PKT-SP-MIB-MTA, period.
In addition, if a device also complies with the RFC, it must comply with the MUST/SHOULD/etc. of that RFC.

ETSI, CableLabs and other organizations will likely investigate what the best strategies are to revise the specs affected by the publication of a standard-track IETF RFC based on the service operator's requirements and guidance. 

> 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 seprate thread on this if appropriate.
My focus as co-author of the MTA MIB is to advance the ID and this is the scope of this wg I think.

> 
> WG comments appreciated.