From ipcdn-admin@ietf.org Sun Apr 1 21:07:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09749; Sun, 1 Apr 2001 21:07:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00548; Sun, 1 Apr 2001 21:01:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19641 for ; Fri, 30 Mar 2001 18:11:51 -0500 (EST) Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19513 for ; Fri, 30 Mar 2001 18:11:52 -0500 (EST) Received: from smplsft.com (sudhir.vip.best.com [206.86.7.159]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id PAA24773; Fri, 30 Mar 2001 15:09:41 -0800 (PST) Message-ID: <3AC4A2DF.CABA8500@smplsft.com> Date: Fri, 30 Mar 2001 23:14:39 +0000 From: Sudhir Pendse Organization: SIMPLESOFT Inc. X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "White, David" CC: "'Kaz Ozawa'" , IETF Ipcdn , DOCSIS OSS Mailing List , DOCSIS Security Mailing List , Steve Malenfant , "'Loukianov, Dmitrii'" References: <5E1D5067851CD411BC900090270F79D03DF861@cadant1.cadant.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Re: Max Length of X509Certificate in BPI+ MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Dave, I believe the historical reason for the < 1500 byte limit in SNMP comes from the argument that when the network is very congested, you still want SNMP packets to go through. If the SNMP packets are large and they become fragmented and put in multiple ethernet frames, then the chances of them going through are lesser than if the entire SNMP packet fit into one ethernet frame. Infact in the SNMPv1 spec (RFC1157) the minimum mandatory message length to be supported is 484. (RFC1157) ... 4. Protocol Specification ..... .................. An implementation of this protocol need not accept messages whose length exceeds 484 octets. However, it is recommended that implementations support larger datagrams whenever feasible. A similar logic is reflected in the SNMPv2 (RFC1905) specs... (RFC 1905) ..... 2.5. Message Sizes The maximum size of a SNMPv2 message is limited to the minimum of: (1) the maximum message size which the destination SNMPv2 entity can accept; and, (2) the maximum message size which the source SNMPv2 entity can generate. The former may be known on a per-recipient basis; and in the absence of such knowledge, is indicated by transport domain used when sending the message. The latter is imposed by implementation-specific local constraints. Each transport mapping for the SNMPv2 indicates the minimum message size which a SNMPv2 implementation must be able to produce or consume. Although implementations are encouraged to support larger values whenever possible, a conformant implementation must never generate messages larger than allowed by the receiving SNMPv2 entity. One of the aims of the GetBulkRequest-PDU, specified in this protocol, is to minimize the number of protocol exchanges required to retrieve a large amount of management information. As such, this PDU type allows a SNMPv2 entity acting in a manager role to request that the response be as large as possible given the constraints on message sizes. These constraints include the limits on the size of messages which the SNMPv2 entity acting in an agent role can generate, and the SNMPv2 entity acting in a manager role can receive. However, it is possible that such maximum sized messages may be larger than the Path MTU of the path across the network traversed by the messages. In this situation, such messages are subject to fragmentation. Fragmentation is generally considered to be harmful [4], since among other problems, it leads to a decrease in the reliability of the transfer of the messages. Thus, a SNMPv2 entity which sends a GetBulkRequest-PDU must take care to set its parameters accordingly, so as to reduce the risk of fragmentation. In particular, under conditions of network stress, only small values should be used for max-repetitions. 2.6. Transport Mappings It is important to note that the exchange of SNMPv2 messages requires only an unreliable datagram service, with every message being entirely and independently contained in a single transport datagram. Specific transport mappings and encoding rules are specified elsewhere [5]. However, the preferred mapping is the use of the User Datagram Protocol [6]. The transport mapping document (RFC 1906) has this to say about SNMP over UDP... (RFC 1906) 3. SNMPv2 over UDP ...... When an SNMPv2 entity uses this transport mapping, it must be capable of accepting messages that are at least 484 octets in size. Implementation of larger values is encouraged whenever possible. In SNMPv3 to make things easier, the SNMPv3 header itself has the msgMaxSize which gives an indication of how large a response the requester can handle... (RFC 2572) 6.3. msgMaxSize The msgMaxSize field of the message conveys the maximum message size supported by the sender of the message, i.e., the maximum message size that the sender can accept when another SNMP engine sends an SNMP message (be it a response or any other message) to the sender of this message on the transport in use for this message. When an SNMP message is being generated, the msgMaxSize is provided by the SNMP engine which generates the message. At the receiving SNMP engine, the msgMaxSize is used to determine the maximum message size the sender can accommodate. As you can see from above, the message size is a function of what each entity can accept. To be compliant with the protocol each side at the bare minimum only needs to support 484 byte messages (if using UDP transport). Now in reality, most applications support more than 484 byte messages. What that number is, grows with the overall industry requirements or general consensus. Up until now, it used to be around 1500. With the increase in reliability of networks and need to make the data transfer more efficient, the 1500 number will slowly grow also. SimpleSoft's tools will be changed to support the new consensus. It is probably just ignoring the larger size responses today, although I doubt if it crashes. But management entities supporting a smaller MTU than 1500 can hardly be deemed "broken". In a heterogenous world, to ensure interoperability, one has to atleast consider being able to exchange information with others how might be "buffer size challenged". Kind Regards, -sudhir "White, David" wrote: > > Kaz, > I believe the motivation for trimming the size of X.509 certs > is so that SNMP response PDUs do not cause certain SNMP agent tester > tools to crash. I believe the root of the problem lies neither in the > DOCSIS spec., nor in SNMP, nor in any other standard. The problem is > that the SNMP agent tester tools and/or managers have assumed the > maximum sized SNMP GetResponse will be 1500 bytes, not including the > MAC header. > Cadant has asked SimpleSoft to fix this exact bug. I'm assuming > that fixing the UCD bug would involve going into the source code > (which is freely available) and upping their receive buffer size to > something more appropriate of dynamically allocating a buffer based > upon the number of bytes received from the UDP layer. > UDP has a maximum size of 64k, so 1487 is no problem for UDP. > Ethernet (not to be confused with 802.3) has an MTU of 1500 bytes. > IEEE 802.2/802.3 CSMA/CD has an MTU of 1492. The smallest and > most common IPv4 header is 20 bytes. UDP has a header of 8 bytes. > > sizeof(Ethernet MTU) > - sizeof(smallest IPv4 header) > - sizeof(UDP header) > ---------------------------------- > = max_sizeof(proposed new X.509 cert) > > 1500 > - 20 > - 8 > ---- > = 1472 > > However, this does not even include the SNMP header, whether it be > v1, v2c, or v3. So, 1472 still won't work. > If DOCSIS must bend over backwards to work around known bugs in > SNMP agent tester tools and/or managers, then I propose we decrease the > size of X.509 certs to 800 bytes, even though it still won't solve the > problem in all cases. A single GetBulk of just 2 X.509 certs of 800 bytes > each would still be around 1700 bytes, which would still cause certain > tools and/or managers to crash. > > David White > dave@cadant.com > > -----Original Message----- > From: Kaz Ozawa [mailto:kaz@pobox.com] > Sent: Friday, March 30, 2001 9:07 AM > To: IETF Ipcdn; DOCSIS OSS Mailing List; DOCSIS Security Mailing List > Cc: Steve Malenfant; 'Loukianov, Dmitrii' > Subject: RE: Max Length of X509Certificate in BPI+ MIB > > I would like to hear more feedback to make sure the following points. > (1) 1487 octets, the current maximum length of X509Certificate in > BPI+ MIB cannot fit in the single UDP packet. > (2) If we change the maximum length from 1487 octets to 1472 octets, > it fits in the single UDP packet. > (3) If the long MIB data is spited into two UDP packets, CMTS/CM > vendors need to implement extra protocol to handle the special case > in which the order of two UDP packets is switched or one of them is > missed. (Dmitrii's point) > (4) The new maximum length 1472 octets is enough for DOCSIS Certificates. > If all of the above points are correct, we should change the maximum > length to 1472 octets. > I will very much appreciate your review and feedback. > > Thanks, > kaz > > > -----Original Message----- > > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > > Steve Malenfant > > Sent: Monday, March 26, 2001 11:06 AM > > To: 'Loukianov, Dmitrii'; 'Kaz Ozawa'; IETF Ipcdn; DOCSIS OSS Mailing > > List; DOCSIS Security Mailing List > > Subject: [ipcdn] RE: Max Length of X509Certificate in BPI+ MIB > > > > > > The current Test Docsis Root CA that we have signed with 2048 bits doesn't > > go up to 1000 bytes... So other certificates shouldn't be > > bigger, except if > > you fill out your organization name with 200 caracters... > > > > It will also depends on the MTU size of the CM... > > > > Steve > > Com21 > > > > -----Original Message----- > > From: Loukianov, Dmitrii [mailto:dmitrii.loukianov@intel.com] > > Sent: Monday, March 26, 2001 10:24 AM > > To: 'Kaz Ozawa'; IETF Ipcdn; DOCSIS OSS Mailing List; DOCSIS Security > > Mailing List > > Subject: RE: Max Length of X509Certificate in BPI+ MIB > > > > > > Ooops! SNMP works on top of UDP protocol, which does not > > guarantee that the > > packets > > will arrive in the order sent. Having the packet split in two will require > > modification of the SNMP protocol internals, including out-of-order packet > > delivery. > > > > Therefore it is necessary to reduce the maximum size to fit into > > one single PDU, or split certificate into two independent MIBs > > (not a great > > idea). > > > > Dmitrii Loukianov, > > Intel. > > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Saturday, March 24, 2001 7:55 PM > > To: IETF Ipcdn; DOCSIS OSS Mailing List; DOCSIS Security Mailing List > > Subject: Max Length of X509Certificate in BPI+ MIB > > > > > > The BPI+ MIB draft-ietf-ipcdn-bpiplus-mib-03.txt specifies as follows. > > > > > -- Textual conventions > > > > > > X509Certificate ::= TEXTUAL-CONVENTION > > > STATUS current > > > DESCRIPTION > > > "An X509 digital certificate encoded as an ASN.1 DER > > > object." > > > SYNTAX OCTET STRING (SIZE (0..1487)) > > > > 1487 octets is the maximum length of the DER encoded digital > > certificate which fits the Auth Request message and Auth Reply > > message. > > > > Recently, we realized that there are very few SNMP tools which > > (stably) supports this maximum length. Most of the BPI+ MIB > > objects with this X509Certificate syntax are very important for > > both testing and operation. Therefore, we need to request the > > SNMP tool suppliers to support this long string. > > > > By the way, I heard that the MIB command with 1473 octets or > > longer string does not fit the single PDU and will be divided > > into two PDU. Therefore, changing the maximum length from 1487 > > octets to 1472 octets could help the SNMP tool suppliers to > > support the maximum length earlier. I would like to hear any > > opinion on the possibility of this change. > > > > Thanks, > > kaz > > > > Kaz Ozawa > > Toshiba Visiting Engineer at CableLabs > > (303) 661-3860 (direct); -9199 (fax) > > kaz@pobox.com / k.ozawa@cablelabs.com > > -- Sudhir Pendse Tel: (650) 965-4515 SIMPLESOFT Inc. Fax: (650) 965-4505 http://www.smplsft.com Email: spendse@smplsft.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From owner-ipcdn@terayon.com Mon Apr 2 15:59:41 2001 Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27992 for ; Mon, 2 Apr 2001 15:59:40 -0400 (EDT) Received: (from root@localhost) by terayon.com (8.9.3+Sun/8.9.3) id IAA24204 for ipcdn-outgoing; Mon, 2 Apr 2001 08:59:37 -0700 (PDT) Message-ID: <007401c0bb8d$fbb80d60$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPoW ' 01 (IP over DWDM) Date: Mon, 2 Apr 2001 18:00:04 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C0BB9E.BECB5F40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipcdn@terayon.com Precedence: bulk Reply-To: ipcdn@terayon.com This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C0BB9E.BECB5F40 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 Which granularity for all optical networks?=20 Synchronous or asynchronous optical networks?=20 Which model for the optical network: overlay or peer-to-peer?=20 How to integrate DWDM systems into MPL(ambda)S ?=20 IPoW ' 01 (IP over DWDM), will take place in Paris, France, from October = 9 to 12, 2001.=20 The call for proposals dead line has been extended to April 23rd. http://www.upperside.fr/ipow01/ipow2001intro.htm ------=_NextPart_000_0071_01C0BB9E.BECB5F40 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
Which granularity for all optical networks? =
Synchronous or=20 asynchronous optical networks?
Which model for the optical network: = overlay=20 or peer-to-peer?
How to integrate DWDM systems into MPL(ambda)S ? =
IPoW ' 01 (IP over DWDM), will take place = in Paris,=20 France, from October 9 to 12, 2001.=20
The call for proposals dead line has been extended = to=20 April 23rd.
http://www.uppe= rside.fr/ipow01/ipow2001intro.htm
 
------=_NextPart_000_0071_01C0BB9E.BECB5F40-- From ipcdn-admin@ietf.org Wed Apr 4 07:31:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14307; Wed, 4 Apr 2001 07:31:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09076; Wed, 4 Apr 2001 07:27:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09052 for ; Wed, 4 Apr 2001 07:27:13 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13897; Wed, 4 Apr 2001 07:27:12 -0400 (EDT) Message-Id: <200104041127.HAA13897@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 04 Apr 2001 07:27:12 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-dvbdev-mib-00.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : DVB Cable Interactive Network Adapter Device MIB Author(s) : J. Pedersen Filename : draft-ietf-ipcdn-dvbdev-mib-00.txt Pages : 50 Date : 03-Apr-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of a DVB Interactive Network Adapter device. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-dvbdev-mib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-dvbdev-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-dvbdev-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010403124157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-dvbdev-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-dvbdev-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010403124157.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Apr 4 07:33:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14351; Wed, 4 Apr 2001 07:33:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09118; Wed, 4 Apr 2001 07:27:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09089 for ; Wed, 4 Apr 2001 07:27:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13914; Wed, 4 Apr 2001 07:27:17 -0400 (EDT) Message-Id: <200104041127.HAA13914@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 04 Apr 2001 07:27:17 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-dvbinaif-mib-00.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : DVB Cable Interactive Network Adapter Interface MIB Author(s) : J. Pedersen Filename : draft-ietf-ipcdn-dvbinaif-mib-00.txt Pages : 103 Date : 03-Apr-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of a cable interface of a DVB Interactive Network Adapter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-dvbinaif-mib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-dvbinaif-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-dvbinaif-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010403124206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-dvbinaif-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-dvbinaif-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010403124206.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Sun Apr 8 22:04:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14456; Sun, 8 Apr 2001 22:04:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06748; Sun, 8 Apr 2001 22:03:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06729 for ; Sun, 8 Apr 2001 22:03:23 -0400 (EDT) Received: from funnel.cisco.com ([161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14440 for ; Sun, 8 Apr 2001 22:03:22 -0400 (EDT) Received: from rwoundy-w2k.cisco.com (ch-janeiro-p30.cisco.com [171.69.209.234]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA17695 for ; Sun, 8 Apr 2001 22:02:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20010408213739.01a53948@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 08 Apr 2001 22:03:49 -0400 To: ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] IPCDN powerpoint slides from Minneapolis Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, Below are the powerpoint slides from the IPCDN WG meeting in Minneapolis held on March 19, 2001. Some of the slides that were created or modified since the last email on this subject (last announcement of the WG agenda on March 18) are marked with an '*'. Thanks again to all authors that produced these slides. I will submit these slides to the IETF folks for permanent archival. -- Rich WG Status and Charter Revision (*) EuroModem NIU Device and Interface MIBs EuroModem INA Device and Interface MIBs DOCSIS Application of RFC 2933 MIB Subscriber Management MIB DOCSIS Notifications RFC 2669 and 2670 Updates (*) TCP Port Filtering Issues (*) _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Sun Apr 8 22:17:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14536; Sun, 8 Apr 2001 22:17:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06707; Sun, 8 Apr 2001 22:03:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06683 for ; Sun, 8 Apr 2001 22:03:03 -0400 (EDT) Received: from funnel.cisco.com ([161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14438 for ; Sun, 8 Apr 2001 22:03:02 -0400 (EDT) Received: from rwoundy-w2k.cisco.com (ch-janeiro-p30.cisco.com [171.69.209.234]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA17686 for ; Sun, 8 Apr 2001 22:02:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20010408212703.01a383a0@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 08 Apr 2001 22:03:27 -0400 To: ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] IPCDN meeting minutes from Minneapolis Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Folks, Below are the current meeting minutes from the IPCDN WG meeting in Minneapolis held on March 19, 2001. Thanks to Pak Siripunkaw for collecting this information! Please send any corrections of the minutes to myself and the mailing list by Wednesday, April 11, since I need to submit these minutes to the IETF folks for permanent archival very soon. -- Rich IETF IPCDN Meeting Minneapolis, MN March 19, 2001 Reported by Pak Siripunkaw (psiripunkaw@broadband.att.com) WG Meeting Summary ------------------ Approximately 35 members of the IP over Cable Data Networks WG met at the Minneapolis IETF on March 19, 2001. The WG discussed the status of most of its work items as well as the ongoing charter revision. The WG also discussed the common problems with respect to TCP port filtering and matching that exist in many of the WG documents. Since the last IETF meeting, the WG submitted two new internet-drafts (not including two drafts that missed the submission deadline but were posted to the mailing list), and six updates to existing internet-drafts. WG Status and Charter Revision (Richard Woundy) ----------------------------------------------- Richard Woundy discussed the overall status of work items in the working group. The BPI MIB has been published as RFC 3083, the Euromodem/DVB NIU MIB is in WG last-call, and the DOCSIS QoS MIB and Application of the IGMP MIB (RFC 2933) to DOCSIS Devices are about to start WG last-call. It is unclear whether the Application of the IGMP MIB is implemented in a DOCSIS device yet. The MIB is required to be implemented for DOCSIS 1.1 certification, though. A presentation for the DOCSIS QoS MIB was not available for the meeting, but the WG consensus appeared to be in favor of bringing this document to WG last-call. There has been little progress on the proposed Account Management Control MIB since the last WG meeting. The WG may want to re-evaluate this project as a work item, possibly dropping it. The next IPCDN meeting is sometime during the week of August 5-10 in London, and a number of work items need to be completed by that time. The co-chairs have been formulating and proposing significant changes to the WG charter, to update the description (add text about DOCSIS 1.1 and Euromodem), modify work items, and revamp the overall schedule. The charter is currently under evaluation by our Area Directors. EuroModem NIU Device and Interface MIBs (slides by Andrew Valentine) -------------------------------------------------------------------- Richard Woundy presented slides from Andrew Valentine, which discuss the Euromodem NIU Device MIB version -03 -- currently in WG last-call. Richard Woundy has submitted editorial comments to the author. Andrew plans to collect all comments from the last-call period, issue draft -04, republish with a one week review time, and submit to the IESG as a standards track specification. The WG raised no technical objections with the draft at this meeting. Andrew also has submitted the first version of the Euromodem NIU Interface MIB, which organizes DVB-specific interface management objects into MAC layer, RF downstream, and RF upstream groups. There are some analogies between this MIB and RFC 2670, particularly in the handling of the interface layering model. EuroModem INA Device and Interface MIBs (slides by Andrew Valentine) -------------------------------------------------------------------- Richard Woundy presented slides from Jens Pedersen, which discuss the first versions of the Euromodem INA Interface MIB and the Euromodem INA Device MIB. The INA Interface MIB defines DVB-specific interface management objects for MAC layer, RF downstream, RF upstream, and NIU provisioning and management. The INA Device MIB defines optional object groups for management of general device control, network management access, software images, DHCP relay configuration, event handling and logging, Ethernet and IP filters, and NIU IP address and subnet controls. DOCSIS Application of RFC 2933 MIB (slides by Howard Abramson) -------------------------------------------------------------- Richard Woundy presented slides from Howard Abramson, which discuss changes in version -02 of the DOCSIS Application of the IGMP MIB. In this version, the author clarifies "interface robustness" for the CM HFC interface (i.e. it controls the number of retransmissions of Unsolicited Membership Reports in the absence of a response), emphasizes that igmpCacheIfIndex is a table index, and clarifies the behavior of the "IGMP cache" when a row is deleted (i.e. the row may be recreated upon receipt of a new IGMP Membership Report). The WG raised no technical objections with the draft at this meeting. Subscriber Management MIB (slides by Wilson Sawyer) --------------------------------------------------- Richard Woundy presented slides from Wilson Sawyer, which discuss changes in version -03 of the Subscriber Management MIB, as well as justification for its current form. The major change in version -03 is alignment of the MIB with RFC 2851 for Internet address-related objects; the specification also takes care not to mandate IPv6 capability for MIB compliance. In the last WG meeting, some folks voiced their concerns about the implementation complexity of this MIB. Wilson provides three justifications for the current MIB content: (1) multiple vendors are implementing this MIB (which suggests the MIB is implementable), (2) CableLabs requires implementation of this MIB for DOCSIS 1.1 certification, and (3) the filtering functionality and source address verification are needed for the protection of the cable network. The WG expressed confusion about the OID for the base of the Subscriber Management MIB subtree. While "{ experimental 83 4 }" is the current OID, the current text suggests that the OID would be modified to "{ docsDev 4 }". Unfortunately, Mike StJohns already assigned this OID to docsDevConformanceV2 in the RFC 2669 update. The WG co-chairs will assign a new OID for the Subscriber Management MIB -- in all likelihood, "{ docsDev 5 }". Some WG members have sent technical issues to the author and/or the mailing list, which should be resolved. One technical issue, concerning TCP traffic filtering and IP fragmentation, was discussed separately since it broadly applies to a number of WG specifications (see below). DOCSIS Notifications (slides by Junming Gao) -------------------------------------------- Richard Woundy presented slides from Junming Gao, which discuss changes in version -01 of the DOCSIS Notification MIB. In this version, the author adheres to RFC 2576 by adding "0" to key OID prefixes, adds trap control objects, adds a reference to the event throttling control of RFC 2669, and modifies some object names for clarity. The WG discussed whether the event throttling mechanism of RFC 2669 applied to events not defined in this internet draft. The WG agreed that the mechanism also applies to generic SNMP traps such as linkUp and linkDown. RFC 2669 and 2670 Updates (Richard Woundy) ------------------------------------------ Richard Woundy presented slides which discuss the latest updates to the DOCSIS Cable Device MIB and the DOCSIS RFI MIB (RFCs 2669 and 2670). In version -01 of the update to RFC 2669, the author aligns the MIB with RFC 2851 for most Internet address-related objects, adds an object to support the DOCSIS Application of RFC 2933 MIB, and adds references to the Event Notification and Subscriber Management MIBs. Future work includes aligning this MIB with the DOCSIS QoS MIB and the DOCSIS OSSI specification, choosing one mechanism to support multiple CPE-side interfaces on a CM (DOCSIS OSSI approach versus InterfaceSet objects), clarifying the handling of generic traps, and fixing issues with the docsDevNmAccessTable. In the first version of the update to RFC 2670, the author aligns Internet address-related object with RFC 2851, modifies objects and compliances for EuroDOCSIS and European cable plant characteristics, clarifies object descriptions for objects with the BITS syntax, and fixes other object definition errors. Future work includes aligning this MIB with the DOCSIS Notification MIB (i.e. adding objects from IF-EXT-MIB), clarifying the upstream channel transmit timing offset, and aligning with the most recent version of the Interfaces Group MIB, RFC 2863. The WG felt that generic traps (e.g. linkUp and linkDown) should be included in the RFC 2669 throttling control. A WG member suggested that the WG determine the extent of the overlap between the RFC 2669 event log and RFC 3014, "Notification Log MIB". A WG member suggested that RFC 2669 may need more objects for maximum CPE limits. One object might indicate how many CPE devices the CM can support in firmware; another object might indicate the maximum number of CPE devices that should be allowed to communicate across the cable network by operator configuration. A WG member pointed out that the docsDevEvReporting object uses the BITS syntax, which needs to be clarified (i.e. bit-ordering) in the description. A WG member pointed out that slide 8 made reference to RFC 2683, a typo for RFC 2863. This is corrected in the powerpoint slides submitted to the IETF. A WG member notes that the Interfaces Group MIB, RFC 2863, now has a companion specification, The Inverted Stack Table Extension to the Interfaces Group MIB, RFC 2864. The author agreed to investigate the impact on RFC 2670. Pak Siripunkaw agreed to help Rich reconcile the RFC 2670 update with the DOCSIS OSSI. TCP Port Filtering Issues (Richard Woundy) ------------------------------------------ Richard Woundy presented slides on potential issues with TCP port filtering and matching in various WG work items. RFC 1858 describes problems related to IP fragmentation and TCP port filtering, and some implementation workarounds. Richard recommends that cable device implementations performing TCP/UDP port filtering should ignore non-initial IP fragments, but should drop all TCP fragments with offset 1, to prevent tiny-gram and port-overwrite attacks. Richard also recommends that cable device implementations performing TCP port matching (e.g. DOCSIS QoS MIB) should not match non-initial IP fragments, and applications requiring special handling should use Path MTU Discovery (RFC 1191). The WG agreed that this is a problem that needs to be fixed immediately. After the WG session, a WG member pointed out that RFC 1858 offers another workaround for TCP port filtering: a forwarding device can reassemble the IP fragments before applying the port filters and forwarding the datagram. His suggestion was to allow this implementation workaround as an alternative. _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Apr 10 10:52:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17204; Tue, 10 Apr 2001 10:51:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22594; Tue, 10 Apr 2001 10:33:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22573 for ; Tue, 10 Apr 2001 10:33:23 -0400 (EDT) Received: from funnel.cisco.com ([161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16585 for ; Tue, 10 Apr 2001 10:33:20 -0400 (EDT) Received: from rwoundy-w2k.cisco.com (dhcp-161-44-149-239.cisco.com [161.44.149.239]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA14377; Tue, 10 Apr 2001 10:32:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20010410100801.01a490c0@funnel.cisco.com> X-Sender: rwoundy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Apr 2001 10:33:46 -0400 To: "Nakanishi, Greg" From: Rich Woundy Cc: ipcdn@ietf.org In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE203BD76E3@ntas0027.gi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Re: Question on RFC 3083 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org At 08:53 PM 4/9/2001 -0400, Nakanishi, Greg wrote: >Rich, > >I noticed that in RFC 3083, the value start(1) for object docsBpiCmAuthState >has been deleted. > >Was this intentional? Is it because start(1) is not a real state? > >thanks, greg No, this was an editing mistake between the final internet-draft version and the RFC version of the BPI MIB. The object definition should still be: docsBpiCmAuthState OBJECT-TYPE SYNTAX INTEGER { start(1), authWait(2), authorized(3), reauthWait(4), authRejectWait(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object is the state of the CM authorization FSM. The start state indicates that FSM is in its initial state." REFERENCE "DOCSIS Baseline Privacy Interface Specification, Section 4.1.2.1." ::= { docsBpiCmBaseEntry 3 } We have to figure out how to work around this problem. See for one short term approach -- I'll submit a bugfix. We might also need to add text in the DOCSIS OSSI (at the same time it makes reference to 3083), and may need to reissue RFC 3083 as a new RFC with the fix. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn