[ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2

Fred Oko wrote:
> OK, sorry if I have transgressed. In part my cross-posting 
> was something I questioned and took guidance from seeing some 
> previous cross-posting (being the most efficient 
> distribution) on the reflectors but will be careful to avoid 
> such in the future. As a theme of this thread I embrace, we 
> learn by doing.

No problem. Sorry if my email response was perceived as harsh, it was not intended.

[snip]

Fred Oko wrote:
> But as you say some of the drafts have 
> taken directions that no longer support 
> backward-compatibility and would in fact mandate a re-root to 
> prevent OID<->object conflicts etc. 

So does this mean you are ok with the IETF IPCDN QoS MIB Internet-Draft 10 being changed to request an OID assignment under ..mib-2(1)?  I would like to get wg consensus on this: we have to move this draft along to get it on the IESG agenda asap.

> As I was not tracking 
> this at the time I can only assume that this was the only 
> (/optimal by consensus) path and no longer open to review e.g.
> 
>     REVISION        "200302010000Z" -- February 1, 2003
>     DESCRIPTION
>         "Published as draft-ietf-ipcdn-qos-mib-07.txt.
> 
>         Changes from qos-mib-06 include:
> 
>         - Re-routed the docQosMib because of compilation errors.
>         - Removed obsolete and deprecated objects.
>         - Renumbered existing objects after removal of
>           obsolete and deprecated objects.
> 
> and the subsequent renaming to DOCS-IETF-QOS-MIB from DOCS-QOS-MIB.
  Yes. For reference, this is well documented.
  On 2/13/03, during the interim IPCDN wg meeting held at CableLabs chaired by Rich Woundy and myself, Bert Wijnen had strongly recommended this approach when reviewing the BPI+ mib draft 06. We as a wg approved to re-route the DOCSIS BPI+ then under mib-2, and we also agreed to change all IPCDN MIB module identity names.
  See http://www.ipcdn.org/meetings.html, Feb 13 2003 meeting,
  and the notes recorded in the IETF proceedings at:
  http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/index.html

> But note that my original references to 
> backward-compatibility were not referring to the desired 
> intra-MIB backward-compatibility (to the version mandated to 
> be implemented) we have lost but instead of the likely 
> necessity of the CMTS to support (post-reroot) 
> backward-compatability at the SNMP agent application layer by 
> concurrently exposing both the already-implemented draft MIB 
> in addition to the RFCed version (i.e. transition period). 
  Ok. The latter is always what I meant. Note that, as I pointed out, the decision to mandate the "likely necessity of the CMTS to support" is something that will be done by cable operators. Be assured that we will deal with this extremely carefully and communicate with the vendors as part of the CableLabs process (this is btw not a topic for discussion in IETF).

> I would think the experiences of the respondents on this 
> thread would cry out for a better scheme for handling such 
> version incompatibilities if this is truly such a common 
> occurrence with internet drafts in industries that demand 
> rapid deployment. 
  Isnt' the way we have dealt with those issues in the CableLabs PacketCable and Cablehome projects answering your request for a better scheme?

Jean-François 

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn