From daemon@optimus.ietf.org Fri Feb 1 08:55:32 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 IAA22052 for ; Fri, 1 Feb 2002 08:55:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15611 for policy-archive@odin.ietf.org; Fri, 1 Feb 2002 08:55:35 -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 IAA15052; Fri, 1 Feb 2002 08:47:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15019 for ; Fri, 1 Feb 2002 08:47:23 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21774 for ; Fri, 1 Feb 2002 08:47:18 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA77786; Fri, 1 Feb 2002 07:42:44 -0600 Received: from lrafalow (dyn9-27-16-134.raleigh.ibm.com [9.27.16.134]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with SMTP id g11DlIb213948; Fri, 1 Feb 2002 08:47:18 -0500 Message-ID: <002301c1ab26$e5678c00$86101b09@lrafalow> Reply-To: "Lee Rafalow" From: "Lee Rafalow" To: , , , References: <4.3.2.7.2.20020131183702.02832b18@brussels.cisco.com> <3C59CBAB.D8995CE3@sonicwall.com> Date: Fri, 1 Feb 2002 08:46:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Policy] IpHeadersFilter (Re: Address ranges) Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Yes, this is an oversight. We need to fix IpHeadersFilter to support ranges. Good catch Casey! The current class definition is: NAME IpHeadersFilter DESCRIPTION A class representing an entire IP header filter, or any subset of one. DERIVED FROM FilterEntryBase TYPE Concrete PROPERTIES HdrIpVersion, HdrSrcAddress, HdrSrcMask, HdrDestAddress, HdrDestMask, HdrProtocolID, HdrSrcPortStart, HdrSrcPortEnd, HdrDestPortStart, HdrDestPortEnd, HdrDSCP, HdrFlowLabel I suggest the following changes. Add HdrSrcAddressEndOfRange and HdrDestAddressEndOfRange. When non-null, the start of range value is in the corresponding HdrXxxxAddress property. When null, the corresponding HdrXxxxAddress property is interpreted as today as a single address filter that may have a mask. And the HdrXxxxAddressEndOfRange properties MUST be null when their corresponding HdrXxxxMask property is non-null and vice-versa (i.e., no mask on ranges). For consistency, I'd also have us rename the HdrXxxxPortStart properties to drop the "Start" and rename the HdrXxxxPortEnd properties to "EndOfRange" and change the semantics so that the EndOfRange properties are null when the filter is not specifying a port range instead of the current both values are the same definition. Comments? ----- Original Message ----- From: "Scott G. Kelly" To: "Eric Vyncke" Cc: "Casey Carr" ; "IPSec Policy WG" Sent: Thursday, January 31, 2002 5:56 PM Subject: Re: Address ranges > > Eric Vyncke wrote: > > > > At 11:15 30/01/2002 -0500, Casey Carr wrote: > > > > >Could someone please give me some guidance on how the IPSec policy model > > >addresses (no pun intended) filtering on a range of IPv4 addresses? > > > > > >The IPSec library we are using supports defining filters based on address > > >ranges but it doesn't appear to me that the model supports this. I've > > > > This is correct as ICPM tried to re-use as much as possible of PCIM/PCIMe > > which does not understand IP address ranges > > > > -eric > > Since RFC2401 mandates support for address ranges, shouldn't the policy > model support them? > > Scott > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri Feb 1 12:24:07 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 MAA04828 for ; Fri, 1 Feb 2002 12:24:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28772 for policy-archive@odin.ietf.org; Fri, 1 Feb 2002 12:24:10 -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 MAA27523; Fri, 1 Feb 2002 12:05:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27477 for ; Fri, 1 Feb 2002 12:05:19 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03807 for ; Fri, 1 Feb 2002 12:05:16 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11H4iC29349; Fri, 1 Feb 2002 12:04:44 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11H4gb01689; Fri, 1 Feb 2002 12:04:42 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8Z2Y6AD; Fri, 1 Feb 2002 12:04:41 -0500 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1AADT1N6; Fri, 1 Feb 2002 12:04:41 -0500 Message-ID: <3C5ACBB3.9E12B31F@americasm01.nt.com> Date: Fri, 01 Feb 2002 12:09:07 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Moore CC: IETF Policy , bwijnen@lucent.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Policy] Re: IP Protocol value range Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Here they are. I've just listed them all (including the ones that were already specified). I'm not sure what would be a formal notation for the number of bits that a PolicyBitStringValue must have. E.g. An IPToS variable can be matched against BitString values with *exactly* 8 bits. See also the note on SNAP at the bottom. Regards, Mircea. PolicySourceIPv4Variable........PolicyIPv4AddrValue PolicySourceIPv6Variable........PolicyIPv6AddrValue PolicyDestinationIPv4Variable...PolicyIPv4AddrValue PolicyDestinationIPv6Variable...PolicyIPv6AddrValue PolicySourcePortVariable........PolicyIntegerValue (0..65535) PolicyDestinationPortVariable...PolicyIntegerValue (0..65535) PolicyIPProtocolVariable........PolicyIntegerValue (0..255) PolicyIPVersionVariable.........PolicyIntegerValue (0..15) PolicyIPToSVariable.............PolicyIntegerValue (0..255) PolicyBitStringValue (8 bit) PolicyDSCPVariable..............PolicyIntegerValue (0..63) PolicyBitStringValue (6 bit) PolicyFlowIdVariable............PolicyIntegerValue (0..1048575) PolicyBitStringValue (20 bit) PolicySourceMACVariable.........PolicyMACAddrValue PolicyDestinationMACVariable....PolicyMACAddrValue PolicyVLANVariable..............PolicyIntegerValue (0..4095) PolicyBitStringValue (12 bit) PolicyCoSVariable...............PolicyIntegerValue (0..7) PolicyBitStringValue (3 bit) PolicyEthertypeVariable.........PolicyIntegerValue (0..65535) PolicyBitStringValue (16 bit) PolicySourceSAPVariable.........PolicyIntegerValue (0..255) PolicyBitStringValue (8 bit) PolicyDestinationSAPVariable....PolicyIntegerValue (0..255) PolicyBitStringValue (8 bit) PolicySNAPVariable..............PolicyIntegerValue (0..65535) PolicyBitStringValue (16 bit) PolicyFlowDirectionVariable.....PolicyStringValue (IN, OUT) Note: SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". See http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for Routed Protocols" for example. The SNAP header includes two fields: OUI (3 octets) and PID (2 octets). I have two comments here: 1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access Protocol". 2. Was it intended for the PCIMe class "PolicySNAPVariable" to represent only the PID part of the SNAP header (2 octets)? Or should it reflect the entire header: OUI+PID (5 octets). _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri Feb 1 12:25:46 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 MAA04875 for ; Fri, 1 Feb 2002 12:25:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28848 for policy-archive@odin.ietf.org; Fri, 1 Feb 2002 12:25:49 -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 MAA28165; Fri, 1 Feb 2002 12:13:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28134 for ; Fri, 1 Feb 2002 12:13:54 -0500 (EST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04398 for ; Fri, 1 Feb 2002 12:13:46 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.29 2002/01/25 02:32:19 root Exp $) with ESMTP id g11HDB604683 for ; Fri, 1 Feb 2002 17:13:11 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.11 2001/11/09 23:28:01 root Exp $) with SMTP id g11HDGW26346 for ; Fri, 1 Feb 2002 17:13:16 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002020109131713990 ; Fri, 01 Feb 2002 09:13:17 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 09:13:47 -0800 Message-ID: <86DB568235A8D511ABAC0002A5072CA501E9234C@orsmsx120.jf.intel.com> From: "Jason, Jamie" To: policy@ietf.org, wg-network@dmtf.org, wg-policy@dmtf.org Subject: RE: [Policy] IpHeadersFilter (Re: Address ranges) Date: Fri, 1 Feb 2002 09:13:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This seems reasonable to me. We need to ensure that PCIMe can support address ranges so that we can re-use this class in the IPsec policy model. Thanks Lee. Jamie > -----Original Message----- > From: Lee Rafalow [mailto:rafalow@watson.ibm.com] > Sent: Friday, February 01, 2002 5:47 AM > To: policy@ietf.org; wg-network@dmtf.org; wg-policy@dmtf.org; > ipsec-policy@vpnc.org > Subject: [Policy] IpHeadersFilter (Re: Address ranges) > > > Yes, this is an oversight. We need to fix IpHeadersFilter to > support ranges. Good catch Casey! > > The current class definition is: > > NAME IpHeadersFilter > DESCRIPTION A class representing an entire IP > header filter, or any subset of one. > DERIVED FROM FilterEntryBase > TYPE Concrete > PROPERTIES HdrIpVersion, HdrSrcAddress, HdrSrcMask, > HdrDestAddress, HdrDestMask, HdrProtocolID, HdrSrcPortStart, > HdrSrcPortEnd, HdrDestPortStart, HdrDestPortEnd, HdrDSCP, HdrFlowLabel > > I suggest the following changes. > > Add HdrSrcAddressEndOfRange and HdrDestAddressEndOfRange. > When non-null, the start of range value is in the > corresponding HdrXxxxAddress property. When null, the > corresponding HdrXxxxAddress property is interpreted as today > as a single address filter that may have a mask. And the > HdrXxxxAddressEndOfRange properties MUST be null when their > corresponding HdrXxxxMask property is non-null and vice-versa > (i.e., no mask on ranges). > > For consistency, I'd also have us rename the HdrXxxxPortStart > properties to drop the "Start" and rename the HdrXxxxPortEnd > properties to "EndOfRange" and change the semantics so that > the EndOfRange properties are null when the filter is not > specifying a port range instead of the current both values > are the same definition. > > Comments? > > ----- Original Message ----- > From: "Scott G. Kelly" > To: "Eric Vyncke" > Cc: "Casey Carr" ; "IPSec Policy WG" > > Sent: Thursday, January 31, 2002 5:56 PM > Subject: Re: Address ranges > > > > > > Eric Vyncke wrote: > > > > > > At 11:15 30/01/2002 -0500, Casey Carr wrote: > > > > > > >Could someone please give me some guidance on how the > IPSec policy > model > > > >addresses (no pun intended) filtering on a range of IPv4 > addresses? > > > > > > > >The IPSec library we are using supports defining filters based on > address > > > >ranges but it doesn't appear to me that the model > supports this. > > > >I've > > > > > > This is correct as ICPM tried to re-use as much as possible of > PCIM/PCIMe > > > which does not understand IP address ranges > > > > > > -eric > > > > Since RFC2401 mandates support for address ranges, shouldn't the > > policy model support them? > > > > Scott > > > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri Feb 1 18:59:15 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 SAA14475 for ; Fri, 1 Feb 2002 18:59:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA18098 for policy-archive@odin.ietf.org; Fri, 1 Feb 2002 18:59:17 -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 SAA17582; Fri, 1 Feb 2002 18:46:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18488 for ; Fri, 1 Feb 2002 09:41:13 -0500 (EST) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24283 for ; Fri, 1 Feb 2002 09:41:09 -0500 (EST) Received: from casey ([66.26.63.121]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Fri, 1 Feb 2002 09:40:06 -0500 From: "Casey Carr" To: "Lee Rafalow" , , , , Date: Fri, 1 Feb 2002 09:39:21 -0500 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <002301c1ab26$e5678c00$86101b09@lrafalow> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Policy] RE: IpHeadersFilter (Re: Address ranges) Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Works for me. Casey -----Original Message----- From: owner-ipsec-policy@mail.vpnc.org [mailto:owner-ipsec-policy@mail.vpnc.org]On Behalf Of Lee Rafalow Sent: Friday, February 01, 2002 8:47 AM To: policy@ietf.org; wg-network@dmtf.org; wg-policy@dmtf.org; ipsec-policy@vpnc.org Subject: IpHeadersFilter (Re: Address ranges) Yes, this is an oversight. We need to fix IpHeadersFilter to support ranges. Good catch Casey! The current class definition is: NAME IpHeadersFilter DESCRIPTION A class representing an entire IP header filter, or any subset of one. DERIVED FROM FilterEntryBase TYPE Concrete PROPERTIES HdrIpVersion, HdrSrcAddress, HdrSrcMask, HdrDestAddress, HdrDestMask, HdrProtocolID, HdrSrcPortStart, HdrSrcPortEnd, HdrDestPortStart, HdrDestPortEnd, HdrDSCP, HdrFlowLabel I suggest the following changes. Add HdrSrcAddressEndOfRange and HdrDestAddressEndOfRange. When non-null, the start of range value is in the corresponding HdrXxxxAddress property. When null, the corresponding HdrXxxxAddress property is interpreted as today as a single address filter that may have a mask. And the HdrXxxxAddressEndOfRange properties MUST be null when their corresponding HdrXxxxMask property is non-null and vice-versa (i.e., no mask on ranges). For consistency, I'd also have us rename the HdrXxxxPortStart properties to drop the "Start" and rename the HdrXxxxPortEnd properties to "EndOfRange" and change the semantics so that the EndOfRange properties are null when the filter is not specifying a port range instead of the current both values are the same definition. Comments? ----- Original Message ----- From: "Scott G. Kelly" To: "Eric Vyncke" Cc: "Casey Carr" ; "IPSec Policy WG" Sent: Thursday, January 31, 2002 5:56 PM Subject: Re: Address ranges > > Eric Vyncke wrote: > > > > At 11:15 30/01/2002 -0500, Casey Carr wrote: > > > > >Could someone please give me some guidance on how the IPSec policy model > > >addresses (no pun intended) filtering on a range of IPv4 addresses? > > > > > >The IPSec library we are using supports defining filters based on address > > >ranges but it doesn't appear to me that the model supports this. I've > > > > This is correct as ICPM tried to re-use as much as possible of PCIM/PCIMe > > which does not understand IP address ranges > > > > -eric > > Since RFC2401 mandates support for address ranges, shouldn't the policy > model support them? > > Scott > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Mon Feb 4 09:44: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 JAA23840 for ; Mon, 4 Feb 2002 09:44:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06307 for policy-archive@odin.ietf.org; Mon, 4 Feb 2002 09:44:25 -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 JAA05747; Mon, 4 Feb 2002 09:32:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05685 for ; Mon, 4 Feb 2002 09:31:58 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23421; Mon, 4 Feb 2002 09:31:56 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA25030; Mon, 4 Feb 2002 08:27:19 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g14EVvD59470; Mon, 4 Feb 2002 09:31:57 -0500 Subject: Re: [Policy] Re: IP Protocol value range To: "Mircea Pana" Cc: bwijnen@lucent.com, IETF Policy , policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Mon, 4 Feb 2002 09:36:04 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_01072002 Beta 5|January 07, 2002) at 02/04/2002 09:31:57 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE1C5DFDCBCE48f9e8a93df938690918c0ABBE1C5DFDCBCE4" Content-Disposition: inline Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1C5DFDCBCE48f9e8a93df938690918c0ABBE1C5DFDCBCE4 Content-type: text/plain; charset=US-ASCII >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". See >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for Routed >Protocols" for example. The SNAP header includes two fields: OUI (3 >octets) and PID (2 octets). > >I have two comments here: >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access >Protocol". >2. Was it intended for the PCIMe class "PolicySNAPVariable" to represent >only the PID part of the SNAP header (2 octets)? Or should it reflect >the entire header: OUI+PID (5 octets). To be honest, I don't know what we meant to refer to with PolicySNAPVariable. (I think this class came from Cisco - in any case, I know it didn't come from IBM.) Some possibilities: Currently in PCIMe: Sub-Network Access Protocol. Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. On acronymfinder.com: Subnetwork Access Protocol, Standard Network Access Protocol (in bold, for some reason), Small Network Access Package, and a bunch of other options that are plainly not what we're talking about. Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell us what we meant when we defined PolicySNAPVariable. And maybe they'll even agree! :-) Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com --0__=0ABBE1C5DFDCBCE48f9e8a93df938690918c0ABBE1C5DFDCBCE4 Content-type: text/html; charset=US-ASCII Content-Disposition: inline >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". See
>http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for Routed
>Protocols" for example. The SNAP header includes two fields: OUI (3
>octets) and PID (2 octets).
>
>I have two comments here:
>1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access
>Protocol".
>2. Was it intended for the PCIMe class "PolicySNAPVariable" to represent
>only the PID part of the SNAP header (2 octets)? Or should it reflect
>the entire header: OUI+PID (5 octets).

To be honest, I don't know what we meant to refer to with
PolicySNAPVariable.  (I think this class came from Cisco - in
any case, I know it didn't come from IBM.)  Some possibilities:

Currently in PCIMe: Sub-Network Access Protocol.

Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point.

On acronymfinder.com: Subnetwork Access Protocol,
Standard Network Access Protocol (in bold, for some
reason), Small Network Access Package, and a bunch
of other options that are plainly not what we're
talking about.

Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell
us what we meant when we defined PolicySNAPVariable.
And maybe they'll even agree! :-)

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com
--0__=0ABBE1C5DFDCBCE48f9e8a93df938690918c0ABBE1C5DFDCBCE4-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Mon Feb 4 10:47: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 KAA26183 for ; Mon, 4 Feb 2002 10:47:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10461 for policy-archive@odin.ietf.org; Mon, 4 Feb 2002 10:47: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 KAA09813; Mon, 4 Feb 2002 10:32:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09762 for ; Mon, 4 Feb 2002 10:32:24 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25749; Mon, 4 Feb 2002 10:32:19 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14FVnH11677; Mon, 4 Feb 2002 10:31:50 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14FVk728469; Mon, 4 Feb 2002 10:31:46 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8Z281Q4; Mon, 4 Feb 2002 10:31:36 -0500 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1AADTFRA; Mon, 4 Feb 2002 10:31:39 -0500 Message-ID: <3C5EAA5E.282B1788@americasm01.nt.com> Date: Mon, 04 Feb 2002 10:35:58 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Moore CC: bwijnen@lucent.com, IETF Policy , policy-admin@ietf.org Subject: Re: [Policy] Re: IP Protocol value range References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit ...and just to add to my confusion, RFC1042 defines the *same* SNAP header as "an extension of the LLC header called the Sub-Network Access Protocol (SNAP)" :-0 So, a reference to the actual definitions (RFC, IEEE etc.) may help if added in PCIMe. IMO, it is less important what exactly this (or other) PolicyVariable represents, more important is to define it unambiguously. Regards, Mircea. Robert Moore wrote: > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > See > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > Routed > >Protocols" for example. The SNAP header includes two fields: OUI (3 > >octets) and PID (2 octets). > > > >I have two comments here: > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > >Protocol". > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > represent > >only the PID part of the SNAP header (2 octets)? Or should it reflect > >the entire header: OUI+PID (5 octets). > > To be honest, I don't know what we meant to refer to with > PolicySNAPVariable. (I think this class came from Cisco - in > any case, I know it didn't come from IBM.) Some possibilities: > > Currently in PCIMe: Sub-Network Access Protocol. > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > On acronymfinder.com: Subnetwork Access Protocol, > Standard Network Access Protocol (in bold, for some > reason), Small Network Access Package, and a bunch > of other options that are plainly not what we're > talking about. > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > us what we meant when we defined PolicySNAPVariable. > And maybe they'll even agree! :-) > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Mon Feb 4 13:40:59 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 NAA02494 for ; Mon, 4 Feb 2002 13:40:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23269 for policy-archive@odin.ietf.org; Mon, 4 Feb 2002 13:41:01 -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 NAA21977; Mon, 4 Feb 2002 13:25:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21863 for ; Mon, 4 Feb 2002 13:24:02 -0500 (EST) Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02054 for ; Mon, 4 Feb 2002 13:24:00 -0500 (EST) Received: from user-vcaulgn.dsl.mindspring.com ([216.175.86.23] helo=ANDREWHOME) by harrier.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16Xnkk-0005Ph-00; Mon, 04 Feb 2002 10:22:06 -0800 From: "Andrew Smith" To: "Mircea Pana" , "Robert Moore" Cc: "IETF Policy" Subject: RE: [Policy] Re: IP Protocol value range Date: Mon, 4 Feb 2002 10:50:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3C5EAA5E.282B1788@americasm01.nt.com> Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit I don't know where RFC1483 got its material from but SNAP stands for Sub-Network Access Protocol in all the IEEE documents I've ever seen. It's defined in IEEE 802 "Overview and Architecture": http://www.ieee802.org/1/mirror/8021/o-drafts/d29/802-d29.pdf (I think this URL works for the public) section 10.2.2 is the latest version. You might also refer to section 10.3 of same document which defines the SNAP encoding, including the format of the 40-bit "protocol identifier" field. Note that this document (P802/D29 is the name of the last pre-approval draft) has been approved by IEEE but I don't think it's available from the printers yet. If the above URL doesn't work then the old version of the standard is available at http://standards.ieee.org/reading/ieee/std/lanman/802-1990.pdf although the section numbering has changed quite a bit since then. Andrew Smith -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of Mircea Pana Sent: Monday, February 04, 2002 7:36 AM To: Robert Moore Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org Subject: Re: [Policy] Re: IP Protocol value range ...and just to add to my confusion, RFC1042 defines the *same* SNAP header as "an extension of the LLC header called the Sub-Network Access Protocol (SNAP)" :-0 So, a reference to the actual definitions (RFC, IEEE etc.) may help if added in PCIMe. IMO, it is less important what exactly this (or other) PolicyVariable represents, more important is to define it unambiguously. Regards, Mircea. Robert Moore wrote: > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > See > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > Routed > >Protocols" for example. The SNAP header includes two fields: OUI (3 > >octets) and PID (2 octets). > > > >I have two comments here: > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > >Protocol". > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > represent > >only the PID part of the SNAP header (2 octets)? Or should it reflect > >the entire header: OUI+PID (5 octets). > > To be honest, I don't know what we meant to refer to with > PolicySNAPVariable. (I think this class came from Cisco - in > any case, I know it didn't come from IBM.) Some possibilities: > > Currently in PCIMe: Sub-Network Access Protocol. > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > On acronymfinder.com: Subnetwork Access Protocol, > Standard Network Access Protocol (in bold, for some > reason), Small Network Access Package, and a bunch > of other options that are plainly not what we're > talking about. > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > us what we meant when we defined PolicySNAPVariable. > And maybe they'll even agree! :-) > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Mon Feb 4 14:54:45 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 OAA04486 for ; Mon, 4 Feb 2002 14:54:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27450 for policy-archive@odin.ietf.org; Mon, 4 Feb 2002 14:54:48 -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 OAA26322; Mon, 4 Feb 2002 14:32:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26292 for ; Mon, 4 Feb 2002 14:32:24 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03864 for ; Mon, 4 Feb 2002 14:32:21 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14JVoH08195; Mon, 4 Feb 2002 14:31:50 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14JVm314349; Mon, 4 Feb 2002 14:31:48 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8Z29C0L; Mon, 4 Feb 2002 14:31:45 -0500 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1AADTF9M; Mon, 4 Feb 2002 14:31:48 -0500 Message-ID: <3C5EE2A6.6F2DE40F@americasm01.nt.com> Date: Mon, 04 Feb 2002 14:36:06 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Smith , IETF Policy Subject: Re: [Policy] Re: IP Protocol value range References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Andrew, thanks for the clarification. Looks like rfc1483 was a "red herring". A question for the PCIMe authors though: Which part of the SNAP header, if not all 5 octets, is captured in "PolicySNAPVariable"? If all, then, I think, the allowed value range should be (0..(2**40-1)) if Integer or (40 bit) if BitString. Mircea. Andrew Smith wrote: > > I don't know where RFC1483 got its material from but SNAP stands for > Sub-Network Access Protocol in all the IEEE documents I've ever seen. It's > defined in IEEE 802 "Overview and Architecture": > http://www.ieee802.org/1/mirror/8021/o-drafts/d29/802-d29.pdf (I think this > URL works for the public) section 10.2.2 is the latest version. You might > also refer to section 10.3 of same document which defines the SNAP encoding, > including the format of the 40-bit "protocol identifier" field. > > Note that this document (P802/D29 is the name of the last pre-approval > draft) has been approved by IEEE but I don't think it's available from the > printers yet. If the above URL doesn't work then the old version of the > standard is available at > http://standards.ieee.org/reading/ieee/std/lanman/802-1990.pdf although the > section numbering has changed quite a bit since then. > > Andrew Smith > > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of > Mircea Pana > Sent: Monday, February 04, 2002 7:36 AM > To: Robert Moore > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > Subject: Re: [Policy] Re: IP Protocol value range > > ...and just to add to my confusion, RFC1042 defines the *same* SNAP > header as > "an extension of the LLC header called the Sub-Network Access Protocol > (SNAP)" :-0 > > So, a reference to the actual definitions (RFC, IEEE etc.) may help if > added in PCIMe. IMO, it is less important what exactly this (or other) > PolicyVariable represents, more important is to define it unambiguously. > > Regards, > Mircea. > > Robert Moore wrote: > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > > See > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > Routed > > >Protocols" for example. The SNAP header includes two fields: OUI (3 > > >octets) and PID (2 octets). > > > > > >I have two comments here: > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > >Protocol". > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > represent > > >only the PID part of the SNAP header (2 octets)? Or should it reflect > > >the entire header: OUI+PID (5 octets). > > > > To be honest, I don't know what we meant to refer to with > > PolicySNAPVariable. (I think this class came from Cisco - in > > any case, I know it didn't come from IBM.) Some possibilities: > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > On acronymfinder.com: Subnetwork Access Protocol, > > Standard Network Access Protocol (in bold, for some > > reason), Small Network Access Package, and a bunch > > of other options that are plainly not what we're > > talking about. > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > us what we meant when we defined PolicySNAPVariable. > > And maybe they'll even agree! :-) > > > > Regards, > > Bob > > > > Bob Moore > > Advanced Design and Technology > > Application Integration Middleware Division > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Tue Feb 5 07:28:10 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 HAA28317 for ; Tue, 5 Feb 2002 07:28:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25408 for policy-archive@odin.ietf.org; Tue, 5 Feb 2002 07:28:11 -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 HAA24172; Tue, 5 Feb 2002 07:17:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24133 for ; Tue, 5 Feb 2002 07:17:24 -0500 (EST) Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28036; Tue, 5 Feb 2002 07:17:21 -0500 (EST) Received: from RONC (212.199.103.75) by mail.san.yahoo.com (5.5.056) id 3C5842800016D81E; Tue, 5 Feb 2002 03:55:19 -0800 From: "Ron Cohen" To: "'Mircea Pana'" , "'Robert Moore'" Cc: , "'IETF Policy'" , Subject: RE: [Policy] Re: IP Protocol value range Date: Tue, 5 Feb 2002 13:54:33 +0200 Message-ID: <1068327212765C4F995A07930BF7F24606AF37@oakenfold.lyciumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <1068327212765C4F995A07930BF7F2460D9558@oakenfold.lyciumnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Mircea, Bob PCIMe defines: PolicySNAPVariable: The protocol number over a Sub-Network Access Protocol (SNAP) SAP encapsulation. Explanation: IEEE 802.2 defines two encapsulations, following the Ethernet length field: - One with 3 bytes, SSAP, DSAP and CNTRL. The first two are represented by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. - The second called the 802.2 SNAP encapsulation, and adds 5 bytes, where the last two bytes are called the SNAP type. This is the equivalent of the Ethernet Type. The intention was that the PolicySNAPVariable would represent this two byte SNAP type field. I suggest that we rename this variable to PolicySNAPTypeVriable and remove the current ambiguity. Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Mircea Pana > Sent: Monday, February 04, 2002 5:36 PM > To: Robert Moore > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > Subject: Re: [Policy] Re: IP Protocol value range > > > ...and just to add to my confusion, RFC1042 defines the *same* SNAP > header as > "an extension of the LLC header called the Sub-Network Access Protocol > (SNAP)" :-0 > > So, a reference to the actual definitions (RFC, IEEE etc.) may help if > added in PCIMe. IMO, it is less important what exactly this (or other) > PolicyVariable represents, more important is to define it > unambiguously. > > Regards, > Mircea. > > > Robert Moore wrote: > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > > See > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > Routed > > >Protocols" for example. The SNAP header includes two fields: OUI (3 > > >octets) and PID (2 octets). > > > > > >I have two comments here: > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > >Protocol". > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > represent > > >only the PID part of the SNAP header (2 octets)? Or should > it reflect > > >the entire header: OUI+PID (5 octets). > > > > To be honest, I don't know what we meant to refer to with > > PolicySNAPVariable. (I think this class came from Cisco - in > > any case, I know it didn't come from IBM.) Some possibilities: > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > On acronymfinder.com: Subnetwork Access Protocol, > > Standard Network Access Protocol (in bold, for some > > reason), Small Network Access Package, and a bunch > > of other options that are plainly not what we're > > talking about. > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > us what we meant when we defined PolicySNAPVariable. > > And maybe they'll even agree! :-) > > > > Regards, > > Bob > > > > Bob Moore > > Advanced Design and Technology > > Application Integration Middleware Division > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Tue Feb 5 13:10:12 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 NAA11530 for ; Tue, 5 Feb 2002 13:10:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22531 for policy-archive@odin.ietf.org; Tue, 5 Feb 2002 13:10:14 -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 MAA21202; Tue, 5 Feb 2002 12:52:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21159 for ; Tue, 5 Feb 2002 12:52:13 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10803; Tue, 5 Feb 2002 12:52:08 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA70058; Tue, 5 Feb 2002 11:47:29 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g15Hq9w139256; Tue, 5 Feb 2002 12:52:09 -0500 Subject: RE: [Policy] Re: IP Protocol value range To: "Ron Cohen" Cc: bwijnen@lucent.com, "'Mircea Pana'" , "'IETF Policy'" , policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Tue, 5 Feb 2002 12:56:20 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_01072002 Beta 5|January 07, 2002) at 02/05/2002 12:52:09 PM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A Content-type: multipart/alternative; Boundary="1__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A" --1__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A Content-type: text/plain; charset=US-ASCII Let me propose an update to the PCIMe text. If this isn't exactly right, it should at least be specific enough for people to comment on. It's a complete replacement for section 5.12.19: NAME PolicySNAPTypeVariable DESCRIPTION The value of the Sub-Network Access Protocol (SNAP) Type field for 802.2 SNAP encapsulation. ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - PolicyBitStringValue (16 bit) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Ron Cohen" To: "'Mircea Pana'" , Robert Moore/Raleigh/IBM@IBMUS 02/05/02 06:54 AM cc: , "'IETF Policy'" , Subject: RE: [Policy] Re: IP Protocol value range Mircea, Bob PCIMe defines: PolicySNAPVariable: The protocol number over a Sub-Network Access Protocol (SNAP) SAP encapsulation. Explanation: IEEE 802.2 defines two encapsulations, following the Ethernet length field: - One with 3 bytes, SSAP, DSAP and CNTRL. The first two are represented by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. - The second called the 802.2 SNAP encapsulation, and adds 5 bytes, where the last two bytes are called the SNAP type. This is the equivalent of the Ethernet Type. The intention was that the PolicySNAPVariable would represent this two byte SNAP type field. I suggest that we rename this variable to PolicySNAPTypeVriable and remove the current ambiguity. Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Mircea Pana > Sent: Monday, February 04, 2002 5:36 PM > To: Robert Moore > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > Subject: Re: [Policy] Re: IP Protocol value range > > > ...and just to add to my confusion, RFC1042 defines the *same* SNAP > header as > "an extension of the LLC header called the Sub-Network Access Protocol > (SNAP)" :-0 > > So, a reference to the actual definitions (RFC, IEEE etc.) may help if > added in PCIMe. IMO, it is less important what exactly this (or other) > PolicyVariable represents, more important is to define it > unambiguously. > > Regards, > Mircea. > > > Robert Moore wrote: > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > > See > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > Routed > > >Protocols" for example. The SNAP header includes two fields: OUI (3 > > >octets) and PID (2 octets). > > > > > >I have two comments here: > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > >Protocol". > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > represent > > >only the PID part of the SNAP header (2 octets)? Or should > it reflect > > >the entire header: OUI+PID (5 octets). > > > > To be honest, I don't know what we meant to refer to with > > PolicySNAPVariable. (I think this class came from Cisco - in > > any case, I know it didn't come from IBM.) Some possibilities: > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > On acronymfinder.com: Subnetwork Access Protocol, > > Standard Network Access Protocol (in bold, for some > > reason), Small Network Access Package, and a bunch > > of other options that are plainly not what we're > > talking about. > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > us what we meant when we defined PolicySNAPVariable. > > And maybe they'll even agree! :-) > > > > Regards, > > Bob > > > > Bob Moore > > Advanced Design and Technology > > Application Integration Middleware Division > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > --1__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A Content-type: text/html; charset=US-ASCII Content-Disposition: inline Let me propose an update to the PCIMe text. If this isn't exactly right,
it should at least be specific enough for people to comment on.
It's a complete replacement for section 5.12.19:

      NAME PolicySNAPTypeVariable
      DESCRIPTION The value of the Sub-Network Access Protocol
                         (SNAP) Type field for 802.2 SNAP encapsulation.

      ALLOWED VALUE TYPES:
       - PolicyIntegerValue (0..65535)
       - PolicyBitStringValue (16 bit)

      DERIVED FROM PolicyImplicitVariable
      ABSTRACT FALSE
      PROPERTIES (none)

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Ron Cohen" <ronc@ntear.com>




          "Ron Cohen" <ronc@ntear.com>

          02/05/02 06:54 AM



To: "'Mircea Pana'" <mpana@nortelnetworks.com>, Robert Moore/Raleigh/IBM@IBMUS
cc: <bwijnen@lucent.com>, "'IETF Policy'" <policy@ietf.org>, <policy-admin@ietf.org>
Subject: RE: [Policy] Re: IP Protocol value range


Mircea, Bob


PCIMe defines:

PolicySNAPVariable: The protocol number over a Sub-Network Access
Protocol (SNAP) SAP encapsulation.

Explanation:

IEEE 802.2 defines two encapsulations, following the Ethernet length
field:

- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are represented
by the PolicySourceSAPVariable and PolicyDestinationSAPVariable.
- The second called the 802.2 SNAP encapsulation, and adds 5 bytes,
where the last two bytes are called the SNAP type. This is the
equivalent of the Ethernet Type. The intention was that the
PolicySNAPVariable would represent this two byte SNAP type field.

I suggest that we rename this variable to PolicySNAPTypeVriable and
remove the current ambiguity.


Ron






> -----Original Message-----
> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On
> Behalf Of Mircea Pana
> Sent: Monday, February 04, 2002 5:36 PM
> To: Robert Moore
> Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org
> Subject: Re: [Policy] Re: IP Protocol value range
>
>
> ...and just to add to my confusion, RFC1042 defines the *same* SNAP
> header as
> "an extension of the LLC header called the Sub-Network Access Protocol
> (SNAP)" :-0
>
> So, a reference to the actual definitions (RFC, IEEE etc.) may help if
> added in PCIMe. IMO, it is less important what exactly this (or other)
> PolicyVariable represents, more important is to define it
> unambiguously.
>
> Regards,
> Mircea.
>
>
> Robert Moore wrote:
> >
> > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point".
> > See
> > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for
> > Routed
> > >Protocols" for example. The SNAP header includes two fields: OUI (3
> > >octets) and PID (2 octets).
> > >
> > >I have two comments here:
> > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access
> > >Protocol".
> > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to
> > represent
> > >only the PID part of the SNAP header (2 octets)? Or should
> it reflect
> > >the entire header: OUI+PID (5 octets).
> >
> > To be honest, I don't know what we meant to refer to with
> > PolicySNAPVariable. (I think this class came from Cisco - in
> > any case, I know it didn't come from IBM.) Some possibilities:
> >
> > Currently in PCIMe: Sub-Network Access Protocol.
> >
> > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point.
> >
> > On acronymfinder.com: Subnetwork Access Protocol,
> > Standard Network Access Protocol (in bold, for some
> > reason), Small Network Access Package, and a bunch
> > of other options that are plainly not what we're
> > talking about.
> >
> > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell
> > us what we meant when we defined PolicySNAPVariable.
> > And maybe they'll even agree! :-)
> >
> > Regards,
> > Bob
> >
> > Bob Moore
> > Advanced Design and Technology
> > Application Integration Middleware Division
> > IBM Software Group
> > +1-919-254-4436
> > remoore@us.ibm.com
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>


--1__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A-- --0__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE1C4DFF2676A8f9e8a93@raleigh.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE1C4DFF2676A8f9e8a93@raleigh.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Tue Feb 5 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 NAA11748 for ; Tue, 5 Feb 2002 13:14:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22732 for policy-archive@odin.ietf.org; Tue, 5 Feb 2002 13:14: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 NAA22182; Tue, 5 Feb 2002 13:04:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22150 for ; Tue, 5 Feb 2002 13:04:25 -0500 (EST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11186 for ; Tue, 5 Feb 2002 13:04:23 -0500 (EST) Received: from user-vcaulvl.dsl.mindspring.com ([216.175.87.245] helo=ANDREWHOME) by albatross.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16Y9u9-00028J-00; Tue, 05 Feb 2002 10:01:17 -0800 From: "Andrew Smith" To: "Ron Cohen" Cc: "'IETF Policy'" Subject: RE: [Policy] Re: IP Protocol value range Date: Tue, 5 Feb 2002 10:30:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-reply-to: <1068327212765C4F995A07930BF7F24606AF37@oakenfold.lyciumnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Ron, But Mircea's original point was that that this definition for PolicySNAPVariable does not include the 24-bit/3-octet O.U.I. field. I think you are assuming that the only interesting O.U.I. is 00-00-00 which is the one specified by IEEE 802 Overview and Architecture (the doc that I referenced before - this was first defined in RFC 1042 but that is superceded by IEEE 802, at least that's what IEEE says) for encoding an Ethertype over IEEE 802.2 LLC layers. If that is the intent then the description should say something about the 00-00-00 being implicit. BTW, this encaps is often called "SNAP RFC 1042". But you might also want to include that other pesky encapsulation (from IEEE 802.1H) which uses O.U.I. 00-00-F8 for carrying a "Bridged Ethertype" (this isn't the place to go into the usage scenarios for this encaps - see 802.1H for that) which does occur still. This encaps is often called "SNAP 802.1H". And then there's the full SNAP 40-bit/5-octet usage but I think that's probably not worth including (does anyone here still use private SNAP protocols? I think perhaps some of the big vendors are still shipping stuff encapsulated that way - we got a lot of pressure, even 2 years ago when doing IEEE 802.1v-2001, to include this encapsulation). Suggestion: names like Policy1042EthertypeVariable, Policy8021hEthertypeVariable and PolicySNAPPidVariable might be more descriptive. Andrew Smith -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of Ron Cohen Sent: Tuesday, February 05, 2002 3:55 AM To: 'Mircea Pana'; 'Robert Moore' Cc: bwijnen@lucent.com; 'IETF Policy'; policy-admin@ietf.org Subject: RE: [Policy] Re: IP Protocol value range Mircea, Bob PCIMe defines: PolicySNAPVariable: The protocol number over a Sub-Network Access Protocol (SNAP) SAP encapsulation. Explanation: IEEE 802.2 defines two encapsulations, following the Ethernet length field: - One with 3 bytes, SSAP, DSAP and CNTRL. The first two are represented by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. - The second called the 802.2 SNAP encapsulation, and adds 5 bytes, where the last two bytes are called the SNAP type. This is the equivalent of the Ethernet Type. The intention was that the PolicySNAPVariable would represent this two byte SNAP type field. I suggest that we rename this variable to PolicySNAPTypeVriable and remove the current ambiguity. Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Mircea Pana > Sent: Monday, February 04, 2002 5:36 PM > To: Robert Moore > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > Subject: Re: [Policy] Re: IP Protocol value range > > > ...and just to add to my confusion, RFC1042 defines the *same* SNAP > header as > "an extension of the LLC header called the Sub-Network Access Protocol > (SNAP)" :-0 > > So, a reference to the actual definitions (RFC, IEEE etc.) may help if > added in PCIMe. IMO, it is less important what exactly this (or other) > PolicyVariable represents, more important is to define it > unambiguously. > > Regards, > Mircea. > > > Robert Moore wrote: > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > > See > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > Routed > > >Protocols" for example. The SNAP header includes two fields: OUI (3 > > >octets) and PID (2 octets). > > > > > >I have two comments here: > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > >Protocol". > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > represent > > >only the PID part of the SNAP header (2 octets)? Or should > it reflect > > >the entire header: OUI+PID (5 octets). > > > > To be honest, I don't know what we meant to refer to with > > PolicySNAPVariable. (I think this class came from Cisco - in > > any case, I know it didn't come from IBM.) Some possibilities: > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > On acronymfinder.com: Subnetwork Access Protocol, > > Standard Network Access Protocol (in bold, for some > > reason), Small Network Access Package, and a bunch > > of other options that are plainly not what we're > > talking about. > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > us what we meant when we defined PolicySNAPVariable. > > And maybe they'll even agree! :-) > > > > Regards, > > Bob > > > > Bob Moore > > Advanced Design and Technology > > Application Integration Middleware Division > > IBM Software Group > > +1-919-254-4436 > > remoore@us.ibm.com > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Tue Feb 5 14:07:43 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 OAA14186 for ; Tue, 5 Feb 2002 14:07:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26342 for policy-archive@odin.ietf.org; Tue, 5 Feb 2002 14:07:40 -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 NAA24923; Tue, 5 Feb 2002 13:53:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24896 for ; Tue, 5 Feb 2002 13:53:07 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13511 for ; Tue, 5 Feb 2002 13:53:04 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15IqYH19641; Tue, 5 Feb 2002 13:52:34 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15IqW322862; Tue, 5 Feb 2002 13:52:32 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8ZJBN89; Tue, 5 Feb 2002 13:52:31 -0500 Received: from americasm01.nt.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1AADTHNJ; Tue, 5 Feb 2002 13:52:32 -0500 Message-ID: <3C602AF0.BBE26B4A@americasm01.nt.com> Date: Tue, 05 Feb 2002 13:56:48 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Moore , IETF Policy Subject: [Fwd: RE: [Policy] Re: IP Protocol value range] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Bob, I find the proposed text to be specific enough to make it unambiguous. Maybe, just for the record, instead of "802.2" you could add "the IEEE 802.2". Thanks, Mircea. -------- Original Message -------- From: "Robert Moore" Subject: RE: [Policy] Re: IP Protocol value range To: "Ron Cohen" CC: bwijnen@lucent.com,"Pana, Mircea [CAR:5E30:EXCH]","'IETF Policy'" , policy-admin@ietf.org --1__=0ABBE1C4DFF2676A8f9e8a93df938690918c0ABBE1C4DFF2676A Content-type: text/plain; charset=US-ASCII Let me propose an update to the PCIMe text. If this isn't exactly right, it should at least be specific enough for people to comment on. It's a complete replacement for section 5.12.19: NAME PolicySNAPTypeVariable DESCRIPTION The value of the Sub-Network Access Protocol (SNAP) Type field for 802.2 SNAP encapsulation. ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - PolicyBitStringValue (16 bit) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Tue Feb 5 16:00: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 QAA19131 for ; Tue, 5 Feb 2002 16:00:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01539 for policy-archive@odin.ietf.org; Tue, 5 Feb 2002 16:00:28 -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 PAA01021; Tue, 5 Feb 2002 15:52:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00973 for ; Tue, 5 Feb 2002 15:52:22 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18916; Tue, 5 Feb 2002 15:52:17 -0500 (EST) Received: from [66.95.38.74] (HELO joel) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2769705; Tue, 05 Feb 2002 15:52:18 -0500 Message-Id: <4.2.2.20020205155123.00a76390@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Feb 2002 15:52:24 -0500 To: "Robert Moore" , "Ron Cohen" From: "Joel M. Halpern" Subject: RE: [Policy] Re: IP Protocol value range Cc: bwijnen@lucent.com, "'Mircea Pana'" , "'IETF Policy'" , policy-admin@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/related; type="text/plain"; boundary="=====================_887305==_.REL" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --=====================_887305==_.REL Content-Type: text/plain; charset="us-ascii"; format=flowed If we are going to do that, we should add a PolicySNAPOIDVariable as well. If you are looking at SNAP/SAP encapsulated information, you must check the OID for 0 before you can treat the last two bytes as an etherType. Yours, Joel M. Halpern At 12:56 PM 2/5/02 -0500, Robert Moore wrote: >Let me propose an update to the PCIMe text. If this isn't exactly right, >it should at least be specific enough for people to comment on. >It's a complete replacement for section 5.12.19: >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the Sub-Network Access >Protocol (SNAP) Type field for 802.2 SNAP encapsulation. > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - >PolicyBitStringValue (16 bit) > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > >Regards, >Bob > >Bob Moore >Advanced Design and Technology >Application Integration Middleware Division >IBM Software Group >+1-919-254-4436 >remoore@us.ibm.com > >d821c.jpg"Ron Cohen" > > >d8356.jpg >d836d.jpg >"Ron Cohen" > >02/05/02 06:54 AM > >d8380.jpg > >To:"'Mircea Pana'" , Robert Moore/Raleigh/IBM@IBMUS >cc:, "'IETF Policy'" , > >Subject:RE: [Policy] Re: IP Protocol value range > > >Mircea, Bob > > >PCIMe defines: > >PolicySNAPVariable: The protocol number over a Sub-Network Access >Protocol (SNAP) SAP encapsulation. > >Explanation: > >IEEE 802.2 defines two encapsulations, following the Ethernet length >field: > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are represented >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, >where the last two bytes are called the SNAP type. This is the >equivalent of the Ethernet Type. The intention was that the >PolicySNAPVariable would represent this two byte SNAP type field. > >I suggest that we rename this variable to PolicySNAPTypeVriable and >remove the current ambiguity. > > >Ron > > > > > > > > -----Original Message----- > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > Behalf Of Mircea Pana > > Sent: Monday, February 04, 2002 5:36 PM > > To: Robert Moore > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > ...and just to add to my confusion, RFC1042 defines the *same* SNAP > > header as > > "an extension of the LLC header called the Sub-Network Access Protocol > > (SNAP)" :-0 > > > > So, a reference to the actual definitions (RFC, IEEE etc.) may help if > > added in PCIMe. IMO, it is less important what exactly this (or other) > > PolicyVariable represents, more important is to define it > > unambiguously. > > > > Regards, > > Mircea. > > > > > > Robert Moore wrote: > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > > > See > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > > Routed > > > >Protocols" for example. The SNAP header includes two fields: OUI (3 > > > >octets) and PID (2 octets). > > > > > > > >I have two comments here: > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > > >Protocol". > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > > represent > > > >only the PID part of the SNAP header (2 octets)? Or should > > it reflect > > > >the entire header: OUI+PID (5 octets). > > > > > > To be honest, I don't know what we meant to refer to with > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > Standard Network Access Protocol (in bold, for some > > > reason), Small Network Access Package, and a bunch > > > of other options that are plainly not what we're > > > talking about. > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > us what we meant when we defined PolicySNAPVariable. > > > And maybe they'll even agree! :-) > > > > > > Regards, > > > Bob > > > > > > Bob Moore > > > Advanced Design and Technology > > > Application Integration Middleware Division > > > IBM Software Group > > > +1-919-254-4436 > > > remoore@us.ibm.com > > > > _______________________________________________ > > Policy mailing list > > Policy@ietf.org > > > https://www1.ietf.org/mailm > an/listinfo/policy > > > > --=====================_887305==_.REL Content-Type: image/jpeg; name="d821c.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020205155123.00a76390@mail.stevecrocker.com.0> Content-Disposition: inline; filename="d821c.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAQABADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3/wAC fDDwLa6f42+GviG6TxRr2i23iPS9ctPBngDwV8TvCfiTxD4A1nSdV8c2HxPuvC/hjQ49A8NfEu++ H12nw+8Eav8A2X4Z0PwH4g0n4d6bNY6FqHi/wDJ5FpU3h3TNb8ZfCXST4a1TSdS1D4i/EjwJ4k8L +HPC+i6lpXhu1+Helx+K/EvxF1zwQnjHXta+IXhq7g+IWl+OLvRPhbpnjvwZ8RtZvtX+FV3p3hnW ETwln/H/AMUSzi9+FfivXvGuoaT4+/4V98Ybbx9Po3xm0qHx1o2qeIr2aLTPHvwy8TWWk6/8f9F0 mLS9A8DeHdZ1Dxd8Ybo+A/hto/jyw8QalqEuu+Abnyv4SeHb21+J/gCLQPBOt6f4N8G+OH8S3njX wBofgO78bJ4zgez8QWtqNE8U+FPDPxDt7HR9T8GaF4h12z0Lx/fWFhPcaV8UdX0eeXW7rwhX4Nw/ whxFg8iz3OeIMVmnD2Y47B1MdlMM7y7h6lkWV5bU4fzLO8JxRgMXiMmwccZxtmmMznMvrPBSy3C1 q9XLONcNm+JlXzFwP9DsPgMVxTSxnFtLNKVbC4TM6WAxHDWAyWpjMPj8qweL4ZyrMMwxfDSwWYYm jj8tzinwx9XzuhhMNDhbC4nKeJcHXzPhnNMZkEP/2Q== --=====================_887305==_.REL Content-Type: image/jpeg; name="d8356.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020205155123.00a76390@mail.stevecrocker.com.1> Content-Disposition: inline; filename="d8356.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAABAEgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD51X/k 339p7/siN3/6rHwpXZfs/f8AIm+Kf+z3vEP/AKb/AI1UUVwZn/yN/DX/ALKnxH/9avMD/RnKf4PD v/ZJfRV/9bP6MB+i3hD/AJFDSP8As5L42/8Aryv9lisPxh/yb1a/9kf/AG5P/VH29FFf56eH/wDy JeMv+y8zf/4do+S8df8Ak3/il/2eDiv/ANZLLz4t/Zl/5Fz4H/8AYq/s9/8Apg0GvTPDv/JtU/8A 2UT4H/8ArLP7L1FFf2Rk/wDyUnGP/Y+8NP8A17fjmfb+Kv8Aydzg/wD7JDxz/wDU/wAOj6W8Of8A JHvFX/ZvP7I3/pm+B9fM/wAA/wDk5j/gpD/2Vb40f+ptpFFFeHwJ/wAllxX/ANkXkP8A67b6NB38 Mf8AKQviX/2afE/+tr4Kn35+w1/yR39oL/di/wDUK8E0UUV/kv4u/wDJy82/7JngX/1nqJ5XDv8A yPeIP+xB4R/+ug4JP//Z --=====================_887305==_.REL Content-Type: image/jpeg; name="d836d.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020205155123.00a76390@mail.stevecrocker.com.2> Content-Disposition: inline; filename="d836d.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAABAEgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD51X/k 339p7/siN3/6rHwpXZfs/f8AIm+Kf+z3vEP/AKb/AI1UUVwZn/yN/DX/ALKnxH/9avMD/RnKf4PD v/ZJfRV/9bP6MB+i3hD/AJFDSP8As5L42/8Aryv9lisPxh/yb1a/9kf/AG5P/VH29FFf56eH/wDy JeMv+y8zf/4do+S8df8Ak3/il/2eDiv/ANZLLz4t/Zl/5Fz4H/8AYq/s9/8Apg0GvTPDv/JtU/8A 2UT4H/8ArLP7L1FFf2Rk/wDyUnGP/Y+8NP8A17fjmfb+Kv8Aydzg/wD7JDxz/wDU/wAOj6W8Of8A JHvFX/ZvP7I3/pm+B9fM/wAA/wDk5j/gpD/2Vb40f+ptpFFFeHwJ/wAllxX/ANkXkP8A67b6NB38 Mf8AKQviX/2afE/+tr4Kn35+w1/yR39oL/di/wDUK8E0UUV/kv4u/wDJy82/7JngX/1nqJ5XDv8A yPeIP+xB4R/+ug4JP//Z --=====================_887305==_.REL Content-Type: image/jpeg; name="d8380.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020205155123.00a76390@mail.stevecrocker.com.3> Content-Disposition: inline; filename="d8380.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAABAEgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD51X/k 339p7/siN3/6rHwpXZfs/f8AIm+Kf+z3vEP/AKb/AI1UUVwZn/yN/DX/ALKnxH/9avMD/RnKf4PD v/ZJfRV/9bP6MB+i3hD/AJFDSP8As5L42/8Aryv9lisPxh/yb1a/9kf/AG5P/VH29FFf56eH/wDy JeMv+y8zf/4do+S8df8Ak3/il/2eDiv/ANZLLz4t/Zl/5Fz4H/8AYq/s9/8Apg0GvTPDv/JtU/8A 2UT4H/8ArLP7L1FFf2Rk/wDyUnGP/Y+8NP8A17fjmfb+Kv8Aydzg/wD7JDxz/wDU/wAOj6W8Of8A JHvFX/ZvP7I3/pm+B9fM/wAA/wDk5j/gpD/2Vb40f+ptpFFFeHwJ/wAllxX/ANkXkP8A67b6NB38 Mf8AKQviX/2afE/+tr4Kn35+w1/yR39oL/di/wDUK8E0UUV/kv4u/wDJy82/7JngX/1nqJ5XDv8A yPeIP+xB4R/+ug4JP//Z --=====================_887305==_.REL-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed Feb 6 06:00:37 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 GAA16544 for ; Wed, 6 Feb 2002 06:00:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA23782 for policy-archive@odin.ietf.org; Wed, 6 Feb 2002 06:00: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 FAA22851; Wed, 6 Feb 2002 05:50:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA22810 for ; Wed, 6 Feb 2002 05:50:30 -0500 (EST) Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16324; Wed, 6 Feb 2002 05:50:25 -0500 (EST) Received: from RONC (212.199.103.75) by mail.san.yahoo.com (5.5.056) id 3C584280001BC03B; Wed, 6 Feb 2002 02:38:13 -0800 From: "Ron Cohen" To: "'Joel M. Halpern'" , "'Robert Moore'" Cc: , "'Mircea Pana'" , "'IETF Policy'" , Subject: RE: [Policy] Re: IP Protocol value range Date: Wed, 6 Feb 2002 12:37:29 +0200 Message-ID: <1068327212765C4F995A07930BF7F24606AF3B@oakenfold.lyciumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <1068327212765C4F995A07930BF7F246069A9C@oakenfold.lyciumnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit I agree. I think that we should add an OID variable as well. I think that this would answer the remarks by Mircea as well as the input/solution proposed by Andrew. I'm assuming that we don't need to support the 40 bit OIU (see Andrew's email). How about the following definition: NAME PolicySNAPOIDVariable DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP) field for 802.2 SNAP encapsulation. The value 00-00-00 indicates the standard SNAP encapsulation (RFC 1042). OID value 00-00-F8 indicates the bridged ethertype (IEEE 802.1H) ALLOWED VALUE TYPES: - PolicyBitStringValue (24 bit) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Tuesday, February 05, 2002 10:52 PM > To: Robert Moore; Ron Cohen > Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy'; > policy-admin@ietf.org > Subject: RE: [Policy] Re: IP Protocol value range > > > If we are going to do that, we should add a PolicySNAPOIDVariable as > well. If you are looking at SNAP/SAP encapsulated > information, you must > check the OID for 0 before you can treat the last two bytes > as an etherType. > Yours, > Joel M. Halpern > > At 12:56 PM 2/5/02 -0500, Robert Moore wrote: > >Let me propose an update to the PCIMe text. If this isn't > exactly right, > >it should at least be specific enough for people to comment on. > >It's a complete replacement for section 5.12.19: > >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the > Sub-Network Access > >Protocol (SNAP) Type field for 802.2 > SNAP encapsulation. > > > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - > >PolicyBitStringValue (16 bit) > > > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > > > > >Regards, > >Bob > > > >Bob Moore > >Advanced Design and Technology > >Application Integration Middleware Division > >IBM Software Group > >+1-919-254-4436 > >remoore@us.ibm.com > > > >d821c.jpg"Ron Cohen" > > > > > >d8356.jpg > >d836d.jpg > >"Ron Cohen" > > > >02/05/02 06:54 AM > > > >d8380.jpg > > > >To:"'Mircea Pana'" , Robert > Moore/Raleigh/IBM@IBMUS > >cc:, "'IETF Policy'" , > > > >Subject:RE: [Policy] Re: IP Protocol value range > > > > > >Mircea, Bob > > > > > >PCIMe defines: > > > >PolicySNAPVariable: The protocol number over a Sub-Network Access > >Protocol (SNAP) SAP encapsulation. > > > >Explanation: > > > >IEEE 802.2 defines two encapsulations, following the Ethernet length > >field: > > > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are > represented > >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. > >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, > >where the last two bytes are called the SNAP type. This is the > >equivalent of the Ethernet Type. The intention was that the > >PolicySNAPVariable would represent this two byte SNAP type field. > > > >I suggest that we rename this variable to PolicySNAPTypeVriable and > >remove the current ambiguity. > > > > > >Ron > > > > > > > > > > > > > > > -----Original Message----- > > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > > Behalf Of Mircea Pana > > > Sent: Monday, February 04, 2002 5:36 PM > > > To: Robert Moore > > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > > > > ...and just to add to my confusion, RFC1042 defines the > *same* SNAP > > > header as > > > "an extension of the LLC header called the Sub-Network > Access Protocol > > > (SNAP)" :-0 > > > > > > So, a reference to the actual definitions (RFC, IEEE > etc.) may help if > > > added in PCIMe. IMO, it is less important what exactly > this (or other) > > > PolicyVariable represents, more important is to define it > > > unambiguously. > > > > > > Regards, > > > Mircea. > > > > > > > > > Robert Moore wrote: > > > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork > Attachment Point". > > > > See > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > > > Routed > > > > >Protocols" for example. The SNAP header includes two > fields: OUI (3 > > > > >octets) and PID (2 octets). > > > > > > > > > >I have two comments here: > > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > > > >Protocol". > > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > > > represent > > > > >only the PID part of the SNAP header (2 octets)? Or should > > > it reflect > > > > >the entire header: OUI+PID (5 octets). > > > > > > > > To be honest, I don't know what we meant to refer to with > > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > > Standard Network Access Protocol (in bold, for some > > > > reason), Small Network Access Package, and a bunch > > > > of other options that are plainly not what we're > > > > talking about. > > > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > > us what we meant when we defined PolicySNAPVariable. > > > > And maybe they'll even agree! :-) > > > > > > > > Regards, > > > > Bob > > > > > > > > Bob Moore > > > > Advanced Design and Technology > > > > Application Integration Middleware Division > > > > IBM Software Group > > > > +1-919-254-4436 > > > > remoore@us.ibm.com > > > > > > _______________________________________________ > > > Policy mailing list > > > Policy@ietf.org > > > > > > https://www1.ie tf.org/mailm > an/listinfo/policy > > > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed Feb 6 08:10:19 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 IAA18760 for ; Wed, 6 Feb 2002 08:10:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00300 for policy-archive@odin.ietf.org; Wed, 6 Feb 2002 08:10:22 -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 IAA29735; Wed, 6 Feb 2002 08:01:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29691 for ; Wed, 6 Feb 2002 08:01:12 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18603; Wed, 6 Feb 2002 08:01:07 -0500 (EST) Received: from [66.95.38.74] (HELO joel) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2770469; Wed, 06 Feb 2002 08:01:04 -0500 Message-Id: <4.2.2.20020206080016.00ab7c60@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 06 Feb 2002 08:00:59 -0500 To: "Robert Moore" , "Ron Cohen" From: "Joel M. Halpern" Subject: RE: [Policy] Re: IP Protocol value range Cc: bwijnen@lucent.com, "'Mircea Pana'" , "'IETF Policy'" , policy-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/related; type="text/plain"; boundary="=====================_33615604==_.REL" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --=====================_33615604==_.REL Content-Type: text/plain; charset="us-ascii"; format=flowed [Retransmission, this time saying the right thing...] If we are going to do that, we should add a PolicySNAPOIUIVariable as well. If you are looking at SNAP/SAP encapsulated information, you must check the OUI for 0 before you can treat the last two bytes as an etherType. Yours, Joel M. Halpern [I wrote OID for some reason last time. I meant OUI.] At 12:56 PM 2/5/02 -0500, Robert Moore wrote: >Let me propose an update to the PCIMe text. If this isn't exactly right, >it should at least be specific enough for people to comment on. >It's a complete replacement for section 5.12.19: >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the Sub-Network Access >Protocol (SNAP) Type field for 802.2 SNAP encapsulation. > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - >PolicyBitStringValue (16 bit) > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > > >Regards, >Bob > >Bob Moore >Advanced Design and Technology >Application Integration Middleware Division >IBM Software Group >+1-919-254-4436 >remoore@us.ibm.com > >200e7d0.jpg"Ron Cohen" > > >200e7e6.jpg >200e7f8.jpg >"Ron Cohen" > >02/05/02 06:54 AM > > >200e80c.jpg > >To:"'Mircea Pana'" , Robert Moore/Raleigh/IBM@IBMUS >cc:, "'IETF Policy'" , > >Subject:RE: [Policy] Re: IP Protocol value range > > >Mircea, Bob > > >PCIMe defines: > >PolicySNAPVariable: The protocol number over a Sub-Network Access >Protocol (SNAP) SAP encapsulation. > >Explanation: > >IEEE 802.2 defines two encapsulations, following the Ethernet length >field: > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are represented >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, >where the last two bytes are called the SNAP type. This is the >equivalent of the Ethernet Type. The intention was that the >PolicySNAPVariable would represent this two byte SNAP type field. > >I suggest that we rename this variable to PolicySNAPTypeVriable and >remove the current ambiguity. > > >Ron > > > > > > > > -----Original Message----- > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > Behalf Of Mircea Pana > > Sent: Monday, February 04, 2002 5:36 PM > > To: Robert Moore > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > ...and just to add to my confusion, RFC1042 defines the *same* SNAP > > header as > > "an extension of the LLC header called the Sub-Network Access Protocol > > (SNAP)" :-0 > > > > So, a reference to the actual definitions (RFC, IEEE etc.) may help if > > added in PCIMe. IMO, it is less important what exactly this (or other) > > PolicyVariable represents, more important is to define it > > unambiguously. > > > > Regards, > > Mircea. > > > > > > Robert Moore wrote: > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork Attachment Point". > > > See > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > > Routed > > > >Protocols" for example. The SNAP header includes two fields: OUI (3 > > > >octets) and PID (2 octets). > > > > > > > >I have two comments here: > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > > >Protocol". > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > > represent > > > >only the PID part of the SNAP header (2 octets)? Or should > > it reflect > > > >the entire header: OUI+PID (5 octets). > > > > > > To be honest, I don't know what we meant to refer to with > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > Standard Network Access Protocol (in bold, for some > > > reason), Small Network Access Package, and a bunch > > > of other options that are plainly not what we're > > > talking about. > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > us what we meant when we defined PolicySNAPVariable. > > > And maybe they'll even agree! :-) > > > > > > Regards, > > > Bob > > > > > > Bob Moore > > > Advanced Design and Technology > > > Application Integration Middleware Division > > > IBM Software Group > > > +1-919-254-4436 > > > remoore@us.ibm.com > > > > _______________________________________________ > > Policy mailing list > > Policy@ietf.org > > > https://www1.ietf.org/mailm > an/listinfo/policy > > > --=====================_33615604==_.REL Content-Type: image/jpeg; name="200e7d0.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020206080016.00ab7c60@mail.stevecrocker.com.4> Content-Disposition: inline; filename="200e7d0.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAQABADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3/wAC fDDwLa6f42+GviG6TxRr2i23iPS9ctPBngDwV8TvCfiTxD4A1nSdV8c2HxPuvC/hjQ49A8NfEu++ H12nw+8Eav8A2X4Z0PwH4g0n4d6bNY6FqHi/wDJ5FpU3h3TNb8ZfCXST4a1TSdS1D4i/EjwJ4k8L +HPC+i6lpXhu1+Helx+K/EvxF1zwQnjHXta+IXhq7g+IWl+OLvRPhbpnjvwZ8RtZvtX+FV3p3hnW ETwln/H/AMUSzi9+FfivXvGuoaT4+/4V98Ybbx9Po3xm0qHx1o2qeIr2aLTPHvwy8TWWk6/8f9F0 mLS9A8DeHdZ1Dxd8Ybo+A/hto/jyw8QalqEuu+Abnyv4SeHb21+J/gCLQPBOt6f4N8G+OH8S3njX wBofgO78bJ4zgez8QWtqNE8U+FPDPxDt7HR9T8GaF4h12z0Lx/fWFhPcaV8UdX0eeXW7rwhX4Nw/ whxFg8iz3OeIMVmnD2Y47B1MdlMM7y7h6lkWV5bU4fzLO8JxRgMXiMmwccZxtmmMznMvrPBSy3C1 q9XLONcNm+JlXzFwP9DsPgMVxTSxnFtLNKVbC4TM6WAxHDWAyWpjMPj8qweL4ZyrMMwxfDSwWYYm jj8tzinwx9XzuhhMNDhbC4nKeJcHXzPhnNMZkEP/2Q== --=====================_33615604==_.REL Content-Type: image/jpeg; name="200e7e6.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020206080016.00ab7c60@mail.stevecrocker.com.5> Content-Disposition: inline; filename="200e7e6.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAABAEgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD51X/k 339p7/siN3/6rHwpXZfs/f8AIm+Kf+z3vEP/AKb/AI1UUVwZn/yN/DX/ALKnxH/9avMD/RnKf4PD v/ZJfRV/9bP6MB+i3hD/AJFDSP8As5L42/8Aryv9lisPxh/yb1a/9kf/AG5P/VH29FFf56eH/wDy JeMv+y8zf/4do+S8df8Ak3/il/2eDiv/ANZLLz4t/Zl/5Fz4H/8AYq/s9/8Apg0GvTPDv/JtU/8A 2UT4H/8ArLP7L1FFf2Rk/wDyUnGP/Y+8NP8A17fjmfb+Kv8Aydzg/wD7JDxz/wDU/wAOj6W8Of8A JHvFX/ZvP7I3/pm+B9fM/wAA/wDk5j/gpD/2Vb40f+ptpFFFeHwJ/wAllxX/ANkXkP8A67b6NB38 Mf8AKQviX/2afE/+tr4Kn35+w1/yR39oL/di/wDUK8E0UUV/kv4u/wDJy82/7JngX/1nqJ5XDv8A yPeIP+xB4R/+ug4JP//Z --=====================_33615604==_.REL Content-Type: image/jpeg; name="200e7f8.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020206080016.00ab7c60@mail.stevecrocker.com.6> Content-Disposition: inline; filename="200e7f8.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAABAEgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD51X/k 339p7/siN3/6rHwpXZfs/f8AIm+Kf+z3vEP/AKb/AI1UUVwZn/yN/DX/ALKnxH/9avMD/RnKf4PD v/ZJfRV/9bP6MB+i3hD/AJFDSP8As5L42/8Aryv9lisPxh/yb1a/9kf/AG5P/VH29FFf56eH/wDy JeMv+y8zf/4do+S8df8Ak3/il/2eDiv/ANZLLz4t/Zl/5Fz4H/8AYq/s9/8Apg0GvTPDv/JtU/8A 2UT4H/8ArLP7L1FFf2Rk/wDyUnGP/Y+8NP8A17fjmfb+Kv8Aydzg/wD7JDxz/wDU/wAOj6W8Of8A JHvFX/ZvP7I3/pm+B9fM/wAA/wDk5j/gpD/2Vb40f+ptpFFFeHwJ/wAllxX/ANkXkP8A67b6NB38 Mf8AKQviX/2afE/+tr4Kn35+w1/yR39oL/di/wDUK8E0UUV/kv4u/wDJy82/7JngX/1nqJ5XDv8A yPeIP+xB4R/+ug4JP//Z --=====================_33615604==_.REL Content-Type: image/jpeg; name="200e80c.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.2.2.20020206080016.00ab7c60@mail.stevecrocker.com.7> Content-Disposition: inline; filename="200e80c.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAABAEgDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD51X/k 339p7/siN3/6rHwpXZfs/f8AIm+Kf+z3vEP/AKb/AI1UUVwZn/yN/DX/ALKnxH/9avMD/RnKf4PD v/ZJfRV/9bP6MB+i3hD/AJFDSP8As5L42/8Aryv9lisPxh/yb1a/9kf/AG5P/VH29FFf56eH/wDy JeMv+y8zf/4do+S8df8Ak3/il/2eDiv/ANZLLz4t/Zl/5Fz4H/8AYq/s9/8Apg0GvTPDv/JtU/8A 2UT4H/8ArLP7L1FFf2Rk/wDyUnGP/Y+8NP8A17fjmfb+Kv8Aydzg/wD7JDxz/wDU/wAOj6W8Of8A JHvFX/ZvP7I3/pm+B9fM/wAA/wDk5j/gpD/2Vb40f+ptpFFFeHwJ/wAllxX/ANkXkP8A67b6NB38 Mf8AKQviX/2afE/+tr4Kn35+w1/yR39oL/di/wDUK8E0UUV/kv4u/wDJy82/7JngX/1nqJ5XDv8A yPeIP+xB4R/+ug4JP//Z --=====================_33615604==_.REL-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Thu Feb 7 10:40:55 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 KAA00017 for ; Thu, 7 Feb 2002 10:40:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26763 for policy-archive@odin.ietf.org; Thu, 7 Feb 2002 10:40:56 -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 KAA25726; Thu, 7 Feb 2002 10:25:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25678 for ; Thu, 7 Feb 2002 10:25:29 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29670; Thu, 7 Feb 2002 10:25:23 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA86594; Thu, 7 Feb 2002 09:20:03 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g17FOBC155352; Thu, 7 Feb 2002 10:24:22 -0500 Subject: RE: [Policy] Re: IP Protocol value range To: "Ron Cohen" Cc: bwijnen@lucent.com, "'Joel M. Halpern'" , "'Mircea Pana'" , "'IETF Policy'" , policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Thu, 7 Feb 2002 10:28:24 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_01072002 Beta 5|January 07, 2002) at 02/07/2002 10:24:44 AM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54 Content-type: multipart/alternative; Boundary="1__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54" --1__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54 Content-type: text/plain; charset=US-ASCII Somehow I seem to be the only person here without a copy of the relevant 802.2 spec. So I have no way of deciding between Ron's OID proposal and Joel's OUI one. I agree with Mircea that the most important thing here is to state, very clearly and unambiguously, the contents of each of our variable classes. I'm just not in a position to do that myself. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Ron Cohen" To: "'Joel M. Halpern'" , Robert Moore/Raleigh/IBM@IBMUS 02/06/02 05:37 AM cc: , "'Mircea Pana'" , "'IETF Policy'" , Subject: RE: [Policy] Re: IP Protocol value range I agree. I think that we should add an OID variable as well. I think that this would answer the remarks by Mircea as well as the input/solution proposed by Andrew. I'm assuming that we don't need to support the 40 bit OIU (see Andrew's email). How about the following definition: NAME PolicySNAPOIDVariable DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP) field for 802.2 SNAP encapsulation. The value 00-00-00 indicates the standard SNAP encapsulation (RFC 1042). OID value 00-00-F8 indicates the bridged ethertype (IEEE 802.1H) ALLOWED VALUE TYPES: - PolicyBitStringValue (24 bit) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Tuesday, February 05, 2002 10:52 PM > To: Robert Moore; Ron Cohen > Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy'; > policy-admin@ietf.org > Subject: RE: [Policy] Re: IP Protocol value range > > > If we are going to do that, we should add a PolicySNAPOIDVariable as > well. If you are looking at SNAP/SAP encapsulated > information, you must > check the OID for 0 before you can treat the last two bytes > as an etherType. > Yours, > Joel M. Halpern > > At 12:56 PM 2/5/02 -0500, Robert Moore wrote: > >Let me propose an update to the PCIMe text. If this isn't > exactly right, > >it should at least be specific enough for people to comment on. > >It's a complete replacement for section 5.12.19: > >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the > Sub-Network Access > >Protocol (SNAP) Type field for 802.2 > SNAP encapsulation. > > > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - > >PolicyBitStringValue (16 bit) > > > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > > > > >Regards, > >Bob > > > >Bob Moore > >Advanced Design and Technology > >Application Integration Middleware Division > >IBM Software Group > >+1-919-254-4436 > >remoore@us.ibm.com > > > >d821c.jpg"Ron Cohen" > > > > > >d8356.jpg > >d836d.jpg > >"Ron Cohen" > > > >02/05/02 06:54 AM > > > >d8380.jpg > > > >To:"'Mircea Pana'" , Robert > Moore/Raleigh/IBM@IBMUS > >cc:, "'IETF Policy'" , > > > >Subject:RE: [Policy] Re: IP Protocol value range > > > > > >Mircea, Bob > > > > > >PCIMe defines: > > > >PolicySNAPVariable: The protocol number over a Sub-Network Access > >Protocol (SNAP) SAP encapsulation. > > > >Explanation: > > > >IEEE 802.2 defines two encapsulations, following the Ethernet length > >field: > > > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are > represented > >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. > >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, > >where the last two bytes are called the SNAP type. This is the > >equivalent of the Ethernet Type. The intention was that the > >PolicySNAPVariable would represent this two byte SNAP type field. > > > >I suggest that we rename this variable to PolicySNAPTypeVriable and > >remove the current ambiguity. > > > > > >Ron > > > > > > > > > > > > > > > -----Original Message----- > > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > > Behalf Of Mircea Pana > > > Sent: Monday, February 04, 2002 5:36 PM > > > To: Robert Moore > > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > > > > ...and just to add to my confusion, RFC1042 defines the > *same* SNAP > > > header as > > > "an extension of the LLC header called the Sub-Network > Access Protocol > > > (SNAP)" :-0 > > > > > > So, a reference to the actual definitions (RFC, IEEE > etc.) may help if > > > added in PCIMe. IMO, it is less important what exactly > this (or other) > > > PolicyVariable represents, more important is to define it > > > unambiguously. > > > > > > Regards, > > > Mircea. > > > > > > > > > Robert Moore wrote: > > > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork > Attachment Point". > > > > See > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > > > Routed > > > > >Protocols" for example. The SNAP header includes two > fields: OUI (3 > > > > >octets) and PID (2 octets). > > > > > > > > > >I have two comments here: > > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > > > >Protocol". > > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > > > represent > > > > >only the PID part of the SNAP header (2 octets)? Or should > > > it reflect > > > > >the entire header: OUI+PID (5 octets). > > > > > > > > To be honest, I don't know what we meant to refer to with > > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > > Standard Network Access Protocol (in bold, for some > > > > reason), Small Network Access Package, and a bunch > > > > of other options that are plainly not what we're > > > > talking about. > > > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > > us what we meant when we defined PolicySNAPVariable. > > > > And maybe they'll even agree! :-) > > > > > > > > Regards, > > > > Bob > > > > > > > > Bob Moore > > > > Advanced Design and Technology > > > > Application Integration Middleware Division > > > > IBM Software Group > > > > +1-919-254-4436 > > > > remoore@us.ibm.com > > > > > > _______________________________________________ > > > Policy mailing list > > > Policy@ietf.org > > > > > > https://www1.ie tf.org/mailm > an/listinfo/policy > > > > --1__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Somehow I seem to be the only person here without a copy of the relevant 802.2 spec. So I have no way of deciding between Ron's OID proposal and Joel's OUI one. I agree with Mircea that the most important thing here is to state, very clearly and unambiguously, the contents of each of our variable classes. I'm just not in a position to do that myself.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Ron Cohen" <ronc@ntear.com>




          "Ron Cohen" <ronc@ntear.com>

          02/06/02 05:37 AM



To: "'Joel M. Halpern'" <joel@stevecrocker.com>, Robert Moore/Raleigh/IBM@IBMUS
cc: <bwijnen@lucent.com>, "'Mircea Pana'" <mpana@nortelnetworks.com>, "'IETF Policy'" <policy@ietf.org>, <policy-admin@ietf.org>
Subject: RE: [Policy] Re: IP Protocol value range



I agree. I think that we should add an OID variable as well. I think
that this would answer the remarks by Mircea as well as the
input/solution proposed by Andrew. I'm assuming that we don't need to
support the 40 bit OIU (see Andrew's email).

How about the following definition:

NAME PolicySNAPOIDVariable
DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP)
field for 802.2 SNAP encapsulation.
The value 00-00-00 indicates the standard SNAP encapsulation (RFC 1042).
OID value 00-00-F8 indicates the bridged ethertype (IEEE
802.1H)

ALLOWED VALUE TYPES:
- PolicyBitStringValue (24 bit)

DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)


Ron

> -----Original Message-----
> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On
> Behalf Of Joel M. Halpern
> Sent: Tuesday, February 05, 2002 10:52 PM
> To: Robert Moore; Ron Cohen
> Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy';
> policy-admin@ietf.org
> Subject: RE: [Policy] Re: IP Protocol value range
>
>
> If we are going to do that, we should add a PolicySNAPOIDVariable as
> well. If you are looking at SNAP/SAP encapsulated
> information, you must
> check the OID for 0 before you can treat the last two bytes
> as an etherType.
> Yours,
> Joel M. Halpern
>
> At 12:56 PM 2/5/02 -0500, Robert Moore wrote:
> >Let me propose an update to the PCIMe text. If this isn't
> exactly right,
> >it should at least be specific enough for people to comment on.
> >It's a complete replacement for section 5.12.19:
> >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the
> Sub-Network Access
> >Protocol (SNAP) Type field for 802.2
> SNAP encapsulation.
> >
> >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) -
> >PolicyBitStringValue (16 bit)
> >
> >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none)
> >
> >
> >Regards,
> >Bob
> >
> >Bob Moore
> >Advanced Design and Technology
> >Application Integration Middleware Division
> >IBM Software Group
> >+1-919-254-4436
> >remoore@us.ibm.com
> >
> >d821c.jpg"Ron Cohen" <ronc@ntear.com>
> >
> >
> >d8356.jpg
> >d836d.jpg
> >"Ron Cohen" <ronc@ntear.com>
> >
> >02/05/02 06:54 AM
> >
> >d8380.jpg
> >
> >To:"'Mircea Pana'" <mpana@nortelnetworks.com>, Robert
> Moore/Raleigh/IBM@IBMUS
> >cc:<bwijnen@lucent.com>, "'IETF Policy'" <policy@ietf.org>,
> ><policy-admin@ietf.org>
> >Subject:RE: [Policy] Re: IP Protocol value range
> >
> >
> >Mircea, Bob
> >
> >
> >PCIMe defines:
> >
> >PolicySNAPVariable: The protocol number over a Sub-Network Access
> >Protocol (SNAP) SAP encapsulation.
> >
> >Explanation:
> >
> >IEEE 802.2 defines two encapsulations, following the Ethernet length
> >field:
> >
> >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are
> represented
> >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable.
> >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes,
> >where the last two bytes are called the SNAP type. This is the
> >equivalent of the Ethernet Type. The intention was that the
> >PolicySNAPVariable would represent this two byte SNAP type field.
> >
> >I suggest that we rename this variable to PolicySNAPTypeVriable and
> >remove the current ambiguity.
> >
> >
> >Ron
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On
> > > Behalf Of Mircea Pana
> > > Sent: Monday, February 04, 2002 5:36 PM
> > > To: Robert Moore
> > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org
> > > Subject: Re: [Policy] Re: IP Protocol value range
> > >
> > >
> > > ...and just to add to my confusion, RFC1042 defines the
> *same* SNAP
> > > header as
> > > "an extension of the LLC header called the Sub-Network
> Access Protocol
> > > (SNAP)" :-0
> > >
> > > So, a reference to the actual definitions (RFC, IEEE
> etc.) may help if
> > > added in PCIMe. IMO, it is less important what exactly
> this (or other)
> > > PolicyVariable represents, more important is to define it
> > > unambiguously.
> > >
> > > Regards,
> > > Mircea.
> > >
> > >
> > > Robert Moore wrote:
> > > >
> > > > >SNAP actually stands for "IEEE 802.1a SubNetwork
> Attachment Point".
> > > > See
> > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for
> > > > Routed
> > > > >Protocols" for example. The SNAP header includes two
> fields: OUI (3
> > > > >octets) and PID (2 octets).
> > > > >
> > > > >I have two comments here:
> > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access
> > > > >Protocol".
> > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to
> > > > represent
> > > > >only the PID part of the SNAP header (2 octets)? Or should
> > > it reflect
> > > > >the entire header: OUI+PID (5 octets).
> > > >
> > > > To be honest, I don't know what we meant to refer to with
> > > > PolicySNAPVariable. (I think this class came from Cisco - in
> > > > any case, I know it didn't come from IBM.) Some possibilities:
> > > >
> > > > Currently in PCIMe: Sub-Network Access Protocol.
> > > >
> > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point.
> > > >
> > > > On acronymfinder.com: Subnetwork Access Protocol,
> > > > Standard Network Access Protocol (in bold, for some
> > > > reason), Small Network Access Package, and a bunch
> > > > of other options that are plainly not what we're
> > > > talking about.
> > > >
> > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell
> > > > us what we meant when we defined PolicySNAPVariable.
> > > > And maybe they'll even agree! :-)
> > > >
> > > > Regards,
> > > > Bob
> > > >
> > > > Bob Moore
> > > > Advanced Design and Technology
> > > > Application Integration Middleware Division
> > > > IBM Software Group
> > > > +1-919-254-4436
> > > > remoore@us.ibm.com
> > >
> > > _______________________________________________
> > > Policy mailing list
> > > Policy@ietf.org
> > >
> >
> <https://www1.ietf.org/mailman/listinfo/policy>https://www1.ie
tf.org/mailm
> an/listinfo/policy
> >
>
>


--1__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54-- --0__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE1CADFC71C548f9e8a93@raleigh.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE1CADFC71C548f9e8a93@raleigh.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE1CADFC71C548f9e8a93df938690918c0ABBE1CADFC71C54-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Thu Feb 7 11:25: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 LAA01307 for ; Thu, 7 Feb 2002 11:25:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29243 for policy-archive@odin.ietf.org; Thu, 7 Feb 2002 11:25:43 -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 LAA28472; Thu, 7 Feb 2002 11:09:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28421 for ; Thu, 7 Feb 2002 11:09:37 -0500 (EST) Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01015; Thu, 7 Feb 2002 11:09:33 -0500 (EST) Received: from RONC (212.199.103.75) by mail.san.yahoo.com (5.5.056) id 3C5842800021E9F7; Thu, 7 Feb 2002 08:08:18 -0800 From: "Ron Cohen" To: "'Robert Moore'" Cc: , "'Joel M. Halpern'" , "'Mircea Pana'" , "'IETF Policy'" , Subject: RE: [Policy] Re: IP Protocol value range Date: Thu, 7 Feb 2002 18:07:17 +0200 Message-ID: <1068327212765C4F995A07930BF7F24606AF55@oakenfold.lyciumnetworks.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0008_01C1B002.4F404600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <1068327212765C4F995A07930BF7F246069ABC@oakenfold.lyciumnetworks.com> Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1B002.4F404600 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C1B002.4F404600" ------=_NextPart_001_0009_01C1B002.4F404600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Its OUI - my mistake Ron -----Original Message----- From: Robert Moore [mailto:remoore@us.ibm.com] Sent: Thursday, February 07, 2002 5:28 PM To: Ron Cohen Cc: bwijnen@lucent.com; 'Joel M. Halpern'; 'Mircea Pana'; 'IETF Policy'; policy-admin@ietf.org Subject: RE: [Policy] Re: IP Protocol value range Somehow I seem to be the only person here without a copy of the relevant 802.2 spec. So I have no way of deciding between Ron's OID proposal and Joel's OUI one. I agree with Mircea that the most important thing here is to state, very clearly and unambiguously, the contents of each of our variable classes. I'm just not in a position to do that myself. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Ron Cohen" "Ron Cohen" 02/06/02 05:37 AM To: "'Joel M. Halpern'" , Robert Moore/Raleigh/IBM@IBMUS cc: , "'Mircea Pana'" , "'IETF Policy'" , Subject: RE: [Policy] Re: IP Protocol value range I agree. I think that we should add an OID variable as well. I think that this would answer the remarks by Mircea as well as the input/solution proposed by Andrew. I'm assuming that we don't need to support the 40 bit OIU (see Andrew's email). How about the following definition: NAME PolicySNAPOIDVariable DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP) field for 802.2 SNAP encapsulation. The value 00-00-00 indicates the standard SNAP encapsulation (RFC 1042). OID value 00-00-F8 indicates the bridged ethertype (IEEE 802.1H) ALLOWED VALUE TYPES: - PolicyBitStringValue (24 bit) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Tuesday, February 05, 2002 10:52 PM > To: Robert Moore; Ron Cohen > Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy'; > policy-admin@ietf.org > Subject: RE: [Policy] Re: IP Protocol value range > > > If we are going to do that, we should add a PolicySNAPOIDVariable as > well. If you are looking at SNAP/SAP encapsulated > information, you must > check the OID for 0 before you can treat the last two bytes > as an etherType. > Yours, > Joel M. Halpern > > At 12:56 PM 2/5/02 -0500, Robert Moore wrote: > >Let me propose an update to the PCIMe text. If this isn't > exactly right, > >it should at least be specific enough for people to comment on. > >It's a complete replacement for section 5.12.19: > >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the > Sub-Network Access > >Protocol (SNAP) Type field for 802.2 > SNAP encapsulation. > > > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - > >PolicyBitStringValue (16 bit) > > > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > > > > >Regards, > >Bob > > > >Bob Moore > >Advanced Design and Technology > >Application Integration Middleware Division > >IBM Software Group > >+1-919-254-4436 > >remoore@us.ibm.com > > > >d821c.jpg"Ron Cohen" > > > > > >d8356.jpg > >d836d.jpg > >"Ron Cohen" > > > >02/05/02 06:54 AM > > > >d8380.jpg > > > >To:"'Mircea Pana'" , Robert > Moore/Raleigh/IBM@IBMUS > >cc:, "'IETF Policy'" , > > > >Subject:RE: [Policy] Re: IP Protocol value range > > > > > >Mircea, Bob > > > > > >PCIMe defines: > > > >PolicySNAPVariable: The protocol number over a Sub-Network Access > >Protocol (SNAP) SAP encapsulation. > > > >Explanation: > > > >IEEE 802.2 defines two encapsulations, following the Ethernet length > >field: > > > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are > represented > >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. > >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, > >where the last two bytes are called the SNAP type. This is the > >equivalent of the Ethernet Type. The intention was that the > >PolicySNAPVariable would represent this two byte SNAP type field. > > > >I suggest that we rename this variable to PolicySNAPTypeVriable and > >remove the current ambiguity. > > > > > >Ron > > > > > > > > > > > > > > > -----Original Message----- > > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > > Behalf Of Mircea Pana > > > Sent: Monday, February 04, 2002 5:36 PM > > > To: Robert Moore > > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > > > > ...and just to add to my confusion, RFC1042 defines the > *same* SNAP > > > header as > > > "an extension of the LLC header called the Sub-Network > Access Protocol > > > (SNAP)" :-0 > > > > > > So, a reference to the actual definitions (RFC, IEEE > etc.) may help if > > > added in PCIMe. IMO, it is less important what exactly > this (or other) > > > PolicyVariable represents, more important is to define it > > > unambiguously. > > > > > > Regards, > > > Mircea. > > > > > > > > > Robert Moore wrote: > > > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork > Attachment Point". > > > > See > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > > > Routed > > > > >Protocols" for example. The SNAP header includes two > fields: OUI (3 > > > > >octets) and PID (2 octets). > > > > > > > > > >I have two comments here: > > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > > > >Protocol". > > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > > > represent > > > > >only the PID part of the SNAP header (2 octets)? Or should > > > it reflect > > > > >the entire header: OUI+PID (5 octets). > > > > > > > > To be honest, I don't know what we meant to refer to with > > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > > Standard Network Access Protocol (in bold, for some > > > > reason), Small Network Access Package, and a bunch > > > > of other options that are plainly not what we're > > > > talking about. > > > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > > us what we meant when we defined PolicySNAPVariable. > > > > And maybe they'll even agree! :-) > > > > > > > > Regards, > > > > Bob > > > > > > > > Bob Moore > > > > Advanced Design and Technology > > > > Application Integration Middleware Division > > > > IBM Software Group > > > > +1-919-254-4436 > > > > remoore@us.ibm.com > > > > > > _______________________________________________ > > > Policy mailing list > > > Policy@ietf.org > > > > > > https://www1.ie tf.org/mailm > an/listinfo/policy > > > > ------=_NextPart_001_0009_01C1B002.4F404600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
Its=20 OUI - my mistake
 
Ron
-----Original Message-----
From: = Robert Moore=20 [mailto:remoore@us.ibm.com]
Sent: Thursday, February 07, = 2002 5:28=20 PM
To: Ron Cohen
Cc: bwijnen@lucent.com; 'Joel M.=20 Halpern'; 'Mircea Pana'; 'IETF Policy';=20 policy-admin@ietf.org
Subject: RE: [Policy] Re: IP Protocol = value=20 range

Somehow I seem to be the only person here = without a=20 copy of the relevant 802.2 spec. So I have no way of deciding between = Ron's=20 OID proposal and Joel's OUI one. I agree with Mircea that the most = important=20 thing here is to state, very clearly and unambiguously, the contents = of each=20 of our variable classes. I'm just not in a position to do that=20 myself.

Regards,
Bob

Bob Moore
Advanced Design and = Technology
Application Integration Middleware Division
IBM = Software=20 Group
+1-919-254-4436
remoore@us.ibm.com

3D""=20"Ron Cohen"=20 <ronc@ntear.com>


3D""
          "Ron Cohen"=20 <ronc@ntear.com>=20

          02/06/02 05:37 = AM

3D""
 3D""

To:=20 "'Joel M. Halpern'" = <joel@stevecrocker.com>,=20 Robert Moore/Raleigh/IBM@IBMUS
cc: = <bwijnen@lucent.com>, "'Mircea Pana'"=20 <mpana@nortelnetworks.com>, "'IETF Policy'"=20 <policy@ietf.org>, = <policy-admin@ietf.org>
Subject: RE: [Policy] Re: IP = Protocol value=20 range



I=20 agree. I think that we should add an OID variable as well. I = think
that=20 this would answer the remarks by Mircea as well as = the
input/solution=20 proposed by Andrew. I'm assuming that we don't need to
support the = 40 bit=20 OIU (see Andrew's email).

How about the following=20 definition:

NAME PolicySNAPOIDVariable
DESCRIPTION The OID = value of=20 the Sub-Network Access Protocol (SNAP)
field for 802.2 SNAP = encapsulation.=20
The value 00-00-00 indicates the standard SNAP encapsulation (RFC=20 1042).
OID value 00-00-F8 indicates the bridged ethertype=20 (IEEE
802.1H)

ALLOWED VALUE TYPES:
- PolicyBitStringValue = (24=20 bit)

DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE=20
PROPERTIES (none)


Ron

> -----Original=20 Message-----
> From: policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org] On
> Behalf Of Joel M. = Halpern
>=20 Sent: Tuesday, February 05, 2002 10:52 PM
> To: Robert Moore; = Ron=20 Cohen
> Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy'; =
>=20 policy-admin@ietf.org
> Subject: RE: [Policy] Re: IP Protocol = value=20 range
>
>
> If we are going to do that, we should = add a=20 PolicySNAPOIDVariable as
> well. If you are looking at SNAP/SAP = encapsulated
> information, you must
> check the OID for = 0=20 before you can treat the last two bytes
> as an = etherType.
>=20 Yours,
> Joel M. Halpern
>
> At 12:56 PM 2/5/02 = -0500,=20 Robert Moore wrote:
> >Let me propose an update to the PCIMe = text. If=20 this isn't
> exactly right,
> >it should at least be = specific=20 enough for people to comment on.
> >It's a complete = replacement for=20 section 5.12.19:
> >NAMEPolicySNAPTypeVariable DESCRIPTIONThe = value=20 of the
> Sub-Network Access
> >Protocol (SNAP) Type = field for=20 802.2
> SNAP encapsulation.
> >
> >ALLOWED = VALUE=20 TYPES: - PolicyIntegerValue (0..65535) -
> = >PolicyBitStringValue (16=20 bit)
> >
> >DERIVED FROMPolicyImplicitVariable = ABSTRACTFALSE=20 PROPERTIES(none)
> >
> >
> = >Regards,
>=20 >Bob
> >
> >Bob Moore
> >Advanced Design = and=20 Technology
> >Application Integration Middleware = Division
>=20 >IBM Software Group
> >+1-919-254-4436
>=20 >remoore@us.ibm.com
> >
> >d821c.jpg"Ron Cohen"=20 <ronc@ntear.com>
> >
> >
> = >d8356.jpg
>=20 >d836d.jpg
> >"Ron Cohen" <ronc@ntear.com>
>=20 >
> >02/05/02 06:54 AM
> >
> = >d8380.jpg
>=20 >
> >To:"'Mircea Pana'" <mpana@nortelnetworks.com>, = Robert=20
> Moore/Raleigh/IBM@IBMUS
> = >cc:<bwijnen@lucent.com>,=20 "'IETF Policy'" <policy@ietf.org>,
>=20 ><policy-admin@ietf.org>
> >Subject:RE: [Policy] Re: = IP=20 Protocol value range
> = >
>=20 >
> >Mircea, Bob
> >
> >
> = >PCIMe=20 defines:
> >
> >PolicySNAPVariable: The protocol = number over=20 a Sub-Network Access
> >Protocol (SNAP) SAP = encapsulation.
>=20 >
> >Explanation:
> >
> >IEEE 802.2 = defines two=20 encapsulations, following the Ethernet length
> = >field:
>=20 >
> >- One with 3 bytes, SSAP, DSAP and CNTRL. The first = two are=20
> represented
> >by the PolicySourceSAPVariable and=20 PolicyDestinationSAPVariable.
> >- The second called the = 802.2 SNAP=20 encapsulation, and adds 5 bytes,
> >where the last two bytes = are=20 called the SNAP type. This is the
> >equivalent of the = Ethernet Type.=20 The intention was that the
> >PolicySNAPVariable would = represent this=20 two byte SNAP type field.
> >
> >I suggest that we = rename=20 this variable to PolicySNAPTypeVriable and
> >remove the = current=20 ambiguity.
> >
> >
> >Ron
> = >
>=20 >
> >
> >
> >
> >
> > = >=20 -----Original Message-----
> > > From: = policy-admin@ietf.org=20 [mailto:policy-admin@ietf.org] On
> > > Behalf Of Mircea=20 Pana
> > > Sent: Monday, February 04, 2002 5:36 PM
> = >=20 > To: Robert Moore
> > > Cc: bwijnen@lucent.com; IETF = Policy;=20 policy-admin@ietf.org
> > > Subject: Re: [Policy] Re: IP = Protocol=20 value range
> > >
> > >
> > > = ...and just=20 to add to my confusion, RFC1042 defines the
> *same* = SNAP
> >=20 > header as
> > > "an extension of the LLC header = called the=20 Sub-Network
> Access Protocol
> > > (SNAP)" = :-0
>=20 > >
> > > So, a reference to the actual definitions = (RFC,=20 IEEE
> etc.) may help if
> > > added in PCIMe. IMO, = it is=20 less important what exactly
> this (or other)
> > > = PolicyVariable represents, more important is to define it
> > = >=20 unambiguously.
> > >
> > > Regards,
> = > >=20 Mircea.
> > >
> > >
> > > Robert = Moore=20 wrote:
> > > >
> > > > >SNAP actually = stands=20 for "IEEE 802.1a SubNetwork
> Attachment Point".
> > = > >=20 See
> > > > >http://www.ietf.org/rfc/rfc1483.txt = "4.1. LLC=20 Encapsulation for
> > > > Routed
> > > > = >Protocols" for example. The SNAP header includes two
> = fields: OUI=20 (3
> > > > >octets) and PID (2 octets).
> > = >=20 > >
> > > > >I have two comments here:
> = >=20 > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network = Access
> > > > >Protocol".
> > > > = >2. Was=20 it intended for the PCIMe class "PolicySNAPVariable" to
> > = > >=20 represent
> > > > >only the PID part of the SNAP = header (2=20 octets)? Or should
> > > it reflect
> > > > = >the=20 entire header: OUI+PID (5 octets).
> > > >
> > = >=20 > To be honest, I don't know what we meant to refer to with
> = >=20 > > PolicySNAPVariable. (I think this class came from Cisco - = in
>=20 > > > any case, I know it didn't come from IBM.) Some=20 possibilities:
> > > >
> > > > Currently = in=20 PCIMe: Sub-Network Access Protocol.
> > > >
> = > >=20 > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment = Point.
>=20 > > >
> > > > On acronymfinder.com: Subnetwork = Access=20 Protocol,
> > > > Standard Network Access Protocol (in = bold,=20 for some
> > > > reason), Small Network Access Package, = and a=20 bunch
> > > > of other options that are plainly not = what=20 we're
> > > > talking about.
> > > = >
>=20 > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can=20 tell
> > > > us what we meant when we defined=20 PolicySNAPVariable.
> > > > And maybe they'll even = agree!=20 :-)
> > > >
> > > > Regards,
> = > >=20 > Bob
> > > >
> > > > Bob = Moore
> >=20 > > Advanced Design and Technology
> > > > = Application=20 Integration Middleware Division
> > > > IBM Software=20 Group
> > > > +1-919-254-4436
> > > >=20 remoore@us.ibm.com
> > >
> > >=20 _______________________________________________
> > > = Policy=20 mailing list
> > > Policy@ietf.org
> > > =
> >=20
> <https://www1.ietf.= org/mailman/listinfo/policy>https://www1.ie
tf.org/mailm
>=20 an/listinfo/policy
>=20 >
>
>


------=_NextPart_001_0009_01C1B002.4F404600-- ------=_NextPart_000_0008_01C1B002.4F404600 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <727380616@07022002-327B> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0008_01C1B002.4F404600 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <727380616@07022002-3282> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0008_01C1B002.4F404600-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Thu Feb 7 12:53:07 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 MAA03676 for ; Thu, 7 Feb 2002 12:53:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA05112 for policy-archive@odin.ietf.org; Thu, 7 Feb 2002 12:53:08 -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 MAA04712; Thu, 7 Feb 2002 12:40:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04670 for ; Thu, 7 Feb 2002 12:40:53 -0500 (EST) Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03475 for ; Thu, 7 Feb 2002 12:40:51 -0500 (EST) Received: from user-vcaulvl.dsl.mindspring.com ([216.175.87.245] helo=ANDREWHOME) by avocet.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16YsXM-0001fy-00; Thu, 07 Feb 2002 09:40:44 -0800 From: "Andrew Smith" To: "Robert Moore" Cc: "'IETF Policy'" Subject: RE: [Policy] Re: IP Protocol value range Date: Thu, 7 Feb 2002 10:09:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Bob, How about this for the Type variable: "NAME PolicySNAPTypeVariable DESCRIPTION The value of the 4th and 5th octets of the Sub-Network Access Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP encapsulation when the PolicySNAPOUIVariable indicates one of the two Encapsulated Ethernet frame formats. This value is undefined for other values of PolicySNAPOUIVariable. ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)" Does this "language" have REFERENCE clauses? That would be a good place to put the appropriate RFCs and IEEE documents. I'm still a bit unclear on Ron's proposal: if we don't allow the OUI to be other than 00-00-00 or 00-00-F8 then shouldn't there be some type of enumerated list of these "allowed values"? Or is this language not that formal? Otherwise we have to add something like "Other values of OUI are not supported". And one other wrinkle is that people who live in what is often known as "IBM-endian" land might interprete 00-00-F8 in a different way to those hailing from "Ethernet-land" (I can't remember which is "Big-" and which is "Little-" endian - people tend to call them "Ethernet order" and "Token-Ring order"). The official IEEE chapter and verse on this is (from the the book of "IEEE 802 Overview and Architecture"): "3.8 Hexadecimal Representation: The representation of a sequence of octet values in which the values of the individual octets are displayed in order from left to right with each octet value represented as a two-digit hexadecimal numeral, and with the resulting pairs of hexadecimal digits separated by hyphens. The order of the hexadecimal digits in each pair, and the mapping between the hexadecimal digits and the bits of the octet value, are derived by interpreting the bits of the octet value as a binary numeral using the normal mathemat-ical rules for digit significance." as opposed to "3.2 bit-reversed representation: The representation of a sequence of octet values in which the values of the individual octets are displayed in order from left to right with each octet value represented as a two-digit hexadecimal numeral, and with the resulting pairs of hexadecimal digits separated by colons. The order of the hexadecimal digits in each pair, and the mapping between the hexadecimal digits and the bits of the octet value, are derived by reversing the order of the bits in the octet value and interpreting the resulting bit sequence as a binary numeral using the normal mathematical rules for digit significance. NOTE- The bit-reversed representation is applicable to LAN MAC addresses for use in a Token Ring (IEEE 802.5) or FDDI environment. See Figure 8 for a comparative example of Bit-reversed and Hexadecimal Representation. In other words, 00-00-F8 is supposed to unequivocably mean "Ethernet order" as opposed to 00:00:EF which means the same thing in Token-Ring land. Not a lot of people know that. But if we write things like 00-00-F8 in the Policy document, we've got to reference this convention. So how about the following revision of Ron's proposal for the OUI variable: "NAME PolicySNAPOUIVariable DESCRIPTION The value of the first three octets of the Sub-Network Access Protocol (SNAP) Protocol Identifier field for 802.2 SNAP encapsulation, containing an O.U.I.. The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC 1042). OID value 00-00-F8 indicates the special encapsulation of Ethernet frames by certain types of bridge (IEEE 802.1H). Other values are not supported. These O.U.I. values are to be interpreted according to the endian-notation conventions of IEEE 802. For either of these encapsulations, the remainder of the Protocol Identified field is indicated by PolicySNAPTypeVariable. ALLOWED VALUE TYPES: - PolicyBitStringValue (24 bit) *** DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none)" Note ***: is there such thing as a "PolicyOctetStringValue (3 octet)" type? Using BitString leads to additional interpretation problems unless it is clearly defined somewhere else what endian order is implied. I'd suggest that the OUI variable precede the Type one in the document. That's my 2 cents - take this message as an I.O.U. :-) Andrew -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of Robert Moore Sent: Thursday, February 07, 2002 7:28 AM To: Ron Cohen Cc: bwijnen@lucent.com; 'Joel M. Halpern'; 'Mircea Pana'; 'IETF Policy'; policy-admin@ietf.org Subject: RE: [Policy] Re: IP Protocol value range Somehow I seem to be the only person here without a copy of the relevant 802.2 spec. So I have no way of deciding between Ron's OID proposal and Joel's OUI one. I agree with Mircea that the most important thing here is to state, very clearly and unambiguously, the contents of each of our variable classes. I'm just not in a position to do that myself. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Ron Cohen" "Ron Cohen" 02/06/02 05:37 AM To: "'Joel M. Halpern'" , Robert Moore/Raleigh/IBM@IBMUS cc: , "'Mircea Pana'" , "'IETF Policy'" , Subject: RE: [Policy] Re: IP Protocol value range I agree. I think that we should add an OID variable as well. I think that this would answer the remarks by Mircea as well as the input/solution proposed by Andrew. I'm assuming that we don't need to support the 40 bit OIU (see Andrew's email). How about the following definition: NAME PolicySNAPOIDVariable DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP) field for 802.2 SNAP encapsulation. The value 00-00-00 indicates the standard SNAP encapsulation (RFC 1042). OID value 00-00-F8 indicates the bridged ethertype (IEEE 802.1H) ALLOWED VALUE TYPES: - PolicyBitStringValue (24 bit) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Joel M. Halpern > Sent: Tuesday, February 05, 2002 10:52 PM > To: Robert Moore; Ron Cohen > Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy'; > policy-admin@ietf.org > Subject: RE: [Policy] Re: IP Protocol value range > > > If we are going to do that, we should add a PolicySNAPOIDVariable as > well. If you are looking at SNAP/SAP encapsulated > information, you must > check the OID for 0 before you can treat the last two bytes > as an etherType. > Yours, > Joel M. Halpern > > At 12:56 PM 2/5/02 -0500, Robert Moore wrote: > >Let me propose an update to the PCIMe text. If this isn't > exactly right, > >it should at least be specific enough for people to comment on. > >It's a complete replacement for section 5.12.19: > >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the > Sub-Network Access > >Protocol (SNAP) Type field for 802.2 > SNAP encapsulation. > > > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - > >PolicyBitStringValue (16 bit) > > > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > > > > >Regards, > >Bob > > > >Bob Moore > >Advanced Design and Technology > >Application Integration Middleware Division > >IBM Software Group > >+1-919-254-4436 > >remoore@us.ibm.com > > > >d821c.jpg"Ron Cohen" > > > > > >d8356.jpg > >d836d.jpg > >"Ron Cohen" > > > >02/05/02 06:54 AM > > > >d8380.jpg > > > >To:"'Mircea Pana'" , Robert > Moore/Raleigh/IBM@IBMUS > >cc:, "'IETF Policy'" , > > > >Subject:RE: [Policy] Re: IP Protocol value range > > > > > >Mircea, Bob > > > > > >PCIMe defines: > > > >PolicySNAPVariable: The protocol number over a Sub-Network Access > >Protocol (SNAP) SAP encapsulation. > > > >Explanation: > > > >IEEE 802.2 defines two encapsulations, following the Ethernet length > >field: > > > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are > represented > >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. > >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, > >where the last two bytes are called the SNAP type. This is the > >equivalent of the Ethernet Type. The intention was that the > >PolicySNAPVariable would represent this two byte SNAP type field. > > > >I suggest that we rename this variable to PolicySNAPTypeVriable and > >remove the current ambiguity. > > > > > >Ron > > > > > > > > > > > > > > > -----Original Message----- > > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > > Behalf Of Mircea Pana > > > Sent: Monday, February 04, 2002 5:36 PM > > > To: Robert Moore > > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > > > > ...and just to add to my confusion, RFC1042 defines the > *same* SNAP > > > header as > > > "an extension of the LLC header called the Sub-Network > Access Protocol > > > (SNAP)" :-0 > > > > > > So, a reference to the actual definitions (RFC, IEEE > etc.) may help if > > > added in PCIMe. IMO, it is less important what exactly > this (or other) > > > PolicyVariable represents, more important is to define it > > > unambiguously. > > > > > > Regards, > > > Mircea. > > > > > > > > > Robert Moore wrote: > > > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork > Attachment Point". > > > > See > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC Encapsulation for > > > > Routed > > > > >Protocols" for example. The SNAP header includes two > fields: OUI (3 > > > > >octets) and PID (2 octets). > > > > > > > > > >I have two comments here: > > > > >1. IMO, PCIMe incorrectly describes SNAP as "Sub-Network Access > > > > >Protocol". > > > > >2. Was it intended for the PCIMe class "PolicySNAPVariable" to > > > > represent > > > > >only the PID part of the SNAP header (2 octets)? Or should > > > it reflect > > > > >the entire header: OUI+PID (5 octets). > > > > > > > > To be honest, I don't know what we meant to refer to with > > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > > Standard Network Access Protocol (in bold, for some > > > > reason), Small Network Access Package, and a bunch > > > > of other options that are plainly not what we're > > > > talking about. > > > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > > us what we meant when we defined PolicySNAPVariable. > > > > And maybe they'll even agree! :-) > > > > > > > > Regards, > > > > Bob > > > > > > > > Bob Moore > > > > Advanced Design and Technology > > > > Application Integration Middleware Division > > > > IBM Software Group > > > > +1-919-254-4436 > > > > remoore@us.ibm.com > > > > > > _______________________________________________ > > > Policy mailing list > > > Policy@ietf.org > > > > > > https://www1.ie tf.org/mailm > an/listinfo/policy > > > > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri Feb 8 10:43:59 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 KAA11906 for ; Fri, 8 Feb 2002 10:43:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14498 for policy-archive@odin.ietf.org; Fri, 8 Feb 2002 10:44: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 KAA13181; Fri, 8 Feb 2002 10:26:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13149 for ; Fri, 8 Feb 2002 10:26:09 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10908 for ; Fri, 8 Feb 2002 10:26:02 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g18FPXL03174 for ; Fri, 8 Feb 2002 10:25:33 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g18FPVn20393 for ; Fri, 8 Feb 2002 10:25:31 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NNLNL02; Fri, 8 Feb 2002 10:25:30 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1MRS5RLC; Fri, 8 Feb 2002 10:25:30 -0500 Message-ID: <3C63EEE3.E65E4390@metasolv.com> Date: Fri, 08 Feb 2002 10:29:39 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF Policy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Policy] test. please ignore. Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit test. please ignore. _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Sat Feb 9 12:28:31 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 MAA17955 for ; Sat, 9 Feb 2002 12:28:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25812 for policy-archive@odin.ietf.org; Sat, 9 Feb 2002 12:28:35 -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 MAA25184; Sat, 9 Feb 2002 12:13:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25157 for ; Sat, 9 Feb 2002 12:13:19 -0500 (EST) Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17405 for ; Sat, 9 Feb 2002 12:13:15 -0500 (EST) Received: from RONC (62.0.181.184) by mail.san.yahoo.com (5.5.056) id 3C64377300032244; Sat, 9 Feb 2002 09:12:10 -0800 From: "Ron Cohen" To: "'Andrew Smith'" , "'Robert Moore'" Cc: "'IETF Policy'" Subject: RE: [Policy] Re: IP Protocol value range Date: Sat, 9 Feb 2002 19:11:20 +0200 Message-ID: <000501c1b18c$d0433dd0$6401010a@RONC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <1068327212765C4F995A07930BF7F246066925@oakenfold.lyciumnetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Andrew, I like your definitions. I didn't mean to restrict the OUI values, but rather to provide examples. Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Andrew Smith > Sent: Thursday, February 07, 2002 8:09 PM > To: Robert Moore > Cc: 'IETF Policy' > Subject: RE: [Policy] Re: IP Protocol value range > > > Bob, > > How about this for the Type variable: > > "NAME PolicySNAPTypeVariable > DESCRIPTION The value of the 4th and 5th octets of the > Sub-Network Access > Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP > encapsulation > when the PolicySNAPOUIVariable > indicates one of the two Encapsulated Ethernet frame formats. > This value is > undefined for other values of PolicySNAPOUIVariable. > > ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) > > DERIVED FROM PolicyImplicitVariable > ABSTRACT FALSE > PROPERTIES (none)" > > Does this "language" have REFERENCE clauses? That would be a > good place to > put the appropriate RFCs and IEEE documents. > > I'm still a bit unclear on Ron's proposal: if we don't allow > the OUI to be > other than 00-00-00 or 00-00-F8 then shouldn't there be some type of > enumerated list of these "allowed values"? Or is this > language not that > formal? Otherwise we have to add something like "Other values > of OUI are not > supported". > > And one other wrinkle is that people who live in what is > often known as > "IBM-endian" land might interprete 00-00-F8 in a different > way to those > hailing from "Ethernet-land" (I can't remember which is > "Big-" and which is > "Little-" endian - people tend to call them "Ethernet order" > and "Token-Ring > order"). The official IEEE chapter and verse on this is (from > the the book > of "IEEE 802 Overview and Architecture"): > > "3.8 Hexadecimal Representation: The representation of a > sequence of octet > values in which the values of the individual octets are > displayed in order > from left to right with each octet value represented as a two-digit > hexadecimal numeral, and with the resulting pairs of > hexadecimal digits > separated by hyphens. The order of the hexadecimal digits in > each pair, and > the mapping between the hexadecimal digits and the bits of > the octet value, > are derived by interpreting the bits of the octet value as a > binary numeral > using the normal mathemat-ical rules for digit significance." > > as opposed to > > "3.2 bit-reversed representation: The representation of a > sequence of octet > values in which the values of the individual octets are > displayed in order > from left to right with each octet value represented as a two-digit > hexadecimal numeral, and with the resulting pairs of > hexadecimal digits > separated by colons. The order of the hexadecimal digits in > each pair, and > the mapping between the hexadecimal digits and the bits of > the octet value, > are derived by reversing the order of the bits in the octet value and > interpreting the resulting bit sequence as a binary numeral > using the normal > mathematical rules for digit significance. > NOTE- The bit-reversed representation is applicable to LAN > MAC addresses for > use in a Token Ring (IEEE 802.5) or FDDI environment. See > Figure 8 for a > comparative example of Bit-reversed and Hexadecimal Representation. > > In other words, 00-00-F8 is supposed to unequivocably mean > "Ethernet order" > as opposed to 00:00:EF which means the same thing in > Token-Ring land. Not a > lot of people know that. But if we write things like 00-00-F8 > in the Policy > document, we've got to reference this convention. So how > about the following > revision of Ron's proposal for the OUI variable: > > "NAME PolicySNAPOUIVariable > DESCRIPTION The value of the first three octets of the > Sub-Network Access > Protocol (SNAP) > Protocol Identifier field for 802.2 SNAP encapsulation, containing an > O.U.I.. > The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC > 1042). > OID value 00-00-F8 indicates the special encapsulation of > Ethernet frames by > certain types of bridge (IEEE 802.1H). Other values are not > supported. These > O.U.I. values are to be interpreted according to the endian-notation > conventions of IEEE 802. For either of these encapsulations, > the remainder > of the Protocol Identified field is indicated by > PolicySNAPTypeVariable. > > ALLOWED VALUE TYPES: > - PolicyBitStringValue (24 bit) *** > > DERIVED FROM PolicyImplicitVariable > ABSTRACT FALSE > PROPERTIES (none)" > > Note ***: is there such thing as a "PolicyOctetStringValue (3 > octet)" type? > Using BitString leads to additional interpretation problems > unless it is > clearly defined somewhere else what endian order is implied. > > I'd suggest that the OUI variable precede the Type one in the > document. > That's my 2 cents - take this message as an I.O.U. :-) > > Andrew > > > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of > Robert Moore > Sent: Thursday, February 07, 2002 7:28 AM > To: Ron Cohen > Cc: bwijnen@lucent.com; 'Joel M. Halpern'; 'Mircea Pana'; > 'IETF Policy'; > policy-admin@ietf.org > Subject: RE: [Policy] Re: IP Protocol value range > > > Somehow I seem to be the only person here without a copy of > the relevant > 802.2 spec. So I have no way of deciding between Ron's OID > proposal and > Joel's OUI one. I agree with Mircea that the most important > thing here is to > state, very clearly and unambiguously, the contents of each > of our variable > classes. I'm just not in a position to do that myself. > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > "Ron Cohen" > > > > > > "Ron Cohen" > 02/06/02 05:37 AM > > To: "'Joel M. Halpern'" , Robert > Moore/Raleigh/IBM@IBMUS > cc: , "'Mircea Pana'" > , "'IETF > Policy'" , > Subject: RE: [Policy] Re: IP Protocol value range > > > > > I agree. I think that we should add an OID variable as well. I think > that this would answer the remarks by Mircea as well as the > input/solution proposed by Andrew. I'm assuming that we don't need to > support the 40 bit OIU (see Andrew's email). > > How about the following definition: > > NAME PolicySNAPOIDVariable > DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP) > field for 802.2 SNAP encapsulation. > The value 00-00-00 indicates the standard SNAP encapsulation > (RFC 1042). > OID value 00-00-F8 indicates the bridged ethertype (IEEE > 802.1H) > > ALLOWED VALUE TYPES: > - PolicyBitStringValue (24 bit) > > DERIVED FROM PolicyImplicitVariable > ABSTRACT FALSE > PROPERTIES (none) > > > Ron > > > -----Original Message----- > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > Behalf Of Joel M. Halpern > > Sent: Tuesday, February 05, 2002 10:52 PM > > To: Robert Moore; Ron Cohen > > Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy'; > > policy-admin@ietf.org > > Subject: RE: [Policy] Re: IP Protocol value range > > > > > > If we are going to do that, we should add a PolicySNAPOIDVariable as > > well. If you are looking at SNAP/SAP encapsulated > > information, you must > > check the OID for 0 before you can treat the last two bytes > > as an etherType. > > Yours, > > Joel M. Halpern > > > > At 12:56 PM 2/5/02 -0500, Robert Moore wrote: > > >Let me propose an update to the PCIMe text. If this isn't > > exactly right, > > >it should at least be specific enough for people to comment on. > > >It's a complete replacement for section 5.12.19: > > >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the > > Sub-Network Access > > >Protocol (SNAP) Type field for 802.2 > > SNAP encapsulation. > > > > > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - > > >PolicyBitStringValue (16 bit) > > > > > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > > > > > > > >Regards, > > >Bob > > > > > >Bob Moore > > >Advanced Design and Technology > > >Application Integration Middleware Division > > >IBM Software Group > > >+1-919-254-4436 > > >remoore@us.ibm.com > > > > > >d821c.jpg"Ron Cohen" > > > > > > > > >d8356.jpg > > >d836d.jpg > > >"Ron Cohen" > > > > > >02/05/02 06:54 AM > > > > > >d8380.jpg > > > > > >To:"'Mircea Pana'" , Robert > > Moore/Raleigh/IBM@IBMUS > > >cc:, "'IETF Policy'" , > > > > > >Subject:RE: [Policy] Re: IP Protocol value range > > > > > > > > >Mircea, Bob > > > > > > > > >PCIMe defines: > > > > > >PolicySNAPVariable: The protocol number over a Sub-Network Access > > >Protocol (SNAP) SAP encapsulation. > > > > > >Explanation: > > > > > >IEEE 802.2 defines two encapsulations, following the > Ethernet length > > >field: > > > > > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are > > represented > > >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. > > >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, > > >where the last two bytes are called the SNAP type. This is the > > >equivalent of the Ethernet Type. The intention was that the > > >PolicySNAPVariable would represent this two byte SNAP type field. > > > > > >I suggest that we rename this variable to PolicySNAPTypeVriable and > > >remove the current ambiguity. > > > > > > > > >Ron > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > > > Behalf Of Mircea Pana > > > > Sent: Monday, February 04, 2002 5:36 PM > > > > To: Robert Moore > > > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > > > > > > > ...and just to add to my confusion, RFC1042 defines the > > *same* SNAP > > > > header as > > > > "an extension of the LLC header called the Sub-Network > > Access Protocol > > > > (SNAP)" :-0 > > > > > > > > So, a reference to the actual definitions (RFC, IEEE > > etc.) may help if > > > > added in PCIMe. IMO, it is less important what exactly > > this (or other) > > > > PolicyVariable represents, more important is to define it > > > > unambiguously. > > > > > > > > Regards, > > > > Mircea. > > > > > > > > > > > > Robert Moore wrote: > > > > > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork > > Attachment Point". > > > > > See > > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC > Encapsulation for > > > > > Routed > > > > > >Protocols" for example. The SNAP header includes two > > fields: OUI (3 > > > > > >octets) and PID (2 octets). > > > > > > > > > > > >I have two comments here: > > > > > >1. IMO, PCIMe incorrectly describes SNAP as > "Sub-Network Access > > > > > >Protocol". > > > > > >2. Was it intended for the PCIMe class > "PolicySNAPVariable" to > > > > > represent > > > > > >only the PID part of the SNAP header (2 octets)? Or should > > > > it reflect > > > > > >the entire header: OUI+PID (5 octets). > > > > > > > > > > To be honest, I don't know what we meant to refer to with > > > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > > > Standard Network Access Protocol (in bold, for some > > > > > reason), Small Network Access Package, and a bunch > > > > > of other options that are plainly not what we're > > > > > talking about. > > > > > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > > > us what we meant when we defined PolicySNAPVariable. > > > > > And maybe they'll even agree! :-) > > > > > > > > > > Regards, > > > > > Bob > > > > > > > > > > Bob Moore > > > > > Advanced Design and Technology > > > > > Application Integration Middleware Division > > > > > IBM Software Group > > > > > +1-919-254-4436 > > > > > remoore@us.ibm.com > > > > > > > > _______________________________________________ > > > > Policy mailing list > > > > Policy@ietf.org > > > > > > > > > https://www1.ie > tf.org/mailm > > an/listinfo/policy > > > > > > > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Mon Feb 11 10:50:53 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 KAA06783 for ; Mon, 11 Feb 2002 10:50:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15419 for policy-archive@odin.ietf.org; Mon, 11 Feb 2002 10:50:54 -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 KAA14495; Mon, 11 Feb 2002 10:35:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14466 for ; Mon, 11 Feb 2002 10:35:51 -0500 (EST) Received: from hqmail01.ellacoya.com ([64.223.136.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05986 for ; Mon, 11 Feb 2002 10:35:49 -0500 (EST) Received: by hqmail01.ellacoya.com with Internet Mail Service (5.5.2653.19) id <1WR0ZCGC>; Mon, 11 Feb 2002 10:33:15 -0500 Message-ID: From: "Weiss, Walter" To: "'IETF Policy'" Date: Mon, 11 Feb 2002 10:33:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Policy] Supporting hierarchical classifiers in QDDIM Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Folks, In Salt Lake City Andrea and I were asked to determine the necessary changes to support hierarchical classifiers. The purpose of this change is to support arbitrary groupings of classifiers. The immediate value of this change is at the edges of the network to provide different users with different combinations of pre-defined policies. Andrea and I have both agreed that the only change required in the model is to modify the cardinality of ClassifierElementUsesFilterList from 1-* to 0/1-* such that it is possible to have a ClassifierElement to not point to a FilterList at all. With this change, a ClassiferElement can just points only to a Classifier allowing hierarchical classification. If anyone has a concern with this change please raise it on the list right away since we are in the process of updating the QDDIM doc before the deadline. regards, -Walter _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Mon Feb 11 11:40:21 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 LAA08936 for ; Mon, 11 Feb 2002 11:40:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18672 for policy-archive@odin.ietf.org; Mon, 11 Feb 2002 11:40:23 -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 LAA16620; Mon, 11 Feb 2002 11:08:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16590 for ; Mon, 11 Feb 2002 11:08:47 -0500 (EST) Received: from longmail2.lboard.com ([63.109.116.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07468; Mon, 11 Feb 2002 11:08:44 -0500 (EST) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id <13GBHJTB>; Mon, 11 Feb 2002 11:07:43 -0500 Message-ID: From: Ed Ellesson To: "'Wijnen, Bert (Bert)'" Cc: "'ietf-secretariat@ietf.org'" , "'Joel M. Halpern'" , "'policy@ietf.org'" Date: Mon, 11 Feb 2002 11:07:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Policy] Request to Advance QPIM Draft to Proposed Standard Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Bert, Please forward the following draft to the IESG for consideration as a Proposed Standard RFC: http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-info-model-04.txt The contents of this draft represents the rough consensus of our working group, based on the comments and resulting revisions discussed and accepted in face to face meetings of our working group, and on the mailing list, and confirmed in a working group last call on the policy framework working group mailing list. Sincerely, Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework WG _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Mon Feb 11 16:50:34 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 QAA18581 for ; Mon, 11 Feb 2002 16:50:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA04632 for policy-archive@odin.ietf.org; Mon, 11 Feb 2002 16:50:35 -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 QAA04193; Mon, 11 Feb 2002 16:35:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04116 for ; Mon, 11 Feb 2002 16:34:58 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17878; Mon, 11 Feb 2002 16:33:35 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA19588; Mon, 11 Feb 2002 15:28:48 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1BLXZ4174052; Mon, 11 Feb 2002 16:33:35 -0500 Subject: RE: [Policy] Re: IP Protocol value range To: "Ron Cohen" Cc: "'Andrew Smith'" , "'IETF Policy'" , policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Mon, 11 Feb 2002 16:37:56 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_02042002 Pre-release 1|February 04, 2002) at 02/11/2002 04:33:35 PM MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E" Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E Content-type: multipart/alternative; Boundary="1__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E" --1__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E Content-type: text/plain; charset=US-ASCII OK, taking Andrew's text as a starting point, I've created a new PCIMe section for the OUI variable, and updated the section for the SNAP Type variable. Since Ron said that the two Ethernet values were just supposed to be examples, I amended Andrew's text to say that other values *are* allowed, rather than to say that they are not allowed. Also, since the answer to Andrew's question is "No, there isn't a PolicyOctetStringValue class," I went ahead and did the subtyping for the new variable the same way it was done for the others. Finally, rather than opening up the *enormous* issue of canonical versus non-canonical formats, I stopped with Andrew's one sentence about endian-ness. Anyway, here's the new text, available for your comments: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 5.12.19. The Class "PolicySNAPOUIVariable" NAME PolicySNAPOUIVariable DESCRIPTION The value of the first three octets of the Sub- Network Access Protocol (SNAP) Protocol Identifier field for 802.2 SNAP encapsulation, containing an Organizationally Unique Identifier (OUI). The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC 1042). OUI value 00-00-F8 indicates the special encapsulation of Ethernet frames by certain types of bridges (IEEE 802.1H). Other values are supported, but are not further defined here. These OUI. values are to be interpreted according to the endian-notation conventions of IEEE 802. For either of the two Ethernet encapsulations, the remainder of the Protocol Identifier field is represented by the PolicySNAPTypeVariable. ALLOWED VALUE TYPES: - PolicyIntegerValue (0..16777215) - PolicyBitStringValue (24 bits) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) 5.12.20. The Class "PolicySNAPTypeVariable" NAME PolicySNAPTypeVariable DESCRIPTION The value of the 4th and 5th octets of the Sub- Network Access Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP encapsulation when the PolicySNAPOUIVariable indicates one of the two Encapsulated Ethernet frame formats. This value is undefined for other values of PolicySNAPOUIVariable. ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - PolicyBitStringValue (16 bits) DERIVED FROM PolicyImplicitVariable ABSTRACT FALSE PROPERTIES (none) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Ron Cohen" To: "'Andrew Smith'" , Robert Sent by: policy- Moore/Raleigh/IBM@IBMUS admin@ietf.org cc: "'IETF Policy'" Subject: RE: [Policy] Re: IP Protocol value range 02/09/02 12:11 PM Andrew, I like your definitions. I didn't mean to restrict the OUI values, but rather to provide examples. Ron > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > Behalf Of Andrew Smith > Sent: Thursday, February 07, 2002 8:09 PM > To: Robert Moore > Cc: 'IETF Policy' > Subject: RE: [Policy] Re: IP Protocol value range > > > Bob, > > How about this for the Type variable: > > "NAME PolicySNAPTypeVariable > DESCRIPTION The value of the 4th and 5th octets of the > Sub-Network Access > Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP > encapsulation > when the PolicySNAPOUIVariable > indicates one of the two Encapsulated Ethernet frame formats. > This value is > undefined for other values of PolicySNAPOUIVariable. > > ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) > > DERIVED FROM PolicyImplicitVariable > ABSTRACT FALSE > PROPERTIES (none)" > > Does this "language" have REFERENCE clauses? That would be a > good place to > put the appropriate RFCs and IEEE documents. > > I'm still a bit unclear on Ron's proposal: if we don't allow > the OUI to be > other than 00-00-00 or 00-00-F8 then shouldn't there be some type of > enumerated list of these "allowed values"? Or is this > language not that > formal? Otherwise we have to add something like "Other values > of OUI are not > supported". > > And one other wrinkle is that people who live in what is > often known as > "IBM-endian" land might interprete 00-00-F8 in a different > way to those > hailing from "Ethernet-land" (I can't remember which is > "Big-" and which is > "Little-" endian - people tend to call them "Ethernet order" > and "Token-Ring > order"). The official IEEE chapter and verse on this is (from > the the book > of "IEEE 802 Overview and Architecture"): > > "3.8 Hexadecimal Representation: The representation of a > sequence of octet > values in which the values of the individual octets are > displayed in order > from left to right with each octet value represented as a two-digit > hexadecimal numeral, and with the resulting pairs of > hexadecimal digits > separated by hyphens. The order of the hexadecimal digits in > each pair, and > the mapping between the hexadecimal digits and the bits of > the octet value, > are derived by interpreting the bits of the octet value as a > binary numeral > using the normal mathemat-ical rules for digit significance." > > as opposed to > > "3.2 bit-reversed representation: The representation of a > sequence of octet > values in which the values of the individual octets are > displayed in order > from left to right with each octet value represented as a two-digit > hexadecimal numeral, and with the resulting pairs of > hexadecimal digits > separated by colons. The order of the hexadecimal digits in > each pair, and > the mapping between the hexadecimal digits and the bits of > the octet value, > are derived by reversing the order of the bits in the octet value and > interpreting the resulting bit sequence as a binary numeral > using the normal > mathematical rules for digit significance. > NOTE- The bit-reversed representation is applicable to LAN > MAC addresses for > use in a Token Ring (IEEE 802.5) or FDDI environment. See > Figure 8 for a > comparative example of Bit-reversed and Hexadecimal Representation. > > In other words, 00-00-F8 is supposed to unequivocably mean > "Ethernet order" > as opposed to 00:00:EF which means the same thing in > Token-Ring land. Not a > lot of people know that. But if we write things like 00-00-F8 > in the Policy > document, we've got to reference this convention. So how > about the following > revision of Ron's proposal for the OUI variable: > > "NAME PolicySNAPOUIVariable > DESCRIPTION The value of the first three octets of the > Sub-Network Access > Protocol (SNAP) > Protocol Identifier field for 802.2 SNAP encapsulation, containing an > O.U.I.. > The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC > 1042). > OID value 00-00-F8 indicates the special encapsulation of > Ethernet frames by > certain types of bridge (IEEE 802.1H). Other values are not > supported. These > O.U.I. values are to be interpreted according to the endian-notation > conventions of IEEE 802. For either of these encapsulations, > the remainder > of the Protocol Identified field is indicated by > PolicySNAPTypeVariable. > > ALLOWED VALUE TYPES: > - PolicyBitStringValue (24 bit) *** > > DERIVED FROM PolicyImplicitVariable > ABSTRACT FALSE > PROPERTIES (none)" > > Note ***: is there such thing as a "PolicyOctetStringValue (3 > octet)" type? > Using BitString leads to additional interpretation problems > unless it is > clearly defined somewhere else what endian order is implied. > > I'd suggest that the OUI variable precede the Type one in the > document. > That's my 2 cents - take this message as an I.O.U. :-) > > Andrew > > > -----Original Message----- > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of > Robert Moore > Sent: Thursday, February 07, 2002 7:28 AM > To: Ron Cohen > Cc: bwijnen@lucent.com; 'Joel M. Halpern'; 'Mircea Pana'; > 'IETF Policy'; > policy-admin@ietf.org > Subject: RE: [Policy] Re: IP Protocol value range > > > Somehow I seem to be the only person here without a copy of > the relevant > 802.2 spec. So I have no way of deciding between Ron's OID > proposal and > Joel's OUI one. I agree with Mircea that the most important > thing here is to > state, very clearly and unambiguously, the contents of each > of our variable > classes. I'm just not in a position to do that myself. > > Regards, > Bob > > Bob Moore > Advanced Design and Technology > Application Integration Middleware Division > IBM Software Group > +1-919-254-4436 > remoore@us.ibm.com > > "Ron Cohen" > > > > > > "Ron Cohen" > 02/06/02 05:37 AM > > To: "'Joel M. Halpern'" , Robert > Moore/Raleigh/IBM@IBMUS > cc: , "'Mircea Pana'" > , "'IETF > Policy'" , > Subject: RE: [Policy] Re: IP Protocol value range > > > > > I agree. I think that we should add an OID variable as well. I think > that this would answer the remarks by Mircea as well as the > input/solution proposed by Andrew. I'm assuming that we don't need to > support the 40 bit OIU (see Andrew's email). > > How about the following definition: > > NAME PolicySNAPOIDVariable > DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP) > field for 802.2 SNAP encapsulation. > The value 00-00-00 indicates the standard SNAP encapsulation > (RFC 1042). > OID value 00-00-F8 indicates the bridged ethertype (IEEE > 802.1H) > > ALLOWED VALUE TYPES: > - PolicyBitStringValue (24 bit) > > DERIVED FROM PolicyImplicitVariable > ABSTRACT FALSE > PROPERTIES (none) > > > Ron > > > -----Original Message----- > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > Behalf Of Joel M. Halpern > > Sent: Tuesday, February 05, 2002 10:52 PM > > To: Robert Moore; Ron Cohen > > Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy'; > > policy-admin@ietf.org > > Subject: RE: [Policy] Re: IP Protocol value range > > > > > > If we are going to do that, we should add a PolicySNAPOIDVariable as > > well. If you are looking at SNAP/SAP encapsulated > > information, you must > > check the OID for 0 before you can treat the last two bytes > > as an etherType. > > Yours, > > Joel M. Halpern > > > > At 12:56 PM 2/5/02 -0500, Robert Moore wrote: > > >Let me propose an update to the PCIMe text. If this isn't > > exactly right, > > >it should at least be specific enough for people to comment on. > > >It's a complete replacement for section 5.12.19: > > >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the > > Sub-Network Access > > >Protocol (SNAP) Type field for 802.2 > > SNAP encapsulation. > > > > > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) - > > >PolicyBitStringValue (16 bit) > > > > > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none) > > > > > > > > >Regards, > > >Bob > > > > > >Bob Moore > > >Advanced Design and Technology > > >Application Integration Middleware Division > > >IBM Software Group > > >+1-919-254-4436 > > >remoore@us.ibm.com > > > > > >d821c.jpg"Ron Cohen" > > > > > > > > >d8356.jpg > > >d836d.jpg > > >"Ron Cohen" > > > > > >02/05/02 06:54 AM > > > > > >d8380.jpg > > > > > >To:"'Mircea Pana'" , Robert > > Moore/Raleigh/IBM@IBMUS > > >cc:, "'IETF Policy'" , > > > > > >Subject:RE: [Policy] Re: IP Protocol value range > > > > > > > > >Mircea, Bob > > > > > > > > >PCIMe defines: > > > > > >PolicySNAPVariable: The protocol number over a Sub-Network Access > > >Protocol (SNAP) SAP encapsulation. > > > > > >Explanation: > > > > > >IEEE 802.2 defines two encapsulations, following the > Ethernet length > > >field: > > > > > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are > > represented > > >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable. > > >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes, > > >where the last two bytes are called the SNAP type. This is the > > >equivalent of the Ethernet Type. The intention was that the > > >PolicySNAPVariable would represent this two byte SNAP type field. > > > > > >I suggest that we rename this variable to PolicySNAPTypeVriable and > > >remove the current ambiguity. > > > > > > > > >Ron > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On > > > > Behalf Of Mircea Pana > > > > Sent: Monday, February 04, 2002 5:36 PM > > > > To: Robert Moore > > > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org > > > > Subject: Re: [Policy] Re: IP Protocol value range > > > > > > > > > > > > ...and just to add to my confusion, RFC1042 defines the > > *same* SNAP > > > > header as > > > > "an extension of the LLC header called the Sub-Network > > Access Protocol > > > > (SNAP)" :-0 > > > > > > > > So, a reference to the actual definitions (RFC, IEEE > > etc.) may help if > > > > added in PCIMe. IMO, it is less important what exactly > > this (or other) > > > > PolicyVariable represents, more important is to define it > > > > unambiguously. > > > > > > > > Regards, > > > > Mircea. > > > > > > > > > > > > Robert Moore wrote: > > > > > > > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork > > Attachment Point". > > > > > See > > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC > Encapsulation for > > > > > Routed > > > > > >Protocols" for example. The SNAP header includes two > > fields: OUI (3 > > > > > >octets) and PID (2 octets). > > > > > > > > > > > >I have two comments here: > > > > > >1. IMO, PCIMe incorrectly describes SNAP as > "Sub-Network Access > > > > > >Protocol". > > > > > >2. Was it intended for the PCIMe class > "PolicySNAPVariable" to > > > > > represent > > > > > >only the PID part of the SNAP header (2 octets)? Or should > > > > it reflect > > > > > >the entire header: OUI+PID (5 octets). > > > > > > > > > > To be honest, I don't know what we meant to refer to with > > > > > PolicySNAPVariable. (I think this class came from Cisco - in > > > > > any case, I know it didn't come from IBM.) Some possibilities: > > > > > > > > > > Currently in PCIMe: Sub-Network Access Protocol. > > > > > > > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point. > > > > > > > > > > On acronymfinder.com: Subnetwork Access Protocol, > > > > > Standard Network Access Protocol (in bold, for some > > > > > reason), Small Network Access Package, and a bunch > > > > > of other options that are plainly not what we're > > > > > talking about. > > > > > > > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell > > > > > us what we meant when we defined PolicySNAPVariable. > > > > > And maybe they'll even agree! :-) > > > > > > > > > > Regards, > > > > > Bob > > > > > > > > > > Bob Moore > > > > > Advanced Design and Technology > > > > > Application Integration Middleware Division > > > > > IBM Software Group > > > > > +1-919-254-4436 > > > > > remoore@us.ibm.com > > > > > > > > _______________________________________________ > > > > Policy mailing list > > > > Policy@ietf.org > > > > > > > > > https://www1.ie > tf.org/mailm > > an/listinfo/policy > > > > > > > > > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy --1__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E Content-type: text/html; charset=US-ASCII Content-Disposition: inline OK, taking Andrew's text as a starting point, I've created a new PCIMe section for the OUI variable, and updated the section for the SNAP Type variable. Since Ron said that the two Ethernet values were just supposed to be examples, I amended Andrew's text to say that other values *are* allowed, rather than to say that they are not allowed. Also, since the answer to Andrew's question is "No, there isn't a PolicyOctetStringValue class," I went ahead and did the subtyping for the new variable the same way it was done for the others. Finally, rather than opening up the *enormous* issue of canonical versus non-canonical formats, I stopped with Andrew's one sentence about endian-ness.

Anyway, here's the new text, available for your comments:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5.12.19. The Class "PolicySNAPOUIVariable"
      NAME PolicySNAPOUIVariable
      DESCRIPTION The value of the first three octets of the Sub-Network Access Protocol (SNAP) Protocol Identifier field for 802.2 SNAP encapsulation, containing an Organizationally Unique Identifier (OUI).  The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC 1042).  OUI value 00-00-F8 indicates the special encapsulation of Ethernet frames by certain types of bridges (IEEE 802.1H).  Other values are supported, but are not further defined here.  These OUI. values are to be interpreted according to the endian-notation conventions of IEEE 802.  For either of the two Ethernet encapsulations, the remainder of the Protocol Identifier field is represented by the PolicySNAPTypeVariable.

      ALLOWED VALUE TYPES:
      - PolicyIntegerValue (0..16777215)
      - PolicyBitStringValue (24 bits)

      DERIVED FROM PolicyImplicitVariable
      ABSTRACT FALSE
      PROPERTIES (none)
5.12.20. The Class "PolicySNAPTypeVariable"
      NAME PolicySNAPTypeVariable
      DESCRIPTION The value of the 4th and 5th octets of the Sub-Network Access Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP encapsulation when the PolicySNAPOUIVariable indicates one of the two Encapsulated Ethernet frame formats. This value is undefined for other values of PolicySNAPOUIVariable.

      ALLOWED VALUE TYPES:
       - PolicyIntegerValue (0..65535)
       - PolicyBitStringValue (16 bits)

      DERIVED FROM PolicyImplicitVariable
      ABSTRACT FALSE
      PROPERTIES (none)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com

"Ron Cohen" <ronc@ntear.com>




          "Ron Cohen" <ronc@ntear.com>
          Sent by: policy-admin@ietf.org

          02/09/02 12:11 PM



To: "'Andrew Smith'" <ah_smith@acm.org>, Robert Moore/Raleigh/IBM@IBMUS
cc: "'IETF Policy'" <policy@ietf.org>
Subject: RE: [Policy] Re: IP Protocol value range


Andrew,

I like your definitions. I didn't mean to restrict the OUI values, but
rather to provide examples.

Ron


> -----Original Message-----
> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On
> Behalf Of Andrew Smith
> Sent: Thursday, February 07, 2002 8:09 PM
> To: Robert Moore
> Cc: 'IETF Policy'
> Subject: RE: [Policy] Re: IP Protocol value range
>
>
> Bob,
>
> How about this for the Type variable:
>
> "NAME PolicySNAPTypeVariable
> DESCRIPTION The value of the 4th and 5th octets of the
> Sub-Network Access
> Protocol (SNAP) Protocol Identifier field for IEEE 802 SNAP
> encapsulation
> when the PolicySNAPOUIVariable
> indicates one of the two Encapsulated Ethernet frame formats.
> This value is
> undefined for other values of PolicySNAPOUIVariable.
>
> ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535)
>
> DERIVED FROM PolicyImplicitVariable
> ABSTRACT FALSE
> PROPERTIES (none)"
>
> Does this "language" have REFERENCE clauses? That would be a
> good place to
> put the appropriate RFCs and IEEE documents.
>
> I'm still a bit unclear on Ron's proposal: if we don't allow
> the OUI to be
> other than 00-00-00 or 00-00-F8 then shouldn't there be some type of
> enumerated list of these "allowed values"? Or is this
> language not that
> formal? Otherwise we have to add something like "Other values
> of OUI are not
> supported".
>
> And one other wrinkle is that people who live in what is
> often known as
> "IBM-endian" land might interprete 00-00-F8 in a different
> way to those
> hailing from "Ethernet-land" (I can't remember which is
> "Big-" and which is
> "Little-" endian - people tend to call them "Ethernet order"
> and "Token-Ring
> order"). The official IEEE chapter and verse on this is (from
> the the book
> of "IEEE 802 Overview and Architecture"):
>
> "3.8 Hexadecimal Representation: The representation of a
> sequence of octet
> values in which the values of the individual octets are
> displayed in order
> from left to right with each octet value represented as a two-digit
> hexadecimal numeral, and with the resulting pairs of
> hexadecimal digits
> separated by hyphens. The order of the hexadecimal digits in
> each pair, and
> the mapping between the hexadecimal digits and the bits of
> the octet value,
> are derived by interpreting the bits of the octet value as a
> binary numeral
> using the normal mathemat-ical rules for digit significance."
>
> as opposed to
>
> "3.2 bit-reversed representation: The representation of a
> sequence of octet
> values in which the values of the individual octets are
> displayed in order
> from left to right with each octet value represented as a two-digit
> hexadecimal numeral, and with the resulting pairs of
> hexadecimal digits
> separated by colons. The order of the hexadecimal digits in
> each pair, and
> the mapping between the hexadecimal digits and the bits of
> the octet value,
> are derived by reversing the order of the bits in the octet value and
> interpreting the resulting bit sequence as a binary numeral
> using the normal
> mathematical rules for digit significance.
> NOTE- The bit-reversed representation is applicable to LAN
> MAC addresses for
> use in a Token Ring (IEEE 802.5) or FDDI environment. See
> Figure 8 for a
> comparative example of Bit-reversed and Hexadecimal Representation.
>
> In other words, 00-00-F8 is supposed to unequivocably mean
> "Ethernet order"
> as opposed to 00:00:EF which means the same thing in
> Token-Ring land. Not a
> lot of people know that. But if we write things like 00-00-F8
> in the Policy
> document, we've got to reference this convention. So how
> about the following
> revision of Ron's proposal for the OUI variable:
>
> "NAME PolicySNAPOUIVariable
> DESCRIPTION The value of the first three octets of the
> Sub-Network Access
> Protocol (SNAP)
> Protocol Identifier field for 802.2 SNAP encapsulation, containing an
> O.U.I..
> The value 00-00-00 indicates the encapsulation of Ethernet frames (RFC
> 1042).
> OID value 00-00-F8 indicates the special encapsulation of
> Ethernet frames by
> certain types of bridge (IEEE 802.1H). Other values are not
> supported. These
> O.U.I. values are to be interpreted according to the endian-notation
> conventions of IEEE 802. For either of these encapsulations,
> the remainder
> of the Protocol Identified field is indicated by
> PolicySNAPTypeVariable.
>
> ALLOWED VALUE TYPES:
> - PolicyBitStringValue (24 bit) ***
>
> DERIVED FROM PolicyImplicitVariable
> ABSTRACT FALSE
> PROPERTIES (none)"
>
> Note ***: is there such thing as a "PolicyOctetStringValue (3
> octet)" type?
> Using BitString leads to additional interpretation problems
> unless it is
> clearly defined somewhere else what endian order is implied.
>
> I'd suggest that the OUI variable precede the Type one in the
> document.
> That's my 2 cents - take this message as an I.O.U. :-)
>
> Andrew
>
>
> -----Original Message-----
> From: policy-admin@ietf.org [mailto:policy-admin@ietf.org]On Behalf Of
> Robert Moore
> Sent: Thursday, February 07, 2002 7:28 AM
> To: Ron Cohen
> Cc: bwijnen@lucent.com; 'Joel M. Halpern'; 'Mircea Pana';
> 'IETF Policy';
> policy-admin@ietf.org
> Subject: RE: [Policy] Re: IP Protocol value range
>
>
> Somehow I seem to be the only person here without a copy of
> the relevant
> 802.2 spec. So I have no way of deciding between Ron's OID
> proposal and
> Joel's OUI one. I agree with Mircea that the most important
> thing here is to
> state, very clearly and unambiguously, the contents of each
> of our variable
> classes. I'm just not in a position to do that myself.
>
> Regards,
> Bob
>
> Bob Moore
> Advanced Design and Technology
> Application Integration Middleware Division
> IBM Software Group
> +1-919-254-4436
> remoore@us.ibm.com
>
> "Ron Cohen" <ronc@ntear.com>
>
>
>
>
>
> "Ron Cohen" <ronc@ntear.com>
> 02/06/02 05:37 AM
>
> To: "'Joel M. Halpern'" <joel@stevecrocker.com>, Robert
> Moore/Raleigh/IBM@IBMUS
> cc: <bwijnen@lucent.com>, "'Mircea Pana'"
> <mpana@nortelnetworks.com>, "'IETF
> Policy'" <policy@ietf.org>, <policy-admin@ietf.org>
> Subject: RE: [Policy] Re: IP Protocol value range
>
>
>
>
> I agree. I think that we should add an OID variable as well. I think
> that this would answer the remarks by Mircea as well as the
> input/solution proposed by Andrew. I'm assuming that we don't need to
> support the 40 bit OIU (see Andrew's email).
>
> How about the following definition:
>
> NAME PolicySNAPOIDVariable
> DESCRIPTION The OID value of the Sub-Network Access Protocol (SNAP)
> field for 802.2 SNAP encapsulation.
> The value 00-00-00 indicates the standard SNAP encapsulation
> (RFC 1042).
> OID value 00-00-F8 indicates the bridged ethertype (IEEE
> 802.1H)
>
> ALLOWED VALUE TYPES:
> - PolicyBitStringValue (24 bit)
>
> DERIVED FROM PolicyImplicitVariable
> ABSTRACT FALSE
> PROPERTIES (none)
>
>
> Ron
>
> > -----Original Message-----
> > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On
> > Behalf Of Joel M. Halpern
> > Sent: Tuesday, February 05, 2002 10:52 PM
> > To: Robert Moore; Ron Cohen
> > Cc: bwijnen@lucent.com; 'Mircea Pana'; 'IETF Policy';
> > policy-admin@ietf.org
> > Subject: RE: [Policy] Re: IP Protocol value range
> >
> >
> > If we are going to do that, we should add a PolicySNAPOIDVariable as
> > well. If you are looking at SNAP/SAP encapsulated
> > information, you must
> > check the OID for 0 before you can treat the last two bytes
> > as an etherType.
> > Yours,
> > Joel M. Halpern
> >
> > At 12:56 PM 2/5/02 -0500, Robert Moore wrote:
> > >Let me propose an update to the PCIMe text. If this isn't
> > exactly right,
> > >it should at least be specific enough for people to comment on.
> > >It's a complete replacement for section 5.12.19:
> > >NAMEPolicySNAPTypeVariable DESCRIPTIONThe value of the
> > Sub-Network Access
> > >Protocol (SNAP) Type field for 802.2
> > SNAP encapsulation.
> > >
> > >ALLOWED VALUE TYPES: - PolicyIntegerValue (0..65535) -
> > >PolicyBitStringValue (16 bit)
> > >
> > >DERIVED FROMPolicyImplicitVariable ABSTRACTFALSE PROPERTIES(none)
> > >
> > >
> > >Regards,
> > >Bob
> > >
> > >Bob Moore
> > >Advanced Design and Technology
> > >Application Integration Middleware Division
> > >IBM Software Group
> > >+1-919-254-4436
> > >remoore@us.ibm.com
> > >
> > >d821c.jpg"Ron Cohen" <ronc@ntear.com>
> > >
> > >
> > >d8356.jpg
> > >d836d.jpg
> > >"Ron Cohen" <ronc@ntear.com>
> > >
> > >02/05/02 06:54 AM
> > >
> > >d8380.jpg
> > >
> > >To:"'Mircea Pana'" <mpana@nortelnetworks.com>, Robert
> > Moore/Raleigh/IBM@IBMUS
> > >cc:<bwijnen@lucent.com>, "'IETF Policy'" <policy@ietf.org>,
> > ><policy-admin@ietf.org>
> > >Subject:RE: [Policy] Re: IP Protocol value range
> > >
> > >
> > >Mircea, Bob
> > >
> > >
> > >PCIMe defines:
> > >
> > >PolicySNAPVariable: The protocol number over a Sub-Network Access
> > >Protocol (SNAP) SAP encapsulation.
> > >
> > >Explanation:
> > >
> > >IEEE 802.2 defines two encapsulations, following the
> Ethernet length
> > >field:
> > >
> > >- One with 3 bytes, SSAP, DSAP and CNTRL. The first two are
> > represented
> > >by the PolicySourceSAPVariable and PolicyDestinationSAPVariable.
> > >- The second called the 802.2 SNAP encapsulation, and adds 5 bytes,
> > >where the last two bytes are called the SNAP type. This is the
> > >equivalent of the Ethernet Type. The intention was that the
> > >PolicySNAPVariable would represent this two byte SNAP type field.
> > >
> > >I suggest that we rename this variable to PolicySNAPTypeVriable and
> > >remove the current ambiguity.
> > >
> > >
> > >Ron
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] On
> > > > Behalf Of Mircea Pana
> > > > Sent: Monday, February 04, 2002 5:36 PM
> > > > To: Robert Moore
> > > > Cc: bwijnen@lucent.com; IETF Policy; policy-admin@ietf.org
> > > > Subject: Re: [Policy] Re: IP Protocol value range
> > > >
> > > >
> > > > ...and just to add to my confusion, RFC1042 defines the
> > *same* SNAP
> > > > header as
> > > > "an extension of the LLC header called the Sub-Network
> > Access Protocol
> > > > (SNAP)" :-0
> > > >
> > > > So, a reference to the actual definitions (RFC, IEEE
> > etc.) may help if
> > > > added in PCIMe. IMO, it is less important what exactly
> > this (or other)
> > > > PolicyVariable represents, more important is to define it
> > > > unambiguously.
> > > >
> > > > Regards,
> > > > Mircea.
> > > >
> > > >
> > > > Robert Moore wrote:
> > > > >
> > > > > >SNAP actually stands for "IEEE 802.1a SubNetwork
> > Attachment Point".
> > > > > See
> > > > > >http://www.ietf.org/rfc/rfc1483.txt "4.1. LLC
> Encapsulation for
> > > > > Routed
> > > > > >Protocols" for example. The SNAP header includes two
> > fields: OUI (3
> > > > > >octets) and PID (2 octets).
> > > > > >
> > > > > >I have two comments here:
> > > > > >1. IMO, PCIMe incorrectly describes SNAP as
> "Sub-Network Access
> > > > > >Protocol".
> > > > > >2. Was it intended for the PCIMe class
> "PolicySNAPVariable" to
> > > > > represent
> > > > > >only the PID part of the SNAP header (2 octets)? Or should
> > > > it reflect
> > > > > >the entire header: OUI+PID (5 octets).
> > > > >
> > > > > To be honest, I don't know what we meant to refer to with
> > > > > PolicySNAPVariable. (I think this class came from Cisco - in
> > > > > any case, I know it didn't come from IBM.) Some possibilities:
> > > > >
> > > > > Currently in PCIMe: Sub-Network Access Protocol.
> > > > >
> > > > > Mircea's suggestion: IEEE 802.1a SubNetwork Attachment Point.
> > > > >
> > > > > On acronymfinder.com: Subnetwork Access Protocol,
> > > > > Standard Network Access Protocol (in bold, for some
> > > > > reason), Small Network Access Package, and a bunch
> > > > > of other options that are plainly not what we're
> > > > > talking about.
> > > > >
> > > > > Maybe Andrea, or Yoram, or Yoram, or Ron, or John can tell
> > > > > us what we meant when we defined PolicySNAPVariable.
> > > > > And maybe they'll even agree! :-)
> > > > >
> > > > > Regards,
> > > > > Bob
> > > > >
> > > > > Bob Moore
> > > > > Advanced Design and Technology
> > > > > Application Integration Middleware Division
> > > > > IBM Software Group
> > > > > +1-919-254-4436
> > > > > remoore@us.ibm.com
> > > >
> > > > _______________________________________________
> > > > Policy mailing list
> > > > Policy@ietf.org
> > > >
> > >
> > <https://www1.ietf.org/mailman/listinfo/policy>https://www1.ie
> tf.org/mailm
> > an/listinfo/policy
> > >
> >
> >
>
>
> _______________________________________________
> Policy mailing list
> Policy@ietf.org
> https://www1.ietf.org/mailman/listinfo/policy
>


_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy

--1__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E-- --0__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=0ABBE1CEDFE6701E8f9e8a93@raleigh.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=0ABBE1CEDFE6701E8f9e8a93@raleigh.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABBE1CEDFE6701E8f9e8a93df938690918c0ABBE1CEDFE6701E-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Tue Feb 12 16:49:57 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 QAA28670 for ; Tue, 12 Feb 2002 16:49:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15705 for policy-archive@odin.ietf.org; Tue, 12 Feb 2002 16:49: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 QAA14081; Tue, 12 Feb 2002 16:11:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14048 for ; Tue, 12 Feb 2002 16:11:08 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27461 for ; Tue, 12 Feb 2002 16:11:05 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA14542; Tue, 12 Feb 2002 15:06:13 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1CLB07190600; Tue, 12 Feb 2002 16:11:01 -0500 To: policy@ietf.org Cc: wg-network@dmtf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Tue, 12 Feb 2002 16:15:22 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_02042002 Pre-release 1|February 04, 2002) at 02/12/2002 04:11:01 PM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE1CDDFE0661D8f9e8a93df938690918c0ABBE1CDDFE0661D" Content-Disposition: inline Subject: [Policy] One more PCIMe change: IPHeadersFilter.HdrDSCP Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1CDDFE0661D8f9e8a93df938690918c0ABBE1CDDFE0661D Content-type: text/plain; charset=US-ASCII Since we seem to be behaving as if we're in an IETF Last Call for PCIMe, I have one more minor change to propose, based on discussions we had in the DMTF Networks WG. Currently, the property IPHeadersFilter.HdrDSCP has the syntax uint8, representing a single DSCP. The proposal is to change its syntax to uint8[ ] (an array of uint8's), so that it can represent an unordered, ORed list of DSCPs. Currently it would take three entire IPHeadersFilter instances to match on "DSCP 10, 11, or 12". This can easily be streamlined to one instance by making this change to the syntax of the HdrDSCP property. Does anybody think this is a bad idea? Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com --0__=0ABBE1CDDFE0661D8f9e8a93df938690918c0ABBE1CDDFE0661D Content-type: text/html; charset=US-ASCII Content-Disposition: inline Since we seem to be behaving as if we're in an IETF Last Call for PCIMe, I have one more minor change to propose, based on discussions we had in the DMTF Networks WG. Currently, the property IPHeadersFilter.HdrDSCP has the syntax uint8, representing a single DSCP. The proposal is to change its syntax to uint8[ ] (an array of uint8's), so that it can represent an unordered, ORed list of DSCPs.

Currently it would take three entire IPHeadersFilter instances to match on "DSCP 10, 11, or 12". This can easily be streamlined to one instance by making this change to the syntax of the HdrDSCP property.

Does anybody think this is a bad idea?

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com
--0__=0ABBE1CDDFE0661D8f9e8a93df938690918c0ABBE1CDDFE0661D-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Tue Feb 12 17:23:29 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 RAA29406 for ; Tue, 12 Feb 2002 17:23:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17781 for policy-archive@odin.ietf.org; Tue, 12 Feb 2002 17:23: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 QAA15903; Tue, 12 Feb 2002 16:57:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15873 for ; Tue, 12 Feb 2002 16:57:37 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28863 for ; Tue, 12 Feb 2002 16:57:32 -0500 (EST) Received: from [63.113.114.131] (HELO joel) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2786936; Tue, 12 Feb 2002 16:57:33 -0500 Message-Id: <4.2.2.20020212165150.00a75f00@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 12 Feb 2002 16:53:14 -0500 To: "Robert Moore" , policy@ietf.org From: "Joel M. Halpern" Subject: Re: [Policy] One more PCIMe change: IPHeadersFilter.HdrDSCP Cc: wg-network@dmtf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Since the reality is that this will almost always require three filters, I find it strange to try to compress this particular representation. We allow blocks of IP addresses because the reliaty is that prefixes are something filters match on. Unless we want to get into masked DSCPs (please, no, lets not go there) I would think we were better off sticking to single values for this field. Yours, Joel M. Halpern At 04:15 PM 2/12/02 -0500, Robert Moore wrote: >Since we seem to be behaving as if we're in an IETF Last Call for PCIMe, I >have one more minor change to propose, based on discussions we had in the >DMTF Networks WG. Currently, the property IPHeadersFilter.HdrDSCP has the >syntax uint8, representing a single DSCP. The proposal is to change its >syntax to uint8[ ] (an array of uint8's), so that it can represent an >unordered, ORed list of DSCPs. > >Currently it would take three entire IPHeadersFilter instances to match on >"DSCP 10, 11, or 12". This can easily be streamlined to one instance by >making this change to the syntax of the HdrDSCP property. > >Does anybody think this is a bad idea? > >Regards, >Bob > >Bob Moore >Advanced Design and Technology >Application Integration Middleware Division >IBM Software Group >+1-919-254-4436 >remoore@us.ibm.com _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Tue Feb 12 18:14:22 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 SAA00445 for ; Tue, 12 Feb 2002 18:14:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA19876 for policy-archive@odin.ietf.org; Tue, 12 Feb 2002 18:14:23 -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 RAA19110; Tue, 12 Feb 2002 17:56:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19078 for ; Tue, 12 Feb 2002 17:56:10 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00170 for ; Tue, 12 Feb 2002 17:56:06 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CMqT507597; Tue, 12 Feb 2002 17:52:29 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CMqNJ11221; Tue, 12 Feb 2002 17:52:23 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NNLXSBY; Tue, 12 Feb 2002 17:52:22 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1MRS5VPT; Tue, 12 Feb 2002 17:52:24 -0500 Message-ID: <3C699D95.65D28DA7@metasolv.com> Date: Tue, 12 Feb 2002 17:56:21 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: policy@ietf.org CC: "Joel M. Halpern" , Robert Moore , wg-network@dmtf.org Subject: Re: [Policy] One more PCIMe change: IPHeadersFilter.HdrDSCP References: <4.2.2.20020212165150.00a75f00@mail.stevecrocker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit I prefer the "compact-ness" of the filter resulting from Bob's suggestion for the reason that it is easier to manage. This may be translated into multiple simpler filters for devices that do not support sets of DSCP. Similarly, for example, a mirrored Compound Filter may be translated into two Compound Conditions for devices that do not understand "isMirrored". Regards, Mircea "Joel M. Halpern" wrote: > > Since the reality is that this will almost always require three filters, I > find it strange to try to compress this particular representation. We > allow blocks of IP addresses because the reliaty is that prefixes are > something filters match on. Unless we want to get into masked DSCPs > (please, no, lets not go there) I would think we were better off sticking > to single values for this field. > Yours, > Joel M. Halpern > > At 04:15 PM 2/12/02 -0500, Robert Moore wrote: > >Since we seem to be behaving as if we're in an IETF Last Call for PCIMe, I > >have one more minor change to propose, based on discussions we had in the > >DMTF Networks WG. Currently, the property IPHeadersFilter.HdrDSCP has the > >syntax uint8, representing a single DSCP. The proposal is to change its > >syntax to uint8[ ] (an array of uint8's), so that it can represent an > >unordered, ORed list of DSCPs. > > > >Currently it would take three entire IPHeadersFilter instances to match on > >"DSCP 10, 11, or 12". This can easily be streamlined to one instance by > >making this change to the syntax of the HdrDSCP property. > > > >Does anybody think this is a bad idea? > > > >Regards, > >Bob > > > >Bob Moore > >Advanced Design and Technology > >Application Integration Middleware Division > >IBM Software Group > >+1-919-254-4436 > >remoore@us.ibm.com > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Thu Feb 14 16:25:23 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 QAA10183 for ; Thu, 14 Feb 2002 16:25:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27697 for policy-archive@odin.ietf.org; Thu, 14 Feb 2002 16:25:26 -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 QAA26899; Thu, 14 Feb 2002 16:06: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 QAA26842 for ; Thu, 14 Feb 2002 16:06:24 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09732 for ; Thu, 14 Feb 2002 16:06:20 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EL5oY11367 for ; Thu, 14 Feb 2002 16:05:50 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EL5mo02351 for ; Thu, 14 Feb 2002 16:05:48 -0500 (EST) Received: from zcard04n.ca.nortel.com ([47.129.242.86]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1NNL9CL9; Thu, 14 Feb 2002 16:05:46 -0500 Received: from metasolv.com (mpana-1.ca.nortel.com [47.128.213.55]) by zcard04n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1MRS5Y1D; Thu, 14 Feb 2002 16:05:48 -0500 Message-ID: <3C6C2796.253FE13C@metasolv.com> Date: Thu, 14 Feb 2002 16:09:42 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: Mircea Pana Reply-To: mpana@metasolv.com Organization: Metasolv Software X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF Policy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Policy] condition evaluation order Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit PCIM and PCIMe do not provide a mechanism for ordering conditions in a set (PolicyConditionStructure in PCIMe). This, mathematically speaking, is correct because the boolean operators AND and OR are commutative (E.g.: "a AND b" is equivalent to "b AND a"). However, in reality, the order of the operands (aggregated PolicyConditions) may have an important impact on the performance of the expression evaluation. This is true when shortcut evaluation is used (evaluation stops as soon as the result is obvious) - and most compilers support that. Example 1: Among the two domain filters below, the evaluation of the first one may be more efficient for packets coming from 10.x.x.x sources. The evaluation of the second one may involve a DNS call for every packet. 1. (SrcIP=10.x.x.x OR SrcIP=abc.bigco.com) AND DstIP=www.bigco.com 2. (SrcIP=abc.bigco.com OR SrcIP=10.x.x.x) AND DstIP=www.bigco.com Example 2: 1. (Src=10.x.x.x OR Src=1.2.x.x OR Src=3.4.5.6) AND ... 2. (Src=3.4.5.6 OR Src=1.2.x.x OR Src=10.x.x.x) AND ... Filter 1. may be more efficient than Filter 2. in an administrative domain where the traffic has an equal distribution. However, in a domain where Src=3.4.5.6 produces most of the traffic, Filter 2. may be more efficient. Has anybody encountered this issue yet? I would appreciate any suggestions. I know that the PCIMe feature list is closed now, so I guess that whatever I do to resolve this issue would be a non-standard solution. Right? Regards, Mircea. _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Fri Feb 15 07:27:46 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 HAA03253 for ; Fri, 15 Feb 2002 07:27:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16667 for policy-archive@odin.ietf.org; Fri, 15 Feb 2002 07:27:47 -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 HAA16393; Fri, 15 Feb 2002 07:19:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16353 for ; Fri, 15 Feb 2002 07:19:56 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03054; Fri, 15 Feb 2002 07:19:54 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA123310; Fri, 15 Feb 2002 06:15:00 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1FCJsa241184; Fri, 15 Feb 2002 07:19:54 -0500 Subject: Re: [Policy] condition evaluation order To: mpana@metasolv.com Cc: IETF Policy , policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Fri, 15 Feb 2002 07:24:23 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_02042002 Pre-release 1|February 04, 2002) at 02/15/2002 07:19:53 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE1F2DFD0CA2D8f9e8a93df938690918c0ABBE1F2DFD0CA2D" Content-Disposition: inline Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1F2DFD0CA2D8f9e8a93df938690918c0ABBE1F2DFD0CA2D Content-type: text/plain; charset=US-ASCII Mircea, Way back at the beginning of the Policy work, we discussed this exact point. (I don't remember now whether we did this wearing our IETF hats or our DMTF hats, but it doesn't really matter.) We decided that rather than putting something into the model to let the Policy Administrator indicate an order for condition evaluation, we would leave it up to each PEP (or PDP) to optimize its own order for condition evaluation. We recognized that there would be some cases where the Policy Administrator would have been able to help the PEP / PDP with this optimization, by providing it with a recommended ordering based on information that it did not have. But we decided that on balance there weren't going to be enough of these cases to justify the additional complexity in the model. There was also concern about cases where the Policy Administrator might specify an evaluation order which, because of the way it was implemented, a particular PEP / PDP would be unable to honor. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com --0__=0ABBE1F2DFD0CA2D8f9e8a93df938690918c0ABBE1F2DFD0CA2D Content-type: text/html; charset=US-ASCII Content-Disposition: inline Mircea,

Way back at the beginning of the Policy work, we discussed
this exact point. (I don't remember now whether we did
this wearing our IETF hats or our DMTF hats, but it doesn't
really matter.) We decided that rather than putting
something into the model to let the Policy Administrator
indicate an order for condition evaluation, we would leave
it up to each PEP (or PDP) to optimize its own order for
condition evaluation. We recognized that there would be
some cases where the Policy Administrator would have been
able to help the PEP / PDP with this optimization, by
providing it with a recommended ordering based on information
that it did not have. But we decided that on balance there
weren't going to be enough of these cases to justify the
additional complexity in the model. There was also concern
about cases where the Policy Administrator might specify an
evaluation order which, because of the way it was implemented,
a particular PEP / PDP would be unable to honor.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com
--0__=0ABBE1F2DFD0CA2D8f9e8a93df938690918c0ABBE1F2DFD0CA2D-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Mon Feb 25 10:57:05 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 KAA14954 for ; Mon, 25 Feb 2002 10:57:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27968 for policy-archive@odin.ietf.org; Mon, 25 Feb 2002 10:57:08 -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 KAA27388; Mon, 25 Feb 2002 10:45:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27356 for ; Mon, 25 Feb 2002 10:45:08 -0500 (EST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14406 for ; Mon, 25 Feb 2002 10:45:03 -0500 (EST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1PFjbI33050; Mon, 25 Feb 2002 16:45:38 +0100 (CET) Received: from [192.168.102.79] (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 187A9C040; Mon, 25 Feb 2002 16:44:27 +0100 (CET) Date: Mon, 25 Feb 2002 16:57:13 +0100 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de To: mpana@metasolv.com, IETF Policy Subject: Re: [Policy] condition evaluation order Message-ID: <22499772.1014656233@[192.168.102.79]> In-Reply-To: <3C6C2796.253FE13C@metasolv.com> References: <3C6C2796.253FE13C@metasolv.com> X-Mailer: Mulberry/2.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org Content-Transfer-Encoding: 7bit Since this really implementation dependent I would like to stay out of it. Additionally, I assume that PDPs/PEPs taking rules as input will convert them into an internal representation anyway. That step can be used to optimize for whatever execution engine you are running. And I think in most case you can define a heuristice to get good results. Marcus --On Thursday, February 14, 2002 4:09 PM -0500 Mircea Pana wrote: > PCIM and PCIMe do not provide a mechanism for ordering conditions in a > set (PolicyConditionStructure in PCIMe). This, mathematically speaking, > is correct because the boolean operators AND and OR are commutative > (E.g.: "a AND b" is equivalent to "b AND a"). > > However, in reality, the order of the operands (aggregated > PolicyConditions) may have an important impact on the performance of the > expression evaluation. This is true when shortcut evaluation is used > (evaluation stops as soon as the result is obvious) - and most compilers > support that. > > Example 1: Among the two domain filters below, the evaluation of the > first one may be more efficient for packets coming from 10.x.x.x > sources. The evaluation of the second one may involve a DNS call for > every packet. > 1. (SrcIP=10.x.x.x OR SrcIP=abc.bigco.com) AND DstIP=www.bigco.com > 2. (SrcIP=abc.bigco.com OR SrcIP=10.x.x.x) AND DstIP=www.bigco.com > > Example 2: > 1. (Src=10.x.x.x OR Src=1.2.x.x OR Src=3.4.5.6) AND ... > 2. (Src=3.4.5.6 OR Src=1.2.x.x OR Src=10.x.x.x) AND ... > Filter 1. may be more efficient than Filter 2. in an administrative > domain where the traffic has an equal distribution. However, in a domain > where Src=3.4.5.6 produces most of the traffic, Filter 2. may be more > efficient. > > Has anybody encountered this issue yet? I would appreciate any > suggestions. I know that the PCIMe feature list is closed now, so I > guess that whatever I do to resolve this issue would be a non-standard > solution. Right? > > Regards, > Mircea. > > _______________________________________________ > Policy mailing list > Policy@ietf.org > https://www1.ietf.org/mailman/listinfo/policy > -------------------------------------- Dr. Marcus Brunner Network Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.brubers.org/marcus _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed Feb 27 09:41:18 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 JAA24768 for ; Wed, 27 Feb 2002 09:41:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23569 for policy-archive@odin.ietf.org; Wed, 27 Feb 2002 09:41:22 -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 JAA22483; Wed, 27 Feb 2002 09:28:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22450 for ; Wed, 27 Feb 2002 09:28:15 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23989 for ; Wed, 27 Feb 2002 09:28:09 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA52766 for ; Wed, 27 Feb 2002 08:23:02 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1RESBg49208 for ; Wed, 27 Feb 2002 09:28:11 -0500 To: policy@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Wed, 27 Feb 2002 09:33:06 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_02042002 Pre-release 1|February 04, 2002) at 02/27/2002 09:28:11 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE1FEDFDD741A8f9e8a93df938690918c0ABBE1FEDFDD741A" Content-Disposition: inline Subject: [Policy] PCIMe-07 submitted Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1FEDFDD741A8f9e8a93df938690918c0ABBE1FEDFDD741A Content-type: text/plain; charset=US-ASCII I have just submitted an -07 version of PCIMe to the Internet-Drafts repository. This update reflects a number of changes in the representation of packet headers for filtering. None of the changes is major, all have been discussed on the list, and all appear to have WG consensus. Briefly, here's what changed: With respect to IpHeadersFilter: - In response to a request from IPSP, the capability to filter on source and destination address ranges was added. - As a minor optimization, the ability to specify a set of DSCPs in a filter, rather than just a single DSCP, was added. With respect to filters expressed as variables and values: - Range constraints were added, and expressed consistently, for all variables corrsponding to header fields. - The PolicySNAPVariable class was split into two classes, PolicySNAPOUIVariable and PolicySNPATypeVariable, and its usage was clarified. I believe that with these updates, PCIMe is ready to move forward to the IESG. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com --0__=0ABBE1FEDFDD741A8f9e8a93df938690918c0ABBE1FEDFDD741A Content-type: text/html; charset=US-ASCII Content-Disposition: inline I have just submitted an -07 version of PCIMe to the Internet-Drafts repository. This update reflects a number of changes in the representation of packet headers for filtering. None of the changes is major, all have been discussed on the list, and all appear to have WG consensus. Briefly, here's what changed:

With respect to IpHeadersFilter:

- In response to a request from IPSP, the capability to filter on source and destination address ranges was added.
- As a minor optimization, the ability to specify a set of DSCPs in a filter, rather than just a single DSCP, was added.

With respect to filters expressed as variables and values:

- Range constraints were added, and expressed consistently, for all variables corrsponding to header fields.
- The PolicySNAPVariable class was split into two classes, PolicySNAPOUIVariable and PolicySNPATypeVariable, and its usage was clarified.

I believe that with these updates, PCIMe is ready to move forward to the IESG.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com
--0__=0ABBE1FEDFDD741A8f9e8a93df938690918c0ABBE1FEDFDD741A-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@optimus.ietf.org Wed Feb 27 10:16:40 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 KAA26657 for ; Wed, 27 Feb 2002 10:16:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA25533 for policy-archive@odin.ietf.org; Wed, 27 Feb 2002 10:16:42 -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 JAA24236; Wed, 27 Feb 2002 09:56:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24205 for ; Wed, 27 Feb 2002 09:56:08 -0500 (EST) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25498 for ; Wed, 27 Feb 2002 09:56:05 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA22960 for ; Wed, 27 Feb 2002 08:52:52 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1REu7g227782 for ; Wed, 27 Feb 2002 09:56:07 -0500 To: policy@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Wed, 27 Feb 2002 10:01:02 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M12_02042002 Pre-release 1|February 04, 2002) at 02/27/2002 09:56:06 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBE1FEDFC221688f9e8a93df938690918c0ABBE1FEDFC22168" Content-Disposition: inline Subject: [Policy] QDDIM-07 submitted Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0__=0ABBE1FEDFC221688f9e8a93df938690918c0ABBE1FEDFC22168 Content-type: text/plain; charset=US-ASCII I have just submitted an -07 version of QDDIM to the Internet-Drafts repository. This update includes three sets of changes that were agreed to in SLC: - I added text to a number of the enumeration properties, saying how an agent should behave if it finds an unexpected/illegal value in the property. - Walter and Andrea updated the association between classifiers and classifier elements, to let the model accommodate cascaded classifiers. - Joel, with editorial help from John and me, updated the QoSService class and its subclasses, to clarify and simplify that part of the model. Since I wasn't in SLC, I don't know what is supposed to happen next with QDDIM. It seems to me, though, that the -07 version should be ready for a fairly quick WG Last Call. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com --0__=0ABBE1FEDFC221688f9e8a93df938690918c0ABBE1FEDFC22168 Content-type: text/html; charset=US-ASCII Content-Disposition: inline I have just submitted an -07 version of QDDIM to the Internet-Drafts repository. This update includes three sets of changes that were agreed to in SLC:

- I added text to a number of the enumeration properties, saying how an agent should behave if it finds an unexpected/illegal value in the property.
- Walter and Andrea updated the association between classifiers and classifier elements, to let the model accommodate cascaded classifiers.
- Joel, with editorial help from John and me, updated the QoSService class and its subclasses, to clarify and simplify that part of the model.

Since I wasn't in SLC, I don't know what is supposed to happen next with QDDIM. It seems to me, though, that the -07 version should be ready for a fairly quick WG Last Call.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com
--0__=0ABBE1FEDFC221688f9e8a93df938690918c0ABBE1FEDFC22168-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy From daemon@ns.ietf.org Thu Feb 28 00:45:08 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 AAA04615 for ; Thu, 28 Feb 2002 00:45:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA25729 for policy-archive@odin.ietf.org; Thu, 28 Feb 2002 00:45:09 -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 AAA24685; Thu, 28 Feb 2002 00:22:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24659 for ; Thu, 28 Feb 2002 00:22:42 -0500 (EST) Received: from mx-s0.dreamwiz.com (mx-s0.dreamwiz.com [211.174.54.135]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04444 for ; Thu, 28 Feb 2002 00:22:36 -0500 (EST) Received: from mail13.dreamwiz.com (mail13.dreamwiz.com [211.174.54.33]) by mx-s0.dreamwiz.com (8.12.2/8.12.2) with ESMTP id g1S5Mbc3037850 for ; Thu, 28 Feb 2002 14:22:38 +0900 (KST) Received: from localhost (localhost [127.0.0.1]) by mail13.dreamwiz.com (8.12.2/8.12.2) with ESMTP id g1S5MakO070126 for ; Thu, 28 Feb 2002 14:22:36 +0900 (KST) Message-Id: <200202280522.g1S5MakO070126@mail13.dreamwiz.com> Date: Thu, 28 Feb 2002 14:22:36 +0900 (KST) From: =?EUC-KR?B?seixpL+1?= Reply-To: silan@dreamwiz.com To: policy@ietf.org Organization: http://my.dreamwiz.com/silan X-Sender-IP: 211.46.81.1 X-Sender-ID: silan@dreamwiz.com X-Priority: 3 X-Mailer: DreamWiz Web-Mailer V1.32 X-DreamWiz-Data: receive_check=1;save=mail13.dreamwiz.com:silan:Sent:229; MIME-Version: 1.0 Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="0-1273906818-1014873756=:70121" Subject: [Policy] subscribe Sender: policy-admin@ietf.org Errors-To: policy-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Policy Framework X-BeenThere: policy@ietf.org --0-1273906818-1014873756=:70121 Content-Type: TEXT/PLAIN; CHARSET=EUC-KR Content-Transfer-Encoding: 8BIT subscribe 행복한 하루 되세요! *^_^* 우리집은 http://my.dreamwiz.com/silan ------------------------------------------------- DreamWiz Free Mail @ http://www.dreamwiz.com/ DreamSearch Click the world!!! http://search.dreamwiz.com/ --0-1273906818-1014873756=:70121 Content-Type: TEXT/HTML; CHARSET=EUC-KR Content-Transfer-Encoding: 8BIT
subscribe


행복한 하루 되세요! *^_^*
우리집은 http://my.dreamwiz.com/silan

Your life on the net



--0-1273906818-1014873756=:70121-- _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy