RE: 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]]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