Subject: [ipcdn] RE: (ipcdn) review of subscriber management mib?

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 7 Jan 2003 23:15:12 +0100

Well, it compiles clean. Good.

But... you get me confused.
You made some good changes based on my review I think,
but it seems they are incomplete.

For example I see:
   docsSubMgtPktFilterSrcAddr OBJECT-TYPE
       SYNTAX      InetAddress
       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. The address type of this object is
       specified by docsSubMgtPktFilterAddrType."
       DEFVAL { '0400000000'H }    -- 0.0.0.0
       ::= { docsSubMgtPktFilterEntry 4 }

   docsSubMgtPktFilterSrcMask OBJECT-TYPE
       SYNTAX      InetAddressPrefixLength
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Specifies the number of leftmost 1's bits in an address
       bit mask. The bit mask that is 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. The address type of this
       object is specified by docsSubMgtPktFilterAddrType."
       DEFVAL { 0  }
       ::= { docsSubMgtPktFilterEntry 5 }

It is good that you use a prefixnow for the Mask (maybe I would
just call it Prefix instead of Mask as well, but that is another
matter). But now that you have done so, I think that the algorithm
from above:
               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

Of course no longer works, cause the Mask is now not an ipaddress
anymore.

I also see (In MODULE COMPLIANCE):
   OBJECT docsSubMgtPktFilterAddrType
       SYNTAX InetAddressType { ipv4(1) }
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

the above is OK

   OBJECT docsSubMgtPktFilterSrcAddr
       SYNTAX InetAddress (SIZE(5))
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

But why has an IP Address (in an InetAddress) all of a sudden
become 5 octets instead of 4 (as in your rev 6) ??

More later
Thanks,
Bert 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: maandag 6 januari 2003 16:18
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: RE: (ipcdn) review of subscriber management mib?
> 
> 
> 
> Bert -
> 
> Happy new year!
> 
> Rich and Jean-Francois are organizing an interim ipcdn 
> meeting in February
> and have posed a January 20 deadline for i-d updates from 
> myself and the
> other ipcdn authors. If you can help me meet that, I would be 
> grateful.
> There'll be a draft -08 in any case because:
> 
> -- the SNMP references and boilerplate have changed.
> -- someone has pointed out that the filter lists are not 
> explicit about the
> default (matched-no-filter) behavior.
> 
> Regards,
> Wilson
> 
> 
> 
>                                                               
>                                                    
>                       "Wijnen, Bert                           
>                                                    
>                       (Bert)"                  To:       
> [email-masked], [email-masked]        
>                       <[email-masked]        cc:            
>                                                    
>                       om>                      Subject:  RE: 
> (ipcdn) review of subscriber management mib?        
>                                                               
>                                                    
>                       12/17/02 10:02 AM                       
>                                                    
>                                                               
>                                                    
>                                                               
>                                                    
> 
> 
> 
> 
> Not yet, but hope to get to it before the end of the year
> 
> Thanks,
> Bert
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: dinsdag 17 december 2002 15:37
> > To: [email-masked]
> > Subject: (ipcdn) review of subscriber management mib?
> >
> >
> > Hi Bert,
> >
> > Have you had a chance to look at
> > draft-ietf-ipcdn-subscriber-mib-07.txt,
> > now that we're past the November meeting?
> >
> > Please let me know if there's anything I can do to help.
> >
> > Regards,
> > Wilson
> >
> 
> 
> 
> 
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 8 Jan 2003 01:28:17 +0100

> Of course no longer works, cause the Mask is now not an ipaddress

After rereading I see you use the prefix to create the mask.
So that is kind of OK then I think. It just is that "FileterSrcMask"
is the suffix of the descriptor, and so it confused me (and probably
will confuse others) to think that you use the prefix number
itself to AND... maybe a bit better explanations would help

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 8 Jan 2003 01:37:23 +0100

Looking in more detail, I start to see why you
used length 5 in the MODULE-COMPLIANCE

The 04 in the DEFVAL, what is that?
Do you intend it to mean IPv4?
Or is it intended to be the length?
None of these should be in the InetAddress field.

Bert

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 7 Jan 2003 18:12:38 -0700

Wilson, As Bert pointed 
the 04 will show up only if the ScrAddr (or InetAddress Type ) field
were part of a multi-indexed table, 
It that were the case still not needed in the SYNTAX clause a size 5,
the Index encoding will introduce the length of the octet string, the
object size itself is still 4 for mib purposes. 

See RFC3291 section 4.1

Bert, 
My next question is (in general for all DOCSIS mibs drafts and DOCSIS
InetAddress types) :

Among the mib documents, there are multiple Compliance statements to
specify that inetAddress is required only to specify ipv4 type ""An
implementation is only required to support IPv4 addresses."

Q: If indeed this is done for all drafts, Would still IETF prefer to
define InetAddress TEXTUAL-CONVENTION for all this objects instead of
InetAddressIPv4 ? And avoid all those COMPLIANCE statements that are
replicating in a verbose way the InetAddressIPv4 SYNTAX . (ipv6, dns
types are not required in all DOCSIS modules )  

In such way a NMS will have the DISPLAY-HINT 1d.1d.1d.1d ready that is
the current pain.
I can still illegally have a friend IPv4 representation  by adding in
the Browser MIB a DISPLAY-HINT to InetAddress TEXTUAL-CONVENTION in
RFC3291, but is not the desired solution. 

Thanks 

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Tuesday, January 07, 2003 5:37 PM
To: [email-masked]'; 'Wijnen, Bert (Bert)'
Cc: [email-masked]'; 'Ipcdn (E-mail)'
Subject: [ipcdn] RE: (ipcdn) review of subscriber management mib?

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 8 Jan 2003 11:21:24 +0100

Inline

> From: Eduardo Cardona [mailto:[email-masked]]
> Sent: woensdag 8 januari 2003 2:13
> To: Wijnen, Bert (Bert); [email-masked]
> Cc: [email-masked]; Ipcdn (E-mail)
> Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib?
> 
> Wilson, As Bert pointed 
Right.

> specify that inetAddress is required only to specify ipv4 type "An
Which is good if that is the COMPLIANCE you currently want.

> types are not required in all DOCSIS modules )  
The idea of the approach you currently have is that the OBJECT
definitions in the MIB Module itself are all ready for IPv6
(and other protocols as well).
By the time you (or whoever) decides they want to use this with
IPv6 (or whatever other protocol), they can use the MIB Module
unchanged. All that is needed is a possible extra MODULE-COMPLIANCE
(which could be in a separate document) to show that from then on
(or better, in order to claim compliance with the new compliance
 statement) one must also support IPv6.

> In such way a NMS will have the DISPLAY-HINT 1d.1d.1d.1d ready that is

I would think that any decent NMS these days should be able to 
handle the techniques as presented in RFC3291, no?
So why would it be so difficult for this specific MIB module.

> RFC3291, but is not the desired solution. 
People can always do illegal things. We are not law (or protocol or
stds) enforcement body... so what can I say.
Cablelabs should not certify implementations that do illegal things
(they have more power than IETF have in this regard).

Hope this helps.
Bert

---

From: [email-masked]
Date: Wed, 8 Jan 2003 07:45:05 -0500

My mistake. I had hallucinated a leading length octet for some (now
incomprehensible) reason.
- Wilson

                      "Wijnen, Bert                                                                              
                      (Bert)"                  To:       Eduardo Cardona <[email-masked]>, "Wijnen,     
                      <[email-masked]         Bert (Bert)" <[email-masked]>, [email-masked]      
                      om>                      cc:       [email-masked], "Ipcdn (E-mail)"      
                      Sent by:                  <[email-masked]>                                                 
                      ipcdn-admin@ietf.        Subject:  RE: [ipcdn] RE: (ipcdn) review of subscriber management 
                      org                       mib?                                                             

                      01/08/03 05:21 AM                                                                          

Inline

Right.

(remainder snipped)

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 8 Jan 2003 19:23:25 -0700

Thanks Bert, For the comments, 

Maybe the topic is out of the ipcdn group so move back to ipcdn topics.

Just see more comments inline '<Edo></Edo>' if interested

Thanks

Eduardo

The idea of the approach you currently have is that the OBJECT
definitions in the MIB Module itself are all ready for IPv6 (and other
protocols as well). By the time you (or whoever) decides they want to
use this with IPv6 (or whatever other protocol), they can use the MIB
Module unchanged. All that is needed is a possible extra
MODULE-COMPLIANCE (which could be in a separate document) to show that
from then on (or better, in order to claim compliance with the new
compliance
 statement) one must also support IPv6.

<Edo>
I may abandon my desires on that, due to the fact that I guess RFC2578
Section 9. "Refined Syntax" for OCTET STRING note(3) does not allow  an
upgrade of TC octet string to augment the size choise (just to reduce
it) ? 
The bottom line is that the TC is OCTET string, so moving from (SIZE(4))
to InetAddress (SIZE(0..255) may not valid. Am I correct?

I will say I had no intention to be out of the IPv6 upgrading path. Just
getting the minimum COMPLIANCE statements
 << objectable ) :-) >>

But let me explain what weres my thoughs.... Or jump over the next
<Edo></Edo>

I see this as an analogy:
RFC2011 is being proposed to be deprecated by
draft-ietf-ipv6-rfc2011-update-01.txt 
Until someone decided to support Ipv6, there is no need to have support
for the 'RFC2011-update'.
All instrumentation around mib-2 RFC2011 is no longer valid for IPv6
including (i.e) ipNetToMediaTable, now inetNetToMediaTable ( Time to
change the NMS) in the mean time everyone will continue using the
traditional RFC2011 ipNetToMediaTable.

In DOCSIS, mib drafts there are provisions for IPv6 like InetAddressType
and InetAddress* TC rather than IpAddress type.
I do no see a hurry of fully implementing 'InetAddress' TC and being
IPv6 'ready' when IPv4 is overloaded with a big set of COMPLIANT
statements which add few value in the chain (IPv4 is what we care now).

(**) The upgrade to Support IPv6 or any other protocol would be ( if
IETF allows that) moving from InetAddressIPv4 to InetAddress which
technically is no more than moving from SIZE(4) to size(0..255) OCTET
STRING -I'd prefer SIZE(4|8|16|20) under a new TC with no dns(16) type -
and no compliance statements at all. 
Or deprecate the mibs just to change the TC as RFC2011 moving from
IpAddress to InetAddress ? Because of RFC2578 requirements?

Closing the topic :
- InetAddress TC is so general, MIB is ready for further IP protocols
but the backward IPv4 SMIv2 compatibility problem could be costly at
expenses of not still implementing Ipv6 or any other protocol.
 ( see comment about NMS)

</Edo>

<Edo>
I guess It is not a problem with this particular mib, it is for all mibs
involved with IP objects migrating to Ipv6. 

The RFC3291 procedure to assign the DISPLAY-HIT based on the object type
is not backward compatible with current(before inetAddress)/legacy NMS
entities and SMIv2 requirements. Now you need an extra object
(inetAddressType) to discriminate the DISPLAY-HINT, so no arbitrary
get/getnext request to an Address object will be able to hint the object
syntax.

 IPv4 case: 
So far 4 browsers/applications I know, handle 'inetAddress' as just
plain OCTET STRING SIZE(0..255) -since no DISPLAY-HINT-, then, a user
gets a Hex format for ipv4 values.

If an "1d." DISPLAY-HINT is set, some of them will present (SNMP GET
operations) in friendly ip format d.d.d.d 
few less will still recognize the hint format and encode properly when
doing SNMP SET operations.
Those cases are worst in graphical interfaces applications.

</Edo>

<Edo>
In this case there is not certainly an ilegal thing that comes with a
wrong implementations, It just a work around in the browser side (not
the Agent implementation) because is knew that ipv4 is the expected
value. What I am saying is I would prefer not having to modified the
InetAddress Tcin RFC3291, or advice someone to do that as I've been
forced to do in some cases, including CableLabs for testing purposes.

We are in an intermedia position: Writing IPv4 implementations
requirements with Ipv6 requirements and not even satisfying the IPv4
needs as they were under SMI/SMIv2 IpAddress scheme ( and I will argue
RFC3291 is broken, not SMIv2 backward compatible in the management
entity side).

</Edo>

Hope this helps.
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 9 Jan 2003 12:24:34 +0100

OK, I think this is a discussion not specific to your IPCDN 
MIB Modules, but a generic discussion about the INET-ADDRESS-MIB
and that is best done on the [email-masked] mailing list
(you must subscribe in order to post).

I believe that a lot of this discussion did take place in the
past already... but it may not be bad to do another rerun if
you so desire. You will find that many/most/all SNMP/SMI/MIB
people will agree with me (approving the RFC3291 basically
means we have IETF consensus on it). If not, then I am 
surprised that not anyone spoke up on the IETF Last Call
for that document (that is what IETF Last Calls are for...
if people just ignore such last calls and then object when
they later get faced with what we believe to be IETF consensus
... well, then our process is broken.... or people/participants
do not understand how the process works).

Thanks,
Bert 

> Sent: donderdag 9 januari 2003 3:23