RE: RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2

Andre,
 
It sounds like we have a SERIOUS MISMATCH between CL and IETF.
If CL wants to define their own stuff and mandate implementations BEFORE IETF approves
a MIB document, then that is fine... but then one should not come to IETF and try to get
IETF approval. It just does not work that way.
 
And even if you do these sort of things just within CL, even then I do see that you guys can
easily run into interoperability problems. We are not doing this just for the fun of it, but because
there are serious risks for inetroperability problems!
 
AGAIN, as I said before. if you want to root under docsIfMIb, fine. Write a doc similar to 
RFC3737 and we can do it. Not that we (IETF MIB Doctors) prefer it that way, but we/you (IPCDN WG)
can do it that way.
 
It would still mean that you can only get the branch assigned underneath docsIfMib AFTER
IESG approval. That comes back to possible interoperability issues if you assign it earlier.
 
Bert

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, January 06, 2005 18:24
To: [email protected]; [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2



Bert, 

The main problem is that CableLabs require CM and CMTS vendors to submit their equipment for a very expensive certification process using draft MIBs as pre-requisites into these certification waves (CW) and we, the vendors who have to pay for this certification process have very little influence into these decisions. If these MIBs were not required until they become RFC, then we would all be happy, except for the fact that the Cable industry wants to move faster than the time it takes to properly go through the RFC approval processes, which is a valid desire. Those who purchase the CM and CMTS equipment (the MSOs) will not purchase equipment that has not been previously certified by CableLabs.

I concur with Fred here on most of his points. Re-rooting any of the MIBs is a very expensive process as it costs 100s of thousands of dollars for every vendor as they require to implement and test the change and go through certification with the changes. Multiply this by the number of vendors and a simple re-rooting change can cost a million. Then looking into all support equipment that depends on these MIBs and more money and efforts get wasted.

I won't argue that MIBs that were defined against the experimental root can be re-rooted. I wish someone could find a way to avoid such re-rooting in the future. This is the case for the Subscriber Management MIB.

However, I don't agree that any of the other drafts need to be moved from where they were assigned in the past, even if the assignment was not done following approved processes.

The draft docsBpi2MIB was placed by someone under mib-2 transmission docsIfMIB and that was the right place for it. It is a MIB that needs to be maintained per interface, similarly to other MIBs found under the transmission tree. That person assigned the ID 6 to it, assuming it would be the next one to be adopted. It would not serve anyone if it was placed anywhere else.

The draft Event Notification MIB was placed by someone under mib-2 docsDev and assigned the ID 2 to it. I also think this was an appropriate place for such MIB and don't see a need to move it anywhere else.

The draft Qos MIB was placed under mib-2 transmission docsIfMIB and I also think that was an appropriate place for it, as it also needs to be maintained per interface. The person assigned ID 7 to it as it was the next available ID. We hope that this assignment will continue to be used for the RFC.

Maybe the solution to all this is to let the the IANA assign the numbers to wherever they want, but define requirements in the DOCSIS OSSI spec to re-root each of these RFCs to where they were first allocated. This is ugly in terms of documentation, but it matches the reality of having two standard bodies trying to define the same things, each with their own valid reasons.

André 


-----Original Message----- 
From: Wijnen, Bert (Bert) [ mailto:[email protected] <mailto:[email protected]> ] 
Sent: Thursday, January 06, 2005 6:42 AM 
To: Fred Oko; Jean-Francois Mule; [email protected] 
Cc: [email protected]; Eduardo Cardona; [email protected]; DOCSIS OSS 
Majordomo List 
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules 
O ID assignmen ts: Assigning new RFCs under mib-2 


Inline 

> -----Original Message----- 
> From: [email protected] 
> [ mailto:[email protected] <mailto:[email protected]> ]On Behalf Of 
> Fred Oko 
> Sent: Thursday, January 06, 2005 04:26 
> To: Jean-Francois Mule; [email protected] 
> Cc: [email protected]; Eduardo Cardona; [email protected]; 
>     DOCSIS OSS Majordomo List 
> Subject: [ipcdn] 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. 
> 
I think the above shows where we have a BASIC problem (and we discussed 
this in the past as well). 

When trying to standardize a MIB document in the IETF, then there should 
be NO assumptions on where the module gets rooted. That will ONLY be known 
once the document has been approved by the IESG. After that approval, it is 
IANA who assigns the OID. 

And that is exactly one of the reasons why we do not like that WGs start 
assigning MIB modules underneath some OID branch for that WG/technology. 

The reason for not wanting such early assignments (other than experimental) 
is that the MIB module may change (dramatically even) during the process in 
the IETF WG, IETF Last Call, MIB Doctor review, IESG review. And so if 
anyone implemented the MIB module based on some random revision 
of an Internte-Draft then that module (with assigned OID) might be completely 
different than the one that finally gets approved (same OID if you followed 
your logic). And so that WILL result in INTEROPERABILITY problems in the 
market place. 

See also draft-ietf-ops-mib-review-guidelines-03.txt sections 4.3 and 4.5 


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

While a MIB is under development in the IETF, no one should be assuming 
that such a MIB module is final and so no-one should be using a 
pre-assigned OID for the MIB module. If anything, one could 
use experimental (need to request an assignment though; also see 
warnings about that in mib review guidleines) or your own (vendor specific 
OID tree. Make sure you UNDERSTAND that the names (OIDs) should not 
conflict with any future final OID for the MIB once approved. 

> 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 

If one follows MIB guidelines/rules (and you MUST follow those to get a 
MIB module or an update to a MIB module approved in IETF), then these 
guidelines/rules (and associated MIB doctor review in IETF) will guarantee 
backward compatibility. If such needs to be compromised, then it would only 
happen with serious and explicit agreement of the WG and otehr IETF review 
(for example when everyone agrees that there was a BUG in an earlier module) 

>       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 
> 
Not sure I understand all points a-b. 
What is an MSO? 
What is CL CW? 

> 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 

that is good. 
But, since they only exists in Internet-Drafts, they have not really 
been assigned!!!! That is the thing to understand!!! PLEASE! 

> 2) no re-roots have been implemented in any code -- they only 
> exist in more recent drafts thus nullifying them is only on paper 
> 
As explained above, they SHOULD NOT exist in running code!!! 
This is a real basic approach of how we do Iinternet-Drafts and how 
and why we assign OIDs AFTER an Internet-Draft has gone through 
the whole IETF developement and review process and has been APPROVED 
by the IESG. 

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

I have explained to teh chairs, that a reroot is not MANDATORY. 
But IF you want to continue to allocate (or keep the current 
allocations) under docIfMib, then I would URGE you to create 
a document similar to RFC3737. 

And in the future, you would NOT let an Internet-Draft have any 
pre-assigned value, but instead have something aka: 

   ::= { docsIfMib xx } -- xx to be assigned by IANA as per 
                        -- procedures outlined in <your-rfc3737-equivalent> 

So you (the WG) has basically been mis-using the fact that you 
had a docIfMib branch and were pre-assigning values against the 
normal process, and with the risk of having incomp-atible versions 
of MIB modules in implementations! 

> 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. 
> 
Totally agree. And having 4 or 5 potential places to root a 
new MIB mdoule aka 
  docsIf, experimental, mib-2-pending, clab 
seems REALLY REALLY bad to me. 

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

Bert Wijnen, 
speaking as co-AD for the IETF OPS area. 
open to a good discussion on this topic and to try and document 
the correct and agreed way for new and furture MIB dvelopement 
in this space. 

Bert 
NOTICE: This communication contains information which may be proprietary, privileged or confidential. If you are not the intended recipient (or authorized to receive for the intended recipient), or believe that you have received this communication in error, please do not print, copy,retransmit, disseminate, disclose or otherwise use the information. Also, please indicate to the sender that you have received this communication in error and delete the copy you received. Thank you.

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