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

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 6 Sep 2005 13:59:37 -0600

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.

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

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 6 Sep 2005 18:06:46 -0700

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-masked]] 
Sent: Tuesday, September 06, 2005 6:03 AM
To: Thomas Anders; [email-masked]
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.

Comments appreciated.
Jean-François