From mailman-owner@ietf.org Fri Feb 1 05:43:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14117 for ; Fri, 1 Feb 2002 05:43:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27824 for ; Fri, 1 Feb 2002 05:43:41 -0500 (EST) Date: Fri, 1 Feb 2002 05:43:41 -0500 (EST) Message-Id: <200202011043.FAA27824@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ipcdn-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ipcdn-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipcdn-archive@lists.ietf.org: List Password // URL ---- -------- ipcdn@ietf.org BtQa https://www1.ietf.org/mailman/options/ipcdn/ipcdn-archive@lists.ietf.org From ipcdn-admin@ietf.org Sat Feb 2 19:03:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08956; Sat, 2 Feb 2002 19:03:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18847; Sat, 2 Feb 2002 19:02:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18823 for ; Sat, 2 Feb 2002 19:02:50 -0500 (EST) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08930 for ; Sat, 2 Feb 2002 19:02:44 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 132B567103 for ; Sat, 2 Feb 2002 19:18:32 -0500 (EST) Date: Sat, 2 Feb 2002 19:02:16 -0500 Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed From: RJ Atkinson To: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <48A1531C-1839-11D6-B91D-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Subject: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.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 Content-Transfer-Encoding: 7bit Rich, I have some possibly dumb questions about your draft and a more general question about the stuff here as it relates to stuff in the CableLabs' DOCSIS process. With luck, I'm just confused and you can clarify things for me. :-) 1) Revision date The current online version has text indicated "Expires: August 2001" but has a Fall date stamp at ftp.ietf.org/internet-drafts/. So I think maybe that draft really dates to Fall 2001. Correct ? Could you please update/fix the dates the next time you revise the draft (presumably before IETF/MSP) ?? Also, if the date inside the MODULE-IDENTITY clause could get updated that would be very helpful. 2) Relationship to DOCSIS specs/draft specs I'm assuming that your draft is in reasonably close sync with work coordinated at CableLabs on newer DOCSIS revisions than the REFERENCES section of the draft seems to list. True ? Which DOCSIS revisions are represented in your draft (e.g. 1.0, 1.1, 2.0, other) ?? Or maybe it would be simpler to ask whether the draft and the corresponding DOCSIS documents/drafts will be reasonably in sync as of IETF/MSP ? It would be helpful if your draft explicitly cited whichever newer DOCSIS drafts/specs/documents relate to it in the REFERENCES section, if there are any newer DOCSIS specs relating to the draft. 3) Security Considerations It would be helpful across the board (i.e. not just in your draft) if folks would explicitly note that SNMPv2c is just as insecure as SNMPv1 is. Folks generally do document this for SNMPv1. SNMP wizards know it is true for SNMPv2c, but there is a lot of confusion in the world about what SNMPv2c does/doesn't provide. Additional clarity would be very helpful and ought not require very many more words. More generally, not specific to this draft, some folks appear to think that DOCSIS specs and IETF IPCDN drafts aren't fully in sync on OID definitions and such like (for the OID branches that are within scope for IPCDN WG). I hope that is either confusion on those folks part or just a temporary lack of sync (e.g. because neither DOCSIS documents nor I-Ds/RFCs can be instantly updated) and that the end result will be full synchronisation of the DOCSIS documents' citation/definition of those OIDs and the set of documents in this WG. To me, it seems sensible to use the CableLabs fora as a kind of Design Team for any IPCDN MIBs relating to DOCSIS. If you could clarify reality in this respect, I'd be very greatly obliged. Thanks, Ran rja@extremenetworks.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Sat Feb 2 19:55:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08961 for ; Sat, 2 Feb 2002 19:03:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA18906 for ipcdn-archive@odin.ietf.org; Sat, 2 Feb 2002 19:03:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18847; Sat, 2 Feb 2002 19:02:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18823 for ; Sat, 2 Feb 2002 19:02:50 -0500 (EST) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08930 for ; Sat, 2 Feb 2002 19:02:44 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 132B567103 for ; Sat, 2 Feb 2002 19:18:32 -0500 (EST) Date: Sat, 2 Feb 2002 19:02:16 -0500 Mime-Version: 1.0 (Apple Message framework v480) Content-Type: text/plain; charset=US-ASCII; format=flowed From: RJ Atkinson To: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <48A1531C-1839-11D6-B91D-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.480) Content-Transfer-Encoding: 7bit Subject: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.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 Content-Transfer-Encoding: 7bit Rich, I have some possibly dumb questions about your draft and a more general question about the stuff here as it relates to stuff in the CableLabs' DOCSIS process. With luck, I'm just confused and you can clarify things for me. :-) 1) Revision date The current online version has text indicated "Expires: August 2001" but has a Fall date stamp at ftp.ietf.org/internet-drafts/. So I think maybe that draft really dates to Fall 2001. Correct ? Could you please update/fix the dates the next time you revise the draft (presumably before IETF/MSP) ?? Also, if the date inside the MODULE-IDENTITY clause could get updated that would be very helpful. 2) Relationship to DOCSIS specs/draft specs I'm assuming that your draft is in reasonably close sync with work coordinated at CableLabs on newer DOCSIS revisions than the REFERENCES section of the draft seems to list. True ? Which DOCSIS revisions are represented in your draft (e.g. 1.0, 1.1, 2.0, other) ?? Or maybe it would be simpler to ask whether the draft and the corresponding DOCSIS documents/drafts will be reasonably in sync as of IETF/MSP ? It would be helpful if your draft explicitly cited whichever newer DOCSIS drafts/specs/documents relate to it in the REFERENCES section, if there are any newer DOCSIS specs relating to the draft. 3) Security Considerations It would be helpful across the board (i.e. not just in your draft) if folks would explicitly note that SNMPv2c is just as insecure as SNMPv1 is. Folks generally do document this for SNMPv1. SNMP wizards know it is true for SNMPv2c, but there is a lot of confusion in the world about what SNMPv2c does/doesn't provide. Additional clarity would be very helpful and ought not require very many more words. More generally, not specific to this draft, some folks appear to think that DOCSIS specs and IETF IPCDN drafts aren't fully in sync on OID definitions and such like (for the OID branches that are within scope for IPCDN WG). I hope that is either confusion on those folks part or just a temporary lack of sync (e.g. because neither DOCSIS documents nor I-Ds/RFCs can be instantly updated) and that the end result will be full synchronisation of the DOCSIS documents' citation/definition of those OIDs and the set of documents in this WG. To me, it seems sensible to use the CableLabs fora as a kind of Design Team for any IPCDN MIBs relating to DOCSIS. If you could clarify reality in this respect, I'd be very greatly obliged. Thanks, Ran rja@extremenetworks.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Fri Feb 8 21:55:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00803 for ; Fri, 8 Feb 2002 21:55:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA19355 for ipcdn-archive@odin.ietf.org; Fri, 8 Feb 2002 21:55:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19318; Fri, 8 Feb 2002 21:54:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19290 for ; Fri, 8 Feb 2002 21:54:12 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00786 for ; Fri, 8 Feb 2002 21:54:09 -0500 (EST) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g192ruK23741; Fri, 8 Feb 2002 21:53:56 -0500 (EST) Received: from rwoundy-w2k.cisco.com (che-vpn2-7.cisco.com [10.86.244.7]) by goblet.cisco.com (Mirapoint) with ESMTP id AAR24884; Fri, 8 Feb 2002 21:53:39 -0500 (EST) Message-Id: <4.3.2.7.2.20020208163158.0171f008@goblet.cisco.com> X-Sender: rwoundy@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Feb 2002 16:38:11 -0500 To: docsis-macup@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Update on the DOCSIS DCI Suboption for the DHCP Relay Agent Information Option 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, The information in this email pertains to the following requirement in the DOCSIS 1.1 RFI, section 6.3.24: "The CMTS MUST retain the device class information for use in the DHCP Process. The CMTS MUST create a DHCP Agent Option 82 tuple with the device class information and MUST insert this tuple in the DHCPDISCOVER from the corresponding CM before forwarding that DHCPDISCOVER to the DHCP server." The DHCP DCI suboption draft is on the RFC editor's queue . The RFC editor's queue is the final step before RFC publication; by publication time, the draft's suboption code (currently "TBD" in sections 2 and 4 of the draft) must be replaced with an official number from IANA. I have recently received email from IANA that states that the suboption code has been assigned the value 4: At 02:20 PM 2/6/2002 -0800, IANA wrote: >Attn: Authors > >We are working on the IANA Actions for RFC-to-be >. > >We have assigned the value 4 to DOCSIS Device Class >Suboption. Please see the following to view the >assignment: > > > >Please let us know if this looks correct. After >we receive your response we will send a message to >the RFC-Editor to let them know that the IANA has >completed the IANA Actions for this document. > >Thank you for your time. > >Best regards, > >Michelle S. Cotton >IANA Administrator -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Feb 8 22:40:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00797; Fri, 8 Feb 2002 21:54:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19318; Fri, 8 Feb 2002 21:54:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19290 for ; Fri, 8 Feb 2002 21:54:12 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00786 for ; Fri, 8 Feb 2002 21:54:09 -0500 (EST) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g192ruK23741; Fri, 8 Feb 2002 21:53:56 -0500 (EST) Received: from rwoundy-w2k.cisco.com (che-vpn2-7.cisco.com [10.86.244.7]) by goblet.cisco.com (Mirapoint) with ESMTP id AAR24884; Fri, 8 Feb 2002 21:53:39 -0500 (EST) Message-Id: <4.3.2.7.2.20020208163158.0171f008@goblet.cisco.com> X-Sender: rwoundy@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Feb 2002 16:38:11 -0500 To: docsis-macup@cablelabs.com, docsis-oss@cablelabs.com, ipcdn@ietf.org From: Rich Woundy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] Update on the DOCSIS DCI Suboption for the DHCP Relay Agent Information Option 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, The information in this email pertains to the following requirement in the DOCSIS 1.1 RFI, section 6.3.24: "The CMTS MUST retain the device class information for use in the DHCP Process. The CMTS MUST create a DHCP Agent Option 82 tuple with the device class information and MUST insert this tuple in the DHCPDISCOVER from the corresponding CM before forwarding that DHCPDISCOVER to the DHCP server." The DHCP DCI suboption draft is on the RFC editor's queue . The RFC editor's queue is the final step before RFC publication; by publication time, the draft's suboption code (currently "TBD" in sections 2 and 4 of the draft) must be replaced with an official number from IANA. I have recently received email from IANA that states that the suboption code has been assigned the value 4: At 02:20 PM 2/6/2002 -0800, IANA wrote: >Attn: Authors > >We are working on the IANA Actions for RFC-to-be >. > >We have assigned the value 4 to DOCSIS Device Class >Suboption. Please see the following to view the >assignment: > > > >Please let us know if this looks correct. After >we receive your response we will send a message to >the RFC-Editor to let them know that the IANA has >completed the IANA Actions for this document. > >Thank you for your time. > >Best regards, > >Michelle S. Cotton >IANA Administrator -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Tue Feb 12 10:30:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15212 for ; Tue, 12 Feb 2002 10:30:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27384 for ipcdn-archive@odin.ietf.org; Tue, 12 Feb 2002 10:30:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27280; Tue, 12 Feb 2002 10:29:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27006 for ; Tue, 12 Feb 2002 10:21:34 -0500 (EST) Received: from titan.arrisi.com (client.arrisi.com [63.86.75.27] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14940 for ; Tue, 12 Feb 2002 10:21:30 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: docsis-oss@cablelabs.com, ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Tue, 12 Feb 2002 10:20:33 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.8 |June 18, 2001) at 02/12/2002 10:21:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] Docsis Subscriber Management MIB: proposed changes for -05 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 Several folks have pointed out problems with and ambiguities in the -04 draft of the subscriber management MIB. Described below are proposed changes that will go into the -05 draft, subject to the approval of the working group. Respectfully submitted, Wilson Sawyer ARRIS wsawyer@ieee.org ------------------------------------------------------------------------ Problem: The MIB is rooted at a temporary location; furthermore, its OID space has been renumbered between revisions, introducing conflicts with earlier revisions if not moved. Solution: re-home at { docsDev 5 } Problem: specifying ULP=ANY doesn't really create a sensible filter when paired with a TcpUdpFilterEntry. The semantics in that case would be something like: match if neither TCP nor UDP, or if TcpUdpFilterEntry matches. It strains the imagination to invent a good use for such behavior. Solution: Ignore TcpUdpFilterEntry when ULP=ANY. This brings this mib in line with RFC-2669. Textually, the description of docsSubMgtPktFilterUlp changes to: docsSubMgtPktFilterUlp OBJECT-TYPE SYNTAX Integer32 (0..256) MAX-ACCESS read-create STATUS current DESCRIPTION "Upper level protocol to match. If this value is 256, matches ALL ULP values. Otherwise, this matches the specific protocol value. Note that if the packet ULP is either 6 (tcp) or 17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be consulted (if its entry exists) to see if this entry matches. If this value is neither tcp(6) nor udp(17), then that table is not consulted." DEFVAL { 256 } ::= { docsSubMgtPktFilterEntry 11 } Problem: docsSubMgtCpeControlMaxCpeIp is defined as Integer32(0..1024), while the corresponding provisioning object is a 10-bit field, implying a range of 0..1023. Solution: Change the definition of docsSubMgtCpeControlMaxCpeIp to be Integer32(0..1023). [ed: normally per 2578 this would require an OID change, but we are changing all OIDs in this mib as it's re-rooted anyway.] Problem: It may not be clear that docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream are really meant to control an aspect of CPE behavior, in the sense in which CPE is meant by, say, docsSubMgtCpeControlActive. (These items exist not to control modem behavior per se, but to control the ways in which the modem, or its MAC identity, could be suborned to acquire unauthorized services for a subscriber host.) Solution: Change the description of docsSubMgtCmFilterEntry to be: docsSubMgtCmFilterEntry OBJECT-TYPE SYNTAX DocsSubMgtCmFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Binds a filter group to each direction of traffic for a modem. The filters in this entry apply if docsSubMgtCpeControlActive is true." AUGMENTS { docsIfCmtsCmStatusEntry } ::= {docsSubMgtCmFilterTable 1 } _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Feb 12 11:26:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15206; Tue, 12 Feb 2002 10:29:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27280; Tue, 12 Feb 2002 10:29:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27006 for ; Tue, 12 Feb 2002 10:21:34 -0500 (EST) Received: from titan.arrisi.com (client.arrisi.com [63.86.75.27] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14940 for ; Tue, 12 Feb 2002 10:21:30 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: docsis-oss@cablelabs.com, ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Tue, 12 Feb 2002 10:20:33 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.8 |June 18, 2001) at 02/12/2002 10:21:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] Docsis Subscriber Management MIB: proposed changes for -05 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 Several folks have pointed out problems with and ambiguities in the -04 draft of the subscriber management MIB. Described below are proposed changes that will go into the -05 draft, subject to the approval of the working group. Respectfully submitted, Wilson Sawyer ARRIS wsawyer@ieee.org ------------------------------------------------------------------------ Problem: The MIB is rooted at a temporary location; furthermore, its OID space has been renumbered between revisions, introducing conflicts with earlier revisions if not moved. Solution: re-home at { docsDev 5 } Problem: specifying ULP=ANY doesn't really create a sensible filter when paired with a TcpUdpFilterEntry. The semantics in that case would be something like: match if neither TCP nor UDP, or if TcpUdpFilterEntry matches. It strains the imagination to invent a good use for such behavior. Solution: Ignore TcpUdpFilterEntry when ULP=ANY. This brings this mib in line with RFC-2669. Textually, the description of docsSubMgtPktFilterUlp changes to: docsSubMgtPktFilterUlp OBJECT-TYPE SYNTAX Integer32 (0..256) MAX-ACCESS read-create STATUS current DESCRIPTION "Upper level protocol to match. If this value is 256, matches ALL ULP values. Otherwise, this matches the specific protocol value. Note that if the packet ULP is either 6 (tcp) or 17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be consulted (if its entry exists) to see if this entry matches. If this value is neither tcp(6) nor udp(17), then that table is not consulted." DEFVAL { 256 } ::= { docsSubMgtPktFilterEntry 11 } Problem: docsSubMgtCpeControlMaxCpeIp is defined as Integer32(0..1024), while the corresponding provisioning object is a 10-bit field, implying a range of 0..1023. Solution: Change the definition of docsSubMgtCpeControlMaxCpeIp to be Integer32(0..1023). [ed: normally per 2578 this would require an OID change, but we are changing all OIDs in this mib as it's re-rooted anyway.] Problem: It may not be clear that docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream are really meant to control an aspect of CPE behavior, in the sense in which CPE is meant by, say, docsSubMgtCpeControlActive. (These items exist not to control modem behavior per se, but to control the ways in which the modem, or its MAC identity, could be suborned to acquire unauthorized services for a subscriber host.) Solution: Change the description of docsSubMgtCmFilterEntry to be: docsSubMgtCmFilterEntry OBJECT-TYPE SYNTAX DocsSubMgtCmFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Binds a filter group to each direction of traffic for a modem. The filters in this entry apply if docsSubMgtCpeControlActive is true." AUGMENTS { docsIfCmtsCmStatusEntry } ::= {docsSubMgtCmFilterTable 1 } _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Tue Feb 12 21:18:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03741 for ; Tue, 12 Feb 2002 21:18:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA26789 for ipcdn-archive@odin.ietf.org; Tue, 12 Feb 2002 21:18:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26746; Tue, 12 Feb 2002 21:18:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17505 for ; Tue, 12 Feb 2002 17:19:49 -0500 (EST) Received: from tab.pbc.com (pbc-67.pbc.com [63.207.108.67] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29308 for ; Tue, 12 Feb 2002 17:19:45 -0500 (EST) Received: from himalaya.juniper.net (himalaya.juniper.net [172.17.37.182]) by tab.pbc.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25220; Tue, 12 Feb 2002 14:19:16 -0800 (PST) Received: by himalaya.juniper.net with Internet Mail Service (5.5.2650.21) id <1SL3JPCW>; Tue, 12 Feb 2002 14:18:47 -0800 Message-ID: <8104DBB8386FD411B8A600D0B76FEAFEFDA2E0@himalaya.juniper.net> From: Norbert Juffa To: "'Wilson.Sawyer@arrisi.com'" , docsis-oss@cablelabs.com, ipcdn@ietf.org Date: Tue, 12 Feb 2002 14:18:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: Docsis Subscriber Management MIB: proposed changes for -05 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 [...] > Problem: It may not be clear that docsSubMgtCmFilterDownstream and > docsSubMgtCmFilterUpstream are really meant to control an aspect of > CPE behavior, in the sense in which CPE is meant by, say, > docsSubMgtCpeControlActive. (These items exist not to control > modem behavior per se, but to control the ways in which the modem, > or its MAC identity, could be suborned to acquire > unauthorized services > for a subscriber host.) > > Solution: Change the description of docsSubMgtCmFilterEntry to be: > > docsSubMgtCmFilterEntry OBJECT-TYPE > SYNTAX DocsSubMgtCmFilterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Binds a filter group to each direction of traffic for a > modem. The filters in this entry apply if > docsSubMgtCpeControlActive > is true." > AUGMENTS { docsIfCmtsCmStatusEntry } > ::= {docsSubMgtCmFilterTable 1 } This looks like a very important clarification to me. My previous understanding was that docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream are applied independent of the state of docsSubMgtCpeControlActive, i.e. the filters in these groups are always applied. Apparently this understanding was incorrect. If I understand this change correctly, it says that the application of docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream is conditional dependening on the state of docsSubMgtCpeControlActive. In other words, if docsSubMgtCpeControlActive is FALSE, none of the filters in docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream apply. Is my understanding correct now? -- Norbert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Feb 12 22:11:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03736; Tue, 12 Feb 2002 21:18:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26746; Tue, 12 Feb 2002 21:18:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17505 for ; Tue, 12 Feb 2002 17:19:49 -0500 (EST) Received: from tab.pbc.com (pbc-67.pbc.com [63.207.108.67] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29308 for ; Tue, 12 Feb 2002 17:19:45 -0500 (EST) Received: from himalaya.juniper.net (himalaya.juniper.net [172.17.37.182]) by tab.pbc.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25220; Tue, 12 Feb 2002 14:19:16 -0800 (PST) Received: by himalaya.juniper.net with Internet Mail Service (5.5.2650.21) id <1SL3JPCW>; Tue, 12 Feb 2002 14:18:47 -0800 Message-ID: <8104DBB8386FD411B8A600D0B76FEAFEFDA2E0@himalaya.juniper.net> From: Norbert Juffa To: "'Wilson.Sawyer@arrisi.com'" , docsis-oss@cablelabs.com, ipcdn@ietf.org Date: Tue, 12 Feb 2002 14:18:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: Docsis Subscriber Management MIB: proposed changes for -05 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 [...] > Problem: It may not be clear that docsSubMgtCmFilterDownstream and > docsSubMgtCmFilterUpstream are really meant to control an aspect of > CPE behavior, in the sense in which CPE is meant by, say, > docsSubMgtCpeControlActive. (These items exist not to control > modem behavior per se, but to control the ways in which the modem, > or its MAC identity, could be suborned to acquire > unauthorized services > for a subscriber host.) > > Solution: Change the description of docsSubMgtCmFilterEntry to be: > > docsSubMgtCmFilterEntry OBJECT-TYPE > SYNTAX DocsSubMgtCmFilterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Binds a filter group to each direction of traffic for a > modem. The filters in this entry apply if > docsSubMgtCpeControlActive > is true." > AUGMENTS { docsIfCmtsCmStatusEntry } > ::= {docsSubMgtCmFilterTable 1 } This looks like a very important clarification to me. My previous understanding was that docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream are applied independent of the state of docsSubMgtCpeControlActive, i.e. the filters in these groups are always applied. Apparently this understanding was incorrect. If I understand this change correctly, it says that the application of docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream is conditional dependening on the state of docsSubMgtCpeControlActive. In other words, if docsSubMgtCpeControlActive is FALSE, none of the filters in docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream apply. Is my understanding correct now? -- Norbert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Feb 14 08:42:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17782; Thu, 14 Feb 2002 08:42:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28529; Thu, 14 Feb 2002 08:41:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27670 for ; Thu, 14 Feb 2002 08:26:21 -0500 (EST) Received: from titan.arrisi.com (client.arrisi.com [63.86.75.190] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17440 for ; Thu, 14 Feb 2002 08:26:17 -0500 (EST) From: Wilson.Sawyer@arrisi.com Subject: Re: [ipcdn] RE: Docsis Subscriber Management MIB: proposed changes for -05 To: Norbert Juffa Cc: docsis-oss@cablelabs.com, ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Thu, 14 Feb 2002 08:26:18 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.8 |June 18, 2001) at 02/14/2002 08:26:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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 Yes, that is correct. - Wilson Norbert Juffa , m> docsis-oss@cablelabs.com, ipcdn@ietf.org Sent by: cc: ipcdn-admin@ie Fax to: tf.org Subject: [ipcdn] RE: Docsis Subscriber Management MIB: proposed changes for -05 02/12/02 05:18 PM [...] > Problem: It may not be clear that docsSubMgtCmFilterDownstream and > docsSubMgtCmFilterUpstream are really meant to control an aspect of > CPE behavior, in the sense in which CPE is meant by, say, > docsSubMgtCpeControlActive. (These items exist not to control > modem behavior per se, but to control the ways in which the modem, > or its MAC identity, could be suborned to acquire > unauthorized services > for a subscriber host.) > > Solution: Change the description of docsSubMgtCmFilterEntry to be: > > docsSubMgtCmFilterEntry OBJECT-TYPE > SYNTAX DocsSubMgtCmFilterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Binds a filter group to each direction of traffic for a > modem. The filters in this entry apply if > docsSubMgtCpeControlActive > is true." > AUGMENTS { docsIfCmtsCmStatusEntry } > ::= {docsSubMgtCmFilterTable 1 } This looks like a very important clarification to me. My previous understanding was that docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream are applied independent of the state of docsSubMgtCpeControlActive, i.e. the filters in these groups are always applied. Apparently this understanding was incorrect. If I understand this change correctly, it says that the application of docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream is conditional dependening on the state of docsSubMgtCpeControlActive. In other words, if docsSubMgtCpeControlActive is FALSE, none of the filters in docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream apply. Is my understanding correct now? -- Norbert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Thu Feb 14 08:42:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17791 for ; Thu, 14 Feb 2002 08:42:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28601 for ipcdn-archive@odin.ietf.org; Thu, 14 Feb 2002 08:42:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28529; Thu, 14 Feb 2002 08:41:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27670 for ; Thu, 14 Feb 2002 08:26:21 -0500 (EST) Received: from titan.arrisi.com (client.arrisi.com [63.86.75.190] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17440 for ; Thu, 14 Feb 2002 08:26:17 -0500 (EST) From: Wilson.Sawyer@arrisi.com Subject: Re: [ipcdn] RE: Docsis Subscriber Management MIB: proposed changes for -05 To: Norbert Juffa Cc: docsis-oss@cablelabs.com, ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Thu, 14 Feb 2002 08:26:18 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.8 |June 18, 2001) at 02/14/2002 08:26:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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 Yes, that is correct. - Wilson Norbert Juffa , m> docsis-oss@cablelabs.com, ipcdn@ietf.org Sent by: cc: ipcdn-admin@ie Fax to: tf.org Subject: [ipcdn] RE: Docsis Subscriber Management MIB: proposed changes for -05 02/12/02 05:18 PM [...] > Problem: It may not be clear that docsSubMgtCmFilterDownstream and > docsSubMgtCmFilterUpstream are really meant to control an aspect of > CPE behavior, in the sense in which CPE is meant by, say, > docsSubMgtCpeControlActive. (These items exist not to control > modem behavior per se, but to control the ways in which the modem, > or its MAC identity, could be suborned to acquire > unauthorized services > for a subscriber host.) > > Solution: Change the description of docsSubMgtCmFilterEntry to be: > > docsSubMgtCmFilterEntry OBJECT-TYPE > SYNTAX DocsSubMgtCmFilterEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Binds a filter group to each direction of traffic for a > modem. The filters in this entry apply if > docsSubMgtCpeControlActive > is true." > AUGMENTS { docsIfCmtsCmStatusEntry } > ::= {docsSubMgtCmFilterTable 1 } This looks like a very important clarification to me. My previous understanding was that docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream are applied independent of the state of docsSubMgtCpeControlActive, i.e. the filters in these groups are always applied. Apparently this understanding was incorrect. If I understand this change correctly, it says that the application of docsSubMgtCmFilterDownstream and docsSubMgtCmFilterUpstream is conditional dependening on the state of docsSubMgtCpeControlActive. In other words, if docsSubMgtCpeControlActive is FALSE, none of the filters in docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream apply. Is my understanding correct now? -- Norbert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From owner-ipcdn@terayon.com Thu Feb 21 08:10:03 2002 Received: from terayon.com (mails.terayon.com [63.201.251.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15918 for ; Thu, 21 Feb 2002 08:10:02 -0500 (EST) Received: (from root@localhost) by terayon.com (8.9.3+Sun/8.9.3) id DAA01906 for ipcdn-outgoing; Thu, 21 Feb 2002 03:44:45 -0800 (PST) Message-ID: <005601c1bacc$b7b6f4c0$1901a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPoW ' 02 (the IP over WDM international conference) Date: Thu, 21 Feb 2002 12:41:35 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01C1BAD5.18D38400" 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_0053_01C1BAD5.18D38400 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IPoW ' 02 (the IP over WDM international conference), will take place in = Paris, France, from June 25 to 28, 2002. All details at: http://www.upperside.fr/ipow01/ipow2001intro.htm ------=_NextPart_000_0053_01C1BAD5.18D38400 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
IPoW ' 02 (the IP over WDM = international=20 conference), will take place in Paris, France, from June 25 to 28, = 2002.
All=20 details at:
http://www.uppe= rside.fr/ipow01/ipow2001intro.htm
 
------=_NextPart_000_0053_01C1BAD5.18D38400-- From daemon@ns.ietf.org Thu Feb 28 04:17:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15191 for ; Thu, 28 Feb 2002 04:17:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15518 for ipcdn-archive@odin.ietf.org; Thu, 28 Feb 2002 04:17:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15453; Thu, 28 Feb 2002 04:16:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15422 for ; Thu, 28 Feb 2002 04:16:26 -0500 (EST) Received: from huksweep.eu.hns.com (mail.eu.hns.com [193.129.245.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15115 for ; Thu, 28 Feb 2002 04:16:21 -0500 (EST) Received: from pegasus.eu.hns.com (unverified) by huksweep.eu.hns.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 28 Feb 2002 09:16:43 +0000 To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: A.Valentine@eu.hns.com Date: Thu, 28 Feb 2002 09:16:21 +0000 X-MIMETrack: Serialize by Router on PEGASUS/HNSEU(Release 5.0.7 |March 21, 2001) at 28/02/2002 09:17:57, Serialize complete at 28/02/2002 09:17:57 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ipcdn] Good-bye :-( 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 Hi, Sadly, I will be stepping down as co-chair of the IPCDN WG. Due to recent events with my current employer (redundancies) I will be starting at a new company next week. This means I will not be able to continue with the IPCDN and also the IETF for the forseeable future :-( It has been a great pleasure working with you all and I wish you all the best of luck with the work you are currently undertaking and in future. Have fun andrew -- Andrew Valentine Senior Systems Architect UK Engineering Design Centre Hughes Network Systems Ltd. Linford Wood , Saxon Street, Milton Keynes MK14 6LD, United Kingdom Tel : Direct +44 1908 326 233 Tel Main +44 1908 221122 x 233 Fax : +44 1908 221127 Email: A.Valentine@eu.hns.com #********************************************************************** This message is intended solely for the use of the individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Hughes Network Systems Limited, including its European subsidiaries and affiliates. Hughes Network Systems Limited, including its European subsidiaries and affiliates accepts no responsibility for loss or damage arising from its use, including damage from virus. #********************************************************************** _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Feb 28 05:13:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15186; Thu, 28 Feb 2002 04:17:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15453; Thu, 28 Feb 2002 04:16:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15422 for ; Thu, 28 Feb 2002 04:16:26 -0500 (EST) Received: from huksweep.eu.hns.com (mail.eu.hns.com [193.129.245.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15115 for ; Thu, 28 Feb 2002 04:16:21 -0500 (EST) Received: from pegasus.eu.hns.com (unverified) by huksweep.eu.hns.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 28 Feb 2002 09:16:43 +0000 To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: A.Valentine@eu.hns.com Date: Thu, 28 Feb 2002 09:16:21 +0000 X-MIMETrack: Serialize by Router on PEGASUS/HNSEU(Release 5.0.7 |March 21, 2001) at 28/02/2002 09:17:57, Serialize complete at 28/02/2002 09:17:57 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [ipcdn] Good-bye :-( 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 Hi, Sadly, I will be stepping down as co-chair of the IPCDN WG. Due to recent events with my current employer (redundancies) I will be starting at a new company next week. This means I will not be able to continue with the IPCDN and also the IETF for the forseeable future :-( It has been a great pleasure working with you all and I wish you all the best of luck with the work you are currently undertaking and in future. Have fun andrew -- Andrew Valentine Senior Systems Architect UK Engineering Design Centre Hughes Network Systems Ltd. Linford Wood , Saxon Street, Milton Keynes MK14 6LD, United Kingdom Tel : Direct +44 1908 326 233 Tel Main +44 1908 221122 x 233 Fax : +44 1908 221127 Email: A.Valentine@eu.hns.com #********************************************************************** This message is intended solely for the use of the individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Hughes Network Systems Limited, including its European subsidiaries and affiliates. Hughes Network Systems Limited, including its European subsidiaries and affiliates accepts no responsibility for loss or damage arising from its use, including damage from virus. #********************************************************************** _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn