From owner-rap@ops.ietf.org  Tue Nov  5 18:11:12 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23789
	for <rap-archive@lists.ietf.org>; Tue, 5 Nov 2002 18:11:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189CrX-0001PX-00
	for rap-data@psg.com; Tue, 05 Nov 2002 15:11:59 -0800
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by psg.com with esmtp (Exim 3.36 #2)
	id 189CrV-0001Nw-00
	for rap@ops.ietf.org; Tue, 05 Nov 2002 15:11:57 -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 gA5NBPq15403
	for <rap@ops.ietf.org>; Tue, 5 Nov 2002 18:11:25 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19)
	id <V8QXZZMJ>; Wed, 6 Nov 2002 00:11:24 +0100
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0F54F8B8@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Rap-wg (E-mail)" <rap@ops.ietf.org>
Subject: FW: PLEASE HOLD on: Protocol Action: Session Authorization for RS
	VP to Proposed
Date: Wed, 6 Nov 2002 00:11:23 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Status: No, hits=-1.4 required=5.0
	tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Mmm... it looks like this was not posted to the RAP wg list.

So this is to inform you that this happened.
You can blame me for having dropped one set of comments from a
security expert (Eric Rescorla, also IAB member) that got 
uncovered right after the "approval" message was posted.
I then asked to put the doc on Hold and I also asked Louis
to work with Eric to try and resolve the issues.

I think they are close to fixing the concerns and I expect
Louis to post a new draft to this list with a summary of the
issues that were raised and how he has addressed them.

Thanks,
Bert 

-----Original Message-----
From: Steve Coya [mailto:scoya@ietf.org]
Sent: vrijdag 1 november 2002 23:54
To: rfc-editor@rfc-editor.org
Cc: iesg@ietf.org
Subject: PLEASE HOLD on: Protocol Action: Session Authorization for RSVP
to Proposed



Greetings,


Just as the announcement was sent, it was discovered that not all the
comments had been conveyed to the author (wouldn't ya know it).

Please hold off processing this Protocol action.



Steve




From owner-rap@ops.ietf.org  Tue Nov  5 18:40:30 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25055
	for <rap-archive@lists.ietf.org>; Tue, 5 Nov 2002 18:40:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189DKa-00048d-00
	for rap-data@psg.com; Tue, 05 Nov 2002 15:42:00 -0800
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by psg.com with esmtp (Exim 3.36 #2)
	id 189DKY-00043D-00
	for rap@ops.ietf.org; Tue, 05 Nov 2002 15:41:58 -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 gA5NfQq23610
	for <rap@ops.ietf.org>; Tue, 5 Nov 2002 18:41:27 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19)
	id <V8QXZZVN>; Wed, 6 Nov 2002 00:41:26 +0100
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0F54F8C3@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Hahn, Scott" <scott.hahn@intel.com>,
        "Rap-wg (E-mail)"
	 <rap@ops.ietf.org>
Subject: RE: PLEASE HOLD on: Protocol Action: Session Authorization for RS
	 VP to Proposed
Date: Wed, 6 Nov 2002 00:41:23 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-Spam-Status: No, hits=-1.9 required=5.0
	tests=EXCHANGE_SERVER,SPAM_PHRASE_01_02
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Scott asks:
> Can you forward me what the issue was?
> Thanks.
> 	-Scott

Appologies, I should actually have copied this to the list
right away last Week..  Anyway, here it is attached below

I first thought that maybe it was a matter of answering the 
comments by Louis... turns out that a few changes had to be
made to the doc (that Louis will post as I expect).

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: donderdag 31 oktober 2002 22:11
To: Louis-Nicolas Hamer (E-mail)
Cc: Eric Rescorla (E-mail); Steve Bellovin (E-mail); Randy Bush (E-mail)
Subject: FW: draft-ietf-rap-session-auth-04.txt


Louis, sorry, but it seems we did miss to re-evaluate
some comments/questions from Eric.

Can you quickly try to address his comments/questions.
Specially important are:

   The items that are potentially serious are 4.1.1 
   and 4.2. In those cases I'm not at all clear on what 
   the authors intend. 4.1.1 may have a simple answer 
   (we should ask the authors). We should ask about 4.2
   as well.

Sorry that I overlooked these when re-evaluating the latest 
revision. First let us (quickly) have answers and/or your
views, then let us see what we can still do about it at this 
point in the process. I am not even sure you ever saw these
before (I was under the impression that you did have them,
but I now see no proof of that in my email archive.

Thanks,
Bert 
------------------
To: bwijnen@lucent.com, smb@research.att.com
Subject: More on RSVP Auth
Mime-Version: 1.0 (generated by tm-edit 1.8)
Date: Fri, 20 Sep 2002 10:14:08 -0700
From: Eric Rescorla <ekr@rtfm.com>

Ok, I've reread the document. It's much improved but I've
still got some issues.


S 3.3.1
Realistically, when would you use DNs? It looks like they're
only used to specify shared keys. The same question applies
to URIs. What's the target of the URI supposed to be?

What are the contents of the X509_V3_CERT id type supposed
to be? No ASN.1 type is specified here.

S 3.3.3
I'm trying to figure out how to interpret the source address.
In particular, is the FQDN ever mapped to an IP address here?
If so, that seems problematic.

S 4.1.1
I don't understand how key rollover works for shared symmetric
keys. Is there some key ID value that indicates whether the 
old or new key is being used?

S 4.2
This still seems under-specified to me. What's the protocol
that the router/PDP uses to contact the authorizing entity?

S 4.3.1.1 
It's still pretty unclear which certificates go where. S/MIME
has it's own certificate carrying mechanism and then there's
also the X509_CERT identity payload.

S 4.3.1.2
A lot of the terminology in the PGP section appears to be
PKIX terminology... AFAIK, PGP doesn't have CRLs or distinguished
names....

S 5
I'd put this before the detailed message descriptions. I think
it would make it easier to understand. 


General questions/comments
(1) It appears from rereading that the auth token duplicates
a lot of data in the RSVP request. Is that so? Is it considered
a problem?

(2) It appears from the text that the idea here is that 
Policy Servers keep a cache of authorized sessions (using
SESSION_IDs as lookup keys). Is there some provision
for self-authenticating tokens instead? Or is that just
a local matter?

(3) I'd like it made more clear that proper clock synch is
really important for the anti-replay stuff to
work properly.

Nits:
There are a lot of special characters (\226) here.




From owner-rap@ops.ietf.org  Tue Nov  5 18:44:31 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25219
	for <rap-archive@lists.ietf.org>; Tue, 5 Nov 2002 18:44:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189DPL-0004WN-00
	for rap-data@psg.com; Tue, 05 Nov 2002 15:46:55 -0800
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by psg.com with esmtp (Exim 3.36 #2)
	id 189DPI-0004VJ-00
	for rap@ops.ietf.org; Tue, 05 Nov 2002 15:46:53 -0800
Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4])
	by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id gA5NilY13131
	for <rap@ops.ietf.org>; Wed, 6 Nov 2002 10:44:47 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id gA5Nkom22776
	for <rap@ops.ietf.org>; Wed, 6 Nov 2002 10:46:50 +1100 (EST)
Received: from ericsson.com.au (dhcp-239-99.epa.ericsson.se [146.11.239.99]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id WAVS6356; Wed, 6 Nov 2002 10:46:48 +1100
Message-ID: <3DC8584F.6070309@ericsson.com.au>
Date: Wed, 06 Nov 2002 10:46:23 +1100
From: Brian Williams <brian.williams@ericsson.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
X-Accept-Language: en
MIME-Version: 1.0
To: rap@ops.ietf.org
Subject: wildcard flowid in framework PIB?
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.3 required=5.0
	tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA,
	      X_ACCEPT_LANG
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi All.
I have a question on the framework PIB. When I look at many of the 
filter attributes, there exist values that can be used as wildcards.

The following are a few examples:
- for source and destination addresses, a prefix length of 0 indicates a 
match of any address
- for DSCP, a value of -1 will match all DSCP values
- for port numbers, you can set the min and max to include all values
- for protocol number, a value of 255 means match all

However, for the FlowId, the range is specified as 0..1048575 which is 
the valid range of the 20 bit label. How is a wildcard FlowId indicated?
/brian





From owner-rap@ops.ietf.org  Tue Nov  5 23:03:08 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09632
	for <rap-archive@lists.ietf.org>; Tue, 5 Nov 2002 23:03:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189HQv-0001kt-00
	for rap-data@psg.com; Tue, 05 Nov 2002 20:04:49 -0800
Received: from smtp-out-6.wanadoo.fr ([193.252.19.25] helo=mel-rto6.wanadoo.fr)
	by psg.com with esmtp (Exim 3.36 #2)
	id 189HQl-0001kD-00
	for rap@ops.ietf.org; Tue, 05 Nov 2002 20:04:39 -0800
Received: from mel-rta8.wanadoo.fr (193.252.19.79) by mel-rto6.wanadoo.fr (6.5.007)
        id 3DA24D4D0116A9FE; Wed, 6 Nov 2002 05:04:02 +0100
Received: from manouchka (80.11.101.245) by mel-rta8.wanadoo.fr (6.5.007)
        id 3DA24B4A0110C744; Wed, 6 Nov 2002 05:04:02 +0100
Reply-To: <em.dumont@wanadoo.fr>
From: "Emmanuel Dumont" <em.dumont@wanadoo.fr>
To: "Brian Williams" <brian.williams@ericsson.com.au>, <rap@ops.ietf.org>
Cc: <alain.baudot@rd.francetelecom.com>
Subject: RE: wildcard flowid in framework PIB?
Date: Wed, 6 Nov 2002 05:07:58 +0100
Message-ID: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr>
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.2910.0)
In-Reply-To: <3DC8584F.6070309@ericsson.com.au>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Spam-Status: No, hits=-3.8 required=5.0
	tests=IN_REP_TO,SPAM_PHRASE_01_02,USER_AGENT_OUTLOOK
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Brian,

Do you think a wildcard is needed for the FlowId attribute ?
Which one could you suggest ?
Kwok: is it an omission in the FR-PIB ?
Maybe an IPv6 expert can help us to solve that question...

Brian : Do you think that others wildcards are missing ?

Emmanuel Dumont
----------------------------
France Telecom OCISI/DIeP (Guyancourt, France)
Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com
----------------------------

-----Message d'origine-----
De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la part de
Brian Williams
Envoye : mercredi 6 novembre 2002 00:46
A : rap@ops.ietf.org
Objet : wildcard flowid in framework PIB?

Hi All.
I have a question on the framework PIB. When I look at many of the
filter attributes, there exist values that can be used as wildcards.

The following are a few examples:
- for source and destination addresses, a prefix length of 0 indicates a
match of any address
- for DSCP, a value of -1 will match all DSCP values
- for port numbers, you can set the min and max to include all values
- for protocol number, a value of 255 means match all

However, for the FlowId, the range is specified as 0..1048575 which is
the valid range of the 20 bit label. How is a wildcard FlowId indicated?
/brian





From owner-rap@ops.ietf.org  Thu Nov  7 15:13:55 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09216
	for <rap-archive@lists.ietf.org>; Thu, 7 Nov 2002 15:13:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189t3L-000Hjl-00
	for rap-data@psg.com; Thu, 07 Nov 2002 12:14:59 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #2)
	id 189t36-000HhP-00; Thu, 07 Nov 2002 12:14:44 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965
	for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST)
Message-Id: <200211072011.PAA08965@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: All IETF Working Groups: ;
Subject: Note Well Statement
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -0500
X-Spam-Status: No, hits=0.9 required=5.0
	tests=SPAM_PHRASE_01_02,TO_HAS_SPACES,TO_MALFORMED
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk


From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.



From owner-rap@ops.ietf.org  Thu Nov  7 17:11:59 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15391
	for <rap-archive@lists.ietf.org>; Thu, 7 Nov 2002 17:11:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189uuR-0003zE-00
	for rap-data@psg.com; Thu, 07 Nov 2002 14:13:55 -0800
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by psg.com with esmtp (Exim 3.36 #2)
	id 189uuO-0003z2-00
	for rap@ops.ietf.org; Thu, 07 Nov 2002 14:13:52 -0800
Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4])
	by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id gA7MBgY16726;
	Fri, 8 Nov 2002 09:11:44 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id gA7MDim27533;
	Fri, 8 Nov 2002 09:13:44 +1100 (EST)
Received: from ericsson.com.au (dhcp-239-99.epa.ericsson.se [146.11.239.99]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id WAVS75WG; Fri, 8 Nov 2002 09:13:43 +1100
Message-ID: <3DCAE572.20003@ericsson.com.au>
Date: Fri, 08 Nov 2002 09:13:06 +1100
From: Brian Williams <brian.williams@ericsson.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
X-Accept-Language: en
MIME-Version: 1.0
To: em.dumont@wanadoo.fr
CC: rap@ops.ietf.org, alain.baudot@rd.francetelecom.com
Subject: Re: wildcard flowid in framework PIB?
References: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-3.9 required=5.0
	tests=EMAIL_ATTRIBUTION,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,
	      USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Emmanuel.
Please see comments inline.
/brian

Emmanuel Dumont wrote:

>Hi Brian,
>
>Do you think a wildcard is needed for the FlowId attribute ?
>  
>
I consider that a wildcard would be needed for FlowId as much as for the 
other attributes (eg DSCP). I think there would need to be an 
explanation of why one is not provided.

>Which one could you suggest ?
>
I would think a value of -1 (as used for DSCP) would be appropriate.

>Kwok: is it an omission in the FR-PIB ?
>Maybe an IPv6 expert can help us to solve that question...
>
>Brian : Do you think that others wildcards are missing ?
>
This is the only one that I have identified is missing from the filter. 
I have not done a careful check on anything else in the document.

>Emmanuel Dumont
>----------------------------
>France Telecom OCISI/DIeP (Guyancourt, France)
>Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com
>----------------------------
>
>-----Message d'origine-----
>De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la part de
>Brian Williams
>Envoye : mercredi 6 novembre 2002 00:46
>A : rap@ops.ietf.org
>Objet : wildcard flowid in framework PIB?
>
>Hi All.
>I have a question on the framework PIB. When I look at many of the
>filter attributes, there exist values that can be used as wildcards.
>
>The following are a few examples:
>- for source and destination addresses, a prefix length of 0 indicates a
>match of any address
>- for DSCP, a value of -1 will match all DSCP values
>- for port numbers, you can set the min and max to include all values
>- for protocol number, a value of 255 means match all
>
>However, for the FlowId, the range is specified as 0..1048575 which is
>the valid range of the 20 bit label. How is a wildcard FlowId indicated?
>/brian
>
>
>  
>






From owner-rap@ops.ietf.org  Thu Nov  7 19:04:30 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18825
	for <rap-archive@lists.ietf.org>; Thu, 7 Nov 2002 19:04:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189wes-000Fk4-00
	for rap-data@psg.com; Thu, 07 Nov 2002 16:05:58 -0800
Received: from zcars04f.nortelnetworks.com ([47.129.242.57])
	by psg.com with esmtp (Exim 3.36 #2)
	id 189weq-000FeE-00
	for rap@ops.ietf.org; Thu, 07 Nov 2002 16:05:56 -0800
Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA8058e08150;
	Thu, 7 Nov 2002 19:05:11 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TWX03RNT; Thu, 7 Nov 2002 19:05:08 -0500
Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TSNC93GT; Thu, 7 Nov 2002 19:05:06 -0500
Message-Id: <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 07 Nov 2002 19:03:07 -0500
To: Brian Williams <brian.williams@ericsson.com.au>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: wildcard flowid in framework PIB?
Cc: em.dumont@wanadoo.fr, rap@ops.ietf.org, alain.baudot@rd.francetelecom.com,
        Kwok Ho Chan <khchan@NortelNetworks.com>
In-Reply-To: <3DCAE572.20003@ericsson.com.au>
References: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Status: No, hits=-8.2 required=5.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Brian, Emmanuel:
We do not need wildcard for the frwkIpFilterFlowId attribute in the
Framework PIB's frwkIpFilterEntry.

The reasoning is as follows:

Please first see
   http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-03.txt
which I have quote the following from bottom of its section 3:

>    The Flow Label value set by the source MUST be delivered unchanged to
>    the destination node(s).
>
>    IPv6 nodes MUST NOT assume mathematical or other non-standardized
>    properties of the Flow Label values assigned by source nodes. Router
>    performance SHOULD NOT be dependent on the distribution of the Flow
>    Label values. Especially, the Flow Label bits alone make poor
>    material for a hash key.
>
>
>
>Rajahalme, et al.         Expires: March 2003                   [Page 3]
>
>INTERNET-DRAFT     draft-ietf-ipv6-flow-label-03.txt      September 2002
>
>
>    If an IPv6 node is not providing flow-specific treatment, it MUST
>    ignore the field when receiving or forwarding a packet.

the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can be 3 
conditions
for the Flow Label field of the IPv6 header:
1. It contain the value of zero, meaning it is not used.
2. It contain some specific value, with no defined syntax and semantics.
     Hence each value is unique on its own with no relationship to Flow Labels
     of containing another value.
3. It contain some value other than zero.

For the first 2 cases indicated above, the filter setup for them is 
trivial, just
set the frwkIpFilterFlowId to zero or the specific value needed.

For the 3rd case, the filtering definition should use the 
frwkBaseFilterNegation
set to true and frwkIpFilterFlowId set to zero.  This will indicate a 
filter match
for all Flow Label values other than zero.

Please let me know if this does not resolve the question you have.
Thanks!
-- Kwok --


At 09:13 AM 11/8/02 +1100, Brian Williams wrote:
>Hi Emmanuel.
>Please see comments inline.
>/brian
>
>Emmanuel Dumont wrote:
>
>>Hi Brian,
>>
>>Do you think a wildcard is needed for the FlowId attribute ?
>>
>I consider that a wildcard would be needed for FlowId as much as for the 
>other attributes (eg DSCP). I think there would need to be an explanation 
>of why one is not provided.
>
>>Which one could you suggest ?
>I would think a value of -1 (as used for DSCP) would be appropriate.
>
>>Kwok: is it an omission in the FR-PIB ?
>>Maybe an IPv6 expert can help us to solve that question...
>>
>>Brian : Do you think that others wildcards are missing ?
>This is the only one that I have identified is missing from the filter. I 
>have not done a careful check on anything else in the document.
>
>>Emmanuel Dumont
>>----------------------------
>>France Telecom OCISI/DIeP (Guyancourt, France)
>>Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com
>>----------------------------
>>
>>-----Message d'origine-----
>>De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la part de
>>Brian Williams
>>Envoye : mercredi 6 novembre 2002 00:46
>>A : rap@ops.ietf.org
>>Objet : wildcard flowid in framework PIB?
>>
>>Hi All.
>>I have a question on the framework PIB. When I look at many of the
>>filter attributes, there exist values that can be used as wildcards.
>>
>>The following are a few examples:
>>- for source and destination addresses, a prefix length of 0 indicates a
>>match of any address
>>- for DSCP, a value of -1 will match all DSCP values
>>- for port numbers, you can set the min and max to include all values
>>- for protocol number, a value of 255 means match all
>>
>>However, for the FlowId, the range is specified as 0..1048575 which is
>>the valid range of the 20 bit label. How is a wildcard FlowId indicated?
>>/brian
>>
>>
>>
>
>
>




From owner-rap@ops.ietf.org  Thu Nov  7 19:54:14 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19818
	for <rap-archive@lists.ietf.org>; Thu, 7 Nov 2002 19:54:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189xQf-000KoN-00
	for rap-data@psg.com; Thu, 07 Nov 2002 16:55:21 -0800
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by psg.com with esmtp (Exim 3.36 #2)
	id 189xQb-000Ko7-00
	for rap@ops.ietf.org; Thu, 07 Nov 2002 16:55:18 -0800
Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4])
	by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id gA80r2Y13220;
	Fri, 8 Nov 2002 11:53:02 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id gA80t3m18585;
	Fri, 8 Nov 2002 11:55:04 +1100 (EST)
Received: from ericsson.com.au (dhcp-239-99.epa.ericsson.se [146.11.239.99]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id WAVS70Q7; Fri, 8 Nov 2002 11:55:01 +1100
Message-ID: <3DCB0B45.9050508@ericsson.com.au>
Date: Fri, 08 Nov 2002 11:54:29 +1100
From: Brian Williams <brian.williams@ericsson.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
X-Accept-Language: en
MIME-Version: 1.0
To: Kwok Ho Chan <khchan@NortelNetworks.com>
CC: em.dumont@wanadoo.fr, rap@ops.ietf.org, alain.baudot@rd.francetelecom.com
Subject: Re: wildcard flowid in framework PIB?
References: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-7.4 required=5.0
	tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES,
	      SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA,
	      X_ACCEPT_LANG
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Kwok.
I still am not clear how you would indicate a value to match all 
FlowIDs, and hence the FlowId can be ignored. Please see further inline.
/brian

Kwok Ho Chan wrote:

> Brian, Emmanuel:
> We do not need wildcard for the frwkIpFilterFlowId attribute in the
> Framework PIB's frwkIpFilterEntry.
>
> The reasoning is as follows:

<snip>

>>    If an IPv6 node is not providing flow-specific treatment, it MUST
>>    ignore the field when receiving or forwarding a packet.
>
I assume you are using this as the key point. What I am after is how you 
tell the node that it is not doing flow-specific treatment, and 
therefore the field can be ignored. That is, what do you send in the PIB 
to tell the node that the FlowId is not used? This is not case 1, 2, or 
3 below.

> the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can be 
> 3 conditions
> for the Flow Label field of the IPv6 header:
> 1. It contain the value of zero, meaning it is not used.
> 2. It contain some specific value, with no defined syntax and semantics.
>     Hence each value is unique on its own with no relationship to Flow 
> Labels
>     of containing another value.
> 3. It contain some value other than zero.
>
> For the first 2 cases indicated above, the filter setup for them is 
> trivial, just
> set the frwkIpFilterFlowId to zero or the specific value needed.

This is clear.

> For the 3rd case, the filtering definition should use the 
> frwkBaseFilterNegation
> set to true and frwkIpFilterFlowId set to zero.  This will indicate a 
> filter match
> for all Flow Label values other than zero.

This is also clear.

> Please let me know if this does not resolve the question you have.
> Thanks!
> -- Kwok --
>
>
> At 09:13 AM 11/8/02 +1100, Brian Williams wrote:
>
>> Hi Emmanuel.
>> Please see comments inline.
>> /brian
>>
>> Emmanuel Dumont wrote:
>>
>>> Hi Brian,
>>>
>>> Do you think a wildcard is needed for the FlowId attribute ?
>>>
>> I consider that a wildcard would be needed for FlowId as much as for 
>> the other attributes (eg DSCP). I think there would need to be an 
>> explanation of why one is not provided.
>>
>>> Which one could you suggest ?
>>
>> I would think a value of -1 (as used for DSCP) would be appropriate.
>>
>>> Kwok: is it an omission in the FR-PIB ?
>>> Maybe an IPv6 expert can help us to solve that question...
>>>
>>> Brian : Do you think that others wildcards are missing ?
>>
>> This is the only one that I have identified is missing from the 
>> filter. I have not done a careful check on anything else in the document.
>>
>>> Emmanuel Dumont
>>> ----------------------------
>>> France Telecom OCISI/DIeP (Guyancourt, France)
>>> Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com
>>> ----------------------------
>>>
>>> -----Message d'origine-----
>>> De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la part de
>>> Brian Williams
>>> Envoye : mercredi 6 novembre 2002 00:46
>>> A : rap@ops.ietf.org
>>> Objet : wildcard flowid in framework PIB?
>>>
>>> Hi All.
>>> I have a question on the framework PIB. When I look at many of the
>>> filter attributes, there exist values that can be used as wildcards.
>>>
>>> The following are a few examples:
>>> - for source and destination addresses, a prefix length of 0 indicates a
>>> match of any address
>>> - for DSCP, a value of -1 will match all DSCP values
>>> - for port numbers, you can set the min and max to include all values
>>> - for protocol number, a value of 255 means match all
>>>
>>> However, for the FlowId, the range is specified as 0..1048575 which is
>>> the valid range of the 20 bit label. How is a wildcard FlowId indicated?
>>> /brian
>>
>>




From owner-rap@ops.ietf.org  Thu Nov  7 20:33:28 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20535
	for <rap-archive@lists.ietf.org>; Thu, 7 Nov 2002 20:33:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189y2S-000OlI-00
	for rap-data@psg.com; Thu, 07 Nov 2002 17:34:24 -0800
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by psg.com with esmtp (Exim 3.36 #2)
	id 189y2P-000Okx-00
	for rap@ops.ietf.org; Thu, 07 Nov 2002 17:34:22 -0800
Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gA81XYG14149;
	Thu, 7 Nov 2002 20:33:36 -0500 (EST)
Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TWX03RT2; Thu, 7 Nov 2002 20:33:34 -0500
Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id TSNC932A; Thu, 7 Nov 2002 20:32:45 -0500
Message-Id: <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com>
X-Sender: khchan@zbl6c002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 07 Nov 2002 20:30:24 -0500
To: Brian Williams <brian.williams@ericsson.com.au>
From: Kwok Ho Chan <khchan@NortelNetworks.com>
Subject: Re: wildcard flowid in framework PIB?
Cc: "Kwok-Ho Chan" <khchan@NortelNetworks.com>, em.dumont@wanadoo.fr,
        rap@ops.ietf.org, alain.baudot@rd.francetelecom.com
In-Reply-To: <3DCB0B45.9050508@ericsson.com.au>
References: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr>
 <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Status: No, hits=-8.9 required=5.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Brian:
Please see inline below.
-- Kwok --

At 11:54 AM 11/8/02 +1100, Brian Williams wrote:
>Hi Kwok.
>I still am not clear how you would indicate a value to match all FlowIDs, 
>and hence the FlowId can be ignored. Please see further inline.
>/brian
>
>Kwok Ho Chan wrote:
>
>>Brian, Emmanuel:
>>We do not need wildcard for the frwkIpFilterFlowId attribute in the
>>Framework PIB's frwkIpFilterEntry.
>>
>>The reasoning is as follows:
>
><snip>
>
>>>    If an IPv6 node is not providing flow-specific treatment, it MUST
>>>    ignore the field when receiving or forwarding a packet.
>I assume you are using this as the key point. What I am after is how you 
>tell the node that it is not doing flow-specific treatment, and therefore 
>the field can be ignored. That is, what do you send in the PIB to tell the 
>node that the FlowId is not used? This is not case 1, 2, or 3 below.

The encoding of the frwkIpFilterFlowId attribute can have a length of zero, 
used to
indicate the attribute is not used (please see COPS-PR RFC 3084).  Hence this
is used to indicate this attribute is not used as part of the filter 
definition and will
not contribute to the filtering action, resulting in a "don't care" 
condition for
frwkIpFilterFlowId,  the meaning of a wildcard match for this attribute.


>>the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can be 3 
>>conditions
>>for the Flow Label field of the IPv6 header:
>>1. It contain the value of zero, meaning it is not used.
>>2. It contain some specific value, with no defined syntax and semantics.
>>     Hence each value is unique on its own with no relationship to Flow 
>> Labels
>>     of containing another value.
>>3. It contain some value other than zero.
>>
>>For the first 2 cases indicated above, the filter setup for them is 
>>trivial, just
>>set the frwkIpFilterFlowId to zero or the specific value needed.
>
>This is clear.
>
>>For the 3rd case, the filtering definition should use the 
>>frwkBaseFilterNegation
>>set to true and frwkIpFilterFlowId set to zero.  This will indicate a 
>>filter match
>>for all Flow Label values other than zero.
>
>This is also clear.
>
>>Please let me know if this does not resolve the question you have.
>>Thanks!
>>-- Kwok --
>>
>>
>>At 09:13 AM 11/8/02 +1100, Brian Williams wrote:
>>
>>>Hi Emmanuel.
>>>Please see comments inline.
>>>/brian
>>>
>>>Emmanuel Dumont wrote:
>>>
>>>>Hi Brian,
>>>>
>>>>Do you think a wildcard is needed for the FlowId attribute ?
>>>I consider that a wildcard would be needed for FlowId as much as for the 
>>>other attributes (eg DSCP). I think there would need to be an 
>>>explanation of why one is not provided.
>>>
>>>>Which one could you suggest ?
>>>
>>>I would think a value of -1 (as used for DSCP) would be appropriate.
>>>
>>>>Kwok: is it an omission in the FR-PIB ?
>>>>Maybe an IPv6 expert can help us to solve that question...
>>>>
>>>>Brian : Do you think that others wildcards are missing ?
>>>
>>>This is the only one that I have identified is missing from the filter. 
>>>I have not done a careful check on anything else in the document.
>>>
>>>>Emmanuel Dumont
>>>>----------------------------
>>>>France Telecom OCISI/DIeP (Guyancourt, France)
>>>>Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com
>>>>----------------------------
>>>>
>>>>-----Message d'origine-----
>>>>De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la part de
>>>>Brian Williams
>>>>Envoye : mercredi 6 novembre 2002 00:46
>>>>A : rap@ops.ietf.org
>>>>Objet : wildcard flowid in framework PIB?
>>>>
>>>>Hi All.
>>>>I have a question on the framework PIB. When I look at many of the
>>>>filter attributes, there exist values that can be used as wildcards.
>>>>
>>>>The following are a few examples:
>>>>- for source and destination addresses, a prefix length of 0 indicates a
>>>>match of any address
>>>>- for DSCP, a value of -1 will match all DSCP values
>>>>- for port numbers, you can set the min and max to include all values
>>>>- for protocol number, a value of 255 means match all
>>>>
>>>>However, for the FlowId, the range is specified as 0..1048575 which is
>>>>the valid range of the 20 bit label. How is a wildcard FlowId indicated?
>>>>/brian
>>>




From owner-rap@ops.ietf.org  Thu Nov  7 22:17:24 2002
Received: from psg.com (smmsp@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22891
	for <rap-archive@lists.ietf.org>; Thu, 7 Nov 2002 22:17:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 189zfP-0008G3-00
	for rap-data@psg.com; Thu, 07 Nov 2002 19:18:43 -0800
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by psg.com with esmtp (Exim 3.36 #2)
	id 189zfM-0008Fq-00
	for rap@ops.ietf.org; Thu, 07 Nov 2002 19:18:41 -0800
Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4])
	by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id gA83GGY03274;
	Fri, 8 Nov 2002 14:16:20 +1100 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165])
	by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id gA83IGm27636;
	Fri, 8 Nov 2002 14:18:17 +1100 (EST)
Received: from ericsson.com.au (150.236.87.122 [150.236.87.122]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id WAVS8C57; Fri, 8 Nov 2002 14:18:14 +1100
Message-ID: <3DCB2CCB.1060602@ericsson.com.au>
Date: Fri, 08 Nov 2002 14:17:31 +1100
From: Brian Williams <brian.williams@ericsson.com.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kwok Ho Chan <khchan@NortelNetworks.com>
CC: em.dumont@wanadoo.fr, rap@ops.ietf.org, alain.baudot@rd.francetelecom.com
Subject: Re: wildcard flowid in framework PIB?
References: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com>
In-Reply-To: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-10.0 required=5.0
	tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
	      SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA,
	      X_ACCEPT_LANG
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Kwok.
I understood the use of setting the length to zero was for unsupported 
attributes. If the intention is to use this for wildcards, then why is 
there a distinct wildcard value indicated for the protocol and DSCP 
attributes?
/brian

Kwok Ho Chan wrote:

> Brian:
> Please see inline below.
> -- Kwok --
>
> At 11:54 AM 11/8/02 +1100, Brian Williams wrote:
>
>> Hi Kwok.
>> I still am not clear how you would indicate a value to match all 
>> FlowIDs, and hence the FlowId can be ignored. Please see further inline.
>> /brian
>>
>> Kwok Ho Chan wrote:
>>
>>> Brian, Emmanuel:
>>> We do not need wildcard for the frwkIpFilterFlowId attribute in the
>>> Framework PIB's frwkIpFilterEntry.
>>>
>>> The reasoning is as follows:
>>
>>
>> <snip>
>>
>>>>    If an IPv6 node is not providing flow-specific treatment, it MUST
>>>>    ignore the field when receiving or forwarding a packet.
>>>
>> I assume you are using this as the key point. What I am after is how 
>> you tell the node that it is not doing flow-specific treatment, and 
>> therefore the field can be ignored. That is, what do you send in the 
>> PIB to tell the node that the FlowId is not used? This is not case 1, 
>> 2, or 3 below.
>
>
> The encoding of the frwkIpFilterFlowId attribute can have a length of 
> zero, used to
> indicate the attribute is not used (please see COPS-PR RFC 3084).  
> Hence this
> is used to indicate this attribute is not used as part of the filter 
> definition and will
> not contribute to the filtering action, resulting in a "don't care" 
> condition for
> frwkIpFilterFlowId,  the meaning of a wildcard match for this attribute.
>
>
>>> the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can 
>>> be 3 conditions
>>> for the Flow Label field of the IPv6 header:
>>> 1. It contain the value of zero, meaning it is not used.
>>> 2. It contain some specific value, with no defined syntax and 
>>> semantics.
>>>     Hence each value is unique on its own with no relationship to 
>>> Flow Labels
>>>     of containing another value.
>>> 3. It contain some value other than zero.
>>>
>>> For the first 2 cases indicated above, the filter setup for them is 
>>> trivial, just
>>> set the frwkIpFilterFlowId to zero or the specific value needed.
>>
>>
>> This is clear.
>>
>>> For the 3rd case, the filtering definition should use the 
>>> frwkBaseFilterNegation
>>> set to true and frwkIpFilterFlowId set to zero.  This will indicate 
>>> a filter match
>>> for all Flow Label values other than zero.
>>
>>
>> This is also clear.
>>
>>> Please let me know if this does not resolve the question you have.
>>> Thanks!
>>> -- Kwok --
>>>
>>>
>>> At 09:13 AM 11/8/02 +1100, Brian Williams wrote:
>>>
>>>> Hi Emmanuel.
>>>> Please see comments inline.
>>>> /brian
>>>>
>>>> Emmanuel Dumont wrote:
>>>>
>>>>> Hi Brian,
>>>>>
>>>>> Do you think a wildcard is needed for the FlowId attribute ?
>>>>
>>>> I consider that a wildcard would be needed for FlowId as much as 
>>>> for the other attributes (eg DSCP). I think there would need to be 
>>>> an explanation of why one is not provided.
>>>>
>>>>> Which one could you suggest ?
>>>>
>>>>
>>>> I would think a value of -1 (as used for DSCP) would be appropriate.
>>>>
>>>>> Kwok: is it an omission in the FR-PIB ?
>>>>> Maybe an IPv6 expert can help us to solve that question...
>>>>>
>>>>> Brian : Do you think that others wildcards are missing ?
>>>>
>>>>
>>>> This is the only one that I have identified is missing from the 
>>>> filter. I have not done a careful check on anything else in the 
>>>> document.
>>>>
>>>>> Emmanuel Dumont
>>>>> ----------------------------
>>>>> France Telecom OCISI/DIeP (Guyancourt, France)
>>>>> Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com
>>>>> ----------------------------
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la 
>>>>> part de
>>>>> Brian Williams
>>>>> Envoye : mercredi 6 novembre 2002 00:46
>>>>> A : rap@ops.ietf.org
>>>>> Objet : wildcard flowid in framework PIB?
>>>>>
>>>>> Hi All.
>>>>> I have a question on the framework PIB. When I look at many of the
>>>>> filter attributes, there exist values that can be used as wildcards.
>>>>>
>>>>> The following are a few examples:
>>>>> - for source and destination addresses, a prefix length of 0 
>>>>> indicates a
>>>>> match of any address
>>>>> - for DSCP, a value of -1 will match all DSCP values
>>>>> - for port numbers, you can set the min and max to include all values
>>>>> - for protocol number, a value of 255 means match all
>>>>>
>>>>> However, for the FlowId, the range is specified as 0..1048575 
>>>>> which is
>>>>> the valid range of the 20 bit label. How is a wildcard FlowId 
>>>>> indicated?
>>>>> /brian
>>>>
>>>>
>





From owner-rap@ops.ietf.org  Fri Nov  8 13:40:56 2002
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06679
	for <rap-archive@lists.ietf.org>; Fri, 8 Nov 2002 13:40:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 18AE4x-0001f2-00
	for rap-data@psg.com; Fri, 08 Nov 2002 10:42:03 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #2)
	id 18AE4u-0001eq-00
	for rap@ops.ietf.org; Fri, 08 Nov 2002 10:42:00 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06404;
	Fri, 8 Nov 2002 13:39:28 -0500 (EST)
Message-Id: <200211081839.NAA06404@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-access-bind-02.txt
Date: Fri, 08 Nov 2002 13:39:28 -0500
X-Spam-Status: No, hits=1.8 required=5.0
	tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO,
	      SPAM_PHRASE_01_02,TO_MALFORMED
	version=2.41
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		: Framework for Binding Access Control to COPS 
                          Provisioning
	Author(s)	: W. Weiss et al.
	Filename	: draft-ietf-rap-access-bind-02.txt
	Pages		: 107
	Date		: 2002-11-8
	
There is an ever-growing distinction between edge and core 
functionality. While the core continues to focus on stability and 
pure forwarding functionality, the edges increasingly need to deal 
with dynamic capabilities like QoS management, VPN encapsulations, 
encryption, dynamic steering and service monitoring. The dynamic 
deployment of these functions is dependent on specific contextual 
knowledge such as the physical location of the data stream and the 
identity of the client or system generating the data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-access-bind-02.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-access-bind-02.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-access-bind-02.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:	<2002-11-8124937.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-access-bind-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-access-bind-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-11-8124937.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Fri Nov  8 13:41:26 2002
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06740
	for <rap-archive@lists.ietf.org>; Fri, 8 Nov 2002 13:41:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 18AE51-0001fH-00
	for rap-data@psg.com; Fri, 08 Nov 2002 10:42:07 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #2)
	id 18AE4z-0001f4-00
	for rap@ops.ietf.org; Fri, 08 Nov 2002 10:42:05 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06423;
	Fri, 8 Nov 2002 13:39:33 -0500 (EST)
Message-Id: <200211081839.NAA06423@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-feedback-fr-pib-04.txt
Date: Fri, 08 Nov 2002 13:39:32 -0500
X-Spam-Status: No, hits=1.8 required=5.0
	tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO,
	      SPAM_PHRASE_01_02,TO_MALFORMED
	version=2.41
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		: Framework Policy Information Base for Usage Feedback
	Author(s)	: D. Rawlins et al.
	Filename	: draft-ietf-rap-feedback-fr-pib-04.txt
	Pages		: 31
	Date		: 2002-11-8
	
This document describes a Policy Information Base (PIB) to control 
policy usage collection and reporting in a device. 
The provisioning classes specified here allow a Policy Decision 
Point (PDP) to select which policy objects should collect usage 
information, what information should be collected and when it 
should be reported. 
This PIB requires the presence of other PIBs (defined elsewhere) 
that provide the policy objects that usage information is collected 
from.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-04.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-feedback-fr-pib-04.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-feedback-fr-pib-04.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:	<2002-11-8124947.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-feedback-fr-pib-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-feedback-fr-pib-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-11-8124947.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-rap@ops.ietf.org  Sat Nov  9 07:06:47 2002
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16635
	for <rap-archive@lists.ietf.org>; Sat, 9 Nov 2002 07:06:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 18AUOc-00066t-00
	for rap-data@psg.com; Sat, 09 Nov 2002 04:07:26 -0800
Received: from [131.211.224.2] (helo=afwas.ibb.sshunet.nl)
	by psg.com with esmtp (Exim 3.36 #2)
	id 18AUOa-00066h-00
	for rap@ops.ietf.org; Sat, 09 Nov 2002 04:07:25 -0800
Received: from [131.211.226.63] (63pc226.sshunet.nl [131.211.226.63])
	by afwas.ibb.sshunet.nl (Postfix) with ESMTP
	id E1CCF1247F; Sat,  9 Nov 2002 13:07:22 +0100 (CET)
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Wed, 06 Nov 2002 11:19:32 +0100
Subject: Re: wildcard flowid in framework PIB?
From: Freek Dijkstra <freek@macfreek.nl>
To: <rap@ops.ietf.org>
Cc: Walter Weiss <w.weiss@attbi.com>, Kwok Ho Chan <khchan@NortelNetworks.com>
Message-ID: <B9EEAB44.9A70%freek@macfreek.nl>
In-Reply-To: <CNECJLCIGMJKBNHNAFMDAEBICEAA.em.dumont@wanadoo.fr>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Status: No, hits=-6.4 required=5.0
	tests=DATE_IN_PAST_48_96,EMAIL_ATTRIBUTION,INVALID_MSGID,
	      IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT,
	      USER_AGENT_ENTOURAGE
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On 06-11-2002 05:07, Emmanuel Dumont <em.dumont@wanadoo.fr> wrote:

> Hi Brian,
> 
> Do you think a wildcard is needed for the FlowId attribute ?
> Which one could you suggest ?
> Kwok: is it an omission in the FR-PIB ?
> [...]
> 
> Brian : Do you think that others wildcards are missing ?

I haven't looked into this much detail of the FR-PIB, but I have to note
that the current draft of the Access Bind PIB [1] does require that each

Is it possible for PRI's to use a value of <null> instead of 0, -1, etc to
indicate a wildcard?

[1] draft-ietf-rap-access-bind-02.txt, a new version was submitted but is
not pubblished




From owner-rap@ops.ietf.org  Sat Nov  9 07:53:56 2002
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17537
	for <rap-archive@lists.ietf.org>; Sat, 9 Nov 2002 07:53:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 18AV92-0007ok-00
	for rap-data@psg.com; Sat, 09 Nov 2002 04:55:24 -0800
Received: from rip.psg.com ([147.28.0.39])
	by psg.com with esmtp (Exim 3.36 #2)
	id 18AV91-0007oY-00
	for rap@ops.ietf.org; Sat, 09 Nov 2002 04:55:23 -0800
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com)
	by rip.psg.com with esmtp (Exim 4.10)
	id 18AV90-000HRe-00
	for rap@ops.ietf.org; Sat, 09 Nov 2002 04:55:23 -0800
Message-ID: <B9F2C422.9B3F%fdijkstr@science.uva.nl>
In-Reply-To: <3DCB2CCB.1060602@ericsson.com.au>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Date: Sat, 09 Nov 2002 13:54:42 +0100
Subject: Re: wildcard flowid in framework PIB?
From: Freek Dijkstra <fdijkstr@science.uva.nl>
To: <rap@ops.ietf.org>
X-Spam-Status: No, hits=-8.2 required=5.0
	tests=EMAIL_ATTRIBUTION,INVALID_MSGID,IN_REP_TO,
	      QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_02_03
	version=2.41
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 mis-posts.  so fix subscription addresses! ]

On 08-11-2002 04:17, Brian Williams <brian.williams@ericsson.com.au> wrote:

> I understood the use of setting the length to zero was for unsupported
> attributes. If the intention is to use this for wildcards, then why is
> there a distinct wildcard value indicated for the protocol and DSCP
> attributes?

Well, at first sight I would say that they are same. After all, they mean
the same: ignore this header field. In fact, the distinction between
numerical wildcards (0, -1, etc,) and NULL wildcards has confused me.

However, in draft-ietf-rap-access-bind-02.txt (and all previous versions)
implicitly assumes that you can specify both a NULL and a numberical
wildcard. They have a very different meaning:

Allow me to use an example by Walter Weiss. Take for example these two
frwkIpFilter filters, which will match all packets, regardsless of the port
number of the source address.

Filter1:
 frwkIpFilterDstL4PortMin = <null>
 frwkIpFilterDstL4PortMax = <null>

Filter1:
 frwkIpFilterDstL4PortMin = 1
 frwkIpFilterDstL4PortMax = 65535

However, the access bind PIB specifies a signaling protocol, and for the
second filter, an event will be sent each time a new unique port number is
detected. For the first filter, the port number is ignored in determining if
an event must be sent.

Regards,
Freek Dijkstra






From owner-rap@ops.ietf.org  Sun Nov 10 09:06:31 2002
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16620
	for <rap-archive@lists.ietf.org>; Sun, 10 Nov 2002 09:06:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 18AsjN-000Ogx-00
	for rap-data@psg.com; Sun, 10 Nov 2002 06:06:29 -0800
Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com)
	by psg.com with esmtp (Exim 3.36 #2)
	id 18AsjL-000OeT-00
	for rap@ops.ietf.org; Sun, 10 Nov 2002 06:06:27 -0800
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gAAE5tI28719
	for <rap@ops.ietf.org>; Sun, 10 Nov 2002 09:05:55 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19)
	id <V8QX8HAF>; Sun, 10 Nov 2002 15:05:54 +0100
Message-ID: <A451D5E6F15FD211BABC0008C7FAD7BC0F55003B@nl0006exch003u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Rap-wg (E-mail)" <rap@ops.ietf.org>
Subject: new revision for authsession document
Date: Sun, 10 Nov 2002 15:05:53 +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.2 required=5.0
	tests=EXCHANGE_SERVER,SPAM_PHRASE_00_01
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk

Document
  http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-05.txt
is a new revision that addresses the concerns raised by Eric Rescorla.

Louis will soon post a summary of the changes.

Thanks,
Bert 



From owner-rap@ops.ietf.org  Sun Nov 10 21:04:00 2002
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28657
	for <rap-archive@lists.ietf.org>; Sun, 10 Nov 2002 21:03:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 18B3wS-0007Et-00
	for rap-data@psg.com; Sun, 10 Nov 2002 18:04:44 -0800
Received: from zcars04e.nortelnetworks.com ([47.129.242.56])
	by psg.com with esmtp (Exim 3.36 #2)
	id 18B3wP-0007Cs-00
	for rap@ops.ietf.org; Sun, 10 Nov 2002 18:04:41 -0800
Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67])
	by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAB246r17860
	for <rap@ops.ietf.org>; Sun, 10 Nov 2002 21:04:09 -0500 (EST)
Received: from zcard031.ca.nortel.com ([47.129.242.121]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id WJLF1D6F; Sun, 10 Nov 2002 21:04:06 -0500
Received: from nortelnetworks.com (acart3yy.ca.nortel.com [47.129.49.69]) by zcard031.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VD6HCZH4; Sun, 10 Nov 2002 21:04:06 -0500
Message-ID: <3DCF0F69.2070608@nortelnetworks.com>
Date: Sun, 10 Nov 2002 21:01:13 -0500
X-Sybari-Space: 00000000 00000000 00000000
From: Louis-Nicolas Hamer <nhamer@nortelnetworks.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: rap@ops.ietf.org
Subject: draft-ietf-rap-rsvp-authsession-05.txt
Content-Type: multipart/alternative;
 boundary="------------020003040904080008060408"
X-Spam-Status: No, hits=-1.7 required=5.0
	tests=HTML_FONT_FACE_ODD,SPAM_PHRASE_02_03,USER_AGENT,
	      USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG
	version=2.41
Sender: owner-rap@ops.ietf.org
Precedence: bulk


--------------020003040904080008060408
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  Hi all,

As Bert has indicated, a set of comments from Eric Rescorla had not been 
addressed in the last revision.
The comments were related to the security aspects of the draft. A few 
modifications were made
to ensure the draft specified in more details some security aspects.
Summary of ALL changes:

-1: DNS Spoofing: Eric identified a DNS Spoofing issue. Because of this 
flaw,
a few fields were removed from the SOURCE_ADDR and DEST_ADDR S-TYPEs, 
specifically,
the FQDN, ASCII_DN & UNICODE_DN.

-2: Key rollovers: The example for shared symmetric keys was missing one
field, the AUTH_ENT_ID (I added that to the example). I also added the 
following clarification:
"Since multiple keys may be configured for a particular
   AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST
   be a key ID to be used to identify the appropriate key.

-3: Time synch: Added a sentence to discuss why it is important.

-4: Changed "should" to "SHOULD" in the sentence: "Triple-DES encryption 
is supported in many Kerberos implementations
   (although not specified in [RFC-1510]), and SHOULD be used over
   single DES."

-5: PGP section: wrong terminology was used - It was removed.

-6: X.509 V3 section:
Clarified the certs and crls. Changed the X509_V3_CERT field to be a DN.

-7: Kerberos.  Added the clarifications needed
about the client and server:
" In this request, the client
   (router/PDP) sends (in cleartext) its own identity and the identity
   of the server (the authorizing entity taken from the AUTH_ENT_ID field)
   for which it is requesting credentials .

-8: Clarifications added to section 6.4.
Clarifications added about the danger to rely upon an insecure database 
(such
   as DNS or a public LDAP directory).

Document available @
http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-05.txt

Thanks to Bert for his helpfull assistance. And many thanks to Eric for 
his comments & suggestions.
The draft has been re-inputted into the RFC-Editor's queue.

Cheers,
L-N

--------------020003040904080008060408
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
        <font size="2" face="Times New Roman, Times, serif">Hi all,</font><font
 face="Times New Roman, Times, serif"> <br>
<br>
</font>  <font size="2" face="Times New Roman, Times, serif">As Bert has
indicated, a set of comments from Eric Rescorla had not been addressed in
the last revision.</font><font face="Times New Roman, Times, serif"> <br>
</font><font size="2" face="Times New Roman, Times, serif">The comments were
related to the security aspects of the draft. A few modifications were made</font><font
 face="Times New Roman, Times, serif"> <br>
</font><font size="2" face="Times New Roman, Times, serif">to ensure the
draft specified in more details some security aspects.</font><font
 face="Times New Roman, Times, serif"> <br>
</font>  <font size="2" face="Times New Roman, Times, serif">Summary of ALL
changes: </font>   <br>
<font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">-1: DNS Spoofing:
Eric identified a DNS Spoofing issue. Because of this flaw,</font><font
 face="Times New Roman, Times, serif"> <br>
</font><font size="2" face="Times New Roman, Times, serif">a few fields were
removed from the SOURCE_ADDR and DEST_ADDR S-TYPEs, specifically,</font><font
 face="Times New Roman, Times, serif"> <br>
</font><font size="2" face="Times New Roman, Times, serif">the FQDN, ASCII_DN
&amp; UNICODE_DN.</font><font face="Times New Roman, Times, serif"> <br>
<br>
</font>  <font size="2" face="Times New Roman, Times, serif">-2: Key rollovers:
The example for shared symmetric keys was missing one </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">field, the AUTH_ENT_ID
(I added that to the example). I also added the following clarification:
</font> <font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">"Since multiple
keys may be configured for a particular </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; AUTH_ENT_ID
value, the first 32 bits of the AUTH_DATA field MUST </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; be a key ID
to be used to identify the appropriate key.</font><font
 face="Times New Roman, Times, serif"> <br>
<br>
</font>  <font size="2" face="Times New Roman, Times, serif">-3: Time synch:
Added a sentence to discuss why it is important. </font>   <br>
<font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">-4: Changed "should"
to "SHOULD" in the sentence: "Triple-DES encryption is supported in many
Kerberos implementations </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; (although not
specified in [RFC-1510]), and SHOULD be used over </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; single DES."
</font>   <br>
<font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">-5: PGP section:
wrong terminology was used - It was removed. </font>   <br>
<font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">-6: X.509 V3 section:
</font> <font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">Clarified the
certs and crls. Changed the X509_V3_CERT field to be a DN. </font>   <br>
<font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">-7: Kerberos.
&nbsp;Added the clarifications needed </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">about the client
and server: </font> <font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">" In this request,
the client </font> <font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; (router/PDP)
sends (in cleartext) its own identity and the identity </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; of the server
(the authorizing entity taken from the AUTH_ENT_ID field) </font> <font
 face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; for which it
is requesting credentials .</font><font
 face="Times New Roman, Times, serif"> <br>
<br>
</font>  <font size="2" face="Times New Roman, Times, serif">-8: Clarifications
added to section 6.4. </font> <font face="Times New Roman, Times, serif"><br>
Clarifications added about the danger to </font><font size="2"
 face="Times New Roman, Times, serif">rely upon an insecure database (such
</font> <font face="Times New Roman, Times, serif"><br>
</font><font size="2" face="Times New Roman, Times, serif">&nbsp;&nbsp; as DNS or a
public LDAP directory)</font><font face="Times New Roman, Times, serif">.<br>
</font><font size="2" face="Times New Roman, Times, serif"></font> <font
 face="Times New Roman, Times, serif"><br>
</font>   <font size="2" face="Times New Roman, Times, serif">Document available
@</font><font face="Times New Roman, Times, serif"> <br>
</font><font face="Times New Roman, Times, serif"><a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-05.txt">http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-05.txt</a><br>
<br>
Thanks to Bert for his helpfull assistance. And many thanks to Eric for his
comments &amp; suggestions.<br>
The draft has been re-inputted into the RFC-Editor's queue.<br>
<br>
Cheers,<br>
L-N</font><br>
</body>
</html>

--------------020003040904080008060408--




From owner-rap@ops.ietf.org  Mon Nov 11 15:10:48 2002
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29707
	for <rap-archive@lists.ietf.org>; Mon, 11 Nov 2002 15:10:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.36 #2)
	id 18BKuP-00026h-00
	for rap-data@psg.com; Mon, 11 Nov 2002 12:11:45 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.36 #2)
	id 18BKuM-00026S-00
	for rap@ops.ietf.org; Mon, 11 Nov 2002 12:11:42 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29670;
	Mon, 11 Nov 2002 15:09:08 -0500 (EST)
Message-Id: <200211112009.PAA29670@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-rsvp-authsession-05.txt
Date: Mon, 11 Nov 2002 15:09:08 -0500
X-Spam-Status: No, hits=1.8 required=5.0
	tests=MIME_SUSPECT_NAME,NO_REAL_NAME,SEARCH_ENGINE_PROMO,
	      SPAM_PHRASE_01_02,TO_MALFORMED
	version=2.41
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		: Session Authorization Policy Element
	Author(s)	: L. Hamer, B. Gage, B. Kosinski, H. Shieh
	Filename	: draft-ietf-rap-rsvp-authsession-05.txt
	Pages		: 28
	Date		: 2002-11-8
	
This document describes the representation of a session authorization
policy element for supporting policy-based per-session authorization
and admission control.  The goal of session authorization is to allow
the exchange of information between network elements in order to
authorize the use of resources for a service and to co-ordinate actions
between the signaling and transport planes.  This document describes
how a process on a system authorizes the reservation of resources by a
host and then provides that host with a session authorization policy
element which can be inserted into a resource reservation protocol
(e.g. the RSVP PATH message) to facilitate proper and secure
reservation of those resources within the network. We describe the
encoding of session authorization information as a policy element
conforming to the format of a Policy Data object (RFC-2750) and provide
details relating to operations, processing rules and error scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-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-rsvp-authsession-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-rsvp-authsession-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:	<2002-11-8193525.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-rap-rsvp-authsession-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-rap-rsvp-authsession-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-11-8193525.I-D@ietf.org>

--OtherAccess--

--NextPart--