From speermint-bounces@ietf.org Mon Jan 26 19:28:26 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FB23A69D8; Mon, 26 Jan 2009 19:28:26 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7325C3A69F3 for ; Mon, 26 Jan 2009 19:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33iT99CPDCZi for ; Mon, 26 Jan 2009 19:28:23 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1329C3A69D8 for ; Mon, 26 Jan 2009 19:28:22 -0800 (PST) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n0R3O7b01358; Tue, 27 Jan 2009 03:24:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jan 2009 22:27:59 -0500 Message-ID: In-Reply-To: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Meeting minutes from IETF 73 Speermint session Thread-Index: AclheIM6vfcHtNx+S0q4AzvQWgZd6QeqtZlg References: <160DE07A1C4F8E4AA2715DEC577DA491B1AF74@srvxchg3.cablelabs.com> From: "James McEachern" To: Cc: Daryl Malas Subject: Re: [Speermint] Meeting minutes from IETF 73 Speermint session X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Daryl, I volunteered to do a detailed review of the SPEERMINT Peering Architecture draft, so in the spirit of "better late than never" I will begin sending my comments to the list for consideration. My comments will be in several emails over the rest of the week... First a nit: 1. References. It appears that the references (at least in the introduction) are off by one. SPEERMINT Requirements is shown as [13], but is actually [14] while Terminology is shown as [12] but is [13] in the reference section. I didn't go further, but please check to ensure references are correct. Next, a couple of general comments related to consistency: 2. Originating vs. Initiating SSP: Sometimes we use one, sometimes the other. In this case I'm pretty sure everyone agrees on what we mean, so let's pick one or the other and use it throughout. (I'm kind of leaning toward "initiating" but cold live with either.) 3. SSP vs. peer: Most of the time we use "SSP", but in some sections we begin to use "peer". I think the term "peer" is relative, and leaves us open to all sorts of confusion, while the SSP is clear. My preference is to use SSP throughout, and I will assume that in any remaining comments. 4. Target vs. Terminating: I'll save that one for later, as I don't believe we all are in agreement just yet on that particular one. Now on to section specific comments: 5. Section 2. Network Context, final paragraph says: " The members of a federation may jointly use a set of functions such as location function..." Comment: The terminology draft defines LUF and LRF, but does not define "location function". Similarly, this draft also discusses LUF and LRF, but not "location function". Recommended Solution: Change "location function" to "Look-Up Function, Location Routing Function,". While we are at it, we probably should capitalize the other functions the way we have done in the Terminology draft. 6. Section 3. Procedures, Bullet 5 states " the determination of the UAS,". Comment: This is unclear to me. I think we are determining something about the UAS, perhaps the location of the UAS. If this is correct, then we should change it to say this. 7. Section 3. Procedures This section might be strengthened by changing to the active voice. For example, bullet 6 would be a lot clearer (to me at least) if we just said "establish the session". However, I'm ok with group consensus on this one. 8. Section 3. Procedures: The final paragraph states that "In the case the target SSP is different from the terminating SSP ...". Comment: If we are going to open this can of worms (and I fear we must) then it is crucial that we clearly define what terminating and target SSP mean, and use them with absolute consistency throughout the document. If there was a consensus on the list after Minneapolis, I missed it; to me it sounded like two solitudes. Since I don't want to just raise issues, I am going to propose what I think makes sense here, and let people react. Target SSP = the SSP we are currently trying to reach. If the session is "retargeted" then it is given a new target SSP (unless of course the new target is in the same SSP). This seems consistent with general usage. Terminating SSP = the SSP where the session actually does terminate. The remainder of my comments assume these definitions. In the spirit of making concrete suggestions, I would suggest that the final paragraph of Section 3 be modified as follows: Current text: "In the case the target SSP is different from the terminating SSP it would repeat steps 1-4. This is reflected in Figure 2 that shows the target SSP with its own peering functions." Change to: " In the case the initial target SSP is different from the terminating SSP it would repeat steps 1-4. This is reflected in Figure 2 that shows the target SSP with its own peering functions." 9. Section 5.1. Originating SSP Procedures We use "originating SSP" in the section heading, but "initiating SSP" in the body. 10. Section 5.1.1. The Look-Up Function Currently states "Purpose is to determine the SF of the target domain ..." Comment: Earlier in this document, and in the Terminology draft, we state that the LUF determines the target domain - not the SF of the target domain. In addition, we later state that the LRF determines the location of the SF. Therefore I believe we should change as follows: Current text: "Purpose is to determine the SF of the target domain ..." Change to: "Purpose is to determine the target domain ..." 11. Section 5.1.1. The Look-Up Function Currently states "...optionally develop Session Establishment Data (SED) [12]." Comment: I believe this is only true when the target address is in the same domain as the initiating SSP, otherwise the LRF develops the SED. Therefore I suggest we change as follows: Current text: "... optionally develop Session Establishment Data (SED) [12]. " Change to: "... if the target address is in the same administrative domain as the initiating SSP, optionally develop Session Establishment Data (SED) [12]. " 12. Section 5.1.1.1 Target address analysis. Second paragraph states that "... the initiating SSP resolves the call routing data by using the Location Routing Function (LRF)" I suggest we recognize the step where the LUF first determines the target domain, by changing the above to read: "... the initiating SSP first determines the target domain, and then resolves the call routing data by using the Location Routing Function (LRF)" 13. Section 5.1.1.1 Target address analysis. The third paragraph begins with "For example...". This confuses me. The previous paragraph ends by saying what the LRF does, but then immediately gives examples of how the LUF works - at least I think this is what it is providing. At the very least we need to somehow qualify the examples, though to be honest I'd be happy if we just deleted the third and fourth paragraphs.. ---- end of first set of comments ---- More comments to follow in a day or so. Jim McEachern T:+1 613 763-3419 M:+1 613 853-0176 -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Daryl Malas Sent: Thursday, December 18, 2008 8:24 PM To: speermint@ietf.org Cc: Alexander Mayrhofer; Livingood,Jason Subject: [Speermint] Meeting minutes from IETF 73 Speermint session All, The meeting minutes for the IETF 73 Speermint session can be found here: http://www.ietf.org/proceedings/08nov/minutes/speermint.txt Please check the notes, as some of you volunteered to do things...and, some by the end of the year (2008). Also, there were several issues that were going to be further discussed on the mailing list. Those of you presenting on these topics, please start the threads. If you have questions, concerns, or feel like something important was left out let us know. Thank you for your participation in Minneapolis. Regards, Daryl Speermint co-Chair ---------------- Daryl Malas CableLabs (o) +1 303 661 3302 (f) +1 303 661 9199 mailto:d.malas@cablelabs.com _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 27 13:03:30 2009 Return-Path: X-Original-To: speermint-archive@megatron.ietf.org Delivered-To: ietfarch-speermint-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596023A6A90; Tue, 27 Jan 2009 13:03:30 -0800 (PST) X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8173A6A90 for ; Tue, 27 Jan 2009 13:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_50=0.001, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjM1XfSRPMKu for ; Tue, 27 Jan 2009 13:03:29 -0800 (PST) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id 06DB03A67F8 for ; Tue, 27 Jan 2009 13:03:28 -0800 (PST) Received: from notes2.fra1.osl.denic.de (notes2.fra1.osl.denic.de [10.122.50.20]) by office.denic.de with esmtp id 1LRv5R-00084h-S4; Tue, 27 Jan 2009 22:03:09 +0100 From: Heike Schmidt-Hunkel/Denic To: speermint@ietf.org Message-ID: Date: Tue, 27 Jan 2009 22:02:59 +0100 X-MIMETrack: Serialize by Router on notes2/Denic at 27.01.2009 22:03:09 MIME-Version: 1.0 Subject: [Speermint] =?iso-8859-1?q?Heike_Schmidt-Hunkel_ist_au=DFer_Haus?= =?iso-8859-1?q?=2E?= X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Ich werde ab 15.01.2009 nicht im B=FCro sein. Ich kehre zur=FCck am 16.02= .2009. Ich werde Ihre Nachricht nach meiner R=FCckkehr beantworten. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www.ietf.org/mailman/listinfo/speermint