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

["Eduardo Cardona" <[e-mail]>]

few comments inline

-----Original Message-----
From: Fred Oko [mailto:[e-mail]] 
Sent: Friday, January 07, 2005 1:05 AM
To: Jean-Francois Mule; [e-mail]
Cc: [e-mail]; Eduardo Cardona; DOCSIS OSS Majordomo List; [e-mail]; Dan Rice
Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2


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.

In part I was under the impression that the draft period was a time not only for forward evolution but that time would also be given to examine the operational impact imposed upon MIB implementers and consumers so as to not run into a brick wall once the RFC is cast in stone/shipped -- we could later call it foresight. 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. 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. 


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). The only other field deployment precedent to such a case yet faced by CableLabs MIBs was the noted docsDev experimental and RFC versions at the CM level. But there the two versions were interchangeable but for OID root while here there could be a mandate to support two, as you note, quite different versions of what in some cases can be expensive MIBs to manage resource-wise.

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. I would expect this to be one trait to consider in evaluating possible technology replacements for SNMP in DOCSIS3.0 such that it is easier to support versioning through handshake or views.

<Edo>
 
SNMP semantics is believed to be rich enough to have a solution for transitions, 
If in the past docsis required the dual implementation of CD MIB in experimental as well as RFC 2669, we always take take the exercise of evaluate those consiredations for backward compatible analysis as the specs evolve
Specially on those days (DOCSIS 1.0) it was a matter of one MIB module for CMs with reduced number of instances per MIB structures such tables. 
In the current case (anyway outside of the topic discussion) we are also covering CMTS which is a different situation
Thanks for pointing out those elements that certainly are critical in deciding where to shift the transition cost ( device or Management system).
 
- The history told us that DOCSIS 1.0 put the load in the CM, 
DOCSIS 1.1 removed that "dual" MIB requirement so we have 4 years of DOCSIS 1.1 requirements that hopefully are pusshing the NMS applications to the next level

In particular, as well as SNMPv3 stack normaly automatically does Engine ID discovery, I believe it is expected for the NMS to do Mib modules per device registeration by querying sysOrTable and dynamically swap MIB modules and or Management routines and scripts. (Agree reads simple but could be complex, but what application on todays days is dump simple?)

That's not such difference on already products ready to switch from IP MIB RFC 2011 to the upcoming RFC 2011 updates for IPv6. as an example:
ipNetToPhysicalTable replaces ipNetToMedia
 - Changes of Object names
 - Changes of Index structure ( INETAddress requirements)
It means total applications rewrite

In our case "in the eventuality of updates" to new RFCs
- Majority of the objects keep the same name ( different MODULE name)
- A discovery process as indicated above will do most of the work
- Potentially Apps can stay quite the same, just the OID engine need to be smarter

Again, not saying that is easy, cost implications etc. other forums or discussions will decide that.

In summary, The Cable transition from one root to another, Is necessary, not an isolated case, (not exclusive for "rapid deployment" industries).  All IETF faces those paradigms, and the solutions for backward compatibility, and old devices support should (wish) come from all IETF parties. 

Your DOCSIS 3.0 comments
Based on your inertia of cross-pointing lists, please note that there is also a DOCSIS 3.0  Majordomo list, which I verified you are already subscribed.
 
</Edo> 



-----Original Message-----
From: Jean-Francois Mule [mailto:[e-mail]] 
Sent: Thursday, January 06, 2005 1:27 PM
To: Fred Oko; [e-mail]
Cc: [e-mail]; Eduardo Cardona; DOCSIS OSS Majordomo List; [e-mail]; Dan Rice
Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2

Fred,
  
  Let me be direct: your email is totally inappropriate, and actually, misplaced.

  First, you responded to an email sent by Eduardo Cardona to the sole DOCSIS OSS reflector and copy the public IETF IPCDN reflector: you are effectively breaking the IPR policy your company signed. Worse, you included comments sent by André, comments that were solely sent in response to the DOCSIS OSS email Eduardo had sent). This is inappropriate.  Note that Eduardo and I wanted to ping the CableLabs DOCSIS OSS vendor team first by respect of the work those vendors have done for the MIBs and continue to do by bringing implementations to market - most of those vendors have implemented the DOCSIS MIBs we are talking about and not all unfortunately are watching the IPCDN traffic.

  Second, you missed the point of my email, the email I sent to the IETF IPCDN reflector. Note that in total transparence for the IETF process, we (Eduardo and myself) did communicate the same points to both the CableLabs DOCSIS OSS and IETF IPCDN reflectors. We asked internally the DOCSIS OSS team first as the MIB module in question was designed and evolved thanks to all the original contributions of the individuals and vendors part of the DOCSIS OSS team. But in the end (and that is the purpose on my email), the IETF IPCDN wg prevails and the IETF wg consensus is the one that matters.

Jean-Francois.

  

> -----Original Message-----
> From: Fred Oko [mailto:[e-mail]]
> Sent: Wednesday, January 05, 2005 8:26 PM
> To: Jean-Francois Mule; [e-mail]
> Cc: [e-mail]; Eduardo Cardona; DOCSIS OSS 
> Majordomo List; [e-mail]
> Subject: RE: IETF IPCDN proposed standard drafts MIB Modules 
> OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> I would agree that a MIB for which the author had the
> foresight to root in the experimental(3) branch would be 
> expected (both by MIB consumers and IETF) to be re-rooted for 
> RFC transition. However, this only applies to the 
> subscriber-mgmt MIB. I would argue that there is no value, 
> only negative operational implications, and no impervious 
> mandate for re-rooting any other MIB that has already seen 
> widespread implementation and consumption. I would argue this 
> not only for the QOS MIB, but for any draft MIB for which 
> originally had a sub-docsIfMib or enterprise root that was 
> mandated to be supported in any already passed CableLabs 
> certification wave. The reasoning is that since these objects 
> were implemented by CM/CMTS vendor and qualified, they have 
> most certainly been also implemented against by existing OSS 
> software, wherein lies definite operational impact of such a 
> major change.
> 
> Impact points of any re-root:
> 1) common to any change: CMTS and CM vendor must change code,
> CL must update ATP etc for qualifications, vendors must 
> re-qualify code, and MSO's must deploy new code (granted 
> required just for other MIB updates if not re-root)
> 2) a decision must be made whether a CMTS or CM is 
> backward-compatible (either as mandated by CL or discretion 
> of vendor as advised by MSOs) and supporting two instance of 
> a MIB has implications -- and regardless the decision of 
> backward-compatibility on a single device, any OSS that 
> monitors across a non-homogeneous field will of course have 
> chance to run into new and old instances
> 	a) multiple OIDs for same subidentifiers must be known 
> by clients which may have preference to use non-fully-qualified
> 	b) if back-compat, collection must limit itself to one 
> of the two instances to avoid double collection thus 
> requiring conditional logic based on probing
> 	c) I would expect any MSO with utilities that are 
> broken by such a re-root will demand this "bug" be fixed by 
> the vendor thus forcing effective back-compat
> 	d) it may be difficult for some SNMP agent 
> implementations to support efficient backward-compatability 
> (i.e. two OIDs mapping to same in-memory data) as such 
> efficiency would be a must for some of the expensive MIB tables
> 3) Since CL CW have continued to require very old drafts we 
> know that implementation against the "old"/only OIDs have 
> been in use for a while
> 
> No real impact points of not re-rooting anything -- simplest path:
> 1) current OID assignments, while not actually assigned by
> IANA are guaranteed to be non-conflicting
> 2) no re-roots have been implemented in any code -- they only 
> exist in more recent drafts thus nullifying them is only on paper
> 
> Additionally I personally see little value in the any
> re-roots beyond philosophical cleanliness. I do agree that 
> all MIBs may not be semantically perfect below docsIf, but I 
> take it as the best hierarchical umbrella we have on that 
> road that has been traveled. If we were forced to re-root I 
> would advocate at least leveraging hierarchy by contextually 
> group all CL/IPCDN related objects together instead of having 
> them assigned loosely and likely non-contiguously into the 
> mib-2 free space. E.g. in that sense I was a fan of the 
> enterprise clab root.
> 
> The very nature of so many representative MIB-rooting
> conventions across the many CL-related MIBs (docsIf, 
> experimental, mib-2-pending, clab) suggests if this is not 
> exactly a contentious issue, it is definitely one still open 
> to the author's discretion which one might tend to agree has 
> been non-optimal. I also see a variable modification time of 
> these drafts at some middle revision to change OID roots 
> which indicates it was not guided by a single firm guiding 
> consensus (but perhaps MIB doctor advice trickle effect?). I 
> would advocate that a firm future-guiding decision be made 
> that would apply to all as-of-yet unwritten MIBs.
> 
> Though were these proposed re-roots to make their way
> unimpeded into continued-draft/RFC/ECR/cert-wave would a good 
> time estimate to seeing such in the field be late 2006?


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