headers
Thomas Narten | 2 Jan 2003 19:04
Picon
Favicon

Re: Proposal for an interim IPCDN working group meeting

Rich,

An interim meeting certainly has potential for being a good thing. TO
justify an interim, I think you (and the WG) need to make a case that
there will be sufficient "critical mass" at the interim to make it
useful. Also, it would be necessary to have an advance agenda so that
folks can decide whether its worth their while to attend, how much
time you will need, what documents will be the focus, etc. Also,
presumably some work needs to be done in advance of the meeting itself
(i.e., revise and/or submit new IDs). I would expect that the folks
with such work items would be clearly identified and would need to
commit to meeting appropriate deadlines in order for the WG meeting
itself to meet its goals.

Thomas
Permalink | Reply | 0 comments |
headers
Woundy, Richard | 3 Jan 2003 16:06
Picon

FW: Typos in the MIB boilerplate

IPCDN authors,

Please note the typo corrections below to apply to the new MIB boilerplate,
<http://www.ops.ietf.org/mib-boilerplate.html>.

Also be aware that the MIB Security Considerations
<http://www.ops.ietf.org/security.html> is being re-edited at this time.

-- Rich

-----Original Message-----
From: C. M. Heard [mailto:heard <at> pobox.com]
Sent: Thursday, January 02, 2003 10:55 PM
To: mibs <at> ops.ietf.org
Subject: Typos in the MIB boilerplate

Hello,

I noticed a couple of typos in the boilerplate
at http://www.ops.ietf.org/mib-boilerplate.html

Specifically, the last paragraph should be changed from

Y. Informative Refenreces <-- spelling + missing comma
                                             V
   [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
             "Introduction and Applicability Statements for Internet-
             Standard Management Framework", RFC 3410, December 2002.

to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raftus, David | 6 Jan 2003 17:24

RE: Updating the IPCDN WG milestones

Hi,

The RF mib track looks fine to me.

Dave

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

david.raftus <at> imedia.com           
613.592.1052  ext 222
************************************               

-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy <at> cable.comcast.com]
Sent: Tuesday, December 24, 2002 2:35 PM
To: Alexander Katsnelson (E-mail); Charles Schell (E-mail); David Raftus
(E-mail); Doug Jones (E-mail); Eugene Nechamkin (E-mail); Howard Abramson
(E-mail); Junming Gao (E-mail); Matt Osman (E-mail); Michael Patrick
(E-mail); Satish Kumar (E-mail); Siripunkaw, Pak; Sumanth Channabasappa
(E-mail); William Murwin (E-mail); Wilson Sawyer (E-mail); Wim De Ketelaere
(E-mail); Woundy, Richard
Cc: IPCDN (E-mail); Jean-Francois Mule (E-mail)
Subject: Updating the IPCDN WG milestones

Authors,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 7 Jan 2003 23:15
Picon
Favicon

RE: (ipcdn) review of subscriber management mib?

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 8 Jan 2003 01:28
Picon
Favicon

RE: (ipcdn) review of subscriber management mib?

I wrote:
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 8 Jan 2003 01:37
Picon
Favicon

RE: (ipcdn) review of subscriber management mib?

Looking in more detail, I start to see why you
used length 5 in the MODULE-COMPLIANCE
   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 }

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
Permalink | Reply | 0 comments |
headers
Eduardo Cardona | 8 Jan 2003 02:12
Favicon

RE: RE: (ipcdn) review of subscriber management mib?


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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 8 Jan 2003 02:43
Picon
Favicon

RE: MIB Doctor review of: draft-ietf-ipcdn-subscriber-mib-07.txt

base on my earlier comments on rev 06

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: dinsdag 1 oktober 2002 17:28
> To: wsawyer <at> ieee.org; ipcdn <at> ietf.org
> Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Bert 
> Wijnen (E-mail)
> Subject: MIB Doctor review of: draft-ietf-ipcdn-subscriber-mib-06.txt
> 
> 
> Took a bit longer than I had hoped. Oh well, here we go
> 
> More or less serious issues/concerns:
> - 2nd para in Section 2 starts off with:
>     "Much of this MIB duplicates capabilities found in 
>      the DOCSIS Cable Device MIB [17]."
>   So I immediately wonder why we need to duplicate any of
>   that other stuff, even without looking at the details.
>   Pls explain/justify. 
>   The other praragraphs in this section try to explain some 
>   of it I think. But what is not clear is: will this MIB
>   then obsolete the one in reference [17].
>   If it only partially obsoletes/replaces it, then maybe
>   that should be made clear and the [17] may need a 
>   revision to deprecate the objects being replaced.

I see text is added, also had some more input from the 
authors/editors. I have suggested to potentially add some more
of the explanations that were given to me to the document
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 8 Jan 2003 11:21
Picon
Favicon

RE: RE: (ipcdn) review of subscriber management mib?

Inline

> -----Original Message-----
> From: Eduardo Cardona [mailto:e.cardona <at> CableLabs.com]
> Sent: woensdag 8 januari 2003 2:13
> To: Wijnen, Bert (Bert); Wilson.Sawyer <at> arrisi.com
> Cc: richard_woundy <at> cable.comcast.com; Ipcdn (E-mail)
> Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib?
> 
> 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
> 
Right.

> 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."
> 
Which is good if that is the COMPLIANCE you currently want.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wilson.Sawyer | 8 Jan 2003 13:45
Favicon

RE: RE: (ipcdn) review of subscriber management mib?


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

                                                                                                                 
                      "Wijnen, Bert                                                                              
                      (Bert)"                  To:       Eduardo Cardona <e.cardona <at> CableLabs.com>, "Wijnen,     
                      <bwijnen <at> lucent.c         Bert (Bert)" <bwijnen <at> lucent.com>, Wilson.Sawyer <at> arrisi.com      
                      om>                      cc:       richard_woundy <at> cable.comcast.com, "Ipcdn (E-mail)"      
                      Sent by:                  <ipcdn <at> ietf.org>                                                 
                      ipcdn-admin <at> ietf.        Subject:  RE: [ipcdn] RE: (ipcdn) review of subscriber management 
                      org                       mib?                                                             

                                                                                                                 
                      01/08/03 05:21 AM                                                                          

Inline

> -----Original Message-----
> From: Eduardo Cardona [mailto:e.cardona <at> CableLabs.com]
> Sent: woensdag 8 januari 2003 2:13
> To: Wijnen, Bert (Bert); Wilson.Sawyer <at> arrisi.com
> Cc: richard_woundy <at> cable.comcast.com; Ipcdn (E-mail)
> Subject: RE: [ipcdn] RE: (ipcdn) review of subscriber management mib?
>
> 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,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane