From mailman-owner@ietf.org Thu Aug 1 05:50:06 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 FAA15769 for ; Thu, 1 Aug 2002 05:50:06 -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 FAA22424 for ; Thu, 1 Aug 2002 05:51:15 -0400 (EDT) Date: Thu, 1 Aug 2002 05:51:15 -0400 (EDT) Message-Id: <200208010951.FAA22424@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. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** 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 Thu Aug 15 10:15:49 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 KAA27135 for ; Thu, 15 Aug 2002 10:15:49 -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 KAA01490; Thu, 15 Aug 2002 10:16:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29867 for ; Wed, 14 Aug 2002 09:47:55 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08929 for ; Wed, 14 Aug 2002 09:46:34 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7EDlMY21716 for ; Wed, 14 Aug 2002 09:47:22 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Aug 2002 15:47:21 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: howard_abramson@adc.com, ipcdn@ietf.org Cc: "'Thomas Narten'" , "'Erik Nordmark'" , "Bert Wijnen (E-mail)" , "Bill Fenner (E-mail)" , "Dave Thaler (E-mail)" Date: Wed, 14 Aug 2002 15:47:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] MIB Docotor review of: draft-ietf-ipcdn-igmp-mib-04.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 First, I am copy-ing Bill and Dave because - The document is basically about IGMP applicability for DOCSIS - Bill is main author/editor for IGMPv2 (RFC2236) - Dave is co-author of IGMP MIB (RFC2933) It seems that Bill and Dave (or one of the other IGMP MIB authors) should take a look at this too. Or maybe the IDMR WG should look at it. Comments based on my own quick review: 1. This is mostly about IGMP applicability in DOCSIS environment. The applicability/required-conformance is expressed in terms of values in MIB objects in the IGMP MIB. That is sort of weird. I would rather assume that the MIB (when queried) returns the values as they actually exist. 2. For exmaple (and this is just one example), sect 4.1.1.2 regarding the igmpInterfaceQueryInterval. Passive Mode ------------ HFC-side: n/a, read-only. The CM MUST not transmit queries upstream. Return a value of zero. This seems wrong to me. If the object is implemented and accessible, then the agent MUST return the proper/actual value. I think what you want to say is that the HFC side should NOT/NEVER transmit IGMP Host Query packets. if so, then pls say so. It may mean that this MIB object therefor will have a value of zero, and that is fine. But the requirement (I think) is that the HFC side does not transmit packets at any time. CMCI-side: read only . This value is derived based on the interval of queries received from an upstream querier. This seems wrong too. At least it does not agree with the DESCRIPTION clause of the object in the igmp MIB 3. Another example (again an example) is section 4.1.1.1 on igmpInterfaceIfIndex: The ifIndex value of the interface for which IGMP is enabled. All Modes / Both sides: same for passive and active modes. HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV MAC Layer CMCI-side: not-accessible. ifIndex of CMCI-Side interface. These objects are INDEX objects (and as you say not accessible). So if anything, then maybe what you are saying is that the MIB should only contain instances (rows/entries) for interfaces that are of ifType 127 on the HFC side. Not sure I understand what you are saying for CMCI side (actually I am sure I do not understand). 4. Yet another example: 4.1.1.3 igmpInterfaceStatus The activation of a row enables IGMP on the interface. The destruction of a row disables IGMP on the interface. Sofar it is a repeat of what IGMP MIB already says. Seems useless. All Modes / Both sides: MUST be enabled on both interfaces for all DOCSIS 1.1 CM interfaces. Well, the value for the object then is 'active'. But I think what you are basically saying is that Bother sides MUST support IGMP on all their CM interfaces. Again, the instance of the MIB on a device should just relfect the actual situation, no matter if that is compliant with your spec or not. 5. As a last example: 4.1.1.4 igmpInterfaceVersion The version of IGMP which is running on this interface. All Modes / Both sides: MUST be version 2 for all DOCSIS 1.1 CM interfaces. I think what you are saying that DOCSIS devices MUST implement IGMPv2 for all of their CM interfaces. Again, the MIB, when queried MUST report the actual situation. It seems to me, before we go into more detail on these sort of things that we need to agree on how to specify your IGMP requirements for DOCSIS devices. But it seems to me that it is not appropriate to do so in the form of expected MIB object values. Additional comments: 6. sect 4.3.1.2 and sect 4.3.2.3 seem duplicates? 7. sect 4.3.2.5 and sect 4.3.2.6 seem not to be represented in the compliance statements in sect 4.3.1 8. When we get to section 4.3, maybe what you are trying to do is to tell DOCSIS device manufacturers that they do not have to implement the complete IGMP MIB on all devices. So what you may want to do is to specify special compliance statements. That seems a good idea. To do so, you should enclose them in a real MIB-MODULE (it can just contain the complaince statements). It would look aka: DOCS-IGMP-MIB-COMPLIANCES DEFINITIONS BEGIN IMPORT ... docsIgmpMibCompliancesMIB MODULE-IDENTITY .... docsIgmpV2PassiveDeviceCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Devices passively running IGMPv2 and implementing the IGMP MIB." MODULE IGMP-STD-MIB MANDATORY-GROUPS { igmpBaseMIBGroup, igmpRouterMIBGroup, igmpV2RouterMIBGroup } OBJECT igmpInterfaceStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= {docsIgmpMIBCompliances 1} ... END Note that the way I specify read-only for igmpInterfaceStatus is also different from what you had done. I think my way is the correct (or at least better) way. I know that the IGMP MIB has it the same as you have. In fact you have exactly the same compliance statement. If that is what you want, then you just tell people that they must implement igmpV2RouterMIBCompliance. 9. An additional comment is, that if you allow igmpInterfaceStatus to be read-only, then I think you have to allow all objects in that table to be read-only, or maybe read-write. If you do not allow read-create access to a RowStatus object, then new rows cannot be created, and so none of the objects should then allow read-create access. 10. This applies equally well to the igmpCacheStatus object/rows of course. 11. If you allow for some people to do a read-write and others to do a read-only implementation, then I prefer to see 2 compliance statements. The Diffserv MIB (RFC3289) is a good example on how to do it. so you would have a xxxxMIBFullCompliance that does NOT allow for read-only xxxxMIBReadOnlyCompliance that does allow for the read-only implementations 12. You are also proposing a new object in the docsis device MIB. I do not understand why you do that, you have a revision of that MIB being worked on in the WG, so you can just refer to that new MIB and talk about the new object that you need. 13. And it then seems to me that you want to include that object in the COMPLIANCE statements that we talked about above. So you import a new group from the docsis device MIB and include it in the compliance statement(s) above. 14. By the way, you cannot add objects to an existing group. That could break the compliance that some people have claimed already. So you must define a new group, aka docsdevbaseGroup2. It could either just contain that one new objects, or it could contain the old list of objects plus the new object. Additional non-technical comments: 15. Acronyms used in Title and Abstract 16. References not split in normative/informative 17. references used in abstract section 18. a lot of RFC2119 language used while this is informational. for the first 15/16/17, see: http://www.rfc-editor.org/policy.html Bert AD for Network Management side of OPS Area _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Thu Aug 15 10:15:49 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 KAA27144 for ; Thu, 15 Aug 2002 10:15:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01567 for ipcdn-archive@odin.ietf.org; Thu, 15 Aug 2002 10:17:08 -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 KAA01490; Thu, 15 Aug 2002 10:16:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29867 for ; Wed, 14 Aug 2002 09:47:55 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08929 for ; Wed, 14 Aug 2002 09:46:34 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7EDlMY21716 for ; Wed, 14 Aug 2002 09:47:22 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Aug 2002 15:47:21 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: howard_abramson@adc.com, ipcdn@ietf.org Cc: "'Thomas Narten'" , "'Erik Nordmark'" , "Bert Wijnen (E-mail)" , "Bill Fenner (E-mail)" , "Dave Thaler (E-mail)" Date: Wed, 14 Aug 2002 15:47:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] MIB Docotor review of: draft-ietf-ipcdn-igmp-mib-04.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 First, I am copy-ing Bill and Dave because - The document is basically about IGMP applicability for DOCSIS - Bill is main author/editor for IGMPv2 (RFC2236) - Dave is co-author of IGMP MIB (RFC2933) It seems that Bill and Dave (or one of the other IGMP MIB authors) should take a look at this too. Or maybe the IDMR WG should look at it. Comments based on my own quick review: 1. This is mostly about IGMP applicability in DOCSIS environment. The applicability/required-conformance is expressed in terms of values in MIB objects in the IGMP MIB. That is sort of weird. I would rather assume that the MIB (when queried) returns the values as they actually exist. 2. For exmaple (and this is just one example), sect 4.1.1.2 regarding the igmpInterfaceQueryInterval. Passive Mode ------------ HFC-side: n/a, read-only. The CM MUST not transmit queries upstream. Return a value of zero. This seems wrong to me. If the object is implemented and accessible, then the agent MUST return the proper/actual value. I think what you want to say is that the HFC side should NOT/NEVER transmit IGMP Host Query packets. if so, then pls say so. It may mean that this MIB object therefor will have a value of zero, and that is fine. But the requirement (I think) is that the HFC side does not transmit packets at any time. CMCI-side: read only . This value is derived based on the interval of queries received from an upstream querier. This seems wrong too. At least it does not agree with the DESCRIPTION clause of the object in the igmp MIB 3. Another example (again an example) is section 4.1.1.1 on igmpInterfaceIfIndex: The ifIndex value of the interface for which IGMP is enabled. All Modes / Both sides: same for passive and active modes. HFC-side: not-accessible. ifIndex of docsCableMaclayer(127), CATV MAC Layer CMCI-side: not-accessible. ifIndex of CMCI-Side interface. These objects are INDEX objects (and as you say not accessible). So if anything, then maybe what you are saying is that the MIB should only contain instances (rows/entries) for interfaces that are of ifType 127 on the HFC side. Not sure I understand what you are saying for CMCI side (actually I am sure I do not understand). 4. Yet another example: 4.1.1.3 igmpInterfaceStatus The activation of a row enables IGMP on the interface. The destruction of a row disables IGMP on the interface. Sofar it is a repeat of what IGMP MIB already says. Seems useless. All Modes / Both sides: MUST be enabled on both interfaces for all DOCSIS 1.1 CM interfaces. Well, the value for the object then is 'active'. But I think what you are basically saying is that Bother sides MUST support IGMP on all their CM interfaces. Again, the instance of the MIB on a device should just relfect the actual situation, no matter if that is compliant with your spec or not. 5. As a last example: 4.1.1.4 igmpInterfaceVersion The version of IGMP which is running on this interface. All Modes / Both sides: MUST be version 2 for all DOCSIS 1.1 CM interfaces. I think what you are saying that DOCSIS devices MUST implement IGMPv2 for all of their CM interfaces. Again, the MIB, when queried MUST report the actual situation. It seems to me, before we go into more detail on these sort of things that we need to agree on how to specify your IGMP requirements for DOCSIS devices. But it seems to me that it is not appropriate to do so in the form of expected MIB object values. Additional comments: 6. sect 4.3.1.2 and sect 4.3.2.3 seem duplicates? 7. sect 4.3.2.5 and sect 4.3.2.6 seem not to be represented in the compliance statements in sect 4.3.1 8. When we get to section 4.3, maybe what you are trying to do is to tell DOCSIS device manufacturers that they do not have to implement the complete IGMP MIB on all devices. So what you may want to do is to specify special compliance statements. That seems a good idea. To do so, you should enclose them in a real MIB-MODULE (it can just contain the complaince statements). It would look aka: DOCS-IGMP-MIB-COMPLIANCES DEFINITIONS BEGIN IMPORT ... docsIgmpMibCompliancesMIB MODULE-IDENTITY .... docsIgmpV2PassiveDeviceCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for DOCSIS Devices passively running IGMPv2 and implementing the IGMP MIB." MODULE IGMP-STD-MIB MANDATORY-GROUPS { igmpBaseMIBGroup, igmpRouterMIBGroup, igmpV2RouterMIBGroup } OBJECT igmpInterfaceStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, and active is the only status that needs to be supported." OBJECT igmpCacheStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= {docsIgmpMIBCompliances 1} ... END Note that the way I specify read-only for igmpInterfaceStatus is also different from what you had done. I think my way is the correct (or at least better) way. I know that the IGMP MIB has it the same as you have. In fact you have exactly the same compliance statement. If that is what you want, then you just tell people that they must implement igmpV2RouterMIBCompliance. 9. An additional comment is, that if you allow igmpInterfaceStatus to be read-only, then I think you have to allow all objects in that table to be read-only, or maybe read-write. If you do not allow read-create access to a RowStatus object, then new rows cannot be created, and so none of the objects should then allow read-create access. 10. This applies equally well to the igmpCacheStatus object/rows of course. 11. If you allow for some people to do a read-write and others to do a read-only implementation, then I prefer to see 2 compliance statements. The Diffserv MIB (RFC3289) is a good example on how to do it. so you would have a xxxxMIBFullCompliance that does NOT allow for read-only xxxxMIBReadOnlyCompliance that does allow for the read-only implementations 12. You are also proposing a new object in the docsis device MIB. I do not understand why you do that, you have a revision of that MIB being worked on in the WG, so you can just refer to that new MIB and talk about the new object that you need. 13. And it then seems to me that you want to include that object in the COMPLIANCE statements that we talked about above. So you import a new group from the docsis device MIB and include it in the compliance statement(s) above. 14. By the way, you cannot add objects to an existing group. That could break the compliance that some people have claimed already. So you must define a new group, aka docsdevbaseGroup2. It could either just contain that one new objects, or it could contain the old list of objects plus the new object. Additional non-technical comments: 15. Acronyms used in Title and Abstract 16. References not split in normative/informative 17. references used in abstract section 18. a lot of RFC2119 language used while this is informational. for the first 15/16/17, see: http://www.rfc-editor.org/policy.html Bert AD for Network Management side of OPS Area _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Aug 15 13:14: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 NAA05306 for ; Thu, 15 Aug 2002 13:14:53 -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 NAA15910; Thu, 15 Aug 2002 13:15:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15879 for ; Thu, 15 Aug 2002 13:15:45 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05298 for ; Thu, 15 Aug 2002 13:14:24 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7FHFDX14040; Thu, 15 Aug 2002 13:15:13 -0400 (EDT) Received: from shrinivaspcho ([135.17.5.202]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA26229; Thu, 15 Aug 2002 13:14:44 -0400 (EDT) Reply-To: From: "Shrinivas Samant" To: , Date: Thu, 15 Aug 2002 13:06:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [ipcdn] Subscriber Management MIB-06 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 This question is related to the docsSubMgtTcpUdpFilterTable. This table defines the filtering criteria for TCP and UDP packets. If a CM's filter group has a list of TcpUdp filters, then how do we determine the action if a packet matches the filter. In short, should'nt the docsSubMgtTcpUdpFilterEntry have an action field associated with it? Thanks, Shrini -------------------------------------------- Shrinivas Samant Bell Labs AT Lucent Technologies Room 4L-350, Holmdel 732-949-6533 (O) 732-441-9209 (H) 732-693-7528 (M) 732-949-9330 (F) 732-949-1342 (F) -------------------------------------------- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From daemon@optimus.ietf.org Thu Aug 15 13:14: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 NAA05314 for ; Thu, 15 Aug 2002 13:14:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15932 for ipcdn-archive@odin.ietf.org; Thu, 15 Aug 2002 13:16:14 -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 NAA15910; Thu, 15 Aug 2002 13:15:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15879 for ; Thu, 15 Aug 2002 13:15:45 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05298 for ; Thu, 15 Aug 2002 13:14:24 -0400 (EDT) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7FHFDX14040; Thu, 15 Aug 2002 13:15:13 -0400 (EDT) Received: from shrinivaspcho ([135.17.5.202]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA26229; Thu, 15 Aug 2002 13:14:44 -0400 (EDT) Reply-To: From: "Shrinivas Samant" To: , Date: Thu, 15 Aug 2002 13:06:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [ipcdn] Subscriber Management MIB-06 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 This question is related to the docsSubMgtTcpUdpFilterTable. This table defines the filtering criteria for TCP and UDP packets. If a CM's filter group has a list of TcpUdp filters, then how do we determine the action if a packet matches the filter. In short, should'nt the docsSubMgtTcpUdpFilterEntry have an action field associated with it? Thanks, Shrini -------------------------------------------- Shrinivas Samant Bell Labs AT Lucent Technologies Room 4L-350, Holmdel 732-949-6533 (O) 732-441-9209 (H) 732-693-7528 (M) 732-949-9330 (F) 732-949-1342 (F) -------------------------------------------- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Thu Aug 15 13:36:25 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 NAA06070 for ; Thu, 15 Aug 2002 13:36:25 -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 NAA17757; Thu, 15 Aug 2002 13:37:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17729 for ; Thu, 15 Aug 2002 13:37:20 -0400 (EDT) Received: from titan.arrisi.com (client.antec.com [63.86.74.252] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06052 for ; Thu, 15 Aug 2002 13:35:59 -0400 (EDT) From: Wilson.Sawyer@arrisi.com Subject: Re: [ipcdn] Subscriber Management MIB-06 To: , ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Thu, 15 Aug 2002 13:35:24 -0400 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 08/15/2002 01:37:04 PM 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 If I understand your question, use docsSubMgtPktFilterAction. The tcp/udp entry is considered an extension of docsSubMgtPktFilterEntry. Regards, Wilson Sawyer "Shrinivas Samant" To: , Fax to: Sent by: Subject: [ipcdn] Subscriber Management MIB-06 ipcdn-admin@ietf. org 08/15/02 01:06 PM Please respond to ssamant This question is related to the docsSubMgtTcpUdpFilterTable. This table defines the filtering criteria for TCP and UDP packets. If a CM's filter group has a list of TcpUdp filters, then how do we determine the action if a packet matches the filter. In short, should'nt the docsSubMgtTcpUdpFilterEntry have an action field associated with it? Thanks, Shrini -------------------------------------------- Shrinivas Samant Bell Labs AT Lucent Technologies Room 4L-350, Holmdel 732-949-6533 (O) 732-441-9209 (H) 732-693-7528 (M) 732-949-9330 (F) 732-949-1342 (F) -------------------------------------------- _______________________________________________ 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 Aug 15 13:36:25 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 NAA06077 for ; Thu, 15 Aug 2002 13:36:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17794 for ipcdn-archive@odin.ietf.org; Thu, 15 Aug 2002 13:37:46 -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 NAA17757; Thu, 15 Aug 2002 13:37:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17729 for ; Thu, 15 Aug 2002 13:37:20 -0400 (EDT) Received: from titan.arrisi.com (client.antec.com [63.86.74.252] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06052 for ; Thu, 15 Aug 2002 13:35:59 -0400 (EDT) From: Wilson.Sawyer@arrisi.com Subject: Re: [ipcdn] Subscriber Management MIB-06 To: , ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Thu, 15 Aug 2002 13:35:24 -0400 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 08/15/2002 01:37:04 PM 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 If I understand your question, use docsSubMgtPktFilterAction. The tcp/udp entry is considered an extension of docsSubMgtPktFilterEntry. Regards, Wilson Sawyer "Shrinivas Samant" To: , Fax to: Sent by: Subject: [ipcdn] Subscriber Management MIB-06 ipcdn-admin@ietf. org 08/15/02 01:06 PM Please respond to ssamant This question is related to the docsSubMgtTcpUdpFilterTable. This table defines the filtering criteria for TCP and UDP packets. If a CM's filter group has a list of TcpUdp filters, then how do we determine the action if a packet matches the filter. In short, should'nt the docsSubMgtTcpUdpFilterEntry have an action field associated with it? Thanks, Shrini -------------------------------------------- Shrinivas Samant Bell Labs AT Lucent Technologies Room 4L-350, Holmdel 732-949-6533 (O) 732-441-9209 (H) 732-693-7528 (M) 732-949-9330 (F) 732-949-1342 (F) -------------------------------------------- _______________________________________________ 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 ipcdn-admin@ietf.org Fri Aug 23 22:34:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23582 for ; Fri, 23 Aug 2002 22:34:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7O2Zio09235; Fri, 23 Aug 2002 22:35:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7O2Y3o09200 for ; Fri, 23 Aug 2002 22:34:03 -0400 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23416 for ; Fri, 23 Aug 2002 22:32:28 -0400 (EDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 19:33:24 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 19:33:23 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 23 Aug 2002 19:33:23 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 23 Aug 2002 19:33:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 19:33:23 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Fri, 23 Aug 2002 19:33:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Aug 2002 19:33:21 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10738422C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: MIB Docotor review of: draft-ietf-ipcdn-igmp-mib-04.txt thread-index: AcJDmR04oB2CZbLESEuM0/RH/4agwAHeWSpA From: "Dave Thaler" To: "Wijnen, Bert (Bert)" , , Cc: "Thomas Narten" , "Erik Nordmark" , "Bill Fenner (E-mail)" X-OriginalArrivalTime: 24 Aug 2002 02:33:22.0770 (UTC) FILETIME=[9DBF0320:01C24B16] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7O2Y4o09201 Subject: [ipcdn] RE: MIB Docotor review of: draft-ietf-ipcdn-igmp-mib-04.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] [...] > First, I am copy-ing Bill and Dave because > > - The document is basically about IGMP applicability for DOCSIS > - Bill is main author/editor for IGMPv2 (RFC2236) > - Dave is co-author of IGMP MIB (RFC2933) > > It seems that Bill and Dave (or one of the other IGMP MIB authors) > should take a look at this too. > Or maybe the IDMR WG should look at it. Section 3 really duplicates part of the "IGMP Proxy" spec (expired?) by Bill. The model appears to be that a CM is a typical IGMP Proxy. On such a device, the objects covered by igmpV2HostMIBCompliance Should apply on the HFC-side and the objects covered by igmpV2RouterMIBCompliance should apply on the CMCI-side if in active mode. In passive mode CMCI-side, a subset will apply which is not covered by any existing compliance statement in the IGMP MIB. 4.1.1.2 igmpInterfaceQueryInterval > HFC-side: n/a, read-only. The CM MUST not transmit queries > upstream. Return a value of zero. Since the HFC-side is in host-mode not router mode, there should be no instance of this object on the HFC-side. It should not return 0. Same for igmpInterfaceQueryMaxResponseTime, igmpInterfaceQuerierExpiryTime, igmpInterfaceJoins, etc. 4.1.1.5 igmpInterfaceQuerier > HFC-side: read-only. MUST be the address of an upstream device for > both active and passive CMs. This equates to saying the optional igmpHostOptMIBGroup group is actually mandatory in this spec. 4.1.1.8 igmpInterfaceQuerierExpiryTime > Both Sides: n/a, read-only. The CM is never the querier, return 0. This is definitely wrong. The DESCRIPTION of this object says: "The amount of time remaining before the Other Querier Present Timer expires. If the local system is the querier, the value of this object is zero." The value should only be present and 0 when one is the querier. If you can never be the querier, then you're not in router-mode, and hence no object instance should be present. 4.1.1.10 igmpInterfaceWrongVersionQueries > All Modes / Both sides - read-only. The number of non-v2 queries > received on this interface. As with igmpInterfaceQueryInterval, I see no reason for this object to be present on the HFC-side. --- stopped here for the moment, but you can probably extrapolate what my responses to a bunch of other objects will be when I get a few more minutes. -Dave _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Aug 23 23:23:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23581 for ; Fri, 23 Aug 2002 22:34:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7O2Zrc09244 for ipcdn-archive@odin.ietf.org; Fri, 23 Aug 2002 22:35:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7O2Zio09235; Fri, 23 Aug 2002 22:35:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7O2Y3o09200 for ; Fri, 23 Aug 2002 22:34:03 -0400 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23416 for ; Fri, 23 Aug 2002 22:32:28 -0400 (EDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 19:33:24 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 19:33:23 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 23 Aug 2002 19:33:23 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 23 Aug 2002 19:33:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 23 Aug 2002 19:33:23 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Fri, 23 Aug 2002 19:33:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Aug 2002 19:33:21 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10738422C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: MIB Docotor review of: draft-ietf-ipcdn-igmp-mib-04.txt thread-index: AcJDmR04oB2CZbLESEuM0/RH/4agwAHeWSpA From: "Dave Thaler" To: "Wijnen, Bert (Bert)" , , Cc: "Thomas Narten" , "Erik Nordmark" , "Bill Fenner (E-mail)" X-OriginalArrivalTime: 24 Aug 2002 02:33:22.0770 (UTC) FILETIME=[9DBF0320:01C24B16] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g7O2Y4o09201 Subject: [ipcdn] RE: MIB Docotor review of: draft-ietf-ipcdn-igmp-mib-04.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] [...] > First, I am copy-ing Bill and Dave because > > - The document is basically about IGMP applicability for DOCSIS > - Bill is main author/editor for IGMPv2 (RFC2236) > - Dave is co-author of IGMP MIB (RFC2933) > > It seems that Bill and Dave (or one of the other IGMP MIB authors) > should take a look at this too. > Or maybe the IDMR WG should look at it. Section 3 really duplicates part of the "IGMP Proxy" spec (expired?) by Bill. The model appears to be that a CM is a typical IGMP Proxy. On such a device, the objects covered by igmpV2HostMIBCompliance Should apply on the HFC-side and the objects covered by igmpV2RouterMIBCompliance should apply on the CMCI-side if in active mode. In passive mode CMCI-side, a subset will apply which is not covered by any existing compliance statement in the IGMP MIB. 4.1.1.2 igmpInterfaceQueryInterval > HFC-side: n/a, read-only. The CM MUST not transmit queries > upstream. Return a value of zero. Since the HFC-side is in host-mode not router mode, there should be no instance of this object on the HFC-side. It should not return 0. Same for igmpInterfaceQueryMaxResponseTime, igmpInterfaceQuerierExpiryTime, igmpInterfaceJoins, etc. 4.1.1.5 igmpInterfaceQuerier > HFC-side: read-only. MUST be the address of an upstream device for > both active and passive CMs. This equates to saying the optional igmpHostOptMIBGroup group is actually mandatory in this spec. 4.1.1.8 igmpInterfaceQuerierExpiryTime > Both Sides: n/a, read-only. The CM is never the querier, return 0. This is definitely wrong. The DESCRIPTION of this object says: "The amount of time remaining before the Other Querier Present Timer expires. If the local system is the querier, the value of this object is zero." The value should only be present and 0 when one is the querier. If you can never be the querier, then you're not in router-mode, and hence no object instance should be present. 4.1.1.10 igmpInterfaceWrongVersionQueries > All Modes / Both sides - read-only. The number of non-v2 queries > received on this interface. As with igmpInterfaceQueryInterval, I see no reason for this object to be present on the HFC-side. --- stopped here for the moment, but you can probably extrapolate what my responses to a bunch of other objects will be when I get a few more minutes. -Dave _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Tue Aug 27 18:16:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14780 for ; Tue, 27 Aug 2002 18:16:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RMHJo07347; Tue, 27 Aug 2002 18:17:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGfo28149 for ; Tue, 27 Aug 2002 15:16:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [ipcdn] Nomcom call for volunteers Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Aug 27 18:17:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14808 for ; Tue, 27 Aug 2002 18:17:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g7RMILI07440 for ipcdn-archive@odin.ietf.org; Tue, 27 Aug 2002 18:18:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RMHJo07347; Tue, 27 Aug 2002 18:17:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g7RJGfo28149 for ; Tue, 27 Aug 2002 15:16:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Date: Tue, 27 Aug 2002 14:44:44 -0400 Subject: [ipcdn] Nomcom call for volunteers Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn