Subject: [ipcdn] RE: MTA MIB draft06 - AD comment #4

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 6 Sep 2005 07:02:35 -0600

Thomas,

   Comments inline,

Jean-François

Thomas Anders wrote:
> I'll try to rephrase my questions/remarks, aiming at clarification:
> 
> 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.

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.

> ii) Will the proposed "EMTA devices implementing this MIB Module MUST
> be
> compliant with [...] [PKT-SP-PROV]" (hence the relation of this thread
> to #4) introduce a stronger requirement than the existing normative
> reference to [PKT-SP-PROV], REFERENCE'd in some MIB objects? 

Oh ok. Well, a normative reference is normative and you may want to read section 1.1 of RFC 3967:
"  Broadly speaking, a
   normative reference specifies a document that must be read to fully
   understand or implement the subject matter in the new RFC, or whose
   contents are effectively part of the new RFC, as its omission would
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   leave the new RFC incompletely specified.  An informative reference
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   is not normative; rather, it provides only additional background
   information."

That said, if your comment is that the MUST is not appropriate to solve comment #4, if Eugene is ok, I'm ok to remove it. 

> If so, is
> this fully intentional?

Here was the rationale. The purpose of the comment was to add a citation to RFC 2863.

To recap, the normative reference comes from the following IMPORT in the mib  module:
   IMPORT...
       ifPhysAddress 
             FROM IF-MIB;
  which is there because we send the ifPhysAddress in the pktcMtaDevProvisioningEnrollment notification (defined further in the PKT-SP-PROV MTA Device provisioning specification, step mta-15). It is in the provisioning specification that we define the enrollment. There are several references of the MTA MAC address in the enrollment process (ifPhysAddress). Hence the proposal.

But given that we also added the citation in the mib import section:
    ifPhysAddress
          FROM IF-MIB;                       -- [RFC2863]
  we could do without this addition.

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

Comments appreciated.
Jean-François

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Thomas Anders <[email-masked]>
Date: Tue, 06 Sep 2005 16:15:26 +0200

> 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…

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…

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.

> 	- 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)