Subject: [ipcdn] RE: Working group last-calls

From: "Pollak, Lucy" <[email-masked]>
Date: Mon, 19 Nov 2001 18:38:41 +0200

Please, explain what was a reason to return removed objects as obsolete. The
next MIB comment does not contain any explanation:
	Added objects that were removed from earlier revisions of the mib,
as obsolete.           
All the next objects were removed even from version 3. Currently certified
modems and modems will be certified in CW20 use version 4, which does not
contain these objects:
-- Remove docsQosServiceFlowProvisionedParamSetIndex 
--    {docsQosServiceFlowEntry 2} with revision -03
-- Remove docsQosServiceFlowAdmittedParamSetIndex 
--    {docsQosServiceFlowEntry 3} with revision -03
-- Remove docsQosServiceFlowActiveParamSetIndex 
--    {docsQosServiceFlowEntry 4} with revision -03
-- Moved docsQosServiceFlow'ActiveTimeout, 'AdmittedTimeout,
-- 'SchedulingType, 'RequestPolicy, 'TosAndMask, and 'TosOrMask
-- back to docsQosParamSetTable with QOS-MIB-04.
-- docsQosServiceClassParamSetIndex { docsQosServiceClassEntry 2 }
--    was removed in revision -03
-- Removed dosQosPHSClassifierIndex {docsQosPHSEntry 6}
--   in revision -03.
I afraid that returned objects will cause a large amount of problems in
future OSS tests, espesially with automatic tools such as IWL and
SimpleTester. The OSS spec requires some specific management for obsolete
objects:
	Obsolete object. It is optional. A vendor can choose to implement or
not implement the object. If a vendor
	chooses to implement the object, the object MUST be implemented
correctly according to the MIB
	definition. If a vendor chooses not to implement the object, an
agent MUST NOT instantiated such object
	and MUST respond with the appropriate error/exception condition.
(e.g., no such object for SNMPv2c)
Part of the objects are table index and it will be critical for SNMP testing
(Table behavior is dependent from index number.) Thus, we will observe
backward compatibility problems with devices, which uses v4 MIB. The future
applications will be inconsistent in this issue. 
What was a reason to return them?
Regards.
Lucy

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 6:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Working group last-calls

Folks,

(I am copying the docsis-oss list as a courtesy, to invite the folks in the 
DOCSIS world to contribute and comment.)

Thanks to the authors and with support from CableLabs, there are three 
internet-drafts that I believe are ready for working group last call:

Application of the IGMP MIB to DOCSIS, 
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt>
Subscriber Management MIB, 
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt>
DOCSIS QoS MIB, 
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt>

Note: There are some minor editorial issues with the QoS MIB which I will 
post in a separate email message, but otherwise it is ready for review.

The last call for the IGMP/DOCSIS MIB is scheduled to end on November 21. 
Please send comments (positive or negative) to the [email-masked] mailing 
list reflector.

I propose that the last calls for the Subscriber Management and DOCSIS QoS 
MIBs start immediately, and end on December 10 -- the current date of the 
IPCDN face-to-face meeting at the IETF. This allows ample WG review time 
for two fairly hefty drafts, and works around a fairly significant holiday 
in the United States (Thanksgiving). It also allows us to conclude the 
review at a convenient venue for the working group. Please send email 
comments (positive or negative) to the [email-masked] mailing list
reflector.

-- Rich

P.S. We may have more internet-drafts ready for WG last-call by the 
internet-draft submission deadline. Stay tuned.

At 06:30 PM 11/7/2001 -0500, Rich Woundy wrote:
>Folks,
>
>There are a number of current activities pertaining to the IPCDN working 
>group:
>
>1. There are folks working on new working group internet-drafts for the 
>following DOCSIS projects:
>- the DOCSIS RF MIB (i.e. adding support for DOCSIS 2.0),
>- the QoS MIB (i.e. adding IPv6 syntax support),
>- the event notification MIB (changes TBD),
>- the BPI+ MIB (changes TBD), and
>- the subscriber management MIB (changes TBD).
>No promises that all of these drafts will be ready by the 11/21 IETF 
>deadline, but it seems very likely. Additional draft updates are also
possible.
>
>2. I would like to announce the beginning of the working group last call 
>for "Application of the IGMP MIB", 
><http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt>. 
>The last call will end on November 21st.
>
>3. The working group is going to meet at the 52nd IETF meeting in Salt 
>Lake City, <http://www.ietf.org/meetings/IETF-52.html>. Tentatively, our 
>meeting is scheduled for Monday afternoon, December 10th.
>
>Beware of booking based on this early information. Note that the IPCDN 
>scheduled slot for the last IETF (London) was changed after the 
>announcement to the list, so a number of folks missed the working group 
>session.
>
>-- Rich
>
>
>_______________________________________________
>IPCDN mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Pollak, Lucy" <[email-masked]>
Date: Mon, 19 Nov 2001 18:38:41 +0200

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 6:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: Working group last-calls

Folks,

-- Rich

possible.

---

From: Murwin William-LWM008 <[email-masked]>
Date: Mon, 19 Nov 2001 16:11:01 -0500

Comments In Line.
I hope this clears up the reason why these objects were re-added as obsolete. If not please feel free to contact me again. 
 
Thanks,
Will Murwin

 -----Original Message-----
From: Pollak, Lucy [mailto:[email-masked]]
Sent: Monday, November 19, 2001 11:39 AM
To: 'Rich Woundy'; [email-masked]; William Murwin
Cc: [email-masked]
Subject: RE: Working group last-calls

Please, explain what was a reason to return removed objects as obsolete. The next MIB comment does not contain any explanation:
[In-line Comment>] When developing MIBs, when objects are no longer required or not needed they should not simply be deleted.  They should be made obsolete, in order to be backwards compatible with older drafts, and to avoid OID reuse in future revisions. For these deleted objects the decision was made to re-add the objects with the STATUS of obsolete. It was not correct procedure for us to remove these objects and leave comments in their place, as this is counter to the prime directive for MIB design. Because we did not obsolete these object nothing was stopping someone from writing a new version of the QoS MIB and using the deleted object's OIDs for newer objects. A new MIB then would be then in conflict with past drafts of the QoS MIB.

        Added objects that were removed from earlier revisions of the mib, as obsolete.           
All the next objects were removed even from version 3. Currently certified modems and modems will be certified in CW20 use version 4, which does not contain these objects:
[In-line Comment>] I agree with you that certified modems and CW20 products will contain version 4 of the QoS MIB. However, there is no backwards compatiblity problems when using draft 06 with agents that implement draft 04, I'll explain myself in one second. The whole reason this was done was to avoid  backwards compatiblity problems.

A good SNMP Manager should not use obsolete objects, so the obsolete objects would not be queried from the SNMP Manager. Thus an agent that implemented QoS MIB v4 and used v6 in the Manager, would see no problems from both the Manager's and Agent's perceptive. It would be as if  version 4 was being used within the SNMP Manager.

However this is the real world and I know of SNMP Managers that do not behave in this manner. A SNMP Manager that queries obsolete objects on a snmp walk or get-next would receive the next instance of an object that was implemented on the agent. A SNMP Manager that sent a snmp get or set on a obsolete object would receive NoSuchName(2) error, from a agent that did not implement this object. All of this is the correct behavior for the agent. This would be the same behavior if both the agent and the manager implemented version 6 of the QoS MIB, and the manager queried obsolete objects. 

If the agent implemented version 6 and the Manager used version 4, the agent SHOULD NOT implement obsolete objects, and acceptable behavior would be observed for both the Agent and the Manager for these obsolete objects. 

No backward compatible problems are raised by using obsolete within version 6 of the QoS MIB. And future OID re-use issues are avoided by using obsolete within version 6 of the QoS MIB.

I afraid that returned objects will cause a large amount of problems in future OSS tests, espesially with automatic tools such as IWL and SimpleTester. The OSS spec requires some specific management for obsolete objects:
[In-line Comment>] First of all the latest definition of Obsolete within the OSSI Specification is a little different:

            Ob - Obsolete - It is optional. Though in SNMP convention, obsolete objects should not be implemented, DOCSIS 1.1 OSSI lets vendors choose whether or not to support the obsolete  object. That is, a vendor can choose to implement or not implement the obsolete object. If a vendor chooses to implement the object, the object MUST be implemented correctly according to the MIB definition. If a vendor chooses not to implement the object, SNMP agent MUST NOT instantiated such object and MUST respond with the appropriate error/exception condition. (e.g., no such object for SNMPv2c)

When defining the Access of these SNMP obsolete object within the Docsis 1.1 Spec, it will make more sense to define them with the access of N-Sup. This N-Sup access matches strict SNMP convention, of how these objects should be implemented. It should also be noted that the DOCSIS access is not the same as the SNMP access. DOCSIS adds their own restrictions to those already imposed by the MIBs requirements.

	Obsolete object. It is optional. A vendor can choose to implement or not implement the object. If a vendor 
chooses to implement the object, the object MUST be implemented correctly according to the MIB 
definition. If a vendor chooses not to implement the object, an agent MUST NOT instantiated such object 
and MUST respond with the appropriate error/exception condition. (e.g., no such object for SNMPv2c) 

Part of the objects are table index and it will be critical for SNMP testing (Table behavior is dependent from index number.) Thus, we will observe backward compatibility problems with devices, which uses v4 MIB. The future applications will be inconsistent in this issue. 
[In-line Comment>] None of the objects from above where indexes to tables in past versions of the MIB. I agree that if these objects had been indexes in the past there would be serious problem by re-adding them as obsolete. Hovewever, this is not the case when it comes to these objects.

What was a reason to return them? 
[In-line Comment>]  Obsolete is used to provide interoperability with past version of MIBs. No definitions may ever be removed from a published MIB module and the same is true for a work-in-progress, because the MIB updates are not allowed to change the semantics of previously defined objects. 
Regards. 
Lucy 

-----Original Message----- 
From: Rich Woundy [  <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Thursday, November 15, 2001 6:50 PM 
To: [email-masked] 
Cc: [email-masked] 
Subject: Working group last-calls 

Folks, 

Application of the IGMP MIB to DOCSIS, 
< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt> > 
Subscriber Management MIB, 
< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt> > 
DOCSIS QoS MIB, 
< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt> > 

comments (positive or negative) to the [email-masked] mailing list reflector. 

-- Rich 

At 06:30 PM 11/7/2001 -0500, Rich Woundy wrote: 
>deadline, but it seems very likely. Additional draft updates are also possible. 
> 
>< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt> >. 
>Lake City, < http://www.ietf.org/meetings/IETF-52.html <http://www.ietf.org/meetings/IETF-52.html> >. Tentatively, our 
> http://www1.ietf.org/mailman/listinfo/ipcdn <http://www1.ietf.org/mailman/listinfo/ipcdn>

---

From: Murwin William-LWM008 <[email-masked]>
Date: Mon, 19 Nov 2001 16:11:01 -0500

Comments In Line.
 
Thanks,
Will Murwin

-----Original Message----- 
From: Rich Woundy [  <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Thursday, November 15, 2001 6:50 PM 
To: [email-masked] 
Cc: [email-masked] 
Subject: Working group last-calls 

Folks, 

-- Rich

---

From: Rich Woundy <[email-masked]>
Date: Mon, 19 Nov 2001 19:57:16 -0500

Lucy,

What William says is correct, and I stand by his approach.

Here's what one of the IETF "MIB doctors" said in a similar circumstance:

>    I think it might be better to keep the 2 deleted objects and make
>    their status "obsolete". Add to the DESCRIPTION clause why they
>    were obsoleted. That way, no-body will ever re-allocate those OIDs

We need approval from an IETF MIB doctor to get the MIB published as an RFC.

-- Rich

At 04:11 PM 11/19/2001 -0500, Murwin William-LWM008 wrote:
>Comments In Line.
>I hope this clears up the reason why these objects were re-added as 
>obsolete. If not please feel free to contact me again.
>
>Thanks,
>Will Murwin
>
>Please, explain what was a reason to return removed objects as obsolete. 
>The next MIB comment does not contain any explanation:
>[In-line Comment>] When developing MIBs, when objects are no longer 
>required or not needed they should not simply be deleted.  They should be 
>made obsolete, in order to be backwards compatible with older drafts, and 
>to avoid OID reuse in future revisions. For these deleted objects the 
>decision was made to re-add the objects with the STATUS of obsolete. It 
>was not correct procedure for us to remove these objects and leave 
>comments in their place, as this is counter to the prime directive for MIB 
>design. Because we did not obsolete these object nothing was stopping 
>someone from writing a new version of the QoS MIB and using the deleted 
>object's OIDs for newer objects. A new MIB then would be then in conflict 
>with past drafts of the QoS MIB.
>[In-line Comment>] I agree with you that certified modems and CW20 
>products will contain version 4 of the QoS MIB. However, there is no 
>backwards compatiblity problems when using draft 06 with agents that 
>implement draft 04, I'll explain myself in one second. The whole reason 
>this was done was to avoid  backwards compatiblity problems.
>A good SNMP Manager should not use obsolete objects, so the obsolete 
>objects would not be queried from the SNMP Manager. Thus an agent that 
>implemented QoS MIB v4 and used v6 in the Manager, would see no problems 
>from both the Manager's and Agent's perceptive. It would be as if  version 
>4 was being used within the SNMP Manager.
>However this is the real world and I know of SNMP Managers that do not 
>behave in this manner. A SNMP Manager that queries obsolete objects on a 
>snmp walk or get-next would receive the next instance of an object that 
>was implemented on the agent. A SNMP Manager that sent a snmp get or set 
>on a obsolete object would receive NoSuchName(2) error, from a agent that 
>did not implement this object. All of this is the correct behavior for the 
>agent. This would be the same behavior if both the agent and the manager 
>implemented version 6 of the QoS MIB, and the manager queried obsolete 
>objects.
>If the agent implemented version 6 and the Manager used version 4, the 
>agent SHOULD NOT implement obsolete objects, and acceptable behavior would 
>be observed for both the Agent and the Manager for these obsolete objects.
>No backward compatible problems are raised by using obsolete within 
>version 6 of the QoS MIB. And future OID re-use issues are avoided by 
>using obsolete within version 6 of the QoS MIB.
>[In-line Comment>] First of all the latest definition of Obsolete within 
>the OSSI Specification is a little different:
>             Ob - Obsolete It is optional. Though in SNMP convention, 
> obsolete objects should not be implemented, DOCSIS 1.1 OSSI lets vendors 
> choose whether or not to support the obsolete  object. That is, a vendor 
> can choose to implement or not implement the obsolete object. If a vendor 
> chooses to implement the object, the object MUST be implemented correctly 
> according to the MIB definition. If a vendor chooses not to implement the 
> object, SNMP agent MUST NOT instantiated such object and MUST respond 
> with the appropriate error/exception condition. (e.g., no such object for 
> SNMPv2c)
>When defining the Access of these SNMP obsolete object within the Docsis 
>1.1 Spec, it will make more sense to define them with the access of N-Sup. 
>This N-Sup access matches strict SNMP convention, of how these objects 
>should be implemented. It should also be noted that the DOCSIS access is 
>not the same as the SNMP access. DOCSIS adds their own restrictions to 
>those already imposed by the MIBs requirements.
>Obsolete object. It is optional. A vendor can choose to implement or not 
>implement the object. If a vendor  chooses to implement the object, the 
>object MUST be implemented correctly according to the MIB  definition. If 
>a vendor chooses not to implement the object, an agent MUST NOT 
>instantiated such object  and MUST respond with the appropriate 
>error/exception condition. (e.g., no such object for SNMPv2c)
>Part of the objects are table index and it will be critical for SNMP 
>testing (Table behavior is dependent from index number.) Thus, we will 
>observe backward compatibility problems with devices, which uses v4 MIB. 
>The future applications will be inconsistent in this issue.
>[In-line Comment>] None of the objects from above where indexes to tables 
>in past versions of the MIB. I agree that if these objects had been 
>indexes in the past there would be serious problem by re-adding them as 
>obsolete. Hovewever, this is not the case when it comes to these objects.
>
>[In-line Comment>]  Obsolete is used to provide interoperability with past 
>version of MIBs. No definitions may ever be removed from a published MIB 
>module and the same is true for a work-in-progress, because the MIB 
>updates are not allowed to change the semantics of previously defined objects.
>Regards.
>Lucy
>
>From: Rich Woundy [<mailto:[email-masked]>mailto:[email-masked]]
><<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt> 
>
><<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt> 
>
>DOCSIS QoS MIB,
><<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt> 
>
>
> ><<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt>ht 
> tp://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt>.
> >Lake City, 
> <<http://www.ietf.org/meetings/IETF-52.html>http://www.ietf.org/meetings/IETF-52.html>. 
> Tentatively, our
> ><http://www1.ietf.org/mailman/listinfo/ipcdn>http://www1.ietf.org/mailman 
> /listinfo/ipcdn

---

From: Rich Woundy <[email-masked]>
Date: Mon, 19 Nov 2001 19:57:16 -0500

Lucy,

-- Rich

---

From: "Pollak, Lucy" <[email-masked]>
Date: Tue, 20 Nov 2001 16:04:14 +0200

Will.
1. I agree with you that to obsolete the objects is the correct way to
remove them from the MIB. But this correct way was violated for QOS mib. Two
versions 3 and 4 do not have all these objects at all. These two versions
are more popular then v1 and 2, which never were implemented. 
2. Most of existed browsers do not interpret obsoleted object correctly.
Obviously, they do not know about OSSI spec requirement to support it in two
different ways. The text I referenced is from section 3. You referenced to
appendix A. Both texts from the spec  permit 2 implementation. If you will
add objects into mib as obsolete and into OSSI spec as N-Sup, it will solve
part of the problems, but not wit all the test suite. 
I guess, if we did the remove mistake in the past, we need to stay with it.
It will cause to the less problems then attempts to correct it so late.
Regards.
Lucy

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email-masked]]
Sent: Monday, November 19, 2001 11:11 PM
To: Pollak, Lucy; 'Rich Woundy'; [email-masked]; Murwin William-LWM008
Cc: [email-masked]
Subject: RE: Working group last-calls

Comments In Line.
 
Thanks,
Will Murwin

 -----Original Message-----
From: Pollak, Lucy [mailto:[email-masked]]
Sent: Monday, November 19, 2001 11:39 AM
To: 'Rich Woundy'; [email-masked]; William Murwin
Cc: [email-masked]
Subject: RE: Working group last-calls

Please, explain what was a reason to return removed objects as obsolete. The
next MIB comment does not contain any explanation:
[In-line Comment>] When developing MIBs, when objects are no longer required
or not needed they should not simply be deleted.  They should be made
obsolete, in order to be backwards compatible with older drafts, and to
avoid OID reuse in future revisions. For these deleted objects the decision
was made to re-add the objects with the STATUS of obsolete. It was not
correct procedure for us to remove these objects and leave comments in their
place, as this is counter to the prime directive for MIB design. Because we
did not obsolete these object nothing was stopping someone from writing a
new version of the QoS MIB and using the deleted object's OIDs for newer
objects. A new MIB then would be then in conflict with past drafts of the
QoS MIB.

        Added objects that were removed from earlier revisions of the mib,
as obsolete.           
All the next objects were removed even from version 3. Currently certified
modems and modems will be certified in CW20 use version 4, which does not
contain these objects:
[In-line Comment>] I agree with you that certified modems and CW20 products
will contain version 4 of the QoS MIB. However, there is no backwards
compatiblity problems when using draft 06 with agents that implement draft
04, I'll explain myself in one second. The whole reason this was done was to
avoid  backwards compatiblity problems.

A good SNMP Manager should not use obsolete objects, so the obsolete objects
would not be queried from the SNMP Manager. Thus an agent that implemented
QoS MIB v4 and used v6 in the Manager, would see no problems from both the
Manager's and Agent's perceptive. It would be as if  version 4 was being
used within the SNMP Manager.

However this is the real world and I know of SNMP Managers that do not
behave in this manner. A SNMP Manager that queries obsolete objects on a
snmp walk or get-next would receive the next instance of an object that was
implemented on the agent. A SNMP Manager that sent a snmp get or set on a
obsolete object would receive NoSuchName(2) error, from a agent that did not
implement this object. All of this is the correct behavior for the agent.
This would be the same behavior if both the agent and the manager
implemented version 6 of the QoS MIB, and the manager queried obsolete
objects. 

If the agent implemented version 6 and the Manager used version 4, the agent
SHOULD NOT implement obsolete objects, and acceptable behavior would be
observed for both the Agent and the Manager for these obsolete objects. 

No backward compatible problems are raised by using obsolete within version
6 of the QoS MIB. And future OID re-use issues are avoided by using obsolete
within version 6 of the QoS MIB.

[In-line Comment>] First of all the latest definition of Obsolete within the
OSSI Specification is a little different:

            Ob - Obsolete - It is optional. Though in SNMP convention,
obsolete objects should not be implemented, DOCSIS 1.1 OSSI lets vendors
choose whether or not to support the obsolete  object. That is, a vendor can
choose to implement or not implement the obsolete object. If a vendor
chooses to implement the object, the object MUST be implemented correctly
according to the MIB definition. If a vendor chooses not to implement the
object, SNMP agent MUST NOT instantiated such object and MUST respond with
the appropriate error/exception condition. (e.g., no such object for
SNMPv2c)

When defining the Access of these SNMP obsolete object within the Docsis 1.1
Spec, it will make more sense to define them with the access of N-Sup. This
N-Sup access matches strict SNMP convention, of how these objects should be
implemented. It should also be noted that the DOCSIS access is not the same
as the SNMP access. DOCSIS adds their own restrictions to those already
imposed by the MIBs requirements.

	Obsolete object. It is optional. A vendor can choose to implement or
not implement the object. If a vendor 
chooses to implement the object, the object MUST be implemented correctly
according to the MIB 
definition. If a vendor chooses not to implement the object, an agent MUST
NOT instantiated such object 
and MUST respond with the appropriate error/exception condition. (e.g., no
such object for SNMPv2c) 

Part of the objects are table index and it will be critical for SNMP testing
(Table behavior is dependent from index number.) Thus, we will observe
backward compatibility problems with devices, which uses v4 MIB. The future
applications will be inconsistent in this issue. 
[In-line Comment>] None of the objects from above where indexes to tables in
past versions of the MIB. I agree that if these objects had been indexes in
the past there would be serious problem by re-adding them as obsolete.
Hovewever, this is not the case when it comes to these objects.

What was a reason to return them? 
[In-line Comment>]  Obsolete is used to provide interoperability with past
version of MIBs. No definitions may ever be removed from a published MIB
module and the same is true for a work-in-progress, because the MIB updates
are not allowed to change the semantics of previously defined objects. 
Regards. 
Lucy 

-----Original Message----- 
From: Rich Woundy [  <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Thursday, November 15, 2001 6:50 PM 
To: [email-masked] 
Cc: [email-masked] 
Subject: Working group last-calls 

Folks, 

Application of the IGMP MIB to DOCSIS, 
< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt> > 
Subscriber Management MIB, 
< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt>
DOCSIS QoS MIB, 
< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt> > 

-- Rich 

possible. 
>< http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt> >. 
>Lake City, < http://www.ietf.org/meetings/IETF-52.html
<http://www.ietf.org/meetings/IETF-52.html> >. Tentatively, our 
>announcement to the list, so a number of folks missed the working group 
<http://www1.ietf.org/mailman/listinfo/ipcdn>

---

From: "Pollak, Lucy" <[email-masked]>
Date: Tue, 20 Nov 2001 20:46:48 +0200

Rich.
Thank you very much for your explanation. I already agreed with this change
in the mail sent to Will. My objection was based on browser behavior and bad
testing experience with them. The preferable way is to work in accordance
with guidance. Let me explain also some redundant implementation effort
caused by this removing/returning process. From development point of view we
might to remain all these objects in our implementation, if they had been
obsoleted in v3 (obsolete objects may be implemented in accordance with
OSSI.) In this case we will pass also all the tests without any additional
failure. We did some efforts to remove all these objects and now with new
MIB version we will receive some additional testing failures, which should
be explained to testers and also documented. 
I guess, we need to avoid problems like this in the future.
Thanks.
Lucy 

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 8:08 PM
To: Pollak, Lucy; 'Murwin William-LWM008'; [email-masked]
Cc: [email-masked]
Subject: RE: Working group last-calls

Lucy,

RFC 2578 section 10 says:

"Also note that obsolete definitions must not be removed from MIB modules 
since their descriptors may still be referenced by other information 
modules, and the OBJECT IDENTIFIERs used to name them must never be 
re-assigned."

The problem is that the update from -02 to -03 did not follow this 
guidance, so now we are fixing the problem in -06.

I don't think the IETF is going to be sympathetic about interoperation with 
MIB browsers that do not follow the SNMP specs. In their mind, it's a lot 
better to get a browser that follows the standard, instead of corrupting 
the standard for broken tools.

I might point out that you could edit the obsolete objects out of -06 
before feeding the MIB into the broken browser to fix those sorts of 
problems. Here's a real example: every time I compile a MIB for the IPCDN 
working group, I have to convert all Unsigned32's to Gauge32's, and all 
BITS to BIT STRINGs, because my MIB compiler is utterly ignorant of these 
syntaxes although it is otherwise very powerful and correct. I wouldn't 
presume to change the syntax of MIB objects in published internet drafts to 
older constructs just to make my compiler work without complaints...

-- Rich

At 04:04 PM 11/20/2001 +0200, Pollak, Lucy wrote:
>remove them from the MIB. But this correct way was violated for QOS mib. 
>Two versions 3 and 4 do not have all these objects at all. These two 
>versions are more popular then v1 and 2, which never were implemented.
>Obviously, they do not know about OSSI spec requirement to support it in 
>two different ways. The text I referenced is from section 3. You 
>referenced to appendix A. Both texts from the spec  permit 2 
>implementation. If you will add objects into mib as obsolete and into OSSI 
>spec as N-Sup, it will solve part of the problems, but not wit all the 
>test suite.
>I guess, if we did the remove mistake in the past, we need to stay with 
>it. It will cause to the less problems then attempts to correct it so late.
>Regards.
>Lucy
>
><<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt>http
://www.ietf.org/internet-drafts/draft-ietf-ipcdn-igmp-mib-02.txt> 
><<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.tx
t>http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-04.txt
> 
>
>DOCSIS QoS MIB,
><<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt>http:
//www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-06.txt> 
reflector.

> >3. The working group is going to meet at the 52nd IETF meeting in Salt
<<http://www.ietf.org/meetings/IETF-52.html>http://www.ietf.org/meetings/IET
F-52.html>.

---

From: "Pollak, Lucy" <[email-masked]>
Date: Tue, 20 Nov 2001 20:46:48 +0200

Rich.

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 8:08 PM
To: Pollak, Lucy; 'Murwin William-LWM008'; [email-masked]
Cc: [email-masked]
Subject: RE: Working group last-calls

Lucy,

-- Rich

reflector.