Subject: [ipcdn] Docsis Subscriber Management MIB: proposed changes for -05

From: [email-masked]
Date: Tue, 12 Feb 2002 10:20:33 -0500

Several folks have pointed out problems with and ambiguities in
the -04 draft of the subscriber management MIB. Described below
are proposed changes that will go into the -05 draft, subject to the
approval of the working group.

Respectfully submitted,
Wilson Sawyer
ARRIS
[email-masked]

------------------------------------------------------------------------

Problem: The MIB is rooted at a temporary location; furthermore,
its OID space has been renumbered between revisions, introducing
conflicts with earlier revisions if not moved.

Solution: re-home at { docsDev 5 }

Problem: specifying ULP=ANY doesn't really create a sensible
filter when paired with a TcpUdpFilterEntry. The semantics in that
case would be something like: match if neither TCP nor UDP, or if
TcpUdpFilterEntry matches. It strains the imagination to invent a
good use for such behavior.

Solution: Ignore TcpUdpFilterEntry when ULP=ANY. This brings this mib
in line with RFC-2669. Textually, the description of docsSubMgtPktFilterUlp
changes to:

   docsSubMgtPktFilterUlp OBJECT-TYPE
       SYNTAX      Integer32 (0..256)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Upper level protocol to match.  If this value is 256,
       matches ALL ULP values.  Otherwise, this matches the specific
       protocol value.  Note that if the packet ULP is either 6 (tcp) or
       17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be
       consulted (if its entry exists) to see if this entry matches.
       If this value is neither tcp(6) nor udp(17), then that
       table is not consulted."
        DEFVAL { 256 }
       ::= { docsSubMgtPktFilterEntry 11 }

Problem: docsSubMgtCpeControlMaxCpeIp is defined as Integer32(0..1024),
while the corresponding provisioning object is a 10-bit field, implying
a range of 0..1023.

Solution: Change the definition of docsSubMgtCpeControlMaxCpeIp to be
Integer32(0..1023). [ed: normally per 2578 this would require an OID
change, but we are changing all OIDs in this mib as it's re-rooted
anyway.]

Problem: It may not be clear that docsSubMgtCmFilterDownstream and
docsSubMgtCmFilterUpstream are really meant to control an aspect of
CPE behavior, in the sense in which CPE is meant by, say,
docsSubMgtCpeControlActive. (These items exist not to control
modem behavior per se, but to control the ways in which the modem,
or its MAC identity, could be suborned to acquire unauthorized services
for a subscriber host.)

Solution: Change the description of docsSubMgtCmFilterEntry to be:

   docsSubMgtCmFilterEntry OBJECT-TYPE
       SYNTAX  DocsSubMgtCmFilterEntry
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
           "Binds a filter group to each direction of traffic for a
       modem. The filters in this entry apply if docsSubMgtCpeControlActive
       is true."
       AUGMENTS { docsIfCmtsCmStatusEntry }
       ::= {docsSubMgtCmFilterTable 1 }

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

---

From: Norbert Juffa <[email-masked]>
Date: Tue, 12 Feb 2002 14:18:46 -0800

[...]
>        ::= {docsSubMgtCmFilterTable 1 }

This looks like a very important clarification to me.

My previous understanding was that docsSubMgtCmFilterDownstream and
docsSubMgtCmFilterUpstream are applied independent of the state of 
docsSubMgtCpeControlActive, i.e. the filters in these groups are 
always applied. Apparently this understanding was incorrect.

If I understand this change correctly, it says that the application
of docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream is
conditional dependening on the state of docsSubMgtCpeControlActive.

In other words, if docsSubMgtCpeControlActive is FALSE, none of the
filters in docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream,
docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream apply.

Is my understanding correct now?

-- Norbert

---

From: Norbert Juffa <[email-masked]>
Date: Tue, 12 Feb 2002 14:18:46 -0800

[...]

-- Norbert

---

From: [email-masked]
Date: Thu, 14 Feb 2002 08:26:18 -0500

Yes, that is correct.

- Wilson

                    Norbert Juffa                                                                                     
                    <[email-masked]       To:     "[email-masked]'" <[email-masked]>,             
                    m>                    [email-masked], [email-masked]                                    
                    Sent by:             cc:                                                                          
                    ipcdn-admin@ie       Fax to:                                                                      
                    tf.org               Subject:     [ipcdn] RE: Docsis Subscriber Management MIB: proposed changes  
                                          for -05                                                                     
                                                                                                                      
                    02/12/02 05:18                                                                                    
                    PM                                                                                                

[...]

-- Norbert

---

From: [email-masked]
Date: Thu, 14 Feb 2002 08:26:18 -0500

Yes, that is correct.

- Wilson

                    Norbert Juffa                                                                                     
                                                                                                                      
                    02/12/02 05:18                                                                                    
                    PM                                                                                                

[...]

-- Norbert