Subject: [ipcdn] Subscriber Management MIB questions.

From: Murwin William-LWM008 <[email-masked]>
Date: Thu, 15 Nov 2001 14:08:54 -0500

Dear Docsis OSS and IPCDN Community,
	
	I have some questions about the lastest Subcriber Management MIB, that go all
	the way back to draft-ietf-ipcdn-subscriber-mib-02.txt and draft-ietf-ipcdn-subscriber-mib-03.txt,
	since last call has begun on  draft-ietf-ipcdn-subscriber-mib-04.txt.

	In draft-ietf-ipcdn-subscriber-mib-02.txt, Ip Address objects where of the syntax  IpV4orV6Addr.
	
docsSubMgtCpeIpAddr OBJECT-TYPE
       SYNTAX      IpV4orV6Addr
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The IP address either set from provisioning or learned via
       wiretapping. See docsSubMgtCpeIpIndex for the mechanism."
       ::= { docsSubMgtCpeIpEntry 2 }

docsSubMgtPktFilterSrcAddr OBJECT-TYPE
       SYNTAX      IpV4orV6Addr
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The source IP address to match in the packet to be
       classified.  By default, this is the all-zero's IP v4 and v6
       address. A packet matches the SrcAddr filter if the following is
       true:
            AND (FilterSrcAddr, FilterSrcMask) ==
            AND (Packet SrcAddr, FilterSrcMask).
       The mask value is applied to both the match value in this table
       and to the packet IP address."
       DEFVAL { ''h }
       ::= { docsSubMgtPktFilterEntry 3 }

   docsSubMgtPktFilterSrcMask OBJECT-TYPE
       SYNTAX      IpV4orV6Addr
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "A bit mask that is to be applied to the source address
       prior to matching. This, taken with the SrcAddr specifies a
       matching criteria.  By default, the pair specifies a filter
       which matches all source addresses. This mask is not
       necessarily the same as a subnet mask, but for IPv4 addresses
       the 1's bits must be leftmost and contiguous. IPv6 masks have
       no such restriction."
       DEFVAL { ''h  }
       ::= { docsSubMgtPktFilterEntry 4 }

   docsSubMgtPktFilterDstAddr OBJECT-TYPE
       SYNTAX      IpV4orV6Addr
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The destination IP address to match in the packet to be
       classified.  By default, this is the all-zero's IP v4 and v6
       address. A packet matches the DstAddr filter if the following is
       true:
            AND (FilterDstAddr, FilterDstMask) ==
            AND (Packet DstAddr, FilterDstMask).
       The mask value is applied to both the match value in this table
       and to the packet IP address."
       DEFVAL { ''h }
       ::= { docsSubMgtPktFilterEntry 5 }

   docsSubMgtPktFilterDstMask OBJECT-TYPE
       SYNTAX      IpV4orV6Addr
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "A bit mask that is to be applied to the destination
       address prior to matching. This, taken with the DstAddr
       specifies a matching criteria.  By default, the pair specifies
       a filter which matches all destination addresses. This mask is
       not necessarily the same as a subnet mask, but for IPv4
       addresses the 1's bits must be leftmost and contiguous. IPv6
       masks have no such restriction."
       DEFVAL { ''h  }
       ::= { docsSubMgtPktFilterEntry 6 }

In draft-ietf-ipcdn-subscriber-mib-03.txt, Ip Address objects where changed to have syntax of
InetAddress, and new object where introduced of InetAddressType. However according to the
rules of Internet Network Address rfc2851. The InetAddressType object had to
preceded the InetAddress object. Thus the MIB was renumbered. 

For example, 
docsSubMgtCpeIpAddr had its type changed and went from 
{ docsSubMgtCpeIpEntry 2 } to { docsSubMgtCpeIpEntry 3 }
because of this the rest of the objects in the docsSubMgtCpeIpTable were
renumbered. The same thing also happened with the
docsSubMgtPktFilterTable.

For this reason draft-ietf-ipcdn-subscriber-mib-03.txt is NOT
BACKWARD compatible with draft-ietf-ipcdn-subscriber-mib-02.txt.

From personal experience it has been a hassle to make sure
the right version of the MIB implemented for the correct occasion.
whether it be for Dry Runs, TEPs, ATPs, or other,  since version 2
will not work when version 3 is required.

At the same time this did not seem like such a big deal since 
version 3 Ip Address syntax was a recognized textual convention
for supporting both IPv4 and IPv6 Address formats. And I assumed
that version 3 would soon become required for DOCSIS 1.1 and become
widely implemented.

However, to date version 2 of the MIB is only required by DOCSIS.
And now that there are Qualified DOCSIS 1.1 product, 
draft-ietf-ipcdn-subscriber-mib-02.txt has been widely implemented.

What will happen when draft-ietf-ipcdn-subscriber-mib-04.txt becomes
used within Managers and query agents that supported draft-ietf-ipcdn-subscriber-mib-02.txt
or Managers that currently use draft-ietf-ipcdn-subscriber-mib-02.txt and talk to
agent that implement draft-ietf-ipcdn-subscriber-mib-04.txt. 

I was hoping to see in changes within draft-ietf-ipcdn-subscriber-mib-04.txt 
made to address these issues in order to provide backward compatible with
widely implemented version 2.

Whether it be objects made obsolete or deprecated that where
of syntax IpV4orV6Addr, or whole tables decreased 
and new one implemented, so that a smooth
transition can be made from draft-ietf-ipcdn-subscriber-mib-02.txt to 
draft-ietf-ipcdn-subscriber-mib-04.txt  and visa-versa.

While I understand that this is an internet draft and is experimental,
believe there should be some consistency moving forward with
this draft to address the industry usage of this MIB.

Thanks,
Will  Murwin

_______________________________
William Murwin
Broadband Communications Sector
Motorola Inc.
Email: [email-masked]
Tel: (508) 261-5578

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