From exandrov@fighttowin.com Mon Aug 18 14:25:44 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B4C3A6D93 for ; Mon, 18 Aug 2008 14:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.958 X-Spam-Level: **** X-Spam-Status: No, score=4.958 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 PeyGein7s6um for ; Mon, 18 Aug 2008 14:25:43 -0700 (PDT) Received: from mail.teknotes.bg (mail.teknotes.bg [82.147.149.82]) by core3.amsl.com (Postfix) with ESMTP id 0CDC83A6ADA for ; Mon, 18 Aug 2008 14:25:42 -0700 (PDT) Date: Tue, 19 Aug 2008 00:25:50 +0300 Message-Id: <4041643745.kv41.UIUB.169226522875@fighttowin.com> From: "Top News Agency" Reply-To: "Do Not Reply please" To: ipdvb-archive@ietf.org Subject: Weekly top news MIME-Version: 1.0 X-Mailer:eBizmailer4.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Britney Spears Engaged

Pop singer Britney Spears has got in = engaged. This=20 time Spears got engaged to former "the New Mickey Mouse Club" co-star = and former=20 NSYNC member JC Chasez.

Read All (35) breaking = news
AND 40=20 shocking videos From owner-ipdvb@erg.abdn.ac.uk Fri Aug 22 15:29:51 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4D7F28C0E5 for ; Fri, 22 Aug 2008 15:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.09 X-Spam-Level: ** X-Spam-Status: No, score=2.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_AT=0.745, HOST_EQ_STATIC=1.172] 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 xx2yvqDvfF0j for ; Fri, 22 Aug 2008 15:29:50 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 55B2F3A6A9C for ; Fri, 22 Aug 2008 15:29:49 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7MMAiqm009295 for ; Fri, 22 Aug 2008 23:10:44 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m7MMAiuv009294 for ipdvb-subscribed-users; Fri, 22 Aug 2008 23:10:44 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7MMAXlv009280 for ; Fri, 22 Aug 2008 23:10:33 +0100 (BST) Received: from [172.16.10.187] (85-124-63-18.static.xdsl-line.inode.at [85.124.63.18]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id B0F08228DF8 for ; Sat, 23 Aug 2008 00:10:33 +0200 (CEST) Message-ID: <48AF3955.4090901@cosy.sbg.ac.at> Date: Sat, 23 Aug 2008 00:10:29 +0200 From: Michael Noisternig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: [Fwd: Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08] References: <48AF0472.2000301@erg.abdn.ac.uk> In-Reply-To: <48AF0472.2000301@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Hello Rupert, many thanks for your review and the comments. See our replies inline. > -------- Original Message -------- > Subject: Re: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08 > Date: Wed, 30 Jul 2008 11:53:32 +0100 > From: Rupert Goodings > To: ipdvb@erg.abdn.ac.uk > CC: Gorry Fairhurst , H.Cruickshank@surrey.ac.uk > References: <487DC23A.7040903@erg.abdn.ac.uk> > <225B6337E699484095DA8EE02A5063B5090B14@EVS-EC1-NODE1.surrey.ac.uk> > > Gorry, All, > > Following a nudge from Haitham, I've reviewed this draft RFC. > See below for my detailed comments. > > Apologies to you all for the lateness of my comments. > > To summarise; I think this draft generally reads OK - these just > suggestions that are intended to improve the doc - I would hope that > they can all be dealt with pretty easily and hence (hopefully) not > introduce any delays. > > best regards > > Rupert Goodings > > ==START OF COMMENTS > > Section 1: (this my major comment) > I find the introduction confusing with regard to scope of this RFC for > Two-Way IP networks. > > In my understanding this RFC only really considers link level ULE > security on the forward (hub to remote) link of 2-way networks. Hence > although ULE can be used in 2-way networks the scope of this RFC is > limited to security of the ULE encapsulated forward link only. ULE security concerns security for the ULE link which is the connection between the encapsulator and the receiver. There is no reason ULE cannot be used throughout in 2-way networks if the MPEG-2 transmission network accomodates that. Plus, the transmission network could be hubless. Speaking of that, ULE can be used in any MPEG-2 network and is not restricted to satellite networks. > I think > some reworking of section 1 would help - > specifically the para immediately below the A-F list. I suggest: > > RFC 4259 states that ULE must be robust to errors and security threats. > Security must also consider both unidirectional (A, B, C and D) as well > as bidirectional (E and F) links for the scenarios mentioned above. #NEW# > This RFC will consider security for the unidirectional scenarios, and > for the forward link of the bidirectional scenarios.#END NEW# > > [Aside: As an example of this assumption: the discussion of monitoring > threats due to the broadcast nature of the network, is clearly only true > for the forward link.] Assuming senders directly use ULE with ULE security both forward and return link are protected. > Section 2: > The definition of NPA really seems to be a definition of MAC Address. > It seems that the rest of the RFC is concerned with the MAC Address (not > the NPA). Hence I suggest you replace NPA with "MAC Address"; i.e: We want to reserve MAC for Message Authentication Code as this is a security document. Also NPA has been defined in RFC 4326 and therefore it should be used in all IP-DVB related documents. Gorry adds that this could also be confused with the LAN MAC address with bridging encaps - which is something different. > MAC Address: In this document, the MAC Address refers to a 6-byte > destination address (resembling an IEEE Medium Access Control address) > within the MPEG-2 transmission network that is used to identify > individual Receivers or groups of Receivers. > [[Obviously this requires replacing NPA with MAC Address in the rest of > the Doc. I think replacement is appropriate in most cases]] > > ALTERNATIVELY, if you want to retain "NPA" please used a better definition. > I'd insert the phrase "A point where a host can be attached to the > network." > Then continue with the current definition with a few tweaks. Hence: > > NPA: Network Point of Attachment. A point where a host can be attached > to the network. In this document, the NPA is identified by the 6-byte > destination address (resembling an IEEE Medium Access Control address) > within the MPEG-2 transmission network that is used to identify > individual Receivers or groups of Receivers. As above, the definition is taken from RFC 4326 which people will eventually refer to, anyways. > Section 3: > Could we add the NPA to this picture? > (I assume it is between the Host and MPEG-2 receiver. This assumes > my definition as above - i.e. *identified* by the MAC address; not the > MAC Address itself). > [[This depends on response to previous comment]] We do not want to complicate that figure. It is adapted from RFC 4259 and its purpose is to identify all entities within the MPEG-2 network, which is used later for threat analysis. > Section 3.3. > The definition of "outsider attacks" seems unduly narrow. > Why is this limited to VPNs? I suggest removing VPN: > "Outsider attacks, i.e. active attacks from adversaries outside the > network without knowledge of the secret material. " I guess the confusion comes from the term VPN. I (Michael) meant to use this for all entities sharing the same secret material thus enabling them to form some secure overlay network. So you could be in the same physical network but not having the key makes you an outsider. Maybe just say "Outsider attacks, i.e. active attacks from adversaries without knowledge of the secret material." to avoid any confusion. > Section 4: Greq (c) > I'd prefer to replace "agility" with "update". > For me, agility implies a dynamic process (new alg every few secs) > rather than a slow update process similar to software update. > [[Else please clarify the agility intended]] Algorithm agility is a common/established term in the security area for protocol design. > Section 4. Table 1. > Table 1 Headings do not align to the Text. Suggest changing the Table > Replace "Attack" with "Threat" > Replace "Mitigation of Threat " with "Security Mechanism" That's good. > Section 7: Typo: "Annexe 1" Yes, should be Appendix A. > Section A.1; Figure 2 > The text does not align to the Figure. Suggest correcting Figure. > "Key Management Group Member Block" > "Key Management Group Server Block". Ok. > Section A.1; Figure 2 > I am a bit confused by the Databases block. Why is this on one side only? > I *guess* that the columns relate to the "Receiver" (LHS) and > Encapsulator/Transmitter (RHS). Two suggestions: > a) Introduce column headings as above (and/or create two overall boxes > round the > three blocks on each side; > b) Add a Database block on the RHS. We do not want to unnecessarily complicate the figure by duplicating the SA/SP block for the key server. However we'll add the text "The Security Databases Block exists in both the group member and server sides. However, it has been omitted from Figure 2 just for clarity." to the introduction of the building blocks. > (Nit: it would be nice to have the order of the text subsections > correspond to the > order of the blocks in Fig 2. i.e. reverse ULE Extension and Database > text sections.) Ok. > Section B.3 > I think it would be good to have a bit more balance in the discussion of > this option. > Specifically delete "major" from advantages and add some of the Ok. > disadvantages. Two suggested disadvantages: > - no protection of MAC Address There seems to be some confusion. ULE security *does* protect the MAC/NPA address. This is said by the point "Ability to protect the identity of the Receiver within the MPEG-2 transmission network at the IP layer and also at L2." By identity we mean (NPA) addresses as introduced earlier. > - only protects C-plane control messages if they are encapsulated. Yes that is correct. But Ipsec and TLS/DLS can not protec control messages either. > > ==END OF COMMENTS From owner-ipdvb@erg.abdn.ac.uk Fri Aug 22 15:34:54 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788FA3A6A5A for ; Fri, 22 Aug 2008 15:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.09 X-Spam-Level: ** X-Spam-Status: No, score=2.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_AT=0.745, HOST_EQ_STATIC=1.172] 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 LjE9cp5i-i9n for ; Fri, 22 Aug 2008 15:34:53 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 5021A3A6A56 for ; Fri, 22 Aug 2008 15:34:52 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7MMJjEa009936 for ; Fri, 22 Aug 2008 23:19:45 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m7MMJj6G009934 for ipdvb-subscribed-users; Fri, 22 Aug 2008 23:19:45 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7MMJWDW009922 for ; Fri, 22 Aug 2008 23:19:32 +0100 (BST) Received: from [172.16.10.187] (85-124-63-18.static.xdsl-line.inode.at [85.124.63.18]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 91C8C228E4C for ; Sat, 23 Aug 2008 00:19:33 +0200 (CEST) Message-ID: <48AF3B70.9030100@cosy.sbg.ac.at> Date: Sat, 23 Aug 2008 00:19:28 +0200 From: Michael Noisternig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: Reminder: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08] References: <48919829.3060700@erg.abdn.ac.uk> <48926642.7020707@nav6.org> In-Reply-To: <48926642.7020707@nav6.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Finally, also thanks to Ang for the review! We'll post an updated version of the draft soon. Michael Ang Way Chuang schrieb: > Gorry Fairhurst wrote: >> >> This is a reminder that the sec requirements document is still in >> WGLC, until the end of this week. There are a number of committed >> reviewers, but it would be most helpful to the Chair to know if other >> people have read this version (even if you have only minor comments, >> or no comments at all). >> > No comment > > --- draft-ietf-ipdvb-sec-req-08.txt 2008-08-01 09:25:24.000000000 +0800 > +++ draft-ietf-ipdvb-sec-req-08-minor.txt 2008-08-01 > 09:24:50.000000000 +0800 > @@ -799,7 +799,7 @@ > > Link-layer (L2) encryption of IP traffic is commonly used in > broadcast/radio links to supplement end-to-end security (e.g. > - provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). > + provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301]). > > A common objective is to provide the same level of privacy as > wired links. It is recommended that an ISP or user provide end- > >> Best wishes, >> >> Gorry Fairhurst >> (ipdvb WG Chair) >> >> >> -------- Original Message -------- >> Subject: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08 >> Date: Wed, 16 Jul 2008 10:41:14 +0100 >> >> This email starts a WG Last-Call for comments for the WG document named >> below: >> >> http://tools.ietf.org/html/draft-ietf-ipdvb-sec-req-08 >> >> Members of the IETF ipdvb WG are now asked to read the above draft and >> send any issues, comments, or corrections to this mailing list. The WGLC >> procedure is the last chance for this working group to modify/correct >> this document. This document is intended for publication as an >> INFORMATIONAL RFC. The document shepherd for the process following >> completion of the WGLC shall be me, as the ipdvb Chair (Gorry Fairhurst). >> >> This Last-Call will end on midnight, 1st August 2008. This is a second >> WGLC, following major revisions to the I-D to address the SecDir review >> comments. The LC period has been extended because this call is made >> adjacent to an IETF meeting. >> >> Please *DO* forward any comments to the list. >> >> Best wishes, >> >> Gorry Fairhurst >> (ipdvb WG Chair) >> >> From owner-ipdvb@erg.abdn.ac.uk Fri Aug 22 16:09:56 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9C53A68EF for ; Fri, 22 Aug 2008 16:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.834 X-Spam-Level: ** X-Spam-Status: No, score=2.834 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_AT=0.745, HOST_EQ_STATIC=1.172] 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 FVvkNrEB+hty for ; Fri, 22 Aug 2008 16:09:55 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 2DCE73A6AFB for ; Fri, 22 Aug 2008 16:09:54 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7MMoH3M012412 for ; Fri, 22 Aug 2008 23:50:17 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m7MMoGMp012411 for ipdvb-subscribed-users; Fri, 22 Aug 2008 23:50:16 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7MMo8If012389 for ; Fri, 22 Aug 2008 23:50:08 +0100 (BST) Received: from [172.16.10.187] (85-124-63-18.static.xdsl-line.inode.at [85.124.63.18]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 0F524228ED3 for ; Sat, 23 Aug 2008 00:50:09 +0200 (CEST) Message-ID: <48AF4299.5000204@cosy.sbg.ac.at> Date: Sat, 23 Aug 2008 00:50:01 +0200 From: Michael Noisternig User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Re: [Fwd: RE: WG Last-Call (WGLC) for comments: draft-ietf-ipdvb-sec-req-08] References: <48AF04BB.9090901@erg.abdn.ac.uk> In-Reply-To: <48AF04BB.9090901@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk Hi Laurence, also many thanks for your review and comments. Replies are inline. > ------------------------------------------------------------------------ > *From:* Laurence.Duquerroy@esa.int [mailto:Laurence.Duquerroy@esa.int] > *Sent:* Thu 7/31/2008 13:02 > *To:* Cruickshank HS Dr (CCSR) > *Cc:* gorry@erg.abdn.ac.uk; Stephane.Combes@esa.int > *Subject:* RE: WG Last-Call (WGLC) for comments: > draft-ietf-ipdvb-sec-req-08 > > > Dear Haitham, > > I reviewed the draft this morning. It is now in a very good shape. I > just have a couple of comments, that you can find below: > > * page 12 - in the case 2 description: I don't understand why req2 > (protection of NPA address) is associated with MAC, digital > signatures or TESLA...Is it not included with the Case 1 > requirements? Yes, you're right, we removed Req2 from Case 2. > * page 12 - in the case 2 description: " In terms of outsiders > attacks, group authentication using MAC should provide the same > level of security ": as what ? I am not sure that the meaning of > this sentence is very clear. Agreed, not very clear. We'll just say "In terms of outsider attacks, group authentication using MACs can provide the required level of security (Req 3 and 5)." now. > * page 21 - A.1.2: Identity protection is not included in the list > of security feautres that the new security ext header will > provide. However in section 5 - p 13, this feature belongs to the > base profile. Yes, added. > > > And a couple of corrections (between dash) > > * page 4 : the all-zeros PID as well as other PID values * - *are - > reserved > * page 14: the security threats and requirement-s- presented in this > document > * page 20: (shown as the key Management Group server block in figure > 2 - ) - > * page 22 : GCKS : the signification of this acronym is missing Ok, fixed that. > > > Best regards, > > Laurence > > Laurence Duquerroy > ESA / ESTEC TEC-ETC > Laurence.Duquerroy@esa.int > +31 (0)71 565 6312 Michael From owner-ipdvb@erg.abdn.ac.uk Wed Aug 27 00:14:21 2008 Return-Path: X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF85C3A6B9F for ; Wed, 27 Aug 2008 00:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 shxWJvRFJai5 for ; Wed, 27 Aug 2008 00:14:21 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 8FB093A6B8D for ; Wed, 27 Aug 2008 00:14:18 -0700 (PDT) Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7R6r1jL028205 for ; Wed, 27 Aug 2008 07:53:01 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id m7R6r1HR028203 for ipdvb-subscribed-users; Wed, 27 Aug 2008 07:53:01 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from Gorry-Fairhursts-Laptop.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id m7R6qvUu028186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 27 Aug 2008 07:52:58 +0100 (BST) Message-ID: <48B42E12.7050607@erg.abdn.ac.uk> Date: Tue, 26 Aug 2008 18:23:46 +0200 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Subject: Updated I-D published: draft-ietf-ipdvb-sec-req-08 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk I see draft-ietf-ipdvb-sec-req-09.txt was published following completion of the WGLC, and has been posted to the IETF repository: Filename: draft-ietf-ipdvb-sec-req Revision: 09 Title: Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol Creation_date: 2008-08-23 WG ID: ipdvb Number_of_pages: 30 Unless I hear otherwise, I shall assume this resolves all pending issues and that this document is now ready for IETF publication. If anyone has any further questions or previous people wish to expand their comments, please let me know before Monday. I am now preparing the appropriate note to request publication by the Area Director. Best wishes, Gorry Fairhurst (ipdvb WG Chair)