headers
Wilson.Sawyer | 1 Nov 2002 20:00
Favicon

draft-ietf-ipcdn-subscriber-mib-07.txt

Colleagues,

Attached is the -07 draft of the Docsis Subscriber Management MIB. It was
revised to incorporate a number of changes suggested by Bert Wijnen as part
of the "MIB Doctor" review. Please see Bert's mail of October 1 for
reference.

Please review this carefully, particularly if you are a vendor or operator
of CMTSs. The draft has changed substantially since -06. In responding to
Bert's requests for clarification, I have made choices which need to be
ratified or corrected by this group.

Note that this draft uses an unspecified root. This means that it cannot be
used for DOCSIS compliance testing. If it progresses to RFC then it will be
assigned a root at that time.

Respectfully submitted,
Wilson Sawyer

(See attached file: draft-ietf-ipcdn-subscriber-mib-07.txt)
Attachment (draft-ietf-ipcdn-subscriber-mib-07.txt): application/octet-stream, 64 KiB
Permalink | Reply | 0 comments |
headers
George Hart | 1 Nov 2002 22:20

RE: RE: rf mib draft v5 - comment period end Friday Oct 2 5

The upstream counters make sense to me, and will be useful in helping
operators determine the utilization of the upstream path. I think I
understand the concept for downstream, although the description for the
object docsIfDownChannelTotalBytes may be confusing. It seems to me this
should represent the downstream capacity available, not the number of bytes
transported which is enumerated by docsIfDownChannelUsedBytes.

One refinement to consider for the upstream is to count minislots available
vs used in the contention region separately from the MAP region. These two
regions are subject to very different access mechanisms and having separate
indications of utilization on these regions could prove helpful.

Thanks to all for the hard work in moving this along so aggressively. It
will be extremely useful to us.

George

-----Original Message-----
From: Greg White [mailto:g.white <at> cablelabs.com]
Sent: Thursday, October 31, 2002 2:32 PM
To: Greg.Gohman <at> arrisi.com
Cc: Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS Majordomo List;
Ipcdn List (E-mail); Rich Woundy (Work) (E-mail); Tom.Cloonan <at> arrisi.com
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5

Does anyone else have an opinion on this?

I will try to flesh out the proposal:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Abramson, Howard | 2 Nov 2002 00:41
Picon

RE: draft-itef-ipcdn-igmp-mib-04


Dave / Bill,

I am working with Rich and Jean-Francois to address the comments provided on
this draft by Dave and the MIB Doctor. Before we get to far on the changes,
we would appreciate your consideration of the following proposal.

This is greatly appreciated.

Regards,

Howard Abramson

Goals:
 . provide flexibility of implementation (e.g., not restrict
   vendors' creativity)
 . RFC-2933 and RFC-2236 compliance for Operator ease of use
 . DOCSIS 1.1 compliance

Proposal:
 . define "Interface Specific" compliance statements to describe
   the minimum set of RFC-2933 objects that must be supported
   by a DOCSIS 1.1 device.

Discussion:
 . there is some confusion as to the correctness of this approach.
   Specifically, can a device apply different compliance statements
   to different interfaces.

 . the number of different types of DOCSIS 1.1 IGMP capable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Francois Mule | 2 Nov 2002 01:56
Favicon

RE: draft-itef-ipcdn-igmp-mib-04

To add to Howard's email, we are seeking input from the ipcdn list and some additional guidance from MIB
experts on how to best draft the MODULE-COMPLIANCE statements based on igmp mib. 

To be specific, a CMTS device may have active/passive interfaces (NSI or HFC interfaces) and depending on
the configuration and the mode of operation (active/passive), those interfaces can act as IGMP proxies
only or routers. As a consequence, if I read the way docsis defines this correctly, in the
igmpInterfaceTable for a CMTS, we have several entries (conceptual rows) with some columnar objects
that do or do not apply depending on the configuration of the device.

So how do we best create logical groups to include the objects that must be supported by docsis devices?
To build on Howard's email, we've got a couple of options, 2 of which are listed here to start the discussion:
  1. Specify the object groups by cmts<Interface><Mode><igmpRole>: the issue here is it does not seem right
to me to have compliance statements that vary depending on the interface type on the device;
  2. Specify the object groups by cmts<Mode><igmpRole> and select objects independently of the interface:
issue here is depending on the interface & configuration, it can play a host or router (see below).

Any thoughts?  

Jean-Francois.
> -----------------------------------------------------
> |           Active DOCSIS IGMP Interfaces           |
> |---------------|-----------------------------------|
... snip
> |---------------------------------------------------|
> |      |        |Host Only   |                      | <- a PROXY
> |      | NSI    -------------|----------------------|
> |      |        |Host&Router |                      | <-an M-Router
> |      |        |            |                      |
> |CMTS  ---------------------------------------------|
> |      |        |Router Only |                      | <-a PROXY
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jean-Francois Mule | 5 Nov 2002 00:47
Favicon

FYI: Copyright statement in MIB Modules


> -----Original Message-----
> From: The IESG [mailto:iesg-secretary <at> ietf.org]
> Sent: Monday, November 04, 2002 3:14 PM
> Cc: RFC Editor
> Subject: Copyright statement in MIB Modules
> 
> 
>            Copyright statement in MIB Modules
>  
>  Many people/tools extract the MIB modules out of our RFCs that 
>  contain a MIB module. In most cases they remove the copyright 
>  information that is part of the RFC. This is against the IETF
>  copyright claim. 
>  
>  People/tools do this not with bad intentions. The reason they 
>  do not extract the copyright info is because it is not in machine
>  readable/parsable form, and they want the MIB modules to feed
>  them into their agents, network management platforms, or other
>  MIB tools.
>  
>  In order to ensure that the copyright statement is properly
>  preserved and included in extracted MIB modules, and in order
>  to make it easier for people/tools to keep the proper copyright
>  when extracting MIB modules, the IESG has agreed with the
>  the RFC-Editor that:
>  
>     The RFC-Editor, during the editing process of an RFC that
>     contains a MIB Module, copies a short copyright statement
>     into the DESCRIPTION clause of the MODULE-IDENTITY macro
(Continue reading)

Permalink | Reply | 0 comments |
headers
Woundy, Richard | 7 Nov 2002 01:19
Picon

Preliminary agenda for the IPCDN meeting in Atlanta

Here's the preliminary agenda for the IPCDN WG meeting in Atlanta.

IP over Cable Data Network WG (ipcdn)

Wednesday, November 20, at 1300-1500
====================================

CHAIRS: Richard Woundy <rwoundy <at> broadband.att.net>
        Jean-Francois Mule <jf.mule <at> cablelabs.com>

AGENDA:

I.   Agenda Bashing

II.  Administration/Re-chartering
      Re-charter progress
      Dropping DVB/Euromodem MIB efforts
      Adding CableHome MIB efforts
      Determining new WG item milestones
      WG handling of expired internet-drafts?

III. DOCSIS Submissions
      DOCSIS IGMP MIB
       Developing compliance statements: CM versus CMTS, active versus
passive modes
       Responding to other MIB doctor issues
      Subscriber Management MIB and Open Issues
       Using the Subscriber Management MIB in place of the Cable Device MIB?
       Responding to other MIB doctor issues
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raftus, David | 7 Nov 2002 13:25

RE: Preliminary agenda for the IPCDN meeting in Atlanta

Hi,

Regarding:
      DOCSIS 2.0 RFI MIB
       Channel utilization: percentages versus counters
       Ready to start WG last call?
       draft-ietf-ipcdn-docs-rfmibv2-05.txt (submitted?)

Not ready for last call, v2-05 not submitted. Cablelabs/vendor community has
not yet settled on appropriate wording/meaning for selected objects.

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:RWoundy <at> broadband.att.com]
Sent: Wednesday, November 06, 2002 7:19 PM
To: IPCDN (E-mail)
Cc: Jean-Francois Mule (E-mail); Woundy, Richard
Subject: [ipcdn] Preliminary agenda for the IPCDN meeting in Atlanta
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg White | 7 Nov 2002 18:20
Favicon

RE: RE: rf mib draft v5 - comment period end Friday Oct 2 5

Victor, 

To summarize, your suggestion is the following? 

Upstream Channel Utilization Index:
The upstream channel utilization index is expressed as a percentage of minislots utilized on the physical
channel, regardless of burst type.  For an Initial Maintenance region, the minislots for the complete
region are considered utilized if the CMTS received an upstream burst within the region from any CM on the
physical channel.  For contention REQ and REQ/DATA regions, the minislots for a transmission
opportunity within the region are considered utilized if the CMTS received an upstream burst within the
opportunity from any CM on the physical channel.  For all other regions, utilized minislots are those in
which the CMTS granted bandwidth to any unicast SID on the physical channel.

If that is what you intended, then I'm fine with that language.

Regarding your question 2, I guess that only applies to contention regions, so I would think that the most
common causes of a burst being received and not properly demodulated/decoded would be either initial
RNG-REQs that are either too faint or too strong, or collisions.  In either case, I don't have a strong
opinion, but counting all bursts, even those that fail HCS or CRC would seem to match the philosophy used
for UGS.  In other words, if it is preventing another CM from using those minislots, it should be counted.

-Greg

-----Original Message-----
From: Victor Hou [mailto:vhou <at> juniper.net]
Sent: Thursday, October 31, 2002 4:15 PM
To: Greg White; Raftus, David; DOCSIS 2.0 Majordomo List; DOCSIS OSS
Majordomo List; Ipcdn List (E-mail)
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg White | 7 Nov 2002 18:31
Favicon

RE: RE: rf mib draft v5 - comment period end Friday Oct 2 5

That text sounds fine to me.

Regarding George's suggestion to separate the upstream minislot counters to count granted minislots
separate from contention minislots, I haven't heard any comments.  This would mean four new objects in the
docsIfUpChannelTable (e.g. docsIfUpChannelTotalGrantedMinislots,
docsIfUpChannelUsedGrantedMinislots, docsIfUpChannelTotalContentionMinislots,
docsIfUpChannelUsedContentionMinislots).  Does anyone have any opinion or suggestions?

-Greg

-----Original Message-----
From: Kirk Friedman [mailto:kfriedman <at> correlant.com]
Sent: Friday, November 01, 2002 5:57 PM
To: 'George Hart'; 'Greg White'; Greg.Gohman <at> arrisi.com
Cc: 'Raftus, David'; 'DOCSIS 2.0 Majordomo List'; 'DOCSIS OSS Majordomo
List'; 'Ipcdn List (E-mail)'; 'Rich Woundy (Work) (E-mail)';
Tom.Cloonan <at> arrisi.com
Subject: RE: [ipcdn] RE: rf mib draft v5 - comment period end Friday Oct
2 5

I think George is right.  The description should be simpler for
docsIfDownChannelTotalBytes.  Otherwise it could get very confusing  For
example, the MPEG header/pointer fields are factored out, but not the
Reed-Soloman encoding on the downstream.  I'm also not sure how it applies
to NULL vs. DOCSIS PIDs.   Finally the OSS spec uses the raw downstream
rates for the ifTable (RFC 2233) ifSpeed MIB object. Simplify it to
docsIfDownChannelTotalBytes.  Suggest:

docsIfDownChannelTotalBytes OBJECT-TYPE
        SYNTAX      Counter64
(Continue reading)

Permalink | Reply | 27 comments |
headers
The IESG | 7 Nov 2002 21:11
Picon
Favicon

Note Well Statement


From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.
Permalink | Reply | 0 comments |

Gmane