From owner-rap@ops.ietf.org Sun Feb 2 07:20:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04935 for ; Sun, 2 Feb 2003 07:20:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fJ8E-000Evp-00 for rap-data@psg.com; Sun, 02 Feb 2003 04:21:54 -0800 Received: from ierw.net.avaya.com ([198.152.13.101]) by psg.com with esmtp (Exim 3.36 #1) id 18fJ8B-000EvX-00 for rap@ops.ietf.org; Sun, 02 Feb 2003 04:21:51 -0800 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10334 for ; Sun, 2 Feb 2003 07:19:18 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10310 for ; Sun, 2 Feb 2003 07:19:16 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Sun, 2 Feb 2003 14:21:47 +0200 Message-ID: Thread-Topic: [Diffserv] RE: FW: FlowId and FlowIdOrAny Thread-Index: AcLIrSk81FfnkI0/Sti+aAR+u4bkmACCBqyg From: "Romascanu, Dan (Dan)" To: "Wijnen, Bert (Bert)" , "Sahita, Ravi" , "Rap-wg (E-mail)" X-Spam-Status: No, hits=-0.1 required=5.0 tests=OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA04935 The -1 value is not needed in SSPM MIB. The object sspmSourceProfileFlowLabel has a MAX-ACCESS read-create, and one MUST specify a meaningful flow id value to be carried by the packet. Dan > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, January 31, 2003 12:14 AM > To: Sahita, Ravi; 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > Right, that seems an approach by which your RFC does not have > to get held up for too long (well, at least not too much longer > than has already happened). > Not sure if you saw this, but I have also posted the mail > on FlowLabel and FlowLabelOrAny on the mibs@ops.ietf.mailing > list, so that we get dicsussion from other MIB folk as well. > ANd I posted it to the authors of the other documents that > were mentioned. > > All seems to be fine except for one question. > And that is: if the range is indeed the correct one. > Let me try and drive to consensus on that on the mibs mailing > list. Pls do join in in the discussion there when you see fit. > > Thanks, > Bert > > > -----Original Message----- > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > > Sent: donderdag 30 januari 2003 22:34 > > To: 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > Bert, > > > > Of the choices you provided, I am tending towards this resolution > > for the frwkIpFilterFlowId object. When the TCs are eventually put > > in a different ID and RFC'ed, we can update the type for > this object. > > > > Ravi > > > > frwkIpFilterFlowId OBJECT-TYPE > > SYNTAX Integer32 (-1 | 0..1048575) > > DESCRIPTION > > "The flow identifier or flow label in an IPv6 header > > that may be used to discriminate traffic flows. > > The value of -1 for this attribute MUST imply that > > any flow label value in the IPv6 header will match, > > resulting in the flow label field of the IPv6 header > > being ignored for matching this filter entry." > > > > > > > > | -----Original Message----- > > | From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > | Sent: Monday, January 27, 2003 1:49 PM > > | To: Rap-wg (E-mail); Diffserv@ietf.org > > | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > | > > | > > | I am not hearing much progress. > > | > > | Appology for a long email posting. But I think it > > | addresses all the issues and occurences of flowId > > | or flowLabel (at least till someone tells me they > > | found yet another one ;-)) > > | > > | The biggest problem exists for the RAP WG document > > | for the framework PIB, cause it is in RFC 48-hour > > | author call (for over a month already). > > | > > | The DIFFSERV PIB (also in RFC 38-hour author call > > | for the same amount of time) of course cannot be > > | published since it depends on the framework pib. > > | > > | The issue at hand is the question on how to specify > > | that a flowID be ignored (wild-carded) for a filter. > > | I think we've come to the conclusion that both the > > | MIB and the PIB solutions need this. So we need > > | a common solution. > > | > > | We've also found 3 other places where a flowID > > | or a flowLabel (but the same thing is meant) is > > | being used. That is in: > > | > > | - draft-ietf-ipsp-ipsec-conf-mib-05.txt > > | which uses a 3-byte octet string and that seems wrong > > | SYNTAX OCTET STRING (SIZE(3)) > > | > > | - draft-ietf-rmonmib-sspm-mib-06.txt > > | which uses an Integer32: > > | SYNTAX Integer32 (0..1048575) -- 20-bit range (0 > to 0xfffff) > > | > > | - Integrated services MIB (RFC 2213) > > | which uses INTEGER > > | SYNTAX INTEGER (0..16777215) > > | > > | The Diffserv MIB (RFC3289) and the framework PIB were > > | using an Unsigned 32, namely > > | SYNTAX Unsigned32 (0..1048575) > > | > > | The framework PIB authors were suggesting a modification > > | SYNTAX Unsigned32 (4294967295 | 0..1048575) > > | So that the value 4294967295 would mean any (in other words > > | one would ignore the flowID in when filtering). > > | > > | Fred (amin editor of the Diffserv MIB) wanted to add a > > | boolean mib object to indicate if the flowID should be > > | ignored when filtering. > > | > > | What I as OPS AD for the NM side see is that we have > > | - too many different ways to represent a flowID or flowLabel. > > | - there is currently no way to define a flowID or any > > | - we need need a facility to specify flowIdOrAny. > > | - we prefer to have one solution. > > | - we have some docs that are still IDs and can easily > > | be changed. > > | - we have two docs that are difficult to change, namely > > | the DIFSERV and the INTEGRATED SERVICES MIB. > > | The difficulty is that if we change the encoding on the > > | wire that we need to deprecate existing object and add > > | a new one. If we keep the wire encoding the same, I think > > | we can defend that it is a bug fix and the fact that some > > | potential new values are now valid is acceptable; at least > > | it would be less of a problem than having to deprecate > > | an object and add a new one. > > | - But even the two RFCs have different SYNTAX, so at least > > | one of them needs to change if we want to specify > > | flowID in a consistent way. > > | > > | So what do people want to do. > > | > > | My proposal is to do the following: > > | > > | - Someone creates a new ID that contains a small MIB module > > | that contains two TCs: > > | > > | FlowId TEXTUAL-CONVENTION > > | DISPLAY-HINT "d" > > | STATUS current > > | DESCRIPTION "The flow identifier or flow Label in an IPv6 > > | header that may be used to > discriminate traffic > > | flows. > > | " > > | SYNTAX Integer32 (0..1048575) > > | > > | FlowIdOrAny TEXTUAL-CONVENTION > > | DISPLAY-HINT "d" > > | STATUS current > > | DESCRIPTION "The flow identifier or flow lable in an IPv6 > > | header that may be used to > discriminate traffic > > | flows. The value of -1 is used to indicate a > > | wildcard, i.e. any value. > > | " > > | SYNTAX Integer32 (-1 | 0..1048575) > > | > > | We probably want to run this quickly by the IPv6 WG. > > | > > | What it would mean for the various documents is the following: > > | > > | - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a > > | co-author/editor..., whenever a new revision is done: > > | - import the new FlowId TC > > | - replace > > | intSrvFlowFlowId OBJECT-TYPE > > | SYNTAX INTEGER (0..16777215) > > | with > > | intSrvFlowFlowId OBJECT-TYPE > > | SYNTAX FlowId > > | I think we can consider this a BUG fix and allow this change > > | that reduces the range of possible values. > > | - by the way, I when I see intSrvFlowIfAddr, then probably > > | we would want that to be done with the TCs from the > > | INET-ADDRESS-MIB. I also wonder about the Port TC in that > > | module > > | > > | - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever > > | a new revision is done, I think we need to: > > | - import the new FlowIdOrAny TC > > | - deprecate object diffServMultiFieldClfrFlowId > > | - define a new object diffServMultiFieldClfrFlowLabel ?? > > | or maybe diffServMultiFieldClfrFlowIdOrAny > > | with syntax FlowIdOrAny > > | - deprecate current MODULE-COMPLIANCEs, define a new one > > | to remove ... FlowId and add ...FlowLable > > | > > | - For the draft-ietf-rap-frameworkpib-09.txt (or better the > > | RFC-to-be) the final fix would be to make this change: > > | - import FlowIdOrAny TC > > | - replace > > | frwkIpFilterFlowId OBJECT-TYPE > > | SYNTAX Unsigned32 (0..1048575) > > | with > > | frwkIpFilterFlowId OBJECT-TYPE > > | SYNTAX FlowIdOrAny > > | - we can consider this as a last minute bug fix. > > | If we agree that the final change may take too long, then we > > | can make a temp fix: > > | - replace > > | frwkIpFilterFlowId OBJECT-TYPE > > | SYNTAX Unsigned32 (0..1048575) > > | with > > | frwkIpFilterFlowId OBJECT-TYPE > > | SYNTAX Integer32 (-1 | 0..1048575) > > | DESCRIPTION "The flow identifier or flow lable > in an IPv6 > > | header that may be used to > > discriminate traffic > > | flows. The value of -1 is used to > indicate a > > | wildcard, i.e. any value. > > | " > > | - whenever the RFC gets revised, then this can be replaced > > | with the final fix, cause it does not change anything on > > | the wire. > > | > > | - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > > | Wes Hardaker, we can fix it as follows > > | - import FlowId > > | - replace > > | ihfIPv6FlowLabel OBJECT-TYPE > > | SYNTAX OCTET STRING (SIZE(3)) > > | with > > | ihfIPv6FlowLabel OBJECT-TYPE > > | SYNTAX FlowId > > | - this is still an ID, so the change is OK. > > | Also, they use a BITS mask to indicate if the flowlabel > > | must be ignored or not. So this works. It is a bit different > > | than it is done in diffserv mib and framework pib, > but at least > > | it uses the same spec for FlowId. (or flowLabel) > > | > > | - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is > > main editor > > | it would mean > > | - import FlowId > > | - replace > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > | SYNTAX Integer32 (0..1048575) -- 20-bit range > > | (0 to 0xfffff) > > | with > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > | SYNTAX FlowId > > | - this is still an ID, so the change is OK > > | > > | > > | Thanks, > > | Bert > > | _______________________________________________ > > | diffserv mailing list > > | diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv > > | Archive: > > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre > > nt/maillist.html > > > > From owner-rap@ops.ietf.org Mon Feb 3 04:46:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01625 for ; Mon, 3 Feb 2003 04:46:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fdDM-000478-00 for rap-data@psg.com; Mon, 03 Feb 2003 01:48:32 -0800 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 18fdDJ-00046w-00 for rap@ops.ietf.org; Mon, 03 Feb 2003 01:48:29 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h139mQb03520 for ; Mon, 3 Feb 2003 04:48:27 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 10:48:25 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C83D9C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , "Wijnen, Bert (Bert)" , "Sahita, Ravi" , "Rap-wg (E-mail)" Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Mon, 3 Feb 2003 10:48:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.2 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk So Dan, you would use the one intended as FlowLabel (which does not include the -1 value). The -1 value is for cases of FlowLableOrAny. I was worried more about the question if the range 0..1048575 is the correct range for FlowLabels. Thanks, Bert > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: zondag 2 februari 2003 13:22 > To: Wijnen, Bert (Bert); Sahita, Ravi; Rap-wg (E-mail) > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > The -1 value is not needed in SSPM MIB. The object > sspmSourceProfileFlowLabel has a MAX-ACCESS read-create, and > one MUST specify a meaningful flow id value to be carried by > the packet. > > Dan > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Friday, January 31, 2003 12:14 AM > > To: Sahita, Ravi; 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > Right, that seems an approach by which your RFC does not have > > to get held up for too long (well, at least not too much longer > > than has already happened). > > Not sure if you saw this, but I have also posted the mail > > on FlowLabel and FlowLabelOrAny on the mibs@ops.ietf.mailing > > list, so that we get dicsussion from other MIB folk as well. > > ANd I posted it to the authors of the other documents that > > were mentioned. > > > > All seems to be fine except for one question. > > And that is: if the range is indeed the correct one. > > Let me try and drive to consensus on that on the mibs mailing > > list. Pls do join in in the discussion there when you see fit. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > > > Sent: donderdag 30 januari 2003 22:34 > > > To: 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > > > > Bert, > > > > > > Of the choices you provided, I am tending towards this resolution > > > for the frwkIpFilterFlowId object. When the TCs are > eventually put > > > in a different ID and RFC'ed, we can update the type for > > this object. > > > > > > Ravi > > > > > > frwkIpFilterFlowId OBJECT-TYPE > > > SYNTAX Integer32 (-1 | 0..1048575) > > > DESCRIPTION > > > "The flow identifier or flow label in an IPv6 header > > > that may be used to discriminate traffic flows. > > > The value of -1 for this attribute MUST imply that > > > any flow label value in the IPv6 header will match, > > > resulting in the flow label field of the IPv6 header > > > being ignored for matching this filter entry." > > > > > > > > > > > > | -----Original Message----- > > > | From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > | Sent: Monday, January 27, 2003 1:49 PM > > > | To: Rap-wg (E-mail); Diffserv@ietf.org > > > | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > | > > > | > > > | I am not hearing much progress. > > > | > > > | Appology for a long email posting. But I think it > > > | addresses all the issues and occurences of flowId > > > | or flowLabel (at least till someone tells me they > > > | found yet another one ;-)) > > > | > > > | The biggest problem exists for the RAP WG document > > > | for the framework PIB, cause it is in RFC 48-hour > > > | author call (for over a month already). > > > | > > > | The DIFFSERV PIB (also in RFC 38-hour author call > > > | for the same amount of time) of course cannot be > > > | published since it depends on the framework pib. > > > | > > > | The issue at hand is the question on how to specify > > > | that a flowID be ignored (wild-carded) for a filter. > > > | I think we've come to the conclusion that both the > > > | MIB and the PIB solutions need this. So we need > > > | a common solution. > > > | > > > | We've also found 3 other places where a flowID > > > | or a flowLabel (but the same thing is meant) is > > > | being used. That is in: > > > | > > > | - draft-ietf-ipsp-ipsec-conf-mib-05.txt > > > | which uses a 3-byte octet string and that seems wrong > > > | SYNTAX OCTET STRING (SIZE(3)) > > > | > > > | - draft-ietf-rmonmib-sspm-mib-06.txt > > > | which uses an Integer32: > > > | SYNTAX Integer32 (0..1048575) -- 20-bit range (0 > > to 0xfffff) > > > | > > > | - Integrated services MIB (RFC 2213) > > > | which uses INTEGER > > > | SYNTAX INTEGER (0..16777215) > > > | > > > | The Diffserv MIB (RFC3289) and the framework PIB were > > > | using an Unsigned 32, namely > > > | SYNTAX Unsigned32 (0..1048575) > > > | > > > | The framework PIB authors were suggesting a modification > > > | SYNTAX Unsigned32 (4294967295 | 0..1048575) > > > | So that the value 4294967295 would mean any (in other words > > > | one would ignore the flowID in when filtering). > > > | > > > | Fred (amin editor of the Diffserv MIB) wanted to add a > > > | boolean mib object to indicate if the flowID should be > > > | ignored when filtering. > > > | > > > | What I as OPS AD for the NM side see is that we have > > > | - too many different ways to represent a flowID or flowLabel. > > > | - there is currently no way to define a flowID or any > > > | - we need need a facility to specify flowIdOrAny. > > > | - we prefer to have one solution. > > > | - we have some docs that are still IDs and can easily > > > | be changed. > > > | - we have two docs that are difficult to change, namely > > > | the DIFSERV and the INTEGRATED SERVICES MIB. > > > | The difficulty is that if we change the encoding on the > > > | wire that we need to deprecate existing object and add > > > | a new one. If we keep the wire encoding the same, I think > > > | we can defend that it is a bug fix and the fact that some > > > | potential new values are now valid is acceptable; at least > > > | it would be less of a problem than having to deprecate > > > | an object and add a new one. > > > | - But even the two RFCs have different SYNTAX, so at least > > > | one of them needs to change if we want to specify > > > | flowID in a consistent way. > > > | > > > | So what do people want to do. > > > | > > > | My proposal is to do the following: > > > | > > > | - Someone creates a new ID that contains a small MIB module > > > | that contains two TCs: > > > | > > > | FlowId TEXTUAL-CONVENTION > > > | DISPLAY-HINT "d" > > > | STATUS current > > > | DESCRIPTION "The flow identifier or flow Label in an IPv6 > > > | header that may be used to > > discriminate traffic > > > | flows. > > > | " > > > | SYNTAX Integer32 (0..1048575) > > > | > > > | FlowIdOrAny TEXTUAL-CONVENTION > > > | DISPLAY-HINT "d" > > > | STATUS current > > > | DESCRIPTION "The flow identifier or flow lable > in an IPv6 > > > | header that may be used to > > discriminate traffic > > > | flows. The value of -1 is used to > indicate a > > > | wildcard, i.e. any value. > > > | " > > > | SYNTAX Integer32 (-1 | 0..1048575) > > > | > > > | We probably want to run this quickly by the IPv6 WG. > > > | > > > | What it would mean for the various documents is the following: > > > | > > > | - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a > > > | co-author/editor..., whenever a new revision is done: > > > | - import the new FlowId TC > > > | - replace > > > | intSrvFlowFlowId OBJECT-TYPE > > > | SYNTAX INTEGER (0..16777215) > > > | with > > > | intSrvFlowFlowId OBJECT-TYPE > > > | SYNTAX FlowId > > > | I think we can consider this a BUG fix and allow > this change > > > | that reduces the range of possible values. > > > | - by the way, I when I see intSrvFlowIfAddr, then probably > > > | we would want that to be done with the TCs from the > > > | INET-ADDRESS-MIB. I also wonder about the Port TC in that > > > | module > > > | > > > | - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever > > > | a new revision is done, I think we need to: > > > | - import the new FlowIdOrAny TC > > > | - deprecate object diffServMultiFieldClfrFlowId > > > | - define a new object diffServMultiFieldClfrFlowLabel ?? > > > | or maybe diffServMultiFieldClfrFlowIdOrAny > > > | with syntax FlowIdOrAny > > > | - deprecate current MODULE-COMPLIANCEs, define a new one > > > | to remove ... FlowId and add ...FlowLable > > > | > > > | - For the draft-ietf-rap-frameworkpib-09.txt (or better the > > > | RFC-to-be) the final fix would be to make this change: > > > | - import FlowIdOrAny TC > > > | - replace > > > | frwkIpFilterFlowId OBJECT-TYPE > > > | SYNTAX Unsigned32 (0..1048575) > > > | with > > > | frwkIpFilterFlowId OBJECT-TYPE > > > | SYNTAX FlowIdOrAny > > > | - we can consider this as a last minute bug fix. > > > | If we agree that the final change may take too long, then we > > > | can make a temp fix: > > > | - replace > > > | frwkIpFilterFlowId OBJECT-TYPE > > > | SYNTAX Unsigned32 (0..1048575) > > > | with > > > | frwkIpFilterFlowId OBJECT-TYPE > > > | SYNTAX Integer32 (-1 | 0..1048575) > > > | DESCRIPTION "The flow identifier or flow lable > > in an IPv6 > > > | header that may be used to > > > discriminate traffic > > > | flows. The value of -1 is used to > > indicate a > > > | wildcard, i.e. any value. > > > | " > > > | - whenever the RFC gets revised, then this can be replaced > > > | with the final fix, cause it does not change anything on > > > | the wire. > > > | > > > | - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > > > | Wes Hardaker, we can fix it as follows > > > | - import FlowId > > > | - replace > > > | ihfIPv6FlowLabel OBJECT-TYPE > > > | SYNTAX OCTET STRING (SIZE(3)) > > > | with > > > | ihfIPv6FlowLabel OBJECT-TYPE > > > | SYNTAX FlowId > > > | - this is still an ID, so the change is OK. > > > | Also, they use a BITS mask to indicate if the flowlabel > > > | must be ignored or not. So this works. It is a bit > different > > > | than it is done in diffserv mib and framework pib, > > but at least > > > | it uses the same spec for FlowId. (or flowLabel) > > > | > > > | - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is > > > main editor > > > | it would mean > > > | - import FlowId > > > | - replace > > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > > | SYNTAX Integer32 (0..1048575) -- 20-bit range > > > | (0 to 0xfffff) > > > | with > > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > > | SYNTAX FlowId > > > | - this is still an ID, so the change is OK > > > | > > > | > > > | Thanks, > > > | Bert > > > | _______________________________________________ > > > | diffserv mailing list > > > | diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv > > | Archive: > > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre > > nt/maillist.html > > > > From owner-rap@ops.ietf.org Mon Feb 3 06:36:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03135 for ; Mon, 3 Feb 2003 06:36:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18fex3-0006S1-00 for rap-data@psg.com; Mon, 03 Feb 2003 03:39:49 -0800 Received: from ierw.net.avaya.com ([198.152.13.101]) by psg.com with esmtp (Exim 3.36 #1) id 18fex0-0006Rp-00 for rap@ops.ietf.org; Mon, 03 Feb 2003 03:39:46 -0800 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00576 for ; Mon, 3 Feb 2003 06:37:12 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00553 for ; Mon, 3 Feb 2003 06:37:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Mon, 3 Feb 2003 13:39:42 +0200 Message-ID: Thread-Topic: [Diffserv] RE: FW: FlowId and FlowIdOrAny Thread-Index: AcLLaWkPtlUhVsKlRw+Fd7xOPeDnawADoLtA From: "Romascanu, Dan (Dan)" To: "Wijnen, Bert (Bert)" , "Sahita, Ravi" , "Rap-wg (E-mail)" X-Spam-Status: No, hits=-0.1 required=5.0 tests=OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA03135 The last mail from Ravi seems to require resolution for the object frwkIpFilterFlowId, which has a -1 value. The range should be OK, at least according to my text book on IPv6. The field itself has 20 bit, and the value zero must be set by host or routers that do not support this functionality. Dan > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, February 03, 2003 11:48 AM > To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Sahita, Ravi; > Rap-wg (E-mail) > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > So Dan, you would use the one intended as FlowLabel (which does > not include the -1 value). The -1 value is for cases of > FlowLableOrAny. I was worried more about the question if the > range 0..1048575 is the correct range for FlowLabels. > > Thanks, > Bert > > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: zondag 2 februari 2003 13:22 > > To: Wijnen, Bert (Bert); Sahita, Ravi; Rap-wg (E-mail) > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > The -1 value is not needed in SSPM MIB. The object > > sspmSourceProfileFlowLabel has a MAX-ACCESS read-create, and > > one MUST specify a meaningful flow id value to be carried by > > the packet. > > > > Dan > > > > > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Friday, January 31, 2003 12:14 AM > > > To: Sahita, Ravi; 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > > > > Right, that seems an approach by which your RFC does not have > > > to get held up for too long (well, at least not too much longer > > > than has already happened). > > > Not sure if you saw this, but I have also posted the mail > > > on FlowLabel and FlowLabelOrAny on the mibs@ops.ietf.mailing > > > list, so that we get dicsussion from other MIB folk as well. > > > ANd I posted it to the authors of the other documents that > > > were mentioned. > > > > > > All seems to be fine except for one question. > > > And that is: if the range is indeed the correct one. > > > Let me try and drive to consensus on that on the mibs mailing > > > list. Pls do join in in the discussion there when you see fit. > > > > > > Thanks, > > > Bert > > > > > > > -----Original Message----- > > > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > > > > Sent: donderdag 30 januari 2003 22:34 > > > > To: 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > > > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > > > > > > > Bert, > > > > > > > > Of the choices you provided, I am tending towards this > resolution > > > > for the frwkIpFilterFlowId object. When the TCs are > > eventually put > > > > in a different ID and RFC'ed, we can update the type for > > > this object. > > > > > > > > Ravi > > > > > > > > frwkIpFilterFlowId OBJECT-TYPE > > > > SYNTAX Integer32 (-1 | 0..1048575) > > > > DESCRIPTION > > > > "The flow identifier or flow label in an IPv6 header > > > > that may be used to discriminate traffic flows. > > > > The value of -1 for this attribute MUST imply that > > > > any flow label value in the IPv6 header will match, > > > > resulting in the flow label field of the IPv6 header > > > > being ignored for matching this filter entry." > > > > > > > > > > > > > > > > | -----Original Message----- > > > > | From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > | Sent: Monday, January 27, 2003 1:49 PM > > > > | To: Rap-wg (E-mail); Diffserv@ietf.org > > > > | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > | > > > > | > > > > | I am not hearing much progress. > > > > | > > > > | Appology for a long email posting. But I think it > > > > | addresses all the issues and occurences of flowId > > > > | or flowLabel (at least till someone tells me they > > > > | found yet another one ;-)) > > > > | > > > > | The biggest problem exists for the RAP WG document > > > > | for the framework PIB, cause it is in RFC 48-hour > > > > | author call (for over a month already). > > > > | > > > > | The DIFFSERV PIB (also in RFC 38-hour author call > > > > | for the same amount of time) of course cannot be > > > > | published since it depends on the framework pib. > > > > | > > > > | The issue at hand is the question on how to specify > > > > | that a flowID be ignored (wild-carded) for a filter. > > > > | I think we've come to the conclusion that both the > > > > | MIB and the PIB solutions need this. So we need > > > > | a common solution. > > > > | > > > > | We've also found 3 other places where a flowID > > > > | or a flowLabel (but the same thing is meant) is > > > > | being used. That is in: > > > > | > > > > | - draft-ietf-ipsp-ipsec-conf-mib-05.txt > > > > | which uses a 3-byte octet string and that seems wrong > > > > | SYNTAX OCTET STRING (SIZE(3)) > > > > | > > > > | - draft-ietf-rmonmib-sspm-mib-06.txt > > > > | which uses an Integer32: > > > > | SYNTAX Integer32 (0..1048575) -- 20-bit range (0 > > > to 0xfffff) > > > > | > > > > | - Integrated services MIB (RFC 2213) > > > > | which uses INTEGER > > > > | SYNTAX INTEGER (0..16777215) > > > > | > > > > | The Diffserv MIB (RFC3289) and the framework PIB were > > > > | using an Unsigned 32, namely > > > > | SYNTAX Unsigned32 (0..1048575) > > > > | > > > > | The framework PIB authors were suggesting a modification > > > > | SYNTAX Unsigned32 (4294967295 | 0..1048575) > > > > | So that the value 4294967295 would mean any (in other words > > > > | one would ignore the flowID in when filtering). > > > > | > > > > | Fred (amin editor of the Diffserv MIB) wanted to add a > > > > | boolean mib object to indicate if the flowID should be > > > > | ignored when filtering. > > > > | > > > > | What I as OPS AD for the NM side see is that we have > > > > | - too many different ways to represent a flowID or flowLabel. > > > > | - there is currently no way to define a flowID or any > > > > | - we need need a facility to specify flowIdOrAny. > > > > | - we prefer to have one solution. > > > > | - we have some docs that are still IDs and can easily > > > > | be changed. > > > > | - we have two docs that are difficult to change, namely > > > > | the DIFSERV and the INTEGRATED SERVICES MIB. > > > > | The difficulty is that if we change the encoding on the > > > > | wire that we need to deprecate existing object and add > > > > | a new one. If we keep the wire encoding the same, I think > > > > | we can defend that it is a bug fix and the fact that some > > > > | potential new values are now valid is acceptable; at least > > > > | it would be less of a problem than having to deprecate > > > > | an object and add a new one. > > > > | - But even the two RFCs have different SYNTAX, so at least > > > > | one of them needs to change if we want to specify > > > > | flowID in a consistent way. > > > > | > > > > | So what do people want to do. > > > > | > > > > | My proposal is to do the following: > > > > | > > > > | - Someone creates a new ID that contains a small MIB module > > > > | that contains two TCs: > > > > | > > > > | FlowId TEXTUAL-CONVENTION > > > > | DISPLAY-HINT "d" > > > > | STATUS current > > > > | DESCRIPTION "The flow identifier or flow Label > in an IPv6 > > > > | header that may be used to > > > discriminate traffic > > > > | flows. > > > > | " > > > > | SYNTAX Integer32 (0..1048575) > > > > | > > > > | FlowIdOrAny TEXTUAL-CONVENTION > > > > | DISPLAY-HINT "d" > > > > | STATUS current > > > > | DESCRIPTION "The flow identifier or flow lable > > in an IPv6 > > > > | header that may be used to > > > discriminate traffic > > > > | flows. The value of -1 is used to > > indicate a > > > > | wildcard, i.e. any value. > > > > | " > > > > | SYNTAX Integer32 (-1 | 0..1048575) > > > > | > > > > | We probably want to run this quickly by the IPv6 WG. > > > > | > > > > | What it would mean for the various documents is the following: > > > > | > > > > | - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a > > > > | co-author/editor..., whenever a new revision is done: > > > > | - import the new FlowId TC > > > > | - replace > > > > | intSrvFlowFlowId OBJECT-TYPE > > > > | SYNTAX INTEGER (0..16777215) > > > > | with > > > > | intSrvFlowFlowId OBJECT-TYPE > > > > | SYNTAX FlowId > > > > | I think we can consider this a BUG fix and allow > > this change > > > > | that reduces the range of possible values. > > > > | - by the way, I when I see intSrvFlowIfAddr, then probably > > > > | we would want that to be done with the TCs from the > > > > | INET-ADDRESS-MIB. I also wonder about the Port TC in that > > > > | module > > > > | > > > > | - For the DIFFSERV-MIB (RFC3289), Fred is main > editor, whenever > > > > | a new revision is done, I think we need to: > > > > | - import the new FlowIdOrAny TC > > > > | - deprecate object diffServMultiFieldClfrFlowId > > > > | - define a new object diffServMultiFieldClfrFlowLabel ?? > > > > | or maybe diffServMultiFieldClfrFlowIdOrAny > > > > | with syntax FlowIdOrAny > > > > | - deprecate current MODULE-COMPLIANCEs, define a new one > > > > | to remove ... FlowId and add ...FlowLable > > > > | > > > > | - For the draft-ietf-rap-frameworkpib-09.txt (or better the > > > > | RFC-to-be) the final fix would be to make this change: > > > > | - import FlowIdOrAny TC > > > > | - replace > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > | SYNTAX Unsigned32 (0..1048575) > > > > | with > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > | SYNTAX FlowIdOrAny > > > > | - we can consider this as a last minute bug fix. > > > > | If we agree that the final change may take too long, then we > > > > | can make a temp fix: > > > > | - replace > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > | SYNTAX Unsigned32 (0..1048575) > > > > | with > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > | SYNTAX Integer32 (-1 | 0..1048575) > > > > | DESCRIPTION "The flow identifier or flow lable > > > in an IPv6 > > > > | header that may be used to > > > > discriminate traffic > > > > | flows. The value of -1 is used to > > > indicate a > > > > | wildcard, i.e. any value. > > > > | " > > > > | - whenever the RFC gets revised, then this can be replaced > > > > | with the final fix, cause it does not change anything on > > > > | the wire. > > > > | > > > > | - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > > > > | Wes Hardaker, we can fix it as follows > > > > | - import FlowId > > > > | - replace > > > > | ihfIPv6FlowLabel OBJECT-TYPE > > > > | SYNTAX OCTET STRING (SIZE(3)) > > > > | with > > > > | ihfIPv6FlowLabel OBJECT-TYPE > > > > | SYNTAX FlowId > > > > | - this is still an ID, so the change is OK. > > > > | Also, they use a BITS mask to indicate if the flowlabel > > > > | must be ignored or not. So this works. It is a bit > > different > > > > | than it is done in diffserv mib and framework pib, > > > but at least > > > > | it uses the same spec for FlowId. (or flowLabel) > > > > | > > > > | - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is > > > > main editor > > > > | it would mean > > > > | - import FlowId > > > > | - replace > > > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > > > | SYNTAX Integer32 (0..1048575) -- 20-bit range > > > > | (0 to 0xfffff) > > > > | with > > > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > > > | SYNTAX FlowId > > > > | - this is still an ID, so the change is OK > > > > | > > > > | > > > > | Thanks, > > > > | Bert > > > > | _______________________________________________ > > > > | diffserv mailing list > > > > | diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > > > | Archive: > > > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre > > > nt/maillist.html > > > > > > > > From owner-rap@ops.ietf.org Mon Feb 3 06:51:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03907 for ; Mon, 3 Feb 2003 06:51:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ffBA-0006rS-00 for rap-data@psg.com; Mon, 03 Feb 2003 03:54:24 -0800 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 18ffB6-0006rF-00 for rap@ops.ietf.org; Mon, 03 Feb 2003 03:54:20 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h13BsEb07012 for ; Mon, 3 Feb 2003 06:54:14 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 12:54:13 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C83E2E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , "Sahita, Ravi" , "Rap-wg (E-mail)" Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Mon, 3 Feb 2003 12:54:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.2 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Inline > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: maandag 3 februari 2003 12:40 > To: Wijnen, Bert (Bert); Sahita, Ravi; Rap-wg (E-mail) > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > The last mail from Ravi seems to require resolution for the > object frwkIpFilterFlowId, which has a -1 value. > Yep, but that is in a place where they want to express FlowLabelOrAny, and so the -1 represents the "any". > The range should be OK, at least according to my text book on > IPv6. The field itself has 20 bit, and the value zero must be > set by host or routers that do not support this functionality. > That is what I thought also, but someone questioned it, and in some existing MIB modules, they seem to have used a larger range already. So I guess we want to get a definitive answer from some IPv6 experts. I will follow up on that. Bert > Dan > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Monday, February 03, 2003 11:48 AM > > To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Sahita, Ravi; > > Rap-wg (E-mail) > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > So Dan, you would use the one intended as FlowLabel (which does > > not include the -1 value). The -1 value is for cases of > > FlowLableOrAny. I was worried more about the question if the > > range 0..1048575 is the correct range for FlowLabels. > > > > Thanks, > > Bert > > > > > -----Original Message----- > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > Sent: zondag 2 februari 2003 13:22 > > > To: Wijnen, Bert (Bert); Sahita, Ravi; Rap-wg (E-mail) > > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > > > > The -1 value is not needed in SSPM MIB. The object > > > sspmSourceProfileFlowLabel has a MAX-ACCESS read-create, and > > > one MUST specify a meaningful flow id value to be carried by > > > the packet. > > > > > > Dan > > > > > > > > > > -----Original Message----- > > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > Sent: Friday, January 31, 2003 12:14 AM > > > > To: Sahita, Ravi; 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > > > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > > > > > > > Right, that seems an approach by which your RFC does not have > > > > to get held up for too long (well, at least not too much longer > > > > than has already happened). > > > > Not sure if you saw this, but I have also posted the mail > > > > on FlowLabel and FlowLabelOrAny on the mibs@ops.ietf.mailing > > > > list, so that we get dicsussion from other MIB folk as well. > > > > ANd I posted it to the authors of the other documents that > > > > were mentioned. > > > > > > > > All seems to be fine except for one question. > > > > And that is: if the range is indeed the correct one. > > > > Let me try and drive to consensus on that on the mibs mailing > > > > list. Pls do join in in the discussion there when you see fit. > > > > > > > > Thanks, > > > > Bert > > > > > > > > > -----Original Message----- > > > > > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > > > > > Sent: donderdag 30 januari 2003 22:34 > > > > > To: 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > > > > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > > > > > > > > > > > Bert, > > > > > > > > > > Of the choices you provided, I am tending towards this > > resolution > > > > > for the frwkIpFilterFlowId object. When the TCs are > > > eventually put > > > > > in a different ID and RFC'ed, we can update the type for > > > > this object. > > > > > > > > > > Ravi > > > > > > > > > > frwkIpFilterFlowId OBJECT-TYPE > > > > > SYNTAX Integer32 (-1 | 0..1048575) > > > > > DESCRIPTION > > > > > "The flow identifier or flow label in an IPv6 header > > > > > that may be used to discriminate traffic flows. > > > > > The value of -1 for this attribute MUST imply that > > > > > any flow label value in the IPv6 header will match, > > > > > resulting in the flow label field of the IPv6 header > > > > > being ignored for matching this filter entry." > > > > > > > > > > > > > > > > > > > > | -----Original Message----- > > > > > | From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > > > | Sent: Monday, January 27, 2003 1:49 PM > > > > > | To: Rap-wg (E-mail); Diffserv@ietf.org > > > > > | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > > > | > > > > > | > > > > > | I am not hearing much progress. > > > > > | > > > > > | Appology for a long email posting. But I think it > > > > > | addresses all the issues and occurences of flowId > > > > > | or flowLabel (at least till someone tells me they > > > > > | found yet another one ;-)) > > > > > | > > > > > | The biggest problem exists for the RAP WG document > > > > > | for the framework PIB, cause it is in RFC 48-hour > > > > > | author call (for over a month already). > > > > > | > > > > > | The DIFFSERV PIB (also in RFC 38-hour author call > > > > > | for the same amount of time) of course cannot be > > > > > | published since it depends on the framework pib. > > > > > | > > > > > | The issue at hand is the question on how to specify > > > > > | that a flowID be ignored (wild-carded) for a filter. > > > > > | I think we've come to the conclusion that both the > > > > > | MIB and the PIB solutions need this. So we need > > > > > | a common solution. > > > > > | > > > > > | We've also found 3 other places where a flowID > > > > > | or a flowLabel (but the same thing is meant) is > > > > > | being used. That is in: > > > > > | > > > > > | - draft-ietf-ipsp-ipsec-conf-mib-05.txt > > > > > | which uses a 3-byte octet string and that seems wrong > > > > > | SYNTAX OCTET STRING (SIZE(3)) > > > > > | > > > > > | - draft-ietf-rmonmib-sspm-mib-06.txt > > > > > | which uses an Integer32: > > > > > | SYNTAX Integer32 (0..1048575) -- 20-bit range (0 > > > > to 0xfffff) > > > > > | > > > > > | - Integrated services MIB (RFC 2213) > > > > > | which uses INTEGER > > > > > | SYNTAX INTEGER (0..16777215) > > > > > | > > > > > | The Diffserv MIB (RFC3289) and the framework PIB were > > > > > | using an Unsigned 32, namely > > > > > | SYNTAX Unsigned32 (0..1048575) > > > > > | > > > > > | The framework PIB authors were suggesting a modification > > > > > | SYNTAX Unsigned32 (4294967295 | 0..1048575) > > > > > | So that the value 4294967295 would mean any (in other words > > > > > | one would ignore the flowID in when filtering). > > > > > | > > > > > | Fred (amin editor of the Diffserv MIB) wanted to add a > > > > > | boolean mib object to indicate if the flowID should be > > > > > | ignored when filtering. > > > > > | > > > > > | What I as OPS AD for the NM side see is that we have > > > > > | - too many different ways to represent a flowID or > flowLabel. > > > > > | - there is currently no way to define a flowID or any > > > > > | - we need need a facility to specify flowIdOrAny. > > > > > | - we prefer to have one solution. > > > > > | - we have some docs that are still IDs and can easily > > > > > | be changed. > > > > > | - we have two docs that are difficult to change, namely > > > > > | the DIFSERV and the INTEGRATED SERVICES MIB. > > > > > | The difficulty is that if we change the encoding on the > > > > > | wire that we need to deprecate existing object and add > > > > > | a new one. If we keep the wire encoding the same, I think > > > > > | we can defend that it is a bug fix and the fact that some > > > > > | potential new values are now valid is acceptable; at least > > > > > | it would be less of a problem than having to deprecate > > > > > | an object and add a new one. > > > > > | - But even the two RFCs have different SYNTAX, so at least > > > > > | one of them needs to change if we want to specify > > > > > | flowID in a consistent way. > > > > > | > > > > > | So what do people want to do. > > > > > | > > > > > | My proposal is to do the following: > > > > > | > > > > > | - Someone creates a new ID that contains a small MIB module > > > > > | that contains two TCs: > > > > > | > > > > > | FlowId TEXTUAL-CONVENTION > > > > > | DISPLAY-HINT "d" > > > > > | STATUS current > > > > > | DESCRIPTION "The flow identifier or flow Label > > in an IPv6 > > > > > | header that may be used to > > > > discriminate traffic > > > > > | flows. > > > > > | " > > > > > | SYNTAX Integer32 (0..1048575) > > > > > | > > > > > | FlowIdOrAny TEXTUAL-CONVENTION > > > > > | DISPLAY-HINT "d" > > > > > | STATUS current > > > > > | DESCRIPTION "The flow identifier or flow lable > > > in an IPv6 > > > > > | header that may be used to > > > > discriminate traffic > > > > > | flows. The value of -1 is used to > > > indicate a > > > > > | wildcard, i.e. any value. > > > > > | " > > > > > | SYNTAX Integer32 (-1 | 0..1048575) > > > > > | > > > > > | We probably want to run this quickly by the IPv6 WG. > > > > > | > > > > > | What it would mean for the various documents is the > following: > > > > > | > > > > > | - For the INTEGRATED-SERVICES-MIB (RFC2213), I see > Fred as a > > > > > | co-author/editor..., whenever a new revision is done: > > > > > | - import the new FlowId TC > > > > > | - replace > > > > > | intSrvFlowFlowId OBJECT-TYPE > > > > > | SYNTAX INTEGER (0..16777215) > > > > > | with > > > > > | intSrvFlowFlowId OBJECT-TYPE > > > > > | SYNTAX FlowId > > > > > | I think we can consider this a BUG fix and allow > > > this change > > > > > | that reduces the range of possible values. > > > > > | - by the way, I when I see intSrvFlowIfAddr, > then probably > > > > > | we would want that to be done with the TCs from the > > > > > | INET-ADDRESS-MIB. I also wonder about the Port > TC in that > > > > > | module > > > > > | > > > > > | - For the DIFFSERV-MIB (RFC3289), Fred is main > > editor, whenever > > > > > | a new revision is done, I think we need to: > > > > > | - import the new FlowIdOrAny TC > > > > > | - deprecate object diffServMultiFieldClfrFlowId > > > > > | - define a new object diffServMultiFieldClfrFlowLabel ?? > > > > > | or maybe diffServMultiFieldClfrFlowIdOrAny > > > > > | with syntax FlowIdOrAny > > > > > | - deprecate current MODULE-COMPLIANCEs, define a new one > > > > > | to remove ... FlowId and add ...FlowLable > > > > > | > > > > > | - For the draft-ietf-rap-frameworkpib-09.txt (or better the > > > > > | RFC-to-be) the final fix would be to make this change: > > > > > | - import FlowIdOrAny TC > > > > > | - replace > > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > > | SYNTAX Unsigned32 (0..1048575) > > > > > | with > > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > > | SYNTAX FlowIdOrAny > > > > > | - we can consider this as a last minute bug fix. > > > > > | If we agree that the final change may take too > long, then we > > > > > | can make a temp fix: > > > > > | - replace > > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > > | SYNTAX Unsigned32 (0..1048575) > > > > > | with > > > > > | frwkIpFilterFlowId OBJECT-TYPE > > > > > | SYNTAX Integer32 (-1 | 0..1048575) > > > > > | DESCRIPTION "The flow identifier or flow lable > > > > in an IPv6 > > > > > | header that may be used to > > > > > discriminate traffic > > > > > | flows. The value of -1 is used to > > > > indicate a > > > > > | wildcard, i.e. any value. > > > > > | " > > > > > | - whenever the RFC gets revised, then this can > be replaced > > > > > | with the final fix, cause it does not change > anything on > > > > > | the wire. > > > > > | > > > > > | - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > > > > > | Wes Hardaker, we can fix it as follows > > > > > | - import FlowId > > > > > | - replace > > > > > | ihfIPv6FlowLabel OBJECT-TYPE > > > > > | SYNTAX OCTET STRING (SIZE(3)) > > > > > | with > > > > > | ihfIPv6FlowLabel OBJECT-TYPE > > > > > | SYNTAX FlowId > > > > > | - this is still an ID, so the change is OK. > > > > > | Also, they use a BITS mask to indicate if the flowlabel > > > > > | must be ignored or not. So this works. It is a bit > > > different > > > > > | than it is done in diffserv mib and framework pib, > > > > but at least > > > > > | it uses the same spec for FlowId. (or flowLabel) > > > > > | > > > > > | - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is > > > > > main editor > > > > > | it would mean > > > > > | - import FlowId > > > > > | - replace > > > > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > > > > | SYNTAX Integer32 (0..1048575) -- 20-bit range > > > > > | (0 to 0xfffff) > > > > > | with > > > > > | sspmSourceProfileFlowLabel OBJECT-TYPE > > > > > | SYNTAX FlowId > > > > > | - this is still an ID, so the change is OK > > > > > | > > > > > | > > > > > | Thanks, > > > > > | Bert > > > > > | _______________________________________________ > > > > > | diffserv mailing list > > > > > | diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > > > | Archive: > > > > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre > > > > nt/maillist.html > > > > > > > > > > > > > From owner-rap@ops.ietf.org Mon Feb 3 13:27:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16231 for ; Mon, 3 Feb 2003 13:27:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18flMN-000Huj-00 for rap-data@psg.com; Mon, 03 Feb 2003 10:30:23 -0800 Received: from [63.125.5.183] (helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18flML-000Hu0-00 for rap@ops.ietf.org; Mon, 03 Feb 2003 10:30:21 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18flML-0000AA-00 for rap@ops.ietf.org; Mon, 03 Feb 2003 13:30:21 -0500 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155D6C368@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain From: "Wijnen, Bert (Bert)" To: rap@ops.ietf.org, diffserv@ietf.org Subject: FlowId and FlowIdOrAny Date: Mon, 3 Feb 2003 17:53:46 +0100 X-Spam-Status: No, hits=-0.2 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk I have posted an initial I-D for the two TCs to the mibs@ops.ietf.org mailing list. Mailing list info: for generic MIB (Management Information Base) discussions: General Discussion: mibs@ops.ietf.org To subscribe: majordomo@ops.ietf.org in body: subscribe mibs Archive: ftp://ops.ietf.org/pub/lists/ Thanks, Bert > -----Original Message----- > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > Sent: dinsdag 21 januari 2003 17:34 > To: Juergen Schoenwaelder > Cc: bwijnen@lucent.com; rap@ops.ietf.org; diffserv@ietf.org > Subject: Re: [Diffserv] FlowId and FlowIdOrAny > > > Um... since you're bringing the Diffserv folks into the > middle of the conversation, would > it be possible to clue us in as to what we're talking about? > Thanks. > > Juergen Schoenwaelder wrote: > > > I changed the subject line and fixed the proposed TC. So > here is where > > I think we are. I have also reduced the CC list and I have added the > > diffserv mailing list since diffserv folks should be in the loop I > > think. > > > > FlowId TECTUAL-CONVENTION > > DISPLAY-HINT "d" > > STATUS current > > DESCRIPTION > > "The flow identifier in an IPv6 header that may be used to > > discriminate traffic flows." > > REFERENCE > > "RFC 2460" > > SYNTAX Integer32 (0..1048575) > > > > FlowIdOrAny TECTUAL-CONVENTION > > DISPLAY-HINT "d" > > STATUS current > > DESCRIPTION > > "The flow identifier in an IPv6 header that may be used to > > discriminate traffic flows. The value of -1 is used to > > indicate a wildcard, i.e. any value." > > REFERENCE > > "RFC 2460" > > SYNTAX Integer32 (-1 | 0..1048575) > > > > Open issues: > > > > - Is the flow identifier the same as the flow label? I guess so. If > > this is true, then we should probably use the TC names FlowLabel > > and FlowLableOrAny and also change the wordings in the description > > clause. > > > > - The name of the MIB modules which will contain these definitions. > > > > - Since Fred kind of said that the diffServMultiFieldClfrFlowId > > object should have had a wildcard, can we agree that this is > > actually a bug in RFC 3289 which will be fixed by using > FlowIdOrAny > > in the next revision of the DIFFSERV-MIB? > > > > /js > > > > -- > > Juergen Schoenwaelder > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www.ietf.org/mail-archive/working-groups/diffserv/curre nt/maillist.html From owner-rap@ops.ietf.org Mon Feb 10 06:47:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05162 for ; Mon, 10 Feb 2003 06:47:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18iCQx-000Mb3-00 for rap-data@psg.com; Mon, 10 Feb 2003 03:49:11 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18iCQt-000Mar-00 for rap@ops.ietf.org; Mon, 10 Feb 2003 03:49:07 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05079; Mon, 10 Feb 2003 06:45:23 -0500 (EST) Message-Id: <200302101145.GAA05079@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-tls-05.txt Date: Mon, 10 Feb 2003 06:45:22 -0500 X-Spam-Status: No, hits=4.9 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_02_03,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : COPS Over TLS Author(s) : J. Walker, A. Kulkarni Filename : draft-ietf-rap-cops-tls-05.txt Pages : 11 Date : 2003-2-7 This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-cops-tls-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-cops-tls-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-7094522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-7094522.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Feb 21 17:17:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16955 for ; Fri, 21 Feb 2003 17:17:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18mLW3-0001mn-00 for rap-data@psg.com; Fri, 21 Feb 2003 14:19:35 -0800 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.36 #1) id 18mLVT-0001m4-00 for rap@ops.ietf.org; Fri, 21 Feb 2003 14:18:59 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h1LMFqd08383 for ; Fri, 21 Feb 2003 22:15:52 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h1LMKbL09767 for ; Fri, 21 Feb 2003 22:20:37 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003022114191417671 ; Fri, 21 Feb 2003 14:19:14 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id <118BTR0T>; Fri, 21 Feb 2003 14:18:57 -0800 Message-ID: From: "Hahn, Scott" To: rap@ops.ietf.org Cc: "Wijnen, Bert (Bert)" , Kwok Ho Chan , "Sahita, Ravi" , mlstevens@rcn.com Subject: FW: FlowId change in framework PIB Date: Fri, 21 Feb 2003 14:18:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.3 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk All, The authors of the framework PIB would like to make the following change prior to RFC publication and we have been asked by our AD to do a "mini last call" on this particular change. If you have any issues with the description of the IPv6 flowid (frwkIpFilterFlowId) please send your comments to the list by Monday 2/24/03 (5:00pm EST), otherwise we will proceed with this change. Thanks and sorry for the short notice. Scott Hahn RAP WG co-chair -----Original Message----- From: Sahita, Ravi Sent: Friday, February 21, 2003 1:57 PM To: Hahn, Scott Cc: Sahita, Ravi Subject: FlowId change To support a wildcard value for the frwkIpFilterFlowId object we are proposing the following change: OLD: frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) STATUS current DESCRIPTION "The flow identifier in an IPv6 header." NEW: frwkIpFilterFlowId OBJECT-TYPE SYNTAX Integer32 (-1 | 0..1048575) DESCRIPTION "The flow label or flow identifier in an IPv6 header that may be used to discriminate traffic flows. The value of -1 for this attribute MUST imply that any flow label value in the IPv6 header will match, resulting in the flow label field of the IPv6 header being ignored for matching this filter entry." From owner-rap@ops.ietf.org Fri Feb 28 07:26:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22844 for ; Fri, 28 Feb 2003 07:26:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ojd8-0005DI-00 for rap-data@psg.com; Fri, 28 Feb 2003 04:28:46 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18ojd5-0005D3-00 for rap@ops.ietf.org; Fri, 28 Feb 2003 04:28:43 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22508; Fri, 28 Feb 2003 07:24:45 -0500 (EST) Message-Id: <200302281224.HAA22508@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-li-rap-mplspib-00.txt Date: Fri, 28 Feb 2003 07:24:44 -0500 X-Spam-Status: No, hits=4.6 required=5.0 tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02,TO_MALFORMED version=2.43 X-Spam-Level: **** Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MPLS Traffic Engineering Policy Information Base Author(s) : M. Li Filename : draft-li-rap-mplspib-00.txt Pages : 25 Date : 2003-2-27 This document specifies a set of policy rule classes (PRC) for configuring MPLS traffic engineering policy at network elements. Instances of these classes reside in a virtual information store called the MPLS-TE Policy Information Base (PIB). The COPS protocol [3] with extensions for provisioning [4] is used to transmit this policy information to network elements. The PRCs defined in this document are intended for use by the COPS-PR MPLS client type. These PRCs are in addition to any other PIBs that may be defined for the MPLS client type, as well as the PRCs defined in the Framework PIB [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-li-rap-mplspib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-li-rap-mplspib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-li-rap-mplspib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27132727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-li-rap-mplspib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-li-rap-mplspib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27132727.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Feb 28 12:00:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04797 for ; Fri, 28 Feb 2003 12:00:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18onvj-000HAZ-00 for rap-data@psg.com; Fri, 28 Feb 2003 09:04:15 -0800 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 18onvh-000HAK-00 for rap@ops.ietf.org; Fri, 28 Feb 2003 09:04:13 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1SH4BG27487 for ; Fri, 28 Feb 2003 12:04:11 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 18:04:10 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501063253@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Hahn, Scott" , Kwok Ho Chan , "Sahita, Ravi" , mfine@cisco.com, ah_smith@acm.org, John Seligson , mlstevens@rcn.com, kzm@cisco.com, franr@pfn.com Cc: "Rap-wg (E-mail)" , Randy Bush Subject: RE: authors 48 hours: RFC 3318 NOW AVAILABLE Date: Fri, 28 Feb 2003 18:03:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.5 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk W.r.t. The VLAN ID. I had proposed (to the bridgmib WG and mibs mailing list) a set of TCs that would be inline with your use, as follows: VlanId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A 12-bit VLAN ID used in the VLAN Tag header." SYNTAX Integer32 (1..4094) REFERENCE "Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D10, chapter 3.13 " VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) The latter one, would have been inline with your use in frwk802FilterVlanId OBJECT-TYPE SYNTAX Integer32 (-1 | 1..4094) STATUS current DESCRIPTION "The VLAN ID (VID) that uniquely identifies a VLAN within the device. This VLAN may be known or unknown (i.e., traffic associated with this VID has not yet been seen by the device) at the time this entry is instantiated. Setting the frwk802FilterVlanId object to -1 indicates that VLAN data should not be considered during traffic classification." ::= { frwk802FilterEntry 5 } But afte someone objected to a negative value for 'any, and based on Andrew's input I believe, people are now discussing VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of 4095 is not a vlaid VLAN ID and is used to indicate a wildcard, i.e. any value. " SYNTAX INTEGER (1..4095) That would be conflicting with your definition, and I might later ask you to deprecate your object and define a new one that aligns with the generic VLAN ID as defined by the bridgemib WG. Unfortunately, they are not sure yet, Bridgemib WG chair is taking it to IEEE and they will discuss it in week of March 9th, So it will take a while before we know for sure. So I am inclined to let you go with what you have, or to redefine it as SYNTAX INTEGER (1..4095). In the latter case, pls again do a quick pseudo WG Last Call for the change. Please let me know how you want to proceeed. Bert From owner-rap@ops.ietf.org Fri Feb 28 19:56:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18943 for ; Fri, 28 Feb 2003 19:56:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ovKS-000Buu-00 for rap-data@psg.com; Fri, 28 Feb 2003 16:58:16 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18ovKO-000Btm-02 for rap@ops.ietf.org; Fri, 28 Feb 2003 16:58:12 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18ouIE-0000cT-00 for rap@ops.ietf.org; Fri, 28 Feb 2003 15:51:54 -0800 Message-ID: <3E5FCDF3.20703@bell-labs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Feb 2003 16:00:35 -0500 From: Uri Blumenthal To: rap@ops.ietf.org Subject: [Fwd: RE: COPS-over-TLS v05 draft review] X-Spam-Status: No, hits=0.3 required=5.0 tests=FWD_MSG,RESENT_TO,SPAM_PHRASE_03_05 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Folks, This is from your friendly Security Advisor. (:-) And since I'm not the member of this mailing list, please kindly copy me on the relevant e-mails that might occur in response to this posting. (:-) Regards, Uri. -------- Original Message -------- From: "Hahn, Scott" ...I think this should be posted to the list for discussion. -Scott > From: Uri Blumenthal [mailto:uri@bell-labs.com] > > Here are the issues I see with the draft > "draft-ietf-rap-cops-tls-05.txt". > > First, overall I want to see how it ensures that when both client and > server can do security, it will be enabled. For example, a > man-in-the-middle can modify the traffic to convince one party that > the other one doesn't support security ("bid-down") and thus force > them to establish an insecure connection even though they both are > capable of secure communications. I would like to see a capability > to enforce secure mode. > > Also, I would like to see scenarios based not [only] on whether > client/server SUPPORTS security - but also on whether its POLICY > REQUIRES secure connection to a given peer. If it was meant so, > it isn't clear from the document. > > > Details by sections: > > 4.2. So what should the client do after receiving the error? > > 4.3. So the server MAY send a ClientClose... Anything else > it "may" do? Nothing it "should" do in this case...? > What should an implementor do here? > > 4.4. Same as above. > > 4.7. Why is this subsection here? I'd say - remove it. > > 8. It is good to require PKI - what happens if CA isn't > available, isn't accessible, whatever? > Reverts to insecure? > > > > > Thanks! > > Regards, > Uri From owner-rap@ops.ietf.org Fri Feb 28 20:01:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19052 for ; Fri, 28 Feb 2003 20:01:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ovPD-000C34-00 for rap-data@psg.com; Fri, 28 Feb 2003 17:03:11 -0800 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by psg.com with esmtp (Exim 3.36 #1) id 18ovP9-000C2i-00 for rap@ops.ietf.org; Fri, 28 Feb 2003 17:03:07 -0800 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.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h210xs804856 for ; Sat, 1 Mar 2003 00:59:54 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h210XYT22757 for ; Sat, 1 Mar 2003 00:33:34 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003022816365601158 ; Fri, 28 Feb 2003 16:36:56 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Feb 2003 16:38:57 -0800 Message-ID: From: "Hahn, Scott" To: "Wijnen, Bert (Bert)" , Kwok Ho Chan , "Sahita, Ravi" , mfine@cisco.com, ah_smith@acm.org, John Seligson , mlstevens@rcn.com, kzm@cisco.com, franr@pfn.com Cc: "Rap-wg (E-mail)" , Randy Bush Subject: RE: authors 48 hours: RFC 3318 NOW AVAILABLE Date: Fri, 28 Feb 2003 16:38:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.5 required=5.0 tests=EXCHANGE_SERVER,SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-rap@ops.ietf.org Precedence: bulk Bert, I would agree with you and go with what we have today. -Scott -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, February 28, 2003 9:04 AM To: Hahn, Scott; Kwok Ho Chan; Sahita, Ravi; mfine@cisco.com; ah_smith@acm.org; John Seligson; mlstevens@rcn.com; kzm@cisco.com; franr@pfn.com Cc: Rap-wg (E-mail); Randy Bush Subject: RE: authors 48 hours: RFC 3318 NOW AVAILABLE W.r.t. The VLAN ID. I had proposed (to the bridgmib WG and mibs mailing list) a set of TCs that would be inline with your use, as follows: VlanId ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A 12-bit VLAN ID used in the VLAN Tag header." SYNTAX Integer32 (1..4094) REFERENCE "Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D10, chapter 3.13 " VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) The latter one, would have been inline with your use in frwk802FilterVlanId OBJECT-TYPE SYNTAX Integer32 (-1 | 1..4094) STATUS current DESCRIPTION "The VLAN ID (VID) that uniquely identifies a VLAN within the device. This VLAN may be known or unknown (i.e., traffic associated with this VID has not yet been seen by the device) at the time this entry is instantiated. Setting the frwk802FilterVlanId object to -1 indicates that VLAN data should not be considered during traffic classification." ::= { frwk802FilterEntry 5 } But afte someone objected to a negative value for 'any, and based on Andrew's input I believe, people are now discussing VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of 4095 is not a vlaid VLAN ID and is used to indicate a wildcard, i.e. any value. " SYNTAX INTEGER (1..4095) That would be conflicting with your definition, and I might later ask you to deprecate your object and define a new one that aligns with the generic VLAN ID as defined by the bridgemib WG. Unfortunately, they are not sure yet, Bridgemib WG chair is taking it to IEEE and they will discuss it in week of March 9th, So it will take a while before we know for sure. So I am inclined to let you go with what you have, or to redefine it as SYNTAX INTEGER (1..4095). In the latter case, pls again do a quick pseudo WG Last Call for the change. Please let me know how you want to proceeed. Bert