Subject: RE: [ipcdn] Transition to InetAddress from IpAddress in DOCSIS Mi bs

From: "Raftus, David" <[email-masked]>
Date: Wed, 4 Dec 2002 04:52:23 -0800

Mike et al,

The rf mib draft update of RFC2670, which has been required by Docsis for
quite some time for both 1.1 and 2.0 has included ipv6 objects since v1 last
November. The release of v5 is imminent. The existing ipv4 objects were
indeed designated as deprecated.

I agree with your goal of allowing unimpeded access to old and new managers.
I would think that ecns to both the spec and atps would be required to both
mandate and verify the behavior though.

Dave

************************************
David Raftus
Imedia Semiconductor
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2

[email-masked]           
613.592.1052  ext 222
************************************               

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 11:23 PM
To: 'Woundy, Richard'; [email-masked]'
Cc: [email-masked]; DOCSIS OSS (E-mail)
Subject: [ipcdn] Transition to InetAddress from IpAddress in DOCSIS Mibs

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
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Wed, 4 Dec 2002 09:06:22 -0500

Wilson,

If we have to have a whole new mib, shouldn't we allow a manager to load both the old and the new mibs, so that a manager can manage both old and new clients?

Doesn't that require the new mib to have different OID names?  If we reuse the names with a different OID, won't that cause MSO scripts talking to old agents to stop working?

Should we have wording in either the new mib (or maybe only in the OSS spec) *requiring* implementation of the old mib in CM and CMTS agents (again, to keep existing snmp scripts working).

-mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 04, 2002 8:59 AM
To: Patrick Michael-LZZ007
Cc: DOCSIS OSS (E-mail); [email-masked]; [email-masked]; 'Woundy,
Richard'
Subject: Re: [ipcdn] Transition to InetAddress from IpAddress in DOCSIS
Mibs

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                                                                            

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

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

---

From: [email-masked]
Date: Wed, 4 Dec 2002 09:39:24 -0500

Mike -

Your point about object names makes assumptions about manager
scripts/browsers. These names have never been guaranteed to be unique
across MIBs, so the scripts/browsers have to have some means of
disambiguating names anyway. For some folks with some scripts, I'd agree
that this entails some inconvenience.

Your last question is for the community at large, but my opinion is that we
should not *require* implementation of the old mib, once the new one is
available. To do so seems to me to keep us stuck to the past. The burden of
detecting which of the two versions to use shouldn't be that bad for
operators.

We may want to coordinate introduction of the various docsis mibs, so that
the operator doesn't have to figure out the combinatorial possibilities
within a single device of old/new submgt, old/new qos, old/new RFI, old/new
device ... This would seem to be a DOCSIS OSS responsibility.

- Wilson

                      Patrick                                                                                      
                      Michael-LZZ007             To:       "[email-masked]'" <[email-masked]> 
                      <Michael.Patrick@mo        cc:       "DOCSIS OSS (E-mail)" <[email-masked]>,       
                      torola.com>                 [email-masked], [email-masked], "'Woundy, Richard'"        
                                                  <[email-masked]>                               
                      12/04/02 09:06 AM          Fax to:                                                           
                                                 Subject:  RE: [ipcdn] Transition to InetAddress from IpAddress in 
                                                  DOCSIS Mi      bs                                                

Wilson,

If we have to have a whole new mib, shouldn't we allow a manager to load
both the old and the new mibs, so that a manager can manage both old and
new clients?

Doesn't that require the new mib to have different OID names?  If we reuse
the names with a different OID, won't that cause MSO scripts talking to old
agents to stop working?

Should we have wording in either the new mib (or maybe only in the OSS
spec) *requiring* implementation of the old mib in CM and CMTS agents
(again, to keep existing snmp scripts working).

-mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, December 04, 2002 8:59 AM
To: Patrick Michael-LZZ007
Cc: DOCSIS OSS (E-mail); [email-masked]; [email-masked]; 'Woundy,
Richard'

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

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

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

---

From: [email-masked]
Date: Wed, 4 Dec 2002 08:47:40 -0700

FYI, the version of the BPI+ MIB that's been required for quite some time 
now also has already been transitioned to handle IPv6.  So in that area at 
least, it's been supported for a long time.

Matt

"Raftus, David" <[email-masked]>
Sent by: [email-masked]
12/04/02 05:52 AM

        To:     "'Patrick Michael-LZZ007'" <[email-masked]>, "'Woundy, 
Richard'" <[email-masked]>, "[email-masked]'" 
<[email-masked]>
        cc:     [email-masked], "DOCSIS OSS (E-mail)" <[email-masked]>, "Docsis 
20 Reflector (E-mail)" <[email-masked]>
        Fax to: 
        Subject:        RE: [ipcdn] Transition to InetAddress from IpAddress in DOCSIS Mi       bs

Mike et al,

The rf mib draft update of RFC2670, which has been required by Docsis for
quite some time for both 1.1 and 2.0 has included ipv6 objects since v1 
last
November. The release of v5 is imminent. The existing ipv4 objects were
indeed designated as deprecated.

I agree with your goal of allowing unimpeded access to old and new 
managers.
I would think that ecns to both the spec and atps would be required to 
both
mandate and verify the behavior though.

Dave

[email-masked] 
613.592.1052  ext 222

-----Original Message-----
From: Patrick Michael-LZZ007 [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 11:23 PM
To: 'Woundy, Richard'; [email-masked]'
Cc: [email-masked]; DOCSIS OSS (E-mail)
Subject: [ipcdn] Transition to InetAddress from IpAddress in DOCSIS Mibs

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

by

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

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,

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.

thanks
Ian