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]]
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]]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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.