From internet-drafts@ietf.org Sun Jun 2 06:41:39 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6969F21F939E; Sun, 2 Jun 2013 06:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.023 X-Spam-Level: X-Spam-Status: No, score=-102.023 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs9eQzlskFqB; Sun, 2 Jun 2013 06:41:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0597E21F8EAE; Sun, 2 Jun 2013 06:41:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130602134139.31727.64349.idtracker@ietfa.amsl.com> Date: Sun, 02 Jun 2013 06:41:39 -0700 Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-interop-09.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 13:41:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Forwarding and Control Element Separation= Working Group of the IETF. Title : Interoperability Report for Forwarding and Control Eleme= nt Separation (ForCES) Author(s) : Weiming Wang Kentaro Ogawa Evangelos Haleplidis Ming Gao Jamal Hadi Salim Filename : draft-ietf-forces-interop-09.txt Pages : 29 Date : 2013-06-02 Abstract: This document captures results of the second Forwarding and Control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. RFC 6053 reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-interop There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-interop-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-forces-interop-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vumip1@gmail.com Mon Jun 3 08:31:22 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0136A11E80AE for ; Mon, 3 Jun 2013 08:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-y2fXmN2OQZ for ; Mon, 3 Jun 2013 08:31:21 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 165D211E80A4 for ; Mon, 3 Jun 2013 08:31:20 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so3294270wgh.1 for ; Mon, 03 Jun 2013 08:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AWVLebTjbGyCSYVYH5NsJN3brOMFafle9g1/IMG6nCM=; b=q0tVW0tk45wSwwkqX5LgSGR2HRTX8S7uJ8DqIjhpVn/ZgmEbkRqrHvY4iPXBLqxeC7 ooJc9wg+5/7DE3uRpfsw1BvXuasGBEGqHBhyRVqLIUfn/dUNXqsTq5GaaKsMOuU+G9QK 6aIsGQ0fV+euqJfY2X5RK2h/H2rHI4XppRPIOlWFR9IvgGSuy5BoS/L3x/PbhwNzdH1r mMIS38vNyHFV3fT+rR77+KYSkQRZPuROttkq34tIu2hRhKBsos9MC6fqiJ4/2VaR9b1C Gt51uAgc7oWmYhvM+tFiisQ+3+hOHh0G/v5dPPdTPTL+Jsmh8gH3Kwv6/PaibQ/jp1t4 ndrw== MIME-Version: 1.0 X-Received: by 10.180.9.195 with SMTP id c3mr13228915wib.61.1370273479920; Mon, 03 Jun 2013 08:31:19 -0700 (PDT) Received: by 10.217.127.10 with HTTP; Mon, 3 Jun 2013 08:31:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Jun 2013 11:31:19 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a11c2441404153e04de41a8c2 Cc: "forces@ietf.org" , Bhumip-ZTE Khasnabish Subject: Re: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 15:31:22 -0000 --001a11c2441404153e04de41a8c2 Content-Type: text/plain; charset=ISO-8859-1 Thanks Jamal. Pls note that to the best of my knowledge there is no IPR issue involved with this draft. In addition, I have not heard any objection re publishing this as well. I'll finalize the shepherd's writeup soon. Thanks again. Best. Bhumip On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim wrote: > > Bhumip has graciously agreed to shepherd the CEHA draft: > https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/ > > This the last outstanding document from the previous charter that > has not started the publication journey. > > Thanks Bhumip. > > cheers, > jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > --001a11c2441404153e04de41a8c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Jamal.
=A0
Pls note that to the best of my knowledge there is no IPR issue involv= ed with this draft.
=A0
In addition, I have not heard any objection re publishing this as well= .
=A0
I'll finalize the shepherd's writeup soon. Thanks again.
=A0
Best.
=A0
Bhumip


=A0
On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Sali= m <hadi@mojatatu.com> wrote:

Bhumip has graciously agreed to shepherd the CEHA draft:=A0
https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/

This the last outstanding document from the previous charter that
has not started the publication journey.

Thanks Bhumip.

cheers,
jamal

_______________________________________________forces mailing list
forces@ietf.org=
https://www.ietf.org/mailman/listinfo/forces




=A0 --001a11c2441404153e04de41a8c2-- From hadi@mojatatu.com Mon Jun 3 09:38:26 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48EB21F942B for ; Mon, 3 Jun 2013 09:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Rvsp4IEdSvh for ; Mon, 3 Jun 2013 09:38:26 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3721F8DDD for ; Mon, 3 Jun 2013 09:38:26 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so3061853vea.29 for ; Mon, 03 Jun 2013 09:38:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=4X2gQS6UPlTsPdgo5pWG00pxZsZItqLyvh32aVhGclM=; b=i8qdGwNo0QfYWfoO4gabywKbJfvCq2kojiMHuofZrSH2EpFKSVhZ9bKyHlib6byAFb tjnzXQQbEA1IqkZH8nhtmbn0MSKUAlhJ1MlfV/mTUZ3u3eGxP+HJSOs67aZmJjBflsTC MalgPTf7BUXXqqSjuecy7eu/0kvwKLK8l3ifPIngDLM07rRItP/FiUScMEYO89NUR3nV D8rWjk5ITul7DHSfHxdT+ki7H9h71skytR7gi1uavhNVsaxKpsSWTdn211m6JkZ6Wf5d XfRb4YWclk1AhLrNGWJprzZJXCwxyB9x1mzIKnQjk0VeS978YcB24ouAs4SRg3cE+Wmr ZbEQ== X-Received: by 10.52.26.140 with SMTP id l12mr14589869vdg.29.1370277505542; Mon, 03 Jun 2013 09:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.206.13 with HTTP; Mon, 3 Jun 2013 09:38:05 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Mon, 3 Jun 2013 12:38:05 -0400 Message-ID: To: "B.Khasnabish@ieee.org" Content-Type: multipart/alternative; boundary=20cf307cfcc6f6489504de4297db X-Gm-Message-State: ALoCoQk8dPFHoLFZM/49W2pvYXGFPdbAZZb7UDj48zRXkmpjRIRS+SjsaJmE8XJh3t/pUCav8HbV Cc: "forces@ietf.org" , Bhumip-ZTE Khasnabish Subject: Re: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 16:38:27 -0000 --20cf307cfcc6f6489504de4297db Content-Type: text/plain; charset=ISO-8859-1 Thanks Bhumip. I can verify that no IPR issues were ever brought up by the authors or any one attending the WG or on the lists over the years in regards to the contents of this document. cheers, jamal On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org wrote: > Thanks Jamal. > > Pls note that to the best of my knowledge there is no IPR issue involved > with this draft. > > In addition, I have not heard any objection re publishing this as well. > > I'll finalize the shepherd's writeup soon. Thanks again. > > Best. > > Bhumip > > > > On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim wrote: > >> >> Bhumip has graciously agreed to shepherd the CEHA draft: >> https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/ >> >> This the last outstanding document from the previous charter that >> has not started the publication journey. >> >> Thanks Bhumip. >> >> cheers, >> jamal >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> >> > > > --20cf307cfcc6f6489504de4297db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Bhumip.
I can verify that no IPR issues w= ere ever brought up by the authors or any one
attending the= WG or on the lists over the years in regards to the contents of this
document.

cheers,
jamal


On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org <vumip1@gmail.com> wrote:=
Thanks Jamal.
=A0
Pls note that to the best of my knowledge there is no IPR issue involv= ed with this draft.
=A0
In addition, I have not heard any objection re publishing this as well= .
=A0
I'll finalize the shepherd's writeup soon. Thanks again.
=A0
Best.
=A0
Bhumip


=A0
On Thu, May 23, 2013 at 8= :47 AM, Jamal Hadi Salim <hadi@mojatatu.com> wrote:

Bhumip has graciously agreed to shepherd the CEHA draft:=A0
https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/

This the last outstanding document from the previous charter that
has not started the publication journey.

Thanks Bhumip.

cheers,
jamal

_____________________________________= __________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo= /forces




=A0

--20cf307cfcc6f6489504de4297db-- From iesg-secretary@ietf.org Mon Jun 3 10:59:25 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7871821F8E89; Mon, 3 Jun 2013 10:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggw2r8gF9BLX; Mon, 3 Jun 2013 10:59:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4768421F8F4A; Mon, 3 Jun 2013 10:57:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603175758.26772.38518.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 10:57:58 -0700 Cc: forces mailing list , forces chair , RFC Editor Subject: [forces] Document Action: 'Interoperability Report for Forwarding and Control Element Separation (ForCES)' to Informational RFC (draft-ietf-forces-interop-09.txt) X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:59:25 -0000 The IESG has approved the following document: - 'Interoperability Report for Forwarding and Control Element Separation (ForCES)' (draft-ietf-forces-interop-09.txt) as Informational RFC This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-forces-interop/ Technical Summary This document captures results of the second Forwarding and Control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. RFC 6053 reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. Working Group Summary The Working Group reviewed the document, and is happy with the contents. The test participants feel it accurately reflects the interoperability tests. Document Quality This document provides a clear description of the testing arrangements, the interoperability tests that were run, and the results of those tests. Personnel Joel Halpern is the Document Shepherd. Adrian Farrel is the Responsible Area Director. From vumip1@gmail.com Tue Jun 4 11:17:46 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3B821F99BC for ; Tue, 4 Jun 2013 11:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdk+6oPKgVQc for ; Tue, 4 Jun 2013 11:17:41 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id C83C021F9CF4 for ; Tue, 4 Jun 2013 10:35:19 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm9so467325wib.0 for ; Tue, 04 Jun 2013 10:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ORtPw2h61Yj5+9zwSMnD6eQRYMQG5a3OR6i/zJtTXCg=; b=XL++1TwZJQffr0FbbyVByxgbkQV+h7JkpIhk2HPf15ucr/o/zZyscjyQt9fAplpUoF XumTs6YKcui7zKBBllXdzwxH/LnvFoCOLejDWAkCxy7a0AhfZ/DneDSk9U0txCFZy/pG /CcMs8dk17585H0JCyYzUhU/E4JKIwBaM2z/X6vyJzxB4MUEadxd1LkCYAK1UUOYzhL4 k8/AjQT0J+ju2pVWfc7SoloceB+5LwjOhtdjtY2GdUXj+/8elbI1R6TtLQz1tjnTi2KQ i9jaf6R0UZGnA141j85Nsh0oAGP9Yu6KVzCnzBD/fZ0eg9DYKkgI9k5gJJN/hP9v//Zd uvqA== MIME-Version: 1.0 X-Received: by 10.180.9.195 with SMTP id c3mr2501971wib.61.1370367308125; Tue, 04 Jun 2013 10:35:08 -0700 (PDT) Received: by 10.217.127.10 with HTTP; Tue, 4 Jun 2013 10:35:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Jun 2013 13:35:07 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: Jamal Hadi Salim Content-Type: multipart/alternative; boundary=001a11c244149cde0604de5780cd Cc: "forces@ietf.org" , Bhumip-ZTE Khasnabish Subject: Re: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:17:46 -0000 --001a11c244149cde0604de5780cd Content-Type: text/plain; charset=ISO-8859-1 Hi Jamal, Thanks for confirming the IPR related matters. PLS note that I found the following ID nits by checking the draft ( http://www.ietf.org/id/draft-ietf-forcesceha-07.txt) through the website: http://www.ietf.org/tools/idnits/ The question is whether the draft should be revised based on the reqd. fixes before publishing. Thanks. Best. Bhumip +++++++++++++++++++++START++++++++++++++++++++++++ idnits 2.12.17 /tmp/draft-ietf-forces-ceha-07.txt: /tmp/draft-ietf-forces-ceha-07.txt(90): update_references( The following definitions are taken from [RFC3654]and [RFC3746]:) . /tmp/draft-ietf-forces-ceha-07.txt(96): update_references( the ForCES Framework in [RFC3746].) . /tmp/draft-ietf-forces-ceha-07.txt(100): update_references( transfer mechanisms as defined in [RFC5810].) . /tmp/draft-ietf-forces-ceha-07.txt(229): update_references( by the FEPO LFB in [RFC5810], Appendix B. In Section 3.1 of this) . /tmp/draft-ietf-forces-ceha-07.txt(247): update_references( 1. To describe with more clarity (than [RFC5810]) how current cold-) . /tmp/draft-ietf-forces-ceha-07.txt(250): update_references( 2. To describe how to evolve the [RFC5810] cold-standby setup to a) . /tmp/draft-ietf-forces-ceha-07.txt(267): update_references( The design intent of the current [RFC5810] as well as this document) . /tmp/draft-ietf-forces-ceha-07.txt(271): update_references( setup in [RFC5810]:) . /tmp/draft-ietf-forces-ceha-07.txt(313): RFC 2119 keyword: To achieve CE High Availability (HA), FEs and CEs MUST inter-operate. /tmp/draft-ietf-forces-ceha-07.txt(314): update_references( per [RFC5810] definition which is repeated for contextual reasons in) . /tmp/draft-ietf-forces-ceha-07.txt(316): RFC 2119 keyword: MUST be implemented by CEs and FEs requiring HA, the Fr plane is out. /tmp/draft-ietf-forces-ceha-07.txt(377): update_references( a detected failure. The FEObject FEState component [RFC5812] defines) . /tmp/draft-ietf-forces-ceha-07.txt(380): update_references( and can turn it on by setting it to OperEnable. Note: [RFC5812]) . /tmp/draft-ietf-forces-ceha-07.txt(425): Line has weird spacing: '... |try v...' /tmp/draft-ietf-forces-ceha-07.txt(456): RFC 2119 keyword: communication failure, regardless of how it is detected, MUST be. /tmp/draft-ietf-forces-ceha-07.txt(468): RFC 2119 keyword: timer [RFC5810] is started. The FE MAY continue to forward packets. /tmp/draft-ietf-forces-ceha-07.txt(468): update_references( timer [RFC5810] is started. The FE MAY continue to forward packets) . /tmp/draft-ietf-forces-ceha-07.txt(476): update_references( bring down its forwarding path (and set the [RFC5812] FEObject) . /tmp/draft-ietf-forces-ceha-07.txt(538): RFC 2119 keyword: MUST configure the FE to make it aware which CE is the master and MAY. /tmp/draft-ietf-forces-ceha-07.txt(657): RFC 2119 keyword: CE (lowest table index) in the AllCEs table MUST be the first CE that. /tmp/draft-ietf-forces-ceha-07.txt(662): RFC 2119 keyword: FE MUST associate with at least one CE. Upon a successful. /tmp/draft-ietf-forces-ceha-07.txt(678): RFC 2119 keyword: FE. Configuration messages (SET/DEL) from backup CEs MUST be dropped. /tmp/draft-ietf-forces-ceha-07.txt(710): Line is too long: the offending characters are '+' /tmp/draft-ietf-forces-ceha-07.txt(711): Line is too long: the offending characters are '|' /tmp/draft-ietf-forces-ceha-07.txt(712): Line is too long: the offending characters are 'v' /tmp/draft-ietf-forces-ceha-07.txt(712): Line has weird spacing: '...ociated v...' /tmp/draft-ietf-forces-ceha-07.txt(713): Line is too long: the offending characters are '|' /tmp/draft-ietf-forces-ceha-07.txt(713): Line has weird spacing: '...)|CE or retry...' /tmp/draft-ietf-forces-ceha-07.txt(714): Line is too long: the offending characters are '|' /tmp/draft-ietf-forces-ceha-07.txt(715): Line is too long: the offending characters are '+' /tmp/draft-ietf-forces-ceha-07.txt(779): RFC 2119 keyword: associating with the master CE, MUST attempt to connect and associate. /tmp/draft-ietf-forces-ceha-07.txt(792): RFC 2119 keyword: FE MAY flag them as unreachable to avoid continuous attempts to. /tmp/draft-ietf-forces-ceha-07.txt(793): RFC 2119 keyword: connect. The FE MAY retry to reassociate with unreachable CEs when. /tmp/draft-ietf-forces-ceha-07.txt(797): RFC 2119 keyword: FE MUST try to find the first associated CE from the list of all CEs. /tmp/draft-ietf-forces-ceha-07.txt(801): RFC 2119 keyword: it MUST attempt to connect and associate with the first from the list. /tmp/draft-ietf-forces-ceha-07.txt(835): update_references( Security consideration as defined in section 9 of [RFC5810] applies.) . /tmp/draft-ietf-forces-ceha-07.txt(850): update_references( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.) . /tmp/draft-ietf-forces-ceha-07.txt(855): update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. /tmp/draft-ietf-forces-ceha-07.txt(860): update_references( [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.) . /tmp/draft-ietf-forces-ceha-07.txt(864): update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.) . /tmp/draft-ietf-forces-ceha-07.txt(868): update_references( [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.) . /tmp/draft-ietf-forces-ceha-07.txt(869): Appendix start: Appendix A. New FEPO version. /tmp/draft-ietf-forces-ceha-07.txt(871): update_references( The xml has been validated against the schema defined in [RFC5812].) . update_references( The following definitions are taken from [RFC3654]and [RFC3746]:) update_references( the ForCES Framework in [RFC3746].) update_references( transfer mechanisms as defined in [RFC5810].) update_references( by the FEPO LFB in [RFC5810], Appendix B. In Section 3.1 of this) update_references( 1. To describe with more clarity (than [RFC5810]) how current cold-) update_references( 2. To describe how to evolve the [RFC5810] cold-standby setup to a) update_references( The design intent of the current [RFC5810] as well as this document) update_references( setup in [RFC5810]:) update_references( per [RFC5810] definition which is repeated for contextual reasons in) update_references( a detected failure. The FEObject FEState component [RFC5812] defines) update_references( and can turn it on by setting it to OperEnable. Note: [RFC5812]) update_references( timer [RFC5810] is started. The FE MAY continue to forward packets) update_references( bring down its forwarding path (and set the [RFC5812] FEObject) update_references( Security consideration as defined in section 9 of [RFC5810] applies.) update_references( [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.) ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010.) ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010. update_references( [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003.) ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003. update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.) ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. update_references( [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.) ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010. Appendix start: Appendix A. New FEPO version update_references( The xml has been validated against the schema defined in [RFC5812].) Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--). Errors MUST be fixed before draft submission. Flaws SHOULD be fixed before draft submission. Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): --------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: --------------------------------------------------------------------------- No issues found here. Running in submission checking mode -- *not* checking nits according to http://www.ietf.org/id-info/checklist . --------------------------------------------------------------------------- No nits found. +++++++++++++++++++++END++++++++++++++++++++++++ On Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim wrote: > Thanks Bhumip. > I can verify that no IPR issues were ever brought up by the authors or any > one > attending the WG or on the lists over the years in regards to the contents > of this > document. > > cheers, > jamal > > > On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org wrote: > >> Thanks Jamal. >> >> Pls note that to the best of my knowledge there is no IPR issue involved >> with this draft. >> >> In addition, I have not heard any objection re publishing this as well. >> >> I'll finalize the shepherd's writeup soon. Thanks again. >> >> Best. >> >> Bhumip >> >> >> >> On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim wrote: >> >>> >>> Bhumip has graciously agreed to shepherd the CEHA draft: >>> https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/ >>> >>> This the last outstanding document from the previous charter that >>> has not started the publication journey. >>> >>> Thanks Bhumip. >>> >>> cheers, >>> jamal >>> >>> _______________________________________________ >>> forces mailing list >>> forces@ietf.org >>> https://www.ietf.org/mailman/listinfo/forces >>> >>> >> >> >> > > > --001a11c244149cde0604de5780cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jamal,
=A0<= /div>
Thanks for confirming the IPR related matters.
=A0
PLS note that I found the following ID nits by checking the draft (http://www.ie= tf.org/id/draft-ietf-forcesceha-07.txt) through the website:
=A0
The question is whether the draft should be revised based
on the reqd. fixes before publishing= . Thanks.
=A0
Best.
=A0
Bhumip
=A0
+++++++++++++++++++++START++++++++++++++++++++++++

idnits = 2.12.17

/tmp/draft-ietf-forces-ceha-07.txt:

/tmp/draft-ietf-forces-ceha-07.txt(90): update_references= ( The following

definitions are taken from [RFC3654]and [RFC3746]:)

.

/tmp/draft-ietf-forces-ceha-07.txt(96): update_references= ( the ForCES

Framework in [RFC3746].)

.

/tmp/draft-ietf-forces-ceha-07.txt(100): update_reference= s( transfer

mechanisms as defined in [RFC5810].)

.

/tmp/draft-ietf-forces-ceha-07.txt(229): update_reference= s( by the FEPO

LFB in [RFC5810], Appendix B. In Section 3.1 of this)

.

/tmp/draft-ietf-forces-ceha-07.txt(247): update_reference= s( 1. To

describe with more clarity (than [RFC5810]) how current c= old-)

.

/tmp/draft-ietf-forces-ceha-07.txt(250): update_reference= s( 2. To

describe how to evolve the [RFC5810] cold-standby setup t= o a)

.

/tmp/draft-ietf-forces-ceha-07.txt(267): update_reference= s( The design

intent of the current [RFC5810] as well as this document)=

.

/tmp/draft-ietf-forces-ceha-07.txt(271): update_reference= s( setup in

[RFC5810]:)

.

/tmp/draft-ietf-forces-ceha-07.txt(313): RFC 2119 keyword= : To achieve CE

High Availability (HA), FEs and CEs MUST inter-operate.

/tmp/draft-ietf-forces-ceha-07.txt(314): update_reference= s( per [RFC5810]

definition which is repeated for contextual reasons in)

.

/tmp/draft-ietf-forces-ceha-07.txt(316): RFC 2119 keyword= : MUST be

implemented by CEs and FEs requiring HA, the Fr plane is = out.

/tmp/draft-ietf-forces-ceha-07.txt(377): update_reference= s( a detected

failure. The FEObject FEState component [RFC5812] defines= )

.

/tmp/draft-ietf-forces-ceha-07.txt(380): update_reference= s( and can turn

it on by setting it to OperEnable. Note: [RFC5812])

.

/tmp/draft-ietf-forces-ceha-07.txt(425): Line has weird s= pacing: '... |try

v...'

/tmp/draft-ietf-forces-ceha-07.txt(456): RFC 2119 keyword= : communication

failure, regardless of how it is detected, MUST be.

<= p align=3D"LEFT">/tmp/draft-ietf-forces-ceha-07.txt(468): RFC 2119 keyword:= timer [RFC5810]

is started. The FE MAY continue to forward packets.

/tmp/draft-ietf-forces-ceha-07.txt(468): update_reference= s( timer

[RFC5810] is started. The FE MAY continue to forward pack= ets)

.

/tmp/draft-ietf-forces-ceha-07.txt(476): update_reference= s( bring down its

forwarding path (and set the [RFC5812] FEObject)

.

/tmp/draft-ietf-forces-ceha-07.txt(538): RFC 2119 keyword= : MUST configure

the FE to make it aware which CE is the master and MAY.

/tmp/draft-ietf-forces-ceha-07.txt(657): RFC 2119 keyword= : CE (lowest

table index) in the AllCEs table MUST be the first CE tha= t.

/tmp/draft-ietf-forces-ceha-07.txt(662): RFC 2119 keyword= : FE MUST

associate with at least one CE. Upon a successful.

/tmp/draft-ietf-forces-ceha-07.txt(678): RFC 2119 keyword= : FE.

Configuration messages (SET/DEL) from backup CEs MUST be = dropped.

/tmp/draft-ietf-forces-ceha-07.txt(710): Line is too long= : the offending

characters are '+'

/tmp/draft-ietf-forces-ceha-07.txt(711): Line is too long= : the offending

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(712): Line is too long= : the offending

characters are 'v'

/tmp/draft-ietf-forces-ceha-07.txt(712): Line has weird s= pacing: '...ociated

v...'

/tmp/draft-ietf-forces-ceha-07.txt(713): Line is too long= : the offending

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(713): Line has weird s= pacing: '...)|CE or

retry...'

/tmp/draft-ietf-forces-ceha-07.txt(714): Line is too long= : the offending

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(715): Line is too long= : the offending

characters are '+'

/tmp/draft-ietf-forces-ceha-07.txt(779): RFC 2119 keyword= : associating

with the master CE, MUST attempt to connect and associate= .

/tmp/draft-ietf-forces-ceha-07.txt(792): RFC 2119 keyword= : FE MAY flag

them as unreachable to avoid continuous attempts to.

/tmp/draft-ietf-forces-ceha-07.txt(793): RFC 2119 keyword= : connect. The

FE MAY retry to reassociate with unreachable CEs when.

/tmp/draft-ietf-forces-ceha-07.txt(797): RFC 2119 keyword= : FE MUST try to

find the first associated CE from the list of all CEs.

/tmp/draft-ietf-forces-ceha-07.txt(801): RFC 2119 keyword= : it MUST attempt

to connect and associate with the first from the list.

/tmp/draft-ietf-forces-ceha-07.txt(835): update_reference= s( Security

consideration as defined in section 9 of [RFC5810] applie= s.)

.

/tmp/draft-ietf-forces-ceha-07.txt(850): update_reference= s( [RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate = Requirement Levels", BCP

14, RFC 2119, March 1997.)

.

/tmp/draft-ietf-forces-ceha-07.txt(855): update_reference= s( [RFC5810] Doria,

A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Don= g, L., Gopal, R.,

and J. Halpern, "Forwarding and Control Element Sepa= ration (ForCES) Protocol

Specification", RFC 5810, March 2010.

/tmp/draft-ietf-forces-ceha-07.txt(860): update_references( [RFC3= 654]

Khosravi, H. and T. Anderson, "Requirements for Sepa= ration of IP Control and

Forwarding", RFC 3654, November 2003.)

.

/tmp/draft-ietf-forces-ceha-07.txt(864): update_reference= s( [RFC3746] Yang,

L., Dantu, R., Anderson, T., and R. Gopal, "Forwardi= ng and Control Element

Separation (ForCES) Framework", RFC 3746, April 2004= .)

.

/tmp/draft-ietf-forces-ceha-07.txt(868): update_reference= s( [RFC5812]

Halpern, J. and J. Hadi Salim, "Forwarding and Contr= ol Element Separation

(ForCES) Forwarding Element Model", RFC 5812, March = 2010.)

.

/tmp/draft-ietf-forces-ceha-07.txt(869): Appendix start: = Appendix A. New

FEPO version.

/tmp/draft-ietf-forces-ceha-07.txt(871): update_reference= s( The xml has

been validated against the schema defined in [RFC5812].)<= /p>

.

update_references( The following definitions are taken fr= om

[RFC3654]and [RFC3746]:)

update_references( the ForCES Framework in [RFC3746].)

update_references( transfer mechanisms as defined in [RFC= 5810].)

update_references( by the FEPO LFB in [RFC5810], Appendix= B. In

Section 3.1 of this)

update_references( 1. To describe with more clarity (than= [RFC5810])

how current cold-)

update_references( 2. To describe how to evolve the [RFC5= 810]

cold-standby setup to a)

update_references( The design intent of the current [RFC5= 810] as well

as this document)

update_references( setup in [RFC5810]:)

update_references( per [RFC5810] definition which is repe= ated for

contextual reasons in)

update_references( a detected failure. The FEObject FESta= te

component [RFC5812] defines)

update_references( and can turn it on by setting it to Op= erEnable.

Note: [RFC5812])

update_references( timer [RFC5810] is started. The FE MAY= continue

to forward packets)

update_references( bring down its forwarding path (and se= t the

[RFC5812] FEObject)

=A0

<= p align=3D"LEFT">

=A0

update_references( Security consideration as defined in section 9= of

[RFC5810] applies.)

update_references( [RFC2119] Bradner, S., "Key words= for use in RFCs to

Indicate Requirement Levels", BCP 14, RFC 2119, Marc= h 1997.)

ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key= words for use in

RFCs to Indicate Requirement Levels", BCP 14, RFC 21= 19, March 1997.

update_references( [RFC5810] Doria, A., Hadi Salim, J., H= aas, R.,

Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpe= rn, "Forwarding

and Control Element Separation (ForCES) Protocol Specific= ation", RFC

5810, March 2010.)

ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim,= J., Haas,

R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. H= alpern,

"Forwarding and Control Element Separation (ForCES) = Protocol

Specification", RFC 5810, March 2010.

update_references( [RFC3654] Khosravi, H. and T. Anderson= ,

"Requirements for Separation of IP Control and Forwa= rding", RFC 3654,

November 2003.)

ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. An= derson,

"Requirements for Separation of IP Control and Forwa= rding", RFC 3654,

November 2003.

update_references( [RFC3746] Yang, L., Dantu, R., Anderso= n, T., and R.

Gopal, "Forwarding and Control Element Separation (F= orCES) Framework",

RFC 3746, April 2004.)

ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., A= nderson, T.,

and R. Gopal, "Forwarding and Control Element Separa= tion (ForCES)

Framework", RFC 3746, April 2004.

update_references( [RFC5812] Halpern, J. and J. Hadi Sali= m, "Forwarding

and Control Element Separation (ForCES) Forwarding Elemen= t Model", RFC

5812, March 2010.)

ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Had= i Salim,

"Forwarding and Control Element Separation (ForCES) = Forwarding Element

Model", RFC 5812, March 2010.

Appendix start: Appendix A. New FEPO version

update_references( The xml has been validated against the= schema

defined in [RFC5812].)

Showing Errors (**), Flaws (~~), Warnings (=3D=3D), and C= omments (--).

Errors MUST be fixed before draft submission. Flaws SHOUL= D be fixed before

draft submission.

Checking boilerplate required by RFC 5378 and the IETF Tr= ust (see

http://t= rustee.ietf.org/license-info):

= =A0

------------------------------------------------------------------------= ---

No issues found here.

Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt= :

---------------------------------------------------------= ------------------

No issues found here.

Running in submission checking mode -- *not* checking nit= s according to

http://= www.ietf.org/id-info/checklist .

---------------------------------------------------------= ------------------

No nits found.

+++++++++++++++++++++= END++++++++++++++++++++++++
=
On Mon, Jun 3, 2013 at 12:38 PM, Jamal Had= i Salim <hadi@mojatatu.com> wrote:
Thanks Bhumip.
I can verify that no I= PR issues were ever brought up by the authors or any one
attending the WG or on the lists over the years in regards to the cont= ents of this
document.

cheers,
jamal
=


=
On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org <vumi= p1@gmail.com> wrote:
Thanks Jamal.
=A0
Pls note that to the best of my knowledge there is no IPR issue involv= ed with this draft.
=A0
In addition, I have not heard any objection re publishing this as well= .
=A0
I'll finalize the shepherd's writeup soon. Thanks again.
=A0
Best.
=A0
Bhumip


=A0
On Thu, May 23, 2013 at 8:47 AM, Jamal= Hadi Salim <hadi@mojatatu.com> wrote:

Bhumip has graciously agreed to shepherd the CEHA draft:=A0
https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/

This the last outstanding document from the previous charter that
has not started the publication journey.

Thanks Bhumip.

cheers,
jamal

_____________________________________= __________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo= /forces




=A0


=A0
--001a11c244149cde0604de5780cd-- From joel@stevecrocker.com Tue Jun 4 11:43:56 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3133421F994C for ; Tue, 4 Jun 2013 11:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zd4lA-npWIx for ; Tue, 4 Jun 2013 11:43:52 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9E79F21F8E93 for ; Tue, 4 Jun 2013 11:38:00 -0700 (PDT) Received: from dummy.name; Tue, 04 Jun 2013 18:37:59 +0000 Message-ID: <51AE33FE.2080309@stevecrocker.com> Date: Tue, 04 Jun 2013 14:37:50 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "B.Khasnabish@ieee.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" , Bhumip-ZTE Khasnabish Subject: Re: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:43:56 -0000 None of those warnings warrant a respin. If the draft gets spun for some other reason, and if we have not added any any 2119 language to the draft, then we should remove the reference. Yours, Joel On 6/4/2013 1:35 PM, B.Khasnabish@ieee.org wrote: > Hi Jamal, > Thanks for confirming the IPR related matters. > PLS note that I found the following ID nits by checking the draft > (http://www.ietf.org/id/draft-ietf-forcesceha-07.txt) through the website: > http://www.ietf.org/tools/idnits/ > The question is whether the draft should be revised based > on the reqd. fixes before publishing. Thanks. > Best. > Bhumip > +++++++++++++++++++++START++++++++++++++++++++++++ > > idnits 2.12.17 > > /tmp/draft-ietf-forces-ceha-07.txt: > > /tmp/draft-ietf-forces-ceha-07.txt(90): update_references( The following > > definitions are taken from [RFC3654]and [RFC3746]:) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(96): update_references( the ForCES > > Framework in [RFC3746].) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(100): update_references( transfer > > mechanisms as defined in [RFC5810].) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(229): update_references( by the FEPO > > LFB in [RFC5810], Appendix B. In Section 3.1 of this) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(247): update_references( 1. To > > describe with more clarity (than [RFC5810]) how current cold-) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(250): update_references( 2. To > > describe how to evolve the [RFC5810] cold-standby setup to a) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(267): update_references( The design > > intent of the current [RFC5810] as well as this document) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(271): update_references( setup in > > [RFC5810]:) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(313): RFC 2119 keyword: To achieve CE > > High Availability (HA), FEs and CEs MUST inter-operate. > > /tmp/draft-ietf-forces-ceha-07.txt(314): update_references( per [RFC5810] > > definition which is repeated for contextual reasons in) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(316): RFC 2119 keyword: MUST be > > implemented by CEs and FEs requiring HA, the Fr plane is out. > > /tmp/draft-ietf-forces-ceha-07.txt(377): update_references( a detected > > failure. The FEObject FEState component [RFC5812] defines) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(380): update_references( and can turn > > it on by setting it to OperEnable. Note: [RFC5812]) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(425): Line has weird spacing: '... |try > > v...' > > /tmp/draft-ietf-forces-ceha-07.txt(456): RFC 2119 keyword: communication > > failure, regardless of how it is detected, MUST be. > > /tmp/draft-ietf-forces-ceha-07.txt(468): RFC 2119 keyword: timer [RFC5810] > > is started. The FE MAY continue to forward packets. > > /tmp/draft-ietf-forces-ceha-07.txt(468): update_references( timer > > [RFC5810] is started. The FE MAY continue to forward packets) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(476): update_references( bring down its > > forwarding path (and set the [RFC5812] FEObject) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(538): RFC 2119 keyword: MUST configure > > the FE to make it aware which CE is the master and MAY. > > /tmp/draft-ietf-forces-ceha-07.txt(657): RFC 2119 keyword: CE (lowest > > table index) in the AllCEs table MUST be the first CE that. > > /tmp/draft-ietf-forces-ceha-07.txt(662): RFC 2119 keyword: FE MUST > > associate with at least one CE. Upon a successful. > > /tmp/draft-ietf-forces-ceha-07.txt(678): RFC 2119 keyword: FE. > > Configuration messages (SET/DEL) from backup CEs MUST be dropped. > > /tmp/draft-ietf-forces-ceha-07.txt(710): Line is too long: the offending > > characters are '+' > > /tmp/draft-ietf-forces-ceha-07.txt(711): Line is too long: the offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-07.txt(712): Line is too long: the offending > > characters are 'v' > > /tmp/draft-ietf-forces-ceha-07.txt(712): Line has weird spacing: '...ociated > > v...' > > /tmp/draft-ietf-forces-ceha-07.txt(713): Line is too long: the offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-07.txt(713): Line has weird spacing: '...)|CE or > > retry...' > > /tmp/draft-ietf-forces-ceha-07.txt(714): Line is too long: the offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-07.txt(715): Line is too long: the offending > > characters are '+' > > /tmp/draft-ietf-forces-ceha-07.txt(779): RFC 2119 keyword: associating > > with the master CE, MUST attempt to connect and associate. > > /tmp/draft-ietf-forces-ceha-07.txt(792): RFC 2119 keyword: FE MAY flag > > them as unreachable to avoid continuous attempts to. > > /tmp/draft-ietf-forces-ceha-07.txt(793): RFC 2119 keyword: connect. The > > FE MAY retry to reassociate with unreachable CEs when. > > /tmp/draft-ietf-forces-ceha-07.txt(797): RFC 2119 keyword: FE MUST try to > > find the first associated CE from the list of all CEs. > > /tmp/draft-ietf-forces-ceha-07.txt(801): RFC 2119 keyword: it MUST attempt > > to connect and associate with the first from the list. > > /tmp/draft-ietf-forces-ceha-07.txt(835): update_references( Security > > consideration as defined in section 9 of [RFC5810] applies.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(850): update_references( [RFC2119] > > Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP > > 14, RFC 2119, March 1997.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(855): update_references( [RFC5810] Doria, > > A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., > > and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol > > Specification", RFC 5810, March 2010. > > /tmp/draft-ietf-forces-ceha-07.txt(860): update_references( [RFC3654] > > Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and > > Forwarding", RFC 3654, November 2003.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(864): update_references( [RFC3746] Yang, > > L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element > > Separation (ForCES) Framework", RFC 3746, April 2004.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(868): update_references( [RFC5812] > > Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation > > (ForCES) Forwarding Element Model", RFC 5812, March 2010.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(869): Appendix start: Appendix A. New > > FEPO version. > > /tmp/draft-ietf-forces-ceha-07.txt(871): update_references( The xml has > > been validated against the schema defined in [RFC5812].) > > . > > update_references( The following definitions are taken from > > [RFC3654]and [RFC3746]:) > > update_references( the ForCES Framework in [RFC3746].) > > update_references( transfer mechanisms as defined in [RFC5810].) > > update_references( by the FEPO LFB in [RFC5810], Appendix B. In > > Section 3.1 of this) > > update_references( 1. To describe with more clarity (than [RFC5810]) > > how current cold-) > > update_references( 2. To describe how to evolve the [RFC5810] > > cold-standby setup to a) > > update_references( The design intent of the current [RFC5810] as well > > as this document) > > update_references( setup in [RFC5810]:) > > update_references( per [RFC5810] definition which is repeated for > > contextual reasons in) > > update_references( a detected failure. The FEObject FEState > > component [RFC5812] defines) > > update_references( and can turn it on by setting it to OperEnable. > > Note: [RFC5812]) > > update_references( timer [RFC5810] is started. The FE MAY continue > > to forward packets) > > update_references( bring down its forwarding path (and set the > > [RFC5812] FEObject) > > update_references( Security consideration as defined in section 9 of > > [RFC5810] applies.) > > update_references( [RFC2119] Bradner, S., "Key words for use in RFCs to > > Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.) > > ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key words for use in > > RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. > > update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R., > > Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding > > and Control Element Separation (ForCES) Protocol Specification", RFC > > 5810, March 2010.) > > ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim, J., Haas, > > R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, > > "Forwarding and Control Element Separation (ForCES) Protocol > > Specification", RFC 5810, March 2010. > > update_references( [RFC3654] Khosravi, H. and T. Anderson, > > "Requirements for Separation of IP Control and Forwarding", RFC 3654, > > November 2003.) > > ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. Anderson, > > "Requirements for Separation of IP Control and Forwarding", RFC 3654, > > November 2003. > > update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. > > Gopal, "Forwarding and Control Element Separation (ForCES) Framework", > > RFC 3746, April 2004.) > > ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., Anderson, T., > > and R. Gopal, "Forwarding and Control Element Separation (ForCES) > > Framework", RFC 3746, April 2004. > > update_references( [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding > > and Control Element Separation (ForCES) Forwarding Element Model", RFC > > 5812, March 2010.) > > ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Hadi Salim, > > "Forwarding and Control Element Separation (ForCES) Forwarding Element > > Model", RFC 5812, March 2010. > > Appendix start: Appendix A. New FEPO version > > update_references( The xml has been validated against the schema > > defined in [RFC5812].) > > Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--). > > Errors MUST be fixed before draft submission. Flaws SHOULD be fixed before > > draft submission. > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > > http://trustee.ietf.org/license-info): > > --------------------------------------------------------------------------- > > No issues found here. > > Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: > > --------------------------------------------------------------------------- > > No issues found here. > > Running in submission checking mode -- *not* checking nits according to > > http://www.ietf.org/id-info/checklist . > > --------------------------------------------------------------------------- > > No nits found. > > +++++++++++++++++++++END++++++++++++++++++++++++ > > > On Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim > wrote: > > Thanks Bhumip. > I can verify that no IPR issues were ever brought up by the authors > or any one > attending the WG or on the lists over the years in regards to the > contents of this > document. > > cheers, > jamal > > > On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org > > wrote: > > Thanks Jamal. > Pls note that to the best of my knowledge there is no IPR issue > involved with this draft. > In addition, I have not heard any objection re publishing this > as well. > I'll finalize the shepherd's writeup soon. Thanks again. > Best. > Bhumip > > > On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim > > wrote: > > > Bhumip has graciously agreed to shepherd the CEHA draft: > https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/ > > This the last outstanding document from the previous charter > that > has not started the publication journey. > > Thanks Bhumip. > > cheers, > jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > > > > > > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From hadi@mojatatu.com Tue Jun 4 11:43:58 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD2D21F994C for ; Tue, 4 Jun 2013 11:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZwJRwOTBurT for ; Tue, 4 Jun 2013 11:43:56 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7E92B21F9AB0 for ; Tue, 4 Jun 2013 11:38:16 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id 12so445143vbf.4 for ; Tue, 04 Jun 2013 11:38:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=9EAh10jgleIprRSUNm+hlvanMqlm/XVSeIgUkBg2Fb0=; b=Mgjby811/ktCFtMQdCrtWJM7mAmVAL8QEBMdNIsxv0Mt6rUbk9JocmLBQlKQ2TM5pN ADLZDyzUNT5QYBxb6D+3TV3eGwvb0YrjK//kQdBiIDdKCKnx+O5SlkB6rbA0WQ3bVEI8 7O2A31pLF3eJwGstF6Ww+4fRxcglGeO9KgvVE8ytzetirYLbMOBTVUzl3Gqo6O/67Tm/ 3iMP6yCcrWcCGFH55H707t4FD4/kPPfV7QIC4O5vC50fjvsWD2a/DX5bb4qc+50ogv/Y KAOXnu6uNDg7wjxek7u4flx6jcn9w/GmNnGQk2RreF/0Vai5VsMRxa+FrHyZ4QZmqxaJ FhPg== X-Received: by 10.52.165.166 with SMTP id yz6mr16153274vdb.6.1370371095645; Tue, 04 Jun 2013 11:38:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.199 with HTTP; Tue, 4 Jun 2013 11:37:55 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Tue, 4 Jun 2013 14:37:55 -0400 Message-ID: To: "B.Khasnabish@ieee.org" Content-Type: multipart/alternative; boundary=001a11c2088c5e052404de5862c0 X-Gm-Message-State: ALoCoQkcffptNA9OdqnkWAPbDcpe3vdxPqOZtdNoRN73Bs96GOHX4i3o9f1sOTbnDOtYv6skp/6J Cc: Bhumip-ZTE Khasnabish , Joel Halpern , "forces@ietf.org" Subject: Re: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:43:58 -0000 --001a11c2088c5e052404de5862c0 Content-Type: text/plain; charset=ISO-8859-1 Bhumip, It seems there is an error in the nits - although couldnt quite tell what it is. Joel/Adrian: Do we need a republication for this doc to be shepherded? cheers, jamal On Tue, Jun 4, 2013 at 1:35 PM, B.Khasnabish@ieee.org wrote: > Hi Jamal, > > Thanks for confirming the IPR related matters. > > PLS note that I found the following ID nits by checking the draft ( > http://www.ietf.org/id/draft-ietf-forcesceha-07.txt) through the website: > http://www.ietf.org/tools/idnits/ > > The question is whether the draft should be revised based > on the reqd. fixes before publishing. Thanks. > > Best. > > Bhumip > > +++++++++++++++++++++START++++++++++++++++++++++++ > > idnits 2.12.17 > > /tmp/draft-ietf-forces-ceha-07.txt: > > /tmp/draft-ietf-forces-ceha-07.txt(90): update_references( The following > > definitions are taken from [RFC3654]and [RFC3746]:) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(96): update_references( the ForCES > > Framework in [RFC3746].) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(100): update_references( transfer > > mechanisms as defined in [RFC5810].) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(229): update_references( by the FEPO > > LFB in [RFC5810], Appendix B. In Section 3.1 of this) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(247): update_references( 1. To > > describe with more clarity (than [RFC5810]) how current cold-) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(250): update_references( 2. To > > describe how to evolve the [RFC5810] cold-standby setup to a) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(267): update_references( The design > > intent of the current [RFC5810] as well as this document) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(271): update_references( setup in > > [RFC5810]:) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(313): RFC 2119 keyword: To achieve CE > > High Availability (HA), FEs and CEs MUST inter-operate. > > /tmp/draft-ietf-forces-ceha-07.txt(314): update_references( per [RFC5810] > > definition which is repeated for contextual reasons in) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(316): RFC 2119 keyword: MUST be > > implemented by CEs and FEs requiring HA, the Fr plane is out. > > /tmp/draft-ietf-forces-ceha-07.txt(377): update_references( a detected > > failure. The FEObject FEState component [RFC5812] defines) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(380): update_references( and can turn > > it on by setting it to OperEnable. Note: [RFC5812]) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(425): Line has weird spacing: '... |try > > v...' > > /tmp/draft-ietf-forces-ceha-07.txt(456): RFC 2119 keyword: communication > > failure, regardless of how it is detected, MUST be. > > /tmp/draft-ietf-forces-ceha-07.txt(468): RFC 2119 keyword: timer [RFC5810] > > is started. The FE MAY continue to forward packets. > > /tmp/draft-ietf-forces-ceha-07.txt(468): update_references( timer > > [RFC5810] is started. The FE MAY continue to forward packets) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(476): update_references( bring down its > > forwarding path (and set the [RFC5812] FEObject) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(538): RFC 2119 keyword: MUST configure > > the FE to make it aware which CE is the master and MAY. > > /tmp/draft-ietf-forces-ceha-07.txt(657): RFC 2119 keyword: CE (lowest > > table index) in the AllCEs table MUST be the first CE that. > > /tmp/draft-ietf-forces-ceha-07.txt(662): RFC 2119 keyword: FE MUST > > associate with at least one CE. Upon a successful. > > /tmp/draft-ietf-forces-ceha-07.txt(678): RFC 2119 keyword: FE. > > Configuration messages (SET/DEL) from backup CEs MUST be dropped. > > /tmp/draft-ietf-forces-ceha-07.txt(710): Line is too long: the offending > > characters are '+' > > /tmp/draft-ietf-forces-ceha-07.txt(711): Line is too long: the offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-07.txt(712): Line is too long: the offending > > characters are 'v' > > /tmp/draft-ietf-forces-ceha-07.txt(712): Line has weird spacing: > '...ociated > > v...' > > /tmp/draft-ietf-forces-ceha-07.txt(713): Line is too long: the offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-07.txt(713): Line has weird spacing: '...)|CE > or > > retry...' > > /tmp/draft-ietf-forces-ceha-07.txt(714): Line is too long: the offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-07.txt(715): Line is too long: the offending > > characters are '+' > > /tmp/draft-ietf-forces-ceha-07.txt(779): RFC 2119 keyword: associating > > with the master CE, MUST attempt to connect and associate. > > /tmp/draft-ietf-forces-ceha-07.txt(792): RFC 2119 keyword: FE MAY flag > > them as unreachable to avoid continuous attempts to. > > /tmp/draft-ietf-forces-ceha-07.txt(793): RFC 2119 keyword: connect. The > > FE MAY retry to reassociate with unreachable CEs when. > > /tmp/draft-ietf-forces-ceha-07.txt(797): RFC 2119 keyword: FE MUST try to > > find the first associated CE from the list of all CEs. > > /tmp/draft-ietf-forces-ceha-07.txt(801): RFC 2119 keyword: it MUST attempt > > to connect and associate with the first from the list. > > /tmp/draft-ietf-forces-ceha-07.txt(835): update_references( Security > > consideration as defined in section 9 of [RFC5810] applies.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(850): update_references( [RFC2119] > > Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", > BCP > > 14, RFC 2119, March 1997.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(855): update_references( [RFC5810] > Doria, > > A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., > > and J. Halpern, "Forwarding and Control Element Separation (ForCES) > Protocol > > Specification", RFC 5810, March 2010. > > /tmp/draft-ietf-forces-ceha-07.txt(860): update_references( [RFC3654] > > Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control > and > > Forwarding", RFC 3654, November 2003.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(864): update_references( [RFC3746] Yang, > > L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element > > Separation (ForCES) Framework", RFC 3746, April 2004.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(868): update_references( [RFC5812] > > Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation > > (ForCES) Forwarding Element Model", RFC 5812, March 2010.) > > . > > /tmp/draft-ietf-forces-ceha-07.txt(869): Appendix start: Appendix A. New > > FEPO version. > > /tmp/draft-ietf-forces-ceha-07.txt(871): update_references( The xml has > > been validated against the schema defined in [RFC5812].) > > . > > update_references( The following definitions are taken from > > [RFC3654]and [RFC3746]:) > > update_references( the ForCES Framework in [RFC3746].) > > update_references( transfer mechanisms as defined in [RFC5810].) > > update_references( by the FEPO LFB in [RFC5810], Appendix B. In > > Section 3.1 of this) > > update_references( 1. To describe with more clarity (than [RFC5810]) > > how current cold-) > > update_references( 2. To describe how to evolve the [RFC5810] > > cold-standby setup to a) > > update_references( The design intent of the current [RFC5810] as well > > as this document) > > update_references( setup in [RFC5810]:) > > update_references( per [RFC5810] definition which is repeated for > > contextual reasons in) > > update_references( a detected failure. The FEObject FEState > > component [RFC5812] defines) > > update_references( and can turn it on by setting it to OperEnable. > > Note: [RFC5812]) > > update_references( timer [RFC5810] is started. The FE MAY continue > > to forward packets) > > update_references( bring down its forwarding path (and set the > > [RFC5812] FEObject) > > > > > > update_references( Security consideration as defined in section 9 of > > [RFC5810] applies.) > > update_references( [RFC2119] Bradner, S., "Key words for use in RFCs to > > Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.) > > ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key words for use in > > RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. > > update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R., > > Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding > > and Control Element Separation (ForCES) Protocol Specification", RFC > > 5810, March 2010.) > > ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim, J., Haas, > > R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, > > "Forwarding and Control Element Separation (ForCES) Protocol > > Specification", RFC 5810, March 2010. > > update_references( [RFC3654] Khosravi, H. and T. Anderson, > > "Requirements for Separation of IP Control and Forwarding", RFC 3654, > > November 2003.) > > ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. Anderson, > > "Requirements for Separation of IP Control and Forwarding", RFC 3654, > > November 2003. > > update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. > > Gopal, "Forwarding and Control Element Separation (ForCES) Framework", > > RFC 3746, April 2004.) > > ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., Anderson, T., > > and R. Gopal, "Forwarding and Control Element Separation (ForCES) > > Framework", RFC 3746, April 2004. > > update_references( [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding > > and Control Element Separation (ForCES) Forwarding Element Model", RFC > > 5812, March 2010.) > > ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Hadi Salim, > > "Forwarding and Control Element Separation (ForCES) Forwarding Element > > Model", RFC 5812, March 2010. > > Appendix start: Appendix A. New FEPO version > > update_references( The xml has been validated against the schema > > defined in [RFC5812].) > > Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--). > > Errors MUST be fixed before draft submission. Flaws SHOULD be fixed before > > draft submission. > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > > http://trustee.ietf.org/license-info): > > > > --------------------------------------------------------------------------- > > No issues found here. > > Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: > > --------------------------------------------------------------------------- > > No issues found here. > > Running in submission checking mode -- *not* checking nits according to > > http://www.ietf.org/id-info/checklist . > > --------------------------------------------------------------------------- > > No nits found. > > +++++++++++++++++++++END++++++++++++++++++++++++ > > On Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim wrote: > >> Thanks Bhumip. >> I can verify that no IPR issues were ever brought up by the authors or >> any one >> attending the WG or on the lists over the years in regards to the >> contents of this >> document. >> >> cheers, >> jamal >> >> >> On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org wrote: >> >>> Thanks Jamal. >>> >>> Pls note that to the best of my knowledge there is no IPR issue involved >>> with this draft. >>> >>> In addition, I have not heard any objection re publishing this as well. >>> >>> I'll finalize the shepherd's writeup soon. Thanks again. >>> >>> Best. >>> >>> Bhumip >>> >>> >>> >>> On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim wrote: >>> >>>> >>>> Bhumip has graciously agreed to shepherd the CEHA draft: >>>> https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/ >>>> >>>> This the last outstanding document from the previous charter that >>>> has not started the publication journey. >>>> >>>> Thanks Bhumip. >>>> >>>> cheers, >>>> jamal >>>> >>>> _______________________________________________ >>>> forces mailing list >>>> forces@ietf.org >>>> https://www.ietf.org/mailman/listinfo/forces >>>> >>>> >>> >>> >>> >> >> >> > > --001a11c2088c5e052404de5862c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bhumip,

It seems there is an error in t= he nits - although couldnt quite tell
what it is.
Joel/Adrian:
Do we need a republication for this doc= to be shepherded?

cheers,
jamal


On Tue, J= un 4, 2013 at 1:35 PM, B.Khasnabis= h@ieee.org <vumip1@gmail.com> wrote:
Hi Jamal,
=A0
Thanks for confirming the IPR rela= ted matters.
=A0
PLS note that I found the following ID nits by checking = the draft (http://www.ietf.org/id/draft-ietf-forcesceha-07.txt) = through the website:
=A0
The question is whether the draft should be re= vised based
on the reqd. fixes before publishing= . Thanks.
=A0
Best.
=A0
Bhumip
=A0
+++++++++++++++++++++START++++++++++++++++++++++++

idnits = 2.12.17

/tmp/draft-ietf-forces-ceha-07.txt:

/tmp/draft-ietf-forces-ceha-07.txt(90): update_references= ( The following

definitions are taken from [RFC3654]and [RFC3746]:)

.

/tmp/draft-ietf-forces-ceha-07.txt(96): update_references= ( the ForCES

Framework in [RFC3746].)

.

/tmp/draft-ietf-forces-ceha-07.txt(100): update_reference= s( transfer

mechanisms as defined in [RFC5810].)

.

/tmp/draft-ietf-forces-ceha-07.txt(229): update_reference= s( by the FEPO

LFB in [RFC5810], Appendix B. In Section 3.1 of this)

.

/tmp/draft-ietf-forces-ceha-07.txt(247): update_reference= s( 1. To

describe with more clarity (than [RFC5810]) how current c= old-)

.

/tmp/draft-ietf-forces-ceha-07.txt(250): update_reference= s( 2. To

describe how to evolve the [RFC5810] cold-standby setup t= o a)

.

/tmp/draft-ietf-forces-ceha-07.txt(267): update_reference= s( The design

intent of the current [RFC5810] as well as this document)=

.

/tmp/draft-ietf-forces-ceha-07.txt(271): update_reference= s( setup in

[RFC5810]:)

.

/tmp/draft-ietf-forces-ceha-07.txt(313): RFC 2119 keyword= : To achieve CE

High Availability (HA), FEs and CEs MUST inter-operate.

/tmp/draft-ietf-forces-ceha-07.txt(314): update_reference= s( per [RFC5810]

definition which is repeated for contextual reasons in)

.

/tmp/draft-ietf-forces-ceha-07.txt(316): RFC 2119 keyword= : MUST be

implemented by CEs and FEs requiring HA, the Fr plane is = out.

/tmp/draft-ietf-forces-ceha-07.txt(377): update_reference= s( a detected

failure. The FEObject FEState component [RFC5812] defines= )

.

/tmp/draft-ietf-forces-ceha-07.txt(380): update_reference= s( and can turn

it on by setting it to OperEnable. Note: [RFC5812])

.

/tmp/draft-ietf-forces-ceha-07.txt(425): Line has weird s= pacing: '... |try

v...'

/tmp/draft-ietf-forces-ceha-07.txt(456): RFC 2119 keyword= : communication

failure, regardless of how it is detected, MUST be.

<= p align=3D"LEFT">/tmp/draft-ietf-forces-ceha-07.txt(468): RFC 2119 keyword:= timer [RFC5810]

is started. The FE MAY continue to forward packets.

/tmp/draft-ietf-forces-ceha-07.txt(468): update_reference= s( timer

[RFC5810] is started. The FE MAY continue to forward pack= ets)

.

/tmp/draft-ietf-forces-ceha-07.txt(476): update_reference= s( bring down its

forwarding path (and set the [RFC5812] FEObject)

.

/tmp/draft-ietf-forces-ceha-07.txt(538): RFC 2119 keyword= : MUST configure

the FE to make it aware which CE is the master and MAY.

/tmp/draft-ietf-forces-ceha-07.txt(657): RFC 2119 keyword= : CE (lowest

table index) in the AllCEs table MUST be the first CE tha= t.

/tmp/draft-ietf-forces-ceha-07.txt(662): RFC 2119 keyword= : FE MUST

associate with at least one CE. Upon a successful.

/tmp/draft-ietf-forces-ceha-07.txt(678): RFC 2119 keyword= : FE.

Configuration messages (SET/DEL) from backup CEs MUST be = dropped.

/tmp/draft-ietf-forces-ceha-07.txt(710): Line is too long= : the offending

characters are '+'

/tmp/draft-ietf-forces-ceha-07.txt(711): Line is too long= : the offending

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(712): Line is too long= : the offending

characters are 'v'

/tmp/draft-ietf-forces-ceha-07.txt(712): Line has weird s= pacing: '...ociated

v...'

/tmp/draft-ietf-forces-ceha-07.txt(713): Line is too long= : the offending

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(713): Line has weird s= pacing: '...)|CE or

retry...'

/tmp/draft-ietf-forces-ceha-07.txt(714): Line is too long= : the offending

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(715): Line is too long= : the offending

characters are '+'

/tmp/draft-ietf-forces-ceha-07.txt(779): RFC 2119 keyword= : associating

with the master CE, MUST attempt to connect and associate= .

/tmp/draft-ietf-forces-ceha-07.txt(792): RFC 2119 keyword= : FE MAY flag

them as unreachable to avoid continuous attempts to.

/tmp/draft-ietf-forces-ceha-07.txt(793): RFC 2119 keyword= : connect. The

FE MAY retry to reassociate with unreachable CEs when.

/tmp/draft-ietf-forces-ceha-07.txt(797): RFC 2119 keyword= : FE MUST try to

find the first associated CE from the list of all CEs.

/tmp/draft-ietf-forces-ceha-07.txt(801): RFC 2119 keyword= : it MUST attempt

to connect and associate with the first from the list.

/tmp/draft-ietf-forces-ceha-07.txt(835): update_reference= s( Security

consideration as defined in section 9 of [RFC5810] applie= s.)

.

/tmp/draft-ietf-forces-ceha-07.txt(850): update_reference= s( [RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate = Requirement Levels", BCP

14, RFC 2119, March 1997.)

.

/tmp/draft-ietf-forces-ceha-07.txt(855): update_reference= s( [RFC5810] Doria,

A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Don= g, L., Gopal, R.,

and J. Halpern, "Forwarding and Control Element Sepa= ration (ForCES) Protocol

Specification", RFC 5810, March 2010.

/tmp/draft-ietf-forces-ceha-07.txt(860): update_references( [RFC3= 654]

Khosravi, H. and T. Anderson, "Requirements for Sepa= ration of IP Control and

Forwarding", RFC 3654, November 2003.)

.

/tmp/draft-ietf-forces-ceha-07.txt(864): update_reference= s( [RFC3746] Yang,

L., Dantu, R., Anderson, T., and R. Gopal, "Forwardi= ng and Control Element

Separation (ForCES) Framework", RFC 3746, April 2004= .)

.

/tmp/draft-ietf-forces-ceha-07.txt(868): update_reference= s( [RFC5812]

Halpern, J. and J. Hadi Salim, "Forwarding and Contr= ol Element Separation

(ForCES) Forwarding Element Model", RFC 5812, March = 2010.)

.

/tmp/draft-ietf-forces-ceha-07.txt(869): Appendix start: = Appendix A. New

FEPO version.

/tmp/draft-ietf-forces-ceha-07.txt(871): update_reference= s( The xml has

been validated against the schema defined in [RFC5812].)<= /p>

.

update_references( The following definitions are taken fr= om

[RFC3654]and [RFC3746]:)

update_references( the ForCES Framework in [RFC3746].)

update_references( transfer mechanisms as defined in [RFC= 5810].)

update_references( by the FEPO LFB in [RFC5810], Appendix= B. In

Section 3.1 of this)

update_references( 1. To describe with more clarity (than= [RFC5810])

how current cold-)

update_references( 2. To describe how to evolve the [RFC5= 810]

cold-standby setup to a)

update_references( The design intent of the current [RFC5= 810] as well

as this document)

update_references( setup in [RFC5810]:)

update_references( per [RFC5810] definition which is repe= ated for

contextual reasons in)

update_references( a detected failure. The FEObject FESta= te

component [RFC5812] defines)

update_references( and can turn it on by setting it to Op= erEnable.

Note: [RFC5812])

update_references( timer [RFC5810] is started. The FE MAY= continue

to forward packets)

update_references( bring down its forwarding path (and se= t the

[RFC5812] FEObject)

=A0

<= p align=3D"LEFT">

=A0

update_references( Security consideration as defined in section 9= of

[RFC5810] applies.)

update_references( [RFC2119] Bradner, S., "Key words= for use in RFCs to

Indicate Requirement Levels", BCP 14, RFC 2119, Marc= h 1997.)

ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key= words for use in

RFCs to Indicate Requirement Levels", BCP 14, RFC 21= 19, March 1997.

update_references( [RFC5810] Doria, A., Hadi Salim, J., H= aas, R.,

Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpe= rn, "Forwarding

and Control Element Separation (ForCES) Protocol Specific= ation", RFC

5810, March 2010.)

ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim,= J., Haas,

R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. H= alpern,

"Forwarding and Control Element Separation (ForCES) = Protocol

Specification", RFC 5810, March 2010.

update_references( [RFC3654] Khosravi, H. and T. Anderson= ,

"Requirements for Separation of IP Control and Forwa= rding", RFC 3654,

November 2003.)

ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. An= derson,

"Requirements for Separation of IP Control and Forwa= rding", RFC 3654,

November 2003.

update_references( [RFC3746] Yang, L., Dantu, R., Anderso= n, T., and R.

Gopal, "Forwarding and Control Element Separation (F= orCES) Framework",

RFC 3746, April 2004.)

ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., A= nderson, T.,

and R. Gopal, "Forwarding and Control Element Separa= tion (ForCES)

Framework", RFC 3746, April 2004.

update_references( [RFC5812] Halpern, J. and J. Hadi Sali= m, "Forwarding

and Control Element Separation (ForCES) Forwarding Elemen= t Model", RFC

5812, March 2010.)

ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Had= i Salim,

"Forwarding and Control Element Separation (ForCES) = Forwarding Element

Model", RFC 5812, March 2010.

Appendix start: Appendix A. New FEPO version

update_references( The xml has been validated against the= schema

defined in [RFC5812].)

Showing Errors (**), Flaws (~~), Warnings (=3D=3D), and C= omments (--).

Errors MUST be fixed before draft submission. Flaws SHOUL= D be fixed before

draft submission.

Checking boilerplate required by RFC 5378 and the IETF Tr= ust (see

http://trustee.ietf.org/license-info):

= =A0

------------------------------------------------------------------------= ---

No issues found here.

Checking nits according to http://www.ietf.org/id-info/= 1id-guidelines.txt:

---------------------------------------------------------= ------------------

No issues found here.

Running in submission checking mode -- *not* checking nit= s according to

http://www.ietf.org/id-info/checklist .

---------------------------------------------------------= ------------------

No nits found.

+++++++++++++++++++++= END++++++++++++++++++++++++
=
On= Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim <hadi@mojatatu.com>= wrote:
Thanks Bhumip.
I can verify that no I= PR issues were ever brought up by the authors or any one
attending the WG or on the lists over the years in regards to the cont= ents of this
document.

cheers,
jamal
=


On = Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org <vumip1@gmail.com> wr= ote:
Thanks Jamal.
=A0
Pls note that to the best of my knowledge there is no IPR issue involv= ed with this draft.
=A0
In addition, I have not heard any objection re publishing this as well= .
=A0
I'll finalize the shepherd's writeup soon. Thanks again.
=A0
Best.
=A0
Bhumip


=A0
On Thu, May 23, 2013 at 8:47 AM, Jamal= Hadi Salim <hadi@mojatatu.com> wrote:

Bhumip has graciously agreed to shepherd the CEHA draft:=A0
https://datatracker.ietf.org/doc/draft-ietf-forces-ceha/

This the last outstanding document from the previous charter that
has not started the publication journey.

Thanks Bhumip.

cheers,
jamal

_____________________________________= __________
forces mailing list
forces@ietf.org
https://www.ietf.org/mailman/listinfo= /forces




=A0


=A0

--001a11c2088c5e052404de5862c0-- From hadi@mojatatu.com Tue Jun 4 11:50:12 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E728921F9A51 for ; Tue, 4 Jun 2013 11:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.644 X-Spam-Level: X-Spam-Status: No, score=-101.644 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pyocefiqbjG for ; Tue, 4 Jun 2013 11:50:00 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id B91D921F9A4E for ; Tue, 4 Jun 2013 11:49:59 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gd11so468321vcb.39 for ; Tue, 04 Jun 2013 11:49:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=kjlG8zjYx8lKyHw89Sc5EF/dNwzEsfS62iFp5pvM0Jg=; b=ejYLchYPEszhGi2Z3c5MtlB5rkR58wzsFJeCmg+B4wwpHWyWfyi5D5FGRwqtQX1mKC ANjSnOudZOpF+o4ScuMs/7gLMJhcAtQ8b8Q/MFzgwoAV9PJ/z5sr7CUR46EBZp8cyXe7 l3atzNI3V+I0kbq4ob8/XpLIFhjPygTC/J0ZGneteBdL5oH65RXh8R+oX+rbUPQGqWB9 r6wU1qUOQLD2BLn0Oi0Ks5e7LJ7sC0v3qY09FxT+hJ7e4kBQj5R04eK+oeQvWfQbZwxq ASFRK/WqhsFDMchJt8/jBrTdt80zPKETS/MTUJA1oODMd5/pyy3+gynpxKjAJeS4b3Od l+Sw== X-Received: by 10.52.170.165 with SMTP id an5mr6088306vdc.89.1370371798887; Tue, 04 Jun 2013 11:49:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.199 with HTTP; Tue, 4 Jun 2013 11:49:38 -0700 (PDT) In-Reply-To: <51AE33FE.2080309@stevecrocker.com> References: <51AE33FE.2080309@stevecrocker.com> From: Jamal Hadi Salim Date: Tue, 4 Jun 2013 14:49:38 -0400 Message-ID: To: Joel Content-Type: multipart/alternative; boundary=047d7b34427248b16904de588c70 X-Gm-Message-State: ALoCoQlVQV4kva5GdnZ65Pv4+jOOky1ZA2aNaeArTK7pMuemWAH7Oj4W5Cv/uJt8UyXY1wP5OuoV Cc: "forces@ietf.org" , Bhumip-ZTE Khasnabish Subject: Re: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 18:50:12 -0000 --047d7b34427248b16904de588c70 Content-Type: text/plain; charset=ISO-8859-1 Joel, According to this: https://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-forces-ceha-07.txt There is one error and 4 warnings (unless that is a bug in the tool) cheers, jamal On Tue, Jun 4, 2013 at 2:37 PM, Joel wrote: > None of those warnings warrant a respin. > If the draft gets spun for some other reason, and if we have not added any > any 2119 language to the draft, then we should remove the reference. > > Yours, > Joel > > > On 6/4/2013 1:35 PM, B.Khasnabish@ieee.org wrote: > >> Hi Jamal, >> Thanks for confirming the IPR related matters. >> PLS note that I found the following ID nits by checking the draft >> (http://www.ietf.org/id/draft-**ietf-forcesceha-07.txt) >> through the website: >> http://www.ietf.org/tools/**idnits/ >> The question is whether the draft should be revised based >> on the reqd. fixes before publishing. Thanks. >> Best. >> Bhumip >> +++++++++++++++++++++START++++**++++++++++++++++++++ >> >> idnits 2.12.17 >> >> /tmp/draft-ietf-forces-ceha-**07.txt: >> >> /tmp/draft-ietf-forces-ceha-**07.txt(90): update_references( The >> following >> >> definitions are taken from [RFC3654]and [RFC3746]:) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(96): update_references( the ForCES >> >> Framework in [RFC3746].) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(100): update_references( transfer >> >> mechanisms as defined in [RFC5810].) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(229): update_references( by the FEPO >> >> LFB in [RFC5810], Appendix B. In Section 3.1 of this) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(247): update_references( 1. To >> >> describe with more clarity (than [RFC5810]) how current cold-) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(250): update_references( 2. To >> >> describe how to evolve the [RFC5810] cold-standby setup to a) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(267): update_references( The design >> >> intent of the current [RFC5810] as well as this document) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(271): update_references( setup in >> >> [RFC5810]:) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(313): RFC 2119 keyword: To achieve >> CE >> >> High Availability (HA), FEs and CEs MUST inter-operate. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(314): update_references( per >> [RFC5810] >> >> definition which is repeated for contextual reasons in) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(316): RFC 2119 keyword: MUST be >> >> implemented by CEs and FEs requiring HA, the Fr plane is out. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(377): update_references( a detected >> >> failure. The FEObject FEState component [RFC5812] defines) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(380): update_references( and can >> turn >> >> it on by setting it to OperEnable. Note: [RFC5812]) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(425): Line has weird spacing: '... >> |try >> >> v...' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(456): RFC 2119 keyword: >> communication >> >> failure, regardless of how it is detected, MUST be. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(468): RFC 2119 keyword: timer >> [RFC5810] >> >> is started. The FE MAY continue to forward packets. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(468): update_references( timer >> >> [RFC5810] is started. The FE MAY continue to forward packets) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(476): update_references( bring down >> its >> >> forwarding path (and set the [RFC5812] FEObject) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(538): RFC 2119 keyword: MUST >> configure >> >> the FE to make it aware which CE is the master and MAY. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(657): RFC 2119 keyword: CE (lowest >> >> table index) in the AllCEs table MUST be the first CE that. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(662): RFC 2119 keyword: FE MUST >> >> associate with at least one CE. Upon a successful. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(678): RFC 2119 keyword: FE. >> >> Configuration messages (SET/DEL) from backup CEs MUST be dropped. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(710): Line is too long: the >> offending >> >> characters are '+' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(711): Line is too long: the >> offending >> >> characters are '|' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(712): Line is too long: the >> offending >> >> characters are 'v' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(712): Line has weird spacing: >> '...ociated >> >> v...' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(713): Line is too long: the >> offending >> >> characters are '|' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(713): Line has weird spacing: >> '...)|CE or >> >> retry...' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(714): Line is too long: the >> offending >> >> characters are '|' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(715): Line is too long: the >> offending >> >> characters are '+' >> >> /tmp/draft-ietf-forces-ceha-**07.txt(779): RFC 2119 keyword: associating >> >> with the master CE, MUST attempt to connect and associate. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(792): RFC 2119 keyword: FE MAY flag >> >> them as unreachable to avoid continuous attempts to. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(793): RFC 2119 keyword: connect. The >> >> FE MAY retry to reassociate with unreachable CEs when. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(797): RFC 2119 keyword: FE MUST try >> to >> >> find the first associated CE from the list of all CEs. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(801): RFC 2119 keyword: it MUST >> attempt >> >> to connect and associate with the first from the list. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(835): update_references( Security >> >> consideration as defined in section 9 of [RFC5810] applies.) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(850): update_references( [RFC2119] >> >> Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", >> BCP >> >> 14, RFC 2119, March 1997.) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(855): update_references( [RFC5810] >> Doria, >> >> A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., >> >> and J. Halpern, "Forwarding and Control Element Separation (ForCES) >> Protocol >> >> Specification", RFC 5810, March 2010. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(860): update_references( [RFC3654] >> >> Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control >> and >> >> Forwarding", RFC 3654, November 2003.) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(864): update_references( [RFC3746] >> Yang, >> >> L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element >> >> Separation (ForCES) Framework", RFC 3746, April 2004.) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(868): update_references( [RFC5812] >> >> Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation >> >> (ForCES) Forwarding Element Model", RFC 5812, March 2010.) >> >> . >> >> /tmp/draft-ietf-forces-ceha-**07.txt(869): Appendix start: Appendix A. >> New >> >> FEPO version. >> >> /tmp/draft-ietf-forces-ceha-**07.txt(871): update_references( The xml has >> >> been validated against the schema defined in [RFC5812].) >> >> . >> >> update_references( The following definitions are taken from >> >> [RFC3654]and [RFC3746]:) >> >> update_references( the ForCES Framework in [RFC3746].) >> >> update_references( transfer mechanisms as defined in [RFC5810].) >> >> update_references( by the FEPO LFB in [RFC5810], Appendix B. In >> >> Section 3.1 of this) >> >> update_references( 1. To describe with more clarity (than [RFC5810]) >> >> how current cold-) >> >> update_references( 2. To describe how to evolve the [RFC5810] >> >> cold-standby setup to a) >> >> update_references( The design intent of the current [RFC5810] as well >> >> as this document) >> >> update_references( setup in [RFC5810]:) >> >> update_references( per [RFC5810] definition which is repeated for >> >> contextual reasons in) >> >> update_references( a detected failure. The FEObject FEState >> >> component [RFC5812] defines) >> >> update_references( and can turn it on by setting it to OperEnable. >> >> Note: [RFC5812]) >> >> update_references( timer [RFC5810] is started. The FE MAY continue >> >> to forward packets) >> >> update_references( bring down its forwarding path (and set the >> >> [RFC5812] FEObject) >> >> update_references( Security consideration as defined in section 9 of >> >> [RFC5810] applies.) >> >> update_references( [RFC2119] Bradner, S., "Key words for use in RFCs to >> >> Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.) >> >> ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key words for use in >> >> RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R., >> >> Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding >> >> and Control Element Separation (ForCES) Protocol Specification", RFC >> >> 5810, March 2010.) >> >> ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim, J., Haas, >> >> R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, >> >> "Forwarding and Control Element Separation (ForCES) Protocol >> >> Specification", RFC 5810, March 2010. >> >> update_references( [RFC3654] Khosravi, H. and T. Anderson, >> >> "Requirements for Separation of IP Control and Forwarding", RFC 3654, >> >> November 2003.) >> >> ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. Anderson, >> >> "Requirements for Separation of IP Control and Forwarding", RFC 3654, >> >> November 2003. >> >> update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. >> >> Gopal, "Forwarding and Control Element Separation (ForCES) Framework", >> >> RFC 3746, April 2004.) >> >> ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., Anderson, T., >> >> and R. Gopal, "Forwarding and Control Element Separation (ForCES) >> >> Framework", RFC 3746, April 2004. >> >> update_references( [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding >> >> and Control Element Separation (ForCES) Forwarding Element Model", RFC >> >> 5812, March 2010.) >> >> ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Hadi Salim, >> >> "Forwarding and Control Element Separation (ForCES) Forwarding Element >> >> Model", RFC 5812, March 2010. >> >> Appendix start: Appendix A. New FEPO version >> >> update_references( The xml has been validated against the schema >> >> defined in [RFC5812].) >> >> Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--). >> >> Errors MUST be fixed before draft submission. Flaws SHOULD be fixed before >> >> draft submission. >> >> Checking boilerplate required by RFC 5378 and the IETF Trust (see >> >> http://trustee.ietf.org/**license-info >> ): >> >> ------------------------------**------------------------------** >> --------------- >> >> No issues found here. >> >> Checking nits according to http://www.ietf.org/id-info/** >> 1id-guidelines.txt : >> >> ------------------------------**------------------------------** >> --------------- >> >> No issues found here. >> >> Running in submission checking mode -- *not* checking nits according to >> >> http://www.ietf.org/id-info/**checklist. >> >> ------------------------------**------------------------------** >> --------------- >> >> No nits found. >> >> +++++++++++++++++++++END++++++**++++++++++++++++++ >> >> >> On Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim > > wrote: >> >> Thanks Bhumip. >> I can verify that no IPR issues were ever brought up by the authors >> or any one >> attending the WG or on the lists over the years in regards to the >> contents of this >> document. >> >> cheers, >> jamal >> >> >> On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org >> > >> > wrote: >> >> Thanks Jamal. >> Pls note that to the best of my knowledge there is no IPR issue >> involved with this draft. >> In addition, I have not heard any objection re publishing this >> as well. >> I'll finalize the shepherd's writeup soon. Thanks again. >> Best. >> Bhumip >> >> >> On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim >> > wrote: >> >> >> Bhumip has graciously agreed to shepherd the CEHA draft: >> https://datatracker.ietf.org/**doc/draft-ietf-forces-ceha/ >> >> This the last outstanding document from the previous charter >> that >> has not started the publication journey. >> >> Thanks Bhumip. >> >> cheers, >> jamal >> >> ______________________________**_________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/**listinfo/forces >> >> >> >> >> >> >> >> >> >> ______________________________**_________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/**listinfo/forces >> >> --047d7b34427248b16904de588c70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joel,
According to this:

There is one error and 4 warnings (un= less that is a bug in the tool)

cheers= ,
jamal



On Tue, Jun 4, 2013 at 2:37 PM, Joel <joel@stevecrocker.com> wrote:
None of those warnings warrant a respin.
If the draft gets spun for some other reason, and if we have not added any = any 2119 language to the draft, then we should remove the reference.

Yours,
Joel


On 6/4/2013 1:35 PM, B.Khasnabish@ieee.org wrote:
Hi Jamal,
Thanks for confirming the IPR related matters.
PLS note that I found the following ID nits by checking the draft
(http://www.ietf.org/id/draft-ietf-forcesceha-07.txt) thr= ough the website:
http://www.= ietf.org/tools/idnits/
The question is whether the draft should be revised based
on the reqd. fixes before publishing. Thanks.
Best.
Bhumip
+++++++++++++++++++++START++++++++++++++++++++++++

idnits 2.12.17

/tmp/draft-ietf-forces-ceha-07.txt:

/tmp/draft-ietf-forces-ceha-07.txt(90): update_references( The follo= wing

definitions are taken from [RFC3654]and [RFC3746]:)

.

/tmp/draft-ietf-forces-ceha-07.txt(96): update_references( the ForCE= S

Framework in [RFC3746].)

.

/tmp/draft-ietf-forces-ceha-07.txt(100): update_references( transfer=

mechanisms as defined in [RFC5810].)

.

/tmp/draft-ietf-forces-ceha-07.txt(229): update_references( by the F= EPO

LFB in [RFC5810], Appendix B. In Section 3.1 of this)

.

/tmp/draft-ietf-forces-ceha-07.txt(247): update_references( 1. To
describe with more clarity (than [RFC5810]) how current cold-)

.

/tmp/draft-ietf-forces-ceha-07.txt(250): update_references( 2. To
describe how to evolve the [RFC5810] cold-standby setup to a)

.

/tmp/draft-ietf-forces-ceha-07.txt(267): update_references( The desi= gn

intent of the current [RFC5810] as well as this document)

.

/tmp/draft-ietf-forces-ceha-07.txt(271): update_references( setup in=

[RFC5810]:)

.

/tmp/draft-ietf-forces-ceha-07.txt(313): RFC 2119 keyword: To achiev= e CE

High Availability (HA), FEs and CEs MUST inter-operate.

/tmp/draft-ietf-forces-ceha-07.txt(314): update_references( per [RFC= 5810]

definition which is repeated for contextual reasons in)

.

/tmp/draft-ietf-forces-ceha-07.txt(316): RFC 2119 keyword: MUST be
implemented by CEs and FEs requiring HA, the Fr plane is out.

/tmp/draft-ietf-forces-ceha-07.txt(377): update_references( a detect= ed

failure. The FEObject FEState component [RFC5812] defines)

.

/tmp/draft-ietf-forces-ceha-07.txt(380): update_references( and can = turn

it on by setting it to OperEnable. Note: [RFC5812])

.

/tmp/draft-ietf-forces-ceha-07.txt(425): Line has weird spacing: = 9;... |try

v...'

/tmp/draft-ietf-forces-ceha-07.txt(456): RFC 2119 keyword: communica= tion

failure, regardless of how it is detected, MUST be.

/tmp/draft-ietf-forces-ceha-07.txt(468): RFC 2119 keyword: timer [RF= C5810]

is started. The FE MAY continue to forward packets.

/tmp/draft-ietf-forces-ceha-07.txt(468): update_references( timer
[RFC5810] is started. The FE MAY continue to forward packets)

.

/tmp/draft-ietf-forces-ceha-07.txt(476): update_references( bring do= wn its

forwarding path (and set the [RFC5812] FEObject)

.

/tmp/draft-ietf-forces-ceha-07.txt(538): RFC 2119 keyword: MUST conf= igure

the FE to make it aware which CE is the master and MAY.

/tmp/draft-ietf-forces-ceha-07.txt(657): RFC 2119 keyword: CE (lowes= t

table index) in the AllCEs table MUST be the first CE that.

/tmp/draft-ietf-forces-ceha-07.txt(662): RFC 2119 keyword: FE MUST
associate with at least one CE. Upon a successful.

/tmp/draft-ietf-forces-ceha-07.txt(678): RFC 2119 keyword: FE.

Configuration messages (SET/DEL) from backup CEs MUST be dropped.

/tmp/draft-ietf-forces-ceha-07.txt(710): Line is too long: the offen= ding

characters are '+'

/tmp/draft-ietf-forces-ceha-07.txt(711): Line is too long: the offen= ding

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(712): Line is too long: the offen= ding

characters are 'v'

/tmp/draft-ietf-forces-ceha-07.txt(712): Line has weird spacing: = 9;...ociated

v...'

/tmp/draft-ietf-forces-ceha-07.txt(713): Line is too long: the offen= ding

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(713): Line has weird spacing: = 9;...)|CE or

retry...'

/tmp/draft-ietf-forces-ceha-07.txt(714): Line is too long: the offen= ding

characters are '|'

/tmp/draft-ietf-forces-ceha-07.txt(715): Line is too long: the offen= ding

characters are '+'

/tmp/draft-ietf-forces-ceha-07.txt(779): RFC 2119 keyword: associati= ng

with the master CE, MUST attempt to connect and associate.

/tmp/draft-ietf-forces-ceha-07.txt(792): RFC 2119 keyword: FE MAY fl= ag

them as unreachable to avoid continuous attempts to.

/tmp/draft-ietf-forces-ceha-07.txt(793): RFC 2119 keyword: connect. = The

FE MAY retry to reassociate with unreachable CEs when.

/tmp/draft-ietf-forces-ceha-07.txt(797): RFC 2119 keyword: FE MUST t= ry to

find the first associated CE from the list of all CEs.

/tmp/draft-ietf-forces-ceha-07.txt(801): RFC 2119 keyword: it MUST a= ttempt

to connect and associate with the first from the list.

/tmp/draft-ietf-forces-ceha-07.txt(835): update_references( Security=

consideration as defined in section 9 of [RFC5810] applies.)

.

/tmp/draft-ietf-forces-ceha-07.txt(850): update_references( [RFC2119= ]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels= ", BCP

14, RFC 2119, March 1997.)

.

/tmp/draft-ietf-forces-ceha-07.txt(855): update_references( [RFC5810= ] Doria,

A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R.,<= br>
and J. Halpern, "Forwarding and Control Element Separation (ForCES) Pr= otocol

Specification", RFC 5810, March 2010.

/tmp/draft-ietf-forces-ceha-07.txt(860): update_references( [RFC3654= ]

Khosravi, H. and T. Anderson, "Requirements for Separation of IP Contr= ol and

Forwarding", RFC 3654, November 2003.)

.

/tmp/draft-ietf-forces-ceha-07.txt(864): update_references( [RFC3746= ] Yang,

L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Ele= ment

Separation (ForCES) Framework", RFC 3746, April 2004.)

.

/tmp/draft-ietf-forces-ceha-07.txt(868): update_references( [RFC5812= ]

Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separat= ion

(ForCES) Forwarding Element Model", RFC 5812, March 2010.)

.

/tmp/draft-ietf-forces-ceha-07.txt(869): Appendix start: Appendix A.= New

FEPO version.

/tmp/draft-ietf-forces-ceha-07.txt(871): update_references( The xml = has

been validated against the schema defined in [RFC5812].)

.

update_references( The following definitions are taken from

[RFC3654]and [RFC3746]:)

update_references( the ForCES Framework in [RFC3746].)

update_references( transfer mechanisms as defined in [RFC5810].)

update_references( by the FEPO LFB in [RFC5810], Appendix B. In

Section 3.1 of this)

update_references( 1. To describe with more clarity (than [RFC5810])

how current cold-)

update_references( 2. To describe how to evolve the [RFC5810]

cold-standby setup to a)

update_references( The design intent of the current [RFC5810] as well

as this document)

update_references( setup in [RFC5810]:)

update_references( per [RFC5810] definition which is repeated for

contextual reasons in)

update_references( a detected failure. The FEObject FEState

component [RFC5812] defines)

update_references( and can turn it on by setting it to OperEnable.

Note: [RFC5812])

update_references( timer [RFC5810] is started. The FE MAY continue

to forward packets)

update_references( bring down its forwarding path (and set the

[RFC5812] FEObject)

update_references( Security consideration as defined in section 9 of

[RFC5810] applies.)

update_references( [RFC2119] Bradner, S., "Key words for use in RFCs t= o

Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.)

ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key words for use in<= br>
RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R.,

Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwardi= ng

and Control Element Separation (ForCES) Protocol Specification", RFC
5810, March 2010.)

ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim, J., Haas,

R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern,

"Forwarding and Control Element Separation (ForCES) Protocol

Specification", RFC 5810, March 2010.

update_references( [RFC3654] Khosravi, H. and T. Anderson,

"Requirements for Separation of IP Control and Forwarding", RFC 3= 654,

November 2003.)

ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. Anderson,

"Requirements for Separation of IP Control and Forwarding", RFC 3= 654,

November 2003.

update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T., and R.

Gopal, "Forwarding and Control Element Separation (ForCES) Framework&q= uot;,

RFC 3746, April 2004.)

ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., Anderson, T.,

and R. Gopal, "Forwarding and Control Element Separation (ForCES)

Framework", RFC 3746, April 2004.

update_references( [RFC5812] Halpern, J. and J. Hadi Salim, "Forwardin= g

and Control Element Separation (ForCES) Forwarding Element Model", RFC=

5812, March 2010.)

ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Hadi Salim,

"Forwarding and Control Element Separation (ForCES) Forwarding Element=

Model", RFC 5812, March 2010.

Appendix start: Appendix A. New FEPO version

update_references( The xml has been validated against the schema

defined in [RFC5812].)

Showing Errors (**), Flaws (~~), Warnings (=3D=3D), and Comments (--).

Errors MUST be fixed before draft submission. Flaws SHOULD be fixed before<= br>
draft submission.

Checking boilerplate required by RFC 5378 and the IETF Trust (see

http://t= rustee.ietf.org/license-info):

-------------------------------------------------------------= --------------

No issues found here.

Checking nits according to http://www.ietf.org/id-info/1id-guideli= nes.txt:

-------------------------------------------------------------= --------------

No issues found here.

Running in submission checking mode -- *not* checking nits according to

http://= www.ietf.org/id-info/checklist .

-------------------------------------------------------------= --------------

No nits found.

+++++++++++++++++++++END++++++++++++++++++++++++


On Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim <hadi@mojatatu.com
<mailto:hadi@moja= tatu.com>> wrote:

=A0 =A0 Thanks Bhumip.
=A0 =A0 I can verify that no IPR issues were ever brought up by the authors=
=A0 =A0 or any one
=A0 =A0 attending the WG or on the lists over the years in regards to the =A0 =A0 contents of this
=A0 =A0 document.

=A0 =A0 cheers,
=A0 =A0 jamal


=A0 =A0 On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org
=A0 =A0 <mailto:B.Khasnabish@ieee.org> <vumip1@gmail.com

=A0 =A0 <mailto:vu= mip1@gmail.com>> wrote:

=A0 =A0 =A0 =A0 Thanks Jamal.
=A0 =A0 =A0 =A0 Pls note that to the best of my knowledge there is no IPR i= ssue
=A0 =A0 =A0 =A0 involved with this draft.
=A0 =A0 =A0 =A0 In addition, I have not heard any objection re publishing t= his
=A0 =A0 =A0 =A0 as well.
=A0 =A0 =A0 =A0 I'll finalize the shepherd's writeup soon. Thanks a= gain.
=A0 =A0 =A0 =A0 Best.
=A0 =A0 =A0 =A0 Bhumip


=A0 =A0 =A0 =A0 On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim
=
=A0 =A0 =A0 =A0 <= hadi@mojatatu.com <mailto:hadi@mojatatu.com>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 Bhumip has graciously agreed to shepherd the CEHA d= raft:
=A0 =A0 =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc= /draft-ietf-forces-ceha/

=A0 =A0 =A0 =A0 =A0 =A0 This the last outstanding document from the previou= s charter
=A0 =A0 =A0 =A0 =A0 =A0 that
=A0 =A0 =A0 =A0 =A0 =A0 has not started the publication journey.

=A0 =A0 =A0 =A0 =A0 =A0 Thanks Bhumip.

=A0 =A0 =A0 =A0 =A0 =A0 cheers,
=A0 =A0 =A0 =A0 =A0 =A0 jamal

=A0 =A0 =A0 =A0 =A0 =A0 ____________________________________________= ___
=A0 =A0 =A0 =A0 =A0 =A0 forces mailing list
=A0 =A0 =A0 =A0 =A0 =A0 forces@ietf.org <mailto:forces@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/forces=









_______________________________________________
forces mailing list
forces@ietf.org = https://www.ietf.org/mailman/listinfo/forces


--047d7b34427248b16904de588c70-- From joel@stevecrocker.com Tue Jun 4 12:57:42 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9CF21F9A03 for ; Tue, 4 Jun 2013 12:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amgdv97PmTcu for ; Tue, 4 Jun 2013 12:57:37 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id A84AB21F9ADB for ; Tue, 4 Jun 2013 11:58:37 -0700 (PDT) Received: from dummy.name; Tue, 04 Jun 2013 18:58:35 +0000 Message-ID: <51AE38D2.5020009@stevecrocker.com> Date: Tue, 04 Jun 2013 14:58:26 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jamal Hadi Salim References: <51AE33FE.2080309@stevecrocker.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "forces@ietf.org" , Bhumip-ZTE Khasnabish Subject: Re: [forces] CEHA shepherding X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 19:57:42 -0000 The error is the long lines. Which can be dealt with by the RFC Series Production Center. Yours, Joel On 6/4/2013 2:49 PM, Jamal Hadi Salim wrote: > Joel, > According to this: > https://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-forces-ceha-07.txt > > There is one error and 4 warnings (unless that is a bug in the tool) > > cheers, > jamal > > > > On Tue, Jun 4, 2013 at 2:37 PM, Joel > wrote: > > None of those warnings warrant a respin. > If the draft gets spun for some other reason, and if we have not > added any any 2119 language to the draft, then we should remove the > reference. > > Yours, > Joel > > > On 6/4/2013 1:35 PM, B.Khasnabish@ieee.org > wrote: > > Hi Jamal, > Thanks for confirming the IPR related matters. > PLS note that I found the following ID nits by checking the draft > (http://www.ietf.org/id/draft-__ietf-forcesceha-07.txt > ) through > the website: > http://www.ietf.org/tools/__idnits/ > > The question is whether the draft should be revised based > on the reqd. fixes before publishing. Thanks. > Best. > Bhumip > +++++++++++++++++++++START++++__++++++++++++++++++++ > > idnits 2.12.17 > > /tmp/draft-ietf-forces-ceha-__07.txt: > > /tmp/draft-ietf-forces-ceha-__07.txt(90): update_references( The > following > > definitions are taken from [RFC3654]and [RFC3746]:) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(96): update_references( the > ForCES > > Framework in [RFC3746].) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(100): update_references( > transfer > > mechanisms as defined in [RFC5810].) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(229): update_references( by > the FEPO > > LFB in [RFC5810], Appendix B. In Section 3.1 of this) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(247): update_references( 1. To > > describe with more clarity (than [RFC5810]) how current cold-) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(250): update_references( 2. To > > describe how to evolve the [RFC5810] cold-standby setup to a) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(267): update_references( > The design > > intent of the current [RFC5810] as well as this document) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(271): update_references( > setup in > > [RFC5810]:) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(313): RFC 2119 keyword: To > achieve CE > > High Availability (HA), FEs and CEs MUST inter-operate. > > /tmp/draft-ietf-forces-ceha-__07.txt(314): update_references( > per [RFC5810] > > definition which is repeated for contextual reasons in) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(316): RFC 2119 keyword: MUST be > > implemented by CEs and FEs requiring HA, the Fr plane is out. > > /tmp/draft-ietf-forces-ceha-__07.txt(377): update_references( a > detected > > failure. The FEObject FEState component [RFC5812] defines) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(380): update_references( > and can turn > > it on by setting it to OperEnable. Note: [RFC5812]) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(425): Line has weird > spacing: '... |try > > v...' > > /tmp/draft-ietf-forces-ceha-__07.txt(456): RFC 2119 keyword: > communication > > failure, regardless of how it is detected, MUST be. > > /tmp/draft-ietf-forces-ceha-__07.txt(468): RFC 2119 keyword: > timer [RFC5810] > > is started. The FE MAY continue to forward packets. > > /tmp/draft-ietf-forces-ceha-__07.txt(468): update_references( timer > > [RFC5810] is started. The FE MAY continue to forward packets) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(476): update_references( > bring down its > > forwarding path (and set the [RFC5812] FEObject) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(538): RFC 2119 keyword: > MUST configure > > the FE to make it aware which CE is the master and MAY. > > /tmp/draft-ietf-forces-ceha-__07.txt(657): RFC 2119 keyword: CE > (lowest > > table index) in the AllCEs table MUST be the first CE that. > > /tmp/draft-ietf-forces-ceha-__07.txt(662): RFC 2119 keyword: FE MUST > > associate with at least one CE. Upon a successful. > > /tmp/draft-ietf-forces-ceha-__07.txt(678): RFC 2119 keyword: FE. > > Configuration messages (SET/DEL) from backup CEs MUST be dropped. > > /tmp/draft-ietf-forces-ceha-__07.txt(710): Line is too long: the > offending > > characters are '+' > > /tmp/draft-ietf-forces-ceha-__07.txt(711): Line is too long: the > offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-__07.txt(712): Line is too long: the > offending > > characters are 'v' > > /tmp/draft-ietf-forces-ceha-__07.txt(712): Line has weird > spacing: '...ociated > > v...' > > /tmp/draft-ietf-forces-ceha-__07.txt(713): Line is too long: the > offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-__07.txt(713): Line has weird > spacing: '...)|CE or > > retry...' > > /tmp/draft-ietf-forces-ceha-__07.txt(714): Line is too long: the > offending > > characters are '|' > > /tmp/draft-ietf-forces-ceha-__07.txt(715): Line is too long: the > offending > > characters are '+' > > /tmp/draft-ietf-forces-ceha-__07.txt(779): RFC 2119 keyword: > associating > > with the master CE, MUST attempt to connect and associate. > > /tmp/draft-ietf-forces-ceha-__07.txt(792): RFC 2119 keyword: FE > MAY flag > > them as unreachable to avoid continuous attempts to. > > /tmp/draft-ietf-forces-ceha-__07.txt(793): RFC 2119 keyword: > connect. The > > FE MAY retry to reassociate with unreachable CEs when. > > /tmp/draft-ietf-forces-ceha-__07.txt(797): RFC 2119 keyword: FE > MUST try to > > find the first associated CE from the list of all CEs. > > /tmp/draft-ietf-forces-ceha-__07.txt(801): RFC 2119 keyword: it > MUST attempt > > to connect and associate with the first from the list. > > /tmp/draft-ietf-forces-ceha-__07.txt(835): update_references( > Security > > consideration as defined in section 9 of [RFC5810] applies.) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(850): update_references( > [RFC2119] > > Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP > > 14, RFC 2119, March 1997.) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(855): update_references( > [RFC5810] Doria, > > A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., > Gopal, R., > > and J. Halpern, "Forwarding and Control Element Separation > (ForCES) Protocol > > Specification", RFC 5810, March 2010. > > /tmp/draft-ietf-forces-ceha-__07.txt(860): update_references( > [RFC3654] > > Khosravi, H. and T. Anderson, "Requirements for Separation of IP > Control and > > Forwarding", RFC 3654, November 2003.) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(864): update_references( > [RFC3746] Yang, > > L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and > Control Element > > Separation (ForCES) Framework", RFC 3746, April 2004.) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(868): update_references( > [RFC5812] > > Halpern, J. and J. Hadi Salim, "Forwarding and Control Element > Separation > > (ForCES) Forwarding Element Model", RFC 5812, March 2010.) > > . > > /tmp/draft-ietf-forces-ceha-__07.txt(869): Appendix start: > Appendix A. New > > FEPO version. > > /tmp/draft-ietf-forces-ceha-__07.txt(871): update_references( > The xml has > > been validated against the schema defined in [RFC5812].) > > . > > update_references( The following definitions are taken from > > [RFC3654]and [RFC3746]:) > > update_references( the ForCES Framework in [RFC3746].) > > update_references( transfer mechanisms as defined in [RFC5810].) > > update_references( by the FEPO LFB in [RFC5810], Appendix B. In > > Section 3.1 of this) > > update_references( 1. To describe with more clarity (than [RFC5810]) > > how current cold-) > > update_references( 2. To describe how to evolve the [RFC5810] > > cold-standby setup to a) > > update_references( The design intent of the current [RFC5810] as > well > > as this document) > > update_references( setup in [RFC5810]:) > > update_references( per [RFC5810] definition which is repeated for > > contextual reasons in) > > update_references( a detected failure. The FEObject FEState > > component [RFC5812] defines) > > update_references( and can turn it on by setting it to OperEnable. > > Note: [RFC5812]) > > update_references( timer [RFC5810] is started. The FE MAY continue > > to forward packets) > > update_references( bring down its forwarding path (and set the > > [RFC5812] FEObject) > > update_references( Security consideration as defined in section 9 of > > [RFC5810] applies.) > > update_references( [RFC2119] Bradner, S., "Key words for use in > RFCs to > > Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.) > > ref_def[RFC2119] at 708: [RFC2119] Bradner, S., "Key words for > use in > > RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. > > update_references( [RFC5810] Doria, A., Hadi Salim, J., Haas, R., > > Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, > "Forwarding > > and Control Element Separation (ForCES) Protocol Specification", RFC > > 5810, March 2010.) > > ref_def[RFC5810] at 711: [RFC5810] Doria, A., Hadi Salim, J., Haas, > > R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, > > "Forwarding and Control Element Separation (ForCES) Protocol > > Specification", RFC 5810, March 2010. > > update_references( [RFC3654] Khosravi, H. and T. Anderson, > > "Requirements for Separation of IP Control and Forwarding", RFC > 3654, > > November 2003.) > > ref_def[RFC3654] at 718: [RFC3654] Khosravi, H. and T. Anderson, > > "Requirements for Separation of IP Control and Forwarding", RFC > 3654, > > November 2003. > > update_references( [RFC3746] Yang, L., Dantu, R., Anderson, T., > and R. > > Gopal, "Forwarding and Control Element Separation (ForCES) > Framework", > > RFC 3746, April 2004.) > > ref_def[RFC3746] at 721: [RFC3746] Yang, L., Dantu, R., > Anderson, T., > > and R. Gopal, "Forwarding and Control Element Separation (ForCES) > > Framework", RFC 3746, April 2004. > > update_references( [RFC5812] Halpern, J. and J. Hadi Salim, > "Forwarding > > and Control Element Separation (ForCES) Forwarding Element > Model", RFC > > 5812, March 2010.) > > ref_def[RFC5812] at 725: [RFC5812] Halpern, J. and J. Hadi Salim, > > "Forwarding and Control Element Separation (ForCES) Forwarding > Element > > Model", RFC 5812, March 2010. > > Appendix start: Appendix A. New FEPO version > > update_references( The xml has been validated against the schema > > defined in [RFC5812].) > > Showing Errors (**), Flaws (~~), Warnings (==), and Comments (--). > > Errors MUST be fixed before draft submission. Flaws SHOULD be > fixed before > > draft submission. > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > > http://trustee.ietf.org/__license-info > ): > > ------------------------------__------------------------------__--------------- > > No issues found here. > > Checking nits according to > http://www.ietf.org/id-info/__1id-guidelines.txt > : > > ------------------------------__------------------------------__--------------- > > No issues found here. > > Running in submission checking mode -- *not* checking nits > according to > > http://www.ietf.org/id-info/__checklist > . > > ------------------------------__------------------------------__--------------- > > No nits found. > > +++++++++++++++++++++END++++++__++++++++++++++++++ > > > On Mon, Jun 3, 2013 at 12:38 PM, Jamal Hadi Salim > > >> wrote: > > Thanks Bhumip. > I can verify that no IPR issues were ever brought up by the > authors > or any one > attending the WG or on the lists over the years in regards > to the > contents of this > document. > > cheers, > jamal > > > On Mon, Jun 3, 2013 at 11:31 AM, B.Khasnabish@ieee.org > > > > > >> wrote: > > Thanks Jamal. > Pls note that to the best of my knowledge there is no > IPR issue > involved with this draft. > In addition, I have not heard any objection re > publishing this > as well. > I'll finalize the shepherd's writeup soon. Thanks again. > Best. > Bhumip > > > On Thu, May 23, 2013 at 8:47 AM, Jamal Hadi Salim > > >> wrote: > > > Bhumip has graciously agreed to shepherd the CEHA > draft: > https://datatracker.ietf.org/__doc/draft-ietf-forces-ceha/ > > > This the last outstanding document from the > previous charter > that > has not started the publication journey. > > Thanks Bhumip. > > cheers, > jamal > > _________________________________________________ > forces mailing list > forces@ietf.org > > https://www.ietf.org/mailman/__listinfo/forces > > > > > > > > > > > _________________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/__listinfo/forces > > > From ehalep@gmail.com Wed Jun 5 07:53:08 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8B21F9AA5 for ; Wed, 5 Jun 2013 07:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqN2sZXncDqr for ; Wed, 5 Jun 2013 07:53:07 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA1521F911B for ; Wed, 5 Jun 2013 07:53:06 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id z7so1272816eaf.5 for ; Wed, 05 Jun 2013 07:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=Z1KRgGXfoKL/z6TuznN3inKEifcamCU7mbvRdRTzHtE=; b=rJPNw2ULx09HxLHDHlPsEL6pZbUk7eJZKnXrbb/+vdreO1e2u+Gfe4seqyKqCF5Jp4 80j3apC+lkWHYsbxZrV/xJ7wQEOwsa0AHj69KxPNoAhTXQqRNhIZVm77BfnQPdQgIpGw zxgRywjqtahVLZ3Wt0aOJH4412loY0DtLW9w6Zrt3+6l/bICC091F6AOJDg5LsXnOiJS 0UT9K9ULhq1k+QKwW/85OQt+VTcQcdrzwrOfjjLKWMasxdItfriQpO8oLGv0gnppQFx4 1WImRL0jxkxHHjc+Z4BJeR5gFOmNaLBZmPKknPx0kezKz+bUWkQphzIpq2xeQLS7lngg ADsA== X-Received: by 10.14.9.136 with SMTP id 8mr29201478eet.37.1370443985997; Wed, 05 Jun 2013 07:53:05 -0700 (PDT) Received: from EhalepXPS (ppp046177110179.access.hol.gr. [46.177.110.179]) by mx.google.com with ESMTPSA id g7sm98426818eew.15.2013.06.05.07.53.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Jun 2013 07:53:05 -0700 (PDT) From: "Haleplidis Evangelos" To: Date: Wed, 5 Jun 2013 17:53:02 +0300 Message-ID: <008d01ce61fc$61edf280$25c9d780$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01CE6215.873B2A80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5h/GDXWhIldZiBRv2SS1CGNtkJgw== Content-Language: el Subject: [forces] LFB Topology possible errata X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:53:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008E_01CE6215.873B2A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings to the list, Just a question regarding the LFB Topology in RFC 5812 and possibly an errata: In section "5.3.3. LFBTopology and LFBLinkType", page 110 it starts with: "The optional LFBTopology component." Is the LFB Topology optional? The xml schema of the LFB Object specify the LFBTopology component as mandatory. Additionally section "5.2.1 ModifiableLFBTopology", page 106 specifies that if the LFB Topology is static the Supported LFBs can be inferred from the LFB Topology, possibly meaning that it should be there. Imho, LFB Topology is not optional, even if the LFB Topology is static. A CE may have need to read the topology to understand the internals of the FE to see which datapath functions are implemented. Regards, Evangelos Haleplidis. ------=_NextPart_000_008E_01CE6215.873B2A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings to the list,

 

Just a question regarding the LFB = Topology in RFC 5812 and possibly an errata:

 

In section “5.3.3. = LFBTopology and LFBLinkType”, page 110 it starts = with:

“The optional LFBTopology = component…”

 

Is the LFB Topology optional? The xml schema of the LFB = Object specify the LFBTopology component as = mandatory.

 

Additionally section “5.2.1 = ModifiableLFBTopology”, page 106 specifies that if the LFB = Topology is static the Supported LFBs can be inferred from the LFB = Topology, possibly meaning that it should be = there.

 

Imho, LFB Topology is not optional, even if the LFB = Topology is static. A CE may have need to read the topology to = understand the internals of the FE to see which datapath functions are = implemented.

 

Regards,

Evangelos = Haleplidis.

------=_NextPart_000_008E_01CE6215.873B2A80-- From hadi@mojatatu.com Thu Jun 6 06:08:16 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E820921F99A7 for ; Thu, 6 Jun 2013 06:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XNcTDi2CP6O for ; Thu, 6 Jun 2013 06:08:16 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 31EE221F99A4 for ; Thu, 6 Jun 2013 06:08:15 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w8so1879765vbf.7 for ; Thu, 06 Jun 2013 06:08:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=+xXGfi0XCWVrGUcjcKnGW3s9kfPaKwdAxZZxq9jFWRU=; b=VCds5Ne21uYwk73FJRjKszXwhXRuJZNg1d7vrEz8XooCFLvxlzzA7/eh/OZ/7AUUFv 31Rp6n9qesezKg8TRMAgMAs2Yb3GWHQkxXlfgYJsSr08pwY5xMQ69/uO55FL/Z+cDGJQ 6XBlUTywDc3kOPeqxodJSvl6M1G2UYQvr38waOWw3UY3hJI9RofNzRHb0B7Q7/pmnqp9 xX6348MmBZsaDaydk9PRygTpdN6avGIiKTNTxjn+I5AOH/WGo7pPDUk0h90b27ogl8H2 i+w04GqSpYInfMubpxUIemfvBXzOReuQgfBQ9Ll8K4y0+bgUfbW+ed5+uEq3LFvqeEdY iRiA== X-Received: by 10.52.18.137 with SMTP id w9mr18727594vdd.50.1370524095384; Thu, 06 Jun 2013 06:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.155.71 with HTTP; Thu, 6 Jun 2013 06:07:55 -0700 (PDT) In-Reply-To: <008d01ce61fc$61edf280$25c9d780$@com> References: <008d01ce61fc$61edf280$25c9d780$@com> From: Jamal Hadi Salim Date: Thu, 6 Jun 2013 09:07:55 -0400 Message-ID: To: Haleplidis Evangelos Content-Type: multipart/alternative; boundary=bcaec502d742dca1f204de7c015b X-Gm-Message-State: ALoCoQnph0w+llHedD4+FhVBE32yKKcFjDv5A4VDOS980tqibDj1kCp6urJUOGLQY0nn0QTyQf1Q Cc: "forces@ietf.org" Subject: Re: [forces] LFB Topology possible errata X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 13:08:17 -0000 --bcaec502d742dca1f204de7c015b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greetings Evangelos, On Wed, Jun 5, 2013 at 10:53 AM, Haleplidis Evangelos wro= te: > Greetings to the list,**** > > ** ** > > Just a question regarding the LFB Topology in RFC 5812 and possibly an > errata:**** > > ** ** > > In section =935.3.3. LFBTopology and LFBLinkType=94, page 110 it starts w= ith:* > *** > > =93The optional LFBTopology component=85=94**** > > ** ** > > Is the LFB Topology optional? The xml schema of the LFB Object specify th= e > LFBTopology component as mandatory.**** > > ** ** > > Additionally section =935.2.1 ModifiableLFBTopology=94, page 106 specifie= s > that if the LFB Topology is static the Supported LFBs can be inferred fro= m > the LFB Topology, possibly meaning that it should be there.**** > > ** > Yes, there's either lack of clarity and possibly a contradiction there. I believe the schema is correct. Joel? > ** > > Imho, LFB Topology is not optional, even if the LFB Topology is static. A > CE may have need to read the topology to understand the internals of the = FE > to see which datapath functions are implemented.**** > > ** > In practise so far (speaking of our implementation), it hasnt been necessary to advertise the topology when it is not modifiable. In principle i agree that we should always advertise it regardless of whether it is static or modifiable. cheers, jamal --bcaec502d742dca1f204de7c015b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Greetings Evangelos,

On Wed, Jun 5, 2013 at 10:53 AM, Haleplidis Evange= los <ehalep@gmail.com> wrote:

Greetings to the list,=

=A0

Just a question regarding the LFB = Topology in RFC 5812 and possibly an errata:

=A0

In section =935.3.3. LFBTopology and LFBLinkType=94, page= 110 it starts with:

=93The optional LFBTopology component=85=94

=A0

Is the LFB Topology optional? The = xml schema of the LFB Object specify the LFBTopology component as mandatory= .

=A0

Additionally section =935.2.1 Modi= fiableLFBTopology=94, page 106 specifies that if the LFB Topology is static= the Supported LFBs can be inferred from the LFB Topology, possibly meaning= that it should be there.

<= /blockquote>


Yes, there's eithe= r lack of clarity and possibly a contradiction there.
I bel= ieve the schema is correct. Joel?
=A0

=A0

Imho, LFB Topology is not optio= nal, even if the LFB Topology is static. A CE may have need to read the top= ology to understand the internals of the FE to see which datapath functions= are implemented.

<= /blockquote>

In practise so far (speaking of our i= mplementation), it hasnt been necessary to advertise
the to= pology when it is not modifiable. In principle i agree that we should alway= s
advertise it regardless of whether it is static or modifiable.

cheers,
jamal

=A0
--bcaec502d742dca1f204de7c015b-- From joel@stevecrocker.com Thu Jun 6 07:36:47 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DCD21F92FC for ; Thu, 6 Jun 2013 07:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DSL=1.129, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVL9-2o32PCT for ; Thu, 6 Jun 2013 07:36:42 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id 29AEA21F93E0 for ; Thu, 6 Jun 2013 07:36:41 -0700 (PDT) Received: from dummy.name; Thu, 06 Jun 2013 14:36:41 +0000 Message-ID: <51B09E76.7030807@stevecrocker.com> Date: Thu, 06 Jun 2013 10:36:38 -0400 From: Joel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jamal Hadi Salim References: <008d01ce61fc$61edf280$25c9d780$@com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "forces@ietf.org" Subject: Re: [forces] LFB Topology possible errata X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 14:36:47 -0000 I agree that the text is wrong and the schema is right. Thus, an errata is appropriate. Yours, Joel On 6/6/2013 9:07 AM, Jamal Hadi Salim wrote: > Greetings Evangelos, > > On Wed, Jun 5, 2013 at 10:53 AM, Haleplidis Evangelos > wrote: > > Greetings to the list,____ > > __ __ > > Just a question regarding the LFB Topology in RFC 5812 and possibly > an errata:____ > > __ __ > > In section “5.3.3. LFBTopology and LFBLinkType”, page 110 it starts > with:____ > > “The optional LFBTopology component…”____ > > __ __ > > Is the LFB Topology optional? The xml schema of the LFB Object > specify the LFBTopology component as mandatory.____ > > __ __ > > Additionally section “5.2.1 ModifiableLFBTopology”, page 106 > specifies that if the LFB Topology is static the Supported LFBs can > be inferred from the LFB Topology, possibly meaning that it should > be there.____ > > __ > > > > Yes, there's either lack of clarity and possibly a contradiction there. > I believe the schema is correct. Joel? > > __ > > Imho, LFB Topology is not optional, even if the LFB Topology is > static. A CE may have need to read the topology to understand the > internals of the FE to see which datapath functions are implemented.____ > > __ > > > In practise so far (speaking of our implementation), it hasnt been > necessary to advertise > the topology when it is not modifiable. In principle i agree that we > should always > advertise it regardless of whether it is static or modifiable. > > cheers, > jamal > > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From vumip1@gmail.com Mon Jun 10 18:09:40 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B93121F9600 for ; Mon, 10 Jun 2013 18:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF340pw8TGid for ; Mon, 10 Jun 2013 18:09:38 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1612321F918F for ; Mon, 10 Jun 2013 18:09:37 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so1431857wiv.9 for ; Mon, 10 Jun 2013 18:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=YK1eHNOkj5/Ft1Gp7ID8QJTF1O7xsM5IkJvDbnLI9Y4=; b=iP98PeETYFkt9e0zQJy5Vk2xCp7hPTVAYQpYea3u9/xuJoHMt6icwzL8I2YDSuJKEt NBuKmW5MeuORmNjq1EEPil0K9MPMnkc/lGtPh8mqCkmYRxjvOnMq/+UVA5hE9o5eZNVE lpQKVpG0bq93ACxve92PP7+85/zknKgFNKJw3ggxd3BFelRg7iLK2a0zFEZJy5Qapu3t xyyzAADXX22lzVjGL+FO6dy4g4rwUc9Ek7zS1fNCDa1w/LwFQTDIvINhKmBC0bUVhnpQ i0+8aE98uoU0EbRGtAADKtUfQ2Z27m5hB8lEO9iZ6fsG2r2WpPrj+zHe1h0l28qvaOIn 3sjw== MIME-Version: 1.0 X-Received: by 10.180.185.84 with SMTP id fa20mr3707878wic.49.1370912976939; Mon, 10 Jun 2013 18:09:36 -0700 (PDT) Received: by 10.216.159.1 with HTTP; Mon, 10 Jun 2013 18:09:36 -0700 (PDT) Date: Mon, 10 Jun 2013 21:09:36 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=001a11c2404c0232b604ded68de0 Cc: forces@ietf.org, jmh@joelhalpern.com Subject: [forces] Shepherd write-up for draft-ietf-forces-ceha-07.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 01:09:40 -0000 --001a11c2404c0232b604ded68de0 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, Below PLEASE find shepherd write-up for the CE-HA draft (http://www.ietf.org/id/draft-ietf-forces-ceha-07.txt). Please start the IESG submission process as appropriate. Thanks a lot. Best. Bhumip Document: draft-ietf-forces-ceha-07.txt Title: ForCES Intra-NE High Availability Authors: K. Ogawa, W. M. Wang, E. Haleplidis, and J. Hadi Salim Intended status: Standards Track (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Yes, this document is a Standards Track document (Proposed Standard). The title page of the draft reflects the RFC type. The choice of standards track is a WG mandate based on previous charter. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This draft discusses Control Element High Availability (CE HA) within a ForCES Network Element. Architecture, protocol, and message exchange (sequence) for hot and cold standby of ForCES control element are discussed. Since the HA parameterization in an FE is driven by configuring the FE Protocol Object (FEPO) LFB, new validated (against the schema defined in RFC5812) XML version of FEPO has also been presented. Working Group Summary: Standard WG discussions, nothing controversial. Document Quality: Based on discussions with ForCES mtg. attendees and dialog participants, it appears that there are a few implementations of this draft. The original version (ver. 00) of this draft was published in Oct. 2010 and since then it has undergone updates based on implementation experiences and other discussion. Personnel: Bhumip Khasnabish is the Document Shepherd. Adrian Farrel is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Yes, I reviewed this draft thoroughly and gave comments/suggestions on earlier versions. The authors have used my suggestions to update this draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No I have no concerns. This draft has gone through sufficient number of reviews and implementation cycles/refinements. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No, not at this point in time or for this version. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The shepherd has polled the authors of this draft. There are no IPR issues disclosed or known for the materials presented in this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR issues related to this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Yes, the WG consensus is strong. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal or indicated any extreme discontent on this draft. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The authors should consider fixing the few minor nits before finalizing/publishing this draft. There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ------------------------------------------------------------------------------------------------------- == Line 344 has weird spacing: '... |try v...' == Line 595 has weird spacing: '...ociated v...' == Line 596 has weird spacing: '...)|CE or retry...' Checking references for intended status: Proposed Standard ------------------------------------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 708, but no explicit reference was found in the text ------------------------------------------------------------------------------------------------------- Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has an IANA considerations section that is appropriately filled out that change a core LFB (FEPO). YES, it does require review by the ForCES IANA experts (13) Have all references within this document been identified as either normative or informative? Yes, however, update(s) may be required after the ID nits check based fixes are done. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The publication of this drat will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Yes, there are impacts due to the existence of and configuration of the new *FE Protocol Object* (FEPO) *Logical Functional Block* (LFB). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. ForCES IANA expert review is required for the new registries that are described in #17 above. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The XML definitions have been vetted by various XML validators against the ForCES model schema. The XML defined in the document has also been verified by implementations about which the Document Shepherd has been made aware of. =======================.............END..............========================== --001a11c2404c0232b604ded68de0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian,=A0=A0=20

=A0

Below PLEASE find shepherd wr= ite-up for the CE-HA
Please start the IESG submiss= ion process as appropriate.

=A0

Thanks a lot.

=A0

Best.

=A0

Bhumip
=A0
=A0

Document: draft-ie= tf-forces-ceha-07.txt

Title:=A0=A0=A0 ForCES Intra-NE High Availability

Authors: =A0= K. Ogawa, W. M. Wang, E. Haleplidis, and J. Hadi Salim

Intended status:=A0= Standards Track=A0

(1) What type of RFC is b= eing requested (BCP, Proposed Standard, Internet Standard, Informational, E= xperimental, or Historic)? Why is this the proper type of RFC? Is this type= of RFC indicated in the title page header?

Yes, this document is a S= tandards Track document (Proposed Standard). The title page of the draft re= flects the RFC type. The choice of standards track is a WG mandate based on= previous charter. =A0

=A0

(2) The IESG approval ann= ouncement includes a Document Announcement Write-Up. Please provide such a = Document Announcement Write-Up. Recent examples can be found in the "A= ction" announcements for approved documents. The approval announcement= contains the following sections:

Technical Summary: = This draft discusses Control Element High Availability (CE HA) within a For= CES Network Element. Architecture, protocol, and message exchange (sequence= ) for hot and cold standby of ForCES control element are discussed.= =A0 Since the HA parameterization in an FE is driven by configuring = the FE Protocol Object (FEPO) LFB, new validated (against the schema define= d in RFC5812) XML version of FEPO has also been presented.

Working Group Summa= ry: Standard WG discussions, nothing controversial.

Document Quality: B= ased on discussions with ForCES mtg. attendees and dialog participants, it = appears that there are a few implementations of this draft. The original ve= rsion (ver. 00) of this draft was published in Oct. 2010 and since then it = has undergone updates based on implementation experiences and other discuss= ion.

Personnel: Bhumip K= hasnabish is the Document Shepherd. Adrian Farrel is the Responsible Area D= irector.

=A0

(3) Briefly describe the = review of this document that was performed by the Document Shepherd. If thi= s version of the document is not ready for publication, please explain why = the document is being forwarded to the IESG.

Yes, I reviewed this draf= t thoroughly and gave comments/suggestions on earlier versions. The authors= have used my suggestions to update this draft.

=A0

(4) Does the document She= pherd have any concerns about the depth or breadth of the reviews that have= been performed?

No I have no concerns. Th= is draft has gone through sufficient number of reviews and implementation c= ycles/refinements.

=A0

=A0(5) Do po= rtions of the document need review from a particular or from broader perspe= ctive, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or inte= rnationalization? If so, describe the review that took place.

No, not at this point in = time or for this version.

=A0

(6) Describe any specific= concerns or issues that the Document Shepherd has with this document that = the Responsible Area Director and/or the IESG should be aware of? For examp= le, perhaps he or she is uncomfortable with certain parts of the document, = or has concerns whether there really is a need for it. In any event, if the= WG has discussed those issues and has indicated that it still wishes to ad= vance the document, detail those concerns here.

None.

=A0

(7) Has each author confi= rmed that any and all appropriate IPR disclosures required for full conform= ance with the provisions of BCP 78 and BCP 79 have already been filed. If n= ot, explain why?

The shepherd has polled t= he authors of this draft. There are no IPR issues disclo= sed or known for the materials presented in this draft.

=A0

(8) Has an IPR disclosure= been filed that references this document? If so, summarize any WG discussi= on and conclusion regarding the IPR disclosures.

There are no IPR issues r= elated to this draft.

=A0

(9) How solid is the WG c= onsensus behind this document? Does it represent the strong concurrence of = a few individuals, with others being silent, or does the WG as a whole unde= rstand and agree with it?

Yes, the WG consensus is = strong.

=A0

(10) Has anyone threatene= d an appeal or otherwise indicated extreme discontent? If so, please summar= ise the areas of conflict in separate email messages to the Responsible Are= a Director. (It should be in a separate email because this questionnaire is= publicly available.)

No one has threatened an = appeal or indicated any extreme discontent on this draft.


(11) Identify any ID nits the Do= cument Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/= and the Internet-Drafts Checklist). Boilerplate checks are not enough; thi= s check needs to be thorough.

The authors should consider fixing the= few minor nits before finalizing/publishing this draft.

There are 6 instances of too long lines = in the document, the longest one being 1 character in excess of 72. Miscell= aneous warnings:

----------------------------------------= ---------------------------------------------------------------

=A0 =3D=3D Line 344 has wei= rd spacing: '...=A0=A0 |try=A0 v...'

=A0 =3D=3D Line 595 has wei= rd spacing: '...ociated=A0=A0 v...'

=A0 =3D=3D Line 596 has wei= rd spacing: '...)|CE or=A0 retry...'

=A0 Checking references for= intended status: Proposed Standard

=A0------------------------= ---------------------------------------------------------------------------= ----

=A0 (See RFCs 3967 and 4897= for information about using normative references to lower-maturity documen= ts in RFCs)

=A0 =3D=3D Unused Reference= : 'RFC2119' is defined on line 708, but no explicit reference was f= ound in the text

----------------------------------------= ---------------------------------------------------------------

=A0=A0=A0=A0 Summary: 1 err= or (**), 0 flaws (~~), 4 warnings (=3D=3D), 1 comment (--).

=A0

=A0
(12) Describe how th= e document meets any required formal review criteria, such as the MIB Docto= r, media type, and URI type reviews.

The document has an IANA = considerations section that is appropriately filled out that change a core = LFB (FEPO). YES, it does require review by the ForCES IANA experts

=A0

(13) Have all references = within this document been identified as either normative or informative?

Yes, however, update(s) m= ay be required after the ID nits check based fixes are done.

=A0

(14) Are there normative = references to documents that are not ready for advancement or are otherwise= in an unclear state? If such normative references exist, what is the plan = for their completion?

No.

=A0

(15) Are there downward n= ormative references (see RFC 3967)? If so, list these downward references t= o support the Area Director in the Last Call procedure.

No.

=A0

(16) Will publication of = this document change the status of any existing RFCs? Are those RFCs listed= on the title page header, listed in the abstract, and discussed in the int= roduction? If the RFCs are not listed in the Abstract and Introduction, exp= lain why, and point to the part of the document where the relationship of t= his document to the other RFCs is discussed. If this information is not in = the document, explain why the WG considers it unnecessary.

The publication of this d= rat will not change the status of any existing RFCs.

=A0

(17) Describe the Documen= t Shepherd's review of the IANA considerations section, especially with= regard to its consistency with the body of the document. Confirm that all = protocol extensions that the document makes are associated with the appropr= iate reservations in IANA registries. Confirm that any referenced IANA regi= stries have been clearly identified. Confirm that newly created IANA regist= ries include a detailed specification of the initial contents for the regis= try, that allocations procedures for future registrations are defined, and = a reasonable name for the new registry has been suggested (see RFC 5226). <= /span>

Yes, there are impacts du= e to the existence of and configuration of the new FE Protocol Object (FEPO) Logical Functional Block (LFB).

=A0

(18) List any new IANA re= gistries that require Expert Review for future allocations. Provide any pub= lic guidance that the IESG would find useful in selecting the IANA Experts = for these new registries.

ForCES IANA expert review= is required for the new registries that are described in #17 above.=

=A0

(19) Describe reviews and= automated checks performed by the Document Shepherd to validate sections o= f the document written in a formal language, such as XML code, BNF rules, M= IB definitions, etc.

The XML definitions have = been vetted by various XML validators against the ForCES model schema. The = XML defined in the document has also been verified by implementations about= which the Document Shepherd has been made aware of.

=A0=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D.............END...........= ...=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=A0

=A0
--001a11c2404c0232b604ded68de0-- From adrian@olddog.co.uk Tue Jun 25 14:16:15 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F82621F9AC5 for ; Tue, 25 Jun 2013 14:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh2-u1pQ-fkA for ; Tue, 25 Jun 2013 14:16:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id D47D021F8B35 for ; Tue, 25 Jun 2013 14:15:38 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5PLFabb026848; Tue, 25 Jun 2013 22:15:36 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5PLFY0g026813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 22:15:35 +0100 From: "Adrian Farrel" To: "'B.Khasnabish@ieee.org'" References: In-Reply-To: Date: Tue, 25 Jun 2013 22:15:31 +0100 Message-ID: <001f01ce71e9$2069db10$613d9130$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CE71F1.8234ABB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJyCoI1vfaz1rnKeAIIZibCja7qeZf/vE3g Content-Language: en-gb Cc: forces@ietf.org, jmh@joelhalpern.com Subject: Re: [forces] Shepherd write-up for draft-ietf-forces-ceha-07.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 21:16:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01CE71F1.8234ABB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Sorry for the delay. Processing this now. In future, more rapid processing can be achieved by sending to the Secretariat with subject line "Publication Request" or by using the data tracker to enter the details. No action for you on this document at the moment. Cheers, Adrian From: B.Khasnabish@ieee.org [mailto:vumip1@gmail.com] Sent: 11 June 2013 02:10 To: adrian@olddog.co.uk Cc: damascene.joachimpillai@verizon.com; hadi@mojatatu.com; jmh@joelhalpern.com; forces@ietf.org Subject: Shepherd write-up for draft-ietf-forces-ceha-07.txt Hi Adrian, Below PLEASE find shepherd write-up for the CE-HA draft (http://www.ietf.org/id/draft-ietf-forces-ceha-07.txt). Please start the IESG submission process as appropriate. Thanks a lot. Best. Bhumip Document: draft-ietf-forces-ceha-07.txt Title: ForCES Intra-NE High Availability Authors: K. Ogawa, W. M. Wang, E. Haleplidis, and J. Hadi Salim Intended status: Standards Track (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Yes, this document is a Standards Track document (Proposed Standard). The title page of the draft reflects the RFC type. The choice of standards track is a WG mandate based on previous charter. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This draft discusses Control Element High Availability (CE HA) within a ForCES Network Element. Architecture, protocol, and message exchange (sequence) for hot and cold standby of ForCES control element are discussed. Since the HA parameterization in an FE is driven by configuring the FE Protocol Object (FEPO) LFB, new validated (against the schema defined in RFC5812) XML version of FEPO has also been presented. Working Group Summary: Standard WG discussions, nothing controversial. Document Quality: Based on discussions with ForCES mtg. attendees and dialog participants, it appears that there are a few implementations of this draft. The original version (ver. 00) of this draft was published in Oct. 2010 and since then it has undergone updates based on implementation experiences and other discussion. Personnel: Bhumip Khasnabish is the Document Shepherd. Adrian Farrel is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Yes, I reviewed this draft thoroughly and gave comments/suggestions on earlier versions. The authors have used my suggestions to update this draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No I have no concerns. This draft has gone through sufficient number of reviews and implementation cycles/refinements. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No, not at this point in time or for this version. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The shepherd has polled the authors of this draft. There are no IPR issues disclosed or known for the materials presented in this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR issues related to this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Yes, the WG consensus is strong. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No one has threatened an appeal or indicated any extreme discontent on this draft. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The authors should consider fixing the few minor nits before finalizing/publishing this draft. There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: -------------------------------------------------------------------------------- ----------------------- == Line 344 has weird spacing: '... |try v...' == Line 595 has weird spacing: '...ociated v...' == Line 596 has weird spacing: '...)|CE or retry...' Checking references for intended status: Proposed Standard -------------------------------------------------------------------------------- ----------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 708, but no explicit reference was found in the text -------------------------------------------------------------------------------- ----------------------- Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document has an IANA considerations section that is appropriately filled out that change a core LFB (FEPO). YES, it does require review by the ForCES IANA experts (13) Have all references within this document been identified as either normative or informative? Yes, however, update(s) may be required after the ID nits check based fixes are done. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The publication of this drat will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Yes, there are impacts due to the existence of and configuration of the new FE Protocol Object (FEPO) Logical Functional Block (LFB). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. ForCES IANA expert review is required for the new registries that are described in #17 above. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The XML definitions have been vetted by various XML validators against the ForCES model schema. The XML defined in the document has also been verified by implementations about which the Document Shepherd has been made aware of. =======================.............END..............========================== ------=_NextPart_000_0020_01CE71F1.8234ABB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

Sorry for the = delay.

Processing this = now.

 

In future, more rapid = processing can be achieved by sending to the Secretariat with subject = line "Publication Request" or by using the data tracker to = enter the details.

 

No action for you on this = document at the moment.

 

Cheers,

Adrian

 

From: = B.Khasnabish@ieee.org [mailto:vumip1@gmail.com]
Sent: 11 June = 2013 02:10
To: adrian@olddog.co.uk
Cc: = damascene.joachimpillai@verizon.com; hadi@mojatatu.com; = jmh@joelhalpern.com; forces@ietf.org
Subject: Shepherd = write-up for = draft-ietf-forces-ceha-07.txt

 

Hi = Adrian,  

 

Below = PLEASE find shepherd write-up for the CE-HA =

 

Thanks a = lot.

 

Best. =

 

Document: = draft-ietf-forces-ceha-07.txt

Title: =    ForCES Intra-NE High Availability

Authors: =  K. Ogawa, W. M. Wang, E. Haleplidis, and J. Hadi Salim =

Intended = status:  Standards Track 

(1) What = type of RFC is being requested (BCP, Proposed Standard, Internet = Standard, Informational, Experimental, or Historic)? Why is this the = proper type of RFC? Is this type of RFC indicated in the title page = header?

Yes, this = document is a Standards Track document (Proposed Standard). The title = page of the draft reflects the RFC type. The choice of standards track = is a WG mandate based on previous charter. =  

 

(2) The = IESG approval announcement includes a Document Announcement Write-Up. = Please provide such a Document Announcement Write-Up. Recent examples = can be found in the "Action" announcements for approved = documents. The approval announcement contains the following sections: =

Technical = Summary: This draft discusses Control Element High Availability (CE HA) = within a ForCES Network Element. Architecture, protocol, and message = exchange (sequence) for hot and cold standby of ForCES control element = are discussed.  Since the HA parameterization in an FE is driven by = configuring the FE Protocol Object (FEPO) LFB, new validated (against = the schema defined in RFC5812) XML version of FEPO has also been = presented.

Working = Group Summary: Standard WG discussions, nothing = controversial.

Document = Quality: Based on discussions with ForCES mtg. attendees and dialog = participants, it appears that there are a few implementations of this = draft. The original version (ver. 00) of this draft was published in = Oct. 2010 and since then it has undergone updates based on = implementation experiences and other discussion.

Personnel: = Bhumip Khasnabish is the Document Shepherd. Adrian Farrel is the = Responsible Area Director.

 

(3) Briefly = describe the review of this document that was performed by the Document = Shepherd. If this version of the document is not ready for publication, = please explain why the document is being forwarded to the IESG. =

Yes, I = reviewed this draft thoroughly and gave comments/suggestions on earlier = versions. The authors have used my suggestions to update this = draft.

 

(4) Does = the document Shepherd have any concerns about the depth or breadth of = the reviews that have been performed?

No I have = no concerns. This draft has gone through sufficient number of reviews = and implementation cycles/refinements.

 

 (5) = Do portions of the document need review from a particular or from = broader perspective, e.g., security, operational complexity, AAA, DNS, = DHCP, XML, or internationalization? If so, describe the review that took = place.

No, not at = this point in time or for this version.

 

(6) = Describe any specific concerns or issues that the Document Shepherd has = with this document that the Responsible Area Director and/or the IESG = should be aware of? For example, perhaps he or she is uncomfortable with = certain parts of the document, or has concerns whether there really is a = need for it. In any event, if the WG has discussed those issues and has = indicated that it still wishes to advance the document, detail those = concerns here.

None.=

 

(7) Has = each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 = have already been filed. If not, explain why?

The = shepherd has polled the authors of this draft. There are no IPR issues = disclosed or known for the materials presented in this draft. =

 

(8) Has an = IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR = disclosures.

There are = no IPR issues related to this draft.

 

(9) How = solid is the WG consensus behind this document? Does it represent the = strong concurrence of a few individuals, with others being silent, or = does the WG as a whole understand and agree with it? =

Yes, the WG = consensus is strong.

 

(10) Has = anyone threatened an appeal or otherwise indicated extreme discontent? = If so, please summarise the areas of conflict in separate email messages = to the Responsible Area Director. (It should be in a separate email = because this questionnaire is publicly available.) =

No one has = threatened an appeal or indicated any extreme discontent on this = draft.


(11) = Identify any ID nits the Document Shepherd has found in this document. = (See http://www.ietf.org/tools/idnits/ and the = Internet-Drafts Checklist). Boilerplate checks are not enough; this = check needs to be thorough.

The authors = should consider fixing the few minor nits before finalizing/publishing = this draft.

There are 6 = instances of too long lines in the document, the longest one being 1 = character in excess of 72. Miscellaneous = warnings:

------------= -------------------------------------------------------------------------= ------------------

  = =3D=3D Line 344 has weird spacing: '...   |try  = v...'

  = =3D=3D Line 595 has weird spacing: '...ociated   = v...'

  = =3D=3D Line 596 has weird spacing: '...)|CE or  = retry...'

  = Checking references for intended status: Proposed = Standard

 ------= -------------------------------------------------------------------------= ------------------------

  (See = RFCs 3967 and 4897 for information about using normative references to = lower-maturity documents in RFCs)

  = =3D=3D Unused Reference: 'RFC2119' is defined on line 708, but no = explicit reference was found in the text

------------= -------------------------------------------------------------------------= ------------------

  =    Summary: 1 error (**), 0 flaws (~~), 4 warnings (=3D=3D), 1 = comment (--).

 

 

(12) = Describe how the document meets any required formal review criteria, = such as the MIB Doctor, media type, and URI type reviews. =

The = document has an IANA considerations section that is appropriately filled = out that change a core LFB (FEPO). YES, it does require review by the = ForCES IANA experts

 

(13) Have = all references within this document been identified as either normative = or informative?

Yes, = however, update(s) may be required after the ID nits check based fixes = are done.

 

(14) Are = there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative = references exist, what is the plan for their = completion?

No. =

 

(15) Are = there downward normative references (see RFC 3967)? If so, list these = downward references to support the Area Director in the Last Call = procedure.

No.

 

(16) Will = publication of this document change the status of any existing RFCs? Are = those RFCs listed on the title page header, listed in the abstract, and = discussed in the introduction? If the RFCs are not listed in the = Abstract and Introduction, explain why, and point to the part of the = document where the relationship of this document to the other RFCs is = discussed. If this information is not in the document, explain why the = WG considers it unnecessary.

The = publication of this drat will not change the status of any existing = RFCs.

 

(17) = Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the = document. Confirm that all protocol extensions that the document makes = are associated with the appropriate reservations in IANA registries. = Confirm that any referenced IANA registries have been clearly = identified. Confirm that newly created IANA registries include a = detailed specification of the initial contents for the registry, that = allocations procedures for future registrations are defined, and a = reasonable name for the new registry has been suggested (see RFC 5226). =

Yes, there = are impacts due to the existence of and configuration of the new FE = Protocol Object (FEPO) Logical Functional Block = (LFB).

 

(18) List = any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful = in selecting the IANA Experts for these new registries. =

ForCES IANA = expert review is required for the new registries that are described in = #17 above.

 

(19) = Describe reviews and automated checks performed by the Document Shepherd = to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc.

The XML = definitions have been vetted by various XML validators against the = ForCES model schema. The XML defined in the document has also been = verified by implementations about which the Document Shepherd has been = made aware of.

 =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D..........= ...END..............=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 

 

------=_NextPart_000_0020_01CE71F1.8234ABB0-- From wwwrun@rfc-editor.org Fri Jun 28 16:48:19 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58C621F9815; Fri, 28 Jun 2013 16:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me14ANYR+zx2; Fri, 28 Jun 2013 16:48:19 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 67E2B21F9649; Fri, 28 Jun 2013 16:48:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4D1A362109; Fri, 28 Jun 2013 16:45:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130628234531.4D1A362109@rfc-editor.org> Date: Fri, 28 Jun 2013 16:45:31 -0700 (PDT) Cc: forces@ietf.org, rfc-editor@rfc-editor.org Subject: [forces] RFC 6956 on Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 23:48:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6956 Title: Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library Author: W. Wang, E. Haleplidis, K. Ogawa, C. Li, J. Halpern Status: Standards Track Stream: IETF Date: June 2013 Mailbox: wmwang@zjsu.edu.cn, ehalep@ece.upatras.gr, ogawa.kentaro@lab.ntt.co.jp, chuanhuang_li@zjsu.edu.cn, joel.halpern@ericsson.com Pages: 111 Characters: 236056 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-forces-lfb-lib-12.txt URL: http://www.rfc-editor.org/rfc/rfc6956.txt This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hadi@mojatatu.com Sat Jun 29 05:59:54 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9711E8116 for ; Sat, 29 Jun 2013 05:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgDhrKJDe9-W for ; Sat, 29 Jun 2013 05:59:50 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id BF0B311E8112 for ; Sat, 29 Jun 2013 05:59:49 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id gd11so1190548vcb.30 for ; Sat, 29 Jun 2013 05:59:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=1PjfjCvZsIRLOJGHxzHf6OMU3l30a0CcyK+hkUw3L2A=; b=FnGaMatVTInHSKG+HgKm41dJ1kruUJeV2lRJjLAljv7o7SpOS3lVKyw/hpALEcrV+h WbDcSlBilzFyayVUd0ir8kcLJhTsDnZ4sy/CLdVbAvOxxmc2Ra4NJ8hIMjZqms1aHHTT YZOsWGhyN6pyxtrWvmvrKIERfOoOEeUAJvITAQoW1WRlq0H2gfgCJiCGzT+99iADh6Do d8w9JMVqoWhbMerPI828zxR2/KNThD1dwy9LHRqlcR2ohv4QGRrPY6gnR7eKKQ6Vvw+q pbJMKOUarV0jznTD/nZ16FmHrQTZn5wgzAzX9IE+ddO4accLMdvcryzqVox9mPST7oeE /qjA== X-Received: by 10.220.185.4 with SMTP id cm4mr7013459vcb.96.1372510782804; Sat, 29 Jun 2013 05:59:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Sat, 29 Jun 2013 05:59:22 -0700 (PDT) In-Reply-To: <20130628234531.4D1A362109@rfc-editor.org> References: <20130628234531.4D1A362109@rfc-editor.org> From: Jamal Hadi Salim Date: Sat, 29 Jun 2013 08:59:22 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2ddd2a8e44904e04a91b7 X-Gm-Message-State: ALoCoQkHVOs1+eubLINK08pQZhM3K1izf6rDvBinN9uBDMYHX0+8qa3oMwWVTH1RozhxLKfhrZg7 Subject: Re: [forces] RFC 6956 on Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 12:59:54 -0000 --001a11c2ddd2a8e44904e04a91b7 Content-Type: text/plain; charset=ISO-8859-1 Congratulations to all the authors for the hardwork and perseverence to get this document out! cheers, jamal On Fri, Jun 28, 2013 at 7:45 PM, wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 6956 > > Title: Forwarding and Control Element Separation > (ForCES) Logical Function Block (LFB) Library > Author: W. Wang, E. Haleplidis, > K. Ogawa, C. Li, > J. Halpern > Status: Standards Track > Stream: IETF > Date: June 2013 > Mailbox: wmwang@zjsu.edu.cn, > ehalep@ece.upatras.gr, > ogawa.kentaro@lab.ntt.co.jp, > chuanhuang_li@zjsu.edu.cn, > joel.halpern@ericsson.com > Pages: 111 > Characters: 236056 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-forces-lfb-lib-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc6956.txt > > This document defines basic classes of Logical Function Blocks (LFBs) > used in Forwarding and Control Element Separation (ForCES). The > basic LFB classes are defined according to the ForCES Forwarding > Element (FE) model and ForCES protocol specifications; they are > scoped to meet requirements of typical router functions and are > considered the basic LFB library for ForCES. The library includes > the descriptions of the LFBs and the XML definitions. > > This document is a product of the Forwarding and Control Element > Separation Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html > . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --001a11c2ddd2a8e44904e04a91b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Congratulations to all the authors for the = hardwork and perseverence to get
this document out!

cheers,
jamal

On Fri, Jun 28, 2013 at 7:45 PM, <rfc-= editor@rfc-editor.org> wrote:
A new Request for Comments is now available in online RFC libraries.


=A0 =A0 =A0 =A0 RFC 6956

=A0 =A0 =A0 =A0 Title: =A0 =A0 =A0Forwarding and Control Element Separation=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ForCES) Logical Function Block (LF= B) Library
=A0 =A0 =A0 =A0 Author: =A0 =A0 W. Wang, E. Haleplidis,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 K. Ogawa, C. Li,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 J. Halpern
=A0 =A0 =A0 =A0 Status: =A0 =A0 Standards Track
=A0 =A0 =A0 =A0 Stream: =A0 =A0 IETF
=A0 =A0 =A0 =A0 Date: =A0 =A0 =A0 June 2013
=A0 =A0 =A0 =A0 Mailbox: =A0 =A0wmwan= g@zjsu.edu.cn,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ehalep@ece.upatras.gr,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ogawa.kentaro@lab.ntt.co.jp,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 chuanhuang_li@zjsu.edu.cn,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 joel.halpern@ericsson.com
=A0 =A0 =A0 =A0 Pages: =A0 =A0 =A0111
=A0 =A0 =A0 =A0 Characters: 236056
=A0 =A0 =A0 =A0 Updates/Obsoletes/SeeAlso: =A0 None

=A0 =A0 =A0 =A0 I-D Tag: =A0 =A0draft-ietf-forces-lfb-lib-12.txt

=A0 =A0 =A0 =A0 URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc6956.txt<= /a>

This document defines basic classes of Logical Function Blocks (LFBs)
used in Forwarding and Control Element Separation (ForCES). =A0The
basic LFB classes are defined according to the ForCES Forwarding
Element (FE) model and ForCES protocol specifications; they are
scoped to meet requirements of typical router functions and are
considered the basic LFB library for ForCES. =A0The library includes
the descriptions of the LFBs and the XML definitions.

This document is a product of the Forwarding and Control Element Separation= Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions=
for improvements. =A0Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. =A0Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=A0 http://www.ietf.org/mailman/listinfo/ietf-announce
=A0 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<= br>
For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.=
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =A0Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
forces mailing list
forces@ietf.org
= https://www.ietf.org/mailman/listinfo/forces

--001a11c2ddd2a8e44904e04a91b7-- From hadi@mojatatu.com Sat Jun 29 06:01:13 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C1611E8117 for ; Sat, 29 Jun 2013 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdD0bKUEpL1x for ; Sat, 29 Jun 2013 06:01:09 -0700 (PDT) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id E715B11E810A for ; Sat, 29 Jun 2013 06:01:08 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id c13so2634013vea.35 for ; Sat, 29 Jun 2013 06:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=GD70gtVW5Igk33XAa2/LlU3r6tJ88QM4cnze+io9eKE=; b=f2Yn+IIv1NOxXAPN75Mm2x5Rx/la0mZKh1+3qxvhzwucw/oqrfGhU9+iGk++Ax5wCb AmO1pagq4z2KquvZ4s/akDTxMlYsgdNnhffm5RkuxRSiasQPTww31OFlDJggQgqRotLT TM/p3U2bNeYb0Zd1Nst4Rl2Kjt6y18cDf8ao5cVGP2XuKMCyEst5GK+2IxixwpXW+ttT c0Jls/pjLxhVSkTt4QNk2YXGgYLjEtXMuUi6Rv8uJwVBawyoOUC3KMER7nlRcCVvGx6F 6GZeBqqurGJDfeM5aNux+dvu4jj2TqILDh6y2fTK7Q7DrfOk6POC4arXGb6XWEYuCzuW 9naA== X-Received: by 10.220.119.77 with SMTP id y13mr6040509vcq.13.1372510868056; Sat, 29 Jun 2013 06:01:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.247.197 with HTTP; Sat, 29 Jun 2013 06:00:47 -0700 (PDT) In-Reply-To: References: <20130628234531.4D1A362109@rfc-editor.org> From: Jamal Hadi Salim Date: Sat, 29 Jun 2013 09:00:47 -0400 Message-ID: To: "forces@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3d814bdcf8a04e04a96d7 X-Gm-Message-State: ALoCoQlTCEVcRtVBBNrCnkVp7vSAks9ElHscSv3rkdIrqFcO8LXPOwnOxgASqACqACYpKXwOCtik Subject: Re: [forces] RFC 6956 on Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 13:01:13 -0000 --001a11c3d814bdcf8a04e04a96d7 Content-Type: text/plain; charset=ISO-8859-1 And not to forget the AD! ;-> cheers, jamal On Sat, Jun 29, 2013 at 8:59 AM, Jamal Hadi Salim wrote: > > Congratulations to all the authors for the hardwork and perseverence to get > this document out! > > cheers, > jamal > > > On Fri, Jun 28, 2013 at 7:45 PM, wrote: > >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 6956 >> >> Title: Forwarding and Control Element Separation >> (ForCES) Logical Function Block (LFB) Library >> Author: W. Wang, E. Haleplidis, >> K. Ogawa, C. Li, >> J. Halpern >> Status: Standards Track >> Stream: IETF >> Date: June 2013 >> Mailbox: wmwang@zjsu.edu.cn, >> ehalep@ece.upatras.gr, >> ogawa.kentaro@lab.ntt.co.jp, >> chuanhuang_li@zjsu.edu.cn, >> joel.halpern@ericsson.com >> Pages: 111 >> Characters: 236056 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-forces-lfb-lib-12.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc6956.txt >> >> This document defines basic classes of Logical Function Blocks (LFBs) >> used in Forwarding and Control Element Separation (ForCES). The >> basic LFB classes are defined according to the ForCES Forwarding >> Element (FE) model and ForCES protocol specifications; they are >> scoped to meet requirements of typical router functions and are >> considered the basic LFB library for ForCES. The library includes >> the descriptions of the LFBs and the XML definitions. >> >> This document is a product of the Forwarding and Control Element >> Separation Working Group of the IETF. >> >> This is now a Proposed Standard. >> >> STANDARDS TRACK: This document specifies an Internet standards track >> protocol for the Internet community,and requests discussion and >> suggestions >> for improvements. Please refer to the current edition of the Internet >> Official Protocol Standards (STD 1) for the standardization state and >> status of this protocol. Distribution of this memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see >> http://www.rfc-editor.org/rfcsearch.html. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> >> _______________________________________________ >> forces mailing list >> forces@ietf.org >> https://www.ietf.org/mailman/listinfo/forces >> > > --001a11c3d814bdcf8a04e04a96d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And not to forget the AD! ;->

cheers= ,
jamal


On Sat, Jun 29, 2013 at 8:59 AM, Jamal Hadi Salim <hadi@m= ojatatu.com> wrote:

Congratulati= ons to all the authors for the hardwork and perseverence to get
this do= cument out!

cheers,
jamal


On Fri, Jun 28, 2013 at 7:45 PM, <rfc-= editor@rfc-editor.org> wrote:
A new Request for Comments is now available in online RFC libraries.


=A0 =A0 =A0 =A0 RFC 6956

=A0 =A0 =A0 =A0 Title: =A0 =A0 =A0Forwarding and Control Element Separation=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ForCES) Logical Function Block (LF= B) Library
=A0 =A0 =A0 =A0 Author: =A0 =A0 W. Wang, E. Haleplidis,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 K. Ogawa, C. Li,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 J. Halpern
=A0 =A0 =A0 =A0 Status: =A0 =A0 Standards Track
=A0 =A0 =A0 =A0 Stream: =A0 =A0 IETF
=A0 =A0 =A0 =A0 Date: =A0 =A0 =A0 June 2013
=A0 =A0 =A0 =A0 Mailbox: =A0 =A0wmwang@zjsu.edu.cn,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ehalep@ece.upatras.gr,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ogawa.kentaro@lab.ntt.co.jp,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 chuanhuang_li@zjsu.edu.cn,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 joel.halpern@ericsson.com
=A0 =A0 =A0 =A0 Pages: =A0 =A0 =A0111
=A0 =A0 =A0 =A0 Characters: 236056
=A0 =A0 =A0 =A0 Updates/Obsoletes/SeeAlso: =A0 None

=A0 =A0 =A0 =A0 I-D Tag: =A0 =A0draft-ietf-forces-lfb-lib-12.txt

=A0 =A0 =A0 =A0 URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc6956.txt<= /a>

This document defines basic classes of Logical Function Blocks (LFBs)
used in Forwarding and Control Element Separation (ForCES). =A0The
basic LFB classes are defined according to the ForCES Forwarding
Element (FE) model and ForCES protocol specifications; they are
scoped to meet requirements of typical router functions and are
considered the basic LFB library for ForCES. =A0The library includes
the descriptions of the LFBs and the XML definitions.

This document is a product of the Forwarding and Control Element Separation= Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions=
for improvements. =A0Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and
status of this protocol. =A0Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=A0 http://www.ietf.org/mailman/listinfo/ietf-announce
=A0 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<= br>
For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.=
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =A0Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
forces mailing list
forces@ietf.org = https://www.ietf.org/mailman/listinfo/forces


--001a11c3d814bdcf8a04e04a96d7-- From wmwang2001@hotmail.com Sat Jun 29 06:46:17 2013 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DB811E812F for ; Sat, 29 Jun 2013 06:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuvDVQG88zJW for ; Sat, 29 Jun 2013 06:46:12 -0700 (PDT) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by ietfa.amsl.com (Postfix) with ESMTP id 021AD11E8115 for ; Sat, 29 Jun 2013 06:46:08 -0700 (PDT) Received: from BLU0-SMTP243 ([65.55.111.136]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Jun 2013 06:46:07 -0700 X-EIP: [iTOmoYnWgJDc5xCygLtIQS4/bbak860j] X-Originating-Email: [wmwang2001@hotmail.com] Message-ID: Received: from WmwangHome ([125.120.82.98]) by BLU0-SMTP243.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Jun 2013 06:46:05 -0700 From: "Wang,Weiming" To: "Jamal Hadi Salim" , References: <20130628234531.4D1A362109@rfc-editor.org> Date: Sat, 29 Jun 2013 21:46:12 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CE7512.12C3B540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 29 Jun 2013 13:46:05.0354 (UTC) FILETIME=[005E10A0:01CE74CF] Subject: Re: [forces] RFC 6956 on Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 13:46:17 -0000 ------=_NextPart_000_005E_01CE7512.12C3B540 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SmFtYWwsIGFsc28gdGhhbmtzIGZvciB5b3VyIGJpZyBlZmZvcnRzIGluIHRoZSBwcm9jZXNzIGJv dGggYXMgdGhlIGtleSBjb250cmlidXRvcnMgYW5kIGFzIHRoZSB3ZyBjaGFpci4NCg0KdGhhbmtz LA0KV2VpbWluZw0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IEph bWFsIEhhZGkgU2FsaW0gDQogIFRvOiBmb3JjZXNAaWV0Zi5vcmcgDQogIFNlbnQ6IFNhdHVyZGF5 LCBKdW5lIDI5LCAyMDEzIDk6MDAgUE0NCiAgU3ViamVjdDogUmU6IFtmb3JjZXNdIFJGQyA2OTU2 IG9uIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIChGb3JDRVMpIExv Z2ljYWwgRnVuY3Rpb24gQmxvY2sgKExGQikgTGlicmFyeQ0KDQoNCiAgQW5kIG5vdCB0byBmb3Jn ZXQgdGhlIEFEISA7LT4NCg0KDQogIGNoZWVycywNCiAgamFtYWwNCg0KDQoNCiAgT24gU2F0LCBK dW4gMjksIDIwMTMgYXQgODo1OSBBTSwgSmFtYWwgSGFkaSBTYWxpbSA8aGFkaUBtb2phdGF0dS5j b20+IHdyb3RlOg0KDQoNCg0KICAgIENvbmdyYXR1bGF0aW9ucyB0byBhbGwgdGhlIGF1dGhvcnMg Zm9yIHRoZSBoYXJkd29yayBhbmQgcGVyc2V2ZXJlbmNlIHRvIGdldA0KICAgIHRoaXMgZG9jdW1l bnQgb3V0IQ0KDQoNCiAgICBjaGVlcnMsDQogICAgamFtYWwNCg0KDQoNCiAgICBPbiBGcmksIEp1 biAyOCwgMjAxMyBhdCA3OjQ1IFBNLCA8cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4gd3JvdGU6 DQoNCiAgICAgIEEgbmV3IFJlcXVlc3QgZm9yIENvbW1lbnRzIGlzIG5vdyBhdmFpbGFibGUgaW4g b25saW5lIFJGQyBsaWJyYXJpZXMuDQoNCg0KICAgICAgICAgICAgICBSRkMgNjk1Ng0KDQogICAg ICAgICAgICAgIFRpdGxlOiAgICAgIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBh cmF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICAgIChGb3JDRVMpIExvZ2ljYWwgRnVuY3Rp b24gQmxvY2sgKExGQikgTGlicmFyeQ0KICAgICAgICAgICAgICBBdXRob3I6ICAgICBXLiBXYW5n LCBFLiBIYWxlcGxpZGlzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICBLLiBPZ2F3YSwgQy4g TGksDQogICAgICAgICAgICAgICAgICAgICAgICAgIEouIEhhbHBlcm4NCiAgICAgICAgICAgICAg U3RhdHVzOiAgICAgU3RhbmRhcmRzIFRyYWNrDQogICAgICAgICAgICAgIFN0cmVhbTogICAgIElF VEYNCiAgICAgICAgICAgICAgRGF0ZTogICAgICAgSnVuZSAyMDEzDQogICAgICAgICAgICAgIE1h aWxib3g6ICAgIHdtd2FuZ0B6anN1LmVkdS5jbiwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ZWhhbGVwQGVjZS51cGF0cmFzLmdyLA0KICAgICAgICAgICAgICAgICAgICAgICAgICBvZ2F3YS5r ZW50YXJvQGxhYi5udHQuY28uanAsDQogICAgICAgICAgICAgICAgICAgICAgICAgIGNodWFuaHVh bmdfbGlAempzdS5lZHUuY24sDQogICAgICAgICAgICAgICAgICAgICAgICAgIGpvZWwuaGFscGVy bkBlcmljc3Nvbi5jb20NCiAgICAgICAgICAgICAgUGFnZXM6ICAgICAgMTExDQogICAgICAgICAg ICAgIENoYXJhY3RlcnM6IDIzNjA1Ng0KICAgICAgICAgICAgICBVcGRhdGVzL09ic29sZXRlcy9T ZWVBbHNvOiAgIE5vbmUNCg0KICAgICAgICAgICAgICBJLUQgVGFnOiAgICBkcmFmdC1pZXRmLWZv cmNlcy1sZmItbGliLTEyLnR4dA0KDQogICAgICAgICAgICAgIFVSTDogICAgICAgIGh0dHA6Ly93 d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzY5NTYudHh0DQoNCiAgICAgIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBiYXNpYyBjbGFzc2VzIG9mIExvZ2ljYWwgRnVuY3Rpb24gQmxvY2tzIChMRkJzKQ0K ICAgICAgdXNlZCBpbiBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbiAo Rm9yQ0VTKS4gIFRoZQ0KICAgICAgYmFzaWMgTEZCIGNsYXNzZXMgYXJlIGRlZmluZWQgYWNjb3Jk aW5nIHRvIHRoZSBGb3JDRVMgRm9yd2FyZGluZw0KICAgICAgRWxlbWVudCAoRkUpIG1vZGVsIGFu ZCBGb3JDRVMgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnM7IHRoZXkgYXJlDQogICAgICBzY29wZWQg dG8gbWVldCByZXF1aXJlbWVudHMgb2YgdHlwaWNhbCByb3V0ZXIgZnVuY3Rpb25zIGFuZCBhcmUN CiAgICAgIGNvbnNpZGVyZWQgdGhlIGJhc2ljIExGQiBsaWJyYXJ5IGZvciBGb3JDRVMuICBUaGUg bGlicmFyeSBpbmNsdWRlcw0KICAgICAgdGhlIGRlc2NyaXB0aW9ucyBvZiB0aGUgTEZCcyBhbmQg dGhlIFhNTCBkZWZpbml0aW9ucy4NCg0KICAgICAgVGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qg b2YgdGhlIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBTZXBhcmF0aW9uIFdvcmtpbmcg R3JvdXAgb2YgdGhlIElFVEYuDQoNCiAgICAgIFRoaXMgaXMgbm93IGEgUHJvcG9zZWQgU3RhbmRh cmQuDQoNCiAgICAgIFNUQU5EQVJEUyBUUkFDSzogVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4g SW50ZXJuZXQgc3RhbmRhcmRzIHRyYWNrDQogICAgICBwcm90b2NvbCBmb3IgdGhlIEludGVybmV0 IGNvbW11bml0eSxhbmQgcmVxdWVzdHMgZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMNCiAgICAg IGZvciBpbXByb3ZlbWVudHMuICBQbGVhc2UgcmVmZXIgdG8gdGhlIGN1cnJlbnQgZWRpdGlvbiBv ZiB0aGUgSW50ZXJuZXQNCiAgICAgIE9mZmljaWFsIFByb3RvY29sIFN0YW5kYXJkcyAoU1REIDEp IGZvciB0aGUgc3RhbmRhcmRpemF0aW9uIHN0YXRlIGFuZA0KICAgICAgc3RhdHVzIG9mIHRoaXMg cHJvdG9jb2wuICBEaXN0cmlidXRpb24gb2YgdGhpcyBtZW1vIGlzIHVubGltaXRlZC4NCg0KICAg ICAgVGhpcyBhbm5vdW5jZW1lbnQgaXMgc2VudCB0byB0aGUgSUVURi1Bbm5vdW5jZSBhbmQgcmZj LWRpc3QgbGlzdHMuDQogICAgICBUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUsIHNlZQ0KICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1hbm5vdW5jZQ0K ICAgICAgICBodHRwOi8vbWFpbG1hbi5yZmMtZWRpdG9yLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jm Yy1kaXN0DQoNCiAgICAgIEZvciBzZWFyY2hpbmcgdGhlIFJGQyBzZXJpZXMsIHNlZSBodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmY3NlYXJjaC5odG1sLg0KICAgICAgRm9yIGRvd25sb2FkaW5n IFJGQ3MsIHNlZSBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy5odG1sLg0KDQogICAgICBS ZXF1ZXN0cyBmb3Igc3BlY2lhbCBkaXN0cmlidXRpb24gc2hvdWxkIGJlIGFkZHJlc3NlZCB0byBl aXRoZXIgdGhlDQogICAgICBhdXRob3Igb2YgdGhlIFJGQyBpbiBxdWVzdGlvbiwgb3IgdG8gcmZj LWVkaXRvckByZmMtZWRpdG9yLm9yZy4gIFVubGVzcw0KICAgICAgc3BlY2lmaWNhbGx5IG5vdGVk IG90aGVyd2lzZSBvbiB0aGUgUkZDIGl0c2VsZiwgYWxsIFJGQ3MgYXJlIGZvcg0KICAgICAgdW5s aW1pdGVkIGRpc3RyaWJ1dGlvbi4NCg0KDQogICAgICBUaGUgUkZDIEVkaXRvciBUZWFtDQogICAg ICBBc3NvY2lhdGlvbiBNYW5hZ2VtZW50IFNvbHV0aW9ucywgTExDDQoNCg0KICAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgIGZvcmNlcyBt YWlsaW5nIGxpc3QNCiAgICAgIGZvcmNlc0BpZXRmLm9yZw0KICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMNCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCg0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICBmb3JjZXMgbWFpbGluZyBsaXN0DQogIGZvcmNlc0BpZXRmLm9yZw0KICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcw0K ------=_NextPart_000_005E_01CE7512.12C3B540 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4yMzUwMSI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQz NTsmIzIwMzA3Oz5KYW1hbCwgYWxzbyB0aGFua3MgZm9yIHlvdXIgYmlnIGVmZm9ydHMgaW4gdGhl IA0KcHJvY2VzcyZuYnNwO2JvdGggYXMgdGhlIGtleSBjb250cmlidXRvcnMmbmJzcDthbmQgYXMg dGhlIHdnIGNoYWlyLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQz NTsmIzIwMzA3Oz48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPSYj MjM0MzU7JiMyMDMwNzs+dGhhbmtzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZh Y2U9JiMyMzQzNTsmIzIwMzA3Oz5XZWltaW5nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RF IA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1 cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAw cHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzs7IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5G cm9tOjwvQj4gDQogIDxBIHRpdGxlPWhhZGlAbW9qYXRhdHUuY29tIGhyZWY9Im1haWx0bzpoYWRp QG1vamF0YXR1LmNvbSI+SmFtYWwgSGFkaSANCiAgU2FsaW08L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1mb3Jj ZXNAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXNAaWV0Zi5vcmciPmZvcmNlc0BpZXRm Lm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 Ij48Qj5TZW50OjwvQj4gU2F0dXJkYXksIEp1bmUgMjksIDIwMTMgOTowMCBQTTwvRElWPg0KICA8 RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+IFJl OiBbZm9yY2VzXSBSRkMgNjk1NiBvbiBGb3J3YXJkaW5nIA0KICBhbmQgQ29udHJvbCBFbGVtZW50 IFNlcGFyYXRpb24gKEZvckNFUykgTG9naWNhbCBGdW5jdGlvbiBCbG9jayAoTEZCKSANCiAgTGli cmFyeTwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBkaXI9bHRyPkFuZCBub3QgdG8g Zm9yZ2V0IHRoZSBBRCEgOy0mZ3Q7DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPmNoZWVycyw8 L0RJVj4NCiAgPERJVj5qYW1hbDwvRElWPjwvRElWPg0KICA8RElWIGNsYXNzPWdtYWlsX2V4dHJh PjxCUj48QlI+DQogIDxESVYgY2xhc3M9Z21haWxfcXVvdGU+T24gU2F0LCBKdW4gMjksIDIwMTMg YXQgODo1OSBBTSwgSmFtYWwgSGFkaSBTYWxpbSA8U1BBTiANCiAgZGlyPWx0cj4mbHQ7PEEgaHJl Zj0ibWFpbHRvOmhhZGlAbW9qYXRhdHUuY29tIiANCiAgdGFyZ2V0PV9ibGFuaz5oYWRpQG1vamF0 YXR1LmNvbTwvQT4mZ3Q7PC9TUEFOPiB3cm90ZTo8QlI+DQogIDxCTE9DS1FVT1RFIA0KICBzdHls ZT0iQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4 OyBQQURESU5HLUxFRlQ6IDFleCIgDQogIGNsYXNzPWdtYWlsX3F1b3RlPg0KICAgIDxESVYgZGly PWx0cj4NCiAgICA8RElWPjxCUj48L0RJVj5Db25ncmF0dWxhdGlvbnMgdG8gYWxsIHRoZSBhdXRo b3JzIGZvciB0aGUgaGFyZHdvcmsgYW5kIA0KICAgIHBlcnNldmVyZW5jZSB0byBnZXQNCiAgICA8 RElWPnRoaXMgZG9jdW1lbnQgb3V0ITwvRElWPg0KICAgIDxESVY+PEJSPjwvRElWPg0KICAgIDxE SVY+Y2hlZXJzLDwvRElWPg0KICAgIDxESVY+amFtYWw8L0RJVj48L0RJVj4NCiAgICA8RElWIGNs YXNzPUhPRW5aYj4NCiAgICA8RElWIGNsYXNzPWg1Pg0KICAgIDxESVYgY2xhc3M9Z21haWxfZXh0 cmE+PEJSPjxCUj4NCiAgICA8RElWIGNsYXNzPWdtYWlsX3F1b3RlPk9uIEZyaSwgSnVuIDI4LCAy MDEzIGF0IDc6NDUgUE0sIDxTUEFOIGRpcj1sdHI+Jmx0OzxBIA0KICAgIGhyZWY9Im1haWx0bzpy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIiANCiAgICB0YXJnZXQ9X2JsYW5rPnJmYy1lZGl0b3JA cmZjLWVkaXRvci5vcmc8L0E+Jmd0OzwvU1BBTj4gd3JvdGU6PEJSPg0KICAgIDxCTE9DS1FVT1RF IA0KICAgIHN0eWxlPSJCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBw eCAwcHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiANCiAgICBjbGFzcz1nbWFpbF9xdW90ZT5B IG5ldyBSZXF1ZXN0IGZvciBDb21tZW50cyBpcyBub3cgYXZhaWxhYmxlIGluIG9ubGluZSANCiAg ICAgIFJGQyBsaWJyYXJpZXMuPEJSPjxCUj48QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFJGQyANCiAgICAgIDY5NTY8QlI+PEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRs ZTogJm5ic3A7ICZuYnNwOyANCiAgICAgICZuYnNwO0ZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxl bWVudCBTZXBhcmF0aW9uPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAgICAgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IChGb3JDRVMpIExvZ2ljYWwg RnVuY3Rpb24gDQogICAgICBCbG9jayAoTEZCKSBMaWJyYXJ5PEJSPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBBdXRob3I6ICZuYnNwOyAmbmJzcDsgDQogICAgICBXLiBXYW5nLCBFLiBIYWxl cGxpZGlzLDxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAg ICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLLiBPZ2F3YSwgQy4gTGksPEJSPiZuYnNw OyAmbmJzcDsgJm5ic3A7IA0KICAgICAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEouIEhhbHBlcm48QlI+Jm5ic3A7IA0KICAgICAgJm5ic3A7ICZuYnNw OyAmbmJzcDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7IFN0YW5kYXJkcyBUcmFjazxCUj4mbmJzcDsg DQogICAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdHJlYW06ICZuYnNwOyAmbmJzcDsgSUVURjxC Uj4mbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAgICZuYnNwOyBEYXRlOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBKdW5lIDIwMTM8QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAgICAg TWFpbGJveDogJm5ic3A7ICZuYnNwOzxBIGhyZWY9Im1haWx0bzp3bXdhbmdAempzdS5lZHUuY24i IA0KICAgICAgdGFyZ2V0PV9ibGFuaz53bXdhbmdAempzdS5lZHUuY248L0E+LDxCUj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8QSANCiAgICAgIGhyZWY9Im1haWx0bzplaGFsZXBAZWNlLnVwYXRyYXMu Z3IiIA0KICAgICAgdGFyZ2V0PV9ibGFuaz5laGFsZXBAZWNlLnVwYXRyYXMuZ3I8L0E+LDxCUj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgDQogICAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyA8QSANCiAgICAgIGhyZWY9Im1haWx0bzpvZ2F3YS5rZW50YXJv QGxhYi5udHQuY28uanAiIA0KICAgICAgdGFyZ2V0PV9ibGFuaz5vZ2F3YS5rZW50YXJvQGxhYi5u dHQuY28uanA8L0E+LDxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAgICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8QSANCiAgICAgIGhyZWY9Im1h aWx0bzpjaHVhbmh1YW5nX2xpQHpqc3UuZWR1LmNuIiANCiAgICAgIHRhcmdldD1fYmxhbms+Y2h1 YW5odWFuZ19saUB6anN1LmVkdS5jbjwvQT4sPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAg ICAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxBIA0K ICAgICAgaHJlZj0ibWFpbHRvOmpvZWwuaGFscGVybkBlcmljc3Nvbi5jb20iIA0KICAgICAgdGFy Z2V0PV9ibGFuaz5qb2VsLmhhbHBlcm5AZXJpY3Nzb24uY29tPC9BPjxCUj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgDQogICAgICBQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsxMTE8QlI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENoYXJhY3RlcnM6IA0KICAgICAgMjM2MDU2PEJS PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVcGRhdGVzL09ic29sZXRlcy9TZWVBbHNvOiAm bmJzcDsgDQogICAgICBOb25lPEJSPjxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSS1E IFRhZzogJm5ic3A7IA0KICAgICAgJm5ic3A7ZHJhZnQtaWV0Zi1mb3JjZXMtbGZiLWxpYi0xMi50 eHQ8QlI+PEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgICAgIFVSTDogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL3JmYy9yZmM2OTU2LnR4dCIgDQogICAgICB0YXJnZXQ9X2JsYW5rPmh0dHA6Ly93d3cu cmZjLWVkaXRvci5vcmcvcmZjL3JmYzY5NTYudHh0PC9BPjxCUj48QlI+VGhpcyANCiAgICAgIGRv Y3VtZW50IGRlZmluZXMgYmFzaWMgY2xhc3NlcyBvZiBMb2dpY2FsIEZ1bmN0aW9uIEJsb2NrcyAo TEZCcyk8QlI+dXNlZCANCiAgICAgIGluIEZvcndhcmRpbmcgYW5kIENvbnRyb2wgRWxlbWVudCBT ZXBhcmF0aW9uIChGb3JDRVMpLiAmbmJzcDtUaGU8QlI+YmFzaWMgDQogICAgICBMRkIgY2xhc3Nl cyBhcmUgZGVmaW5lZCBhY2NvcmRpbmcgdG8gdGhlIEZvckNFUyBGb3J3YXJkaW5nPEJSPkVsZW1l bnQgKEZFKSANCiAgICAgIG1vZGVsIGFuZCBGb3JDRVMgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnM7 IHRoZXkgYXJlPEJSPnNjb3BlZCB0byBtZWV0IA0KICAgICAgcmVxdWlyZW1lbnRzIG9mIHR5cGlj YWwgcm91dGVyIGZ1bmN0aW9ucyBhbmQgYXJlPEJSPmNvbnNpZGVyZWQgdGhlIGJhc2ljIA0KICAg ICAgTEZCIGxpYnJhcnkgZm9yIEZvckNFUy4gJm5ic3A7VGhlIGxpYnJhcnkgaW5jbHVkZXM8QlI+ dGhlIGRlc2NyaXB0aW9ucyBvZiANCiAgICAgIHRoZSBMRkJzIGFuZCB0aGUgWE1MIGRlZmluaXRp b25zLjxCUj48QlI+VGhpcyBkb2N1bWVudCBpcyBhIHByb2R1Y3Qgb2YgdGhlIA0KICAgICAgRm9y d2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gV29ya2luZyBHcm91cCBvZiB0 aGUgDQogICAgICBJRVRGLjxCUj48QlI+VGhpcyBpcyBub3cgYSBQcm9wb3NlZCBTdGFuZGFyZC48 QlI+PEJSPlNUQU5EQVJEUyBUUkFDSzogVGhpcyANCiAgICAgIGRvY3VtZW50IHNwZWNpZmllcyBh biBJbnRlcm5ldCBzdGFuZGFyZHMgdHJhY2s8QlI+cHJvdG9jb2wgZm9yIHRoZSANCiAgICAgIElu dGVybmV0IGNvbW11bml0eSxhbmQgcmVxdWVzdHMgZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnM8 QlI+Zm9yIA0KICAgICAgaW1wcm92ZW1lbnRzLiAmbmJzcDtQbGVhc2UgcmVmZXIgdG8gdGhlIGN1 cnJlbnQgZWRpdGlvbiBvZiB0aGUgDQogICAgICBJbnRlcm5ldDxCUj5PZmZpY2lhbCBQcm90b2Nv bCBTdGFuZGFyZHMgKFNURCAxKSBmb3IgdGhlIHN0YW5kYXJkaXphdGlvbiANCiAgICAgIHN0YXRl IGFuZDxCUj5zdGF0dXMgb2YgdGhpcyBwcm90b2NvbC4gJm5ic3A7RGlzdHJpYnV0aW9uIG9mIHRo aXMgbWVtbyBpcyANCiAgICAgIHVubGltaXRlZC48QlI+PEJSPlRoaXMgYW5ub3VuY2VtZW50IGlz IHNlbnQgdG8gdGhlIElFVEYtQW5ub3VuY2UgYW5kIA0KICAgICAgcmZjLWRpc3QgbGlzdHMuPEJS PlRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSwgc2VlPEJSPiZuYnNwOyA8QSANCiAgICAgIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlIiAN CiAgICAgIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lldGYtYW5ub3VuY2U8L0E+PEJSPiZuYnNwOyANCiAgICAgIDxBIGhyZWY9Imh0dHA6Ly9tYWls bWFuLnJmYy1lZGl0b3Iub3JnL21haWxtYW4vbGlzdGluZm8vcmZjLWRpc3QiIA0KICAgICAgdGFy Z2V0PV9ibGFuaz5odHRwOi8vbWFpbG1hbi5yZmMtZWRpdG9yLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JmYy1kaXN0PC9BPjxCUj48QlI+Rm9yIA0KICAgICAgc2VhcmNoaW5nIHRoZSBSRkMgc2VyaWVz LCBzZWUgPEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmY3NlYXJj aC5odG1sIiANCiAgICAgIHRhcmdldD1fYmxhbms+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9y ZmNzZWFyY2guaHRtbDwvQT4uPEJSPkZvciANCiAgICAgIGRvd25sb2FkaW5nIFJGQ3MsIHNlZSA8 QSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy5odG1sIiANCiAgICAgIHRhcmdl dD1fYmxhbms+aHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMuaHRtbDwvQT4uPEJSPjxCUj5S ZXF1ZXN0cyBmb3IgDQogICAgICBzcGVjaWFsIGRpc3RyaWJ1dGlvbiBzaG91bGQgYmUgYWRkcmVz c2VkIHRvIGVpdGhlciB0aGU8QlI+YXV0aG9yIG9mIHRoZSANCiAgICAgIFJGQyBpbiBxdWVzdGlv biwgb3IgdG8gPEEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciIA0KICAg ICAgdGFyZ2V0PV9ibGFuaz5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9BPi4gJm5ic3A7VW5s ZXNzPEJSPnNwZWNpZmljYWxseSANCiAgICAgIG5vdGVkIG90aGVyd2lzZSBvbiB0aGUgUkZDIGl0 c2VsZiwgYWxsIFJGQ3MgYXJlIGZvcjxCUj51bmxpbWl0ZWQgDQogICAgICBkaXN0cmlidXRpb24u PEJSPjxCUj48QlI+VGhlIFJGQyBFZGl0b3IgVGVhbTxCUj5Bc3NvY2lhdGlvbiBNYW5hZ2VtZW50 IA0KICAgICAgU29sdXRpb25zLCANCiAgICAgIExMQzxCUj48QlI+PEJSPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPmZvcmNlcyANCiAgICAgIG1haWxp bmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86Zm9yY2VzQGlldGYub3JnIiANCiAgICAgIHRhcmdl dD1fYmxhbms+Zm9yY2VzQGlldGYub3JnPC9BPjxCUj48QSANCiAgICAgIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzIiANCiAgICAgIHRhcmdldD1fYmxh bms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXM8L0E+PEJSPjwv QkxPQ0tRVU9URT48L0RJVj48QlI+PC9ESVY+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElW PjxCUj48L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Zm9yY2VzIG1haWxpbmcgDQogIGxpc3Q8 QlI+Zm9yY2VzQGlldGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZm9yY2VzPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_005E_01CE7512.12C3B540--