RE: MTA MIB draft06 - AD comment #4

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