Subject: Fwd: Minutes for IPCDN - 47th IETF

From: "Mike St. Johns" <[email-masked]>
Date: Mon, 10 Apr 2000 00:02:00 -0700

The following was submitted as the minutes for the IPCDN meeting at the 
IETF in Adelaide.  Slides will be available with the proceedings.

Mike

>Date: Wed, 29 Mar 2000 23:15:31 -0800
>To: [email-masked]
>From: "Mike St. Johns" <[email-masked]>
>Subject: Minutes for IPCDN - 47th IETF
>Cc: [email-masked], [email-masked]
>
>Working group:  IP Over Cable Data Networks (IPCDN)
>Chair:  Michael StJohns, Excite@Home
>
>
>The working group met for about 90 minutes to review current work and to 
>resolve some issues related to the current standards track MIBs.
>
>The chair presented the proposed changes to RFC2669 and 2670 to bring them 
>into compliance with IPv6 and SNMPv3 requirements (see the attached 
>presentation).  The working group has an action item to nominate specific 
>objects within the RF Interface MIB to become Counter64 by the end of next 
>week.  The revisions will be posted as IDs within the next week after that.
>
>The chair proxied for Wilson Sawyer of Arris and presented a description 
>of the intent of the new subscriber management MIB.  A new version has 
>been submitted to the ID editor and will go through WG last call two weeks 
>after its published.  The chair will ask the area director to assign a MIB 
>doctor as part of the standards submission process.
>
>Rich Woundy discussed the current status of the BPI (Baseline Privacy) 
>MIB.  After discussion, the working group agreed this should be submitted 
>as Informational/Historical as it documents a branch no longer being 
>developed, but which has been implemented.  The BPI+ MIB has been 
>submitted as an internet draft and will be put through the WG last call 
>process within the next 3 weeks.
>
>At the last meeting, Rich and Andrew Valentine agreed to go off and 
>evaluate whether or not the EuroModem MIBs and the IPCDN MIBs could be 
>harmonized.  Rich and Andrew presented their results and a discussion of 
>possible approches for harmonization. The working group agreed to accept 
>the EuroModem MIBs as work items and Andrew will resubmit the current IDs 
>as draft-ietf-ipcdn-... documents.  The chair will submit a revised 
>charter within the next month which covers the EuroModem work.
>
>Rich gave a brief presentation on some work he's done in DHCP for third 
>parties to verify MAC/IP bindings.  This work will not be added to the WGs 
>table, but will be submitted to the DHCP WG or area for advancement.  The 
>WG will monitor the work and its applicability on CMs, but does not expect 
>an major effects on the WG's work.
>
>The chair led a brief discussion of other items on the charter.  The Telco 
>Return MIB was submitted several years ago, but was allowed to lapse due 
>to lack of interest or implementation desire.  Due to the renewed 
>interest, as well as more experience with Telco Return, the author will 
>resubmit the ID for WG discussion and possible adoption as a work 
>item.  The QOS  MIB is current, but there's been a lack of discussion or 
>interest in the MIB.  The chair will try and rekindle discussion on the 
>MIB or drive it to closure or removal from consideration depending on WG 
>consensus.
>

---

From: apalmer <[email-masked]>
Date: Wed, 19 Apr 2000 15:24:51 -0700

Mike,
   Since we are cleaning up the mibs :),   I would like to propose that we
enhance the RFC2670 to
include the requirements from EuroDOCSIS.

Here are the two additional enhancements that were suggested:

1) New interleave:

docsIfDownChannelInterleave OBJECT-TYPE
        SYNTAX      INTEGER {
            unknown(1),
            other(2),
            taps8Increment16(3),
            taps16Increment8(4),
            taps32Increment4(5),
            taps64Increment2(6),
            taps128Increment1(7),
            taps12increment17(8)
        }
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
            "The Forward Error Correction (FEC) interleaving used
             for this downstream channel.
             Values are defined as follows:
             taps8Increment16(3):   protection 5.9/4.1 usec,
                                    latency .22/.15 msec
             taps16Increment8(4):   protection 12/8.2 usec,
                                    latency .48/.33 msec
             taps32Increment4(5):   protection 24/16 usec,
                                    latency .98/.68 msec
             taps64Increment2(6):   protection 47/33 usec,
                                    latency 2/1.4 msec
             taps128Increment1(7):  protection 95/66 usec,
                                    latency 4/2.8 msec
             taps12increment17(8):  protection 18/14 usec,
                                    latency 0.43/0.32 msec
             If the interface is down, this object either returns
             the configured value (CMTS), the most current value
             (CM), or the value of unknown(1).
             The value of other(2) is returned if the interleave
             is known but not defined in the above list.
             See the associated conformance object for write
             conditions and limitations. See the reference for the
             FEC
             configuration described by the setting of this object."
        REFERENCE
            "DOCSIS Radio Frequency Interface Specification,
             Section 4.3.2."
        ::= { docsIfDownstreamChannelEntry 5 }

2.2 docsIfDownChannelAnnex

This object is implemented to differ for the different implementations of the
downstream.

docsIfDownChannelAnnex OBJECT-TYPE
        SYNTAX      INTEGER {
            unknown(1),
            other(2),
            annexA(3),
            annexB(4),
            annexC(5),
         }
        MAX-ACCESS  read-only

Thanks,
Azlina