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

Jean-Francois Mule wrote:
> Thomas Anders wrote:
>>Jean-Francois Mule wrote:
>>>   EMTA devices implementing this MIB Module MUST be compliant with
>>>   RFC 2863 [RFC2863] and the Packetcable MTA Device Provisioning
>>>   Specification [PKT-SP-PROV].
[...]
>>[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

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?

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

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)