From owner-rap@ops.ietf.org Thu May 16 10:22:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25851 for ; Thu, 16 May 2002 10:22:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178M6i-0004cU-00 for rap-data@psg.com; Thu, 16 May 2002 07:19:52 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 178M6i-0004cO-00 for rap@ops.ietf.org; Thu, 16 May 2002 07:19:52 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.00) id 178M6i-0004z1-00 for rap@ops.ietf.org; Thu, 16 May 2002 07:19:52 -0700 Message-ID: <30BFDEA66FF4D41191EB00D0B765BC6F05B90B@medha.wsspl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Wilson To: "'rap@ops.ietf.org'" Subject: Type definision issue in rfc2578 Date: Thu, 16 May 2002 15:17:23 +0530 Sender: owner-rap@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete mis-posts. so fix subscription addresses! ] Hi, Can someone help in the following issue.. I have some doubt in the types defined in the RFC2578, and its usage in RFC3159. In RFC2578 the type defintion for ExtUTCTime is said not to be imported by any MIB definition, but the RFC3159 is using the MIB definition convention to define the frame work for PIB defintions, and it is importing the ExtUTCTime, as per the RFC2578 which not to be allowed. From owner-rap@ops.ietf.org Thu May 16 10:34:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26232 for ; Thu, 16 May 2002 10:34:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178MKs-0004t1-00 for rap-data@psg.com; Thu, 16 May 2002 07:34:30 -0700 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #1) id 178MKr-0004sv-00 for rap@ops.ietf.org; Thu, 16 May 2002 07:34:29 -0700 Received: from haerke.ibr.cs.tu-bs.de (IDENT:root@haerke.ibr.cs.tu-bs.de [134.169.34.84]) by agitator.ibr.cs.tu-bs.de (8.12.1/8.12.1/Debian -2) with ESMTP id g4GEYPUi018551; Thu, 16 May 2002 16:34:25 +0200 Received: (from schoenw@localhost) by haerke.ibr.cs.tu-bs.de (8.11.6/8.11.6) id g4GEYPB25236; Thu, 16 May 2002 16:34:25 +0200 Date: Thu, 16 May 2002 16:34:25 +0200 Message-Id: <200205161434.g4GEYPB25236@haerke.ibr.cs.tu-bs.de> X-Authentication-Warning: haerke.ibr.cs.tu-bs.de: schoenw set sender to schoenw@ibr.cs.tu-bs.de using -f From: Juergen Schoenwaelder To: Wilson@WSSPL.com CC: rap@ops.ietf.org In-reply-to: <30BFDEA66FF4D41191EB00D0B765BC6F05B90B@medha.wsspl.com> (message from Wilson on Thu, 16 May 2002 15:17:23 +0530) Subject: Re: Type definision issue in rfc2578 References: <30BFDEA66FF4D41191EB00D0B765BC6F05B90B@medha.wsspl.com> Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Wilson writes: Wilson> I have some doubt in the types defined in the RFC2578, and its Wilson> usage in RFC3159. Wilson> In RFC2578 the type defintion for ExtUTCTime is said not to be Wilson> imported by any MIB definition, but the RFC3159 is using the Wilson> MIB definition convention to define the frame work for PIB Wilson> defintions, and it is importing the ExtUTCTime, as per the Wilson> RFC2578 which not to be allowed. The COPS-PR-SPPI module contained in RFC 3159 is an ASN.1 module which imports ExtUTCTime in order to define SPPI - but COPS-PR-SPPI is certainly not a MIB module written to conform to the SMIv2 language as defined in RFC 2578. So I do not really see a problem here. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Thu May 16 10:45:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26620 for ; Thu, 16 May 2002 10:45:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178MVR-00053R-00 for rap-data@psg.com; Thu, 16 May 2002 07:45:25 -0700 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 178MVQ-00053L-00 for rap@ops.ietf.org; Thu, 16 May 2002 07:45:24 -0700 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 g4GEjNa16067 for ; Thu, 16 May 2002 10:45:23 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 16:45:22 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Wilson , "'rap@ops.ietf.org'" Subject: RE: Type definision issue in rfc2578 Date: Thu, 16 May 2002 16:45:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk I think: SPPI (RFC3159) is NOT defining a MIB or a PIB but instead defining a "new language" or an "update to the SMI language". So that is a quite different thing than defining another MIB or PIB Module. Bert > -----Original Message----- > From: Wilson [mailto:Wilson@WSSPL.com] > Sent: Thursday, May 16, 2002 11:47 AM > To: 'rap@ops.ietf.org' > Subject: Type definision issue in rfc2578 > > > [ post by non-subscriber. with the massive amount of spam, > it is easy to > miss and therefore delete mis-posts. so fix subscription > addresses! ] > > Hi, Can someone help in the following issue.. > > I have some doubt in the types defined in the RFC2578, and > its usage in > RFC3159. > > In RFC2578 the type defintion for ExtUTCTime is said not to > be imported by > any MIB definition, > but the RFC3159 is using the MIB definition convention to > define the frame > work for PIB defintions, and it is importing the ExtUTCTime, > as per the > RFC2578 which not to be allowed. > > > > > From owner-rap@ops.ietf.org Thu May 16 12:34:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01179 for ; Thu, 16 May 2002 12:34:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 178OCR-00074b-00 for rap-data@psg.com; Thu, 16 May 2002 09:33:55 -0700 Received: from cypher.cisco.com ([171.69.11.18] helo=cisco.com) by psg.com with esmtp (Exim 3.36 #1) id 178OCQ-00074V-00 for rap@ops.ietf.org; Thu, 16 May 2002 09:33:54 -0700 Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA17034; Thu, 16 May 2002 09:33:50 -0700 (PDT) From: Keith McCloghrie Message-Id: <200205161633.JAA17034@cisco.com> Subject: Re: Type definision issue in rfc2578 To: Wilson@WSSPL.com (Wilson) Date: Thu, 16 May 2002 09:33:49 -0700 (PDT) Cc: rap@ops.ietf.org ('rap@ops.ietf.org') In-Reply-To: <30BFDEA66FF4D41191EB00D0B765BC6F05B90B@medha.wsspl.com> from "Wilson" at May 16, 2002 03:17:23 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Hi, Can someone help in the following issue.. > > I have some doubt in the types defined in the RFC2578, and its usage in > RFC3159. > > In RFC2578 the type defintion for ExtUTCTime is said not to be imported by > any MIB definition, > > but the RFC3159 is using the MIB definition convention to define the frame > work for PIB defintions, and it is importing the ExtUTCTime, as per the > RFC2578 which not to be allowed. Let me explain: 1. ExtUTCTime is defined as part of SMIv2. 2. The SPPI imports ExtUTCTime because the SPPI is an enhanced subset of SMIv2. 3. The module within RFC 3159 which imports ExtUTCTime is the SPPI, which begins: COPS-PR-SPPI DEFINITIONS ::= BEGIN IMPORTS ObjectName, SimpleSyntax, ExtUTCTime, mgmt FROM SNMPv2-SMI; 4. The SPPI is the rules for writing PIBs, but the SPPI is *not* itself a PIB. 5. RFC 3159 does not contain a MIB. 6. The PIB module within RFC 3159 begins: COPS-PR-SPPI-TC PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, MODULE-IDENTITY, TEXTUAL-CONVENTION, pib FROM COPS-PR-SPPI; Notice that this is a PIB because it has the "PIB-DEFINITIONS" keyword, but does not IMPORT ExtUTCTime. So, RFC 3159 does not violate the rules relating to ExtUTCTime as specified in RFC 2578. Keith. From owner-rap@ops.ietf.org Mon May 20 14:23:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27377 for ; Mon, 20 May 2002 14:23:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 179rm5-000M3q-00 for rap-data@psg.com; Mon, 20 May 2002 11:20:49 -0700 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 179rm4-000M3i-00 for rap@ops.ietf.org; Mon, 20 May 2002 11:20:48 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4KIKke18978 for ; Mon, 20 May 2002 14:20:47 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 20:20:45 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: nhamer@nortelnetworks.com, gageb@nortelnetworks.com, hugh.shieh@attws.com Cc: Scott Hahn , Mark Stevens , rap Subject: AD review of draft-ietf-rap-session-auth-03.txt Date: Mon, 20 May 2002 20:20:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Before putting documents on the IESG agenda I review them first. I have issued IETF Last Call for the document draft-ietf-rap-rsvp-authsession-02.txt in which Last Call this informational is included (I expect). So you can consider my comments as IETF Last Call comments Here are my comments and questions: 1. Section 2 can be removed. These keywords (as far as I can tell) are not used in this document. This also means that reference to RFC2119 can go away 2. You talk about "districts" in section 3 qand figure 1 (and maybe other places). Where is this terminology used? Is it the same as "domain"... it seems it is, but I am not sure?? Maybe this term (District) is common place in the SIP space... In any event, you may want to indicate where it comes from. In 1st sentence on page23 you seem to refer to it as domain indeed. 3. You sometimes talk about "Session Manager" other times about Session Manager Server. I think to understand that the "session manager" runs on the session server. But you may want to make that clearer. For example, 2nd bullet in sect 4 talks about "Edge Router, Session Manager, and Policy Server" I see 2 of them in the figure 1, but not the "Session Manager" instead I see "Session Manager Server", which I think is what you mean. This happens in a few more places in the doc. 4. You may want to elaborate a bit on how the "pre-established trust relationships" get set up or established. It seems to be out of scope of the document, but it is kind of important from a security point of view is it not? 5. In each of section 4,5,6,7 you talk about "protocol impacts" on such protocols as: - Resource Reservation protocol - Policy Management protocol - Session Management protocol - Authorization protocol In last para on page 4, you make references to (some of) those protocols (but not to all). And I wonder if "session control protocol" is same as "session management protocol". I think it would be good to: - be consistent in terminology - make references to all protocols on page 4. - possibly also add example references to those protocols when you list them in sect 4,5,6,7. 6. In section 5 you start talking about a "per-transaction basis" And that comes back later on too I think. You may want to explain (either her or in terminology in section 3) what a transaction is in this context. 7. Section 7.1 all of sudden talks about "Call Flow" whereas earlier sections talked about the same concept I think but named it "Message Flows". Better be consistent or explain why now it is a "Call Flow" 8. Section 8. I have difficulty parsing the 1st sentence. Is that just me? I doubt it. 9. If you are going to do another revision, you may want to split the references section in Normative and non-normative references as per draft-rfc-editor-rfc2223bis-02.txt Bert From owner-rap@ops.ietf.org Mon May 20 15:10:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01874 for ; Mon, 20 May 2002 15:10:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 179sXJ-000NTy-00 for rap-data@psg.com; Mon, 20 May 2002 12:09:37 -0700 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 179sXJ-000NTq-00 for rap@ops.ietf.org; Mon, 20 May 2002 12:09:37 -0700 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4KJ9Ym10185 for ; Mon, 20 May 2002 15:09:35 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 21:09:34 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: nhamer@nortelnetworks.com, gageb@nortelnetworks.com, hugh.shieh@attws.com, kosinski@cs.ualberta.ca, mbroda@nortelnetworks.com Cc: Scott Hahn , Mark Stevens , rap Subject: AD review of: draft-ietf-rap-rsvp-authsession-02.txt Date: Mon, 20 May 2002 21:09:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-rap@ops.ietf.org Precedence: bulk Before putting documents on the IESG agenda I review them first. I have issued IETF Last Call for the document draft-ietf-rap-rsvp-authsession-02.txt I would normally issue Last Call only after I have done the review and received responsess from authors. But it seems that 3GPP wants this doc to become RFC soon (June 7th). So therefor we do this in paralell So you can consider my comments as IETF Last Call comments Here are my comments and questions: 1. The RFC-Editor does not want references in the abstract section see draft-rfc-editor-rfc2223bis-02.txt for details You can replace [POL-EXT] with (RFC 2750) as a good alternative. 2. Sect. 2, talks about "DiffEdge". May want to explain that term. I see that you reference an RFC, yet a few words on that term may be good. 3. The way you specify the Policy element in sect 3.2 is different from what I have seen before. For example, RFC3181 does it as follows: P-Type: 16 bits PREEMPTION_PRI = 1 This value is registered with IANA, see Section 7. I would strongly suggest to use the same/similar format. In fact, RFC3182 does that too For the actual value you can either put in a free number or you can do something like "TBD-by-IANA" 4. I would then also recommend a similar approach for each of the attribute types and their SubTypes. Actually RFC3182 is a very good example for that. The idea is that when we have the finalized RFC, people can find in the spec itself the numbers that have been assigned to each S-Type and SubType within an S-Type. And then in teh IANA Considerations section, they can find them all nicely listed together. 5. So I would also strongly recommend that in the IANA Considerations you make clear all the assigned (or TBD-by-IANA) values. I again think that RFC 3182 is a very good example. 6. Of course, you start a new registry, so the IANA COnsiderations section also needs to have a write-up as to how values within the new name space get assigned. In other words, I think your IANA COnsiderations section can be much much clearer than it currently is. 7. Section 3.3 (and others as well) Talks about "padding bytes". You may want to specify that they "MUST have a value of zero". Whatever you choose, it is important to be specific, otherwise running a digest (or creating a signature) for these objects is gonna be problematic. 8. Section 3.3.2 (and other places, but this one in particular) You talk about "plain ASCII" and "plain UNICODE". You may want to add a reference or be more specific as to what you mean. For example, is plain ASCII to mean 7-bit US ASCII? In other places (like in 3.3.1) you reference an RFC. Maybe in that RFC (which I have not yet checked) it becomes clear what exactly an "ASCII string" means. Sect 3.3.3 does need extra reference on this too. 9. The places where you talk about IPv4 and IPv6 addresses, you should specify how they are formatted. Are they 32 and 128 bit values (respectively) in an OCTET STRING, or are they formated as dotted decimal (IPv4) or separated by colons (IPv6) ??? 10. In section 5, I see you talk about "IndetityType", "identity type" and "PE type". Probably this is all the same thing... but it is quite confusing. Why not use the terminology as defined in RFC 2750 whicj calls it P-Type But whichever you choose, I prefer a consistent term, and not 3 different onse in one section that supposedly mean the same thing. Or am I mistaken here. 11. Last sentence section 6. Should "will include" be replaced by "MUST include" ?? 12. I suspect that the Security Considerations section may cause trouble with the Security ADs. I would advise to be more explicit in pointing out possible risks and also strongly recommening (MUST language probably) that implementation MUST support the secure mechanisms. Maybe it is wise to check with one or both Security ADs. Let me know if you want me to help with that. 13. Pls split references section in normative and non-normative references as per draft-rfc-editor-rfc2223bis-02.txt 14. I am missing an IPR section as required per RFC2026. Bert From owner-rap@ops.ietf.org Mon May 20 19:01:53 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19443 for ; Mon, 20 May 2002 19:01:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 179w9G-0004as-00 for rap-data@psg.com; Mon, 20 May 2002 16:01:02 -0700 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #1) id 179w9G-0004am-00 for rap@ops.ietf.org; Mon, 20 May 2002 16:01:02 -0700 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.00) id 179w9G-0008Fw-00 for rap@ops.ietf.org; Mon, 20 May 2002 16:01:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200205201854.OAA00202@ietf.org> To: IETF-Announce: ; Cc: rap@ops.ietf.org From: The IESG SUBJECT: Last Call: Session Authorization for RSVP to Proposed Standard Date: Mon, 20 May 2002 14:54:16 -0400 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has received a request from the Resource Allocation Protocol Working Group to consider Session Authorization for RSVP as a Proposed Standard. The IESG will also consider Framework for session set-up with media authorization for publication as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-02.txt http://www.ietf.org/internet-drafts/draft-ietf-rap-session-auth-03.txt