draft-ietf-rap-rsvp-authsession-04.txt

From owner-rap@ops.ietf.org Tue Oct 1 15:15:09 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01976 for ; Tue, 1 Oct 2002 15:15:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wSTT-000NCa-00 for rap-data@psg.com; Tue, 01 Oct 2002 12:14:27 -0700 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 17wSTK-000NCE-00 for rap@ops.ietf.org; Tue, 01 Oct 2002 12:14:19 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g91JEHO05692 for ; Tue, 1 Oct 2002 15:14:17 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Oct 2002 21:14:16 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Rawlins, Diana" , "'Wijnen, Bert (Bert)'" , "Hahn, Scott" , "Mark Stevens (E-mail)" Cc: "Rap-wg (E-mail)" Subject: AD-review of draft-ietf-rap-feedback-frwk-02.txt Date: Tue, 1 Oct 2002 21:14:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-rap@ops.ietf.org Precedence: bulk Sofar, I never heard anything back on this email Thanks, Bert > -----Original Message----- > From: Rawlins, Diana [mailto:Diana.Rawlins@wcom.com] > Sent: dinsdag 20 augustus 2002 17:39 > To: 'Wijnen, Bert (Bert)'; Hahn, Scott; Mark Stevens (E-mail) > Cc: Rap-wg (E-mail) > Subject: RE: Request to advance drafts > > > I will work with the other authors to address the below > comments and with > the WG chair on that last question. Thank you for the feedback! > > -Diana > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, August 20, 2002 9:55 AM > To: Hahn, Scott; Mark Stevens (E-mail) > Cc: Rap-wg (E-mail) > Subject: RE: Request to advance drafts > > RAP WG, I got this requestst from your WG chairs. > > > > I would like to submit the following draft to the IESG for > > consideration as a Informational RFC: > > > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr > wk-02.txt > > > > My AD-evaluation comments (I understand that a lot of it is > admin/bureaucratic, but you basically knew that and it is always best > to avoid such comments at this late stage).: > > 1. Title and abstract contain Acronyms that RFC-Editor no > longer want to see. You have to expand them. > See: http://www.rfc-editor.org/policy.html > > 2. abstract should not have references. You have a [COPS] reference. > I think you can just use RFC 2478 and leave the ref out. > See: http://www.rfc-editor.org/policy.html > > 3. References need to be split in normative and informative references > > 4. You have text in "Conventions used in this document" on MUST > language and such. That is good. Probably better to include it in > the intro section (or at least after the abstract). > But more important, you need to add [RFC-2119] reference to the > references section > > 5. I think it would be good to do some sort of terminology at the > beginning of the intro. Either explain terms like PDP, > PEP, SIP, PRC > (or at least extend the acronym first time it is used). Might also > add a reference to the terminology as per RFC3198 > > 6. You seem to be using (what we call) redmond-characters in a few > places: 2nd para sect 2, sdt para sect 7, may be other places > > 7. Last sect of para 4.1. > Could we add HOW a PDP may sollicit usage feedback/ > > 8. sect 7, 2nd para > Can you ellaborate on what sort of "additional information > must be provided to uniquely identify...." > > 9. Sect 8, can you explain what a "context switch" is? > > 10. Security consideration. > - You must specify one mandatory to implement. > you are now just saying "...protection can be accomplished". > - When you specify the use of IPsec, pls do not just say > "just use IPsec". A clearer statement is needed, > specifying the necessary IPsec selectors (per RFC 2401) > and the way the cryptographically protected endpoints are > related to the authorization model, i.e., who can do what. > Bert From owner-rap@ops.ietf.org Tue Oct 1 16:00:52 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03485 for ; Tue, 1 Oct 2002 16:00:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17wTE2-000PE1-00 for rap-data@psg.com; Tue, 01 Oct 2002 13:02:34 -0700 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 17wTDy-000PDo-00 for rap@ops.ietf.org; Tue, 01 Oct 2002 13:02:30 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g91K2SO26888 for ; Tue, 1 Oct 2002 16:02:28 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Oct 2002 22:02:27 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "Rawlins, Diana" , "Hahn, Scott" , "Mark Stevens (E-mail)" Cc: "Rap-wg (E-mail)" Subject: AD review of draft-ietf-rap-feedback-fr-pib-03.txt Date: Tue, 1 Oct 2002 22:02:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=2.2 required=5.0 tests=DOUBLE_CAPSWORD,PORN_10,PORN_3 version=2.31 X-Spam-Level: ** Sender: owner-rap@ops.ietf.org Precedence: bulk I am addressing Diana, assuming other co-authors/editors will see the copy on the RAP wg mailing list. I had already commented: > > the following draft to the IESG for consideration as a > > standards track RFC: > > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr-pib-03.txt > >The 2nd one I still need to review, will try to post later today or >tomorrow. Sorry... took some more time > My main question is if we want to go through a similar process as we did > for the earlier PIBs, or if the WG rather decides that this PIB can be > also informational, just as the Framework PIB and the Diffserv PIB. > The discussion with WG chair and my co-AD leaves me at the position that I will not consider the PIB for STDs track, but instead will handle it for Informational, with the same concerns as reaised with earlier PIBs. That situation has not changed. Further comments to this document: - mmm.. the module-identity is named: feedbackPolFrameworkPib then all the rest of the PIB objects/classes/attrs are prefixed with frwkFeedback. WOuld it no be best to keep the prefix of the MIB module and the others the same. - I am missing a REVISION clause in the MODULE-IDENTITY macro - I do not think that labels for enumerations canstart with Uppercase and have underscores - In some cases I see in a description clause of a table or entry "class", or sometimes "table" or sometimes "pri" or "prc"... I would strongly recommend to stick to one term and use that. We had similar problems back when we reviewed diffserv and framework PIBs. Pls check with those and use same terminology. - frwkFeedbackActionListEntry in desxription clause: "This class identifies a set of linkage instances..." mmm.. I guess the table defines a "set", but am entry is one instance of the class, no? probably just language. - Not sure if it is me, but I do not understand the DESCRIPTION clauses of frwkFeedbackActionListGroup and frwkFeedbackActionListRefID How does that work? Can you be more elaborate so I can understand - can you explain (in the description clause) how the seOID is used for the selection process for object/attribute frwkFeedbackSelUsageComboCapsSelection - Is the example code in description clause of frwkFeedbackTrafficThresholdTable actually C code or is it pseudo code? And where do these fields that you are checking come from ?? Is NULL a NULL ptr or the zero value? Would be best to be clear on those questions. - I see: frwkFeedbackTrafficUsagePacketCount OBJECT-TYPE SYNTAX Counter64 STATUS current DESCRIPTION "The count of packets handled by the associated element during the reporting interval." but a Counter64 has Counter64 semantics and has nothing to do with an interval. See RFC2578 definition of Counter64. - A bit later in the PIB you do so again, e.g. another occurance - I see no MODULE COMPLIANCE statement in the PIB !!?? - the security considerations section does not prescribe which of the possible security mechanisms MUST be supported. But possibly is met by the specs RFC2748 and 3084. If you agree, then you should instead say that that is the case and point to those RFCs as normative references. But the security section needs to list details about which classes and or attributes are sensitive and why. Security ADs will look for that. - and last but not least, sending this to SMILINT for a compile check I get a very long list of errors and warnings. Probably some are no problem.. but I see that quite a few are srious problems. Please fix. How can the WG have aggreed that this PIB doc is ready for consideration as PS ?? admin/bureaucratic/editorial/nits: - there are so called Redmond characters (e.g. non-ascii) in th text. Pls fix to plain ascii - RFC Editor does not want acronyms in title and/or abstract See: http://www.rfc-editor.org/policy.html - I think it is more commom to have the "conventions used in this document" (that is the use of MUST language and such) after the TOC - in the example on page 8-0, you use xxxEntry and xxx PRC terminology Might be better to choose one and stick to that, no? - sect 3.2 at the end (i.e. top of page 10) missing 2) ?? - would be good to add WG mailing list infor in CONTACT info I also see only 4 of the 5 authors in the contact info. that is fine with me... but ?? - frwkFeedbackActionEntry has in description: "An instance of this class can indicates a action...' proper english? - references must be split in normative and informative, again see: http://www.rfc-editor.org/policy.html - I see no IANA considerations to request assignment of the PIB oid - I am missing an IPR section as per RFC2026 sect 10. Bert -----Original Message----- From: smilint@ibr.cs.tu-bs.de [mailto:smilint@ibr.cs.tu-bs.de] Sent: dinsdag 1 oktober 2002 21:21 To: Wijnen, Bert (Bert) Subject: Re: check feedback pib rev 03 output of smilint -l 9 follows, empty output means everything is fine. --start-- 6: identifier `ExtUTCTime' cannot be imported from module `COPS-PR-SPPI' 105: identifier `SUSPEND_USAGE_MONITORING_AND_REPORTS' must not contain an underscore 105: parse error, unexpected UPPERCASE_IDENTIFIER, expecting LOWERCASE_IDENTIFIER 106: identifier `SUSPEND_REPORTS_ONLY' must not contain an underscore 108: identifier `RESUME_USAGE_AND_REPORTING' must not contain an underscore 109: identifier `SOLICIT_USAGE_REPORT_NOW' must not contain an underscore 110: warning: flushing recent incorrect declaration, see previous error(s) 111: parse error, unexpected STATUS 122: warning: flushing recent incorrect declaration, see previous error(s) 215: warning: object identifier name `frwkFeedbackSelUsageComboCapsTable' longer than 32 characters 225: warning: object identifier name `frwkFeedbackSelUsageComboCapsEntry' longer than 32 characters 241: warning: type name `FrwkFeedbackSelUsageComboCapsEntry' longer than 32 characters 257: warning: object identifier name `frwkFeedbackSelUsageComboCapsSelection' longer than 32 characters 265: warning: object identifier name `frwkFeedbackSelUsageComboCapsUsage' longer than 32 characters 275: warning: object identifier name `frwkFeedbackSelUsageComboCapsThreshold' longer than 32 characters 289: parse error, unexpected UPPERCASE_IDENTIFIER, expecting LOWERCASE_IDENTIFIER 296: warning: flushing recent incorrect declaration, see previous error(s) 399: warning: object identifier name `frwkFeedbackTrafficThresholdTable' longer than 32 characters 401: parse error, unexpected UPPERCASE_IDENTIFIER, expecting LOWERCASE_IDENTIFIER 420: warning: flushing recent incorrect declaration, see previous error(s) 422: warning: object identifier name `frwkFeedbackTrafficThresholdEntry' longer than 32 characters 432: warning: type name `FrwkFeedbackTrafficThresholdEntry' longer than 32 characters 434: SPPI basetype `Integer64' must be imported from COPS-PR-SPPI 435: SPPI basetype `Integer64' must be imported from COPS-PR-SPPI 446: warning: object identifier name `frwkFeedbackTrafficThresholdPacketThreshold' longer than 32 characters 448: SPPI basetype `Integer64' must be imported from COPS-PR-SPPI 455: warning: object identifier name `frwkFeedbackTrafficThresholdByteThreshold' longer than 32 characters 457: SPPI basetype `Integer64' must be imported from COPS-PR-SPPI 518: warning: object identifier name `frwkFeedbackTrafficUsageLinkRefID' longer than 32 characters 528: warning: object identifier name `frwkFeedbackTrafficUsagePacketCount' longer than 32 characters 538: warning: object identifier name `frwkFeedbackTrafficUsageByteCount' longer than 32 characters 594: warning: object identifier name `frwkFeedbackIfTrafficUsageLinkRefID' longer than 32 characters 603: warning: object identifier name `frwkFeedbackIfTrafficUsageIfIndex' longer than 32 characters 613: warning: object identifier name `frwkFeedbackIfTrafficUsagePacketCount' longer than 32 characters 621: warning: object identifier name `frwkFeedbackIfTrafficUsageByteCount' longer than 32 characters 641: warning: object identifier name `frwkFeedbackRoleComboFilterSelTable' longer than 32 characters 651: warning: object identifier name `frwkFeedbackRoleComboFilterSelEntry' longer than 32 characters 666: warning: type name `FrwkFeedbackRoleComboFilterSelEntry' longer than 32 characters 682: warning: object identifier name `frwkFeedbackRoleComboFilterSelRoleComboRefID' longer than 32 characters 692: warning: object identifier name `frwkFeedbackRoleComboFilterSelBaseFilterRefID' longer than 32 characters 701: warning: object identifier name `frwkFeedbackRoleComboFilterSelIP-802FilterRefID' longer than 32 characters 54: unknown object identifier label `pib' 16: node's parent node must be simple node 87: warning: SEQUENCE element #4 `frwkFeedbackActionList' is not a child node under `frwkFeedbackActionEntry' 89: unknown object identifier label `frwkFeedbackActionIndicator' 136: type `TagReferenceId' of node `frwkFeedbackActionList' does not resolve to a known base type 191: type `TagId' of node `frwkFeedbackActionListGroup' does not resolve to a known base type 298: row's parent node must be a table node 327: type `Prid' of node `frwkFeedbackLinkSel' does not resolve to a known base type 308: unknown object identifier label `frwkFeedbackLinkTable' 359: type `Prid' of node `frwkFeedbackLinkThreshold' does not resolve to a known base type 430: unknown object identifier label `frwkFeedbackTrafficThresholdTable' 422: row's parent node must be a table node 684: unknown object identifier label `frwkRoleComboEntry' 694: unknown object identifier label `frwkBaseFilterEntry' 703: unknown object identifier label `frwkIpFilterEntry' 94: warning: attribute `frwkFeedbackActionId' must be contained in at least one conformance group 124: warning: attribute `frwkFeedbackActionSpecificPri' must be contained in at least one conformance group 136: warning: attribute `frwkFeedbackActionList' must be contained in at least one conformance group 191: warning: attribute `frwkFeedbackActionListGroup' must be contained in at least one conformance group 182: warning: attribute `frwkFeedbackActionListId' must be contained in at least one conformance group 199: warning: attribute `frwkFeedbackActionListRefID' must be contained in at least one conformance group 248: warning: attribute `frwkFeedbackSelUsageComboCapsId' must be contained in at least one conformance group 257: warning: attribute `frwkFeedbackSelUsageComboCapsSelection' must be contained in at least one conformance group 265: warning: attribute `frwkFeedbackSelUsageComboCapsUsage' must be contained in at least one conformance group 275: warning: attribute `frwkFeedbackSelUsageComboCapsThreshold' must be contained in at least one conformance group 319: warning: attribute `frwkFeedbackLinkId' must be contained in at least one conformance group 327: warning: attribute `frwkFeedbackLinkSel' must be contained in at least one conformance group 338: warning: attribute `frwkFeedbackLinkUsage' must be contained in at least one conformance group 347: warning: attribute `frwkFeedbackLinkInterval' must be contained in at least one conformance group 359: warning: attribute `frwkFeedbackLinkThreshold' must be contained in at least one conformance group 368: warning: attribute `frwkFeedbackLinkFlags' must be contained in at least one conformance group 438: warning: attribute `frwkFeedbackTrafficThresholdId' must be contained in at least one conformance group 446: warning: attribute `frwkFeedbackTrafficThresholdPacketThreshold' must be contained in at least one conformance group 455: warning: attribute `frwkFeedbackTrafficThresholdByteThreshold' must be contained in at least one conformance group 510: warning: attribute `frwkFeedbackTrafficUsageId' must be contained in at least one conformance group 518: warning: attribute `frwkFeedbackTrafficUsageLinkRefID' must be contained in at least one conformance group 528: warning: attribute `frwkFeedbackTrafficUsagePacketCount' must be contained in at least one conformance group 538: warning: attribute `frwkFeedbackTrafficUsageByteCount' must be contained in at least one conformance group 586: warning: attribute `frwkFeedbackIfTrafficUsageId' must be contained in at least one conformance group 594: warning: attribute `frwkFeedbackIfTrafficUsageLinkRefID' must be contained in at least one conformance group 603: warning: attribute `frwkFeedbackIfTrafficUsageIfIndex' must be contained in at least one conformance group 613: warning: attribute `frwkFeedbackIfTrafficUsagePacketCount' must be contained in at least one conformance group 621: warning: attribute `frwkFeedbackIfTrafficUsageByteCount' must be contained in at least one conformance group 674: warning: attribute `frwkFeedbackRoleComboFilterSelId' must be contained in at least one conformance group 682: the PIB-REFERENCES does not point to a row 682: warning: attribute `frwkFeedbackRoleComboFilterSelRoleComboRefID' must be contained in at least one conformance group 692: the PIB-REFERENCES does not point to a row 692: warning: attribute `frwkFeedbackRoleComboFilterSelBaseFilterRefID' must be contained in at least one conformance group 701: the PIB-REFERENCES does not point to a row 701: warning: attribute `frwkFeedbackRoleComboFilterSelIP-802FilterRefID' must be contained in at least one conformance group 92: unknown type `TagReferenceId' 178: unknown type `TagId' 312: unknown type `Prid' 4: warning: identifier `Unsigned32' imported from module `COPS-PR-SPPI' is never used 4: warning: identifier `Unsigned64' imported from module `COPS-PR-SPPI' is never used 7: warning: identifier `TEXTUAL-CONVENTION' imported from module `SNMPv2-TC' is never used --end-- From owner-rap@ops.ietf.org Wed Oct 9 08:34:53 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12845 for ; Wed, 9 Oct 2002 08:34:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17zG3T-0009nJ-00 for rap-data@psg.com; Wed, 09 Oct 2002 05:35:11 -0700 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 17zG3Q-0009n7-00 for rap@ops.ietf.org; Wed, 09 Oct 2002 05:35:08 -0700 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 g99CZ6501930 for ; Wed, 9 Oct 2002 08:35:06 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 14:35:01 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: "'Rawlins, Diana'" , "'Hahn, Scott'" , "'Mark Stevens (E-mail)'" Cc: "'Rap-wg (E-mail)'" Subject: RE: AD-review of draft-ietf-rap-feedback-frwk-02.txt Date: Wed, 9 Oct 2002 14:34:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-5.2 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk Oh well... sometimes people complain (sometimes even rightfully so) about the AD not reacting fast enough.... So can I now start to (rightfully) complain that authors and wg are not reacting fast enough? Has interest been lost? If so, we can remove this work topic from the WG charter. Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: dinsdag 1 oktober 2002 21:14 > To: Rawlins, Diana; 'Wijnen, Bert (Bert)'; Hahn, Scott; Mark Stevens > (E-mail) > Cc: Rap-wg (E-mail) > Subject: AD-review of draft-ietf-rap-feedback-frwk-02.txt > > > Sofar, I never heard anything back on this email > > Thanks, > Bert > > > -----Original Message----- > > From: Rawlins, Diana [mailto:Diana.Rawlins@wcom.com] > > Sent: dinsdag 20 augustus 2002 17:39 > > To: 'Wijnen, Bert (Bert)'; Hahn, Scott; Mark Stevens (E-mail) > > Cc: Rap-wg (E-mail) > > Subject: RE: Request to advance drafts > > > > > > I will work with the other authors to address the below > > comments and with > > the WG chair on that last question. Thank you for the feedback! > > > > -Diana > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Tuesday, August 20, 2002 9:55 AM > > To: Hahn, Scott; Mark Stevens (E-mail) > > Cc: Rap-wg (E-mail) > > Subject: RE: Request to advance drafts > > > > RAP WG, I got this requestst from your WG chairs. > > > > > > I would like to submit the following draft to the IESG for > > > consideration as a Informational RFC: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-fr > > wk-02.txt > > > > > > > My AD-evaluation comments (I understand that a lot of it is > > admin/bureaucratic, but you basically knew that and it is > always best > > to avoid such comments at this late stage).: > > > > 1. Title and abstract contain Acronyms that RFC-Editor no > > longer want to see. You have to expand them. > > See: http://www.rfc-editor.org/policy.html > > > > 2. abstract should not have references. You have a [COPS] reference. > > I think you can just use RFC 2478 and leave the ref out. > > See: http://www.rfc-editor.org/policy.html > > > > 3. References need to be split in normative and informative > references > > > > 4. You have text in "Conventions used in this document" on MUST > > language and such. That is good. Probably better to include it in > > the intro section (or at least after the abstract). > > But more important, you need to add [RFC-2119] reference to the > > references section > > > > 5. I think it would be good to do some sort of terminology at the > > beginning of the intro. Either explain terms like PDP, > > PEP, SIP, PRC > > (or at least extend the acronym first time it is used). > Might also > > add a reference to the terminology as per RFC3198 > > > > 6. You seem to be using (what we call) redmond-characters in a few > > places: 2nd para sect 2, sdt para sect 7, may be other places > > > > 7. Last sect of para 4.1. > > Could we add HOW a PDP may sollicit usage feedback/ > > > > 8. sect 7, 2nd para > > Can you ellaborate on what sort of "additional information > > must be provided to uniquely identify...." > > > > 9. Sect 8, can you explain what a "context switch" is? > > > > 10. Security consideration. > > - You must specify one mandatory to implement. > > you are now just saying "...protection can be accomplished". > > - When you specify the use of IPsec, pls do not just say > > "just use IPsec". A clearer statement is needed, > > specifying the necessary IPsec selectors (per RFC 2401) > > and the way the cryptographically protected endpoints are > > related to the authorization model, i.e., who can do what. > > > Bert > From owner-rap@ops.ietf.org Fri Oct 18 07:31: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 HAA21553 for ; Fri, 18 Oct 2002 07:31:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182VMh-00088C-00 for rap-data@psg.com; Fri, 18 Oct 2002 04:32:27 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 182VMg-00087z-00 for rap@ops.ietf.org; Fri, 18 Oct 2002 04:32:26 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21373; Fri, 18 Oct 2002 07:30:11 -0400 (EDT) Message-Id: <200210181130.HAA21373@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-frwk-03.txt Date: Fri, 18 Oct 2002 07:30:11 -0400 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 Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) Author(s) : D. Rawlins, A. Kulkarni Filename : draft-ietf-rap-feedback-frwk-03.txt Pages : 8 Date : 2002-10-17 Common Open Policy Services Protocol [COPS], RFC 2748, defined the capability of reporting information to the PDP. The types of report information are success, failure and accounting of an installed state. This document focuses on the COPS Report Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-feedback-frwk-03.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-frwk-03.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-frwk-03.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-10-17150011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-feedback-frwk-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-feedback-frwk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17150011.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Fri Oct 18 07:31:27 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21567 for ; Fri, 18 Oct 2002 07:31:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 182VMq-00088Q-00 for rap-data@psg.com; Fri, 18 Oct 2002 04:32:36 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 182VMo-00088E-00 for rap@ops.ietf.org; Fri, 18 Oct 2002 04:32:34 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21391; Fri, 18 Oct 2002 07:30:16 -0400 (EDT) Message-Id: <200210181130.HAA21391@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-04.txt Date: Fri, 18 Oct 2002 07:30:15 -0400 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-04.txt Pages : 28 Date : 2002-10-17 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-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-rsvp-authsession-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-rsvp-authsession-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-10-17150022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-rsvp-authsession-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-rsvp-authsession-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17150022.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-rap@ops.ietf.org Tue Oct 22 12:44:00 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25612 for ; Tue, 22 Oct 2002 12:44:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18429O-000Kfk-00 for rap-data@psg.com; Tue, 22 Oct 2002 09:45:02 -0700 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by psg.com with esmtp (Exim 3.36 #2) id 18429L-000Ken-00 for rap@ops.ietf.org; Tue, 22 Oct 2002 09:44:59 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9MGiQH11287 for ; Tue, 22 Oct 2002 12:44:27 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 12:44:27 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C04387FFA@zcard031.ca.nortel.com> From: "Louis-Nicolas Hamer" To: rap@ops.ietf.org Subject: draft-ietf-rap-rsvp-authsession-04.txt Date: Tue, 22 Oct 2002 12:44:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C279EA.48A32FBC" X-Spam-Status: No, hits=-1.9 required=5.0 tests=EXCHANGE_SERVER,MIME_NULL_BLOCK,SPAM_PHRASE_02_03 version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C279EA.48A32FBC Content-Type: text/plain All, As you may have seen, a new revision of the AUTH_SESSION draft was submitted. The new revision was done to address the comments raised during IESG review, specifically from the Security AD - Steven Bellovin. Here is a summary of the comments received from the Security AD: -Lack of detail regarding the security mechanisms described in the draft. Concerns that this lack of detail may not allow implementers to build interoperable systems. Here is a summary of the changes. - Terminology: Change the use of "shared private keys" to "shared symmetric keys" - Section 4.2: Kerberos - Added more details on how to use Kerberos to ensure the integrity of the token. - Added Sub-Section 4.3.1.1: X.509 V3 digital certificates. This sub-section was added to provide the details on how to use X.509 V3 digital certificates to ensure the integrity of the token. - Added Sub-Section 4.3.1.2: PGP Digital Certificates. This sub-section was added to provide the details on how to use PGP digital certificates to ensure the integrity of the token. - Added more details in section 6: Message processing rules. Basically, provided better guidance. - Changed the title of the draft to "Session authorization Policy Element". This title is much more appropriate since this document's main goal is the describe the AUTH_SESSION Policy Element. - Security considerations section: Specified the need for NTP in the non-associated model to ensure proper clock synchronization. - Clarified that fields of subtype UNICODE_DN are X.500 Distinguished name as defined in RFC-2253 as a UTF-8 string. We worked directly with Steven to make sure we successfully addressed all of his concerns - thanks to Bert for facilitating this interaction. Thanks also to Eric Rescorla for providing security advice. Cheers, Louis-Nicolas ------_=_NextPart_001_01C279EA.48A32FBC Content-Type: text/html Content-Transfer-Encoding: quoted-printable draft-ietf-rap-rsvp-authsession-04.txt

All,

As you may have seen, a new revision = of the AUTH_SESSION draft was submitted. The new revision was = done
to address the comments raised during = IESG review, specifically from the Security AD - Steven = Bellovin.

Here is a summary of the comments = received from the Security AD:
-Lack of detail regarding the = security mechanisms described in the draft. Concerns that this lack of = detail
may not allow implementers to build = interoperable systems.

Here is a summary of the = changes.

- Terminology: Change the use of = "shared private keys" to "shared symmetric = keys"
- Section 4.2: Kerberos - Added = more details on how to use Kerberos to ensure the integrity of the = token.
- Added Sub-Section = 4.3.1.1: X.509 V3 digital = certificates. This sub-section was added to provide the details on how = to use

X.509 V3 digital certificates to = ensure the integrity of the token.
- Added Sub-Section 4.3.1.2: PGP = Digital Certificates. This sub-section was added to provide the details = on how to use PGP

digital certificates to ensure the = integrity of the token.
- Added more details in section 6: = Message processing rules. Basically, provided better guidance.
- Changed the title of the draft to = "Session authorization Policy Element". This title is much = more appropriate since this document's

main goal is the describe the = AUTH_SESSION Policy Element.
- Security considerations section: = Specified the need for NTP in the non-associated model to ensure proper = clock synchronization.

- Clarified that fields of subtype = UNICODE_DN are X.500 Distinguished name as defined in RFC-2253 as a = UTF-8 string.

We worked directly with Steven to make = sure we successfully addressed all of his concerns - thanks to Bert for = facilitating

this interaction. Thanks also to Eric = Rescorla for providing security advice.

Cheers,
Louis-Nicolas

------_=_NextPart_001_01C279EA.48A32FBC-- From owner-rap@ops.ietf.org Wed Oct 23 08:36:29 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15912 for ; Wed, 23 Oct 2002 08:36:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184Kk2-0009vj-00 for rap-data@psg.com; Wed, 23 Oct 2002 05:36:06 -0700 Received: from [202.8.94.186] (helo=bumper.sytes.net) by psg.com with esmtp (Exim 3.36 #2) id 184Kjz-0009th-00 for rap@ops.ietf.org; Wed, 23 Oct 2002 05:36:04 -0700 Received: (from lhyuan@localhost) by bumper.sytes.net (8.11.6/8.11.6) id g9NCcXe06375; Wed, 23 Oct 2002 20:38:33 +0800 Date: Wed, 23 Oct 2002 20:38:33 +0800 Message-Id: <200210231238.g9NCcXe06375@bumper.sytes.net> From: Yuan Lihua To: rap@ops.ietf.org Subject: SNMP/MIB v.s. COPS/PIB X-Spam-Status: No, hits=-1.4 required=5.0 tests=SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi, I am trying to understand the differences between using SNMP/MIB for general network management and using COPS/PIB for QoS provisioning. After reading through the RFCs and drafts, I am just getting more and more confused. My question is "Isn't QoS provisioning is a case of network management?" Some Cisco router does even have a QoS MIB, so why can't one use SNMP to manage a network device and therefore provide admission control? Thanks and best regards Lihua -- The man who finds his homeland sweet is still a tender beginner; he to whom every soil is as his native one is already strong; but he is perfect to whom the entire world is as a foreign land. From owner-rap@ops.ietf.org Wed Oct 23 11:37:41 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17806 for ; Wed, 23 Oct 2002 11:37:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184NbT-000HGs-00 for rap-data@psg.com; Wed, 23 Oct 2002 08:39:27 -0700 Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by psg.com with esmtp (Exim 3.36 #2) id 184Nax-000HGB-00 for rap@ops.ietf.org; Wed, 23 Oct 2002 08:38:55 -0700 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA01758; Wed, 23 Oct 2002 11:50:45 -0400 (EDT) Received: from unknown(134.141.77.96) by ctron-dnm.enterasys.com via smap (4.1) id xma001735; Wed, 23 Oct 02 11:50:13 -0400 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Oct 2002 11:32:46 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA075877@NHROCMBX1.ets.enterasys.com> From: "Harrington, David" To: "'Yuan Lihua'" , rap@ops.ietf.org Subject: RE: SNMP/MIB v.s. COPS/PIB Date: Wed, 23 Oct 2002 11:38:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27AAA.3DC442DF" X-Spam-Status: No, hits=-5.4 required=5.0 tests=EXCHANGE_SERVER,MAILTO_LINK,MIME_NULL_BLOCK, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27AAA.3DC442DF Content-Type: text/plain Hi Lihua, Don't feel bad; everybody's confused about how configuration management fits into the overall network management picture. Some people believe SNMP and MIBs can provide sufficient capabilities to do IP-based configuration. The SnmpConf WG has developed a solution using SNMP. Some people believe a special-purpose protocol and special-purpose templates are needed to meet the requirements. The RAP WG has developed a solution using COPS/PR and PIBs. Some people believe either approach could work, but each has advantages and disadvantages. RFC3139 describes the requirements of IP-based configuration that drove the designs used by these two working groups. Some people believe neither approach really meets the needs of operators for doing IP-based configuration, and the requirements used are wrong. There are a number of efforts underway to better understand the requirements of configuration. An internet draft was written describing the conclusions reached during a "world tour" to determine operator requirements for configuration (now expired), and the IAB held a workshop during the summer to discuss this issue (see draft-iab-nm-workshop-00). There are no definitive answers as to the correct approach. dbh --- David Harrington dbh@enterasys.com co-chair, IETF SNMPv3 WG > -----Original Message----- > From: Yuan Lihua [mailto:lhyuan@bumper.sytes.net] > Sent: Wednesday, October 23, 2002 8:39 AM > To: rap@ops.ietf.org > Subject: SNMP/MIB v.s. COPS/PIB > > > Hi, > > I am trying to understand the differences between using SNMP/MIB > for general network management and using COPS/PIB for QoS > provisioning. After reading through the RFCs and drafts, I am > just getting more and more confused. My question is "Isn't QoS > provisioning is a case of network management?" Some Cisco router > does even have a QoS MIB, so why can't one use SNMP to manage a > network device and therefore provide admission control? > > Thanks and best regards > > Lihua > > -- > The man who finds his homeland sweet is still a tender beginner; > he to whom every soil is as his native one is already strong; > > but he is perfect to whom the entire world is as a foreign land. > ------_=_NextPart_001_01C27AAA.3DC442DF Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SNMP/MIB v.s. COPS/PIB

Hi Lihua,

Don't feel bad; everybody's confused about how = configuration management fits into the overall network management = picture.

Some people believe SNMP and MIBs can provide = sufficient capabilities to do IP-based configuration. The SnmpConf WG = has developed a solution using SNMP.

Some people believe a special-purpose protocol and = special-purpose templates are needed to meet the requirements. The RAP = WG has developed a solution using COPS/PR and PIBs.

Some people believe either approach could work, but = each has advantages and disadvantages.

RFC3139 describes the requirements of IP-based = configuration that drove the designs used by these two working = groups.

Some people believe neither approach really meets the = needs of operators for doing IP-based configuration, and the = requirements used are wrong. There are a number of efforts underway to = better understand the requirements of configuration. An internet draft = was written describing the conclusions reached during a "world = tour" to determine operator requirements for configuration (now = expired), and the IAB held a workshop during the summer to discuss this = issue (see draft-iab-nm-workshop-00).

There are no definitive answers as to the correct = approach.

dbh
---
David = Harrington &n= bsp;
dbh@enterasys.com &nbs= p;
co-chair, IETF SNMPv3 WG

> -----Original Message-----
> From: Yuan Lihua [mailto:lhyuan@bumper.sytes.net]
> Sent: Wednesday, October 23, 2002 8:39 = AM
> To: rap@ops.ietf.org
> Subject: SNMP/MIB v.s. COPS/PIB
>
>
> Hi,
>
>     I am trying to = understand the differences between using SNMP/MIB
>     for general network = management and using COPS/PIB for QoS
>     provisioning. = After reading through the RFCs and drafts, I am
>     just getting more and = more confused. My question is "Isn't QoS
>     provisioning is a case = of network management?" Some Cisco router
>     does even have a QoS = MIB, so why can't one use SNMP to manage a
>     network device and = therefore provide admission control?
>
>     Thanks and best = regards
>
> Lihua
>
> --
> The man who finds his homeland sweet is still a = tender beginner;
> he to whom every soil is as his native one is = already strong;
>
> but he is perfect to whom the entire world is = as a foreign land.
>

------_=_NextPart_001_01C27AAA.3DC442DF-- From owner-rap@ops.ietf.org Wed Oct 23 23:30:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15406 for ; Wed, 23 Oct 2002 23:30:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #2) id 184YhA-000H2V-00 for rap-data@psg.com; Wed, 23 Oct 2002 20:30:04 -0700 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 184Yh6-000H1m-00 for rap@ops.ietf.org; Wed, 23 Oct 2002 20:30:00 -0700 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id g9O3TnR6028920 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 24 Oct 2002 05:29:49 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g9O3Tnt3025816 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Thu, 24 Oct 2002 05:29:49 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id g9O3TmjD025813; Thu, 24 Oct 2002 05:29:48 +0200 Date: Thu, 24 Oct 2002 05:29:48 +0200 Message-Id: <200210240329.g9O3TmjD025813@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: lhyuan@bumper.sytes.net CC: rap@ops.ietf.org In-reply-to: <200210231238.g9NCcXe06375@bumper.sytes.net> (message from Yuan Lihua on Wed, 23 Oct 2002 20:38:33 +0800) Subject: Re: SNMP/MIB v.s. COPS/PIB References: <200210231238.g9NCcXe06375@bumper.sytes.net> X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03 version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Yuan Lihua writes: Yuan> I am trying to understand the differences between using SNMP/MIB Yuan> for general network management and using COPS/PIB for QoS Yuan> provisioning. After reading through the RFCs and drafts, I am Yuan> just getting more and more confused. My question is "Isn't QoS Yuan> provisioning is a case of network management?" Some Cisco Yuan> router does even have a QoS MIB, so why can't one use SNMP to Yuan> manage a network device and therefore provide admission control? There are some issues with SNMP that increase implementation costs, especially if you do not have smart tools. COPS tries to address some of them. However, the question whether the COPS proposal and its new features (compared to SNMP) are sufficient to justify the addition of a new protocol has been an interesting controversy within the IETF. And if we listen to network operators that attended the various meetings during last year where IETF folks wanted to collect requirements, then we hear that neither SNMP (as is) nor COPS (as is) satisfies their requirements. For further reading on the technical differences, see http://www.ibr.cs.tu-bs.de/~schoenw/papers/policy-tr-00-02.ps.gz /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Tue Oct 29 17:02:13 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28804 for ; Tue, 29 Oct 2002 17:02:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186eQl-00013s-00 for rap-data@psg.com; Tue, 29 Oct 2002 14:01:47 -0800 Received: from momus.sc.intel.com ([143.183.152.8]) by psg.com with esmtp (Exim 3.36 #2) id 186eQZ-000116-00 for rap@ops.ietf.org; Tue, 29 Oct 2002 14:01:45 -0800 Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by momus.sc.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.48 2002/10/16 23:47:34 dmccart Exp $) with SMTP id g9TM0iP05262 for ; Tue, 29 Oct 2002 22:00:54 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002102914004119354 ; Tue, 29 Oct 2002 14:00:41 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Oct 2002 14:00:29 -0800 Message-ID: From: "Hahn, Scott" To: rap@ops.ietf.org Cc: "Bert Wijnen (Bert) (bwijnen@lucent.com)" , "Mark L. Stevens (mlstevens@rcn.com)" Subject: No RAP meeting in Atlanta Date: Tue, 29 Oct 2002 13:59:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 All, After some discussion with the authors of the current RAP drafts, I have decided not to ask for a RAP session at the upcoming Atlanta IETF meeting. I have attached the list of current drafts and their status below. I believe that the current set of drafts are progressing without any major open issues at the moment. The authors of the Access Bind PIB and the COPS Framework drafts are diligently working on the drafts, but did not feel that there was enough progress made at this point to merit a session in Atlanta. I expect we will discuss these drafts at the next meeting in San Francisco. Until then I would encourage the use of the mailing list for any and all issues. Thanks. -Scott Hahn Here is the current status of WG drafts (please correct me if I have made any mistakes): **The following drafts are currently in the RFC editors queue: Framework Policy Information Base (Note that the Diffserv PIB is also going through this mode) **The following drafts have gone through WG last call and are currently finalizing with Bert before IESG last call: Session Authorization for RSVP (Comments from the IESG have been addressed) Framework for session set-up with media authorization (Comments from the IESG have been addressed) Framework of COPS-PR Policy Usage Feedback Framework of COPS-PR Policy Information Base for Policy Usage Feedback **The following drafts are progressing without issue: RSVP Policy Control Criteria PIB COPS over TLS (needs security review) **These 2 drafts are potential discussion points: Framework for Binding Access Control to COPS Provisioning An Architecture for COPS Based Policy Control Management Framework From owner-rap@ops.ietf.org Wed Oct 30 05:50:38 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07794 for ; Wed, 30 Oct 2002 05:50:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186qSL-000JUn-00 for rap-data@psg.com; Wed, 30 Oct 2002 02:52:13 -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 186qSH-000JTk-00 for rap@ops.ietf.org; Wed, 30 Oct 2002 02:52:09 -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 g9UAq4U16869 for ; Wed, 30 Oct 2002 05:52:04 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 11:52:03 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: Louis-Nicolas Hamer Cc: "Rap-wg (E-mail)" Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents Date: Wed, 30 Oct 2002 11:52:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28002.5F33E884" X-Spam-Status: No, hits=-4.8 required=5.0 tests=EXCHANGE_SERVER,HTML_FONT_COLOR_BLUE,MAILTO_LINK, MIME_NULL_BLOCK,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28002.5F33E884 Content-Type: text/plain I think we have cleared all hurdles... formal announcement is to come from iesg secretary any day now (or so I expect). Thanks, Bert -----Original Message----- From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] Sent: vrijdag 18 oktober 2002 17:26 To: 'Wijnen, Bert (Bert)' Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents ok - thanks. I will wait for further instructions. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, October 18, 2002 10:37 AM To: Hamer, Louis-Nicolas [CAR:AN22:EXCH] Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents I will try to get it approved asap. But it may take till Okt 31 Thanks, Bert -----Original Message----- From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com] Sent: vrijdag 18 oktober 2002 16:16 To: 'Wijnen, Bert (Bert)' Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents Hi Bert, What should I expect next? When will the IESG decision be final so that I can contact IANA? That sort of stuff... Any advice will be greatly appreciated. Thanks, L-N -----Original Message----- From: Wijnen, Bert (Bert) [ mailto:bwijnen@lucent.com ] Sent: Thursday, October 17, 2002 12:35 AM To: Steven M. Bellovin; Hamer, Louis-Nicolas [CAR:AN22:EXCH] Cc: 'Wijnen, Bert (Bert)'; Eric Rescorla (E-mail) Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents Thanks Steve. So Louis, pls submit the new I-D to internet-drafts@ietf.org asap. Thanks, Bert > -----Original Message----- > From: Steven M. Bellovin [ mailto:smb@research.att.com ] > Sent: donderdag 17 oktober 2002 5:32 > To: Louis-Nicolas Hamer > Cc: 'Wijnen, Bert (Bert)'; Eric Rescorla (E-mail) > Subject: Re: FW: draft-ietf-rap-rsvp-authsession documents > > > In message > <9FBD322B7824D511B36900508BF93C9C04387D0F@zcard031.ca.nortel.com>, " > Louis-Nicolas Hamer" writes: > > > > >Bert, Eric, Steve, > > > >I think I correctly answered everything this time (got a > little help from > >Marcus Leech). > >See below for comments. > > > > > > > I believe that my concerns are basically satisfied. I'm not thrilled > with the recommendation to use static key, but... > > Bert, I guess we need a new I-D before I can clear my DISCUSS. > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com ("Firewalls" book) > > ------_=_NextPart_001_01C28002.5F33E884 Content-Type: text/html Message

I think we have cleared all hurdles... formal announcement is to come

from iesg secretary any day now (or so I expect).

Thanks,
Bert

-----Original Message-----
From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com]
Sent: vrijdag 18 oktober 2002 17:26
To: 'Wijnen, Bert (Bert)'
Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents

ok - thanks. I will wait for further instructions.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Friday, October 18, 2002 10:37 AM
To: Hamer, Louis-Nicolas [CAR:AN22:EXCH]
Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents

I will try to get it approved asap. But it may take till Okt 31

Thanks,
Bert

-----Original Message-----
From: Louis-Nicolas Hamer [mailto:nhamer@nortelnetworks.com]
Sent: vrijdag 18 oktober 2002 16:16
To: 'Wijnen, Bert (Bert)'
Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents

Hi Bert,

What should I expect next? When will the IESG decision be final so that I can contact IANA?
That sort of stuff...

Any advice will be greatly appreciated.

Thanks,

L-N

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Thursday, October 17, 2002 12:35 AM
To: Steven M. Bellovin; Hamer, Louis-Nicolas [CAR:AN22:EXCH]
Cc: 'Wijnen, Bert (Bert)'; Eric Rescorla (E-mail)
Subject: RE: FW: draft-ietf-rap-rsvp-authsession documents

Thanks Steve. So Louis, pls submit the new I-D to
internet-drafts@ietf.org asap.

Thanks,
Bert

> -----Original Message-----
> From: Steven M. Bellovin [mailto:smb@research.att.com]
> Sent: donderdag 17 oktober 2002 5:32
> To: Louis-Nicolas Hamer
> Cc: 'Wijnen, Bert (Bert)'; Eric Rescorla (E-mail)
> Subject: Re: FW: draft-ietf-rap-rsvp-authsession documents
>
>
> In message
> <9FBD322B7824D511B36900508BF93C9C04387D0F@zcard031.ca.nortel.com>, "
> Louis-Nicolas Hamer" writes:
> >
>
> >Bert, Eric, Steve,
> >
> >I think I correctly answered everything this time (got a
> little help from
> >Marcus Leech).
> >See below for comments.
> >
> >
>
>
> I believe that my concerns are basically satisfied. I'm not thrilled
> with the recommendation to use static key, but...
>
> Bert, I guess we need a new I-D before I can clear my DISCUSS.
>
> --Steve Bellovin, http://www.research.att.com/~smb (me)
> http://www.wilyhacker.com ("Firewalls" book)
>
>

------_=_NextPart_001_01C28002.5F33E884-- From owner-rap@ops.ietf.org Wed Oct 30 08:46: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 IAA14617 for ; Wed, 30 Oct 2002 08:46:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186tCZ-0001HC-00 for rap-data@psg.com; Wed, 30 Oct 2002 05:48:07 -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 186tCX-0001Fs-00 for rap@ops.ietf.org; Wed, 30 Oct 2002 05:48:05 -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 g9UDlYt18529 for ; Wed, 30 Oct 2002 08:47:34 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 14:47:33 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Hahn, Scott" , rap@ops.ietf.org Cc: "Mark L. Stevens (mlstevens@rcn.com)" Subject: RE: No RAP meeting in Atlanta Date: Wed, 30 Oct 2002 14:47:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-5.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk thanks for the update. W.r.t. > **The following drafts are progressing without issue: > RSVP Policy Control Criteria PIB > COPS over TLS (needs security review) I am not sure if they are on my plate or still in the WG, but I believe they are still in WG. Can you pls clarify if that is in sync with your view. Thanks, Bert > -----Original Message----- > From: Hahn, Scott [mailto:scott.hahn@intel.com] > Sent: dinsdag 29 oktober 2002 23:00 > To: rap@ops.ietf.org > Cc: Bert Wijnen (Bert) (bwijnen@lucent.com); Mark L. Stevens > (mlstevens@rcn.com) > Subject: No RAP meeting in Atlanta > > > All, > After some discussion with the authors of the current RAP > drafts, I have > decided not to ask for a RAP session at the upcoming Atlanta > IETF meeting. > > I have attached the list of current drafts and their status > below. I believe > that the current set of drafts are progressing without any > major open issues > at the moment. The authors of the Access Bind PIB and the > COPS Framework > drafts are diligently working on the drafts, but did not feel > that there was > enough progress made at this point to merit a session in > Atlanta. I expect > we will discuss these drafts at the next meeting in San > Francisco. Until > then I would encourage the use of the mailing list for any > and all issues. > > Thanks. > -Scott Hahn > > > Here is the current status of WG drafts (please correct me if > I have made > any mistakes): > > **The following drafts are currently in the RFC editors queue: > Framework Policy Information Base > (Note that the Diffserv PIB is also going through this mode) > > **The following drafts have gone through WG last call and are > currently > finalizing with Bert before IESG last call: > Session Authorization for RSVP (Comments from the IESG have been > addressed) > Framework for session set-up with media authorization > (Comments from > the IESG have been addressed) > Framework of COPS-PR Policy Usage Feedback > Framework of COPS-PR Policy Information Base for Policy Usage > Feedback > > **The following drafts are progressing without issue: > RSVP Policy Control Criteria PIB > COPS over TLS (needs security review) > > **These 2 drafts are potential discussion points: > Framework for Binding Access Control to COPS Provisioning > An Architecture for COPS Based Policy Control > Management Framework > > > > From owner-rap@ops.ietf.org Wed Oct 30 12:32:49 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27628 for ; Wed, 30 Oct 2002 12:32:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186wip-000DUC-00 for rap-data@psg.com; Wed, 30 Oct 2002 09:33:39 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 186win-000DU0-00 for rap@ops.ietf.org; Wed, 30 Oct 2002 09:33:37 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27485; Wed, 30 Oct 2002 12:31:12 -0500 (EST) Message-Id: <200210301731.MAA27485@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , rap@ops.ietf.org From: The IESG Subject: Protocol Action: Session Authorization for RSVP to Proposed Standard Date: Wed, 30 Oct 2002 12:31:12 -0500 X-Spam-Status: No, hits=-0.2 required=5.0 tests=SPAM_PHRASE_00_01,TO_MALFORMED version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk The IESG has approved publication of the following Internet-Drafts: o Session Authorization for RSVP as a Proposed Standard. o Framework for session set-up with media authorization as an Informational RFC. These documents are the product of the Resource Allocation Protocol Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary The "Session Authorization for RSVP" document describes the representation of session authorization information in the POLICY_DATA object [POL-EXT] for supporting policy-based per-session authorization and admission control in RSVP. 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 the RSVP PATH message to facilitate proper and secure reservation of those resources within the network. It describes the encoding of media authorization information as RSVP policy elements and provides details relating to operations, processing rules and error scenarios. The "framework" document describes a framework within which the above session authorization information can be exchanged and used. Working Group Summary The working group has consensus on these documents. Protocol Quality These documents have been reviewed for the IESG by Bert Wijnen. From owner-rap@ops.ietf.org Wed Oct 30 13:23:34 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01773 for ; Wed, 30 Oct 2002 13:23:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186xWy-000GWL-00 for rap-data@psg.com; Wed, 30 Oct 2002 10:25:28 -0800 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #2) id 186xWx-000GW9-00 for rap@ops.ietf.org; Wed, 30 Oct 2002 10:25:27 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01748; Wed, 30 Oct 2002 13:23:00 -0500 (EST) Message-Id: <200210301823.NAA01748@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , rap@ops.ietf.org From: The IESG Subject: Protocol Action: Session Authorization for RSVP to Proposed Standard Date: Wed, 30 Oct 2002 13:23:00 -0500 X-Spam-Status: No, hits=-0.2 required=5.0 tests=SPAM_PHRASE_00_01,TO_MALFORMED version=2.41 Sender: owner-rap@ops.ietf.org Precedence: bulk The IESG has approved publication of the following Internet-Drafts: o Session Authorization for RSVP as a Proposed Standard. o Framework for session set-up with media authorization as an Informational RFC. These documents are the product of the Resource Allocation Protocol Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary The "Session Authorization for RSVP" document describes the representation of session authorization information in the POLICY_DATA object [POL-EXT] for supporting policy-based per-session authorization and admission control in RSVP. 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 the RSVP PATH message to facilitate proper and secure reservation of those resources within the network. It describes the encoding of media authorization information as RSVP policy elements and provides details relating to operations, processing rules and error scenarios. The "framework" document describes a framework within which the above session authorization information can be exchanged and used. Working Group Summary The working group has consensus on these documents. Protocol Quality These documents have been reviewed for the IESG by Bert Wijnen. From owner-rap@ops.ietf.org Wed Oct 30 13:36:01 2002 Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02712 for ; Wed, 30 Oct 2002 13:36:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 186xjB-000HDq-00 for rap-data@psg.com; Wed, 30 Oct 2002 10:38:05 -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 186xj9-000HDQ-00 for rap@ops.ietf.org; Wed, 30 Oct 2002 10:38:03 -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 g9UIbVm05334 for ; Wed, 30 Oct 2002 13:37:31 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 19:37:30 +0100 Message-ID: From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" Subject: FW: Protocol Action: Session Authorization for RSVP to Proposed S tandard Date: Wed, 30 Oct 2002 19:37:29 +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 Thanks to the WG, but specifically to Louis-Nicolas Hamer who was so patient to deal with all the security concerns from the IESG. Bert -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: woensdag 30 oktober 2002 19:23 Cc: RFC Editor; Internet Architecture Board; rap@ops.ietf.org Subject: Protocol Action: Session Authorization for RSVP to Proposed Standard The IESG has approved publication of the following Internet-Drafts: o Session Authorization for RSVP as a Proposed Standard. o Framework for session set-up with media authorization as an Informational RFC. These documents are the product of the Resource Allocation Protocol Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary The "Session Authorization for RSVP" document describes the representation of session authorization information in the POLICY_DATA object [POL-EXT] for supporting policy-based per-session authorization and admission control in RSVP. 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 the RSVP PATH message to facilitate proper and secure reservation of those resources within the network. It describes the encoding of media authorization information as RSVP policy elements and provides details relating to operations, processing rules and error scenarios. The "framework" document describes a framework within which the above session authorization information can be exchanged and used. Working Group Summary The working group has consensus on these documents. Protocol Quality These documents have been reviewed for the IESG by Bert Wijnen.