Subject: [ipcdn] IPCDN meeting minutes from San Francisco

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 2 Apr 2003 16:15:44 -0700

Folks,

Could you review and comment on the following IPCDN meeting minutes from the
March IETF meeting by close of business Thursday? Thanks.

-- Rich

IETF IPCDN Meeting
San Francisco, CA USA
March 19, 2003

Reported by Greg Nakanishi ([email-masked])
Edited by Rich Woundy ([email-masked])

WG Meeting Summary
------------------

Approximately twelve attendees of the IP over Cable Data Networks WG met
at the San Francisco IETF on March 19, 2003. The WG discussed the status
of its work items: five drafts for DOCSIS MIBs, three drafts for
PacketCable/IPCablecom, and six drafts for CableHome. The results of the
February 2003 interim meeting in Louisville, CO were also discussed.
Total meeting time was a little more than one hour.

The "DOCSIS Subscriber Management MIB" completed MIB doctor review,
although the use of DSCP value and mask objects needs to be resolved.
The "Application of the IGMP MIB to DOCSIS 1.1" needs to be rewritten
with a MIB compliance statement; this draft will be brought back to the
WG. Twenty-two submissions for thirteen distinct internet-drafts have
been posted since the previous IETF meeting in Atlanta. The WG also
launched a website for additional information, <http://www.ipcdn.org/>.

This was the first time the WG used jabber text conferencing during its
meeting. There were two remote jabber participants (not counted in the
twelve participants above), and a third jabber participant joined after
the meeting ended.

Interim Meeting
---------------

Rich Woundy reviewed the discussion from the February interim meeting.
At the interim meeting, eighteen attendees reviewed IPCDN MIBs for about
six hours. The BPI+ MIB and DOCSIS QoS MIB were reviewed in depth,
four more DOCSIS MIBs were briefly reviewed, the DOCSIS Set-Top Gateway
MIB was briefly discussed, and the CableHome MIBs were presented. The
minutes have been posted to the IETF and www.ipcdn.org websites.

Review of DOCSIS MIBs
---------------------

Rich Woundy presented a list of the most current versions of the DOCSIS
MIBs. Greg Nakanishi asked for the timeframe(s) to have all of the
draft updates as a result of the interim meeting. Jean-Francois Mule
responded that the timeframe depended on the draft.

There were a number of technical comments on the BPI+ MIB draft -08 at
the interim meeting. The BPI+ MIB draft -09 is work-in-progress at the
moment. The goal is to post the next draft with all comments resolved
prior to June.

The Cable Device MIB draft -04 was briefly discussed at the interim
meeting, which resulted in the posting of draft -05. The latest draft
has significant revisions to the compliance statements (separated for
CM and CMTS), has new filtering tables for IPv4/IPv6 filtering, Dscp
marking, and IPv4/IPv6 CPE control, and has deleted all VACM extension
objects. This draft requires careful WG review.

At this point, Rich raised the debate about the use of the DiffServ
MIB and its applicability to Cable Device IPv4/IPv6 filtering, and to
the packet classification tables in the DOCSIS QoS and Subscriber
Management MIBs. Rich found the DiffServ MIB to have powerful features
for packet classification, queuing and scheduling, although for
adoption into cable might require simplications via MIB compliance
statements. One difficulty in adopting the DiffServ MIB is that its
Data Path table differentiates between interfaces but not between
groups of devices (e.g. cable modems) on a single interface -- unlike
the Subscriber Management MIB. An additional issue may be the potential
"partial" use of the DiffServ MIB for cable interfaces, but the
"complete" use of the DiffServ MIB for other interfaces on a CMTS.

The Event Notification MIB draft -03 was briefly discussed at the
interim meeting. A timeframe for publication of draft -04 needs to be
determined, and the draft requires careful WG review.

The DOCSIS 2.0 RFI MIB draft -05 was briefly discussed at the
interim meeting, which resulted in the posting of draft -06. The name
of the MIB module needs to be changed from DOCS-IETF-RFI-MIB back to
DOCS-IF-MIB (the slide incorrectly indicated it should be changed to
DOCS-RFI-MIB); both this draft and the cable device MIB draft need to
retain the module names of RFC 2670 and RFC 2669, respectively.  This
draft requires careful WG review.

Minnie Lu raised an issue about the RFI MIB objects
docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets, asking why
they do not include packets from DOCSIS 1.1 or 2.0 modems after
registration -- according to the DOCSIS QoS MIB. This issue will be
(re-)raised and discussed on the mailing list.

The DOCSIS QoS MIB draft -07 was discussed in-depth at the interim
meeting, which resulted in the posting of draft -08. One remaining issue
is the MIB's use of IP ToS instead of DSCP. Rich's opinion was that the
MIB should reflect what is in the DOCSIS specifications, and in the
case of packet classification for DOCSIS QoS, DOCSIS clearly uses
the older notion of the IP ToS byte.

The DOCSIS Subscriber Management MIB draft -08 was briefly discussed at
the interim meeting, where Bert Wijnen indicated his MIB doctor
approval. However, two draft revisions were made after the interim
meeting to resolve issues raised in different MIB reviews. Draft -09
changed the module name from DOCS-SUBMGT-MIB to DOCS-IETF-SUBMGT-MIB, to
reduce potential confusion between the CableLabs and IETF versions.
Draft -10 replaced the TosValue and TosMask objects with DscpValue and
DscpMask objects. The current controversy is whether to keep the
DscpMask object, over the objections of the IETF DiffServ WG, or just
drop this new object.

Rich led a discussion comparing the progress of the DiffServ WG in
parallel with the development of DOCSIS 1.1 and the IPCDN WG. DSCP
is replacing IP ToS in the Cable Device and Subscriber Management MIBs;
the DOCSIS QoS MIB is retaining the concept of the IP ToS byte. In the
meantime, folks in CableLabs are looking at how the DOCSIS protocols
and specifications can be made DiffServ-friendly.

Greg Nakanishi asked which operators are using DiffServ today. Cox
appears to be a key cable operator using DiffServ. Someone in the
meeting asked what happens if the DscpMask object is dropped, and
what are the impacts to the underlying DOCSIS layer two protocols. Rich
replied that the WG co-chairs are going back to the operators to
understand how they have been using DiffServ, and whether dropping the
DscpMask object would cause operational difficulties.

Review of PacketCable/IPCablecom MIBs
-------------------------------------

Jean-Francois Mule reviewed the progress on the PacketCable/IPCablecom
MIBs. Jean-Francois pointed out that he and Rich are seeing the same
mistakes and issues in multiple MIBs under review of the IPCDN WG. The
chairs may start asking for peer reviews on draft MIBs within our WG;
that is, authors may be requested to review other authors' MIBs.

There were a number of technical and editorial comments reviewed for
the PacketCable/IPCablecom MTA MIB, based on email sent to the mailing
list. One issue is the use of a "TFTP URL" for downloading an MTA
configuration file -- the IETF draft defining the TFTP URI scheme has
been queued for AD approval for almost a year, presumably due to the
lack of adequate security in the TFTP protocol. One participant
suggested that we don't expose the fact that we are using TFTP for
configuration file downloads, to avoid the IETF controversy about using
TFTP.

Similarly, the WG reviewed comments for the PacketCable/IPCablecom
Signaling MIB, based on another email sent to the mailing list. One
issue is that AVT profiles are defined in RFC 1890 (and the recent
internet-draft update draft-ietf-avt-profile-new-13.txt), but this MIB 
uses its own naming convention. Another issue is the residual references
to the DCS protocol (SIP-based), even though PacketCable/IPCablecom uses
the NCS protocol (MGCP-based). A third issue is a needed clarification
as to when the MTA performs DNS resolution, e.g. at boot-time, or upon
receipt of an RSIP (ReStartInProgress) NCS message. This third issue
prompted a number of questions and comments on DNS responses. Rich
pointed out that some CMS vendors might support server cluster failover
by returning multiple IP addresses in a single DNS "A" resource record;
the presence of an IP address in the "A" record might imply that the CMS
believes that the server with that IP address is alive, and the
ordering of IP addresses in the "A" record might indicate relative
server processing load (lighter-loaded servers are listed before heavier
-loaded servers).

[Editor's note: The original slides included the following comment on
the Signaling MIB: "Use InetAddress dns type for
pktcNcsEndPntConfigCallAgentId". This comment was removed, because the
CallAgentId as defined by NCS/MGCP includes more than the DNS FQDN, e.g.
"[email-masked]".]

Finally, the WG reviewed comments for the PacketCable/IPCablecom
Management Event MIB. The InetAddress objects in this MIB must link to
the appropriate InetAddressType objects (the slides incorrectly
indicated the opposite linkage, from InetAddressType objects to
InetAddress objects). Another issue is the lack of alignment of logging
severity levels between the Management Event MIB and the SYSLOG MIB. The
consensus of the meeting attendees is to align PacketCable/IPCablecom
event logging severity levels with DOCSIS/CableHome event logging
severity levels, which are already aligned with the SYSLOG MIB. Azlina
volunteered to review the Management Event MIB; other volunteers are
sought to ensure quality MIB reviews in the WG.

Greg Nakanishi asked whether all PacketCable/IPCablecom MIB names should
be changed using the same naming convention adopted for the DOCSIS MIBs,
to prevent confusion between CableLabs and IETF versions. The attendees
and co-chairs agreed with this proposal. This implies the following MIB
module name changes: PKTC-IETF-MTA-MIB for the MTA MIB,
PKTC-IETF-SIG-MIB for the Signaling MIB, and PKTC-IETF-EVENT-MIB for the
Event Management MIB.

The expectation is that the PacketCable/IPCablecom MIBs will be revised
in the next month or so after the San Francisco IETF meeting (target of
mid-April). The co-chairs will want to issue WG last-calls as soon as
the MIBs are updated and ready for review.

Review of CableHome MIBs
------------------------

New co-authors have signed up to edit and review the CableHome MIBs.
The authors represent CableLabs, YAS corporation, and four CableHome
vendors (Ashley Laurent, Linksys, Motorola, and TI). As a result, the
WG co-chairs believe that the IPCDN WG should accept the CableHome MIBs
as part of the IPCDN charter.

There is some overlap between the DHCPv4 Server MIB and the CableHome
Gateway Configuration MIB. The DHCPv4 Server MIB has been recently
revised, and as soon as it reaches WG last call in the DHC WG, the
appropriate CableHome authors will need to resolve the overlap.

No objections to accepting the CableHome MIBs were received from the
IPCDN mailing list, nor from the IETF meeting participants. The co-
chairs will add them to the WG charter.

Miscellaneous Items
-------------------

There was an expectation that the IPCDN WG would discuss the DOCSIS
Set-Top Gateway (DSG) MIB at the San Francisco IETF meeting. This agenda
item was cancelled due to lack of preparation by interested parties.
By default, the WG is deferring any decision about whether to accept
this MIB as one of its work items.

The chairs reminded the IPCDN authors that they are insisting on more
frequent draft updates than in the past. They are also requesting that
participants review the MIBs of this WG -- in addition to a new request
for MIB authors to participate in peer reviews of each others' work.

Greg White (jabber participant) requested a timeline for getting the
DOCSIS MIBs from internet-draft status to RFC, for coordination with
CableLabs standardization efforts.

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

---

From: "Stephen Palm" <[email-masked]>
Date: Wed, 02 Apr 2003 15:36:04 -0800

> Review of CableHome MIBs
[...]
> chairs will add them to the WG charter.

Some of the CableHome MIBs may point to material that might
not be publically available.  In that light, what
is the scope and timeline for CableHome MIBs?

regards, kiwin

-- 
Stephen [kiwin] Palm   Ph.D.                         E:  [email-masked]
Principal Engineer                                   T: +1-949-926-PALM
Epigram/Broadcom Home Networking Division            F: +1-530-325-9798
Irvine, California                              W: http://www.kiwin.com
     Secondary email accounts:     [email-masked]     [email-masked]
     [email-masked]   [email-masked]     [email-masked]