RE: MTA MIB draft06 - AD comment #4

Jean-François,

> 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.
I don't see a problem with that.

> add "-- [RFC2863]" to mib module
No issues, seems to be addressing the concern.

Eugene.

-----Original Message-----
From: Jean-Francois Mule [mailto:[email protected]] 
Sent: Tuesday, September 06, 2005 6:03 AM
To: Thomas Anders; [email protected]
Cc: Eugene Nechamkin
Subject: 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