Subject: [ipcdn] Transition to InetAddress from IpAddress in DOCSIS Mibs

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Tue, 3 Dec 2002 23:23:21 -0500

Rich, Wilson, and other DOCSIS mib implementors:

I apologize for staying out of the loop so long on MIB issues.

Has there been agreement, or even discussion, on the transition from our currently implemented DOCSIS mibs, which use the ipV4-only IpAddress type, to the various newly proposed DOCSIS mibs which use the ipv6-capable InetAddressType/InetAddress  pair?   If we can reach agreement on a transition policy, I think our InetAddress mib versions should have DESCRIPTION wording to enforce that policy.

The polciy objectives are:
I.   "Old" managers (with only old mibs compiled) can manage "new" agents (implementing the new mibs) and
II.  "New" managers (compiling only the new mib or both old and new mibs) can manage "old" agents (i.e. certified devices with the existing MIBs). 

I'd like to propose the following policies:

1.  The updated mibs add NEW objects of type InetAddress for all IPAddress objects in the currently implemented MIBs. They do NOT define a whole new MIB. 

2.  The currently implemented (IpAddress) mib objects are given a status of DEPRECATED, but
    they are also MANDATORY to implement (!) 

3.  Sets to the deprecated (old) IpAddress object can be read back in the corresponding InetAddress object, and the corresponding InetAddressType is set to v4. 

4.  Sets to the (new) InetAddress object to a v4 address can be read back by the corresponding (old) IpAddress object.   

This meets the objectives: 
I. Old managers set and read the old IpAddress objects, which  continue to work on the new agents. 
II.  New managers can set and read the deprecated objects from the old agents. 

This is what we were planning to do for the QOS mib -07 update. 

Comments (for or against)?
-mike

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, November 27, 2002 11:48 AM
To: 'Ian Wheelock'
Cc: [email-masked]; DOCSIS OSS (E-mail)
Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt

The latest internet-draft version of the Subscriber Management MIB is:
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-07.txt>
. The recent changes were responses to comments by our IETF MIB doctor.

This version of the MIB cannot be implemented nor required by a CableLabs
cert wave, because the root of the MIB is "{ mib-2 xx }", where "xx" is to
be assigned after IESG approval of the MIB.

However, the ultimate intent is to require the RFC version of this MIB in a
future certification wave. If there are problems with this MIB, they should
be discussed on the ipcdn mailing list.

-- Rich

-----Original Message-----
From: Ian Wheelock [mailto:[email-masked]]
Sent: Wednesday, November 27, 2002 11:00 AM
To: [email-masked]
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt

Hi,

is there any decision on whether this version of the mib will be required
for the next certwave ?

there seems to have been extensive changes made to the mib compared to -06,
but i did not see much of this debated on the ipcdn reflector.

is there another reflector/list that discussions have been ongoing on ?

thanks
Ian

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

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

---

From: [email-masked]
Date: Wed, 4 Dec 2002 08:59:16 -0500

Speaking only for the subscriber management MIB, there was a strong push as
part of the mib doctor review to clean up historical accidents - for
example, to replace the clumsiness of RFC 2851 InetAddresses with 3291
conventions. There was also a push to re-root the MIB under { mib-2 },
partly to free it from any historical anomalies that may have crept in
under previous drafts while rooted under { docsDev }.

The result is a new mib at a different root with no backward compatibility.
I expect CableLabs to abandon the old mib and require compliance with the
new one, once the RFC editor assigns the { mib-2 XX } root. Of course,
vendors might continue to offer support for the old mib as well.

Regards,
Wilson

                      Patrick                                                                                      
                      Michael-LZZ007             To:       "'Woundy, Richard'" <[email-masked]>, 
                      <Michael.Patrick@mo         "[email-masked]'" <[email-masked]>                          
                      torola.com>                cc:       [email-masked], "DOCSIS OSS (E-mail)"                   
                      Sent by:                    <[email-masked]>                                       
                      [email-masked]        Fax to:                                                           
                      g                          Subject:  [ipcdn] Transition to InetAddress from IpAddress in     
                                                  DOCSIS Mibs                                                      
                                                                                                                   
                      12/03/02 11:23 PM                                                                            

Has there been agreement, or even discussion, on the transition from our
currently implemented DOCSIS mibs, which use the ipV4-only IpAddress type,
to the various newly proposed DOCSIS mibs which use the ipv6-capable
InetAddressType/InetAddress  pair?   If we can reach agreement on a
transition policy, I think our InetAddress mib versions should have
DESCRIPTION wording to enforce that policy.

The polciy objectives are:
I.   "Old" managers (with only old mibs compiled) can manage "new" agents
(implementing the new mibs) and
II.  "New" managers (compiling only the new mib or both old and new mibs)
can manage "old" agents (i.e. certified devices with the existing MIBs).

1.  The updated mibs add NEW objects of type InetAddress for all IPAddress
objects in the currently implemented MIBs. They do NOT define a whole new
MIB.

2.  The currently implemented (IpAddress) mib objects are given a status of
DEPRECATED, but
    they are also MANDATORY to implement (!)

3.  Sets to the deprecated (old) IpAddress object can be read back in the
corresponding InetAddress object, and the corresponding InetAddressType is
set to v4.

4.  Sets to the (new) InetAddress object to a v4 address can be read back
by the corresponding (old) IpAddress object.

This meets the objectives:
I. Old managers set and read the old IpAddress objects, which  continue to
work on the new agents.
II.  New managers can set and read the deprecated objects from the old
agents.

-----Original Message-----
From: Woundy, Richard [mailto:[email-masked]]
Sent: Wednesday, November 27, 2002 11:48 AM
To: 'Ian Wheelock'
Cc: [email-masked]; DOCSIS OSS (E-mail)
Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt

The latest internet-draft version of the Subscriber Management MIB is:
<http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-07.txt

-- Rich

-----Original Message-----
From: Ian Wheelock [mailto:[email-masked]]
Sent: Wednesday, November 27, 2002 11:00 AM
To: [email-masked]
Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-07.txt

Hi,

thanks
Ian