Subject: MTA MIB draft06 - AD comment #4 (RE: [ipcdn] RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt)

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 5 Sep 2005 10:40:01 -0600

Thomas,

   Thank you for your input. I am splitting the threads to separate emails. This one is comment #4.

Jean-François

Thomas Anders wrote:
> Jean-Francois Mule wrote:
> >   We would appreciate receiving quick input from you and the wg on
> the
> > proposed changes for draft 07
> 
> Here are my initial comments on #4, #14, #15 and #38:
> 
> > # Comment 4
> >>     !! Missing citation for Normative reference:
> >>     P047 L040:    [RFC2863] McCloghrie, K., Kastenholz, F., "The
> >> Interfaces Group
> >
> > ok, the reference is mostly because of the IMPORT of the IF-MIB.
> > Proposed resolution: reference to [RFC2863] is introduced. We
> propose
> > to add the following text in section 3:
> >
> >    EMTA devices implementing this MIB Module MUST be compliant with
> >    RFC 2863 [RFC2863] and the Packetcable MTA Device Provisioning
> >    Specification [PKT-SP-PROV].
> >
> > (we're also proposing to also add the existing normative reference
> to
> > the MTA device provisioning spec here).
> 
> Isn't this a formal problem? 
 Not sure what you mean by "problem".

The "problem" solved by Comment #4 is missing citation.
 PKT-SP-PROV has always been a normative reference and it is also the case for RFC 2863 (due to the IMPORTs).

The "problem" you refer to below is imo for CableLabs to address. More inline.
> [PKT-SP-PROV] (PKT-SP-PROV-I10-040730)
> itself has normative references to PKT-SP-MIB-MTA-I09-040402 (which
> our
> IPCDN MTA MIB is going to supersede) all over the place! 
This is the usual chicken and egg kind of problem, and one of synchronizing cross-references.
For the IETF to get the RFC out, one must have a stable reference that is published (it can't be PKT-SP-PROV-Ixx where xx is a future version referencing the IETF RFC).
For ETSI/ITU/CableLabs, we can't even start to consider the IETF MTA MIB rfc until it is published...

> Can we still
> - say "MUST be compliant with ... [PKT-SP-PROV]"
Yes. To my knowledge, PacketCable/IPcablecom MTAs do follow 1 spec for provisioning, and one can:
	a) comply with PKT-SP-PROV 
  and
	b) comply with RFC-to-be

> - list [PKT-SP-PROV] as a normative reference at all
> then? If we can't, this may affect the IPCDN MTA MIB at several places.
It has been there since draft02, and the draft passed 2 WGLC with it.

> Will the PacketCable 1.0 specs be updated to include a normative
> reference to the IPCDN MTA MIB (instead of [PKT-SP-MIB-MTA-I09]) after
> it has become RFC?

This is a question for:
	- CableLabs and its MSO members, as far as the PacketCable specifications are concerned;
	- the ETSI and the IPcablecom specifications 
	- the ITU SG9 for the ipcablecom recommendations still referencing the CableLabs mibs.

I will note that you have no particular comment on how the proposed text addresses the "problem" raised by Comment#4 per se.

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 00:05:12 +0200

>>>   Specification [PKT-SP-PROV].
[...]
>>our IPCDN MTA MIB is going to supersede) all over the place! 

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 ?

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? If so, is 
this fully intentional?

> 	- CableLabs and its MSO members, as far as the PacketCable specifications are concerned;

If it's only a chicken-and-egg problem, then there'll hopefully be a 
chicken following the egg (or vice versa) at the end. ;-)

+Thomas

-- 
Thomas Anders (thomas.anders at blue-cable.de)