Subject: [MIB-DOCTORS] Help with possible object deprecation

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Dec 2010 11:35:01 -0000

Dear MIB doctors,

Help!

The multicast routing protocol, PIM-SM (RFC 4601), has an algorithm to choose a
rendezvous point from information learned by the protocol. This algorithm has
been updated to be more sophisticated in draft-ietf-pim-group-rp-mapping (which
updates RFC 4601).

PIM-STD-MIB in RFC 5060 defines objects for use in the RFC 4601 algorithm
(pimGroupMappingPrecedence and pimStaticRPPrecedence). These objects are no
longer required once the algorithm in draft-ietf-pim-group-rp-mapping is
implemented.

The question is about deprecation of these objects.

Note that RFC 4601 implementations will continue to exist.

Options appear to be:

1. Issue an update to RFC 5060 in step with draft-ietf-pim-group-rp-mapping.
The update would deprecate the two objects.
It is my understanding that "updates" to MIB modules are not preferred. It is
seen as better to "obsolete" with a new module version number.

2.. Issue an update to RFC 5060 in step with draft-ietf-pim-group-rp-mapping.
The update would add text to the description clauses of the two objects.

3. Issue an Erratum for RFC 5060 with text that notes the change in usage for
the two objects.

4. Include text in draft-ietf-pim-group-rp-mapping to explain the changed use
for the two objects.
This is the approach currently employed by the authors (although they use the
word "deprecate" which may be too strong).

Any help gratefully received.
Thanks,
Adrian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 13:49:38 +0100

On Mon, Dec 06, 2010 at 11:35:01AM +0000, Adrian Farrel wrote:

[...]
 
> seen as better to "obsolete" with a new module version number.

I do not know why you believe that updates to MIB modules are not
preferred. There is also no such thing as a "module version number".
The only argument against updates is that relatively minor updates to
long and complex MIB modules are costly in terms of the reviewing and
the document processing required.

> word "deprecate" which may be too strong).

The rule is simple: You can't ever change semantics of published
object definitions. If the existing semantics of the objects do not
work anymore, you have to define new objects that carry the new
semantics. In other words, assuming that semantics are changed, none
of 2.-4. really work.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 6 Dec 2010 15:26:08 +0100

Hi Adrian,

Actually the update of the MIB module (option #1) seems the only
feasible option from your list. Options #2, #3, and #4 seem to try to
keep using the MIB module in 5060 while making semantic changes via
DESCRIPTION clause change, errata, or text in another document - all
these are not possible as they can create incompatibilities between
various implementations of the same MIB module. 

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Monday, December 06, 2010 1:35 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [MIB-DOCTORS] Help with possible object deprecation
> 
> Dear MIB doctors,
> 
> Help!
> 
> The multicast routing protocol, PIM-SM (RFC 4601), has an 
> algorithm to choose a rendezvous point from information 
> learned by the protocol. This algorithm has been updated to 
> be more sophisticated in draft-ietf-pim-group-rp-mapping 
> (which updates RFC 4601).
> 
> PIM-STD-MIB in RFC 5060 defines objects for use in the RFC 
> 4601 algorithm (pimGroupMappingPrecedence and 
> pimStaticRPPrecedence). These objects are no longer required 
> once the algorithm in draft-ietf-pim-group-rp-mapping is implemented.
> 
> It is my understanding that "updates" to MIB modules are not 
> preferred. It is seen as better to "obsolete" with a new 
> module version number.
> 
> 3. Issue an Erratum for RFC 5060 with text that notes the 
> change in usage for the two objects.
> 
> 4. Include text in draft-ietf-pim-group-rp-mapping to explain 
> the changed use for the two objects.
> This is the approach currently employed by the authors 
> (although they use the word "deprecate" which may be too strong).
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Dec 2010 14:45:17 -0000

Thanks Dan and Juergen,

I remain convinced that an "updates" is not what we want.

I should point out that it was MIB Doctors who convinced me of this when I tried
to do an update to a MIB module in the past. I was told that it would not be
clever to have a MIB module normatively defined across two documents. What was
needed was an "obsoletes". In other words, the whole MIB module had to be
reproduced in a new document with the necessary fixes. This sounds to me to be

> the document processing required.

I will talk to the authors about whether this is really a change to the semantic
of the object.

Cheers,
Adrian

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: 06 December 2010 14:26
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [MIB-DOCTORS] Help with possible object deprecation
> 
> Hi Adrian,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 6 Dec 2010 15:53:17 +0100

We probably need to discuss the terminology - what do you mean by an
"update" and what you mean by "obsolete". How did you think that you can
change the STATUS of two objects in a MIB module (which I understand is
what needs to be done in this case) without defining a new version of
the MIB module.

(I guess that that case in the past you remember may have only added MIB
objects, but it's a guess)

Dan

> Sent: Monday, December 06, 2010 4:45 PM
> To: [email-masked]
> Subject: Re: [MIB-DOCTORS] Help with possible object deprecation
> 
> Thanks Dan and Juergen,
> 
> I should point out that it was MIB Doctors who convinced me 
> of this when I tried to do an update to a MIB module in the 
> past. I was told that it would not be clever to have a MIB 
> module normatively defined across two documents. What was 
> needed was an "obsoletes". In other words, the whole MIB 
> module had to be reproduced in a new document with the 
> necessary fixes. This sounds to me to be what Juergen was 
> implying in his email when he said:
> 
> I will talk to the authors about whether this is really a 
> change to the semantic of the object.
> 
> Cheers,
> Adrian
> 
> algorithm 
> > > to choose a rendezvous point from information learned by the 
> > > protocol. This algorithm has been updated to be more 
> sophisticated 
> > > in draft-ietf-pim-group-rp-mapping (which updates RFC 4601).
> > >
> > > pimStaticRPPrecedence). These objects are no longer required once 
> > > the algorithm in draft-ietf-pim-group-rp-mapping is implemented.
> > >
> > > preferred. It is seen as better to "obsolete" with a new module 
> > > version number.
> > >
> > > 4. Include text in draft-ietf-pim-group-rp-mapping to explain the 
> > > changed use for the two objects.
> > > This is the approach currently employed by the authors (although 
> > > they use the word "deprecate" which may be too strong).
> > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Dec 2010 16:40:41 +0100

On Mon, Dec 06, 2010 at 02:45:17PM +0000, Adrian Farrel wrote:
 
> I should point out that it was MIB Doctors who convinced me of this
> when I tried to do an update to a MIB module in the past. I was told
> that it would not be clever to have a MIB module normatively defined
> across two documents. What was needed was an "obsoletes". In other
> words, the whole MIB module had to be reproduced in a new document
> with the necessary fixes.

Now I see that we talked past each other. You seem to use update /
obsolete as used on the RFC header while I was thinking in SMIv2
terms. So in your terminology, you indeed can't update a MIB module by
just publishing a delta - you have to publishe the whole revised MIB
module and this new document will obsolete the previous RFC.

/js

---

From: "Andy Kessler (kessler)" <[email-masked]>
Date: Mon, 6 Dec 2010 08:43:19 -0800

Hi, 

After we published RFC 5060 we received a number of comments
on the MIB. Many of them I wished came out during the draft
process. We have talked about writing up a revision - but no one
wanted to take the time to do that right after we spent 2 years
to get the first draft done. If we were to publish an update
it would include all the fixes - including this one. 

I suggest we just remove (or modify) section 7 of the rp-mapping
draft so that we don't depreciate the MIB objects. We can still
go ahead and define the algorithm. 

We will leave updating the PIM MIB for a future project. 

Would that be a problem ? 

Andy

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, December 06, 2010 7:41 AM
To: Adrian Farrel
Cc: [email-masked];
[email-masked]
Subject: Re: [MIB-DOCTORS] Help with possible object deprecation

/js

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 09 Dec 2010 15:06:35 +0000

All (and Dan)

Thanks for your input on this, it helped clarify for us what we were really
doing.

As it turns out, we are not deprecating objects or changing their meaning. The
existing objects continue to have the same old meanings and uses. However the
number of times we actually use the objects for those purposes will decrease as
the new algorithm comes on  stream.

This is like observing that the IPv4 MIB objects get used less as IPv6 is
deployed.

We have added text to our I-D to explain this, and are moving on.

Cheers,
Adrian

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 09 Dec 2010 15:39:15 +0000

[PRUNED RECIPIENTS]

I think Dan and I have our wires crossed since he just wrote exactly what I
thought was the case.

An RFC that updates an old MIB module RFC would be bad.
The only way to change the semantics of an object is by a new RFC that obsoletes
the old RFC and so replaces the entire MIB module.

Anyway, see previous email, we have decided that we do NOT want to update the
semantics of the existing objects.

A

> Sent: 06 December 2010 14:53
> To: [email-masked]; [email-masked]

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 09 Dec 2010 16:56:13 +0100

Mmm  sounds like you might want to do a new MODULE-COMPLIANCE statement

Bert

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Dec 2010 16:04:10 -0000

Yes, this is a good idea.

But, can we do that without completely republishing the MIB module RFC? After
all, the compliance statement is part of the module.

Perhaps the answer is that we can write a new module that imports stuff from the
existing module and contains the new compliance statement.

A

> From: Bert (IETF) Wijnen [mailto:[email-masked]]
> Sent: 09 December 2010 15:56
> To: [email-masked]
> Cc: 'Romascanu, Dan (Dan)'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 9 Dec 2010 17:04:22 +0100

If a the MIB module will go though a new version in the future a new
MODULE-COMPLIANCE is in place. Revising the MIB module just to do a
MODULE-COMPLIANCE seems to be an overkill to me. 

Dan

> Sent: Thursday, December 09, 2010 5:56 PM
> Cc: Romascanu, Dan (Dan); [email-masked]; 
> [email-masked]; [email-masked]; 
> > Thanks for your input on this, it helped clarify for us 
> what we were 
> > really doing.
> >
> > As it turns out, we are not deprecating objects or changing their 
> > meaning. The existing objects continue to have the same old 
> meanings 
> > and uses. However the number of times we actually use the 
> objects for 
> > those purposes will decrease as the new algorithm comes on  stream.
> >
> > This is like observing that the IPv4 MIB objects get used 
> less as IPv6 
> > is deployed.
> >