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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 6 Jan 2005 12:41:38 +0100

Inline

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Fred Oko
> Sent: Thursday, January 06, 2005 04:26
> To: Jean-Francois Mule; [email-masked]
> Cc: [email-masked]; Eduardo Cardona; [email-masked]; 
>     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

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

---

From: [email-masked]
Date: Thu, 6 Jan 2005 09:24:04 -0800

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-masked]]
Sent: Thursday, January 06, 2005 6:42 AM
To: Fred Oko; Jean-Francois Mule; [email-masked]
Cc: [email-masked]; Eduardo Cardona; [email-masked]; 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

of an Internte-Draft then that module (with assigned OID) might be
completely

that is good.

Bert Wijnen,

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-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 6 Jan 2005 19:51:16 +0100

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-masked] [mailto:[email-masked]]
Sent: Thursday, January 06, 2005 18:24
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
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-masked] <mailto:[email-masked]> ] 
Sent: Thursday, January 06, 2005 6:42 AM 
To: Fred Oko; Jean-Francois Mule; [email-masked] 
Cc: [email-masked]; Eduardo Cardona; [email-masked]; DOCSIS OSS 
Majordomo List 

Inline 

> [ mailto:[email-masked] <mailto:[email-masked]> ]On Behalf Of 
> Fred Oko 

that is good. 

Bert Wijnen, 

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.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 6 Jan 2005 13:35:13 -0700

André et al.,

  Please let us stick to the engineering issues and technical questions at stake. I'm trying hard to keep this thread focused on technical issues and keep it under control, please help me...

  I will only respond to the technical points. See inline.

Jean-Francois 

> Sent: Thursday, January 06, 2005 10:24 AM
> To: [email-masked]; [email-masked]; Jean-Francois Mule
> 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 

[snip, stripped non technical comments, irrelevant to the thread]

> certification process using draft MIBs as pre-requisites into 
> these certification waves (CW) 

A clarification is required:
 - the comment on MIB requirements pointing to IETF ID is only applicable to DOCSIS. We have learned from it and if you take the PacketCable MIB requirements for example, the MIB modules are rooted under the CableLabs private OID branch.

[snip, stripped non technical comments, irrelevant to the thread]

< If these MIBs were not 
> required until they become RFC, then we would all be happy, 
  This is the case for CableLabs projects like PacketCable and Cablehome and it has been our approach since 2002 for any new MIB in any project (including DOCSIS, the eDOCSIS SLED mib is a good example of it).
  The precedent has been set for DOCSIS and there is not much we can do about it other than work towards completing the RFCs to then analyze the gap between what we have been requiring and using in the field for years, and what the standard-track RFCs require. This is the only rationale process I can recommend, otherwise, we keep arguing about drafts that are moving targets, making suppositions about what will be required by CableLabs - this wg is not the right place for that.

Ultimately, we are all servicing the same clients, our cable operators, the service providers that deploy these MIBs and manage the network elements with it.

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

  Consider this: if we had put the original DOCSIS MIB modules under the CableLabs private tree to start with, this entire discussion would be moot. We would have private CableLabs MIBs and IETF RFCs. The migration path would still need to be analyzed and code changes made to support the RFCs. This is no different than what some vendors do with other wg MIB ID: they need mib objects to go to market with, put them under their private branch until the IETF is done, then make code and tool changes to move to the RFCs.

[snip, stripped non technical comments, irrelevant to the thread]
> 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. 

I will only respond to the technical part of this comment.
Read my response to Fred's email. The re-rooting is actually not the hardest piece here, it is the actual syntax and semantic changes that went into those MIBs that would cause the bulk of the work, on both the CM/CMTS network elements and the mgmt applications that use those mibs.
This about how we had been using Counter32 objects for e.g. and how we have come along... Same goes for many technical changes.

[snip, stripped non technical comments, irrelevant to the thread]

> be re-rooted. I wish someone could find a way to avoid such 
> re-rooting in the future. 

  Tell me if what we have been doing since 2002 in other CableLabs projects helps. 
  The solution to date has been: the private CableLabs MIBs should be defined under the CableLabs private OID.
  You, vendors with requirements from operators contribute to design MIB modules in the CableLabs project. We define them under the CableLabs private OID branches to go to market with. As we go through the standard process, we make some changes (look at the many PacketCable Engineering Changes that were introduced in our private MIBs based on the learning we went through due to the IETF process - simple things like changing ipAddress to the RFC 3291 textual conventions to just correcting plain wrong SMI syntax issues). We also submit the original MIB and changes to the IETF process when it is appropriate. Once we reach RFC status, an analysis of the gaps between the RFC and what is being implemented by vendors can be done with all kinds of considerations (costs, benefits, etc.). Ultimately, the cable operators make those important decisions on the product requirements.

> The draft docsBpi2MIB was placed by someone under 
> mib-2 transmission docsIfMIB and that was the right place for 
> it. 

  No.
  The IETF IPCDN ID for the DOCSIS BPI+ MIB, defining the docsBpi2MIB module, ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-15.txt, is requesting an assignment under mib-2.

> 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. 
/wg chair hat on
  This assignment was WRONG, and should NEVER have been done. Let's not use the bad examples of the past to justify what we should do now!!!
  We should have moved this set of MIB requirements under the CableLabs branch before it even became an ID, freeze those requiremetns as we like, then pursue the IETF standardization process as we have.
wg chair hat off/

> It would not serve anyone if it was 
> placed anywhere else. 

  See above, I disagree.
  The OID assignment in that branch is the sole authoritative responsibility of IANA and noone else should make any assignment in the IANA controlled namespace. 

> The draft Event Notification MIB was 
> placed by someone under mib-2 docsDev and assigned the ID 2 
> to it. 
Same comment as above.

> I also think this was an appropriate place for such 
  I disagree, see above.

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

Jean-François

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 6 Jan 2005 13:54:09 -0700

Bert,

  We have discussed this set of issues for DOCSIS with Thomas Narten, yourself and Rich many times since 2002. Since then, I do not believe we have a mismatch. What was done was done, there is not much we CableLabs, the vendors or anyone can do about it.

  Let me be clear that we have worked hard to change the way we do things with MIBs and other IETF Internet-Drafts for that matter. My earlier emails on what we have done in PacketCable should provide detailed examples. Let me give you another example: in the SIP/SIPPING working groups, with the help of several vendors, we initiated the SIP DCS proxy-to-proxy draft and we worked with the wg chairs and Allison to get the draft to RFC. We then changed our SIP-based spec (PacketCable CMSS) to reference this RFC. Same for RFC 3495 on DHCP option 122 (which replaced an experimental DHCP option 177 assignment and that transition has gone well in the specs and in the field).

 See inline for additional comments.

Jean-François

> Sent: Thursday, January 06, 2005 11:51 AM
> To: [email-masked]; [email-masked]; Jean-Francois Mule
  As I said above, I don't think we have any serious mismatch.  

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

  With the time some of us put in the IETF work in various working groups, and my wg chair stance on IPCDN MIB issues when folks invoked "existing implementation" reasons in order not to address the comment, I hope you believe that we bring some contributions in the full spirit of IETF and that we benefit from expert advice and simple good engineering practices.

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

> We are not doing this just for the 
> fun of it, but because there are serious risks for 
> inetroperability problems!
> 
> 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.

  Back to the original question, I have yet to see any good reason for not changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS MIB. Did I miss anything?

> 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

---

From: [email-masked]
Date: Thu, 6 Jan 2005 13:13:48 -0800

Jean-Francois,

What are the attributes that a MIB has to have, in your opinion, for being
added to the transmission OID under mib-2, as opposed to only be added to
mib-2? I presented my opinion regarding this, which was that a MIB that
would only be applicable to a certain type of interface would be better
placed under the associated transmission type rather than being placed at
the mib-2 level. I have not seen any justification for not doing this with
the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts of the
BPI+ MIB is requesting them under mib-2, which is not a sufficient
justification in my opinion.

André

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]]
Sent: Thursday, January 06, 2005 3:54 PM
To: Wijnen, Bert (Bert); [email-masked]; [email-masked]
Cc: [email-masked]; Eduardo Cardona; [email-masked]; DOCSIS OSS
Majordomo List

Bert,

  We have discussed this set of issues for DOCSIS with Thomas Narten,
yourself and Rich many times since 2002. Since then, I do not believe we
have a mismatch. What was done was done, there is not much we CableLabs, the
vendors or anyone can do about it.

  Let me be clear that we have worked hard to change the way we do things
with MIBs and other IETF Internet-Drafts for that matter. My earlier emails
on what we have done in PacketCable should provide detailed examples. Let me
give you another example: in the SIP/SIPPING working groups, with the help
of several vendors, we initiated the SIP DCS proxy-to-proxy draft and we
worked with the wg chairs and Allison to get the draft to RFC. We then
changed our SIP-based spec (PacketCable CMSS) to reference this RFC. Same
for RFC 3495 on DHCP option 122 (which replaced an experimental DHCP option
177 assignment and that transition has gone well in the specs and in the
field).

Jean-François

> to get IETF approval. It just does not work that way.

  With the time some of us put in the IETF work in various working groups,
and my wg chair stance on IPCDN MIB issues when folks invoked "existing
implementation" reasons in order not to address the comment, I hope you
believe that we bring some contributions in the full spirit of IETF and that
we benefit from expert advice and simple good engineering practices.

  You bet.

> prefer it that way, but we/you (IPCDN WG) can do it that way.

  Back to the original question, I have yet to see any good reason for not
changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS MIB. Did
I miss anything?

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 6 Jan 2005 16:48:07 -0500

Here is what the current MIB guidelines (
<http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03
.txt>
http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.
txt, section 4.5)have to say:
 
   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the
     mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863] it is customary to use
     an IANA-assigned value under transmission [RFC2578].  In the past
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.
 
-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, January 06, 2005 4:14 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O
ID assignmen ts: Assigning new RFCs under mib-2

Jean-Francois, 

André 

-----Original Message----- 
From: Jean-Francois Mule [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 06, 2005 3:54 PM 
To: Wijnen, Bert (Bert); [email-masked]; [email-masked] 
Cc: [email-masked]; Eduardo Cardona; [email-masked]; 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 

Bert, 

Jean-François 

> From: Wijnen, Bert (Bert) [mailto:[email-masked]
<mailto:[email-masked]> ] 

  You bet.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 6 Jan 2005 15:39:41 -0700

All right, back to good technical discussions.

Andre wrote:
> Jean-Francois, 
> What are the attributes that a MIB has to have, in your 
> opinion, for being added to the transmission OID under mib-2, 
> as opposed to only be added to mib-2? 

I believe some rough and vague guidelines can be found in the old MIB-II
(RFC 1213 section 3.12) - now transmission is normatively defined by
rfc2578 I think (SNMPv2-SMI). And that section 3.12 is the section I
considered before I sent the email yesterday. Here is an outdated dump
of the first assignments under the transmission branch:

Prefix: iso.org.dod.internet.mgmt.mib-2.transmission
(1.3.6.1.2.1.10)

Decimal   Name          Description
-------   ----          -----------
      5   x25           X.25                             [RFC1382]
      7   IEEE802.3     CSMACD--like Objects             [RFC1650]
      8   IEEE802.4     Token Bus-like Objects       
--                                               [RFC1230,RFC1239]
      9   dot5          Token Ring-like Objects          [RFC1743]
     15   FDDI          FDDI Objects               [RFC1285,JDC20]
     16   lapb          LAP B                            [RFC1381]
     18   ds1           T1 Carrier Objects               [RFC1406]
     19   e1            E1 Carrier Objects               [RFC1406]
     23   ppp           Point-to-Point Protocol          [RFC1471]
     30   ds3           DS3/E3 Interface Objects         [RFC1407]
     31   sip           SMDS Interface Objects           [RFC1694]
     32   frame-relay   Frame Relay Objects          [RFC1315,CXB]
     33   RS-232        RS-232 Objects                   [RFC1659]
     34   Parallel      Parallel Printer Objects         [RFC1660]
     35   arcnet        ARC network                      
     36   arcnet-plus   ARC network plus
     37   atm           ATM
     38   MIOX25        MIOX25                           [RFC1461]
     39   sonetMIB      SONET MIB                        [RFC1595]
     44   frnetservMIB  Frame Relay Service MIB for DCE  [RFC1596]
    ...
    127   docsIfMib     DOCSIS RFI MIB                   [RFC2670]

  The DOCSIS RFI mib clearly defined a new type of transmission media
(docsis mac layer which fits somewhat well within the above table). The
key question is: why should the QoS MIB stay under transmission 127? 
  One could argue that it defines interface extensions (the
docsQosPktClassTable relies on ifIndex being an ifType of 127) - hence
the justification. And this is fine by me: as my earlier post, I stated,
we could document those kinds of motivations in a document (Bert added
in an RFC3737-like document). 
  My earlier email asked the question: do *we* in IPCDN see any real
impact of changing the assignment of the IETF IPCDN *Internet-Draft*
from *unassigned_by_IANA_under_docsIfMib* to
*unassigned_by_IANA_under_mib-2*?  There, I could not find any good
reasons as I started in the email.

That said, I would raise the following considerations:
   - because of the mal practices of assigning DOCSIS MIBs under
docsIfMib (by CableLabs), I would argue that the best thing we can do is
break the current OID given the syntactic and semantic MIB changes; that
means either request that IANA assigns a random OID under docsIfMib that
does *not* match the one that has been allocated, or, request that IANA
assigned an OID under MIB-2;
     I think this is one of the points where I fundamentally disagree
with your argumentation. Since the MIB module has changed so much, the
best thing we can do to avoid OID namespace conflict and nightmares is
to make sure the IETF IPCDN RFC root is different from the one used (or
more correctly wrongfully used).
   - Mike Heard's MIB authoring guidelines
(http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guideline
s-03.txt) do state something about uniqueness of the OIDs, and this is a
key point to me.

Hence my earlier email:
  - if IANA were to assign this QoS MIB under a mib-2 root, I do not see
any real implications. It is more a MIB tree management issue that the
IETF ops area and mib doctors should worry about that I guess. I
personally do not like the multiplication of branches (I tend to like
more leaves rather than branches ;)
  - If IANA were to assign it under a docsIfMib root, there are no real
implications from an IETF point of view but there might be some tough
times in implementations and potential migrations --- if and when the
CableLabs requirements change which again is an argument that does not
belong here.

I hope this answers your question.

Let me add something you stated earlier which I strongly oppose:
You wrote:
> 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.
  No. Do you realize that the latest QoS MIB internet-drafts have
changed some object syntax? DSCP for e.g.
  Do you want an OID to map to 2 different, imcompatible object
definitions? Because that is what I think you end up with if you follow
what you say.

> 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.
  Dr. Richard Green, CableLabs CEO continue to say that CableLabs is not
a standard body, period. We work with other SDOs to get our
specifications to standardization level, like SCTE, ANSI, ETSI in
Europe. Dr. Richard Green is also the chairman of ITU-T SG9 where DOCSIS
is an international standard approved as an ITU-T recommendation.

 And this is just not the way we have worked within IETF to date: the
IETF IPCDN mibs contain sometimes drastic changes to our original
submission (see the use of the diffserv mib objects in the subs mgmt
mib, section 3.3 of
http://www.ipcdn.org/drafts/draft-ietf-ipcdn-subscriber-mib-16.txt).
Our goal is to get those MIBs to stable RFC status with all the changes
that were brought through this process.

Jean-Francois.

---

From: "Fred Oko" <[email-masked]>
Date: Fri, 7 Jan 2005 03:04:39 -0500

I would be interested seeing best practices that have been learned by readers of this reflector contributed to the 04 version of the noted draft-ietf-ops-mib-review-guidelines-03.txt. In particular, as an expansion upon the advise against using experimental for anything that would see field deployment (as is the case for all IPCDN drafts and the like) the advice of the possibly cleaner direction of using enterprise space (e.g. CableLabs enterprise clabProj* of noted path being taken by IPCDN) with notes for the possible necessities of re-rooting.

4.3.  Naming Hierarchy
   Experience has shown that it is impractical to move objects from one
   subtree to another once those objects have seen large-scale use in an
   operational environment.  Hence any object that is targeted for
   deployment in an operational environment MUST NOT be registered under
   the experimental subtree, irrespective of the standardization status
   of that object.  The experimental subtree should be used only for
   objects that are intended for limited experimental deployment.  Such
   objects typically are defined in Experimental RFCs.

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Thursday, January 06, 2005 4:48 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Fred Oko
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
 
Here is what the current MIB guidelines (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt <http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt> , section 4.5)have to say:

-- Rich
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Thursday, January 06, 2005 4:14 PM
	To: [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
	Jean-Francois, 
	What are the attributes that a MIB has to have, in your opinion, for being added to the transmission OID under mib-2, as opposed to only be added to mib-2? I presented my opinion regarding this, which was that a MIB that would only be applicable to a certain type of interface would be better placed under the associated transmission type rather than being placed at the mib-2 level. I have not seen any justification for not doing this with the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts of the BPI+ MIB is requesting them under mib-2, which is not a sufficient justification in my opinion.
	André 
	-----Original Message----- 
	From: Jean-Francois Mule [mailto:[email-masked]] 
	Sent: Thursday, January 06, 2005 3:54 PM 
	To: Wijnen, Bert (Bert); [email-masked]; [email-masked] 
	 
	Bert, 
	 
	  You bet.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 7 Jan 2005 18:09:01 -0500

>I would be interested seeing best practices that have been learned by
readers of this reflector contributed to the 04 version of the noted
draft-ietf-ops-mib-review-guidelines-03.txt.
 
OK, if you would like to make comments on these MIB guidelines, you should
bring those comments to the proper forum in the IETF. The draft itself does
point out the best forum for these comments:
 
   Comments on this memo should be submitted to the
   <[email-masked]> mailing list.  To subscribe to this mailing
   list send an e-mail message to <[email-masked]> with
   the word "subscribe" in the message body.
 
-- Rich
-----Original Message-----
From: Fred Oko [mailto:[email-masked]] 
Sent: Friday, January 07, 2005 3:05 AM
To: Woundy, Richard; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O
ID assignmen ts: Assigning new RFCs under mib-2

I would be interested seeing best practices that have been learned by
readers of this reflector contributed to the 04 version of the noted
draft-ietf-ops-mib-review-guidelines-03.txt. In particular, as an expansion
upon the advise against using experimental for anything that would see field
deployment (as is the case for all IPCDN drafts and the like) the advice of
the possibly cleaner direction of using enterprise space (e.g. CableLabs
enterprise clabProj* of noted path being taken by IPCDN) with notes for the
possible necessities of re-rooting.

4.3.  Naming Hierarchy

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Thursday, January 06, 2005 4:48 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Fred Oko
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O
ID assignmen ts: Assigning new RFCs under mib-2

 
-- Rich
-----Original Message----- 
 
Bert, 
 
  You bet.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 10 Jan 2005 18:11:11 +0100

Let me point out that the author is (right now as we speak) working on a revision
fo draft-ietf-ops-mib-review-guidelines-03.txt., so now is a really good time to comment!
 
Bert
-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Saturday, January 08, 2005 00:09
To: 'Fred Oko'; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2

>I would be interested seeing best practices that have been learned by readers of this reflector contributed to the 04 version of the noted draft-ietf-ops-mib-review-guidelines-03.txt.
 
OK, if you would like to make comments on these MIB guidelines, you should bring those comments to the proper forum in the IETF. The draft itself does point out the best forum for these comments:

-- Rich
-----Original Message-----
From: Fred Oko [mailto:[email-masked]] 
Sent: Friday, January 07, 2005 3:05 AM
To: Woundy, Richard; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2

4.3.  Naming Hierarchy

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]] 
Sent: Thursday, January 06, 2005 4:48 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Fred Oko
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
 
Here is what the current MIB guidelines (  <http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt> http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt, section 4.5)have to say:

-- Rich
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 06, 2005 4:14 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
Jean-Francois, 
-----Original Message----- 
From: Jean-Francois Mule [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, January 06, 2005 3:54 PM 
To: Wijnen, Bert (Bert); [email-masked]; [email-masked] 
Cc: [email-masked]; Eduardo Cardona; [email-masked]; DOCSIS OSS 
Majordomo List 
 
Bert, 
 
  You bet.

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 12 Jan 2005 19:17:52 -0500

IPCDN folks,

After review of the WG input and comments on the email thread started on
1/5/2005 on the IPCDN mailing list, the WG chairs have come to the decision
to request a change of the OID MIB root for the IPCDN QoS MIB Internet-Draft
from ..mib-2(1) transmission(10) docsIfMib(127) to ..mib-2(1). If you have
any further comments on this matter, or wish to object to the decision,
please feel free to contact one or both of the WG chairs, or feel free to
escalate to our WG AD Bert Wijnen.

The proposed alternative was to keep the QoS MIB module under docsIfMIB, and
per the explicit request of the AD, to write an RFC3737-like document to
define IANA guidelines for registering MIB modules under the docsIfMIB
branch. 

The WG chairs have reviewed all the comments expressed publicly to the list.
We would like to add the following notes:

- Some of the technical comments made in favor of maintaining the OID root
do not take into account the fact that the IETF IPCDN Internet-Drafts have
evolved and that the MIB modules have changed drastically in the many
revisions, from object syntax changes to table entry OID renumbering, to
object deletions (not obsolescence), etc.

- The backward compatibility issues raised between the final IETF IDs to be
RFC'ed and the original IPCDN submissions are not caused strictly by the
IETF. The IETF supports backward compatibility between published versions of
RFCs (e.g. between RFC2669 and the to-be-published version of Cable Modem
Device MIBv2, RFC2669bis; between RFC2670 and the to-be-published version of
RF MIBv2, RFC2670bis), per the IETF documented guidelines of the procedures
to follow when updating IETF RFC MIB modules.

The IETF does NOT support backward compatibility between Internet-Draft
versions of MIBs, or between an Internet-Draft version and an RFC version,
because an Internet-Draft is not a stable reference. Note the following
relevant statement that is required to be included in every Internet-Draft
submitted to the IETF:

>Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them
other than as "work in progress."

With respect to the rest of the IPCDN Internet-Drafts (i.e. other than the
updates to RFC2669 and RFC2670), the backward compatibility problem lies in
the fact that some Internet-Drafts have been implemented in products and the
associated MIB module implementations rooted under an IANA-controlled MIB
tree, wrongfully assigned outside the IANA jurisdiction.

The consequences of this backward compatibility problem must be addressed by
specific CableLabs product requirements in a CableLabs specification forum
-- not in the IETF.

- The change of a MIB module OID root (and MIB module identity names) was
previously done for the IPCDN BPI+ MIB in February 2003. This is documented
in the IPCDN meeting notes, see
<http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/index.html
<http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/index.html> >. The MIB
module OID root for the Subscriber Management MIB was changed in November
2002; see <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00333.html
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00333.html> > and
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00367.html
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00367.html> >.

- Maintaining the QoS MIB and other MIB modules under docsIfMib may cause
some serious interoperability problems due to the illegal (i.e. non-IETF
sanctioned) OID assignments and implementations mentioned above.

- Writing an RFC3737-like document would delay the publication of the QoS
MIB which we do not feel justified based on the WG input and comments.

--- Rich Woundy and Jean-Francois Mule
    IPCDN co-chairs