From nobody Tue Jun 3 12:23:39 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F1C1A0320 for ; Tue, 3 Jun 2014 12:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XORwqPVF7km for ; Tue, 3 Jun 2014 12:23:35 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B051A026B for ; Tue, 3 Jun 2014 12:23:35 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s53JNSUf015671 for ; Tue, 3 Jun 2014 20:23:28 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s53JNRWf015663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Jun 2014 20:23:27 +0100 From: "Adrian Farrel" To: References: <15721.1401823067@sandelman.ca> In-Reply-To: <15721.1401823067@sandelman.ca> Subject: FW: second call: NomCom 2014-2015 Call for Volunteers Date: Tue, 3 Jun 2014 20:23:24 +0100 Message-ID: <04dc01cf7f61$4a7fabb0$df7f0310$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHk3x2KODOuCIzWcHoPTHdonZa505s1BCYg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20736.001 X-TM-AS-Result: No--27.992-10.0-31-10 X-imss-scan-details: No--27.992-10.0-31-10 X-TMASE-MatchedRID: 6zqlqVGD/+DPx+OSsubji7xygpRxo469qUtSHIEdjlXjsTquy0JRi3/2 0wqGUabSTWLw2jvbfpw1hgVNDSx/9+yt+a9Mtf+eF6z9HGHKwNspmgrUX87USXaMP8m6qk6SDxu hWpfXGhqocrQRMEFXMq82Pm6gWnZrw+UO3+8MnsTY5KPiokD1BhE2nvEP7i9RkhTgBcQdEWtN71 RaMf3zkj8F1rw8NOrAod4zp/34eGzHgweLox1o/5F+9R8v7nzmr4ukWaaTegACvK/jKRSou2crC dgS5o+Ys2Zrgu0iHY7frd9voQGBySVVqpNDZY1cWBc1kxSpeD/BErlOTfHjClS+oHmj8upzczIC 5DwuxPqecv7twlbCQBvV/pwEL+kU1unGEoSN1fyvPooS+PUQcjA5mGjf3tJW3HILHPjV3vA/inO WyAltIRhGt9tZS5sxB/QlF+bx6wKg5EpxGUA5hNUFhgTP7/bWXgqwd9ijktC4+d+598xky2e2f3 x8eE2/dF0nk2YTKpI8EIkIhSbZV7MywGOaB4QQcL5DSHn5oLf5g6DrTJ7eNQmN4Q0YdwriT8LsL XQkTu8n706osjo8ZoHrUr+2GUQ1s2OC3yBBfROdVNZaI2n6/ywB2jqVCX61OtdgzNULC0oH8GY3 mMuKeaPftsbFhPfsfSqFfj+YGGode3ZRBeYWm0rHeoSQjqUcQBnqdxuJ5SBZDPOr282WY3m8t2i fVKz34Y830BJRtfSAMuqetGVetjfO5GuBbEYY/sToY2qzpx6x5amWK2anSPoLR4+zsDTtAqYBE3 k9Mpw= Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/zrf7xmK8bQ_VbKxQ6RyzCjjdsXQ X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 19:23:38 -0000 Please consider volunteering for NomCom, it is an essential part of what makes the IETF work. Thanks, Adrian > -----Original Message----- > From: WGChairs [mailto:wgchairs-bounces@ietf.org] On Behalf Of Michael > Richardson > Sent: 03 June 2014 20:18 > To: ietf@ietf.org; WG Chairs > Subject: second call: NomCom 2014-2015 Call for Volunteers > > > The IETF nominating committee (nomcom) process for 2014-15 has begun. The > IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, > and the IESG (including IETF Chair). > > This is the second call for volunteers. (and you may have seen it more than > once) > > If your name is on the below, then you have volunteered and are qualified. > If you have heard from me, but are not on the list, then there is some > problem, and you should have gotten a query from me to determine your > eligibility. > If you have volunteered and not heard from him, then please resend; > it got lost. > > Ten voting members for the nomcom are selected in a verifiably random > way from a pool of volunteers. The more volunteers, the better chance we have > of choosing a random yet representative cross section of the IETF population. > > Let's break the 200 volunteer mark again this year! > We are at 54 volunteers so far. > > The details of the operation of the nomcom can be found in RFC 3777, > and BCP10/RFC3797 details the selection algorithm. > > Volunteers must have attended 3 of the past 5 IETF meetings. As specified in > RFC 3777, that means three out of the five past meetings up to the time this > email announcement goes out to start the solicitation of volunteers. > The five meetings out of which you must have attended *three* > are IETF 85(Atlanta), \ > 86(Orlando), \ > 87(Berlin), *** ANY THREE! > 88(Vancouver), / > 89(London) / > > If you qualify, please volunteer. However, much as we want this, before you > decide to volunteer, please be sure you are willing to forgo appointment > to any of the positions for which this nomcom is responsible. > > The list of people and posts whose terms end with the March 2015 IETF > meeting, and thus the positions for which this nomcom is responsible, are > > IAOC: > To be confirmed > > IAB: > Joel Halpern > Russ Housley > Eliot Lear > Xing Li > Andrew Sullivan > Dave Thaler > > IESG: > Pete Resnick (Applications) > Ted Lemon (Internet) > Joel Jaeggli (Operations and Management) > Richard Barnes (RAI) > Adrian Farrel* (Routing) > Stephen Farrell (Security) > Spencer Dawkins (Transport) > Jari Arkko (Gen) > > (names with * have publically indicated they will not serve another term) > > The primary activity for this nomcom will begin in July 2014 and should be > completed in January 2015. The nomcom will have regularly scheduled > conference calls to ensure progress. (We might dogfood WebRTC) > There will be activities to collect requirements from the community, review > candidate questionnaires, review feedback from community members about > candidates, and talk to candidates. > > Thus, being a nomcom member does require some time commitment; but it is > also > a very rewarding experience. > > It is very important that you be able to attend IETF91 to conduct interviews. > Being at IETF90 is useful for training. Being at IETF92 is not essential. > > Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) > June 22, 2013, as follows: > > To: nomcom-chair-2014@ietf.org > Subject: Nomcom 2014-15 Volunteer > > Please include the following information in the email body: > > Your Full Name: __________-- > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form > Emails: _______________ > [] > > Telephone: _______________________ > // For confirmation if selected > > You should expect an email response from me within 3 business days stating > whether or not you are qualified. If you don't receive this response, > please re-send your email with the tag "RESEND"" added to the subject line. > > If you are not yet sure if you would like to volunteer, please consider > that nomcom members play a very important role in shaping the leadership > of the IETF. Questions by email or voice are welcome. > Volunteering for the nomcom is a great way to contribute to the IETF! > > You can find a detailed timeline on the nomcom web site at: > https://datatracker.ietf.org/nomcom/2014/ > > I will be publishing a more detailed target timetable, as well as details > of the randomness seeds to be used for the RFC 3797 selection process, > within the next couple weeks. > > Thank you! > Michael Richardson > mcr+nomcom@sandelman.ca > nomcom-chair-2014@ietf.org > > ===== qualified volunteers so far, in alphabetical order by first name > ANM Zaheduzzaman Sarker > Adam Montville > Bill VerSteeg > Carl Williams > Carlos Martinez > Charles Eckel > DHRUV DHODY > Dacheng Zhang > Dapeng Liu > Donald Eastlake > Eric VYNCKE > Fernando Gont > Fred Baker > Gonzalo Salgueiro > Hongyu Li > Hosnieh Rafiee > Hugo Salgado > John E Drake > John Levine > John Scudder > Linda Dunbar > Lingli Deng > Louis (Lou) Berger > Luca Martini > Lucy Yong > Mach Chen > Mark Townsley > Matt Lepinski > Mehmet Ersue > Melinda Shore > Min Ye > Ning Zong > Ole Troan > Pascal Thubert > Paul Hoffman > Peter Yee > Ralph Droms > Ron Bonica > Ross Callon > Ross Finlayson > Sam K. Aldrin > Sanjay Mishra > Sheng JIANG > Shucheng Liu > Stephan Friedl > Stephan Wenger > Stephen Kent > Suhas Nandakumar > Tim Wicinski > Tissa Senevirathne > Toerless Eckert > Wassim Haddad > Xiaohu XU > Yuanlong Jiang > > > > > > > > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > From nobody Tue Jun 10 02:09:08 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998301A0263 for ; Mon, 9 Jun 2014 15:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCu3uz8gWPJK for ; Mon, 9 Jun 2014 15:42:32 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735F11A003B for ; Mon, 9 Jun 2014 15:42:32 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:50499 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1Wu8Gn-00058i-Fo for routing-discussion@ietf.org; Mon, 09 Jun 2014 22:42:25 +0000 From: "Russ White" To: Subject: RSS Feed for Routing Area Wiki/Routing Area Directorate Wiki? Date: Mon, 9 Jun 2014 18:42:18 -0400 Message-ID: <007701cf8434$11f52cc0$35df8640$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac+EMti1fZfezx/FSmS/DxoooyZHjA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/rpPp0EE2louhqZHhuWZxxnWhXRw X-Mailman-Approved-At: Tue, 10 Jun 2014 02:09:07 -0700 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2014 22:42:33 -0000 Y'all: It looks like trac wiki has the capability to provide an rss feed, but it's not turned on for any of the ietf wiki sites... It would be really nice to have a wiki rss feed for the routing area directorate page -- does anyone know how to turn it on, or if there's a magic url I'm missing, or maybe I'm just blind and can't see the orange button the docs say should be at the bottom of the page... or... ?? :-) Russ From nobody Tue Jun 10 02:12:37 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0781A0354 for ; Tue, 10 Jun 2014 02:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pb9px2GQbma for ; Tue, 10 Jun 2014 02:12:31 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500DB1A044D for ; Tue, 10 Jun 2014 02:12:30 -0700 (PDT) X-TM-IMSS-Message-ID: <383dc90200071e03@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 383dc90200071e03 ; Tue, 10 Jun 2014 14:44:10 +0530 Received: from BLRKECHUB10.ad.infosys.com (10.66.236.120) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 Jun 2014 14:42:16 +0530 Received: from USAPLAHCS03.ad.infosys.com (10.156.249.7) by blrkechub10.ad.infosys.com (10.66.236.120) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 10 Jun 2014 14:41:55 +0530 Received: from USAPLAMBX12.ad.infosys.com ([fe80::d53c:d696:3e94:38c9]) by USAPLAHCS03.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Tue, 10 Jun 2014 04:10:45 -0500 From: VENKATG To: "routing-discussion@ietf.org" Subject: unsubscribe Thread-Topic: unsubscribe Thread-Index: Ac+Ei9jpcItVHB8dRzGhDJDWdHcILg== Importance: high X-Priority: 1 Date: Tue, 10 Jun 2014 09:10:44 +0000 Message-ID: <1C931B54216C1A47A0DFDA81AF4580DF010ADC9B6F@USAPLAMBX12.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.158.80.141] Content-Type: multipart/alternative; boundary="_000_1C931B54216C1A47A0DFDA81AF4580DF010ADC9B6FUSAPLAMBX12ad_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/9Do6LZrf9ygxolkdPgvfe6KRNAw X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 09:12:36 -0000 --_000_1C931B54216C1A47A0DFDA81AF4580DF010ADC9B6FUSAPLAMBX12ad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** --_000_1C931B54216C1A47A0DFDA81AF4580DF010ADC9B6FUSAPLAMBX12ad_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

unsubscribe

= 
*************=
*** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol=
ely 
for the use of the addressee(s). If you are not the intended recipient, p=
lease 
notify the sender by e-mail and delete the original message. Further, you=
 are not 
to copy, disclose, or distribute this e-mail or its contents to any other=
 person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys h=
as taken 
every reasonable precaution to minimize this risk, but is not liable for =
any damage 
you may sustain as a result of any virus in this e-mail. You should carry=
 out your 
own virus checks before opening the e-mail or attachment. Infosys reserve=
s the 
right to monitor and review the content of all messages sent to or from t=
his e-mail 
address. Messages sent to or from this e-mail address may be stored on th=
e 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
--_000_1C931B54216C1A47A0DFDA81AF4580DF010ADC9B6FUSAPLAMBX12ad_-- From nobody Tue Jun 10 12:58:02 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467CA1A02BC for ; Tue, 10 Jun 2014 12:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr68zY6y4xk9 for ; Tue, 10 Jun 2014 12:57:46 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329EC1A0284 for ; Tue, 10 Jun 2014 12:57:46 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 79so4027624ykr.17 for ; Tue, 10 Jun 2014 12:57:45 -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:content-type; bh=X63gSALywdjQu8LSMFgl5zAaRUh7f5UliQYdW0IpFoI=; b=mjgQaw7x38Z+vC6sxJ7CNmMze+8mg9BrjGGgJeFDfboJqQkVYIM1yPYzFpp3GqjhvM Mkndz5LQmtR91JGGPnc10x35cKmfB/Qr0+8ZsdfJbDzWjjd0m7x8kE74FJgdlan/Xq5i mxYtxP9F5fUvbautD6v+iB5bHSdpZd7E0pDOtpdRxkLIBxiY+P7Ivw1+JRre+r0JpMZ9 l6Fdy2WvoS0hiy/Ql4KG1RZbg7c1kHdYC/r/E77TOp0L9+dfU3LDLgggCsgsaD9JApr/ +5kSCokIb8TqqY8UmKt3sS7Gi6Eif34aleFtrnNQvrc/PGTiXfimJSCreYtQLLJPSblI w6Rw== MIME-Version: 1.0 X-Received: by 10.236.39.103 with SMTP id c67mr4670658yhb.139.1402430265611; Tue, 10 Jun 2014 12:57:45 -0700 (PDT) Received: by 10.170.194.2 with HTTP; Tue, 10 Jun 2014 12:57:45 -0700 (PDT) Date: Tue, 10 Jun 2014 15:57:45 -0400 Message-ID: Subject: Improving and Restructuring the Routing Area From: Alia Atlas To: routing-discussion@ietf.org Content-Type: multipart/alternative; boundary=001a1137f2f8cdda1304fb80bdd2 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/F5Y9AtbIHeQjAT90UeHhn927QC0 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 19:57:48 -0000 --001a1137f2f8cdda1304fb80bdd2 Content-Type: text/plain; charset=UTF-8 To all participants in the Routing Area, Adrian and I are working on improving the quality, speed, and experience of getting work done in the IETF Routing Area. There are three initiatives that we are working: WG Draft QA, Routing Area specific WG chair training, and reorganizing the working groups in the area. First, we intend to use our Routing Directorate more proactively by introducing a Working Group Draft Quality Assurance (WG Draft QA) process where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call. The process will be documented on the Routing Area wiki (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow directorate reviews to report technical issues that can actually get fixed early in the process (equivalent of bug reports) as opposed to just noting the concerns in the drafts (equivalent of release notes). Second, as was discussed during the recent IESG retreat, in addition to the IETF-wide WG chair training, we intend to have a series of training sessions for WG Chairs in the Routing Area addressing topics such as judging consensus, project management, motivating volunteers, using the datatracker (via a sandbox version that can be played with safely), and sharing experiences between WG chairs. Third, we intend to reorganize the working groups in the Routing area. We feel that it is important to focus on areas where there is active interest in standardization and to be open and able to accept new work into the area. As you know, we have had several new working groups (nvo3, i2rs, sfc, spring) created in the last few years and we need to be open and able to handle more new work as it comes in. We would also like to improve the signal-to-noise ratio experienced by participants in the different working groups and improve the quantity and quality of discussion and reviews. It is likely that not all WGs in the Routing Area will be directly affected. Here is the time-line for reorganizing the WGs. NOW: public discussion on routing-discussion@ietf.org about how to reorganize the working groups to best meet our motivations. Additional focused discussions are expected on the rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. In Toronto: There will be meetings with the WG chairs and the Routing Directorate to get the ideas described and agreed upon. At the Routing Area Meeting in Toronto: Discuss the set of reorganized WGs and general charter content in the Routing Area meeting. September 2014: Based upon the feedback, suggestions, and discussion, Adrian and I finalize the reorganized WG charters. We start the internal IESG discussion and public reviews. October 2014: Formal rechartering process completes. In Honolulu: The new set of WGs meet. After Honolulu: Adrian and I deal with any issues and charter updates based upon a few months of experience. Here are the motivations that Adrian and I would like to be considered when coming up with ideas for how the WGs should be reorganized. 1) Move towards organizing working groups on functional responsibilities rather than scoping them to specific protocols. 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. 3) Create synergies for scattered functionality (example ideas: OAM, FRR, traffic-engineering) 4) Create a DISPATCH working group for clear new idea discussion; rtgwg serves some of this purpose but doesn't have a clear process and isn't drawing in the new ideas. 5) Focus Routing Area time on design centers rather than on far corner cases. 6) Each working group should have clear, well defined, and achievable goals. Noting that the Routing Area has inherited some of its WG structure from the sub-IP area, it is not a goal to force IP routing and MPLS routing to remain separated. The goal of this reorganization is not closing working groups. Adrian and Alia are perfectly capable of closing working groups without going through restructuring. For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion. Thanks, Alia and Adrian --001a1137f2f8cdda1304fb80bdd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To all participants in the Routing Area,
Adrian and I are working on improving the quality, speed, and<= /div>
experience of getting work done in the IETF Routing Area. =C2=A0T= here are
three initiatives that we are working: WG Draft QA, Routing Area
=
specific WG chair training, and reorganizing the working groups in the=
area.

First, we intend to use our Routi= ng Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft QA)
process where the same selected routing directorate member will revie= w
a draft during WG draft adoption and during WG last call. =C2= =A0The process
will be documented on the Routing Area wiki
directorate reviews t= o report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release note= s).

Second, as was discussed during the recent IES= G retreat, in addition
to the IETF-wide WG chair training, we intend to have a series of
training sessions for WG Chairs in the Routing Area addressing topics=
such as judging consensus, project management, motivating volunt= eers,
using the datatracker (via a sandbox version that can be played
<= div>with safely), and sharing experiences between WG chairs.

=
Third, we intend to reorganize the working groups in the Routing= area.
We feel that it is important to focus on areas where there is active
interest in standardization and to be open and able to accept new = work
into the area. =C2=A0As you know, we have had several new wo= rking groups
(nvo3, i2rs, sfc, spring) created in the last few years and we need to=
be open and able to handle more new work as it comes in. =C2=A0W= e would
also like to improve the signal-to-noise ratio experience= d by
participants in the different working groups and improve the quantity<= /div>
and quality of discussion and reviews. =C2=A0It is likely that no= t all WGs
in the Routing Area will be directly affected.

Here is the time-line for reorganizing the WGs.
=C2=A0 =C2=A0NOW: public discussion on routing-discussion@ietf.org about how to
<= div>=C2=A0 =C2=A0reorganize the working groups to best meet our motivations= .
=C2=A0 =C2=A0Additional focused discussions are expected on the
<= div>=C2=A0 =C2=A0rtg-chairs@ietf.org= and rtg-dir@ietf.org mailing l= ists.

=C2=A0 =C2=A0In Toronto: There will be meetings with the WG chai= rs and the
=C2=A0 =C2=A0Routing Directorate to get the ideas desc= ribed and agreed upon.

=C2=A0 =C2=A0At the Routing= Area Meeting in Toronto: Discuss the set of
=C2=A0 =C2=A0reorganized WGs and general charter content in the Routin= g Area
=C2=A0 =C2=A0meeting.

=C2=A0 =C2= =A0September 2014: Based upon the feedback, suggestions, and
=C2= =A0 =C2=A0discussion, Adrian and I finalize the reorganized WG charters. = =C2=A0We
=C2=A0 =C2=A0start the internal IESG discussion and public reviews.

=C2=A0 =C2=A0October 2014: Formal rechartering proce= ss completes.

=C2=A0 =C2=A0In Honolulu: The new se= t of WGs meet.

=C2=A0 =C2=A0After Honolulu: Adrian and I deal with any issues a= nd charter
=C2=A0 =C2=A0updates based upon a few months of experi= ence.

Here are the motivations that Adrian and I w= ould like to be considered
when coming up with ideas for how the WGs should be reorganized.
=

=C2=A0 =C2=A01) Move towards organizing working groups = on functional
=C2=A0 =C2=A0responsibilities rather than scoping t= hem to specific protocols.

=C2=A0 =C2=A02) Split giant working groups so relevant = work is done in one place
=C2=A0 =C2=A0and there is an improved s= ignal-to-noise ratio for participants who
=C2=A0 =C2=A0are only i= nterested in a slice of the current working group's work.

=C2=A0 =C2=A03) Create synergies for scattered function= ality (example ideas:
=C2=A0 =C2=A0OAM, FRR, traffic-engineering)=

=C2=A0 =C2=A04) Create a DISPATCH working group f= or clear new idea discussion;
=C2=A0 =C2=A0rtgwg serves some of this purpose but doesn't have a = clear process
=C2=A0 =C2=A0and isn't drawing in the new ideas= .

=C2=A0 =C2=A05) Focus Routing Area time on desig= n centers rather than on far
=C2=A0 =C2=A0corner cases.

=C2=A0 =C2=A06) Ea= ch working group should have clear, well defined, and achievable goals.

Noting that the Routing Area has inherited some of it= s WG structure
from the sub-IP area, it is not a goal to force IP routing and MPLS
routing to remain separated.

The goal of t= his reorganization is not closing working groups. =C2=A0Adrian
an= d Alia are perfectly capable of closing working groups without going
through restructuring.

For those of you that = have read this far, thank you. =C2=A0Getting this 80%
right is go= ing to take some serious discussion and thought. =C2=A0We all
wor= k in the Routing Area together with different perspectives. =C2=A0Please
think carefully and help us have a highly focused discussion.

Thanks,
Alia and Adrian

--001a1137f2f8cdda1304fb80bdd2-- From nobody Tue Jun 10 14:10:47 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF91A02E5 for ; Tue, 10 Jun 2014 14:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuLR3okpIMMy for ; Tue, 10 Jun 2014 14:01:20 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947CB1A02E3 for ; Tue, 10 Jun 2014 14:01:20 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s5AKsqYq023045 for ; Tue, 10 Jun 2014 17:01:19 -0400 Received: from mdwvexchht01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 1mdemmm5mm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Jun 2014 17:01:19 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 10 Jun 2014 17:01:18 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Tue, 10 Jun 2014 17:01:06 -0400 From: "Shah, Himanshu" To: "routing-discussion@ietf.org" Date: Tue, 10 Jun 2014 17:01:05 -0400 Subject: subscribe Thread-Topic: subscribe Thread-Index: Ac+E7xgqolA/Q9BTSiWyc/oGPHuW9g== Message-ID: <40746B2300A8FC4AB04EE722A593182B72EC6B77@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182B72EC6B77ONWVEXCHMB04cie_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20750.002 X-TM-AS-Result: No--9.411200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-10_06:2014-06-10,2014-06-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406100254 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Kpyd_VLuINRWbwAQJzU6wfga2wk X-Mailman-Approved-At: Tue, 10 Jun 2014 14:10:24 -0700 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:01:22 -0000 --_000_40746B2300A8FC4AB04EE722A593182B72EC6B77ONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_40746B2300A8FC4AB04EE722A593182B72EC6B77ONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

= --_000_40746B2300A8FC4AB04EE722A593182B72EC6B77ONWVEXCHMB04cie_-- From nobody Tue Jun 10 14:32:53 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDC51A02E5 for ; Tue, 10 Jun 2014 14:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30x0w80MWT5h for ; Tue, 10 Jun 2014 14:32:50 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E771A02C6 for ; Tue, 10 Jun 2014 14:32:50 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-67-5397264dfb3a Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 32.BD.11744.D4627935; Tue, 10 Jun 2014 17:37:49 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 17:32:49 -0400 From: Gregory Mirsky To: "routing-discussion@ietf.org" Subject: WG Draft QA Thread-Topic: WG Draft QA Thread-Index: Ac+E8ckkYFaQI77LS52TAFhVxCOK3Q== Date: Tue, 10 Jun 2014 21:32:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7CC9C4@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7CC9C4eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXSPn66v2vRgg+ntmhYnlmxlc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxty5u9gLHshULFq0la2B8ZlEFyMnh4SAicSzLYtYIGwxiQv3 1rOB2EICRxkl3q4X7WLkArKXM0rc3nYPLMEmYCTxYmMPO4gtImAvsebbMmYQW1hARGLltPus EHFJiY0v2qFsPYl9y/4wgtgsAqoSS7d1MYHYvAK+EjNenwbrZQRa/P3UGrA4s4C4xK0n85kg DhKQWLLnPDOELSrx8vE/VghbUWJf/3R2iPp8iVs7ZrJCzBSUODnzCcsERqFZSEbNQlI2C0kZ RFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XIUVqcWpabbmS4iREY+Mck2Bx3MC74ZHmI UYCDUYmHV+H6tGAh1sSy4srcQ4zSHCxK4rx7rlUFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amBkm3LWZlvLh/7+qqp+1gS9qI2vOHb/YnkbclTz7vl2hpUHv3hOtJS/8Wi1qQRTh4msXN6H +b0q+SlTJhaJetiJ3/s14cRiYTv2GhNWp4dPHPwvsx7acH+rYfr15KtKF/dptU/KeGQe8/3h 0u13rlQrCnO+e5D3SfS1oH/P2/ZlVSs9WGZ+nq2vxFKckWioxVxUnAgAEcoSJV0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/8JC1bcCcH9krmWZoE7SsH61KDZ4 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 21:32:52 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7CC9C4eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Alia, Adrian, et. al, I fully support the goal to improve quality of WG documents and commitment = of the Routing directorate to assign its members to review documents at WG = adoption and WG LC. I hope you will consider to compliment these reviews wi= th reviews by designated experts resembling MPLS Review Team (MPLS-RT). Rev= iews by WG RTs may be especially helpful as work on some documents may be q= uite lengthy time consuming process and it may be challenging to ensure tha= t the RD reviewer at WG adoption call can do review at time of WG LC. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B7CC9C4eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Alia, Adrian, et. al,

I fully support the goal to improve quality of WG do= cuments and commitment of the Routing directorate to assign its members to = review documents at WG adoption and WG LC. I hope you will consider to comp= liment these reviews with reviews by designated experts resembling MPLS Review Team (MPLS-RT). Reviews by WG= RTs may be especially helpful as work on some documents may be quite lengt= hy time consuming process and it may be challenging to ensure that the RD r= eviewer at WG adoption call can do review at time of WG LC.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B7CC9C4eusaamb103erics_-- From nobody Tue Jun 10 15:09:01 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD211A020E for ; Tue, 10 Jun 2014 15:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrOs3N0CSUvI for ; Tue, 10 Jun 2014 15:08:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D894C1A0314 for ; Tue, 10 Jun 2014 15:08:51 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 10 Jun 2014 22:08:49 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Tue, 10 Jun 2014 22:08:49 +0000 From: Ross Callon To: Alia Atlas , "routing-discussion@ietf.org" Subject: RE: Improving and Restructuring the Routing Area Thread-Topic: Improving and Restructuring the Routing Area Thread-Index: AQHPhOZLafoij3+aqkKhXgVuYb6Fv5tq4+dA Date: Tue, 10 Jun 2014 22:08:48 +0000 Message-ID: <027a8e31cf2e47e0bbfabc23a7507e16@CO2PR05MB636.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(164054003)(51444003)(199002)(377454003)(189002)(19609705001)(99396002)(92566001)(46102001)(66066001)(83322001)(4396001)(2656002)(80022001)(33646001)(101416001)(18717965001)(99286001)(74316001)(74662001)(76576001)(21056001)(74502001)(15975445006)(19300405004)(77982001)(85852003)(50986999)(64706001)(19580405001)(83072002)(87936001)(79102001)(76176999)(20776003)(76482001)(54356999)(16236675004)(31966008)(86362001)(19580395003)(15202345003)(81342001)(77096999)(19625215002)(81542001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: multipart/alternative; boundary="_000_027a8e31cf2e47e0bbfabc23a7507e16CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/dLT0nbc1cEX-AnhHoIchgw8W9HA X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 22:08:58 -0000 --_000_027a8e31cf2e47e0bbfabc23a7507e16CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHRoZXJlIGlzIHF1aXRlIGEgYml0IG9mIGNvbnRlbnQgaW4gdGhpcyBlbWFp bCwgYW5kIHRoYXQgd2UgbWlnaHQgbmVlZCB0byBlbmQgdXAgd2l0aCBzZXZlcmFsIHRocmVhZHMg LS0gc3VjaCBhcyBvbmUgZm9yIHJvdXRpbmcgZGlyZWN0b3JhdGUgY2hhbmdlcywgb25lIGZvciBX RyBjaGFpciB0cmFpbmluZywgYW5kIG9uZSBmb3IgV0cgcmVvcmdhbml6YXRpb24uDQoNClNwZWFr aW5nIGZvciB0aGUgbGF0dGVyIOKAkyBXRyByZW9yZ2FuaXphdGlvbiwgYW5kIHNwZWNpZmljYWxs eSBvbiBkZWFsaW5nIHdpdGggdmVyeSBsYXJnZSBXR3M6IEkgdGhpbmsgdGhhdCB0aGVyZSBpcyBh IHRyYWRlb2ZmIGhlcmUuIFZlcnkgbGFyZ2UgV0dzIGNhbiBiZSBjdW1iZXJzb21lIGFuZCBtaWdo dCBub3QgYmUgYXMg4oCcZm9jdXNlZOKAnSBhcyBzbWFsbGVyIGdyb3Vwcy4gSG93ZXZlciwgaXQg aXMgbXVjaCBlYXNpZXIgb3IgbW9yZSBsaWtlbHkgZm9yIHdvcmsgdG8gZGl2ZXJnZSB3aGVuIGl0 IGlzIHNwbGl0IGludG8gbXVsdGlwbGUgZ3JvdXBzLg0KDQpBcyBvbmUgZXhhbXBsZSwgb25lIG9i dmlvdXNseSBsYXJnZSBncm91cCBpcyBNUExTLiBMb29raW5nIGF0IHRoZSB3b3JrIGdvaW5nIG9u IGluIE1QTFMsIG9uZSBwb3NzaWJsZSB3YXkgdG8gc3BsaXQgaXQgdXAgd291bGQgYmUgdG8gc3Bs aXQgb2ZmIHRoZSBPQU0gd29yay4gSG93ZXZlciwgaG93IHRvIG1hbmFnZSBhIHByb3RvY29sIGlz IHZlcnkgbXVjaCB0aWVkIGludG8gb3RoZXIgYXNwZWN0cyBvZiB0aGUgb3BlcmF0aW9uIG9mIHRo ZSBwcm90b2NvbC4gSWYgcGVvcGxlIHdvcmtpbmcgb24gb25lIGFzcGVjdCBvZiBhIHByb3RvY29s IGFyZSBib3JlZCBsaXN0ZW5pbmcgdG8gT0FNIGRpc2N1c3Npb25zLCBpdCBtaWdodCBub25ldGhl bGVzcyBiZSBhIGdvb2QgaWRlYSBmb3IgdGhlbSB0byBsaXN0ZW4gdG8gT0FNIGRpc2N1c3Npb25z Lg0KDQpEbyB3ZSB3YW50IHRvIGdldCBpbnRvIGRpc2N1c3NpbmcgZGV0YWlscyBwZXJ0aW5lbnQg dG8gc3BlY2lmaWMgV0dzPw0KDQpUaGFua3MsIFJvc3MNCg0KRnJvbTogcm91dGluZy1kaXNjdXNz aW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbGlhIEF0bGFzDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDM6NTggUE0NClRv OiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmcNClN1YmplY3Q6IEltcHJvdmluZyBhbmQgUmVz dHJ1Y3R1cmluZyB0aGUgUm91dGluZyBBcmVhDQoNClRvIGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhl IFJvdXRpbmcgQXJlYSwNCg0KQWRyaWFuIGFuZCBJIGFyZSB3b3JraW5nIG9uIGltcHJvdmluZyB0 aGUgcXVhbGl0eSwgc3BlZWQsIGFuZA0KZXhwZXJpZW5jZSBvZiBnZXR0aW5nIHdvcmsgZG9uZSBp biB0aGUgSUVURiBSb3V0aW5nIEFyZWEuICBUaGVyZSBhcmUNCnRocmVlIGluaXRpYXRpdmVzIHRo YXQgd2UgYXJlIHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWENCnNwZWNpZmljIFdH IGNoYWlyIHRyYWluaW5nLCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3JraW5nIGdyb3VwcyBpbiB0 aGUNCmFyZWEuDQoNCkZpcnN0LCB3ZSBpbnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9y YXRlIG1vcmUgcHJvYWN0aXZlbHkgYnkNCmludHJvZHVjaW5nIGEgV29ya2luZyBHcm91cCBEcmFm dCBRdWFsaXR5IEFzc3VyYW5jZSAoV0cgRHJhZnQgUUEpDQpwcm9jZXNzIHdoZXJlIHRoZSBzYW1l IHNlbGVjdGVkIHJvdXRpbmcgZGlyZWN0b3JhdGUgbWVtYmVyIHdpbGwgcmV2aWV3DQphIGRyYWZ0 IGR1cmluZyBXRyBkcmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3QgY2FsbC4gIFRoZSBw cm9jZXNzDQp3aWxsIGJlIGRvY3VtZW50ZWQgb24gdGhlIFJvdXRpbmcgQXJlYSB3aWtpDQooaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpKS4gIFRoaXMgc2hvdWxk IGFsbG93DQpkaXJlY3RvcmF0ZSByZXZpZXdzIHRvIHJlcG9ydCB0ZWNobmljYWwgaXNzdWVzIHRo YXQgY2FuIGFjdHVhbGx5IGdldA0KZml4ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxl bnQgb2YgYnVnIHJlcG9ydHMpIGFzIG9wcG9zZWQgdG8NCmp1c3Qgbm90aW5nIHRoZSBjb25jZXJu cyBpbiB0aGUgZHJhZnRzIChlcXVpdmFsZW50IG9mIHJlbGVhc2Ugbm90ZXMpLg0KDQpTZWNvbmQs IGFzIHdhcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSByZWNlbnQgSUVTRyByZXRyZWF0LCBpbiBhZGRp dGlvbg0KdG8gdGhlIElFVEYtd2lkZSBXRyBjaGFpciB0cmFpbmluZywgd2UgaW50ZW5kIHRvIGhh dmUgYSBzZXJpZXMgb2YNCnRyYWluaW5nIHNlc3Npb25zIGZvciBXRyBDaGFpcnMgaW4gdGhlIFJv dXRpbmcgQXJlYSBhZGRyZXNzaW5nIHRvcGljcw0Kc3VjaCBhcyBqdWRnaW5nIGNvbnNlbnN1cywg cHJvamVjdCBtYW5hZ2VtZW50LCBtb3RpdmF0aW5nIHZvbHVudGVlcnMsDQp1c2luZyB0aGUgZGF0 YXRyYWNrZXIgKHZpYSBhIHNhbmRib3ggdmVyc2lvbiB0aGF0IGNhbiBiZSBwbGF5ZWQNCndpdGgg c2FmZWx5KSwgYW5kIHNoYXJpbmcgZXhwZXJpZW5jZXMgYmV0d2VlbiBXRyBjaGFpcnMuDQoNClRo aXJkLCB3ZSBpbnRlbmQgdG8gcmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMgaW4gdGhlIFJv dXRpbmcgYXJlYS4NCldlIGZlZWwgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZm9jdXMgb24gYXJl YXMgd2hlcmUgdGhlcmUgaXMgYWN0aXZlDQppbnRlcmVzdCBpbiBzdGFuZGFyZGl6YXRpb24gYW5k IHRvIGJlIG9wZW4gYW5kIGFibGUgdG8gYWNjZXB0IG5ldyB3b3JrDQppbnRvIHRoZSBhcmVhLiAg QXMgeW91IGtub3csIHdlIGhhdmUgaGFkIHNldmVyYWwgbmV3IHdvcmtpbmcgZ3JvdXBzDQoobnZv MywgaTJycywgc2ZjLCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhlIGxhc3QgZmV3IHllYXJzIGFuZCB3 ZSBuZWVkIHRvDQpiZSBvcGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3JlIG5ldyB3b3JrIGFzIGl0 IGNvbWVzIGluLiAgV2Ugd291bGQNCmFsc28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWduYWwtdG8t bm9pc2UgcmF0aW8gZXhwZXJpZW5jZWQgYnkNCnBhcnRpY2lwYW50cyBpbiB0aGUgZGlmZmVyZW50 IHdvcmtpbmcgZ3JvdXBzIGFuZCBpbXByb3ZlIHRoZSBxdWFudGl0eQ0KYW5kIHF1YWxpdHkgb2Yg ZGlzY3Vzc2lvbiBhbmQgcmV2aWV3cy4gIEl0IGlzIGxpa2VseSB0aGF0IG5vdCBhbGwgV0dzDQpp biB0aGUgUm91dGluZyBBcmVhIHdpbGwgYmUgZGlyZWN0bHkgYWZmZWN0ZWQuDQoNCkhlcmUgaXMg dGhlIHRpbWUtbGluZSBmb3IgcmVvcmdhbml6aW5nIHRoZSBXR3MuDQoNCiAgIE5PVzogcHVibGlj IGRpc2N1c3Npb24gb24gcm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPG1haWx0bzpyb3V0aW5n LWRpc2N1c3Npb25AaWV0Zi5vcmc+IGFib3V0IGhvdyB0bw0KICAgcmVvcmdhbml6ZSB0aGUgd29y a2luZyBncm91cHMgdG8gYmVzdCBtZWV0IG91ciBtb3RpdmF0aW9ucy4NCiAgIEFkZGl0aW9uYWwg Zm9jdXNlZCBkaXNjdXNzaW9ucyBhcmUgZXhwZWN0ZWQgb24gdGhlDQogICBydGctY2hhaXJzQGll dGYub3JnPG1haWx0bzpydGctY2hhaXJzQGlldGYub3JnPiBhbmQgcnRnLWRpckBpZXRmLm9yZzxt YWlsdG86cnRnLWRpckBpZXRmLm9yZz4gbWFpbGluZyBsaXN0cy4NCg0KICAgSW4gVG9yb250bzog VGhlcmUgd2lsbCBiZSBtZWV0aW5ncyB3aXRoIHRoZSBXRyBjaGFpcnMgYW5kIHRoZQ0KICAgUm91 dGluZyBEaXJlY3RvcmF0ZSB0byBnZXQgdGhlIGlkZWFzIGRlc2NyaWJlZCBhbmQgYWdyZWVkIHVw b24uDQoNCiAgIEF0IHRoZSBSb3V0aW5nIEFyZWEgTWVldGluZyBpbiBUb3JvbnRvOiBEaXNjdXNz IHRoZSBzZXQgb2YNCiAgIHJlb3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBjaGFydGVyIGNvbnRl bnQgaW4gdGhlIFJvdXRpbmcgQXJlYQ0KICAgbWVldGluZy4NCg0KICAgU2VwdGVtYmVyIDIwMTQ6 IEJhc2VkIHVwb24gdGhlIGZlZWRiYWNrLCBzdWdnZXN0aW9ucywgYW5kDQogICBkaXNjdXNzaW9u LCBBZHJpYW4gYW5kIEkgZmluYWxpemUgdGhlIHJlb3JnYW5pemVkIFdHIGNoYXJ0ZXJzLiAgV2UN CiAgIHN0YXJ0IHRoZSBpbnRlcm5hbCBJRVNHIGRpc2N1c3Npb24gYW5kIHB1YmxpYyByZXZpZXdz Lg0KDQogICBPY3RvYmVyIDIwMTQ6IEZvcm1hbCByZWNoYXJ0ZXJpbmcgcHJvY2VzcyBjb21wbGV0 ZXMuDQoNCiAgIEluIEhvbm9sdWx1OiBUaGUgbmV3IHNldCBvZiBXR3MgbWVldC4NCg0KICAgQWZ0 ZXIgSG9ub2x1bHU6IEFkcmlhbiBhbmQgSSBkZWFsIHdpdGggYW55IGlzc3VlcyBhbmQgY2hhcnRl cg0KICAgdXBkYXRlcyBiYXNlZCB1cG9uIGEgZmV3IG1vbnRocyBvZiBleHBlcmllbmNlLg0KDQpI ZXJlIGFyZSB0aGUgbW90aXZhdGlvbnMgdGhhdCBBZHJpYW4gYW5kIEkgd291bGQgbGlrZSB0byBi ZSBjb25zaWRlcmVkDQp3aGVuIGNvbWluZyB1cCB3aXRoIGlkZWFzIGZvciBob3cgdGhlIFdHcyBz aG91bGQgYmUgcmVvcmdhbml6ZWQuDQoNCiAgIDEpIE1vdmUgdG93YXJkcyBvcmdhbml6aW5nIHdv cmtpbmcgZ3JvdXBzIG9uIGZ1bmN0aW9uYWwNCiAgIHJlc3BvbnNpYmlsaXRpZXMgcmF0aGVyIHRo YW4gc2NvcGluZyB0aGVtIHRvIHNwZWNpZmljIHByb3RvY29scy4NCg0KICAgMikgU3BsaXQgZ2lh bnQgd29ya2luZyBncm91cHMgc28gcmVsZXZhbnQgd29yayBpcyBkb25lIGluIG9uZSBwbGFjZQ0K ICAgYW5kIHRoZXJlIGlzIGFuIGltcHJvdmVkIHNpZ25hbC10by1ub2lzZSByYXRpbyBmb3IgcGFy dGljaXBhbnRzIHdobw0KICAgYXJlIG9ubHkgaW50ZXJlc3RlZCBpbiBhIHNsaWNlIG9mIHRoZSBj dXJyZW50IHdvcmtpbmcgZ3JvdXAncyB3b3JrLg0KDQogICAzKSBDcmVhdGUgc3luZXJnaWVzIGZv ciBzY2F0dGVyZWQgZnVuY3Rpb25hbGl0eSAoZXhhbXBsZSBpZGVhczoNCiAgIE9BTSwgRlJSLCB0 cmFmZmljLWVuZ2luZWVyaW5nKQ0KDQogICA0KSBDcmVhdGUgYSBESVNQQVRDSCB3b3JraW5nIGdy b3VwIGZvciBjbGVhciBuZXcgaWRlYSBkaXNjdXNzaW9uOw0KICAgcnRnd2cgc2VydmVzIHNvbWUg b2YgdGhpcyBwdXJwb3NlIGJ1dCBkb2Vzbid0IGhhdmUgYSBjbGVhciBwcm9jZXNzDQogICBhbmQg aXNuJ3QgZHJhd2luZyBpbiB0aGUgbmV3IGlkZWFzLg0KDQogICA1KSBGb2N1cyBSb3V0aW5nIEFy ZWEgdGltZSBvbiBkZXNpZ24gY2VudGVycyByYXRoZXIgdGhhbiBvbiBmYXINCiAgIGNvcm5lciBj YXNlcy4NCg0KICAgNikgRWFjaCB3b3JraW5nIGdyb3VwIHNob3VsZCBoYXZlIGNsZWFyLCB3ZWxs IGRlZmluZWQsIGFuZCBhY2hpZXZhYmxlIGdvYWxzLg0KDQpOb3RpbmcgdGhhdCB0aGUgUm91dGlu ZyBBcmVhIGhhcyBpbmhlcml0ZWQgc29tZSBvZiBpdHMgV0cgc3RydWN0dXJlDQpmcm9tIHRoZSBz dWItSVAgYXJlYSwgaXQgaXMgbm90IGEgZ29hbCB0byBmb3JjZSBJUCByb3V0aW5nIGFuZCBNUExT DQpyb3V0aW5nIHRvIHJlbWFpbiBzZXBhcmF0ZWQuDQoNClRoZSBnb2FsIG9mIHRoaXMgcmVvcmdh bml6YXRpb24gaXMgbm90IGNsb3Npbmcgd29ya2luZyBncm91cHMuICBBZHJpYW4NCmFuZCBBbGlh IGFyZSBwZXJmZWN0bHkgY2FwYWJsZSBvZiBjbG9zaW5nIHdvcmtpbmcgZ3JvdXBzIHdpdGhvdXQg Z29pbmcNCnRocm91Z2ggcmVzdHJ1Y3R1cmluZy4NCg0KRm9yIHRob3NlIG9mIHlvdSB0aGF0IGhh dmUgcmVhZCB0aGlzIGZhciwgdGhhbmsgeW91LiAgR2V0dGluZyB0aGlzIDgwJQ0KcmlnaHQgaXMg Z29pbmcgdG8gdGFrZSBzb21lIHNlcmlvdXMgZGlzY3Vzc2lvbiBhbmQgdGhvdWdodC4gIFdlIGFs bA0Kd29yayBpbiB0aGUgUm91dGluZyBBcmVhIHRvZ2V0aGVyIHdpdGggZGlmZmVyZW50IHBlcnNw ZWN0aXZlcy4gIFBsZWFzZQ0KdGhpbmsgY2FyZWZ1bGx5IGFuZCBoZWxwIHVzIGhhdmUgYSBoaWdo bHkgZm9jdXNlZCBkaXNjdXNzaW9uLg0KDQpUaGFua3MsDQpBbGlhIGFuZCBBZHJpYW4NCg0K --_000_027a8e31cf2e47e0bbfabc23a7507e16CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgdGhlcmUgaXMgcXVpdGUgYSBiaXQg b2YgY29udGVudCBpbiB0aGlzIGVtYWlsLCBhbmQgdGhhdCB3ZSBtaWdodCBuZWVkIHRvIGVuZCB1 cCB3aXRoIHNldmVyYWwgdGhyZWFkcyAtLSBzdWNoIGFzIG9uZSBmb3Igcm91dGluZyBkaXJlY3Rv cmF0ZSBjaGFuZ2VzLA0KIG9uZSBmb3IgV0cgY2hhaXIgdHJhaW5pbmcsIGFuZCBvbmUgZm9yIFdH IHJlb3JnYW5pemF0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNwZWFraW5nIGZvciB0aGUgbGF0dGVyIOKAkyBX RyByZW9yZ2FuaXphdGlvbiwgYW5kIHNwZWNpZmljYWxseSBvbiBkZWFsaW5nIHdpdGggdmVyeSBs YXJnZSBXR3M6IEkgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIHRyYWRlb2ZmIGhlcmUuIFZlcnkgbGFy Z2UgV0dzIGNhbiBiZSBjdW1iZXJzb21lDQogYW5kIG1pZ2h0IG5vdCBiZSBhcyDigJxmb2N1c2Vk 4oCdIGFzIHNtYWxsZXIgZ3JvdXBzLiBIb3dldmVyLCBpdCBpcyBtdWNoIGVhc2llciBvciBtb3Jl IGxpa2VseSBmb3Igd29yayB0byBkaXZlcmdlIHdoZW4gaXQgaXMgc3BsaXQgaW50byBtdWx0aXBs ZSBncm91cHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIG9uZSBleGFtcGxlLCBvbmUgb2J2aW91c2x5IGxhcmdl IGdyb3VwIGlzIE1QTFMuIExvb2tpbmcgYXQgdGhlIHdvcmsgZ29pbmcgb24gaW4gTVBMUywgb25l IHBvc3NpYmxlIHdheSB0byBzcGxpdCBpdCB1cCB3b3VsZCBiZSB0byBzcGxpdCBvZmYgdGhlIE9B TSB3b3JrLg0KIEhvd2V2ZXIsIGhvdyB0byBtYW5hZ2UgYSBwcm90b2NvbCBpcyB2ZXJ5IG11Y2gg dGllZCBpbnRvIG90aGVyIGFzcGVjdHMgb2YgdGhlIG9wZXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wu IElmIHBlb3BsZSB3b3JraW5nIG9uIG9uZSBhc3BlY3Qgb2YgYSBwcm90b2NvbCBhcmUgYm9yZWQg bGlzdGVuaW5nIHRvIE9BTSBkaXNjdXNzaW9ucywgaXQgbWlnaHQgbm9uZXRoZWxlc3MgYmUgYSBn b29kIGlkZWEgZm9yIHRoZW0gdG8gbGlzdGVuIHRvIE9BTSBkaXNjdXNzaW9ucy4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RG8gd2Ugd2FudCB0byBnZXQgaW50byBkaXNjdXNzaW5nIGRldGFpbHMgcGVydGluZW50IHRv IHNwZWNpZmljIFdHcz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCBSb3NzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiByb3V0 aW5nLWRpc2N1c3Npb24gW21haWx0bzpyb3V0aW5nLWRpc2N1c3Npb24tYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxpYSBBdGxhczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKdW5lIDEwLCAyMDE0IDM6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IHJvdXRpbmctZGlzY3Vz c2lvbkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBJbXByb3ZpbmcgYW5kIFJlc3RydWN0 dXJpbmcgdGhlIFJvdXRpbmcgQXJlYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRvIGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhlIFJvdXRpbmcgQXJl YSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QWRyaWFuIGFuZCBJIGFyZSB3b3JraW5nIG9uIGltcHJvdmluZyB0aGUgcXVhbGl0eSwgc3BlZWQs IGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ZXhwZXJpZW5jZSBvZiBnZXR0aW5nIHdvcmsgZG9uZSBpbiB0aGUgSUVURiBSb3V0aW5nIEFyZWEu ICZuYnNwO1RoZXJlIGFyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dGhyZWUgaW5pdGlhdGl2ZXMgdGhhdCB3ZSBhcmUgd29ya2luZzogV0cgRHJh ZnQgUUEsIFJvdXRpbmcgQXJlYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+c3BlY2lmaWMgV0cgY2hhaXIgdHJhaW5pbmcsIGFuZCByZW9yZ2FuaXpp bmcgdGhlIHdvcmtpbmcgZ3JvdXBzIGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXJlYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rmlyc3QsIHdlIGludGVuZCB0byB1c2Ugb3VyIFJv dXRpbmcgRGlyZWN0b3JhdGUgbW9yZSBwcm9hY3RpdmVseSBieTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50cm9kdWNpbmcgYSBXb3JraW5nIEdy b3VwIERyYWZ0IFF1YWxpdHkgQXNzdXJhbmNlIChXRyBEcmFmdCBRQSk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByb2Nlc3Mgd2hlcmUgdGhlIHNh bWUgc2VsZWN0ZWQgcm91dGluZyBkaXJlY3RvcmF0ZSBtZW1iZXIgd2lsbCByZXZpZXc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgZHJhZnQgZHVy aW5nIFdHIGRyYWZ0IGFkb3B0aW9uIGFuZCBkdXJpbmcgV0cgbGFzdCBjYWxsLiAmbmJzcDtUaGUg cHJvY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+d2lsbCBiZSBkb2N1bWVudGVkIG9uIHRoZSBSb3V0aW5nIEFyZWEgd2lraTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDxhIGhyZWY9Imh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraSI+aHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpPC9hPikuICZuYnNwO1RoaXMgc2hvdWxkIGFs bG93PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5k aXJlY3RvcmF0ZSByZXZpZXdzIHRvIHJlcG9ydCB0ZWNobmljYWwgaXNzdWVzIHRoYXQgY2FuIGFj dHVhbGx5IGdldDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Zml4ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxlbnQgb2YgYnVnIHJlcG9y dHMpIGFzIG9wcG9zZWQgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmp1c3Qgbm90aW5nIHRoZSBjb25jZXJucyBpbiB0aGUgZHJhZnRzIChlcXVp dmFsZW50IG9mIHJlbGVhc2Ugbm90ZXMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWNvbmQsIGFzIHdhcyBkaXNjdXNzZWQgZHVyaW5nIHRo ZSByZWNlbnQgSUVTRyByZXRyZWF0LCBpbiBhZGRpdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gdGhlIElFVEYtd2lkZSBXRyBjaGFpciB0 cmFpbmluZywgd2UgaW50ZW5kIHRvIGhhdmUgYSBzZXJpZXMgb2Y8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRyYWluaW5nIHNlc3Npb25zIGZvciBX RyBDaGFpcnMgaW4gdGhlIFJvdXRpbmcgQXJlYSBhZGRyZXNzaW5nIHRvcGljczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3VjaCBhcyBqdWRnaW5n IGNvbnNlbnN1cywgcHJvamVjdCBtYW5hZ2VtZW50LCBtb3RpdmF0aW5nIHZvbHVudGVlcnMsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj51c2luZyB0 aGUgZGF0YXRyYWNrZXIgKHZpYSBhIHNhbmRib3ggdmVyc2lvbiB0aGF0IGNhbiBiZSBwbGF5ZWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGgg c2FmZWx5KSwgYW5kIHNoYXJpbmcgZXhwZXJpZW5jZXMgYmV0d2VlbiBXRyBjaGFpcnMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXJkLCB3 ZSBpbnRlbmQgdG8gcmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMgaW4gdGhlIFJvdXRpbmcg YXJlYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldlIGZlZWwgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZm9jdXMgb24gYXJlYXMgd2hlcmUgdGhl cmUgaXMgYWN0aXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5pbnRlcmVzdCBpbiBzdGFuZGFyZGl6YXRpb24gYW5kIHRvIGJlIG9wZW4gYW5kIGFi bGUgdG8gYWNjZXB0IG5ldyB3b3JrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5pbnRvIHRoZSBhcmVhLiAmbmJzcDtBcyB5b3Uga25vdywgd2UgaGF2 ZSBoYWQgc2V2ZXJhbCBuZXcgd29ya2luZyBncm91cHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihudm8zLCBpMnJzLCBzZmMsIHNwcmluZykgY3Jl YXRlZCBpbiB0aGUgbGFzdCBmZXcgeWVhcnMgYW5kIHdlIG5lZWQgdG88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJlIG9wZW4gYW5kIGFibGUgdG8g aGFuZGxlIG1vcmUgbmV3IHdvcmsgYXMgaXQgY29tZXMgaW4uICZuYnNwO1dlIHdvdWxkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbHNvIGxpa2Ug dG8gaW1wcm92ZSB0aGUgc2lnbmFsLXRvLW5vaXNlIHJhdGlvIGV4cGVyaWVuY2VkIGJ5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wYXJ0aWNpcGFu dHMgaW4gdGhlIGRpZmZlcmVudCB3b3JraW5nIGdyb3VwcyBhbmQgaW1wcm92ZSB0aGUgcXVhbnRp dHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFu ZCBxdWFsaXR5IG9mIGRpc2N1c3Npb24gYW5kIHJldmlld3MuICZuYnNwO0l0IGlzIGxpa2VseSB0 aGF0IG5vdCBhbGwgV0dzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5pbiB0aGUgUm91dGluZyBBcmVhIHdpbGwgYmUgZGlyZWN0bHkgYWZmZWN0ZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhl cmUgaXMgdGhlIHRpbWUtbGluZSBmb3IgcmVvcmdhbml6aW5nIHRoZSBXR3MuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtO T1c6IHB1YmxpYyBkaXNjdXNzaW9uIG9uIDxhIGhyZWY9Im1haWx0bzpyb3V0aW5nLWRpc2N1c3Np b25AaWV0Zi5vcmciPg0Kcm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPC9hPiBhYm91dCBob3cg dG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtyZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdyb3VwcyB0byBiZXN0IG1lZXQgb3Vy IG1vdGl2YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwO0FkZGl0aW9uYWwgZm9jdXNlZCBkaXNjdXNzaW9ucyBhcmUg ZXhwZWN0ZWQgb24gdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1jaGFpcnNAaWV0Zi5v cmciPnJ0Zy1jaGFpcnNAaWV0Zi5vcmc8L2E+IGFuZA0KPGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJA aWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+IG1haWxpbmcgbGlzdHMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtJ biBUb3JvbnRvOiBUaGVyZSB3aWxsIGJlIG1lZXRpbmdzIHdpdGggdGhlIFdHIGNoYWlycyBhbmQg dGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7Um91dGluZyBEaXJlY3RvcmF0ZSB0byBnZXQgdGhlIGlkZWFzIGRlc2NyaWJl ZCBhbmQgYWdyZWVkIHVwb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtBdCB0aGUgUm91dGluZyBBcmVhIE1lZXRpbmcg aW4gVG9yb250bzogRGlzY3VzcyB0aGUgc2V0IG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cmVvcmdhbml6ZWQgV0dzIGFu ZCBnZW5lcmFsIGNoYXJ0ZXIgY29udGVudCBpbiB0aGUgUm91dGluZyBBcmVhPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7bWVl dGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO1NlcHRlbWJlciAyMDE0OiBCYXNlZCB1cG9uIHRoZSBmZWVkYmFjaywg c3VnZ2VzdGlvbnMsIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2Rpc2N1c3Npb24sIEFkcmlhbiBhbmQgSSBmaW5hbGl6 ZSB0aGUgcmVvcmdhbml6ZWQgV0cgY2hhcnRlcnMuICZuYnNwO1dlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7c3RhcnQgdGhl IGludGVybmFsIElFU0cgZGlzY3Vzc2lvbiBhbmQgcHVibGljIHJldmlld3MuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtP Y3RvYmVyIDIwMTQ6IEZvcm1hbCByZWNoYXJ0ZXJpbmcgcHJvY2VzcyBjb21wbGV0ZXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtJbiBIb25vbHVsdTogVGhlIG5ldyBzZXQgb2YgV0dzIG1lZXQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtBZnRl ciBIb25vbHVsdTogQWRyaWFuIGFuZCBJIGRlYWwgd2l0aCBhbnkgaXNzdWVzIGFuZCBjaGFydGVy PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7dXBkYXRlcyBiYXNlZCB1cG9uIGEgZmV3IG1vbnRocyBvZiBleHBlcmllbmNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJl IGFyZSB0aGUgbW90aXZhdGlvbnMgdGhhdCBBZHJpYW4gYW5kIEkgd291bGQgbGlrZSB0byBiZSBj b25zaWRlcmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj53aGVuIGNvbWluZyB1cCB3aXRoIGlkZWFzIGZvciBob3cgdGhlIFdHcyBzaG91bGQgYmUg cmVvcmdhbml6ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsxKSBNb3ZlIHRvd2FyZHMgb3JnYW5pemluZyB3b3JraW5n IGdyb3VwcyBvbiBmdW5jdGlvbmFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cmVzcG9uc2liaWxpdGllcyByYXRoZXIgdGhh biBzY29waW5nIHRoZW0gdG8gc3BlY2lmaWMgcHJvdG9jb2xzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7MikgU3BsaXQg Z2lhbnQgd29ya2luZyBncm91cHMgc28gcmVsZXZhbnQgd29yayBpcyBkb25lIGluIG9uZSBwbGFj ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO2FuZCB0aGVyZSBpcyBhbiBpbXByb3ZlZCBzaWduYWwtdG8tbm9pc2UgcmF0aW8g Zm9yIHBhcnRpY2lwYW50cyB3aG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthcmUgb25seSBpbnRlcmVzdGVkIGluIGEgc2xp Y2Ugb2YgdGhlIGN1cnJlbnQgd29ya2luZyBncm91cCdzIHdvcmsuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDszKSBDcmVh dGUgc3luZXJnaWVzIGZvciBzY2F0dGVyZWQgZnVuY3Rpb25hbGl0eSAoZXhhbXBsZSBpZGVhczo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDtPQU0sIEZSUiwgdHJhZmZpYy1lbmdpbmVlcmluZyk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzQpIENyZWF0 ZSBhIERJU1BBVENIIHdvcmtpbmcgZ3JvdXAgZm9yIGNsZWFyIG5ldyBpZGVhIGRpc2N1c3Npb247 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7cnRnd2cgc2VydmVzIHNvbWUgb2YgdGhpcyBwdXJwb3NlIGJ1dCBkb2Vzbid0IGhh dmUgYSBjbGVhciBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YW5kIGlzbid0IGRyYXdpbmcgaW4gdGhlIG5ldyBp ZGVhcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOzUpIEZvY3VzIFJvdXRpbmcgQXJlYSB0aW1lIG9uIGRlc2lnbiBjZW50 ZXJzIHJhdGhlciB0aGFuIG9uIGZhcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2Nvcm5lciBjYXNlcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzYp IEVhY2ggd29ya2luZyBncm91cCBzaG91bGQgaGF2ZSBjbGVhciwgd2VsbCBkZWZpbmVkLCBhbmQg YWNoaWV2YWJsZSBnb2Fscy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Tm90aW5nIHRoYXQgdGhlIFJvdXRpbmcgQXJlYSBoYXMgaW5oZXJpdGVk IHNvbWUgb2YgaXRzIFdHIHN0cnVjdHVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+ZnJvbSB0aGUgc3ViLUlQIGFyZWEsIGl0IGlzIG5vdCBhIGdv YWwgdG8gZm9yY2UgSVAgcm91dGluZyBhbmQgTVBMUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cm91dGluZyB0byByZW1haW4gc2VwYXJhdGVkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg Z29hbCBvZiB0aGlzIHJlb3JnYW5pemF0aW9uIGlzIG5vdCBjbG9zaW5nIHdvcmtpbmcgZ3JvdXBz LiAmbmJzcDtBZHJpYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmFuZCBBbGlhIGFyZSBwZXJmZWN0bHkgY2FwYWJsZSBvZiBjbG9zaW5nIHdvcmtp bmcgZ3JvdXBzIHdpdGhvdXQgZ29pbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnRocm91Z2ggcmVzdHJ1Y3R1cmluZy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRob3NlIG9mIHlvdSB0 aGF0IGhhdmUgcmVhZCB0aGlzIGZhciwgdGhhbmsgeW91LiAmbmJzcDtHZXR0aW5nIHRoaXMgODAl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yaWdo dCBpcyBnb2luZyB0byB0YWtlIHNvbWUgc2VyaW91cyBkaXNjdXNzaW9uIGFuZCB0aG91Z2h0LiAm bmJzcDtXZSBhbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPndvcmsgaW4gdGhlIFJvdXRpbmcgQXJlYSB0b2dldGhlciB3aXRoIGRpZmZlcmVudCBw ZXJzcGVjdGl2ZXMuICZuYnNwO1BsZWFzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhpbmsgY2FyZWZ1bGx5IGFuZCBoZWxwIHVzIGhhdmUgYSBo aWdobHkgZm9jdXNlZCBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGlhIGFuZCBBZHJpYW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_027a8e31cf2e47e0bbfabc23a7507e16CO2PR05MB636namprd05pro_-- From nobody Wed Jun 11 02:55:56 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9AD1A0325 for ; Wed, 11 Jun 2014 02:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwjrBLEjj5kS for ; Wed, 11 Jun 2014 02:55:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFA71A01EB for ; Wed, 11 Jun 2014 02:55:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFH49780; Wed, 11 Jun 2014 09:55:25 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 10:55:24 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 11 Jun 2014 17:55:21 +0800 From: Qin Wu To: "routing-discussion@ietf.org" Subject: RE: OAM and restructuring the Rtg Area Thread-Topic: OAM and restructuring the Rtg Area Thread-Index: Ac+FWXDS82ER4VXhS+S22nbfxsZjVwAAUnyA Date: Wed, 11 Jun 2014 09:55:20 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8454AF21nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/gVyl-YRwfrK6AHAnNaom_DnXUB8 Cc: "rcallon@juniper.net" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 09:55:34 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8454AF21nkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIGxpa2UgdGhlIHN1Z2dlc3Rpb24gbWFkZSBieSBSb3NzIGFib3V0IHJlc3RydWN0dXJl IGZvciBPQU0uIFRoZXJlIGlzIE9BTSBpbiBzb21lIFJURyB3b3JraW5nIGdyb3VwcyBhbmQgaXQg bmVlZHMgY29vcmRpbmF0aW9uLiBBbHNvIHRoZXJlIGlzIHRoZSBtYW5hZ2VtZW50IG9mIE9BTSBm dW5jdGlvbiB3aXRoIHRoZSBjb250cm9sIHBsYW5lLiBJdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0 byBoYXZlIHNpbmdsZSB3b3JraW5nIGdyb3VwIGZvciBPQU0gaW4gcm91dGluZyBhcmVhLg0KUGxl YXNlIHNlZSB0aGF0IHdlIGhhdmUgcHJvcG9zZWQgYSBCb0YgZm9yIFRvcm9udG8gY2FsbGVkIHRo ZSBUSU1FIEJvRiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2YvdHJhYy8gV2UgZG9uJ3Qg a25vdyBpZiB3ZSBnZXQgZ3JhbnRlZCwgYnV0IHRoZXJlIGlzIGEgbWFpbGluZyBsaXN0IGFuZCBJ bnRlcm5ldC1EcmFmdHMgdGhhdCBkaXNjdXNzIGlkZWFzIHRvIGhhdmUgY29tbW9uIE9BTSBhcHBy b2FjaGVzIGluIHRoZSBJRVRGLg0KDQpSZWdhcmRzIQ0KLVFpbg0KRnJvbTogcm91dGluZy1kaXNj dXNzaW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBSb3NzIENhbGxvbg0KU2VudDogMTAgSnVuZSAyMDE0IDIzOjA5DQpUbzogQWxpYSBB dGxhczsgcm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPG1haWx0bzpyb3V0aW5nLWRpc2N1c3Np b25AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogSW1wcm92aW5nIGFuZCBSZXN0cnVjdHVyaW5nIHRo ZSBSb3V0aW5nIEFyZWENCg0KSSB0aGluayB0aGF0IHRoZXJlIGlzIHF1aXRlIGEgYml0IG9mIGNv bnRlbnQgaW4gdGhpcyBlbWFpbCwgYW5kIHRoYXQgd2UgbWlnaHQgbmVlZCB0byBlbmQgdXAgd2l0 aCBzZXZlcmFsIHRocmVhZHMgLS0gc3VjaCBhcyBvbmUgZm9yIHJvdXRpbmcgZGlyZWN0b3JhdGUg Y2hhbmdlcywgb25lIGZvciBXRyBjaGFpciB0cmFpbmluZywgYW5kIG9uZSBmb3IgV0cgcmVvcmdh bml6YXRpb24uDQoNClNwZWFraW5nIGZvciB0aGUgbGF0dGVyIOKAkyBXRyByZW9yZ2FuaXphdGlv biwgYW5kIHNwZWNpZmljYWxseSBvbiBkZWFsaW5nIHdpdGggdmVyeSBsYXJnZSBXR3M6IEkgdGhp bmsgdGhhdCB0aGVyZSBpcyBhIHRyYWRlb2ZmIGhlcmUuIFZlcnkgbGFyZ2UgV0dzIGNhbiBiZSBj dW1iZXJzb21lIGFuZCBtaWdodCBub3QgYmUgYXMg4oCcZm9jdXNlZOKAnSBhcyBzbWFsbGVyIGdy b3Vwcy4gSG93ZXZlciwgaXQgaXMgbXVjaCBlYXNpZXIgb3IgbW9yZSBsaWtlbHkgZm9yIHdvcmsg dG8gZGl2ZXJnZSB3aGVuIGl0IGlzIHNwbGl0IGludG8gbXVsdGlwbGUgZ3JvdXBzLg0KDQpBcyBv bmUgZXhhbXBsZSwgb25lIG9idmlvdXNseSBsYXJnZSBncm91cCBpcyBNUExTLiBMb29raW5nIGF0 IHRoZSB3b3JrIGdvaW5nIG9uIGluIE1QTFMsIG9uZSBwb3NzaWJsZSB3YXkgdG8gc3BsaXQgaXQg dXAgd291bGQgYmUgdG8gc3BsaXQgb2ZmIHRoZSBPQU0gd29yay4gSG93ZXZlciwgaG93IHRvIG1h bmFnZSBhIHByb3RvY29sIGlzIHZlcnkgbXVjaCB0aWVkIGludG8gb3RoZXIgYXNwZWN0cyBvZiB0 aGUgb3BlcmF0aW9uIG9mIHRoZSBwcm90b2NvbC4gSWYgcGVvcGxlIHdvcmtpbmcgb24gb25lIGFz cGVjdCBvZiBhIHByb3RvY29sIGFyZSBib3JlZCBsaXN0ZW5pbmcgdG8gT0FNIGRpc2N1c3Npb25z LCBpdCBtaWdodCBub25ldGhlbGVzcyBiZSBhIGdvb2QgaWRlYSBmb3IgdGhlbSB0byBsaXN0ZW4g dG8gT0FNIGRpc2N1c3Npb25zLg0KDQpEbyB3ZSB3YW50IHRvIGdldCBpbnRvIGRpc2N1c3Npbmcg ZGV0YWlscyBwZXJ0aW5lbnQgdG8gc3BlY2lmaWMgV0dzPw0KDQpUaGFua3MsIFJvc3MNCg0KRnJv bTogcm91dGluZy1kaXNjdXNzaW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0bGFzDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEw LCAyMDE0IDM6NTggUE0NClRvOiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8bWFpbHRvOnJv dXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZz4NClN1YmplY3Q6IEltcHJvdmluZyBhbmQgUmVzdHJ1 Y3R1cmluZyB0aGUgUm91dGluZyBBcmVhDQoNClRvIGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhlIFJv dXRpbmcgQXJlYSwNCg0KQWRyaWFuIGFuZCBJIGFyZSB3b3JraW5nIG9uIGltcHJvdmluZyB0aGUg cXVhbGl0eSwgc3BlZWQsIGFuZA0KZXhwZXJpZW5jZSBvZiBnZXR0aW5nIHdvcmsgZG9uZSBpbiB0 aGUgSUVURiBSb3V0aW5nIEFyZWEuICBUaGVyZSBhcmUNCnRocmVlIGluaXRpYXRpdmVzIHRoYXQg d2UgYXJlIHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWENCnNwZWNpZmljIFdHIGNo YWlyIHRyYWluaW5nLCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3JraW5nIGdyb3VwcyBpbiB0aGUN CmFyZWEuDQoNCkZpcnN0LCB3ZSBpbnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9yYXRl IG1vcmUgcHJvYWN0aXZlbHkgYnkNCmludHJvZHVjaW5nIGEgV29ya2luZyBHcm91cCBEcmFmdCBR dWFsaXR5IEFzc3VyYW5jZSAoV0cgRHJhZnQgUUEpDQpwcm9jZXNzIHdoZXJlIHRoZSBzYW1lIHNl bGVjdGVkIHJvdXRpbmcgZGlyZWN0b3JhdGUgbWVtYmVyIHdpbGwgcmV2aWV3DQphIGRyYWZ0IGR1 cmluZyBXRyBkcmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3QgY2FsbC4gIFRoZSBwcm9j ZXNzDQp3aWxsIGJlIGRvY3VtZW50ZWQgb24gdGhlIFJvdXRpbmcgQXJlYSB3aWtpDQooaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpKS4gIFRoaXMgc2hvdWxkIGFs bG93DQpkaXJlY3RvcmF0ZSByZXZpZXdzIHRvIHJlcG9ydCB0ZWNobmljYWwgaXNzdWVzIHRoYXQg Y2FuIGFjdHVhbGx5IGdldA0KZml4ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxlbnQg b2YgYnVnIHJlcG9ydHMpIGFzIG9wcG9zZWQgdG8NCmp1c3Qgbm90aW5nIHRoZSBjb25jZXJucyBp biB0aGUgZHJhZnRzIChlcXVpdmFsZW50IG9mIHJlbGVhc2Ugbm90ZXMpLg0KDQpTZWNvbmQsIGFz IHdhcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSByZWNlbnQgSUVTRyByZXRyZWF0LCBpbiBhZGRpdGlv bg0KdG8gdGhlIElFVEYtd2lkZSBXRyBjaGFpciB0cmFpbmluZywgd2UgaW50ZW5kIHRvIGhhdmUg YSBzZXJpZXMgb2YNCnRyYWluaW5nIHNlc3Npb25zIGZvciBXRyBDaGFpcnMgaW4gdGhlIFJvdXRp bmcgQXJlYSBhZGRyZXNzaW5nIHRvcGljcw0Kc3VjaCBhcyBqdWRnaW5nIGNvbnNlbnN1cywgcHJv amVjdCBtYW5hZ2VtZW50LCBtb3RpdmF0aW5nIHZvbHVudGVlcnMsDQp1c2luZyB0aGUgZGF0YXRy YWNrZXIgKHZpYSBhIHNhbmRib3ggdmVyc2lvbiB0aGF0IGNhbiBiZSBwbGF5ZWQNCndpdGggc2Fm ZWx5KSwgYW5kIHNoYXJpbmcgZXhwZXJpZW5jZXMgYmV0d2VlbiBXRyBjaGFpcnMuDQoNClRoaXJk LCB3ZSBpbnRlbmQgdG8gcmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMgaW4gdGhlIFJvdXRp bmcgYXJlYS4NCldlIGZlZWwgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZm9jdXMgb24gYXJlYXMg d2hlcmUgdGhlcmUgaXMgYWN0aXZlDQppbnRlcmVzdCBpbiBzdGFuZGFyZGl6YXRpb24gYW5kIHRv IGJlIG9wZW4gYW5kIGFibGUgdG8gYWNjZXB0IG5ldyB3b3JrDQppbnRvIHRoZSBhcmVhLiAgQXMg eW91IGtub3csIHdlIGhhdmUgaGFkIHNldmVyYWwgbmV3IHdvcmtpbmcgZ3JvdXBzDQoobnZvMywg aTJycywgc2ZjLCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhlIGxhc3QgZmV3IHllYXJzIGFuZCB3ZSBu ZWVkIHRvDQpiZSBvcGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3JlIG5ldyB3b3JrIGFzIGl0IGNv bWVzIGluLiAgV2Ugd291bGQNCmFsc28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWduYWwtdG8tbm9p c2UgcmF0aW8gZXhwZXJpZW5jZWQgYnkNCnBhcnRpY2lwYW50cyBpbiB0aGUgZGlmZmVyZW50IHdv cmtpbmcgZ3JvdXBzIGFuZCBpbXByb3ZlIHRoZSBxdWFudGl0eQ0KYW5kIHF1YWxpdHkgb2YgZGlz Y3Vzc2lvbiBhbmQgcmV2aWV3cy4gIEl0IGlzIGxpa2VseSB0aGF0IG5vdCBhbGwgV0dzDQppbiB0 aGUgUm91dGluZyBBcmVhIHdpbGwgYmUgZGlyZWN0bHkgYWZmZWN0ZWQuDQoNCkhlcmUgaXMgdGhl IHRpbWUtbGluZSBmb3IgcmVvcmdhbml6aW5nIHRoZSBXR3MuDQoNCiAgIE5PVzogcHVibGljIGRp c2N1c3Npb24gb24gcm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPG1haWx0bzpyb3V0aW5nLWRp c2N1c3Npb25AaWV0Zi5vcmc+IGFib3V0IGhvdyB0bw0KICAgcmVvcmdhbml6ZSB0aGUgd29ya2lu ZyBncm91cHMgdG8gYmVzdCBtZWV0IG91ciBtb3RpdmF0aW9ucy4NCiAgIEFkZGl0aW9uYWwgZm9j dXNlZCBkaXNjdXNzaW9ucyBhcmUgZXhwZWN0ZWQgb24gdGhlDQogICBydGctY2hhaXJzQGlldGYu b3JnPG1haWx0bzpydGctY2hhaXJzQGlldGYub3JnPiBhbmQgcnRnLWRpckBpZXRmLm9yZzxtYWls dG86cnRnLWRpckBpZXRmLm9yZz4gbWFpbGluZyBsaXN0cy4NCg0KICAgSW4gVG9yb250bzogVGhl cmUgd2lsbCBiZSBtZWV0aW5ncyB3aXRoIHRoZSBXRyBjaGFpcnMgYW5kIHRoZQ0KICAgUm91dGlu ZyBEaXJlY3RvcmF0ZSB0byBnZXQgdGhlIGlkZWFzIGRlc2NyaWJlZCBhbmQgYWdyZWVkIHVwb24u DQoNCiAgIEF0IHRoZSBSb3V0aW5nIEFyZWEgTWVldGluZyBpbiBUb3JvbnRvOiBEaXNjdXNzIHRo ZSBzZXQgb2YNCiAgIHJlb3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBjaGFydGVyIGNvbnRlbnQg aW4gdGhlIFJvdXRpbmcgQXJlYQ0KICAgbWVldGluZy4NCg0KICAgU2VwdGVtYmVyIDIwMTQ6IEJh c2VkIHVwb24gdGhlIGZlZWRiYWNrLCBzdWdnZXN0aW9ucywgYW5kDQogICBkaXNjdXNzaW9uLCBB ZHJpYW4gYW5kIEkgZmluYWxpemUgdGhlIHJlb3JnYW5pemVkIFdHIGNoYXJ0ZXJzLiAgV2UNCiAg IHN0YXJ0IHRoZSBpbnRlcm5hbCBJRVNHIGRpc2N1c3Npb24gYW5kIHB1YmxpYyByZXZpZXdzLg0K DQogICBPY3RvYmVyIDIwMTQ6IEZvcm1hbCByZWNoYXJ0ZXJpbmcgcHJvY2VzcyBjb21wbGV0ZXMu DQoNCiAgIEluIEhvbm9sdWx1OiBUaGUgbmV3IHNldCBvZiBXR3MgbWVldC4NCg0KICAgQWZ0ZXIg SG9ub2x1bHU6IEFkcmlhbiBhbmQgSSBkZWFsIHdpdGggYW55IGlzc3VlcyBhbmQgY2hhcnRlcg0K ICAgdXBkYXRlcyBiYXNlZCB1cG9uIGEgZmV3IG1vbnRocyBvZiBleHBlcmllbmNlLg0KDQpIZXJl IGFyZSB0aGUgbW90aXZhdGlvbnMgdGhhdCBBZHJpYW4gYW5kIEkgd291bGQgbGlrZSB0byBiZSBj b25zaWRlcmVkDQp3aGVuIGNvbWluZyB1cCB3aXRoIGlkZWFzIGZvciBob3cgdGhlIFdHcyBzaG91 bGQgYmUgcmVvcmdhbml6ZWQuDQoNCiAgIDEpIE1vdmUgdG93YXJkcyBvcmdhbml6aW5nIHdvcmtp bmcgZ3JvdXBzIG9uIGZ1bmN0aW9uYWwNCiAgIHJlc3BvbnNpYmlsaXRpZXMgcmF0aGVyIHRoYW4g c2NvcGluZyB0aGVtIHRvIHNwZWNpZmljIHByb3RvY29scy4NCg0KICAgMikgU3BsaXQgZ2lhbnQg d29ya2luZyBncm91cHMgc28gcmVsZXZhbnQgd29yayBpcyBkb25lIGluIG9uZSBwbGFjZQ0KICAg YW5kIHRoZXJlIGlzIGFuIGltcHJvdmVkIHNpZ25hbC10by1ub2lzZSByYXRpbyBmb3IgcGFydGlj aXBhbnRzIHdobw0KICAgYXJlIG9ubHkgaW50ZXJlc3RlZCBpbiBhIHNsaWNlIG9mIHRoZSBjdXJy ZW50IHdvcmtpbmcgZ3JvdXAncyB3b3JrLg0KDQogICAzKSBDcmVhdGUgc3luZXJnaWVzIGZvciBz Y2F0dGVyZWQgZnVuY3Rpb25hbGl0eSAoZXhhbXBsZSBpZGVhczoNCiAgIE9BTSwgRlJSLCB0cmFm ZmljLWVuZ2luZWVyaW5nKQ0KDQogICA0KSBDcmVhdGUgYSBESVNQQVRDSCB3b3JraW5nIGdyb3Vw IGZvciBjbGVhciBuZXcgaWRlYSBkaXNjdXNzaW9uOw0KICAgcnRnd2cgc2VydmVzIHNvbWUgb2Yg dGhpcyBwdXJwb3NlIGJ1dCBkb2Vzbid0IGhhdmUgYSBjbGVhciBwcm9jZXNzDQogICBhbmQgaXNu J3QgZHJhd2luZyBpbiB0aGUgbmV3IGlkZWFzLg0KDQogICA1KSBGb2N1cyBSb3V0aW5nIEFyZWEg dGltZSBvbiBkZXNpZ24gY2VudGVycyByYXRoZXIgdGhhbiBvbiBmYXINCiAgIGNvcm5lciBjYXNl cy4NCg0KICAgNikgRWFjaCB3b3JraW5nIGdyb3VwIHNob3VsZCBoYXZlIGNsZWFyLCB3ZWxsIGRl ZmluZWQsIGFuZCBhY2hpZXZhYmxlIGdvYWxzLg0KDQpOb3RpbmcgdGhhdCB0aGUgUm91dGluZyBB cmVhIGhhcyBpbmhlcml0ZWQgc29tZSBvZiBpdHMgV0cgc3RydWN0dXJlDQpmcm9tIHRoZSBzdWIt SVAgYXJlYSwgaXQgaXMgbm90IGEgZ29hbCB0byBmb3JjZSBJUCByb3V0aW5nIGFuZCBNUExTDQpy b3V0aW5nIHRvIHJlbWFpbiBzZXBhcmF0ZWQuDQoNClRoZSBnb2FsIG9mIHRoaXMgcmVvcmdhbml6 YXRpb24gaXMgbm90IGNsb3Npbmcgd29ya2luZyBncm91cHMuICBBZHJpYW4NCmFuZCBBbGlhIGFy ZSBwZXJmZWN0bHkgY2FwYWJsZSBvZiBjbG9zaW5nIHdvcmtpbmcgZ3JvdXBzIHdpdGhvdXQgZ29p bmcNCnRocm91Z2ggcmVzdHJ1Y3R1cmluZy4NCg0KRm9yIHRob3NlIG9mIHlvdSB0aGF0IGhhdmUg cmVhZCB0aGlzIGZhciwgdGhhbmsgeW91LiAgR2V0dGluZyB0aGlzIDgwJQ0KcmlnaHQgaXMgZ29p bmcgdG8gdGFrZSBzb21lIHNlcmlvdXMgZGlzY3Vzc2lvbiBhbmQgdGhvdWdodC4gIFdlIGFsbA0K d29yayBpbiB0aGUgUm91dGluZyBBcmVhIHRvZ2V0aGVyIHdpdGggZGlmZmVyZW50IHBlcnNwZWN0 aXZlcy4gIFBsZWFzZQ0KdGhpbmsgY2FyZWZ1bGx5IGFuZCBoZWxwIHVzIGhhdmUgYSBoaWdobHkg Zm9jdXNlZCBkaXNjdXNzaW9uLg0KDQpUaGFua3MsDQpBbGlhIGFuZCBBZHJpYW4NCg0K --_000_B8F9A780D330094D99AF023C5877DABA8454AF21nkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQ2hhcg0KCXttc28t c3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBsaWtlIHRoZSBzdWdnZXN0aW9uIG1hZGUgYnkgUm9zcyBh Ym91dCByZXN0cnVjdHVyZSBmb3IgT0FNLiBUaGVyZSBpcyBPQU0gaW4gc29tZSBSVEcgd29ya2lu ZyBncm91cHMgYW5kIGl0IG5lZWRzIGNvb3JkaW5hdGlvbi4gQWxzbyB0aGVyZSBpcw0KIHRoZSBt YW5hZ2VtZW50IG9mIE9BTSBmdW5jdGlvbiB3aXRoIHRoZSBjb250cm9sIHBsYW5lLiBJdCB3b3Vs ZCBiZSBpbnRlcmVzdGluZyB0byBoYXZlIHNpbmdsZSB3b3JraW5nIGdyb3VwIGZvciBPQU0gaW4g cm91dGluZyBhcmVhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UGxlYXNlIHNlZSB0aGF0IHdlIGhhdmUgcHJvcG9zZWQgYSBCb0YgZm9yIFRvcm9udG8gY2FsbGVk IHRoZSBUSU1FIEJvRg0KPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYm9mL3Ry YWMvIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ib2YvdHJhYy88L2E+IFdlIGRvbid0IGtu b3cgaWYgd2UgZ2V0IGdyYW50ZWQsIGJ1dCB0aGVyZSBpcyBhIG1haWxpbmcgbGlzdCBhbmQgSW50 ZXJuZXQtRHJhZnRzIHRoYXQgZGlzY3VzcyBpZGVhcyB0byBoYXZlIGNvbW1vbiBPQU0gYXBwcm9h Y2hlcyBpbiB0aGUgSUVURi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1RaW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJvdXRpbmctZGlzY3Vzc2lvbiBbPGEgaHJl Zj0ibWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cm91 dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5Sb3NzIENhbGxvbjxicj4NCjxiPlNlbnQ6PC9iPiAxMCBKdW5lIDIwMTQgMjM6MDk8YnI+DQo8 Yj5Ubzo8L2I+IEFsaWEgQXRsYXM7IDxhIGhyZWY9Im1haWx0bzpyb3V0aW5nLWRpc2N1c3Npb25A aWV0Zi5vcmciPnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IEltcHJvdmluZyBhbmQgUmVzdHJ1Y3R1cmluZyB0aGUgUm91dGluZyBBcmVhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCB0aGVyZSBpcyBxdWl0ZSBhIGJpdCBvZiBjb250ZW50 IGluIHRoaXMgZW1haWwsIGFuZCB0aGF0IHdlIG1pZ2h0IG5lZWQgdG8gZW5kIHVwIHdpdGggc2V2 ZXJhbCB0aHJlYWRzIC0tIHN1Y2ggYXMgb25lIGZvciByb3V0aW5nIGRpcmVjdG9yYXRlDQogY2hh bmdlcywgb25lIGZvciBXRyBjaGFpciB0cmFpbmluZywgYW5kIG9uZSBmb3IgV0cgcmVvcmdhbml6 YXRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TcGVha2luZyBmb3Ig dGhlIGxhdHRlciDigJMgV0cgcmVvcmdhbml6YXRpb24sIGFuZCBzcGVjaWZpY2FsbHkgb24gZGVh bGluZyB3aXRoIHZlcnkgbGFyZ2UgV0dzOiBJIHRoaW5rIHRoYXQgdGhlcmUgaXMgYSB0cmFkZW9m ZiBoZXJlLiBWZXJ5IGxhcmdlDQogV0dzIGNhbiBiZSBjdW1iZXJzb21lIGFuZCBtaWdodCBub3Qg YmUgYXMg4oCcZm9jdXNlZOKAnSBhcyBzbWFsbGVyIGdyb3Vwcy4gSG93ZXZlciwgaXQgaXMgbXVj aCBlYXNpZXIgb3IgbW9yZSBsaWtlbHkgZm9yIHdvcmsgdG8gZGl2ZXJnZSB3aGVuIGl0IGlzIHNw bGl0IGludG8gbXVsdGlwbGUgZ3JvdXBzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFzIG9uZSBleGFtcGxlLCBvbmUgb2J2aW91c2x5IGxhcmdlIGdyb3VwIGlzIE1QTFMu IExvb2tpbmcgYXQgdGhlIHdvcmsgZ29pbmcgb24gaW4gTVBMUywgb25lIHBvc3NpYmxlIHdheSB0 byBzcGxpdCBpdCB1cCB3b3VsZCBiZSB0byBzcGxpdCBvZmYNCiB0aGUgT0FNIHdvcmsuIEhvd2V2 ZXIsIGhvdyB0byBtYW5hZ2UgYSBwcm90b2NvbCBpcyB2ZXJ5IG11Y2ggdGllZCBpbnRvIG90aGVy IGFzcGVjdHMgb2YgdGhlIG9wZXJhdGlvbiBvZiB0aGUgcHJvdG9jb2wuIElmIHBlb3BsZSB3b3Jr aW5nIG9uIG9uZSBhc3BlY3Qgb2YgYSBwcm90b2NvbCBhcmUgYm9yZWQgbGlzdGVuaW5nIHRvIE9B TSBkaXNjdXNzaW9ucywgaXQgbWlnaHQgbm9uZXRoZWxlc3MgYmUgYSBnb29kIGlkZWEgZm9yIHRo ZW0gdG8gbGlzdGVuDQogdG8gT0FNIGRpc2N1c3Npb25zLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+RG8gd2Ugd2FudCB0byBnZXQgaW50byBkaXNjdXNzaW5nIGRldGFpbHMg cGVydGluZW50IHRvIHNwZWNpZmljIFdHcz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFua3MsIFJvc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHJvdXRpbmctZGlzY3Vzc2lvbiBbPGEgaHJlZj0ibWFpbHRvOnJvdXRp bmctZGlzY3Vzc2lvbi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cm91dGluZy1kaXNjdXNzaW9u LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGlhIEF0bGFzPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTAsIDIwMTQgMzo1OCBQTTxicj4NCjxiPlRv OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZyI+cm91dGlu Zy1kaXNjdXNzaW9uQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBJbXByb3Zpbmcg YW5kIFJlc3RydWN0dXJpbmcgdGhlIFJvdXRpbmcgQXJlYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRvIGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhlIFJvdXRpbmcgQXJl YSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFkcmlh biBhbmQgSSBhcmUgd29ya2luZyBvbiBpbXByb3ZpbmcgdGhlIHF1YWxpdHksIHNwZWVkLCBhbmQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+ZXhwZXJpZW5jZSBvZiBnZXR0aW5nIHdvcmsgZG9uZSBpbiB0 aGUgSUVURiBSb3V0aW5nIEFyZWEuICZuYnNwO1RoZXJlIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij50aHJlZSBpbml0aWF0aXZlcyB0aGF0IHdlIGFyZSB3b3JraW5nOiBXRyBEcmFmdCBRQSwgUm91 dGluZyBBcmVhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnNwZWNpZmljIFdHIGNoYWlyIHRyYWluaW5n LCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3JraW5nIGdyb3VwcyBpbiB0aGU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+YXJlYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkZpcnN0LCB3ZSBpbnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9yYXRlIG1v cmUgcHJvYWN0aXZlbHkgYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aW50cm9kdWNpbmcgYSBXb3Jr aW5nIEdyb3VwIERyYWZ0IFF1YWxpdHkgQXNzdXJhbmNlIChXRyBEcmFmdCBRQSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+cHJvY2VzcyB3aGVyZSB0aGUgc2FtZSBzZWxlY3RlZCByb3V0aW5nIGRpcmVj dG9yYXRlIG1lbWJlciB3aWxsIHJldmlldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hIGRyYWZ0IGR1 cmluZyBXRyBkcmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3QgY2FsbC4gJm5ic3A7VGhl IHByb2Nlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+d2lsbCBiZSBkb2N1bWVudGVkIG9uIHRoZSBS b3V0aW5nIEFyZWEgd2lraTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4oPGEgaHJlZj0iaHR0cDovL3Ry YWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpIj5odHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2k8L2E+KS4gJm5ic3A7VGhpcyBzaG91bGQgYWxsb3c8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+ZGlyZWN0b3JhdGUgcmV2aWV3cyB0byByZXBvcnQgdGVjaG5p Y2FsIGlzc3VlcyB0aGF0IGNhbiBhY3R1YWxseSBnZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Zml4 ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxlbnQgb2YgYnVnIHJlcG9ydHMpIGFzIG9w cG9zZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+anVzdCBub3RpbmcgdGhlIGNvbmNlcm5zIGlu IHRoZSBkcmFmdHMgKGVxdWl2YWxlbnQgb2YgcmVsZWFzZSBub3RlcykuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZWNvbmQsIGFzIHdhcyBkaXNjdXNz ZWQgZHVyaW5nIHRoZSByZWNlbnQgSUVTRyByZXRyZWF0LCBpbiBhZGRpdGlvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj50byB0aGUgSUVURi13aWRlIFdHIGNoYWlyIHRyYWluaW5nLCB3ZSBpbnRlbmQg dG8gaGF2ZSBhIHNlcmllcyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50cmFpbmluZyBzZXNzaW9u cyBmb3IgV0cgQ2hhaXJzIGluIHRoZSBSb3V0aW5nIEFyZWEgYWRkcmVzc2luZyB0b3BpY3M8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+c3VjaCBhcyBqdWRnaW5nIGNvbnNlbnN1cywgcHJvamVjdCBtYW5h Z2VtZW50LCBtb3RpdmF0aW5nIHZvbHVudGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnVzaW5n IHRoZSBkYXRhdHJhY2tlciAodmlhIGEgc2FuZGJveCB2ZXJzaW9uIHRoYXQgY2FuIGJlIHBsYXll ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj53aXRoIHNhZmVseSksIGFuZCBzaGFyaW5nIGV4cGVyaWVu Y2VzIGJldHdlZW4gV0cgY2hhaXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhpcmQsIHdlIGludGVuZCB0byByZW9yZ2FuaXplIHRoZSB3b3JraW5n IGdyb3VwcyBpbiB0aGUgUm91dGluZyBhcmVhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBmZWVs IHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIGZvY3VzIG9uIGFyZWFzIHdoZXJlIHRoZXJlIGlzIGFj dGl2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pbnRlcmVzdCBpbiBzdGFuZGFyZGl6YXRpb24gYW5k IHRvIGJlIG9wZW4gYW5kIGFibGUgdG8gYWNjZXB0IG5ldyB3b3JrPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPmludG8gdGhlIGFyZWEuICZuYnNwO0FzIHlvdSBrbm93LCB3ZSBoYXZlIGhhZCBzZXZlcmFs IG5ldyB3b3JraW5nIGdyb3VwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4obnZvMywgaTJycywgc2Zj LCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhlIGxhc3QgZmV3IHllYXJzIGFuZCB3ZSBuZWVkIHRvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmJlIG9wZW4gYW5kIGFibGUgdG8gaGFuZGxlIG1vcmUgbmV3IHdv cmsgYXMgaXQgY29tZXMgaW4uICZuYnNwO1dlIHdvdWxkPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFs c28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWduYWwtdG8tbm9pc2UgcmF0aW8gZXhwZXJpZW5jZWQg Ynk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cGFydGljaXBhbnRzIGluIHRoZSBkaWZmZXJlbnQgd29y a2luZyBncm91cHMgYW5kIGltcHJvdmUgdGhlIHF1YW50aXR5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PmFuZCBxdWFsaXR5IG9mIGRpc2N1c3Npb24gYW5kIHJldmlld3MuICZuYnNwO0l0IGlzIGxpa2Vs eSB0aGF0IG5vdCBhbGwgV0dzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmluIHRoZSBSb3V0aW5nIEFy ZWEgd2lsbCBiZSBkaXJlY3RseSBhZmZlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhlcmUgaXMgdGhlIHRpbWUtbGluZSBmb3IgcmVvcmdhbml6 aW5nIHRoZSBXR3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsgJm5ic3A7Tk9XOiBwdWJsaWMgZGlzY3Vzc2lvbiBvbiA8YSBocmVmPSJtYWls dG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnIj4NCnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRm Lm9yZzwvYT4gYWJvdXQgaG93IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDty ZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdyb3VwcyB0byBiZXN0IG1lZXQgb3VyIG1vdGl2YXRpb25z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7QWRkaXRpb25hbCBmb2N1c2VkIGRp c2N1c3Npb25zIGFyZSBleHBlY3RlZCBvbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpydGctY2hhaXJzQGlldGYub3JnIj5ydGctY2hhaXJzQGll dGYub3JnPC9hPiBhbmQNCjxhIGhyZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5ydGctZGly QGlldGYub3JnPC9hPiBtYWlsaW5nIGxpc3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0luIFRvcm9udG86IFRoZXJlIHdpbGwg YmUgbWVldGluZ3Mgd2l0aCB0aGUgV0cgY2hhaXJzIGFuZCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7ICZuYnNwO1JvdXRpbmcgRGlyZWN0b3JhdGUgdG8gZ2V0IHRoZSBpZGVhcyBkZXNj cmliZWQgYW5kIGFncmVlZCB1cG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0F0IHRoZSBSb3V0aW5nIEFyZWEgTWVldGluZyBp biBUb3JvbnRvOiBEaXNjdXNzIHRoZSBzZXQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 ICZuYnNwO3Jlb3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBjaGFydGVyIGNvbnRlbnQgaW4gdGhl IFJvdXRpbmcgQXJlYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7bWVldGluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDtTZXB0ZW1iZXIgMjAxNDogQmFzZWQgdXBvbiB0aGUgZmVlZGJhY2ssIHN1Z2dlc3Rpb25z LCBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO2Rpc2N1c3Npb24sIEFkcmlh biBhbmQgSSBmaW5hbGl6ZSB0aGUgcmVvcmdhbml6ZWQgV0cgY2hhcnRlcnMuICZuYnNwO1dlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtzdGFydCB0aGUgaW50ZXJuYWwgSUVTRyBk aXNjdXNzaW9uIGFuZCBwdWJsaWMgcmV2aWV3cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtPY3RvYmVyIDIwMTQ6IEZvcm1hbCBy ZWNoYXJ0ZXJpbmcgcHJvY2VzcyBjb21wbGV0ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7SW4gSG9ub2x1bHU6IFRoZSBuZXcg c2V0IG9mIFdHcyBtZWV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0FmdGVyIEhvbm9sdWx1OiBBZHJpYW4gYW5kIEkgZGVhbCB3 aXRoIGFueSBpc3N1ZXMgYW5kIGNoYXJ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZu YnNwO3VwZGF0ZXMgYmFzZWQgdXBvbiBhIGZldyBtb250aHMgb2YgZXhwZXJpZW5jZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhlcmUgYXJlIHRoZSBt b3RpdmF0aW9ucyB0aGF0IEFkcmlhbiBhbmQgSSB3b3VsZCBsaWtlIHRvIGJlIGNvbnNpZGVyZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+d2hlbiBjb21pbmcgdXAgd2l0aCBpZGVhcyBmb3IgaG93IHRo ZSBXR3Mgc2hvdWxkIGJlIHJlb3JnYW5pemVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOzEpIE1vdmUgdG93YXJkcyBvcmdhbml6 aW5nIHdvcmtpbmcgZ3JvdXBzIG9uIGZ1bmN0aW9uYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7ICZuYnNwO3Jlc3BvbnNpYmlsaXRpZXMgcmF0aGVyIHRoYW4gc2NvcGluZyB0aGVtIHRvIHNw ZWNpZmljIHByb3RvY29scy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsyKSBTcGxpdCBnaWFudCB3b3JraW5nIGdyb3VwcyBzbyBy ZWxldmFudCB3b3JrIGlzIGRvbmUgaW4gb25lIHBsYWNlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyAmbmJzcDthbmQgdGhlcmUgaXMgYW4gaW1wcm92ZWQgc2lnbmFsLXRvLW5vaXNlIHJhdGlv IGZvciBwYXJ0aWNpcGFudHMgd2hvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDth cmUgb25seSBpbnRlcmVzdGVkIGluIGEgc2xpY2Ugb2YgdGhlIGN1cnJlbnQgd29ya2luZyBncm91 cCdzIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsgJm5ic3A7MykgQ3JlYXRlIHN5bmVyZ2llcyBmb3Igc2NhdHRlcmVkIGZ1bmN0aW9u YWxpdHkgKGV4YW1wbGUgaWRlYXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDtP QU0sIEZSUiwgdHJhZmZpYy1lbmdpbmVlcmluZyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDs0KSBDcmVhdGUgYSBESVNQQVRDSCB3 b3JraW5nIGdyb3VwIGZvciBjbGVhciBuZXcgaWRlYSBkaXNjdXNzaW9uOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsgJm5ic3A7cnRnd2cgc2VydmVzIHNvbWUgb2YgdGhpcyBwdXJwb3NlIGJ1 dCBkb2Vzbid0IGhhdmUgYSBjbGVhciBwcm9jZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyAmbmJzcDthbmQgaXNuJ3QgZHJhd2luZyBpbiB0aGUgbmV3IGlkZWFzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOzUpIEZvY3Vz IFJvdXRpbmcgQXJlYSB0aW1lIG9uIGRlc2lnbiBjZW50ZXJzIHJhdGhlciB0aGFuIG9uIGZhcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7Y29ybmVyIGNhc2VzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOzYpIEVh Y2ggd29ya2luZyBncm91cCBzaG91bGQgaGF2ZSBjbGVhciwgd2VsbCBkZWZpbmVkLCBhbmQgYWNo aWV2YWJsZSBnb2Fscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPk5vdGluZyB0aGF0IHRoZSBSb3V0aW5nIEFyZWEgaGFzIGluaGVyaXRlZCBzb21lIG9m IGl0cyBXRyBzdHJ1Y3R1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZnJvbSB0aGUgc3ViLUlQIGFy ZWEsIGl0IGlzIG5vdCBhIGdvYWwgdG8gZm9yY2UgSVAgcm91dGluZyBhbmQgTVBMUzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5yb3V0aW5nIHRvIHJlbWFpbiBzZXBhcmF0ZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZ29hbCBvZiB0aGlzIHJlb3Jn YW5pemF0aW9uIGlzIG5vdCBjbG9zaW5nIHdvcmtpbmcgZ3JvdXBzLiAmbmJzcDtBZHJpYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+YW5kIEFsaWEgYXJlIHBlcmZlY3RseSBjYXBhYmxlIG9mIGNsb3Np bmcgd29ya2luZyBncm91cHMgd2l0aG91dCBnb2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50aHJv dWdoIHJlc3RydWN0dXJpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5Gb3IgdGhvc2Ugb2YgeW91IHRoYXQgaGF2ZSByZWFkIHRoaXMgZmFyLCB0aGFu ayB5b3UuICZuYnNwO0dldHRpbmcgdGhpcyA4MCU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmlnaHQg aXMgZ29pbmcgdG8gdGFrZSBzb21lIHNlcmlvdXMgZGlzY3Vzc2lvbiBhbmQgdGhvdWdodC4gJm5i c3A7V2UgYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPndvcmsgaW4gdGhlIFJvdXRpbmcgQXJlYSB0 b2dldGhlciB3aXRoIGRpZmZlcmVudCBwZXJzcGVjdGl2ZXMuICZuYnNwO1BsZWFzZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj50aGluayBjYXJlZnVsbHkgYW5kIGhlbHAgdXMgaGF2ZSBhIGhpZ2hseSBm b2N1c2VkIGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsaWEgYW5kIEFkcmlhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA8454AF21nkgeml501mbschi_-- From nobody Wed Jun 11 06:52:39 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00E61A00F9 for ; Wed, 11 Jun 2014 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiZaBVgB_HjE for ; Wed, 11 Jun 2014 06:52:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1041A00E7 for ; Wed, 11 Jun 2014 06:52:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 49C1CC48F; Wed, 11 Jun 2014 09:52:36 -0400 (EDT) Date: Wed, 11 Jun 2014 09:52:36 -0400 From: Jeffrey Haas To: Qin Wu Subject: Re: OAM and restructuring the Rtg Area Message-ID: <20140611135236.GC6784@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/OAXDLZhRB_ItHTiDQYkvjnWC9PM Cc: "rcallon@juniper.net" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:52:37 -0000 Qin (and Ross), On Wed, Jun 11, 2014 at 09:55:20AM +0000, Qin Wu wrote: > I like the suggestion made by Ross about restructure for OAM. There is OAM > in some RTG working groups and it needs coordination. Also there is the > management of OAM function with the control plane. It would be interesting > to have single working group for OAM in routing area. We have an entire area (OPS) with part of this as their charter. While I agree there is a desire to get more involvement in OAM issues and perhaps centralize some of the subject matter experts, how would a WG within routing help? I suspect an argument could even be made that MPLS OAM may belong in transport or int. :-) To some extent, the call from the ADs is to find a way to let work that doesn't have strong boundaries have a home that removes those boundaries. We should be considering this impact across IETF areas and not only within routing. (meta-working groups, as I call them.) -- Jeff From nobody Wed Jun 11 08:42:57 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5B51A0174 for ; Wed, 11 Jun 2014 08:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B879wCQ8lNP for ; Wed, 11 Jun 2014 08:42:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8D11A016E for ; Wed, 11 Jun 2014 08:42:53 -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 s5BFgS44021591; Wed, 11 Jun 2014 16:42:28 +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 s5BFgRUI021585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jun 2014 16:42:27 +0100 From: "Adrian Farrel" To: "'Jeffrey Haas'" , "'Qin Wu'" References: <20140611135236.GC6784@pfrc> In-Reply-To: <20140611135236.GC6784@pfrc> Subject: RE: OAM and restructuring the Rtg Area Date: Wed, 11 Jun 2014 16:42:25 +0100 Message-ID: <011e01cf858b$becf2ab0$3c6d8010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBgGpNUaG4ZZrBF4kxuFVB9l7/1gIQqaBRm/ePEGA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20752.000 X-TM-AS-Result: No--24.683-10.0-31-10 X-imss-scan-details: No--24.683-10.0-31-10 X-TMASE-MatchedRID: y/2oPz6gbvjRhEyb9f1sjhxzRIO7XotZcmsHQK7cMOdojAWuSDNe9kZZ Z6C5Rye746yG3Ufmn1r+jFZADttS75W+sJq4Gm66BEfU2vugRF23dp6DuD+6wCIWzbRXGr/CYCE nAolpChDG1dgLAMwJGhsHDLcsSEIj6XRJ8hwoQUfbB8cowInHkIyzstdwoG+PnvbaEOoeixMwtK SSEFIiTk5qSF6ShjrjU9d+7+jr6avOf6FUr/HJkVfS8E9vfq82f7rvXBvEkWnFJnEpmt9OEzF8L 6qP+UhJdEDqyVj171apuV/S1LzluZcFdomgH0lnOX/V8P8ail3InWAWA4yE6foA9r2LThYYKrau Xd3MZDUD/dHyT/Xh7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/-MdP0vnX6Uvzz-3RGoV8WP0XwRQ Cc: rcallon@juniper.net, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 15:42:56 -0000 Just a question, Jeff... Don't we already have a WG in Routing that does OAM? Are you suggesting that BFD should move to INT? We also have OAM in MPLS (LSP ping and MPLS-TP), CCAMP (where it is coordination of OAM using the control plane), PWE3 and L2VPN (with a history of VCCV), and NVO3 and SFC (currently floating new ideas related to OAM). OTOH, your final para seems to suggest that bundling function (like OAM) into a single WG and having that be cross-area in some sense would not be a bad idea. Adrian > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf > Of Jeffrey Haas > Sent: 11 June 2014 14:53 > To: Qin Wu > Cc: rcallon@juniper.net; routing-discussion@ietf.org > Subject: Re: OAM and restructuring the Rtg Area > > Qin (and Ross), > > On Wed, Jun 11, 2014 at 09:55:20AM +0000, Qin Wu wrote: > > I like the suggestion made by Ross about restructure for OAM. There is OAM > > in some RTG working groups and it needs coordination. Also there is the > > management of OAM function with the control plane. It would be interesting > > to have single working group for OAM in routing area. > > We have an entire area (OPS) with part of this as their charter. While I agree > there is a desire to get more involvement in OAM issues and perhaps > centralize some of the subject matter experts, how would a WG within routing > help? > > I suspect an argument could even be made that MPLS OAM may belong in > transport or int. :-) > > To some extent, the call from the ADs is to find a way to let work that > doesn't have strong boundaries have a home that removes those boundaries. > We should be considering this impact across IETF areas and not only within > routing. (meta-working groups, as I call them.) From nobody Wed Jun 11 09:38:15 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136581A017F for ; Wed, 11 Jun 2014 09:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wljc96AjYyjY for ; Wed, 11 Jun 2014 09:38:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B475B1A016C for ; Wed, 11 Jun 2014 09:38:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 44374C48F; Wed, 11 Jun 2014 12:38:12 -0400 (EDT) Date: Wed, 11 Jun 2014 12:38:12 -0400 From: Jeffrey Haas To: Adrian Farrel Subject: Re: OAM and restructuring the Rtg Area Message-ID: <20140611163812.GE6784@pfrc> References: <20140611135236.GC6784@pfrc> <011e01cf858b$becf2ab0$3c6d8010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011e01cf858b$becf2ab0$3c6d8010$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/UcsNfIyD2-lqWSj9VvlYikgwUkM Cc: rcallon@juniper.net, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 16:38:14 -0000 On Wed, Jun 11, 2014 at 04:42:25PM +0100, Adrian Farrel wrote: > Just a question, Jeff... > > Don't we already have a WG in Routing that does OAM? > Are you suggesting that BFD should move to INT? I do like to ask leading questions. :-) If we were to look at the work BFD does today, there would probably be the same level of hand-wringing over whether it's a routing protocol used for OAM or OAM that has routing components and thus belongs in INT. > We also have OAM in MPLS (LSP ping and MPLS-TP), CCAMP (where it is coordination > of OAM using the control plane), PWE3 and L2VPN (with a history of VCCV), and > NVO3 and SFC (currently floating new ideas related to OAM). > > OTOH, your final para seems to suggest that bundling function (like OAM) into a > single WG and having that be cross-area in some sense would not be a bad idea. Something cross-area is exactly what I have in mind, and think BFD probably fits in the same boat. Some of the other discussion also suggested we want more "agility" within the IETF. To me, these competing things suggest: - Keep many of the trappings of a WG for specific work. Mailing list, ability to have sessions, etc. - Have related sub-WGs fit into a cross-area meta-group. You could liken this to "dotted line" managerial relationships. Thus, I don't think I'd kill BFD as a separate WG. We should spin-up the cross-area functionality and put BFD under such a function. IGP was a similar analogy for isis/ospf (and perhaps others). But aside from "fostering communication" and "splitting work from overloaded groups", I'm unclear what any of this does for us procedurally. In my experience, people already pay (at least partial) attention to related WGs. If they don't, having something like a meta-area list that draws your attention to classes of work is good. BFD probably wouldn't change how often it needs to meet. (Partially because the chairs are aggressive about not meeting unless there is new content to discuss in a room.) MPLS OAM would probably split into a separate session, but the people doing much of that work would still need to heavily coordinate in the main MPLS WG. And to make a critical point: If such splits with coordination to related WGs results in the need for the same presentation to happen more than one place, we've *failed* in my opinion. By comparison, if the same "the IGPs could use this feature" results in one presentation to the IGP meta-WG, we've saved a wasted presentation slot and discussion. That's a win. -- Jeff From nobody Wed Jun 11 11:32:02 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2011B280F for ; Wed, 11 Jun 2014 11:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fnKsLYnN2ra for ; Wed, 11 Jun 2014 11:31:58 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBCD1B280E for ; Wed, 11 Jun 2014 11:31:58 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 11 Jun 2014 18:31:56 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Wed, 11 Jun 2014 18:31:56 +0000 From: Ross Callon To: Gregory Mirsky , "routing-discussion@ietf.org" Subject: RE: WG Draft QA Thread-Topic: WG Draft QA Thread-Index: Ac+E8ckkYFaQI77LS52TAFhVxCOK3QAsN4mQ Date: Wed, 11 Jun 2014 18:31:55 +0000 Message-ID: <76ab8c74c44f4ab0bf0a8dd0d8a40b91@CO2PR05MB636.namprd05.prod.outlook.com> References: <7347100B5761DC41A166AC17F22DF1121B7CC9C4@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7CC9C4@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0239D46DB6 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(199002)(189002)(80022001)(66066001)(74502001)(74662001)(81542001)(18717965001)(19580395003)(83322001)(19580405001)(31966008)(20776003)(76576001)(64706001)(81342001)(16236675004)(74316001)(15202345003)(4396001)(85852003)(19625215002)(86362001)(83072002)(19609705001)(15975445006)(92566001)(2656002)(87936001)(19300405004)(77982001)(99396002)(99286001)(76482001)(33646001)(54356999)(50986999)(76176999)(101416001)(21056001)(79102001)(77096999)(46102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: multipart/alternative; boundary="_000_76ab8c74c44f4ab0bf0a8dd0d8a40b91CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/pGbi5j_2t7ng7_5_IOg1LT7fy7Q X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 18:32:01 -0000 --_000_76ab8c74c44f4ab0bf0a8dd0d8a40b91CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have wondered how WG specific reviews (such as the MPLS review team revie= ws with are done in the MPLS WG) will coexist with the additional early Rou= ting Area Directorate reviews. If both are done early (say, immediately pri= or to WG adoption), then we probably want to do them at the same time. We h= ave up to now been asking for three or sometimes four MPLS-RT reviews. We m= ight want to replace one of these with a routing directorate review. IMHO it has been quite valuable to have reviewers who are very familiar wit= h the general technology area, although I have also noticed an effort to do= the same with routing directorate reviews. Coordinating the chair request for a review by the working group review tea= m with the routing directorate review should be straightforward (WG chairs,= WG secretaries, and ADs for that area should all know each other). Ross From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Gregory Mirsky Sent: Tuesday, June 10, 2014 5:33 PM To: routing-discussion@ietf.org Subject: WG Draft QA Dear Alia, Adrian, et. al, I fully support the goal to improve quality of WG documents and commitment = of the Routing directorate to assign its members to review documents at WG = adoption and WG LC. I hope you will consider to compliment these reviews wi= th reviews by designated experts resembling MPLS Review Team (MPLS-RT). Rev= iews by WG RTs may be especially helpful as work on some documents may be q= uite lengthy time consuming process and it may be challenging to ensure tha= t the RD reviewer at WG adoption call can do review at time of WG LC. Regards, Greg --_000_76ab8c74c44f4ab0bf0a8dd0d8a40b91CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have wondered how WG= specific reviews (such as the MPLS review team reviews with are done in th= e MPLS WG) will coexist with the additional early Routing Area Directorate = reviews. If both are done early (say, immediately prior to WG adoption), then we probably want to do them at the= same time. We have up to now been asking for three or sometimes four MPLS-= RT reviews. We might want to replace one of these with a routing directorat= e review.

 

IMHO it has been quite= valuable to have reviewers who are very familiar with the general technolo= gy area, although I have also noticed an effort to do the same with routing= directorate reviews.

 

Coordinating the chair= request for a review by the working group review team with the routing dir= ectorate review should be straightforward (WG chairs, WG secretaries, and A= Ds for that area should all know each other).

 

Ross=

 

From: routing-= discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, June 10, 2014 5:33 PM
To: routing-discussion@ietf.org
Subject: WG Draft QA

 

Dear Alia, Adrian, et. al,

I fully support the goal to improve quality of WG do= cuments and commitment of the Routing directorate to assign its members to = review documents at WG adoption and WG LC. I hope you will consider to comp= liment these reviews with reviews by designated experts resembling MPLS Review Team (MPLS-RT). Reviews by WG= RTs may be especially helpful as work on some documents may be quite lengt= hy time consuming process and it may be challenging to ensure that the RD r= eviewer at WG adoption call can do review at time of WG LC.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_76ab8c74c44f4ab0bf0a8dd0d8a40b91CO2PR05MB636namprd05pro_-- From nobody Wed Jun 11 14:06:29 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72751B289B for ; Wed, 11 Jun 2014 14:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWSNSYoUjbFw for ; Wed, 11 Jun 2014 14:06:26 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B361B27C2 for ; Wed, 11 Jun 2014 14:06:26 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so559411qcz.28 for ; Wed, 11 Jun 2014 14:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VOK7b317umMgpMUppwV6QEypW6p/lZ7pgQB5hVg+FAo=; b=bE/HW7d1r3eq4hWi4fBcUZj6WX0FA/e3iWh/fmZFFHYWuu6R135UZgxvBLh09BA/fB xihvD2F7IPNzDkrNtVhtNvy5RcwkMH1sgVDnON7N35OjRHrxtxOIamNWkSHpgW+NZd5v XX7y4J3zOEXypBXa487+GoX5xM4XQbO/w6OW3OG13ugXs1m99KxhjEWLHCGqSvjFNQDA uEua4n2fvcy270H7ZuizEAuo+5XECnKNJO+tW2lD3b16qp0DrtWmHdsY4ri/8Tcu44fZ I38XLRBJdKwt182YSo2W3QIugA2J6PkrpqndKk/jl9I5WZ255gP7G+qyTRkNn5tlSodO SC4w== X-Received: by 10.224.92.144 with SMTP id r16mr57109937qam.10.1402520785565; Wed, 11 Jun 2014 14:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.148 with HTTP; Wed, 11 Jun 2014 14:06:05 -0700 (PDT) In-Reply-To: <20140611163812.GE6784@pfrc> References: <20140611135236.GC6784@pfrc> <011e01cf858b$becf2ab0$3c6d8010$@olddog.co.uk> <20140611163812.GE6784@pfrc> From: "Andrew G. Malis" Date: Wed, 11 Jun 2014 17:06:05 -0400 Message-ID: Subject: Re: OAM and restructuring the Rtg Area To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e015386a236bdf404fb95d1e4 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/TyagLx20XaEtCzezdV-W41x9W4Q Cc: Ross Callon , Adrian Farrel , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 21:06:28 -0000 --089e015386a236bdf404fb95d1e4 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 12:38 PM, Jeffrey Haas wrote: > We should spin-up the cross-area functionality and put BFD under such a > function. IGP was a similar analogy for isis/ospf (and perhaps others). > This reminds me of the sub-IP pseudo-area that we spun up in 2001, which was jointly managed by the INT, OPS, RTG and TSV ADs. It had mpls, ccamp, ppvpn (later to become l2vpn and l3vpn), IP over optical, and similar groups that were dealing with sub-l3 issues. It worked very well, and could be a case study for how to proceed here. Cheers, Andy --089e015386a236bdf404fb95d1e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jun 11, 2014 at 12:38 PM, Jeffrey Haas <jhaas@pfrc.org>= wrote:
We should spin-up the cross-area functionality and put BFD und= er such a
function. =C2=A0IGP was a similar analogy for isis/ospf (and perhaps others= ).

This reminds me of the sub-IP pseudo-are= a that we spun up in 2001, which was jointly managed by the INT, OPS, RTG a= nd TSV ADs. It had mpls, ccamp, ppvpn (later to become l2vpn and l3vpn), IP= over optical, and similar groups that were dealing with sub-l3 issues. It = worked very well, and could be a case study for how to proceed here.

Cheers,
Andy
--089e015386a236bdf404fb95d1e4-- From nobody Wed Jun 11 20:27:40 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699BB1B299E for ; Wed, 11 Jun 2014 20:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AmNPwoMcqSy for ; Wed, 11 Jun 2014 20:27:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455AF1A0495 for ; Wed, 11 Jun 2014 20:27:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFI17375; Thu, 12 Jun 2014 03:27:36 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 04:27:35 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 11:27:30 +0800 From: Qin Wu To: Jeffrey Haas Subject: RE: OAM and restructuring the Rtg Area Thread-Topic: OAM and restructuring the Rtg Area Thread-Index: Ac+FWXDS82ER4VXhS+S22nbfxsZjVwAAUnyA//+9OwD//pglkA== Date: Thu, 12 Jun 2014 03:27:29 +0000 Message-ID: References: <20140611135236.GC6784@pfrc> In-Reply-To: <20140611135236.GC6784@pfrc> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/npnx-B-YGVgOakmbWY40S78skzk Cc: "rcallon@juniper.net" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 03:27:39 -0000 SGksIEplZmZyZXk6DQppZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIGpvaW50IG1lZXRp bmdzIG9yIHNlc3Npb25zIGJldHdlZW4gdHdvIGFyZWEgaXMgdXN1YWxseSByYXJlLg0KQ29sbGFi b3JhdGlvbiBpcyBhbG1vc3QgYWx3YXlzIHRocm91Z2ggaW5kaXZpZHVhbHMgcGFydGljaXBhdGlu ZyBpbiBib3RoIE9QUyBhcmVhIGFuZCBSVEcgYXJlYS4NClRoZXJlZm9yZSByZW1vdmluZyBib3Vu ZGFyeSBiZXR3ZWVuIHR3byBhcmVhcyBzZWVtcyBhIHJlYWxseSBnb29kIGlkZWEgdG8gbWUuDQoN ClJlZ2FyZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogSmVmZnJleSBIYWFz IFttYWlsdG86amhhYXNAcGZyYy5vcmddIA0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjExyNUgMjE6NTMN CsrVvP7IyzogUWluIFd1DQqzrcvNOiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc7IHJjYWxs b25AanVuaXBlci5uZXQNCtb3zOI6IFJlOiBPQU0gYW5kIHJlc3RydWN0dXJpbmcgdGhlIFJ0ZyBB cmVhDQoNClFpbiAoYW5kIFJvc3MpLA0KDQpPbiBXZWQsIEp1biAxMSwgMjAxNCBhdCAwOTo1NToy MEFNICswMDAwLCBRaW4gV3Ugd3JvdGU6DQo+IEkgbGlrZSB0aGUgc3VnZ2VzdGlvbiBtYWRlIGJ5 IFJvc3MgYWJvdXQgcmVzdHJ1Y3R1cmUgZm9yIE9BTS4gVGhlcmUgaXMgDQo+IE9BTSBpbiBzb21l IFJURyB3b3JraW5nIGdyb3VwcyBhbmQgaXQgbmVlZHMgY29vcmRpbmF0aW9uLiBBbHNvIHRoZXJl IA0KPiBpcyB0aGUgbWFuYWdlbWVudCBvZiBPQU0gZnVuY3Rpb24gd2l0aCB0aGUgY29udHJvbCBw bGFuZS4gSXQgd291bGQgYmUgDQo+IGludGVyZXN0aW5nIHRvIGhhdmUgc2luZ2xlIHdvcmtpbmcg Z3JvdXAgZm9yIE9BTSBpbiByb3V0aW5nIGFyZWEuDQoNCldlIGhhdmUgYW4gZW50aXJlIGFyZWEg KE9QUykgd2l0aCBwYXJ0IG9mIHRoaXMgYXMgdGhlaXIgY2hhcnRlci4gIFdoaWxlIEkgYWdyZWUg dGhlcmUgaXMgYSBkZXNpcmUgdG8gZ2V0IG1vcmUgaW52b2x2ZW1lbnQgaW4gT0FNIGlzc3VlcyBh bmQgcGVyaGFwcyBjZW50cmFsaXplIHNvbWUgb2YgdGhlIHN1YmplY3QgbWF0dGVyIGV4cGVydHMs IGhvdyB3b3VsZCBhIFdHIHdpdGhpbiByb3V0aW5nIGhlbHA/DQoNCkkgc3VzcGVjdCBhbiBhcmd1 bWVudCBjb3VsZCBldmVuIGJlIG1hZGUgdGhhdCBNUExTIE9BTSBtYXkgYmVsb25nIGluIHRyYW5z cG9ydCBvciBpbnQuIDotKQ0KDQpUbyBzb21lIGV4dGVudCwgdGhlIGNhbGwgZnJvbSB0aGUgQURz IGlzIHRvIGZpbmQgYSB3YXkgdG8gbGV0IHdvcmsgdGhhdCBkb2Vzbid0IGhhdmUgc3Ryb25nIGJv dW5kYXJpZXMgaGF2ZSBhIGhvbWUgdGhhdCByZW1vdmVzIHRob3NlIGJvdW5kYXJpZXMuDQpXZSBz aG91bGQgYmUgY29uc2lkZXJpbmcgdGhpcyBpbXBhY3QgYWNyb3NzIElFVEYgYXJlYXMgYW5kIG5v dCBvbmx5IHdpdGhpbiByb3V0aW5nLiAgKG1ldGEtd29ya2luZyBncm91cHMsIGFzIEkgY2FsbCB0 aGVtLikNCg0KLS0gSmVmZg0K From nobody Wed Jun 11 22:16:13 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF4A1A037A for ; Wed, 11 Jun 2014 22:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouy0ndCDWfQD for ; Wed, 11 Jun 2014 22:16:10 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308981A035F for ; Wed, 11 Jun 2014 22:16:10 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id ABF4918013DA for ; Thu, 12 Jun 2014 07:16:07 +0200 (CEST) Message-ID: <53993792.3050902@pi.nu> Date: Thu, 12 Jun 2014 07:16:02 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "routing-discussion@ietf.org" Subject: big equal to inefficient ?? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/4v62LaJ0QmAzKzv0fs3DMF4qZvA X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 05:16:12 -0000 Alia and Adrian, you say: 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. Exactly what metrics is the assertion that "giant working groups" are in-efficient based on? /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 12 05:30:41 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5041B2882 for ; Thu, 12 Jun 2014 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a27FGdcMUcb2 for ; Thu, 12 Jun 2014 05:30:39 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE28E1B2880 for ; Thu, 12 Jun 2014 05:30:38 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5CCUZ8X008249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Jun 2014 07:30:36 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5CCUZeu026265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Jun 2014 14:30:35 +0200 Received: from [172.27.205.196] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 12 Jun 2014 14:30:34 +0200 Message-ID: <53999D6A.1050803@alcatel-lucent.com> Date: Thu, 12 Jun 2014 14:30:34 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Subject: Functional responsibilities [Re: Improving and Restructuring the Routing Area] References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/-Bp6mBXh2Yx82wEfWecLH5YpRIU X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:30:40 -0000 Le 10/06/2014 21:57, Alia Atlas a écrit : > Here are the motivations that Adrian and I would like to be considered > when coming up with ideas for how the WGs should be reorganized. > > 1) Move towards organizing working groups on functional > responsibilities rather than scoping them to specific protocols. Alia, Adrian, I do not know if that is crystal clear for every one, but if we plan to end-up with such organization may be it would be worth listing, defining/scoping and agreeing on the functions. Is this what you have in mind: routing, forwarding/encapsulation, resource control, resilience, oam, VPNs, mcast, ... Also, beyond the functional areas we will end up with, I tend to think that there are elements which would be transversal inter-domain (routing, resource control, path computation) security Your views and those of others are welcome. Thx -m From nobody Thu Jun 12 05:42:08 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061D11B29F3 for ; Thu, 12 Jun 2014 05:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sa3VQm5bCdG for ; Thu, 12 Jun 2014 05:42:02 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915DD1B29F2 for ; Thu, 12 Jun 2014 05:42:02 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BC17C18013DA for ; Thu, 12 Jun 2014 14:42:00 +0200 (CEST) Message-ID: <5399A014.8060104@pi.nu> Date: Thu, 12 Jun 2014 14:41:56 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: Re: Functional responsibilities [Re: Improving and Restructuring the Routing Area] References: <53999D6A.1050803@alcatel-lucent.com> In-Reply-To: <53999D6A.1050803@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/HK4orkdQeB44_fW-6LZ52qGdUI8 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 12:42:05 -0000 Folks, I think that Martin asks good questions. I'm not convinced that splitting working groups along "functions" even if we can agree what functions should be the basis for the split. I think that one aspect tht has not been at all mentioned is that working groups should be established such the need for coordination between them are minimized. And before yoou start yelling at me, yes there are a need for coordiantion almost always, but I strive to minimize I'd also say that one protocol goes into one working group (again as far as possible). We have had two coordination activities where we mostly succeeded LDP for LSPs to MPLS, LDP for PWs to PWE3, and RSVP-TE for anything but packet to CCAMP, RSVP-TE for packet to MPLS. /Loa On 2014-06-12 14:30, Martin Vigoureux wrote: > Le 10/06/2014 21:57, Alia Atlas a écrit : >> Here are the motivations that Adrian and I would like to be considered >> when coming up with ideas for how the WGs should be reorganized. >> >> 1) Move towards organizing working groups on functional >> responsibilities rather than scoping them to specific protocols. > > Alia, Adrian, > > I do not know if that is crystal clear for every one, but if we plan to > end-up with such organization may be it would be worth listing, > defining/scoping and agreeing on the functions. > > Is this what you have in mind: > > routing, forwarding/encapsulation, resource control, resilience, oam, > VPNs, mcast, ... > > Also, beyond the functional areas we will end up with, I tend to think > that there are elements which would be transversal > inter-domain (routing, resource control, path computation) > security > > Your views and those of others are welcome. > Thx > > -m > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 12 10:16:23 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5E21A058E for ; Thu, 12 Jun 2014 10:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nvF0m2ZMRNs for ; Thu, 12 Jun 2014 10:16:18 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440581A015E for ; Thu, 12 Jun 2014 10:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=954; q=dns/txt; s=iport; t=1402593378; x=1403802978; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=Yxau53y4dTfepsu279wR6HdO50MFwh7adt4fytAE4jc=; b=IDjMsEHwI1hQFktrOWZH/ySOAU2voTOEBWitZ9rohQl8RwT0owA3Cye9 Maexe5+NhdGUY22X+pWlkCYOXD0yeMn08mJ/XkBGEDAMYyQh3xxvkC7u5 aiDNUDXrSF8TxdsO/ppVmXmh6XCOsVe5oxVHJvU8ETayquv+YggbxY86h Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAOnfmVOtJssW/2dsb2JhbABargYBAQEBAQEFAZYNgxEBgSB1hAMBAQEEOFELGAklDwJGBgEMCAEBEYgtuTKZFBeFXIkGhEEBA5oyk1KDPQ X-IronPort-AV: E=Sophos;i="5.01,466,1400025600"; d="scan'208";a="79206849" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 12 Jun 2014 17:16:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5CHGGNv015316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 17:16:16 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s5CHGDFW012042; Thu, 12 Jun 2014 18:16:14 +0100 (BST) Message-ID: <5399E05D.20506@cisco.com> Date: Thu, 12 Jun 2014 18:16:13 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Loa Andersson , "routing-discussion@ietf.org" Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> In-Reply-To: <53993792.3050902@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/4Y2aIXZpIIVhNQu7rMf8GBseNlk X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:16:21 -0000 On 12/06/2014 06:16, Loa Andersson wrote: > Alia and Adrian, > > you say: > > > 2) Split giant working groups so relevant work is done in one place > and there is an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. > > Exactly what metrics is the assertion that "giant working groups" are > in-efficient based on? > > /Loa Well, one concern is that some large working groups take two sessions - the most allowed at a meeting, and still end up with so many drafts to discuss they either get 5mins or less each, or not discussed. This is not a productive way forward. Now maybe the answer is to take a much firmer line on what gets discussed at IETF, but that needs a cultural change. The problem is that cultural changes are incredibly difficult and so far I have seen no workable answer beyond splitting the work into smaller slices. - Stewart From nobody Thu Jun 12 10:21:11 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFE51B27C6 for ; Thu, 12 Jun 2014 10:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ypr8dkmk9_h2 for ; Thu, 12 Jun 2014 10:20:55 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 427E71A01CB for ; Thu, 12 Jun 2014 10:20:55 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id l6so1682097oag.14 for ; Thu, 12 Jun 2014 10:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rU6T9qtk4LbzWGEW539oCOfIXJ3Bl59PT+nW9zAwO3Y=; b=FK3O9gzi6Ytrnti8BBUUtjybWPJ79IT4Ulp8elXn4t6XKVivCYxWa5yhbvLl983QgJ zXkdbgDbuHVfps3IAt4BJnym9ULd5M2bj1ZU69iYdkpmPhXcZPrU3I3JLv2iKJIP+uh2 aIGI2Edu+zwz5O9ZKGnCe4p4hs/rO+ou1vAwuW5iZwYmO+T/ddc4yeCsoBqBQ8IwkQEF looBf25JsLJcbccnotFtfVIDUn5O+kZ7lO2v7154ue8HXhdJK23hnYNvuaqkKgXc5YjR Ufvb/EsC4C57bOoF/ok2A3rzuDpNAcPGwZYgvVzsh2AIhELLqrosNNP1YelZDJVm/xi+ cJ9g== X-Received: by 10.60.52.207 with SMTP id v15mr47995360oeo.19.1402593654697; Thu, 12 Jun 2014 10:20:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.98.70 with HTTP; Thu, 12 Jun 2014 10:20:34 -0700 (PDT) In-Reply-To: <5399E05D.20506@cisco.com> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> From: Scott Brim Date: Thu, 12 Jun 2014 13:20:34 -0400 Message-ID: Subject: Re: big equal to inefficient ?? To: Stewart Bryant Content-Type: multipart/alternative; boundary=001a1133473e8d761b04fba6c845 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/WAW0C67vGLoDI7G9Kltnt3kCoX4 Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:20:58 -0000 --001a1133473e8d761b04fba6c845 Content-Type: text/plain; charset=UTF-8 IMHO it's not so much scope (what gets discussed) as serialization and focus. You can cover a wide range of topics, eventually, as long as you set milestones for each one and ratchet them forward at speed appropriate to their urgency. I suspect an "agile" approach to the overall charter would be appropriate for a large WG. On Thu, Jun 12, 2014 at 1:16 PM, Stewart Bryant wrote: > On 12/06/2014 06:16, Loa Andersson wrote: > >> Alia and Adrian, >> >> you say: >> >> >> 2) Split giant working groups so relevant work is done in one place >> and there is an improved signal-to-noise ratio for participants who >> are only interested in a slice of the current working group's work. >> >> Exactly what metrics is the assertion that "giant working groups" are >> in-efficient based on? >> >> /Loa >> > Well, one concern is that some large working groups take two > sessions - the most allowed at a meeting, and still end up with so > many drafts to discuss they either get 5mins or less each, or not > discussed. This is not a productive way forward. > > Now maybe the answer is to take a much firmer line on what gets > discussed at IETF, but that needs a cultural change. The problem > is that cultural changes are incredibly difficult and so far I have > seen no workable answer beyond splitting the work into smaller > slices. > > - Stewart > > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > --001a1133473e8d761b04fba6c845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMHO it's not so much scope (what gets discussed) as s= erialization and focus. You can cover a wide range of topics, eventually, a= s long as you set milestones for each one and ratchet them forward at speed= appropriate to their urgency. I suspect an "agile" approach to t= he overall charter would be appropriate for a large WG.



On Thu, Jun 12, 2014 at 1:16 PM, Stewart Bryant <stbryant@cisco.com> wrote:
On 12/06/2014 06:16, Loa And= ersson wrote:
Alia and Adrian,

you say:


=C2=A0 =C2=A02) Split giant working groups so relevant work is done in one = place
=C2=A0 =C2=A0and there is an improved signal-to-noise ratio for participant= s who
=C2=A0 =C2=A0are only interested in a slice of the current working group= 9;s work.

Exactly what metrics is the assertion that "giant working groups"= are
in-efficient based on?

/Loa
Well, one concern is that some large working groups take two
sessions - the most allowed at a meeting, and still end up with so
many drafts to discuss they either get 5mins or less each, or not
discussed. This is not a productive way forward.

Now maybe the answer is to take a much firmer line on what gets
discussed at IETF, but that needs a cultural change. The problem
is that cultural changes are incredibly difficult and so far I have
seen no workable answer beyond splitting the work into smaller
slices.

- Stewart




_______________________________________________
routing-discussion mailing list
routing-di= scussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=

--001a1133473e8d761b04fba6c845-- From nobody Thu Jun 12 10:21:40 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DD61B2AC6 for ; Thu, 12 Jun 2014 10:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ranS_nboPYx8 for ; Thu, 12 Jun 2014 10:21:25 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66891B2ACB for ; Thu, 12 Jun 2014 10:21:22 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E2E0A18013E2; Thu, 12 Jun 2014 19:21:20 +0200 (CEST) Message-ID: <5399E18C.4090306@pi.nu> Date: Thu, 12 Jun 2014 19:21:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: stbryant@cisco.com, "routing-discussion@ietf.org" Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> In-Reply-To: <5399E05D.20506@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/bf5IEMEdaNctyfxN8ual_28gMs8 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:21:30 -0000 Stewart, On 2014-06-12 19:16, Stewart Bryant wrote: > On 12/06/2014 06:16, Loa Andersson wrote: >> Alia and Adrian, >> >> you say: >> >> >> 2) Split giant working groups so relevant work is done in one place >> and there is an improved signal-to-noise ratio for participants who >> are only interested in a slice of the current working group's work. >> >> Exactly what metrics is the assertion that "giant working groups" are >> in-efficient based on? >> >> /Loa > Well, one concern is that some large working groups take two > sessions - the most allowed at a meeting, and still end up with so > many drafts to discuss they either get 5mins or less each, or not > discussed. This is not a productive way forward. > > Now maybe the answer is to take a much firmer line on what gets > discussed at IETF, but that needs a cultural change. The problem > is that cultural changes are incredibly difficult and so far I have > seen no workable answer beyond splitting the work into smaller > slices. > > - Stewart So if we split the wg taking two sessions into 3 or 4 groups, taking 3 or 4 sessions, that is better? /Loa > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 12 10:42:25 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83171B2ABF for ; Thu, 12 Jun 2014 10:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I78XbODcnt3T for ; Thu, 12 Jun 2014 10:42:21 -0700 (PDT) Received: from layerfree.net (heronab1.miniserver.com [77.73.2.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600831B27ED for ; Thu, 12 Jun 2014 10:42:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=173.38.208.169; Received: from [10.61.204.5] (unverified [173.38.208.169]) by layerfree.net (SurgeMail 6.5a) with ESMTP (TLS) id 523-1293857 for multiple; Thu, 12 Jun 2014 17:40:50 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: big equal to inefficient ?? From: Giles Heron In-Reply-To: <5399E18C.4090306@pi.nu> Date: Thu, 12 Jun 2014 18:42:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1878.2) X-Authenticated-User: giles@layerfree.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/sV9P7BxkdpicAqpto2B51CQnwi8 Cc: "routing-discussion@ietf.org" , stbryant@cisco.com X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:42:23 -0000 On 12 Jun 2014, at 18:21, Loa Andersson wrote: > Stewart, >=20 > On 2014-06-12 19:16, Stewart Bryant wrote: >> On 12/06/2014 06:16, Loa Andersson wrote: >>> Alia and Adrian, >>>=20 >>> you say: >>>=20 >>>=20 >>> 2) Split giant working groups so relevant work is done in one = place >>> and there is an improved signal-to-noise ratio for participants = who >>> are only interested in a slice of the current working group's = work. >>>=20 >>> Exactly what metrics is the assertion that "giant working groups" = are >>> in-efficient based on? >>>=20 >>> /Loa >> Well, one concern is that some large working groups take two >> sessions - the most allowed at a meeting, and still end up with so >> many drafts to discuss they either get 5mins or less each, or not >> discussed. This is not a productive way forward. >>=20 >> Now maybe the answer is to take a much firmer line on what gets >> discussed at IETF, but that needs a cultural change. The problem >> is that cultural changes are incredibly difficult and so far I have >> seen no workable answer beyond splitting the work into smaller >> slices. >>=20 >> - Stewart >=20 > So if we split the wg taking two sessions into 3 or 4 groups, taking 3 > or 4 sessions, that is better? yes, if the total length of the sessions is the same :) in general a more focussed group is better I think as there's less risk = of people having to sit through tons of drafts they're not interested in = - though I know in MPLS you have often split the sessions so that (for = example) all the MPLS-TP drafts get grouped together. Giles > /Loa >>=20 >>=20 >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Jun 12 10:58:49 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210BA1A0216 for ; Thu, 12 Jun 2014 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLRtxvYiYwFA for ; Thu, 12 Jun 2014 10:58:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAA21A05D1 for ; Thu, 12 Jun 2014 10:58:45 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 12 Jun 2014 17:58:44 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Thu, 12 Jun 2014 17:58:44 +0000 From: Ross Callon To: "stbryant@cisco.com" , Loa Andersson , "routing-discussion@ietf.org" Subject: RE: big equal to inefficient ?? Thread-Topic: big equal to inefficient ?? Thread-Index: AQHPhf1wFx08WUOWfE2nxW0cVA5XX5ttuAqAgAAAU1A= Date: Thu, 12 Jun 2014 17:58:43 +0000 Message-ID: <050c441f39344cb4a563c650171dee76@CO2PR05MB636.namprd05.prod.outlook.com> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> In-Reply-To: <5399E05D.20506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.18] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(13464003)(377454003)(479174003)(189002)(199002)(24454002)(74316001)(79102001)(19580395003)(87936001)(76576001)(74662001)(76482001)(19580405001)(64706001)(85852003)(83072002)(77982001)(50986999)(77096999)(20776003)(86362001)(54356999)(76176999)(15975445006)(81542001)(81342001)(2656002)(99396002)(101416001)(80022001)(4396001)(33646001)(74502001)(83322001)(46102001)(66066001)(99286001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/VO6to7LWn4EZjP1y3CNhruxYdHs X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 17:58:48 -0000 Actually, the MPLS group (which is about as big as they get, I think) has n= ot been quite as busy for the last two IETFs. Thus we have been able to hav= e more in depth discussion (which is desirable). Before that we were pretty= jammed with so many presentations that what you said did happen.=20 If you split the same presentations between more WGs, it doesn't make the w= eek less busy. If we want to have more longer discussions and a less overlo= aded week, it is probably necessary to push back on some presentations. To = me this is a matter for WG chair training -- which I think is a very good i= dea even for experienced WG chairs (there is always something that we can d= o better, or that we have forgotten about over the years). =20 To me the reason for splitting or combining WGs would be to make the work f= it more logically into groups, if we can come up with a split that allows t= his to happen.=20 I don't think that any split can be perfect. Thus there will always be draf= ts which are of interest to multiple WGs, and a need to coordinate work bet= ween WGs. However, it would be desirable if we can reduce the overlaps by g= rouping work into reasonable logical pieces. How to improve this over what = we have now is not obvious to me.=20 Ross -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Stewart Bryant Sent: Thursday, June 12, 2014 1:16 PM To: Loa Andersson; routing-discussion@ietf.org Subject: Re: big equal to inefficient ?? On 12/06/2014 06:16, Loa Andersson wrote: > Alia and Adrian, > > you say: > > > 2) Split giant working groups so relevant work is done in one place > and there is an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. > > Exactly what metrics is the assertion that "giant working groups" are > in-efficient based on? > > /Loa Well, one concern is that some large working groups take two sessions - the most allowed at a meeting, and still end up with so many drafts to discuss they either get 5mins or less each, or not discussed. This is not a productive way forward. Now maybe the answer is to take a much firmer line on what gets discussed at IETF, but that needs a cultural change. The problem is that cultural changes are incredibly difficult and so far I have seen no workable answer beyond splitting the work into smaller slices. - Stewart _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Jun 12 11:07:20 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB961A01A7 for ; Thu, 12 Jun 2014 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcR6cgyd5zCx for ; Thu, 12 Jun 2014 11:07:15 -0700 (PDT) Received: from g6t1525.atlanta.hp.com (g6t1525.atlanta.hp.com [15.193.200.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30671A015C for ; Thu, 12 Jun 2014 11:07:14 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t1525.atlanta.hp.com (Postfix) with ESMTPS id BE187180; Thu, 12 Jun 2014 18:07:12 +0000 (UTC) Received: from G6W3996.americas.hpqcorp.net (16.205.80.211) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 12 Jun 2014 18:05:37 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.232]) by G6W3996.americas.hpqcorp.net ([16.205.80.211]) with mapi id 14.03.0169.001; Thu, 12 Jun 2014 18:05:37 +0000 From: "Fedyk, Don" To: Giles Heron , Loa Andersson Subject: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTg== Date: Thu, 12 Jun 2014 18:05:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.201.12.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/lc-CM3YnWYABM9EneXwLPgWRXbg Cc: "routing-discussion@ietf.org" , "stbryant@cisco.com" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:07:17 -0000 Suggest: Have an interim meeting 1 or two days for large active groups (it has been = done before). A large amount of work can be accomplished there and the IE= TF session can be more of a status meeting (they are really anyway). Andy= Malis brought up the X over MPLS phase where we split work into other are= as. However, for me it was a logistical problem to follow sessions in anoth= er Area's track. In the end we pulled many of them back into routing as wo= rkload subsided.=20 Cheers,=20 Don=20 From nobody Thu Jun 12 11:09:49 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A2B1A01A7 for ; Thu, 12 Jun 2014 11:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6-PN6s3lDLW for ; Thu, 12 Jun 2014 11:09:44 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B591A015C for ; Thu, 12 Jun 2014 11:09:44 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DCD0A1B81E8 for ; Thu, 12 Jun 2014 11:09:43 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C181E190064; Thu, 12 Jun 2014 11:09:43 -0700 (PDT) Received: from vpna-149.vpn.nominum.com (64.89.227.149) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 11:09:43 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? From: Ted Lemon In-Reply-To: Date: Thu, 12 Jun 2014 14:09:36 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "Fedyk, Don" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [64.89.227.149] Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/QyvVSxWrBfGxFiyYx4UyzRyD2vo Cc: Stewart Bryant , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:09:45 -0000 On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: > A large amount of work can be accomplished there and the IETF session = can be more of a status meeting (they are really anyway). If IETF sessions are just status updates, why don't you do that online = and save yourself the travel cost? From nobody Thu Jun 12 11:13:54 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5541B2ADC for ; Thu, 12 Jun 2014 11:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AOleRNlllzX for ; Thu, 12 Jun 2014 11:13:50 -0700 (PDT) Received: from g5t1625.atlanta.hp.com (g5t1625.atlanta.hp.com [15.192.137.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8560E1B2AD6 for ; Thu, 12 Jun 2014 11:13:49 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t1625.atlanta.hp.com (Postfix) with ESMTPS id 61ED425A; Thu, 12 Jun 2014 18:13:48 +0000 (UTC) Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 12 Jun 2014 18:12:08 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.232]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.03.0169.001; Thu, 12 Jun 2014 18:12:09 +0000 From: "Fedyk, Don" To: Ted Lemon Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTgAAiZYAAAAHBcA= Date: Thu, 12 Jun 2014 18:12:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.201.12.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Re9uvVw1SeHlhidpWGZnJ7HWDjY Cc: "routing-discussion@ietf.org" , Stewart Bryant X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:13:52 -0000 Well perhaps status updates is the wrong term but you usually get 5 to 15 m= inutes and some extra minutes in the hallways.=20 Don=20 -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Ted Lemon Sent: Thursday, June 12, 2014 2:10 PM To: Fedyk, Don Cc: Stewart Bryant; routing-discussion@ietf.org Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: > A large amount of work can be accomplished there and the IETF session can= be more of a status meeting (they are really anyway). If IETF sessions are just status updates, why don't you do that online and = save yourself the travel cost? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Jun 12 11:14:21 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8818C1A01A7 for ; Thu, 12 Jun 2014 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jP07xaed5zZ for ; Thu, 12 Jun 2014 11:14:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09A81B2AE0 for ; Thu, 12 Jun 2014 11:14:14 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-ac-53999d1758e0 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7D.27.27529.71D99935; Thu, 12 Jun 2014 14:29:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 14:14:13 -0400 From: Gregory Mirsky To: Giles Heron , Loa Andersson Subject: RE: big equal to inefficient ?? Thread-Topic: big equal to inefficient ?? Thread-Index: AQHPhf1x6zUfw9te4022lC6c+0Pjc5tt+xiAgAABagCAAAXeAP//xUGw Date: Thu, 12 Jun 2014 18:14:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> In-Reply-To: <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyuXSPt6743JnBBouuGFi8ueVl8W/uHGaL E0u2slmcezqH0YHFY8rvjaweS5b8ZPJYfGIFi8es6W1sASxRXDYpqTmZZalF+nYJXBlvHmkX LBCt2Nv+kb2B8atAFyMnh4SAicSFQzvYIWwxiQv31rN1MXJxCAkcZZSYtbuLFcJZziixbfpD NpAqNgEjiRcbe8A6RAQcJNpuvmcGsZkFciSOnJsDFhcW0JB4tOA8C0SNpsSsExeZIWw3iVOn r4PNYRFQlfjy7TUjiM0r4CvR9+AcC8SyfkaJtoZ3rCAJTgFHiduH5zOB2IxA530/tYYJYpm4 xK0nEHEJAQGJJXvOM0PYohIvH/9jhbCVJCYtPccKUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzC MoFRbBaSsbOQtMxC0jILScsCRpZVjBylxalluelGBpsYgdF0TIJNdwfjnpeWhxgFOBiVeHgf JMwIFmJNLCuuzD3EKM3BoiTOq32zKlhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo/Jllwy2 W5OW6hyQqnbI9r3869MChr4fASsF5FTD4zsfxx772jdVQGO7tPWcaZsUI36WrZ+QHZEXMO3B A+Wsd6fzd/qzT2Zs6fvx+n6QXOP9IM3dE5Lmcv/9cJJ3qvDDcxtiJO70rNtw68GrsrUr32xf JB6wtIHT++dsP7dnac4luqfl7jqVLVdiKc5INNRiLipOBABnaSiDhwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/PpqLB81Nn8EXAuHQyqsqGMOlkkA Cc: "routing-discussion@ietf.org" , "stbryant@cisco.com" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:14:16 -0000 Hi Giles, I'm not so sure as, in my personal experience, I'll have to attend all thre= e or four WG and will be asking to make their scheduling mutually exclusive= . Regards, Greg -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Giles Heron Sent: Thursday, June 12, 2014 10:42 AM To: Loa Andersson Cc: routing-discussion@ietf.org; stbryant@cisco.com Subject: Re: big equal to inefficient ?? On 12 Jun 2014, at 18:21, Loa Andersson wrote: > Stewart, >=20 > On 2014-06-12 19:16, Stewart Bryant wrote: >> On 12/06/2014 06:16, Loa Andersson wrote: >>> Alia and Adrian, >>>=20 >>> you say: >>>=20 >>>=20 >>> 2) Split giant working groups so relevant work is done in one place >>> and there is an improved signal-to-noise ratio for participants who >>> are only interested in a slice of the current working group's work. >>>=20 >>> Exactly what metrics is the assertion that "giant working groups"=20 >>> are in-efficient based on? >>>=20 >>> /Loa >> Well, one concern is that some large working groups take two sessions=20 >> - the most allowed at a meeting, and still end up with so many drafts=20 >> to discuss they either get 5mins or less each, or not discussed. This=20 >> is not a productive way forward. >>=20 >> Now maybe the answer is to take a much firmer line on what gets=20 >> discussed at IETF, but that needs a cultural change. The problem is=20 >> that cultural changes are incredibly difficult and so far I have seen=20 >> no workable answer beyond splitting the work into smaller slices. >>=20 >> - Stewart >=20 > So if we split the wg taking two sessions into 3 or 4 groups, taking 3=20 > or 4 sessions, that is better? yes, if the total length of the sessions is the same :) in general a more focussed group is better I think as there's less risk of = people having to sit through tons of drafts they're not interested in - tho= ugh I know in MPLS you have often split the sessions so that (for example) = all the MPLS-TP drafts get grouped together. Giles > /Loa >>=20 >>=20 >>=20 >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Jun 12 11:23:12 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A321B27C7 for ; Thu, 12 Jun 2014 11:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE1y4mLrH2fc for ; Thu, 12 Jun 2014 11:23:08 -0700 (PDT) Received: from layerfree.net (heronab1.miniserver.com [77.73.2.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F091A0213 for ; Thu, 12 Jun 2014 11:23:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=173.38.208.169; Received: from [10.61.204.5] (unverified [173.38.208.169]) by layerfree.net (SurgeMail 6.5a) with ESMTP (TLS) id 531-1293857 for multiple; Thu, 12 Jun 2014 18:21:33 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: big equal to inefficient ?? From: Giles Heron In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> Date: Thu, 12 Jun 2014 19:22:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1878.2) X-Authenticated-User: giles@layerfree.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/9V5yL14cKzGX7A2uJSI5eNHNxjQ Cc: "stbryant@cisco.com" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:23:09 -0000 right - but if their total length is no longer than that of the single = WG then scheduling is no more difficult? On 12 Jun 2014, at 19:14, Gregory Mirsky = wrote: > Hi Giles, > I'm not so sure as, in my personal experience, I'll have to attend all = three or four WG and will be asking to make their scheduling mutually = exclusive. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] = On Behalf Of Giles Heron > Sent: Thursday, June 12, 2014 10:42 AM > To: Loa Andersson > Cc: routing-discussion@ietf.org; stbryant@cisco.com > Subject: Re: big equal to inefficient ?? >=20 > On 12 Jun 2014, at 18:21, Loa Andersson wrote: >=20 >> Stewart, >>=20 >> On 2014-06-12 19:16, Stewart Bryant wrote: >>> On 12/06/2014 06:16, Loa Andersson wrote: >>>> Alia and Adrian, >>>>=20 >>>> you say: >>>>=20 >>>>=20 >>>> 2) Split giant working groups so relevant work is done in one = place >>>> and there is an improved signal-to-noise ratio for participants = who >>>> are only interested in a slice of the current working group's = work. >>>>=20 >>>> Exactly what metrics is the assertion that "giant working groups"=20= >>>> are in-efficient based on? >>>>=20 >>>> /Loa >>> Well, one concern is that some large working groups take two = sessions=20 >>> - the most allowed at a meeting, and still end up with so many = drafts=20 >>> to discuss they either get 5mins or less each, or not discussed. = This=20 >>> is not a productive way forward. >>>=20 >>> Now maybe the answer is to take a much firmer line on what gets=20 >>> discussed at IETF, but that needs a cultural change. The problem is=20= >>> that cultural changes are incredibly difficult and so far I have = seen=20 >>> no workable answer beyond splitting the work into smaller slices. >>>=20 >>> - Stewart >>=20 >> So if we split the wg taking two sessions into 3 or 4 groups, taking = 3=20 >> or 4 sessions, that is better? >=20 > yes, if the total length of the sessions is the same :) >=20 > in general a more focussed group is better I think as there's less = risk of people having to sit through tons of drafts they're not = interested in - though I know in MPLS you have often split the sessions = so that (for example) all the MPLS-TP drafts get grouped together. >=20 > Giles >=20 >> /Loa >>>=20 >>>=20 >>>=20 >>=20 >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Jun 12 11:35:31 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F991B2AE6 for ; Thu, 12 Jun 2014 11:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ob73O3UyrMD for ; Thu, 12 Jun 2014 11:35:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461141B2AEB for ; Thu, 12 Jun 2014 11:35:05 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-0d-53999f8bb8b5 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4D.14.11744.B8F99935; Thu, 12 Jun 2014 14:39:39 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Thu, 12 Jun 2014 14:35:03 -0400 From: Gregory Mirsky To: Giles Heron Subject: RE: big equal to inefficient ?? Thread-Topic: big equal to inefficient ?? Thread-Index: AQHPhf1x6zUfw9te4022lC6c+0Pjc5tt+xiAgAABagCAAAXeAP//xUGwgABGHgD//7/NQA== Date: Thu, 12 Jun 2014 18:35:02 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7CD9F9@eusaamb103.ericsson.se> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> In-Reply-To: <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyuXRPgm73/JnBBjvfGVi8ueVl8W/uHGaL E0u2slmcezqH0YHFY8rvjaweS5b8ZPJYfGIFi8es6W1sASxRXDYpqTmZZalF+nYJXBmrlyxi L/gkVbHy2xP2BsYjol2MnBwSAiYSm1Y2MkPYYhIX7q1n62Lk4hASOMoosXX/U1YIZzmjxLpf 25hAqtgEjCRebOxhB7FFBFQlGub1gBUxC7QzSjzeeIIRJCEsoCHxaMF5FogiTYlZJy4yQ9hh Ere+fQMbxALU/O3oPVYQm1fAV+L+xWYmiG09TBKrW5qAEhwcnAKOErO2SYPUMAKd9/3UGrBe ZgFxiVtP5jNBnC0gsWTPeagXRCVePv7HCmErSUxaeo4Vol5HYsHuT2wQtrbEsoWvmSH2Ckqc nPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGDlKi1PLctONDDcxAuPpmASb4w7GBZ8sDzEKcDAq 8fAu0JgRLMSaWFZcmXuIUZqDRUmcd8+1qmAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjAva pzDPcRK5+cs3rnKLSJrLnDrx/RXXQ35zL21dl6ocNP/H7J83vx2oFo1P4mIwZ8w4u2fBKZfw I1+jD55O4flveZqTRerQsafrTCVWXEwPlZnmz3rsfHSozgLW1LfijzTbitJ4JrQcF7deKSy8 J3dpu6sAx75FwobbTko3md939zTaVSHfosRSnJFoqMVcVJwIAHgNdSeIAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/i55VQXEcLTAXp_RU-ga623bq8wc Cc: "stbryant@cisco.com" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:35:16 -0000 Then what we gain: Time to discuss presentations in more details - no Increased logistical complexity - yes Regards, Greg -----Original Message----- From: Giles Heron [mailto:giles@layerfree.net]=20 Sent: Thursday, June 12, 2014 11:23 AM To: Gregory Mirsky Cc: Loa Andersson; routing-discussion@ietf.org; stbryant@cisco.com Subject: Re: big equal to inefficient ?? right - but if their total length is no longer than that of the single WG t= hen scheduling is no more difficult? On 12 Jun 2014, at 19:14, Gregory Mirsky wrot= e: > Hi Giles, > I'm not so sure as, in my personal experience, I'll have to attend all th= ree or four WG and will be asking to make their scheduling mutually exclusi= ve. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org]=20 > On Behalf Of Giles Heron > Sent: Thursday, June 12, 2014 10:42 AM > To: Loa Andersson > Cc: routing-discussion@ietf.org; stbryant@cisco.com > Subject: Re: big equal to inefficient ?? >=20 > On 12 Jun 2014, at 18:21, Loa Andersson wrote: >=20 >> Stewart, >>=20 >> On 2014-06-12 19:16, Stewart Bryant wrote: >>> On 12/06/2014 06:16, Loa Andersson wrote: >>>> Alia and Adrian, >>>>=20 >>>> you say: >>>>=20 >>>>=20 >>>> 2) Split giant working groups so relevant work is done in one=20 >>>> place and there is an improved signal-to-noise ratio for=20 >>>> participants who are only interested in a slice of the current workin= g group's work. >>>>=20 >>>> Exactly what metrics is the assertion that "giant working groups"=20 >>>> are in-efficient based on? >>>>=20 >>>> /Loa >>> Well, one concern is that some large working groups take two=20 >>> sessions >>> - the most allowed at a meeting, and still end up with so many=20 >>> drafts to discuss they either get 5mins or less each, or not=20 >>> discussed. This is not a productive way forward. >>>=20 >>> Now maybe the answer is to take a much firmer line on what gets=20 >>> discussed at IETF, but that needs a cultural change. The problem is=20 >>> that cultural changes are incredibly difficult and so far I have=20 >>> seen no workable answer beyond splitting the work into smaller slices. >>>=20 >>> - Stewart >>=20 >> So if we split the wg taking two sessions into 3 or 4 groups, taking=20 >> 3 or 4 sessions, that is better? >=20 > yes, if the total length of the sessions is the same :) >=20 > in general a more focussed group is better I think as there's less risk o= f people having to sit through tons of drafts they're not interested in - t= hough I know in MPLS you have often split the sessions so that (for example= ) all the MPLS-TP drafts get grouped together. >=20 > Giles >=20 >> /Loa >>>=20 >>>=20 >>>=20 >>=20 >> -- >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Jun 12 11:36:39 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6F81B2AE5 for ; Thu, 12 Jun 2014 11:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-84aTCkP9RB for ; Thu, 12 Jun 2014 11:36:34 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4ED1B2AE3 for ; Thu, 12 Jun 2014 11:36:34 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 86FD81B806B for ; Thu, 12 Jun 2014 11:36:34 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 793E3190064; Thu, 12 Jun 2014 11:36:34 -0700 (PDT) Received: from vpna-149.vpn.nominum.com (64.89.227.149) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 11:36:34 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? From: Ted Lemon In-Reply-To: Date: Thu, 12 Jun 2014 14:36:27 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "Fedyk, Don" X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [64.89.227.149] Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/HfEB3oeGQ_70iYWM5tq1s1rkcxA Cc: "routing-discussion@ietf.org" , Stewart Bryant X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:36:36 -0000 On Jun 12, 2014, at 2:12 PM, Fedyk, Don wrote: > Well perhaps status updates is the wrong term but you usually get 5 to = 15 minutes and some extra minutes in the hallways.=20 Yup, status quo. I think Steward was questioning whether it should be. From nobody Thu Jun 12 11:41:30 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6A1B2AA0 for ; Thu, 12 Jun 2014 11:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woRpg9SWe2ok for ; Thu, 12 Jun 2014 11:41:25 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BA91A0248 for ; Thu, 12 Jun 2014 11:41:24 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so7521297wiw.10 for ; Thu, 12 Jun 2014 11:41:23 -0700 (PDT) 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; bh=69PFLEfy+jJ3baPOK8BQohoLcuaHMqfDgnoj8RVN7r4=; b=nwDtfvrtXlJQn1HJH/grcQ6sPXHDm04IrIy0ExTVUy45rI5LJHhLqs5nkrvI5OZDbO 4UyqxKFkET9HV/A5Omrth2t5g7T7ahurLem+bah1c+PXnCaBPxKCZGpZukiMRqPEwIVb PEWGhsuH0oWzasM2GTFI/DdVXIy31Esvisllzp0Vr5fzNqe8sJ6bVGECshTNtNBG8gzp p1dIkr+KoCo01PhTqmcI9MUTBdo97rJ0i8xXsKP7ah6LxsPex19bhvvm5mn+ppAAgHpn 02j1VxJt00S20vz7jlL9vWrasbO4VNKLhXNRf0NsX4yhgHmo/tYU6mwaFEbiqzbzcrce Oh7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=69PFLEfy+jJ3baPOK8BQohoLcuaHMqfDgnoj8RVN7r4=; b=RZj/e1pvhoHyvZJmxszH1DDqvQq1dNe7NnVnfPJ09rylH/sEdAfbX+MmYEwpg+AAML XKwiVzp0MqW3n68FLWDErkUT1TE4ImlpyXkFmrxXZdD31qQ6IZlYfjXp+8ZY5RCQIcdI WQjBPJD9pajPo69Wj6kpN577O16GpGnPD7LyRMrOe2scRCSqGSf/FJdxk66iipyoD8fv uNzduked+yy6Ylu8vqZLjG60ij0z0M9iDqyCapO4GqBFIWkZfxZhwIfUWEZHjcCZilZ4 M68H62+y00kD4IHODjisUBdcC0bnpqqIBqsWkSVkbYEVC81fTycxKqoRD0CBC1t1t4xi +EOQ== X-Gm-Message-State: ALoCoQkFuFsfy9PAon17E+D1jdGRqbeD5HsUflGVlUL8YqZwwQfgI7Hr1pKZa4moCKZcPZNUWMUV X-Received: by 10.194.93.228 with SMTP id cx4mr21234616wjb.61.1402598483545; Thu, 12 Jun 2014 11:41:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.5.201 with HTTP; Thu, 12 Jun 2014 11:40:43 -0700 (PDT) In-Reply-To: <050c441f39344cb4a563c650171dee76@CO2PR05MB636.namprd05.prod.outlook.com> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <050c441f39344cb4a563c650171dee76@CO2PR05MB636.namprd05.prod.outlook.com> From: Edward Crabbe Date: Thu, 12 Jun 2014 11:40:43 -0700 Message-ID: Subject: Re: big equal to inefficient ?? To: Ross Callon Content-Type: multipart/alternative; boundary=047d7bb03cfa60002c04fba7e8de Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/HV-37aN1hu2kqriXjyAk6ra-qSw Cc: "routing-discussion@ietf.org" , "stbryant@cisco.com" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:41:28 -0000 --047d7bb03cfa60002c04fba7e8de Content-Type: text/plain; charset=ISO-8859-1 I agree with Ross. It seems to me that this proposal runs the risk of either non-linearly increase the communication complexity and overhead (subgroups must coordinate with other subgroups) or result in chairs providing information conduits for subgroups (dramatically increasing chair work load and decreasing available time per subgroup as part of overall communication overhead.) It will also result in additional overload for participants as the number of SubWGs people have to attend increasing. On Thu, Jun 12, 2014 at 10:58 AM, Ross Callon wrote: > Actually, the MPLS group (which is about as big as they get, I think) has > not been quite as busy for the last two IETFs. Thus we have been able to > have more in depth discussion (which is desirable). Before that we were > pretty jammed with so many presentations that what you said did happen. > > If you split the same presentations between more WGs, it doesn't make the > week less busy. If we want to have more longer discussions and a less > overloaded week, it is probably necessary to push back on some > presentations. To me this is a matter for WG chair training -- which I > think is a very good idea even for experienced WG chairs (there is always > something that we can do better, or that we have forgotten about over the > years). > > To me the reason for splitting or combining WGs would be to make the work > fit more logically into groups, if we can come up with a split that allows > this to happen. > > I don't think that any split can be perfect. Thus there will always be > drafts which are of interest to multiple WGs, and a need to coordinate work > between WGs. However, it would be desirable if we can reduce the overlaps > by grouping work into reasonable logical pieces. How to improve this over > what we have now is not obvious to me. > > Ross > > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On > Behalf Of Stewart Bryant > Sent: Thursday, June 12, 2014 1:16 PM > To: Loa Andersson; routing-discussion@ietf.org > Subject: Re: big equal to inefficient ?? > > On 12/06/2014 06:16, Loa Andersson wrote: > > Alia and Adrian, > > > > you say: > > > > > > 2) Split giant working groups so relevant work is done in one place > > and there is an improved signal-to-noise ratio for participants who > > are only interested in a slice of the current working group's work. > > > > Exactly what metrics is the assertion that "giant working groups" are > > in-efficient based on? > > > > /Loa > Well, one concern is that some large working groups take two > sessions - the most allowed at a meeting, and still end up with so > many drafts to discuss they either get 5mins or less each, or not > discussed. This is not a productive way forward. > > Now maybe the answer is to take a much firmer line on what gets > discussed at IETF, but that needs a cultural change. The problem > is that cultural changes are incredibly difficult and so far I have > seen no workable answer beyond splitting the work into smaller > slices. > > - Stewart > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > --047d7bb03cfa60002c04fba7e8de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with Ross. =A0

It seems t= o me that this proposal runs the risk of =A0either non-linearly increase th= e communication complexity and overhead (subgroups must coordinate with oth= er subgroups) or result in chairs providing information conduits for subgro= ups (dramatically increasing chair work load and decreasing available time = per subgroup as part of overall communication overhead.) =A0It will also re= sult in additional overload for participants as the number of SubWGs people= have to attend increasing. =A0


On Thu, Jun 1= 2, 2014 at 10:58 AM, Ross Callon <rcallon@juniper.net> wro= te:
Actually, the MPLS group (which is about as = big as they get, I think) has not been quite as busy for the last two IETFs= . Thus we have been able to have more in depth discussion (which is desirab= le). Before that we were pretty jammed with so many presentations that what= you said did happen.

If you split the same presentations between more WGs, it doesn't make t= he week less busy. If we want to have more longer discussions and a less ov= erloaded week, it is probably necessary to push back on some presentations.= To me this is a matter for WG chair training -- which I think is a very go= od idea even for experienced WG chairs (there is always something that we c= an do better, or that we have forgotten about over the years).

To me the reason for splitting or combining WGs would be to make the work f= it more logically into groups, if we can come up with a split that allows t= his to happen.

I don't think that any split can be perfect. Thus there will always be = drafts which are of interest to multiple WGs, and a need to coordinate work= between WGs. However, it would be desirable if we can reduce the overlaps = by grouping work into reasonable logical pieces. How to improve this over w= hat we have now is not obvious to me.

Ross

-----Original Message-----
From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Stewart = Bryant
Sent: Thursday, June 12, 2014 1:16 PM
To: Loa Andersson; routing-d= iscussion@ietf.org
Subject: Re: big equal to inefficient ??

On 12/06/2014 06:16, Loa Andersson wrote:
> Alia and Adrian,
>
> you say:
>
>
> =A0 =A02) Split giant working groups so relevant work is done in one p= lace
> =A0 =A0and there is an improved signal-to-noise ratio for participants= who
> =A0 =A0are only interested in a slice of the current working group'= ;s work.
>
> Exactly what metrics is the assertion that "giant working groups&= quot; are
> in-efficient based on?
>
> /Loa
Well, one concern is that some large working groups take two
sessions - the most allowed at a meeting, and still end up with so
many drafts to discuss they either get 5mins or less each, or not
discussed. This is not a productive way forward.

Now maybe the answer is to take a much firmer line on what gets
discussed at IETF, but that needs a cultural change. The problem
is that cultural changes are incredibly difficult and so far I have
seen no workable answer beyond splitting the work into smaller
slices.

- Stewart



_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion
_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion

--047d7bb03cfa60002c04fba7e8de-- From nobody Thu Jun 12 11:42:20 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E4A1B2AFA for ; Thu, 12 Jun 2014 11:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVzTLAOgCkx5 for ; Thu, 12 Jun 2014 11:42:14 -0700 (PDT) Received: from layerfree.net (heronab1.miniserver.com [77.73.2.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DCA1B2AF9 for ; Thu, 12 Jun 2014 11:42:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=173.38.208.169; Received: from [10.61.204.5] (unverified [173.38.208.169]) by layerfree.net (SurgeMail 6.5a) with ESMTP (TLS) id 537-1293857 for multiple; Thu, 12 Jun 2014 18:40:40 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: big equal to inefficient ?? From: Giles Heron In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7CD9F9@eusaamb103.ericsson.se> Date: Thu, 12 Jun 2014 19:42:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <81011B12-8F48-4E38-B2DC-E1FA0CCDAA15@layerfree.net> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9F9@eusaamb103.ericsson.se> To: Gregory Mirsky X-Mailer: Apple Mail (2.1878.2) X-Authenticated-User: giles@layerfree.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/-GUJfQTIYvZwNcx2CnDEue4rdNg Cc: "stbryant@cisco.com" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:42:15 -0000 we gain that those of us who only care about one chunk of the work don't = have to go to all the meetings :) though as I mentioned before the MPLS WG have addressed that to some = extent in the past... =20 On 12 Jun 2014, at 19:35, Gregory Mirsky = wrote: > Then what we gain: > Time to discuss presentations in more details - no > Increased logistical complexity - yes >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Giles Heron [mailto:giles@layerfree.net]=20 > Sent: Thursday, June 12, 2014 11:23 AM > To: Gregory Mirsky > Cc: Loa Andersson; routing-discussion@ietf.org; stbryant@cisco.com > Subject: Re: big equal to inefficient ?? >=20 > right - but if their total length is no longer than that of the single = WG then scheduling is no more difficult? >=20 > On 12 Jun 2014, at 19:14, Gregory Mirsky = wrote: >=20 >> Hi Giles, >> I'm not so sure as, in my personal experience, I'll have to attend = all three or four WG and will be asking to make their scheduling = mutually exclusive. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org]=20= >> On Behalf Of Giles Heron >> Sent: Thursday, June 12, 2014 10:42 AM >> To: Loa Andersson >> Cc: routing-discussion@ietf.org; stbryant@cisco.com >> Subject: Re: big equal to inefficient ?? >>=20 >> On 12 Jun 2014, at 18:21, Loa Andersson wrote: >>=20 >>> Stewart, >>>=20 >>> On 2014-06-12 19:16, Stewart Bryant wrote: >>>> On 12/06/2014 06:16, Loa Andersson wrote: >>>>> Alia and Adrian, >>>>>=20 >>>>> you say: >>>>>=20 >>>>>=20 >>>>> 2) Split giant working groups so relevant work is done in one=20 >>>>> place and there is an improved signal-to-noise ratio for=20 >>>>> participants who are only interested in a slice of the current = working group's work. >>>>>=20 >>>>> Exactly what metrics is the assertion that "giant working groups"=20= >>>>> are in-efficient based on? >>>>>=20 >>>>> /Loa >>>> Well, one concern is that some large working groups take two=20 >>>> sessions >>>> - the most allowed at a meeting, and still end up with so many=20 >>>> drafts to discuss they either get 5mins or less each, or not=20 >>>> discussed. This is not a productive way forward. >>>>=20 >>>> Now maybe the answer is to take a much firmer line on what gets=20 >>>> discussed at IETF, but that needs a cultural change. The problem is=20= >>>> that cultural changes are incredibly difficult and so far I have=20 >>>> seen no workable answer beyond splitting the work into smaller = slices. >>>>=20 >>>> - Stewart >>>=20 >>> So if we split the wg taking two sessions into 3 or 4 groups, taking=20= >>> 3 or 4 sessions, that is better? >>=20 >> yes, if the total length of the sessions is the same :) >>=20 >> in general a more focussed group is better I think as there's less = risk of people having to sit through tons of drafts they're not = interested in - though I know in MPLS you have often split the sessions = so that (for example) all the MPLS-TP drafts get grouped together. >>=20 >> Giles >>=20 >>> /Loa >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>=20 >>> _______________________________________________ >>> routing-discussion mailing list >>> routing-discussion@ietf.org >>> https://www.ietf.org/mailman/listinfo/routing-discussion >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >=20 From nobody Thu Jun 12 11:43:22 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC01A0241 for ; Thu, 12 Jun 2014 11:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9P0nmYwGT1hv for ; Thu, 12 Jun 2014 11:43:18 -0700 (PDT) Received: from g5t1625.atlanta.hp.com (g5t1625.atlanta.hp.com [15.192.137.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A335B1A00E9 for ; Thu, 12 Jun 2014 11:43:18 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t1625.atlanta.hp.com (Postfix) with ESMTPS id DFCA4260; Thu, 12 Jun 2014 18:43:17 +0000 (UTC) Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 12 Jun 2014 18:41:28 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.232]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.03.0169.001; Thu, 12 Jun 2014 18:41:28 +0000 From: "Fedyk, Don" To: Ted Lemon Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTgAAiZYAAAAHBcAAAOkJgAAACZQQ Date: Thu, 12 Jun 2014 18:41:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.201.12.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/yJXuLH9HLy6sluWrM8riRFdmqyc Cc: "routing-discussion@ietf.org" , Stewart Bryant X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:43:20 -0000 That's not to say that there cannot be reorganization but separate the prob= lem: Organization of WGs: where work gets done. (has to fit the plenary meeting = schedule) Where a large WG does its work. (lists, Meetings, Teleconf etc.) Cheers, Don=20 -----Original Message----- From: Ted Lemon [mailto:ted.lemon@nominum.com]=20 Sent: Thursday, June 12, 2014 2:36 PM To: Fedyk, Don Cc: Stewart Bryant; routing-discussion@ietf.org Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? On Jun 12, 2014, at 2:12 PM, Fedyk, Don wrote: > Well perhaps status updates is the wrong term but you usually get 5 to 15= minutes and some extra minutes in the hallways.=20 Yup, status quo. I think Steward was questioning whether it should be. From nobody Thu Jun 12 11:53:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEF41A0241 for ; Thu, 12 Jun 2014 11:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGlx42-KsRxI for ; Thu, 12 Jun 2014 11:53:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 923701A0236 for ; Thu, 12 Jun 2014 11:53:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 39BB2C1FC; Thu, 12 Jun 2014 14:53:13 -0400 (EDT) Date: Thu, 12 Jun 2014 14:53:13 -0400 From: Jeffrey Haas To: Stewart Bryant Subject: Re: big equal to inefficient ?? Message-ID: <20140612185313.GA4233@pfrc> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5399E05D.20506@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/POsVngzvfl6Z-GhGBu4zMfX4Bnw Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 18:53:15 -0000 On Thu, Jun 12, 2014 at 06:16:13PM +0100, Stewart Bryant wrote: > Well, one concern is that some large working groups take two > sessions - the most allowed at a meeting, and still end up with so > many drafts to discuss they either get 5mins or less each, or not > discussed. This is not a productive way forward. > > Now maybe the answer is to take a much firmer line on what gets > discussed at IETF, but that needs a cultural change. The problem > is that cultural changes are incredibly difficult and so far I have > seen no workable answer beyond splitting the work into smaller > slices. We already dedicated some plenary time in trying to reduce unnecessary meetings and presentations. That session should probably be dug up and a link posted to the video so we can try to take it more to heart. Thought experiment (probably proving I've been poisoned by excess exposure to management): Metrics are usually what is needed to figure out how effective something is. In the case of WG sessions, I think the desired metrics are probably a nice constrained set. - Was the overall session productive? - On a per-presentation basis, was the material: + Informative + Necessary to present? + Generated good discussion at the meeting - even if not the session? Is there anything in our organizational policies preventing individual WGs from gathering these metrics? -- Jeff From nobody Thu Jun 12 12:03:13 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6601B27D2 for ; Thu, 12 Jun 2014 12:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHOOVr341-wN for ; Thu, 12 Jun 2014 12:03:09 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACB21A0236 for ; Thu, 12 Jun 2014 12:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=690; q=dns/txt; s=iport; t=1402599790; x=1403809390; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2DJCArQFgw+mLpHzFq9kbVlvTZCb6mrsjLfUlFmNAZk=; b=RfO3Kt5Nq+ipHY7W0cQpudUezE29Amrimqha5bDIByAhRjLKKJXbizUV WOSgPNyz9rwgKZMpgXOcLsQdvEm/yO57um6SSO1pJZFHCTORiA84qgJ9f yNTN4aLrg4a39Z09mrwp3qq+deOkR9VtSyz0wAkJxBsV0OzeOfegM3nQy A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAA/4mVOtJssW/2dsb2JhbABargcBAQEBAQEFAZkeAYEhdYQEAQEEDiotBg0BEAsOExYPCQMCAQIBRQYBDAEHAQGIPrk0mR8XhVyIJ1gHhEEBA5oyk1KDPYFs X-IronPort-AV: E=Sophos;i="5.01,466,1400025600"; d="scan'208";a="79272526" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 12 Jun 2014 19:03:08 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5CJ37se027893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 19:03:07 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s5CJ34So016813; Thu, 12 Jun 2014 20:03:05 +0100 (BST) Message-ID: <5399F968.4080406@cisco.com> Date: Thu, 12 Jun 2014 20:03:04 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Edward Crabbe , Ross Callon Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <050c441f39344cb4a563c650171dee76@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/LkD_joz9XQGQO6l7ven_nNoZLWE Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 19:03:11 -0000 There is a spectrum that runs from one single WG for the whole of RTG, through to something much close to one WG one draft. The former allows optimum cross interest co-ordination, the latter focus on detailed topic of interest to a few subject matter experts. Clearly both are models are ridiculous. The problem that Adrian and I grappled with for a long time, and that Adrian and Alia are trying to work through here, is what is the optimum structure of the RTG Area in 2014 and forward? Is it status quo? If not what structure gives us the right balance between co-ordination, agility and focus and makes optium use of the very limited resources we have? - Stewart From nobody Thu Jun 12 12:14:04 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E478E1B2800 for ; Thu, 12 Jun 2014 12:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw0gqNd0qTUl for ; Thu, 12 Jun 2014 12:13:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305571B27F6 for ; Thu, 12 Jun 2014 12:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1392; q=dns/txt; s=iport; t=1402600437; x=1403810037; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=s9b/bBz3Bv3g3ClUEWay1t8I5pk2gZ90UeozMEKONZ4=; b=h/39Kh9beWt7tKEqAE0h87CD3Ht8S5hVwJLfE/HTSUxbncegmDdx6sq5 HiGLrcxis4z3vpJGyAeXtM/cXzZXckq45J1rvLxfH6giCFhf1krCZS8Fm tPm5TWgzW594gdeu53I6rHacce5HiSmAarjnKDpExPyNgJ5BByn5Fr5Ex A=; X-IronPort-AV: E=Sophos;i="5.01,466,1400025600"; d="scan'208";a="332489355" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jun 2014 19:13:56 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5CJDuPi003465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2014 19:13:56 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s5CJDnDS016614; Thu, 12 Jun 2014 12:13:54 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s5CJDlBI016612; Thu, 12 Jun 2014 12:13:47 -0700 Date: Thu, 12 Jun 2014 12:13:47 -0700 From: Toerless Eckert To: Stewart Bryant Subject: Re: big equal to inefficient ?? Message-ID: <20140612191347.GP11315@cisco.com> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5399E05D.20506@cisco.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/uCzVPTXh-44Wl4Rzr0zj-JEH8v4 Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 19:14:03 -0000 I am a fan of good tools. I think it would be cool if there wa a web page a few weeks before the IETF with for each WG the list of possible drafts, and letting me click which ones i am interested in. Would IMHO help to improve of ther current judgement method applied by WG chairs to decide what to take on to the agenda. On Thu, Jun 12, 2014 at 06:16:13PM +0100, Stewart Bryant wrote: > On 12/06/2014 06:16, Loa Andersson wrote: > >Alia and Adrian, > > > >you say: > > > > > > 2) Split giant working groups so relevant work is done in one place > > and there is an improved signal-to-noise ratio for participants who > > are only interested in a slice of the current working group's work. > > > >Exactly what metrics is the assertion that "giant working groups" are > >in-efficient based on? > > > >/Loa > Well, one concern is that some large working groups take two > sessions - the most allowed at a meeting, and still end up with so > many drafts to discuss they either get 5mins or less each, or not > discussed. This is not a productive way forward. > > Now maybe the answer is to take a much firmer line on what gets > discussed at IETF, but that needs a cultural change. The problem > is that cultural changes are incredibly difficult and so far I have > seen no workable answer beyond splitting the work into smaller > slices. > > - Stewart From nobody Thu Jun 12 15:27:29 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF5C1A028A for ; Thu, 12 Jun 2014 15:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM1T2pg_KhIx for ; Thu, 12 Jun 2014 15:27:26 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 8D36F1A0271 for ; Thu, 12 Jun 2014 15:27:26 -0700 (PDT) Received: (qmail 15368 invoked by uid 0); 13 Jun 2014 04:27:23 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 13 Jun 2014 04:27:23 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id DaTK1o0072SSUrH01aTNv3; Thu, 12 Jun 2014 16:27:23 -0600 X-Authority-Analysis: v=2.1 cv=Q9RBveGa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=C8UVKu96udcA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=wI9aDKlK2hPdkFh_geoA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=40OXWAlNB1l49MXmnOlI4cFgUyvxw8iBWol39Xe+WXY=; b=SewRkxgoWicS0itQYHArPoXW2aaOVSSgQzew7Y2y+enNIdaLz8PPrbN9z3jyjRivpbhf6XXVfwtu9LhRI23vYo7fjPTEdAptuOxjMQuiANU82lmJmSeCldJ+HI5DVlRg; Received: from box313.bluehost.com ([69.89.31.113]:45768 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1WvDSq-00060s-0L; Thu, 12 Jun 2014 16:27:20 -0600 Message-ID: <539A293F.6030807@labn.net> Date: Thu, 12 Jun 2014 18:27:11 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <050c441f39344cb4a563c650171dee76@CO2PR05MB636.namprd05.prod.outlook.com> <5399F968.4080406@cisco.com> In-Reply-To: <5399F968.4080406@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/TObktMs_utX8ErvLrlGEbRKNVz4 Cc: Ross Callon , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:27:28 -0000 I agree with the points made by Ed and Ross. I'm particularly concerned with the potential for the standardization of duplicative mechanisms that could (and have) occurred without the type of communication mentioned by Ed. Consider a concrete case: If rsvp-te and cr-ldp had been in two WGs, would rfc3468 been possible? I think not, and I think we would have a (more) fragmented market and O(2n) the load standardizing parallel extensions. Also a couple of additional points on the 5 minute / draft issue: - I've often seen this problem result from a desire to let all who request a slot get one. While this may have once been some WG's practice and to some degree part of the IETF culture , I think this approach died under it's own weight and now generally some discussion on the list and anticipated discussion in session is required -- and this has helped provide more time for substantive discussion. - One on going demand for WG time in some of the "big*" groups are individual drafts that are looking for a home. I think the "big" group I co-chair generally sends the equivalent of 1 session on such drafts. I think the idea mentioned in Alia's and Adrian mail of a RTG Area Dispatch WG might help here. Now that said, there is the very real risk that all RTG WGs will want to deconflict with this 2nd RTG Area wide session, and there is still an additional session for discussing new work. So, perhaps we should also go with Eckert's idea of polling for session time at least for new WGs (maybe we'll try this for CCAMP in Toronto...) Lou (*) I'll send some metrics on size in another message. On 6/12/2014 3:03 PM, Stewart Bryant wrote: > There is a spectrum that runs from one single WG > for the whole of RTG, through to something much close to > one WG one draft. The former allows optimum cross interest > co-ordination, the latter focus on detailed topic of interest > to a few subject matter experts. > > Clearly both are models are ridiculous. > > The problem that Adrian and I grappled with for > a long time, and that Adrian and Alia are trying to > work through here, is what is the optimum structure > of the RTG Area in 2014 and forward? > > Is it status quo? If not what structure gives us the right > balance between co-ordination, agility and focus and > makes optium use of the very limited resources we > have? > > - Stewart > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Thu Jun 12 15:40:07 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264CB1A029B for ; Thu, 12 Jun 2014 15:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoovG74eaTaZ for ; Thu, 12 Jun 2014 15:40:04 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 30D081A015F for ; Thu, 12 Jun 2014 15:40:04 -0700 (PDT) Received: (qmail 14405 invoked by uid 0); 12 Jun 2014 22:40:03 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 12 Jun 2014 22:40:03 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Dafy1o00K2SSUrH01ag1Sf; Thu, 12 Jun 2014 16:40:03 -0600 X-Authority-Analysis: v=2.1 cv=d4pml3TE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=C8UVKu96udcA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=Vc86tT525mA3trSBEbsA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=KAMTHYGXBYsFcvZV5JwodhwI0HWV3GvaCW3vdrGphm4=; b=eip0jbJYoumApUTSwgHyCeRoFwERdgA76q3eiyIU14uBsukgGKOIjePMDyr2lhFf4x9u4LoW6T32cJW/ikad5SXlvYJsGHEsiSb/MwPGNdoMPgpA/3VjdnIxIARBj4P9; Received: from box313.bluehost.com ([69.89.31.113]:47361 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1WvDf4-0002Fx-3m; Thu, 12 Jun 2014 16:39:58 -0600 Message-ID: <539A2C36.2030907@labn.net> Date: Thu, 12 Jun 2014 18:39:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "routing-discussion@ietf.org" Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> In-Reply-To: <53993792.3050902@pi.nu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/y1KjljmyBmJXOFKrXhlkxAF3Nuc X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 22:40:06 -0000 Alia and Adrian, Can you identify which "giant working groups" you are considering splitting? You said the objective of this item is: an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. I think it's really interesting that you are focusing on improving signal-to-noise ratio for *participants*. In the WG (which may be in your giant list) I co-chair, we try to chunk topics in meeting sessions to allow those contributing to just a part of the WGs activities can decide which session to attend. (If wondering why we generally have two sessions, see my previous mail on this subject.) Of course, many participants are interested in most topics and attend the WG's typical two sessions. We also avoid the potential duplication of mechanisms mentioned in my previous mail on this topic as well as the added communication/coordination, mentioned by Ed, that would be needed if these two sessions were different WGs... Thanks, Lou PS For those who like metrics, here's some data from the last 25 meetings Per wg breakdown, alphabetized: bfd Total Sessions: 5 Met 1x: 5 ccamp Total Sessions: 49 Met 1x: 3 Met 2x: 20 Met 3x: 2 forces Total Sessions: 23 Met 1x: 23 i2rs Total Sessions: 4 Met 1x: 4 idr Total Sessions: 26 Met 1x: 24 Met 2x: 1 irs Total Sessions: 1 Met 1x: 1 isis Total Sessions: 21 Met 1x: 21 karp Total Sessions: 15 Met 1x: 15 l1vpn Total Sessions: 4 Met 1x: 4 l2vpn Total Sessions: 28 Met 1x: 20 Met 2x: 4 l3vpn Total Sessions: 24 Met 1x: 20 Met 2x: 2 manet Total Sessions: 27 Met 1x: 23 Met 2x: 2 mpls Total Sessions: 49 Met 1x: 7 Met 2x: 12 Met 3x: 6 nsc Total Sessions: 1 Met 1x: 1 nvo3 Total Sessions: 9 Met 1x: 5 Met 2x: 2 ospf Total Sessions: 23 Met 1x: 19 Met 2x: 2 pce Total Sessions: 27 Met 1x: 23 Met 2x: 2 pim Total Sessions: 27 Met 1x: 23 Met 2x: 2 pwe3 Total Sessions: 30 Met 1x: 20 Met 2x: 5 rl2n Total Sessions: 1 Met 1x: 1 roll Total Sessions: 22 Met 1x: 12 Met 2x: 5 rpsec Total Sessions: 4 Met 1x: 4 rtgarea Total Sessions: 28 Met 1x: 22 Met 2x: 3 rtgwg Total Sessions: 23 Met 1x: 19 Met 2x: 2 sdn Total Sessions: 1 Met 1x: 1 sfc Total Sessions: 2 Met 1x: 2 sidr Total Sessions: 34 Met 1x: 19 Met 2x: 3 Met 3x: 3 spring Total Sessions: 2 Met 1x: 2 status Total Sessions: 1 Met 1x: 1 On 6/12/2014 1:16 AM, Loa Andersson wrote: > Alia and Adrian, > > you say: > > > 2) Split giant working groups so relevant work is done in one place > and there is an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. > > Exactly what metrics is the assertion that "giant working groups" are > in-efficient based on? > > /Loa From nobody Thu Jun 12 16:05:40 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5801A03A7 for ; Thu, 12 Jun 2014 16:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe0YLMBv7IzE for ; Thu, 12 Jun 2014 16:05:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4FF1A030F for ; Thu, 12 Jun 2014 16:05:12 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5CN5Aiq027623; Fri, 13 Jun 2014 00:05:10 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5CN59d8027617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 00:05:09 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , References: <53993792.3050902@pi.nu> <539A2C36.2030907@labn.net> In-Reply-To: <539A2C36.2030907@labn.net> Subject: RE: big equal to inefficient ?? Date: Fri, 13 Jun 2014 00:05:05 +0100 Message-ID: <054701cf8692$c05029e0$40f07da0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ49XGl5BHz38NpjlBR+RczDMF60wDv+6A5mhO1iaA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20754.003 X-TM-AS-Result: No--9.382-10.0-31-10 X-imss-scan-details: No--9.382-10.0-31-10 X-TMASE-MatchedRID: rYpa/RC+czFi8tNcpebA1hJmPIoQFzZ7X6IRwqkp2m6KXhy9oEl66oP+ YDa/Dhu933p0dwA/N2Qbeq8jPqXwbrnuANUvLzt6VtZNMIeE5PFQLEPuT4LD+Xgml3cPSEldPNZ otZu3jXmvz1dNKTLOZRvcJhk9n4ALq9LRDpYP/jP47K+eCXPAhfTWKs29qDlrVz8J52OVy+SM82 3SqBkeEmfLiqxDswdTS0aY/Qt01zW7JfBr9Xl5CvmF8IFnUmgvKx5ICGp/WtGWGpM90g5V9LmdM 1aLrFCB2ZSBjm5nrHmaIFoVcP3bwdt1WGHYVkBE0Xw0ILvo/uUd+GV/0bmoXYYQveKV5AcTx7gH risWqQ1SFmHeCaa+hMzVnE1oQDqosL7meEdr9ow2WQDmLqSM2spSHbAuVFq+tXl9IxEPXOrRLHH tqtWAcVaqcvzh/M3aDSrurHRS2LmEviVSg75vXxA0LjlGWpxL/1vXbkGjWeXbKtH+eq4g3lu+8P iLRt0yQlw9ktfYJT3dfTrGvdaXw6XgCCul34T6ngIgpj8eDcCV8bCk1I9Wfr6qvLNjDYTwfY9hs M0xN70qtq5d3cxkNWOyIFxsyFI0rAQLEklzhTBddCE2eKJ22/Xt3AZuc43F1S0nn1O/0/Q= Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/zxG-F-dpid1aazRpT8iAw677Fgk X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 23:05:29 -0000 Replying to Lou's post at the top of my pile, but general comments on this discussion as well. > Can you identify which "giant working groups" you are considering splitting? Absolutely not! :-) Actually, we have many thoughts and ideas, but we are deliberately soliciting opinions and winkling stuff out of all of you. After a slow start you have all really got going and I am learning some useful things and being reminded of others. > You said the objective of this item is: > > an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. Yes, and here i want to pounce on Loa's question. | Exactly what metrics is the assertion that "giant working | groups" are in-efficient based on? It's a good question, but one that Loa has to answer because the suggestion of inefficiency is one that he brought in (it's not in the original email from Alia and me). What I am interested in is whether people are sitting through meeting time waiting for one draft to come up. Perhaps they are OK with this (it's warm, except where the aircon is too assertive, and there is wifi). When I look out at a meeting (I often get up to do exactly that) I sometimes see 50% of eyes raised and sometimes less than 20%. What could be the cause? Maybe most people attending WG meetings are tourists. They are at the IETF for webrtc, and they just popped into PIM in case something exciting happens. But there are splits and splits. The GMPLS variants of CR-LDP and RSVP-TE were done in the same WG, but this work was split out of MPLS (where it was started). Did that mean that RSVP-TE implementers had to go to two WGs? Yes. Did it mean that packet heads did not need to sit through hours of discussion of how to switch lambdas? Yes. So for me this is about functional grouping to get the right people in the room for the right work. I worry that if I answer the question I will discover that, since I have to attend as many routing area meetings as possible, we should only have one WG :-) > I think it's really interesting that you are focusing on improving > signal-to-noise ratio for *participants*. In the WG (which may be in > your giant list) I co-chair, we try to chunk topics in meeting sessions > to allow those contributing to just a part of the WGs activities can > decide which session to attend. (If wondering why we generally have two > sessions, see my previous mail on this subject.) Of course, many > participants are interested in most topics and attend the WG's typical > two sessions. We also avoid the potential duplication of mechanisms > mentioned in my previous mail on this topic as well as the added > communication/coordination, mentioned by Ed, that would be needed if > these two sessions were different WGs... It's a good example because CCAMP meetings no longer absorb two big slots. And, instead of asking for just one 2.5 hour slot, the two smaller slots achieve this chunking and allow people who don't care about OTN, etc. to go for coffee. It's hard to say where the line is drawn for "functional grouping" which we are seeking and "forcing additional coordination and communication". At one extreme we might decide to put IDR, L3VPN, L2VPN, SIDR... into one WG because that way we don't need cross-communication on BGP (and there have been some fumbles :-). On the other extreme we might say that CCAMP could split into TE related work, packet work, and non-packet work (THESE ARE JUST EXAMPLES FOR ILLUSTRATIVE PURPOSES AND ARE NOT EVEN STRAW MEN!) So, continue to discuss! Come up with ideas about what could be grouped together, regrouped, and split. And say why that would be good or bad. This is really helping me. Please continue. Adrian From nobody Thu Jun 12 21:32:34 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89B11A0552 for ; Thu, 12 Jun 2014 21:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 606QHvVJT3_t for ; Thu, 12 Jun 2014 21:32:31 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C982A1B28A1 for ; Thu, 12 Jun 2014 21:32:30 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 37CC118013E2; Fri, 13 Jun 2014 06:32:27 +0200 (CEST) Message-ID: <539A7ED7.1050401@pi.nu> Date: Fri, 13 Jun 2014 06:32:23 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Lou Berger' , routing-discussion@ietf.org Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <539A2C36.2030907@labn.net> <054701cf8692$c05029e0$40f07da0$@olddog.co.uk> In-Reply-To: <054701cf8692$c05029e0$40f07da0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/r09x0owplEZBwxru5vX-XhTD8YM X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:32:33 -0000 Adrian, On 2014-06-13 01:05, Adrian Farrel wrote: >> You said the objective of this item is: >> > >> > an improved signal-to-noise ratio for participants who >> > are only interested in a slice of the current working group's work. > Yes, and here i want to pounce on Loa's question. > > | Exactly what metrics is the assertion that "giant working > | groups" are in-efficient based on? > > It's a good question, but one that Loa has to answer because the suggestion of > inefficiency is one that he brought in (it's not in the original email from Alia > and me). > > What I am interested in is whether people are sitting through meeting time > waiting for one draft to come up. Perhaps they are OK with this (it's warm, > except where the aircon is too assertive, and there is wifi). When I look out at > a meeting (I often get up to do exactly that) I sometimes see 50% of eyes raised > and sometimes less than 20%. What could be the cause? What you said was: 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. I kind of translated bad "signal-to-noise ratio" to "inefficient" and I guess that a rather large percentage of people commenting on my mail understood that. So to rephrase: Exactly what metrics is the assertion that "giant working groups" have a bad signal-to-noise ratio based on? Sometimes I've been sitting through wg's (small or large) where I'm only interested in one draft. What quite ofteh happens listening to the "noise" is that I find something interesting where I can potentially contribute. This is a synergy that we may re-organize away. You also say that you keep watching how big portion of the participants pay attention (I have to admit that I try to do that also). From what I see I've no basis to say that the portion of participants appearing to pay attention is bigger or smaller in large or small working groups. Please note: I'm not saying that we should not re-organize, but I've so far not found THE principle according to which we can re-organize the entire area. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 12 21:39:56 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362141B28B0 for ; Thu, 12 Jun 2014 21:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fadIE1cey5n3 for ; Thu, 12 Jun 2014 21:39:43 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C261B28AE for ; Thu, 12 Jun 2014 21:39:43 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 77A2718013E2; Fri, 13 Jun 2014 06:39:40 +0200 (CEST) Message-ID: <539A8088.1090302@pi.nu> Date: Fri, 13 Jun 2014 06:39:36 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Giles Heron Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> In-Reply-To: <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/JtZd_7w-4fJTkC3tdAK_6ZYodNA Cc: "routing-discussion@ietf.org" , "stbryant@cisco.com" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:39:49 -0000 Giles, You are right if a 1 to 3 split, result in three 1 hour meetings instead of one 2.5 hour meeting. Only that I doubt i works that way. Mr Parkinson did look at this back in the mid 1950-ies. I think it is likely that we end up with in the order of 4.5 hours of meeting time. /Loa On 2014-06-12 20:22, Giles Heron wrote: > right - but if their total length is no longer than that of the single WG then scheduling is no more difficult? > > On 12 Jun 2014, at 19:14, Gregory Mirsky wrote: > >> Hi Giles, >> I'm not so sure as, in my personal experience, I'll have to attend all three or four WG and will be asking to make their scheduling mutually exclusive. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Giles Heron >> Sent: Thursday, June 12, 2014 10:42 AM >> To: Loa Andersson >> Cc: routing-discussion@ietf.org; stbryant@cisco.com >> Subject: Re: big equal to inefficient ?? >> >> On 12 Jun 2014, at 18:21, Loa Andersson wrote: >> >>> Stewart, >>> >>> On 2014-06-12 19:16, Stewart Bryant wrote: >>>> On 12/06/2014 06:16, Loa Andersson wrote: >>>>> Alia and Adrian, >>>>> >>>>> you say: >>>>> >>>>> >>>>> 2) Split giant working groups so relevant work is done in one place >>>>> and there is an improved signal-to-noise ratio for participants who >>>>> are only interested in a slice of the current working group's work. >>>>> >>>>> Exactly what metrics is the assertion that "giant working groups" >>>>> are in-efficient based on? >>>>> >>>>> /Loa >>>> Well, one concern is that some large working groups take two sessions >>>> - the most allowed at a meeting, and still end up with so many drafts >>>> to discuss they either get 5mins or less each, or not discussed. This >>>> is not a productive way forward. >>>> >>>> Now maybe the answer is to take a much firmer line on what gets >>>> discussed at IETF, but that needs a cultural change. The problem is >>>> that cultural changes are incredibly difficult and so far I have seen >>>> no workable answer beyond splitting the work into smaller slices. >>>> >>>> - Stewart >>> >>> So if we split the wg taking two sessions into 3 or 4 groups, taking 3 >>> or 4 sessions, that is better? >> >> yes, if the total length of the sessions is the same :) >> >> in general a more focussed group is better I think as there's less risk of people having to sit through tons of drafts they're not interested in - though I know in MPLS you have often split the sessions so that (for example) all the MPLS-TP drafts get grouped together. >> >> Giles >> >>> /Loa >>>> >>>> >>>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa@mail01.huawei.com >>> Senior MPLS Expert loa@pi.nu >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>> >>> _______________________________________________ >>> routing-discussion mailing list >>> routing-discussion@ietf.org >>> https://www.ietf.org/mailman/listinfo/routing-discussion >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 12 21:47:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B771B28B1 for ; Thu, 12 Jun 2014 21:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSjLcfnaF3Mr for ; Thu, 12 Jun 2014 21:47:13 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CDC1B28A7 for ; Thu, 12 Jun 2014 21:47:12 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id b6so1735023yha.26 for ; Thu, 12 Jun 2014 21:47:12 -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=KsgS1Jg50yE54JK3ASQyL4aGSDpnmXMX/iZ3etAbNto=; b=TQ/hjIImgo18wr2NRNdyh6bzR89L7ULk3zLOkI7MPnJ6tfVPAARB5Xd+S8HLeUgxIq /yxdYDTnnpqMbTjgt/5syjSVd/fNzJuZ6RurRB+BBfiNupLcuwVyQkt8E5Luw3lvfIDW lqmupBzpiXtUB0rRzNJvwUkwgydPUvv4swSLcaRiE60ionP/jUmVkbq0YJPKmlx3Ozu7 ny2yzV++vgnXw3eHat8qGwM9uWkmChZ+Omi11wzVYeN1VX3fxw0CFBPCfFYucnUoBKvT fuqzlGTFyEJMSzZC+GN0oKDcTZXUbWThpMMUMPwyLOaULUdvcLagWiildGiNlrdoX2Tz KHeQ== MIME-Version: 1.0 X-Received: by 10.236.72.70 with SMTP id s46mr364456yhd.145.1402634831856; Thu, 12 Jun 2014 21:47:11 -0700 (PDT) Received: by 10.170.52.75 with HTTP; Thu, 12 Jun 2014 21:47:11 -0700 (PDT) In-Reply-To: <539A8088.1090302@pi.nu> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> Date: Fri, 13 Jun 2014 00:47:11 -0400 Message-ID: Subject: Re: big equal to inefficient ?? From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf300514bee70bff04fbb05ed6 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/TPD8l0Ihtp1N397p7aKGRi6YuJU Cc: "routing-discussion@ietf.org" , "stbryant@cisco.com" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:47:15 -0000 --20cf300514bee70bff04fbb05ed6 Content-Type: text/plain; charset=UTF-8 It sounds as if you are measuring efficiency by meeting time. Shouldn't quality of drafts, discussion, and review come in? The IETF's goal is good open standards, not meetings. Alia On Fri, Jun 13, 2014 at 12:39 AM, Loa Andersson wrote: > Giles, > > You are right if a 1 to 3 split, result in three 1 hour meetings > instead of one 2.5 hour meeting. > > Only that I doubt i works that way. Mr Parkinson did look at this > back in the mid 1950-ies. > > I think it is likely that we end up with in the order of 4.5 hours of > meeting time. > > /Loa > > > > > On 2014-06-12 20:22, Giles Heron wrote: > >> right - but if their total length is no longer than that of the single WG >> then scheduling is no more difficult? >> >> On 12 Jun 2014, at 19:14, Gregory Mirsky >> wrote: >> >> Hi Giles, >>> I'm not so sure as, in my personal experience, I'll have to attend all >>> three or four WG and will be asking to make their scheduling mutually >>> exclusive. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] >>> On Behalf Of Giles Heron >>> Sent: Thursday, June 12, 2014 10:42 AM >>> To: Loa Andersson >>> Cc: routing-discussion@ietf.org; stbryant@cisco.com >>> Subject: Re: big equal to inefficient ?? >>> >>> On 12 Jun 2014, at 18:21, Loa Andersson wrote: >>> >>> Stewart, >>>> >>>> On 2014-06-12 19:16, Stewart Bryant wrote: >>>> >>>>> On 12/06/2014 06:16, Loa Andersson wrote: >>>>> >>>>>> Alia and Adrian, >>>>>> >>>>>> you say: >>>>>> >>>>>> >>>>>> 2) Split giant working groups so relevant work is done in one place >>>>>> and there is an improved signal-to-noise ratio for participants who >>>>>> are only interested in a slice of the current working group's work. >>>>>> >>>>>> Exactly what metrics is the assertion that "giant working groups" >>>>>> are in-efficient based on? >>>>>> >>>>>> /Loa >>>>>> >>>>> Well, one concern is that some large working groups take two sessions >>>>> - the most allowed at a meeting, and still end up with so many drafts >>>>> to discuss they either get 5mins or less each, or not discussed. This >>>>> is not a productive way forward. >>>>> >>>>> Now maybe the answer is to take a much firmer line on what gets >>>>> discussed at IETF, but that needs a cultural change. The problem is >>>>> that cultural changes are incredibly difficult and so far I have seen >>>>> no workable answer beyond splitting the work into smaller slices. >>>>> >>>>> - Stewart >>>>> >>>> >>>> So if we split the wg taking two sessions into 3 or 4 groups, taking 3 >>>> or 4 sessions, that is better? >>>> >>> >>> yes, if the total length of the sessions is the same :) >>> >>> in general a more focussed group is better I think as there's less risk >>> of people having to sit through tons of drafts they're not interested in - >>> though I know in MPLS you have often split the sessions so that (for >>> example) all the MPLS-TP drafts get grouped together. >>> >>> Giles >>> >>> /Loa >>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa@mail01.huawei.com >>>> Senior MPLS Expert loa@pi.nu >>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>> >>>> _______________________________________________ >>>> routing-discussion mailing list >>>> routing-discussion@ietf.org >>>> https://www.ietf.org/mailman/listinfo/routing-discussion >>>> >>> >>> _______________________________________________ >>> routing-discussion mailing list >>> routing-discussion@ietf.org >>> https://www.ietf.org/mailman/listinfo/routing-discussion >>> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > --20cf300514bee70bff04fbb05ed6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It sounds as if you are measuring efficiency by meeting ti= me.
Shouldn't quality of drafts, discussion, and review come in?
The IETF's goal is good open standards, not meetings.

Alia


On Fri, Jun 13, 2014 at 12:39 AM, Loa Andersson <loa@pi.nu&g= t; wrote:
Giles,

You are right if a 1 to 3 split, result in three 1 hour meetings
instead of one 2.5 hour meeting.

Only that I doubt i works that way. Mr Parkinson did look at this
back in the mid 1950-ies.

I think it is likely that we end up with in the order of 4.5 hours of
meeting time.

/Loa




On 2014-06-12 20:22, Giles Heron wrote:
right - but if their total length is no longer than that of the single WG t= hen scheduling is no more difficult?

On 12 Jun 2014, at 19:14, Gregory Mirsky <gregory.mirsky@ericsson.com> wrot= e:

Hi Giles,
I'm not so sure as, in my personal experience, I'll have to attend = all three or four WG and will be asking to make their scheduling mutually e= xclusive.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Greg

-----Original Message-----
From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Giles Heron
Sent: Thursday, June 12, 2014 10:42 AM
To: Loa Andersson
Cc: routin= g-discussion@ietf.org; stbryant@cisco.com
Subject: Re: big equal to inefficient ??

On 12 Jun 2014, at 18:21, Loa Andersson <loa@pi.nu> wrote:

Stewart,

On 2014-06-12 19:16, Stewart Bryant wrote:
On 12/06/2014 06:16, Loa Andersson wrote:
Alia and Adrian,

you say:


=C2=A0 2) Split giant working groups so relevant work is done in one place<= br> =C2=A0 and there is an improved signal-to-noise ratio for participants who<= br> =C2=A0 are only interested in a slice of the current working group's wo= rk.

Exactly what metrics is the assertion that "giant working groups"=
are in-efficient based on?

/Loa
Well, one concern is that some large working groups take two sessions
- the most allowed at a meeting, and still end up with so many drafts
to discuss they either get 5mins or less each, or not discussed. This
is not a productive way forward.

Now maybe the answer is to take a much firmer line on what gets
discussed at IETF, but that needs a cultural change. The problem is
that cultural changes are incredibly difficult and so far I have seen
no workable answer beyond splitting the work into smaller slices.

- Stewart

So if we split the wg taking two sessions into 3 or 4 groups, taking 3
or 4 sessions, that is better?

yes, if the total length of the sessions is the same :)

in general a more focussed group is better I think as there's less risk= of people having to sit through tons of drafts they're not interested = in - though I know in MPLS you have often split the sessions so that (for e= xample) all the MPLS-TP drafts get grouped together.

Giles

/Loa




--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64

_______________________________________________
routing-discussion mailing list
routing-di= scussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=

_______________________________________________
routing-discussion mailing list
routing-di= scussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=


--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64

_______________________________________________
routing-discussion mailing list
routing-di= scussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=

--20cf300514bee70bff04fbb05ed6-- From nobody Thu Jun 12 21:53:17 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA531B28B8 for ; Thu, 12 Jun 2014 21:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnKgnO_ZWCH8 for ; Thu, 12 Jun 2014 21:53:04 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9251B28B6 for ; Thu, 12 Jun 2014 21:53:03 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 0D56E18013E2; Fri, 13 Jun 2014 06:53:00 +0200 (CEST) Message-ID: <539A83A8.2060402@pi.nu> Date: Fri, 13 Jun 2014 06:52:56 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alia Atlas Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/KKE09EBaQqCNmNf4ohBE8VGNp9U Cc: "routing-discussion@ietf.org" , "stbryant@cisco.com" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:53:08 -0000 Alia, In no way I'm measuring efficiency in meeting time. We have a a discussion with many facets and it is impossible to repeat every argument in every mail. This was just a comment on an assertion that a group that has been split three ways will require the same meeting time after as before the split. /Loa On 2014-06-13 06:47, Alia Atlas wrote: > It sounds as if you are measuring efficiency by meeting time. > Shouldn't quality of drafts, discussion, and review come in? > The IETF's goal is good open standards, not meetings. > > Alia > > > On Fri, Jun 13, 2014 at 12:39 AM, Loa Andersson > wrote: > > Giles, > > You are right if a 1 to 3 split, result in three 1 hour meetings > instead of one 2.5 hour meeting. > > Only that I doubt i works that way. Mr Parkinson did look at this > back in the mid 1950-ies. > > I think it is likely that we end up with in the order of 4.5 hours of > meeting time. > > /Loa > > > > > On 2014-06-12 20:22, Giles Heron wrote: > > right - but if their total length is no longer than that of the > single WG then scheduling is no more difficult? > > On 12 Jun 2014, at 19:14, Gregory Mirsky > > wrote: > > Hi Giles, > I'm not so sure as, in my personal experience, I'll have to > attend all three or four WG and will be asking to make their > scheduling mutually exclusive. > > Regards, > Greg > > -----Original Message----- > From: routing-discussion > [mailto:routing-discussion-__bounces@ietf.org > ] On Behalf Of > Giles Heron > Sent: Thursday, June 12, 2014 10:42 AM > To: Loa Andersson > Cc: routing-discussion@ietf.org > ; stbryant@cisco.com > > Subject: Re: big equal to inefficient ?? > > On 12 Jun 2014, at 18:21, Loa Andersson > wrote: > > Stewart, > > On 2014-06-12 19:16, Stewart Bryant wrote: > > On 12/06/2014 06:16, Loa Andersson wrote: > > Alia and Adrian, > > you say: > > > 2) Split giant working groups so relevant > work is done in one place > and there is an improved signal-to-noise > ratio for participants who > are only interested in a slice of the current > working group's work. > > Exactly what metrics is the assertion that > "giant working groups" > are in-efficient based on? > > /Loa > > Well, one concern is that some large working groups > take two sessions > - the most allowed at a meeting, and still end up > with so many drafts > to discuss they either get 5mins or less each, or > not discussed. This > is not a productive way forward. > > Now maybe the answer is to take a much firmer line > on what gets > discussed at IETF, but that needs a cultural change. > The problem is > that cultural changes are incredibly difficult and > so far I have seen > no workable answer beyond splitting the work into > smaller slices. > > - Stewart > > > So if we split the wg taking two sessions into 3 or 4 > groups, taking 3 > or 4 sessions, that is better? > > > yes, if the total length of the sessions is the same :) > > in general a more focussed group is better I think as > there's less risk of people having to sit through tons of > drafts they're not interested in - though I know in MPLS you > have often split the sessions so that (for example) all the > MPLS-TP drafts get grouped together. > > Giles > > /Loa > > > > > > -- > > > Loa Andersson email: > loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 > 21 64 > > _________________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > > https://www.ietf.org/mailman/__listinfo/routing-discussion > > > > _________________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/__listinfo/routing-discussion > > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > _________________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/__listinfo/routing-discussion > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Thu Jun 12 21:58:33 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0F1B28B6 for ; Thu, 12 Jun 2014 21:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKNCeSyhJP0D for ; Thu, 12 Jun 2014 21:58:27 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8308C1B28A8 for ; Thu, 12 Jun 2014 21:58:27 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 131so1690477ykp.7 for ; Thu, 12 Jun 2014 21:58:26 -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=0LbT9bZfQF3zW7rieOBUHVahRBnVjxJ7qJKQTLzkJhQ=; b=LvakgAUDemmC0v9wRQauchl7cgA7QJOc87Rz40uHTbU2VM2R8t8eH3FxwFxB1XCwCU 6oYDJGVogGFT+vhFaLAKT8DjuvD3QMIqb61+jTtdMkP4G/dhaq4N47TROsb27yDAzfn9 OHrS2EBdSLUDLdz+1/Fe9r8UjlHymWyan3wI8b0+rfdia5vtwZWi/baPkQHKl7Kq9Dpf VOaToyn6WmFFhjwWgflx6SL+608kFp99e73mlH9BWJi9mCJg0k6K5a72DINFISlFwAP8 tLXS4bBTRqezg9tbIkWtTml3lBGeM3rj0qfvM69r6ncSpnXjkCkw+RBMuTAsEUgdYBJh OHyw== MIME-Version: 1.0 X-Received: by 10.236.72.70 with SMTP id s46mr436728yhd.145.1402635506604; Thu, 12 Jun 2014 21:58:26 -0700 (PDT) Received: by 10.170.52.75 with HTTP; Thu, 12 Jun 2014 21:58:26 -0700 (PDT) Received: by 10.170.52.75 with HTTP; Thu, 12 Jun 2014 21:58:26 -0700 (PDT) In-Reply-To: <539A83A8.2060402@pi.nu> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> Date: Fri, 13 Jun 2014 00:58:26 -0400 Message-ID: Subject: Re: big equal to inefficient ?? From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf300514be1ee2ad04fbb0872a Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/tdbTd5GQM5ORS2McXiAz2zH03W0 Cc: "routing-discussion@ietf.org" , Stewart Bryant X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 04:58:30 -0000 --20cf300514be1ee2ad04fbb0872a Content-Type: text/plain; charset=UTF-8 Loa, Ok. It seemed odd to me. I'm more interested in reading out the communities of interest and closely related work. We all suffer from the Bystander effect (i.e. someone else will take care of it) when a group gets too large. Alia On Jun 13, 2014 12:53 AM, "Loa Andersson" wrote: > Alia, > > In no way I'm measuring efficiency in meeting time. We have a > a discussion with many facets and it is impossible to repeat every > argument in every mail. > > This was just a comment on an assertion that a group that has > been split three ways will require the same meeting time after > as before the split. > > /Loa > > On 2014-06-13 06:47, Alia Atlas wrote: > >> It sounds as if you are measuring efficiency by meeting time. >> Shouldn't quality of drafts, discussion, and review come in? >> The IETF's goal is good open standards, not meetings. >> >> Alia >> >> >> On Fri, Jun 13, 2014 at 12:39 AM, Loa Andersson > > wrote: >> >> Giles, >> >> You are right if a 1 to 3 split, result in three 1 hour meetings >> instead of one 2.5 hour meeting. >> >> Only that I doubt i works that way. Mr Parkinson did look at this >> back in the mid 1950-ies. >> >> I think it is likely that we end up with in the order of 4.5 hours of >> meeting time. >> >> /Loa >> >> >> >> >> On 2014-06-12 20:22, Giles Heron wrote: >> >> right - but if their total length is no longer than that of the >> single WG then scheduling is no more difficult? >> >> On 12 Jun 2014, at 19:14, Gregory Mirsky >> > > wrote: >> >> Hi Giles, >> I'm not so sure as, in my personal experience, I'll have to >> attend all three or four WG and will be asking to make their >> scheduling mutually exclusive. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: routing-discussion >> [mailto:routing-discussion-__bounces@ietf.org >> ] On Behalf Of >> Giles Heron >> Sent: Thursday, June 12, 2014 10:42 AM >> To: Loa Andersson >> Cc: routing-discussion@ietf.org >> ; stbryant@cisco.com >> >> Subject: Re: big equal to inefficient ?? >> >> On 12 Jun 2014, at 18:21, Loa Andersson > > wrote: >> >> Stewart, >> >> On 2014-06-12 19:16, Stewart Bryant wrote: >> >> On 12/06/2014 06:16, Loa Andersson wrote: >> >> Alia and Adrian, >> >> you say: >> >> >> 2) Split giant working groups so relevant >> work is done in one place >> and there is an improved signal-to-noise >> ratio for participants who >> are only interested in a slice of the current >> working group's work. >> >> Exactly what metrics is the assertion that >> "giant working groups" >> are in-efficient based on? >> >> /Loa >> >> Well, one concern is that some large working groups >> take two sessions >> - the most allowed at a meeting, and still end up >> with so many drafts >> to discuss they either get 5mins or less each, or >> not discussed. This >> is not a productive way forward. >> >> Now maybe the answer is to take a much firmer line >> on what gets >> discussed at IETF, but that needs a cultural change. >> The problem is >> that cultural changes are incredibly difficult and >> so far I have seen >> no workable answer beyond splitting the work into >> smaller slices. >> >> - Stewart >> >> >> So if we split the wg taking two sessions into 3 or 4 >> groups, taking 3 >> or 4 sessions, that is better? >> >> >> yes, if the total length of the sessions is the same :) >> >> in general a more focussed group is better I think as >> there's less risk of people having to sit through tons of >> drafts they're not interested in - though I know in MPLS you >> have often split the sessions so that (for example) all the >> MPLS-TP drafts get grouped together. >> >> Giles >> >> /Loa >> >> >> >> >> >> -- >> >> >> Loa Andersson email: >> loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 >> 21 64 >> >> _________________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> >> https://www.ietf.org/mailman/_ >> _listinfo/routing-discussion >> > > >> >> >> _________________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org > ietf.org> >> https://www.ietf.org/mailman/__listinfo/routing-discussion >> >> >> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> >> _________________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/__listinfo/routing-discussion >> >> >> >> > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --20cf300514be1ee2ad04fbb0872a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Loa,

Ok.=C2=A0 It seemed odd to me.=C2=A0 I'm more interested= in reading out the communities of interest and closely related work.=C2=A0= We all suffer from the Bystander effect (i.e. someone else will take care = of it) when a group gets too large.

Alia

On Jun 13, 2014 12:53 AM, "Loa Andersson&qu= ot; <loa@pi.nu> wrote:
Alia,

In no way I'm measuring efficiency in meeting time. We have a
a discussion with many facets and it is impossible to repeat every
argument in every mail.

This was just a comment on an assertion that a group that has
been split three ways will require the same meeting time after
as before the split.

/Loa

On 2014-06-13 06:47, Alia Atlas wrote:
It sounds as if you are measuring efficiency by meeting time.
Shouldn't quality of drafts, discussion, and review come in?
The IETF's goal is good open standards, not meetings.

Alia


On Fri, Jun 13, 2014 at 12:39 AM, Loa Andersson <loa@pi.nu
<mailto:loa@pi.nu>= > wrote:

=C2=A0 =C2=A0 Giles,

=C2=A0 =C2=A0 You are right if a 1 to 3 split, result in three 1 hour meeti= ngs
=C2=A0 =C2=A0 instead of one 2.5 hour meeting.

=C2=A0 =C2=A0 Only that I doubt i works that way. Mr Parkinson did look at = this
=C2=A0 =C2=A0 back in the mid 1950-ies.

=C2=A0 =C2=A0 I think it is likely that we end up with in the order of 4.5 = hours of
=C2=A0 =C2=A0 meeting time.

=C2=A0 =C2=A0 /Loa




=C2=A0 =C2=A0 On 2014-06-12 20:22, Giles Heron wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 right - but if their total length is no longer = than that of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 single WG then scheduling is no more difficult?=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 12 Jun 2014, at 19:14, Gregory Mirsky
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <gregory.mirsky@ericsson.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:gregory.mirsky@ericsson.com>>= wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Giles,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm not so sure as, in my per= sonal experience, I'll have to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attend all three or four WG and w= ill be asking to make their
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scheduling mutually exclusive.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Greg

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From: routing-discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [mailto:routing-discussion-__<= /u>bounces@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:routing-discussion-bounces@ietf.org>] On Behalf Of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Giles Heron
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: Thursday, June 12, 2014 10:= 42 AM
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 To: Loa Andersson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cc: routing-discussion@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:routing-discussion@ietf.o= rg>; stbryan= t@cisco.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:stbryant@cisco.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: big equal to ineffic= ient ??

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 12 Jun 2014, at 18:21, Loa And= ersson <loa@pi.nu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:loa@pi.nu>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Stewart,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2014-06-12 19:16= , Stewart Bryant wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 12= /06/2014 06:16, Loa Andersson wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Alia and Adrian,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 you say:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02) Split giant working groups so relevant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 work is done in one place
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0and there is an improved signal-to-noise
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ratio for participants who
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0are only interested in a slice of the current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 working group's work.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Exactly what metrics is the assertion that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "giant working groups"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 are in-efficient based on?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 /Loa

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Well,= one concern is that some large working groups
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 take = two sessions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - the= most allowed at a meeting, and still end up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with = so many drafts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to di= scuss they either get 5mins or less each, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not d= iscussed. This
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is no= t a productive way forward.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Now m= aybe the answer is to take a much firmer line
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on wh= at gets
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 discu= ssed at IETF, but that needs a cultural change.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The p= roblem is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that = cultural changes are incredibly difficult and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 so fa= r I have seen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no wo= rkable answer beyond splitting the work into
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 small= er slices.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Ste= wart


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 So if we split the = wg taking two sessions into 3 or 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 groups, taking 3 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or 4 sessions, that= is better?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yes, if the total length of the s= essions is the same :)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in general a more focussed group = is better I think as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there's less risk of people h= aving to sit through tons of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drafts they're not interested= in - though I know in MPLS you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have often split the sessions so = that (for example) all the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS-TP drafts get grouped togeth= er.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Giles

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /Loa





=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Loa Andersson =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0email:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@mail01.huawei.com <mailt= o:loa@mail01.hua= wei.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Senior MPLS Expert = loa@pi.nu <mailto:loa@pi.nu>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Huawei Technologies= (consultant) =C2=A0 =C2=A0 phone: +46 739 81
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21 64 <tel:%2B46= %20739%2081%2021%2064>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ______________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 routing-discussion = mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 routing-discussion@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:routing-discussio= n@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https= ://www.ietf.org/mailman/__listinfo/routing-discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <htt= ps://www.ietf.org/mailman/listinfo/routing-discussion>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________________________= ___________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 routing-discussion mailing list =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 routing-discussion@ietf.org <mailto:= routing-di= scussion@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.or= g/mailman/__listinfo/routing-discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.= org/mailman/listinfo/routing-discussion>



=C2=A0 =C2=A0 --


=C2=A0 =C2=A0 Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
=C2=A0 =C2=A0 <mailto:loa@mail01.huawei.com>
=C2=A0 =C2=A0 Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
=C2=A0 =C2=A0 Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 21 64
=C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>

=C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 routing-discussion mailing list
=C2=A0 =C2=A0 routing-discussion@ietf.org <mailto:routing-discussion@ietf.org= >
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/= routing-discussion
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinfo/= routing-discussion>



--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64
--20cf300514be1ee2ad04fbb0872a-- From nobody Fri Jun 13 04:38:13 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8311A04BA for ; Fri, 13 Jun 2014 04:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjRWWn4Le3sY for ; Fri, 13 Jun 2014 04:38:08 -0700 (PDT) Received: from mx2.mtsallstream.com (mx2.mtsallstream.com [216.13.127.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB5C1A0340 for ; Fri, 13 Jun 2014 04:38:07 -0700 (PDT) Received: from tj1exg05.mtsallstream.com ([10.18.10.78]) by mx2.mtsallstream.com with ESMTP; 13 Jun 2014 07:37:42 -0400 Received: from TJ1EXG02.mtsallstream.com ([169.254.3.68]) by tj1exg05.mtsallstream.com ([169.254.5.34]) with mapi id 14.02.0309.002; Fri, 13 Jun 2014 07:38:03 -0400 From: "Krumholz, Danny" To: "routing-discussion@ietf.org" Subject: unsubscribe Thread-Topic: unsubscribe Thread-Index: Ac+G++RXyGJJ0y49QsOxkqVBptUsNQ== Date: Fri, 13 Jun 2014 11:38:03 +0000 Message-ID: <06E237E704C32F47AAC92538B8E97098015B7CEB66@tj1exg02.mtsallstream.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.11.244] Content-Type: multipart/alternative; boundary="_000_06E237E704C32F47AAC92538B8E97098015B7CEB66tj1exg02mtsal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Q72BB-MdJYYy18-SLhoSMm-_RMs X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 11:38:09 -0000 --_000_06E237E704C32F47AAC92538B8E97098015B7CEB66tj1exg02mtsal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to unsubscribe Danny Krumholz --_000_06E237E704C32F47AAC92538B8E97098015B7CEB66tj1exg02mtsal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to unsubscribe

 

Danny Krumholz

 

 

--_000_06E237E704C32F47AAC92538B8E97098015B7CEB66tj1exg02mtsal_-- From nobody Fri Jun 13 04:46:14 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785F01B279B for ; Fri, 13 Jun 2014 04:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYbdkydCw5Db for ; Fri, 13 Jun 2014 04:46:11 -0700 (PDT) Received: from mx2.mtsallstream.com (mx2.mtsallstream.com [216.13.127.56]) by ietfa.amsl.com (Postfix) with ESMTP id 817631A0340 for ; Fri, 13 Jun 2014 04:46:11 -0700 (PDT) Received: from txexg04.mtsallstream.com ([10.18.250.27]) by mx2.mtsallstream.com with ESMTP; 13 Jun 2014 07:45:48 -0400 Received: from TJ1EXG02.mtsallstream.com ([169.254.3.68]) by txexg04.mtsallstream.com ([169.254.5.11]) with mapi id 14.02.0309.002; Fri, 13 Jun 2014 07:46:11 -0400 From: "Krumholz, Danny" To: "routing-discussion@ietf.org" Subject: please unsubscribe me Thread-Topic: please unsubscribe me Thread-Index: Ac+G/Q8TxauDju8yTWOufprG62OpRg== Date: Fri, 13 Jun 2014 11:46:10 +0000 Message-ID: <06E237E704C32F47AAC92538B8E97098015B7CEB9C@tj1exg02.mtsallstream.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.11.244] Content-Type: multipart/alternative; boundary="_000_06E237E704C32F47AAC92538B8E97098015B7CEB9Ctj1exg02mtsal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/8B0CDF3cSHc9E_s360GuazNh55M X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 11:46:12 -0000 --_000_06E237E704C32F47AAC92538B8E97098015B7CEB9Ctj1exg02mtsal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Danny Krumholz --_000_06E237E704C32F47AAC92538B8E97098015B7CEB9Ctj1exg02mtsal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Danny Krumholz

--_000_06E237E704C32F47AAC92538B8E97098015B7CEB9Ctj1exg02mtsal_-- From nobody Fri Jun 13 06:59:53 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6671B2912 for ; Fri, 13 Jun 2014 06:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07pU2CxwlVJz for ; Fri, 13 Jun 2014 06:59:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2FD1A00FB for ; Fri, 13 Jun 2014 06:59:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 30611C3F7; Fri, 13 Jun 2014 09:59:44 -0400 (EDT) Date: Fri, 13 Jun 2014 09:59:44 -0400 From: Jeffrey Haas To: Loa Andersson Subject: Re: big equal to inefficient ?? Message-ID: <20140613135944.GA10109@pfrc> References: <53993792.3050902@pi.nu> <539A2C36.2030907@labn.net> <054701cf8692$c05029e0$40f07da0$@olddog.co.uk> <539A7ED7.1050401@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539A7ED7.1050401@pi.nu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/HwE73qDZkFwCobBXie2lbiaVOdU Cc: adrian@olddog.co.uk, 'Lou Berger' , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 13:59:50 -0000 On Fri, Jun 13, 2014 at 06:32:23AM +0200, Loa Andersson wrote: > Please note: > > I'm not saying that we should not re-organize, but I've so far not > found THE principle according to which we can re-organize the entire > area. I'm also wondering as we continue this discussion whether we're tailoring our comments way too much around observations of meeting sessions rather than the overall work. Much (should) happen on the mailing lists. -- Jeff From nobody Fri Jun 13 10:03:02 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062B11A05CB for ; Fri, 13 Jun 2014 10:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvN34PqCgTJb for ; Fri, 13 Jun 2014 10:02:59 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2392A1A01A8 for ; Fri, 13 Jun 2014 10:02:58 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5DH2taK008881; Fri, 13 Jun 2014 18:02:55 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5DH2qTj008863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 18:02:52 +0100 From: "Adrian Farrel" To: "'Russ White'" , References: <007701cf8434$11f52cc0$35df8640$@riw.us> In-Reply-To: <007701cf8434$11f52cc0$35df8640$@riw.us> Subject: RE: RSS Feed for Routing Area Wiki/Routing Area Directorate Wiki? Date: Fri, 13 Jun 2014 18:02:49 +0100 Message-ID: <020f01cf8729$4fc56860$ef503920$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKfwM/4j5jbrhCI2t7hhuDx4VxpQ5nO0Opw Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20756.000 X-TM-AS-Result: No--8.313-10.0-31-10 X-imss-scan-details: No--8.313-10.0-31-10 X-TMASE-MatchedRID: scwq2vQP8OHeCNsd8bAqKCMr6dQEFx/Lt3aeg7g/usAiFs20Vxq/wmAh JwKJaQoQox3eLPiNwxWTZF1mN+lesQtXPaEskTu5Ry+94mWbR+ZRWu4OwvLdhN9RlPzeVuQQLub wttVz20+mUY/STdS0raDBL7AMEm97owd2GDRd5gWdtRmRhPNchlCpbeAMlu7gydovWuL+KVfbNQ h85GhqIhFbcWj6ErewHmGY/o4z88lNfs8n85Te8v7E6GNqs6ceX8SiR1i/NFH6C0ePs7A07Y6HM 5rqDwqt2OwtQ9w/bs5fDiXZhP2073cPlC0MxFdChBLZ5TyiuzAvQMyr6DUWlkMMprcbiest Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/VH8R8JD7l2ZYszLzgjdKtjdnH2c X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 17:03:01 -0000 I don't see anything either. Mail to the tools team? A > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf > Of Russ White > Sent: 09 June 2014 23:42 > To: routing-discussion@ietf.org > Subject: RSS Feed for Routing Area Wiki/Routing Area Directorate Wiki? > > Y'all: > > It looks like trac wiki has the capability to provide an rss feed, but it's > not turned on for any of the ietf wiki sites... It would be really nice to > have a wiki rss feed for the routing area directorate page -- does anyone > know how to turn it on, or if there's a magic url I'm missing, or maybe I'm > just blind and can't see the orange button the docs say should be at the > bottom of the page... or... ?? > > :-) > > Russ > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Fri Jun 13 12:29:35 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CC11B2A04 for ; Fri, 13 Jun 2014 12:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Y4lbxCtSQiv for ; Fri, 13 Jun 2014 12:29:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F2B1B2A00 for ; Fri, 13 Jun 2014 12:29:31 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) with Microsoft SMTP Server (TLS) id 15.0.954.9; Fri, 13 Jun 2014 19:29:29 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Fri, 13 Jun 2014 19:29:29 +0000 From: Ross Callon To: "Fedyk, Don" , Ted Lemon Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTgAAiZYAAAAHBcAAAGC88A== Date: Fri, 13 Jun 2014 19:29:28 +0000 Message-ID: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0241D5F98C x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(24454002)(189002)(199002)(377454003)(92566001)(20776003)(4396001)(46102001)(77096999)(76576001)(87936001)(85852003)(83072002)(15975445006)(2656002)(74662001)(54356999)(80022001)(76176999)(50986999)(64706001)(66066001)(81342001)(76482001)(31966008)(74502001)(19580395003)(86362001)(101416001)(99396002)(74316001)(83322001)(99286001)(21056001)(77982001)(33646001)(19580405001)(81542001)(79102001)(105586001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/ZTVeD6QU4WjaBNeNDdYsr9xrleM Cc: "routing-discussion@ietf.org" , Stewart Bryant X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 19:29:33 -0000 The extra minutes in the hallways can sometimes be the most valuable part o= f the IETF.=20 One advantage of the 5 minute status presentations: they sometimes give a h= eads up regarding what hallway discussions are needed. I know that in princ= iple we all could read every Internet Draft that comes out and therefore do= n't need the status presentations, but in practice we don't all find the ti= me to read every Internet Draft.=20 Ross -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Fedyk, Don Sent: Thursday, June 12, 2014 2:12 PM To: Ted Lemon Cc: routing-discussion@ietf.org; Stewart Bryant Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Well perhaps status updates is the wrong term but you usually get 5 to 15 m= inutes and some extra minutes in the hallways.=20 Don=20 -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Ted Lemon Sent: Thursday, June 12, 2014 2:10 PM To: Fedyk, Don Cc: Stewart Bryant; routing-discussion@ietf.org Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: > A large amount of work can be accomplished there and the IETF session can= be more of a status meeting (they are really anyway). If IETF sessions are just status updates, why don't you do that online and = save yourself the travel cost? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Fri Jun 13 13:47:16 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F5A1B2A54 for ; Fri, 13 Jun 2014 13:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 015S2vxJpAVA for ; Fri, 13 Jun 2014 13:47:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D0281B2A53 for ; Fri, 13 Jun 2014 13:47:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIJ96609; Fri, 13 Jun 2014 20:47:09 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 21:47:09 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 13:46:59 -0700 From: Linda Dunbar To: Ross Callon , "Fedyk, Don" , "Ted Lemon" Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTgAAiZYAAAAHBcAAAGC88AA2+mJg Date: Fri, 13 Jun 2014 20:46:59 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> References: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/cAYSibVizLipe2Q6ss6NnemCY20 Cc: "routing-discussion@ietf.org" , Stewart Bryant X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:47:14 -0000 I agree with what Ross said "hallways communication is most valuable part o= f the IETF".=20 Therefore, the IETF meetings should have more & longer breaks, with cookies= & drinks farther away from meeting rooms, to give people, especially peopl= e who are not friends yet, more chance to meet and talk.=20 It is difficult for new comers to grab senior people's time other than a fe= w minutes on the hallway.=20 I remember reading a memoir about Steve Jobs' initial design for Pixar offi= ce is to have very few restrooms and have them purposely very far way from = where people sit, to force people seeing each other more on the hallway, to= create a easier environment to communicate.=20 Linda Dunbar -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Ross Callon Sent: Friday, June 13, 2014 2:29 PM To: Fedyk, Don; Ted Lemon Cc: routing-discussion@ietf.org; Stewart Bryant Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? The extra minutes in the hallways can sometimes be the most valuable part o= f the IETF.=20 One advantage of the 5 minute status presentations: they sometimes give a h= eads up regarding what hallway discussions are needed. I know that in princ= iple we all could read every Internet Draft that comes out and therefore do= n't need the status presentations, but in practice we don't all find the ti= me to read every Internet Draft.=20 Ross -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Fedyk, Don Sent: Thursday, June 12, 2014 2:12 PM To: Ted Lemon Cc: routing-discussion@ietf.org; Stewart Bryant Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Well perhaps status updates is the wrong term but you usually get 5 to 15 m= inutes and some extra minutes in the hallways.=20 Don=20 -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Ted Lemon Sent: Thursday, June 12, 2014 2:10 PM To: Fedyk, Don Cc: Stewart Bryant; routing-discussion@ietf.org Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: > A large amount of work can be accomplished there and the IETF session can= be more of a status meeting (they are really anyway). If IETF sessions are just status updates, why don't you do that online and = save yourself the travel cost? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Fri Jun 13 14:38:11 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035C81B2A67 for ; Fri, 13 Jun 2014 14:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aS5xrQmxArRp for ; Fri, 13 Jun 2014 14:38:08 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A1F1B2A65 for ; Fri, 13 Jun 2014 14:38:08 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5DLbnRa014174; Fri, 13 Jun 2014 22:37:49 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5DLbmvO014163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 22:37:48 +0100 From: "Adrian Farrel" To: "'Linda Dunbar'" , "'Ross Callon'" , "'Fedyk, Don'" , "'Ted Lemon'" References: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Date: Fri, 13 Jun 2014 22:37:44 +0100 Message-ID: <02be01cf874f$b6e46020$24ad2060$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGNvzSJQ50UwxwuQQezMAW55dIVUAC+H8m8Aj3Y8z8BR3HwnQIwYsn1m7+AuKA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20756.002 X-TM-AS-Result: No--18.760-10.0-31-10 X-imss-scan-details: No--18.760-10.0-31-10 X-TMASE-MatchedRID: C/snMIRQLS1i8tNcpebA1hJmPIoQFzZ7k9atiES99p1aW2Ktn+I8/m3g 5DpxUflEW2kHn+BQnPtwDA6yjAj5UrRmCG3Cyh8KVV4ZZmbE3Ywh9mNF8ZPJ2Hq20v2fBg+yws0 GnfdoJ8jk1ismlDQ8rLEEaTbbyV+p1xQ2OgXti5WvThHXboayJ4+G8hrjYfYTtXl9IxEPXOrjpA ioQFNHJFPAvwzyxC4s2jE5daveFEF3dXZvIJVkULiMC5wdwKqd8rPh3yI68clfmiXzNQSRfGDlQ gaLAg31Z/0JKiWS3HUqFnem09TLnTUEAKtAUHelkPoFsM336M7omPrNi98UBDW5h17n9B1XL3PL MlQSdmRVTqPfIw96Yn1jjvok3ObG/zkYJHv4a2F63odmwewzv+UOheG2DMMfydovWuL+KVfbNQh 85GhqIhFbcWj6ErewHmGY/o4z88lYe6RsTDPSfTl/1fD/GopdyJ1gFgOMhOm2s0ar5ZAS9AGLeS ok4rrZC24oEZ6SpSkj80Za3RRg8DZ5VLipn5vlAoKbVkX0wsKuSDXKAYeXm1GaJrF/6ul6GSCvL i0tcps= Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/tbbmWHkiUjqSP3qAh8UDw8Qtc3g Cc: routing-discussion@ietf.org, 'Stewart Bryant' X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:38:10 -0000 An interesting theme. Entirely disregarding slot length, there are 17 meeting slots at an IETF meeting. Until 2 weeks ago there were 21 WGs. Say 2 WGs don't meet and 2 WGs have double slots. Add the area meeting and a BoF. Maybe add an IRTF meeting that has significant overlap. That makes for 24 slots in a 17 slot schedule. Now consider critical overlap with other areas. Even doubling up routing WG meetings like we do, we are pretty close to being "full". If we increase break times (or increase the time to walk to rest rooms ;-) then we lose meeting time. Lots of options to solve that, but it has to be rolled into the mix of discussion. Adrian > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf > Of Linda Dunbar > Sent: 13 June 2014 21:47 > To: Ross Callon; Fedyk, Don; Ted Lemon > Cc: routing-discussion@ietf.org; Stewart Bryant > Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? > > I agree with what Ross said "hallways communication is most valuable part of the > IETF". > > Therefore, the IETF meetings should have more & longer breaks, with cookies & > drinks farther away from meeting rooms, to give people, especially people who > are not friends yet, more chance to meet and talk. > > It is difficult for new comers to grab senior people's time other than a few > minutes on the hallway. > > I remember reading a memoir about Steve Jobs' initial design for Pixar office is to > have very few restrooms and have them purposely very far way from where > people sit, to force people seeing each other more on the hallway, to create a > easier environment to communicate. > > Linda Dunbar > > > > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf > Of Ross Callon > Sent: Friday, June 13, 2014 2:29 PM > To: Fedyk, Don; Ted Lemon > Cc: routing-discussion@ietf.org; Stewart Bryant > Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? > > The extra minutes in the hallways can sometimes be the most valuable part of > the IETF. > > One advantage of the 5 minute status presentations: they sometimes give a > heads up regarding what hallway discussions are needed. I know that in principle > we all could read every Internet Draft that comes out and therefore don't need > the status presentations, but in practice we don't all find the time to read every > Internet Draft. > > Ross > > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf > Of Fedyk, Don > Sent: Thursday, June 12, 2014 2:12 PM > To: Ted Lemon > Cc: routing-discussion@ietf.org; Stewart Bryant > Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? > > Well perhaps status updates is the wrong term but you usually get 5 to 15 > minutes and some extra minutes in the hallways. > > Don > > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf > Of Ted Lemon > Sent: Thursday, June 12, 2014 2:10 PM > To: Fedyk, Don > Cc: Stewart Bryant; routing-discussion@ietf.org > Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? > > On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: > > A large amount of work can be accomplished there and the IETF session can be > more of a status meeting (they are really anyway). > > If IETF sessions are just status updates, why don't you do that online and save > yourself the travel cost? > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Fri Jun 13 14:43:09 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D233C1B2A60 for ; Fri, 13 Jun 2014 14:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzhK5pXPXsa9 for ; Fri, 13 Jun 2014 14:43:07 -0700 (PDT) Received: from g6t1526.atlanta.hp.com (g6t1526.atlanta.hp.com [15.193.200.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F801A0236 for ; Fri, 13 Jun 2014 14:43:07 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t1526.atlanta.hp.com (Postfix) with ESMTPS id DF16623E; Fri, 13 Jun 2014 21:43:05 +0000 (UTC) Received: from G6W3996.americas.hpqcorp.net (16.205.80.211) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Fri, 13 Jun 2014 21:41:12 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.232]) by G6W3996.americas.hpqcorp.net ([16.205.80.211]) with mapi id 14.03.0169.001; Fri, 13 Jun 2014 21:41:12 +0000 From: "Fedyk, Don" To: Linda Dunbar , Ross Callon , Ted Lemon Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTgAAiZYAAAAHBcAAAGC88AA2+mJgAAFYxWA= Date: Fri, 13 Jun 2014 21:41:12 +0000 Message-ID: References: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.193.49.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/LhgVuHmRJaFV-cSr9wVy_Je3AiU Cc: "routing-discussion@ietf.org" , Stewart Bryant X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:43:09 -0000 Well I've noticed that when a meeting finishes a bit early that people ofte= n stick around for a bit of discussion but if you pack the agenda to the li= mit everyone is tearing out to the next slot/dinner. Could we script a 5 mi= nute free discussion or would people just adapt and leave the room earlier?= =20 I think the Bit n Bytes was an attempt to do what you are asking but you ne= ver know who will be there. Maybe we should encourage mini-bar bof topics = for the Bits and Bytes. And there is the occasional bar bof. =20 Don=20 =20 -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Linda Dunbar Sent: Friday, June 13, 2014 4:47 PM To: Ross Callon; Fedyk, Don; Ted Lemon Cc: routing-discussion@ietf.org; Stewart Bryant Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? I agree with what Ross said "hallways communication is most valuable part o= f the IETF".=20 Therefore, the IETF meetings should have more & longer breaks, with cookies= & drinks farther away from meeting rooms, to give people, especially peopl= e who are not friends yet, more chance to meet and talk.=20 It is difficult for new comers to grab senior people's time other than a fe= w minutes on the hallway.=20 I remember reading a memoir about Steve Jobs' initial design for Pixar offi= ce is to have very few restrooms and have them purposely very far way from = where people sit, to force people seeing each other more on the hallway, to= create a easier environment to communicate.=20 Linda Dunbar -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Ross Callon Sent: Friday, June 13, 2014 2:29 PM To: Fedyk, Don; Ted Lemon Cc: routing-discussion@ietf.org; Stewart Bryant Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? The extra minutes in the hallways can sometimes be the most valuable part o= f the IETF.=20 One advantage of the 5 minute status presentations: they sometimes give a h= eads up regarding what hallway discussions are needed. I know that in princ= iple we all could read every Internet Draft that comes out and therefore do= n't need the status presentations, but in practice we don't all find the ti= me to read every Internet Draft.=20 Ross -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Fedyk, Don Sent: Thursday, June 12, 2014 2:12 PM To: Ted Lemon Cc: routing-discussion@ietf.org; Stewart Bryant Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Well perhaps status updates is the wrong term but you usually get 5 to 15 m= inutes and some extra minutes in the hallways.=20 Don=20 -----Original Message----- From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Ted Lemon Sent: Thursday, June 12, 2014 2:10 PM To: Fedyk, Don Cc: Stewart Bryant; routing-discussion@ietf.org Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: > A large amount of work can be accomplished there and the IETF session can= be more of a status meeting (they are really anyway). If IETF sessions are just status updates, why don't you do that online and = save yourself the travel cost? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Fri Jun 13 14:59:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5909D1B2A72 for ; Fri, 13 Jun 2014 14:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9mysU2OjNSr for ; Fri, 13 Jun 2014 14:59:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A712B1B2A6A for ; Fri, 13 Jun 2014 14:59:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIJ99425; Fri, 13 Jun 2014 21:59:11 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 22:59:11 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml706-chm.china.huawei.com ([169.254.8.4]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 14:59:05 -0700 From: Linda Dunbar To: "adrian@olddog.co.uk" , "'Ross Callon'" , "'Fedyk, Don'" , "'Ted Lemon'" Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTgAAiZYAAAAHBcAAAGC88AA2+mJgABDYagAADlUi0A== Date: Fri, 13 Jun 2014 21:59:05 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D354E6@dfweml701-chm.china.huawei.com> References: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> <02be01cf874f$b6e46020$24ad2060$@olddog.co.uk> In-Reply-To: <02be01cf874f$b6e46020$24ad2060$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/L4gX07g6UytmXhOO6K7vxbXHlBA Cc: "routing-discussion@ietf.org" , 'Stewart Bryant' X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 21:59:16 -0000 Maybe IETF should also consider "web meetings" for some groups to resolve t= echnical issues ahead of F2F meetings (like ONF, NFV, MEF, etc). And leavi= ng F2F meeting more breaks for informal chat in the hallways. Granted it is very tiring (especially to the chairs) to host bi-weekly, or = monthly meetings throughout the year. I have observed many IETF WG chairs only become "active" a couple of weeks = before and after the F2F meeting.=20 Is it realistic for the IETF WG chairs or the secretaries to publish monthl= y report on major conflicts of opinions expressed on mailing list, posted d= rafts, resolutions, etc?=20 Linda -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Friday, June 13, 2014 4:38 PM To: Linda Dunbar; 'Ross Callon'; 'Fedyk, Don'; 'Ted Lemon' Cc: routing-discussion@ietf.org; 'Stewart Bryant' Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? An interesting theme. Entirely disregarding slot length, there are 17 meeting slots at an IETF me= eting. Until 2 weeks ago there were 21 WGs. Say 2 WGs don't meet and 2 WGs have double slots. Add the area meeting and a BoF. Maybe add an IRTF meeting that has significant overlap. That makes for 24 slots in a 17 slot schedule. Now consider critical overlap with other areas. Even doubling up routing WG meetings like we do, we are pretty close to bei= ng "full". If we increase break times (or increase the time to walk to rest= rooms ;-) then we lose meeting time. Lots of options to solve that, but it has to be rolled into the mix of disc= ussion. Adrian > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org]=20 > On Behalf > Of Linda Dunbar > Sent: 13 June 2014 21:47 > To: Ross Callon; Fedyk, Don; Ted Lemon > Cc: routing-discussion@ietf.org; Stewart Bryant > Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? >=20 > I agree with what Ross said "hallways communication is most valuable=20 > part of the > IETF". >=20 > Therefore, the IETF meetings should have more & longer breaks, with=20 > cookies & drinks farther away from meeting rooms, to give people,=20 > especially people who are not friends yet, more chance to meet and talk. >=20 > It is difficult for new comers to grab senior people's time other than=20 > a few minutes on the hallway. >=20 > I remember reading a memoir about Steve Jobs' initial design for Pixar=20 > office is to > have very few restrooms and have them purposely very far way from=20 > where people sit, to force people seeing each other more on the=20 > hallway, to create a easier environment to communicate. >=20 > Linda Dunbar >=20 >=20 >=20 > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org]=20 > On Behalf > Of Ross Callon > Sent: Friday, June 13, 2014 2:29 PM > To: Fedyk, Don; Ted Lemon > Cc: routing-discussion@ietf.org; Stewart Bryant > Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? >=20 > The extra minutes in the hallways can sometimes be the most valuable=20 > part of the IETF. >=20 > One advantage of the 5 minute status presentations: they sometimes=20 > give a heads up regarding what hallway discussions are needed. I know=20 > that in principle > we all could read every Internet Draft that comes out and therefore=20 > don't need the status presentations, but in practice we don't all find=20 > the time to read every > Internet Draft. >=20 > Ross >=20 > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org]=20 > On Behalf > Of Fedyk, Don > Sent: Thursday, June 12, 2014 2:12 PM > To: Ted Lemon > Cc: routing-discussion@ietf.org; Stewart Bryant > Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? >=20 > Well perhaps status updates is the wrong term but you usually get 5 to=20 > 15 minutes and some extra minutes in the hallways. >=20 > Don >=20 > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org]=20 > On Behalf > Of Ted Lemon > Sent: Thursday, June 12, 2014 2:10 PM > To: Fedyk, Don > Cc: Stewart Bryant; routing-discussion@ietf.org > Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? >=20 > On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: > > A large amount of work can be accomplished there and the IETF=20 > > session can be > more of a status meeting (they are really anyway). >=20 > If IETF sessions are just status updates, why don't you do that online=20 > and save > yourself the travel cost? >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Fri Jun 13 19:15:25 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7978D1B2B11 for ; Fri, 13 Jun 2014 19:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXiy2ySTvBOy for ; Fri, 13 Jun 2014 19:15:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E351B2B10 for ; Fri, 13 Jun 2014 19:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6809; q=dns/txt; s=iport; t=1402712122; x=1403921722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5pEqiuH11kR0lk9VHSsuCZfdIeGulrad63CSXBoiQAs=; b=X64cwTTeYX9pjYhcJVEN1kiMTip8ggOBwByotXio8FcROcaiRO9nWZw7 ReHFgvRxmvEaudmD6685ft0Q34DNTBB5JqIDvbcm3En1V496H332z40Y4 aog7l4wBFSyp+iamCTkbs+3wk437Dm1gzgLSo8mJq05dOT8juFVpaa1GP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUHALuvm1OtJA2L/2dsb2JhbABagw1SWaliAQEBAQEBBQGRZYZsUQGBBRZ1hAMBAQEEAQEBawsMBAIBCBEEAQEBJwcnCxQJCAIEAQ0FFYgtDc9rEwSFXYkCBwaEOwSaN5NXgz6CMA X-IronPort-AV: E=Sophos;i="5.01,475,1400025600"; d="scan'208";a="333129024" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 14 Jun 2014 02:15:21 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5E2FLk0028593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Jun 2014 02:15:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 21:15:21 -0500 From: "Ken Gray (kegray)" To: Linda Dunbar , "adrian@olddog.co.uk" , "'Ross Callon'" , "'Fedyk, Don'" , "'Ted Lemon'" Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Topic: Have an interim Meeting was RE: big equal to inefficient ?? Thread-Index: Ac+GZ1GoZdIJwZBjQ8K3HLpDc3gZTgALA8sAAAAWpgAANP4FAAACtQ2AAAHFvgAAAL7igP//0j0A Date: Sat, 14 Jun 2014 02:15:19 +0000 Message-ID: References: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> <02be01cf874f$b6e46020$24ad2060$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645D354E6@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D354E6@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.121.88] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/T-gKs83QGDG1Dg3T3byFSP2zzzE Cc: "routing-discussion@ietf.org" , "Stewart Bryant \(stbryant\)" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 02:15:24 -0000 The last thing I'd ever want to see in the IETF is to be more like any of these organizations. I'm sorry if that offends, but =8Ajust as an example, some of the ETSI NFV groups have met more than 15 times online this calendar year (ETSI conveniently numbers the meetings on their portal and some of these groups have numbers > 60 in their 18 months of existence). The ONF workgroups seem to have at least a monthly cadence. Bi-weekly even monthly ..in which timezone? Maybe it's old school, but I think mailing lists should work for discussion - their asynchronous nature fits the work habits and timezone spread of our very large culture. Your observation about the WG chairs in the IETF might be linked to the fact that they have a job outside of standards work (thank god for that and good luck to them). Coders, designers, architects =8A at least good ones, aren't going to have the time for bi-weekly commitments to anything - particularly out of their timezones. On 6/13/14 2:59 PM, "Linda Dunbar" wrote: >Maybe IETF should also consider "web meetings" for some groups to resolve >technical issues ahead of F2F meetings (like ONF, NFV, MEF, etc). And >leaving F2F meeting more breaks for informal chat in the hallways. > >Granted it is very tiring (especially to the chairs) to host bi-weekly, >or monthly meetings throughout the year. > >I have observed many IETF WG chairs only become "active" a couple of >weeks before and after the F2F meeting. > >Is it realistic for the IETF WG chairs or the secretaries to publish >monthly report on major conflicts of opinions expressed on mailing list, >posted drafts, resolutions, etc? > >Linda > >-----Original Message----- >From: Adrian Farrel [mailto:adrian@olddog.co.uk] >Sent: Friday, June 13, 2014 4:38 PM >To: Linda Dunbar; 'Ross Callon'; 'Fedyk, Don'; 'Ted Lemon' >Cc: routing-discussion@ietf.org; 'Stewart Bryant' >Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? > >An interesting theme. > >Entirely disregarding slot length, there are 17 meeting slots at an IETF >meeting. > >Until 2 weeks ago there were 21 WGs. >Say 2 WGs don't meet and 2 WGs have double slots. >Add the area meeting and a BoF. >Maybe add an IRTF meeting that has significant overlap. > >That makes for 24 slots in a 17 slot schedule. > >Now consider critical overlap with other areas. > >Even doubling up routing WG meetings like we do, we are pretty close to >being "full". If we increase break times (or increase the time to walk to >rest rooms >;-) then we lose meeting time. > >Lots of options to solve that, but it has to be rolled into the mix of >discussion. > >Adrian > >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] >> On >Behalf >> Of Linda Dunbar >> Sent: 13 June 2014 21:47 >> To: Ross Callon; Fedyk, Don; Ted Lemon >> Cc: routing-discussion@ietf.org; Stewart Bryant >> Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? >>=20 >> I agree with what Ross said "hallways communication is most valuable >> part of >the >> IETF". >>=20 >> Therefore, the IETF meetings should have more & longer breaks, with >> cookies & drinks farther away from meeting rooms, to give people, >> especially people who are not friends yet, more chance to meet and >>talk. >>=20 >> It is difficult for new comers to grab senior people's time other than >> a few minutes on the hallway. >>=20 >> I remember reading a memoir about Steve Jobs' initial design for Pixar >> office >is to >> have very few restrooms and have them purposely very far way from >> where people sit, to force people seeing each other more on the >> hallway, to create a easier environment to communicate. >>=20 >> Linda Dunbar >>=20 >>=20 >>=20 >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] >> On >Behalf >> Of Ross Callon >> Sent: Friday, June 13, 2014 2:29 PM >> To: Fedyk, Don; Ted Lemon >> Cc: routing-discussion@ietf.org; Stewart Bryant >> Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? >>=20 >> The extra minutes in the hallways can sometimes be the most valuable >> part of the IETF. >>=20 >> One advantage of the 5 minute status presentations: they sometimes >> give a heads up regarding what hallway discussions are needed. I know >> that in >principle >> we all could read every Internet Draft that comes out and therefore >> don't need the status presentations, but in practice we don't all find >> the time to read >every >> Internet Draft. >>=20 >> Ross >>=20 >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] >> On >Behalf >> Of Fedyk, Don >> Sent: Thursday, June 12, 2014 2:12 PM >> To: Ted Lemon >> Cc: routing-discussion@ietf.org; Stewart Bryant >> Subject: RE: Have an interim Meeting was RE: big equal to inefficient ?? >>=20 >> Well perhaps status updates is the wrong term but you usually get 5 to >> 15 minutes and some extra minutes in the hallways. >>=20 >> Don >>=20 >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] >> On >Behalf >> Of Ted Lemon >> Sent: Thursday, June 12, 2014 2:10 PM >> To: Fedyk, Don >> Cc: Stewart Bryant; routing-discussion@ietf.org >> Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? >>=20 >> On Jun 12, 2014, at 2:05 PM, Fedyk, Don wrote: >> > A large amount of work can be accomplished there and the IETF >> > session can be >> more of a status meeting (they are really anyway). >>=20 >> If IETF sessions are just status updates, why don't you do that online >> and >save >> yourself the travel cost? >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Fri Jun 13 23:04:28 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2DF1B2B69 for ; Fri, 13 Jun 2014 23:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV-QyZ7CE49d for ; Fri, 13 Jun 2014 23:04:25 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0E11B2B64 for ; Fri, 13 Jun 2014 23:04:25 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 26F3618015A1; Sat, 14 Jun 2014 08:04:21 +0200 (CEST) Message-ID: <539BE5E0.5050507@pi.nu> Date: Sat, 14 Jun 2014 08:04:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <539A2C36.2030907@labn.net> <054701cf8692$c05029e0$40f07da0$@olddog.co.uk> <539A7ED7.1050401@pi.nu> <20140613135944.GA10109@pfrc> In-Reply-To: <20140613135944.GA10109@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/dGkyp2FPM-Xm3Nq0NS4gDchDItY Cc: adrian@olddog.co.uk, 'Lou Berger' , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 06:04:27 -0000 Jeff, On 2014-06-13 15:59, Jeffrey Haas wrote: > On Fri, Jun 13, 2014 at 06:32:23AM +0200, Loa Andersson wrote: >> Please note: >> >> I'm not saying that we should not re-organize, but I've so far not >> found THE principle according to which we can re-organize the entire >> area. > > I'm also wondering as we continue this discussion whether we're tailoring > our comments way too much around observations of meeting sessions rather > than the overall work. Much (should) happen on the mailing lists. > > -- Jeff > I think you are heads on! There are issues that are focused on the F2F meetings. It seems that they are possible manage within the current area structure. We might want to make sure that the re-org actions we take don't make them worse, e.g. more working harder scheduling. If we consider the work on the mailing, I do not see that the signal-to- noise ratio is a real problem. Maybe sometimes the signal is to weak (not enough discussion). One of my co-chairs has often said "quality takes time", I agree thinking things through one extra time improve quality and probably save working time in the long run. This begs the question how we measure speed and efficiency. I'd say (maybe I'm as old-fashion as Ken) take more work to the mailing lists, but use the tools you need. If you need a dt have one, if you need an interim do one, etc. However we should remember that discussions in the IETF happens on mailings lists. Over the last few years we have tweaked the MPLS wg process, one thing we done is to require that authors that update their documents due to comments confirm with the people making the comments that they are comfortable with how the comment has been addressed. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jun 14 04:53:30 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0921B27F0 for ; Sat, 14 Jun 2014 04:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY_Omr8VOnpa for ; Sat, 14 Jun 2014 04:53:27 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723E41A07AB for ; Sat, 14 Jun 2014 04:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2567; q=dns/txt; s=iport; t=1402746809; x=1403956409; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w0LiRlBPh8Iiwk5MOjqMtEtjfdf3Nk/tWmNBZ1ewCNs=; b=K79nJIb0gUXDitrq/tjXLRpMHoXbYXb6UVNBgqtyAD+OBTcN6Bvvt0pC qWNBS+oXygXY1120tokSEVW/MJK/odKZOPHZWlB8zEGVhj7alJgH3nFfr Kyrjc3xjoFIqz2gVyWILAM4ZW/2O8Ajl0lZ7Uw7KgxHfGcY4rHSS1cVOh g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGADA3nFOtJA2M/2dsb2JhbABagw1Sqj8BAQEBAQEFAZFlhmxRAYEDFnWEAwEBAQMBAQEBNzEDCwUJAgIBCBgeEBsMCyUCBA4FiDoIDc9mEwQEhVmIIBEBHTMHgyuBFgSaPZNYgz6Bdw X-IronPort-AV: E=Sophos;i="5.01,477,1400025600"; d="scan'208";a="53067492" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 14 Jun 2014 11:53:28 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5EBrQY9025244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Jun 2014 11:53:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Sat, 14 Jun 2014 06:53:26 -0500 From: "Ken Gray (kegray)" To: Loa Andersson Subject: Re: big equal to inefficient ?? Thread-Topic: big equal to inefficient ?? Thread-Index: AQHPhf11PXEaUdq3Sk+tmjLNLEC6D5tuZkcAgAAHDoCAAFtygIAAnoQAgAENfQCAAA28pQ== Date: Sat, 14 Jun 2014 11:53:25 +0000 Message-ID: <1B424564-6358-4540-B50C-76E4E4DDB8D4@cisco.com> References: <53993792.3050902@pi.nu> <539A2C36.2030907@labn.net> <054701cf8692$c05029e0$40f07da0$@olddog.co.uk> <539A7ED7.1050401@pi.nu> <20140613135944.GA10109@pfrc>,<539BE5E0.5050507@pi.nu> In-Reply-To: <539BE5E0.5050507@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/zb8MLM3ljdKXZxrgdLdtTG0GZTg Cc: "adrian@olddog.co.uk" , Lou Berger , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 11:53:29 -0000 I will note that the "bar bof" motif has been good for discussion. Maybe e= very WG needs to hold one - to enable the less socially skilled. Of course= , that could lead to a particularly hard Friday. =20 Sent from my iPhone > On Jun 14, 2014, at 4:04 PM, "Loa Andersson" wrote: >=20 > Jeff, >=20 >> On 2014-06-13 15:59, Jeffrey Haas wrote: >>> On Fri, Jun 13, 2014 at 06:32:23AM +0200, Loa Andersson wrote: >>> Please note: >>>=20 >>> I'm not saying that we should not re-organize, but I've so far not >>> found THE principle according to which we can re-organize the entire >>> area. >>=20 >> I'm also wondering as we continue this discussion whether we're tailorin= g >> our comments way too much around observations of meeting sessions rather >> than the overall work. Much (should) happen on the mailing lists. >>=20 >> -- Jeff >=20 > I think you are heads on! >=20 > There are issues that are focused on the F2F meetings. It seems that > they are possible manage within the current area structure. We might > want to make sure that the re-org actions we take don't make them worse, > e.g. more working harder scheduling. >=20 > If we consider the work on the mailing, I do not see that the signal-to- > noise ratio is a real problem. Maybe sometimes the signal is to weak > (not enough discussion). >=20 > One of my co-chairs has often said "quality takes time", I agree > thinking things through one extra time improve quality and probably > save working time in the long run. This begs the question how we > measure speed and efficiency. >=20 > I'd say (maybe I'm as old-fashion as Ken) take more work to the mailing > lists, but use the tools you need. If you need a dt have one, if you > need an interim do one, etc. However we should remember that discussions > in the IETF happens on mailings lists. >=20 > Over the last few years we have tweaked the MPLS wg process, one thing > we done is to require that authors that update their documents due to > comments confirm with the people making the comments that they are > comfortable with how the comment has been addressed. >=20 > /Loa >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Sat Jun 14 05:26:07 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFBF1B2845 for ; Sat, 14 Jun 2014 05:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySWsopFGWDHz for ; Sat, 14 Jun 2014 05:26:04 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 85C381A0463 for ; Sat, 14 Jun 2014 05:26:04 -0700 (PDT) Received: (qmail 31552 invoked by uid 0); 14 Jun 2014 12:26:02 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 14 Jun 2014 12:26:02 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id ECRx1o00T2SSUrH01CS0sP; Sat, 14 Jun 2014 06:26:02 -0600 X-Authority-Analysis: v=2.1 cv=d4pml3TE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=tcnv99F1KMcA:10 a=C8UVKu96udcA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=wmjEQDUgffbfiokuLjoA:9 a=xSM0lzeksbJmm1nu:21 a=XQAtCXv84x-nP7GH:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5wukIKG+aH8jwnz0yivPtXxbui3agp2zPrJKRZGLiKk=; b=RMKPHcbXO89ffxySbFgD2/LVqIktLDai7ibjt85/ncAZz3Q9vfXNSBulk/AnLYujeVO0GX7xq5zyEGXeJ1Q7xK1QU1cYsA4TRgJSKzUxNzSOzjLECdVE/qdm0la4JMM6; Received: from box313.bluehost.com ([69.89.31.113]:37668 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Wvn1x-0003F8-J9; Sat, 14 Jun 2014 06:25:57 -0600 Message-ID: <539C3F4E.8050302@labn.net> Date: Sat, 14 Jun 2014 08:25:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/QG-vK4-S4i9bJA_CnVgBMbQS6kE Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 12:26:05 -0000 On 6/13/2014 12:58 AM, Alia Atlas wrote: > > We all suffer from the Bystander effect (i.e. someone else will take > care of it) when a group gets too large. > > Alia > So "Giant" = number of attendees in the room (or active on the list)? Unless the split results in meeting time overlap, I don't see how splitting groups helps. Are you trying to address the tourism effect? (Which by the way is one of my pet peeves, but I've given up on getting our "leadership" to not choose meeting destinations based on the number of IETF tourists that will show.) Lou From nobody Sat Jun 14 05:51:52 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E652D1B28E7 for ; Sat, 14 Jun 2014 05:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sMDXH9wUF-q for ; Sat, 14 Jun 2014 05:51:47 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2ED1B2840 for ; Sat, 14 Jun 2014 05:51:47 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 93FEB18015A1; Sat, 14 Jun 2014 14:51:45 +0200 (CEST) Message-ID: <539C455C.70007@pi.nu> Date: Sat, 14 Jun 2014 14:51:40 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Lou Berger Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> <539C3F4E.8050302@labn.net> In-Reply-To: <539C3F4E.8050302@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/cz0IQ7D1wboeG5ge1ep71mcZBlQ Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 12:51:50 -0000 Lou, I think there is a pretty strong agreement splitting the "giants" (who ever came up with that name) doesn't help. What we do in one or two slots we will have to do in 6 or 7. In stead of being subscribed to 1 or two mailing lists, there will two handfuls, and a very tricky coordination to reach even the roughest consensus. /Loa PS BTW how big is the tourist problem, lot of people milling around on Sun and Mon, and then gradually declining towards the end of the week. On 2014-06-14 14:25, Lou Berger wrote: > > On 6/13/2014 12:58 AM, Alia Atlas wrote: >> >> We all suffer from the Bystander effect (i.e. someone else will take >> care of it) when a group gets too large. >> >> Alia >> > > So "Giant" = number of attendees in the room (or active on the list)? > Unless the split results in meeting time overlap, I don't see how > splitting groups helps. > > Are you trying to address the tourism effect? (Which by the way is one > of my pet peeves, but I've given up on getting our "leadership" to not > choose meeting destinations based on the number of IETF tourists that > will show.) > > Lou > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jun 14 06:33:35 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DDC1B2817 for ; Sat, 14 Jun 2014 06:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeHP1sX3TU_I for ; Sat, 14 Jun 2014 06:33:28 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC5A1B27E6 for ; Sat, 14 Jun 2014 06:33:28 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5EDXQJ9010977; Sat, 14 Jun 2014 14:33:26 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5EDXPKM010967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 14 Jun 2014 14:33:25 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , "'Lou Berger'" References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> <539C3F4E.8050302@labn.net> <539C455C.70007@pi.nu> In-Reply-To: <539C455C.70007@pi.nu> Subject: RE: big equal to inefficient ?? Date: Sat, 14 Jun 2014 14:33:24 +0100 Message-ID: <031c01cf87d5$383401f0$a89c05d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ49XGl5BHz38NpjlBR+RczDMF60wJf08hdAejRXpcBq/BoUQLsbsm+A1xvq9cCED4D3AHm0VDkAzNkA7YCNo94rwJKa2A8ApvuSYmZSZg2cA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20756.007 X-TM-AS-Result: No--23.458-10.0-31-10 X-imss-scan-details: No--23.458-10.0-31-10 X-TMASE-MatchedRID: eVEkOcJu0F5i8tNcpebA1hJmPIoQFzZ7bor1T6xK0ywReIfA/cGQnUc5 A85pTadYWxwLlsLfqJjxTwx4UJIMcqHNozT622Z4r04R126GsicZskwWqoib3FpbYq2f4jz+q4H OBho/QmHA1k+nsCg3dztYylK9liNEMrjYlVK+7cDMuewaQUInJO6vBRO2P4iNipSe9U1/foPabn 9rCMsYTrPNDQwlEmET4ssGb1onzrTtgYgBGmF9nnypjffgdgMPEeXPNyiMU05A9Ad+70Nuk+hB9 8At7WTU5glg0v07FvWV5YoiAvCJA3YuMvx6NP8AnVTWWiNp+v9BldmDYjwlpgzzaIyrVuO8MR6S o5klILP6aoE0USt6cpGTpe1iiCJqtD9qpBlNF8pWdFebWIc3VsRB0bsfrpPI6T/LTDsmJmg= Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/JUbyHCQeBOQ1n46CIWO_-pRLS4Y Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 13:33:31 -0000 In the interests of stirring this particular pot to see what floats to the surface... If splitting existing WGs would not be of any specific benefit, why don't we merge a few WGs? After all, most people who go to CCAMP also go to MPLS, so surely joining them would be beneficial. Adrian > -----Original Message----- > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: 14 June 2014 13:52 > To: Lou Berger > Cc: routing-discussion@ietf.org > Subject: Re: big equal to inefficient ?? > > Lou, > > I think there is a pretty strong agreement splitting the "giants" (who > ever came up with that name) doesn't help. What we do in one or two > slots we will have to do in 6 or 7. In stead of being subscribed to > 1 or two mailing lists, there will two handfuls, and a very tricky > coordination to reach even the roughest consensus. > > > /Loa > > PS > > BTW how big is the tourist problem, lot of people milling around on > Sun and Mon, and then gradually declining towards the end of the > week. > > On 2014-06-14 14:25, Lou Berger wrote: > > > > On 6/13/2014 12:58 AM, Alia Atlas wrote: > >> > >> We all suffer from the Bystander effect (i.e. someone else will take > >> care of it) when a group gets too large. > >> > >> Alia > >> > > > > So "Giant" = number of attendees in the room (or active on the list)? > > Unless the split results in meeting time overlap, I don't see how > > splitting groups helps. > > > > Are you trying to address the tourism effect? (Which by the way is one > > of my pet peeves, but I've given up on getting our "leadership" to not > > choose meeting destinations based on the number of IETF tourists that > > will show.) > > > > Lou > > > > > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www.ietf.org/mailman/listinfo/routing-discussion > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Sat Jun 14 07:08:52 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623201B286C for ; Sat, 14 Jun 2014 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxVLAapV284C for ; Sat, 14 Jun 2014 07:08:49 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 4C9971B2853 for ; Sat, 14 Jun 2014 07:08:49 -0700 (PDT) Received: (qmail 9805 invoked by uid 0); 14 Jun 2014 14:08:46 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 14 Jun 2014 14:08:46 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EE8V1o00T2SSUrH01E8YFl; Sat, 14 Jun 2014 08:08:46 -0600 X-Authority-Analysis: v=2.1 cv=CpMsLBID c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=KZjT-1wHC7QA:10 a=C8UVKu96udcA:10 a=HFCU6gKsb0MA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=N8g2Tqn8GAcA:10 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=lJIjCvM83ura1zzHPFwA:9 a=UeUeSvwk2tvGmn3P:21 a=IzXuBy-jd3tMg7ML:21 a=CjuIK1q_8ugA:10 a=jqlaW5bC1iAA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=mZd7tn3ZNWw0wx1HV85tjFgvxiS7cBf2LnJBjP7qxD0=; b=2SEtt90/HT97/0QxDmbIyJDRM8f7BydDn96jhGiZ2dkravsyouw/ftttqYFlBgkmA4eZxPg0JNcZk3+eZum9kSpab4MXW9FUlmgMDvZPZWJIb1MJFkZisxIZCnQYpkgU; Received: from [70.192.209.112] (port=2812 helo=[10.188.175.89]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WvodB-0004KF-2n; Sat, 14 Jun 2014 08:08:29 -0600 From: Lou Berger To: , "'Loa Andersson'" Date: Sat, 14 Jun 2014 10:08:27 -0400 Message-ID: <1469ab52bd8.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <031c01cf87d5$383401f0$a89c05d0$@olddog.co.uk> References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> <539C3F4E.8050302@labn.net> <539C455C.70007@pi.nu> <031c01cf87d5$383401f0$a89c05d0$@olddog.co.uk> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.3.8 (build: 2100414) Subject: RE: big equal to inefficient ?? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 70.192.209.112 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Ms10LxgVykAQIEzflhxDpkk5zAI Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 14:08:50 -0000 Do I hear a new area being proposed? :-) On June 14, 2014 9:34:02 AM "Adrian Farrel" wrote: > In the interests of stirring this particular pot to see what floats to the > surface... > > If splitting existing WGs would not be of any specific benefit, why don't we > merge a few WGs? After all, most people who go to CCAMP also go to MPLS, so > surely joining them would be beneficial. > > Adrian > > > > -----Original Message----- > > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On > Behalf > > Of Loa Andersson > > Sent: 14 June 2014 13:52 > > To: Lou Berger > > Cc: routing-discussion@ietf.org > > Subject: Re: big equal to inefficient ?? > > Lou, > > I think there is a pretty strong agreement splitting the "giants" (who > > ever came up with that name) doesn't help. What we do in one or two > > slots we will have to do in 6 or 7. In stead of being subscribed to > > 1 or two mailing lists, there will two handfuls, and a very tricky > > coordination to reach even the roughest consensus. > > > > /Loa > > PS > > BTW how big is the tourist problem, lot of people milling around on > > Sun and Mon, and then gradually declining towards the end of the > > week. > > On 2014-06-14 14:25, Lou Berger wrote: > > > > > > On 6/13/2014 12:58 AM, Alia Atlas wrote: > > >> > > >> We all suffer from the Bystander effect (i.e. someone else will take > > >> care of it) when a group gets too large. > > >> > > >> Alia > > >> > > > > > > So "Giant" = number of attendees in the room (or active on the list)? > > > Unless the split results in meeting time overlap, I don't see how > > > splitting groups helps. > > > > > > Are you trying to address the tourism effect? (Which by the way is one > > > of my pet peeves, but I've given up on getting our "leadership" to not > > > choose meeting destinations based on the number of IETF tourists that > > > will show.) > > > > > > Lou > > > > > > > > > > > > _______________________________________________ > > > routing-discussion mailing list > > > routing-discussion@ietf.org > > > https://www.ietf.org/mailman/listinfo/routing-discussion > > > > > -- > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Sat Jun 14 07:23:30 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97B1B28F1 for ; Sat, 14 Jun 2014 07:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Dtvhw9Ti4uH for ; Sat, 14 Jun 2014 07:23:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B291B286E for ; Sat, 14 Jun 2014 07:23:25 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id BBF7E18013DA; Sat, 14 Jun 2014 16:23:22 +0200 (CEST) Message-ID: <539C5AD4.6030004@pi.nu> Date: Sat, 14 Jun 2014 16:23:16 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, 'Lou Berger' Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> <539C3F4E.8050302@labn.net> <539C455C.70007@pi.nu> <031c01cf87d5$383401f0$a89c05d0$@olddog.co.uk> In-Reply-To: <031c01cf87d5$383401f0$a89c05d0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/iEIPmvq3VcTPu3abCKUow473ipg Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 14:23:28 -0000 Adrian, I had to go out and walk the dog for a while. no pun intended this is a quite young puppy that really don't understand how to stay out of underfoot. Keep my mind on something else for a while. How not to step on the puppy. No - I think you are making the same mistake again. The number of peopel (unless maybe in the case that they are getting close to zero) does not have anything to do with how we set up wg's. I'd even say that if we were to start from scratch it is unlikely that we come with the current distribution of wg's. But that is moot, we have a history and I honestly think that the "giant" (your term not mine) working group also have an almost giant experience of efficiently run the working groups. Anyone that reads this to say the current chairs should continue to run the working groups, have to go back and read again. The point is that *the working group* has that giant experience, the individuals are not *that* important. The organizational principle I think we should use for gradual re-org of our working groups is that we should build on the history and improve where we can. An example - let us say that we two working group (with what have come to see as "overlap"), i.e. wg A are chartered to do m, n and o and wg B are chartered to p, q and r. And when A do anything on m, we repeatedly find that we have to cross-review that with the part of B that are doing q, and vice versa. Closer investigating this might lead us to see that some re-org would be beneficial. We could move m and q to a new working group, but if q and r closely related and would cause the same problem again across another interface this might not be a good idea; moving q to A or M to B might be better. My point here is that - with 25 years history - grand new re-org attempts are likely to cause more problems than they solve. Scratch the "re-org the area" scheme and work with the wg's, the wg chair and leadership in general to solve issues where we see problem. Small scale rather than big scale. /Loa On 2014-06-14 15:33, Adrian Farrel wrote: > In the interests of stirring this particular pot to see what floats to the > surface... > > If splitting existing WGs would not be of any specific benefit, why don't we > merge a few WGs? After all, most people who go to CCAMP also go to MPLS, so > surely joining them would be beneficial. > > Adrian > > >> -----Original Message----- >> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On > Behalf >> Of Loa Andersson >> Sent: 14 June 2014 13:52 >> To: Lou Berger >> Cc: routing-discussion@ietf.org >> Subject: Re: big equal to inefficient ?? >> >> Lou, >> >> I think there is a pretty strong agreement splitting the "giants" (who >> ever came up with that name) doesn't help. What we do in one or two >> slots we will have to do in 6 or 7. In stead of being subscribed to >> 1 or two mailing lists, there will two handfuls, and a very tricky >> coordination to reach even the roughest consensus. >> >> >> /Loa >> >> PS >> >> BTW how big is the tourist problem, lot of people milling around on >> Sun and Mon, and then gradually declining towards the end of the >> week. >> >> On 2014-06-14 14:25, Lou Berger wrote: >>> >>> On 6/13/2014 12:58 AM, Alia Atlas wrote: >>>> >>>> We all suffer from the Bystander effect (i.e. someone else will take >>>> care of it) when a group gets too large. >>>> >>>> Alia >>>> >>> >>> So "Giant" = number of attendees in the room (or active on the list)? >>> Unless the split results in meeting time overlap, I don't see how >>> splitting groups helps. >>> >>> Are you trying to address the tourism effect? (Which by the way is one >>> of my pet peeves, but I've given up on getting our "leadership" to not >>> choose meeting destinations based on the number of IETF tourists that >>> will show.) >>> >>> Lou >>> >>> >>> >>> _______________________________________________ >>> routing-discussion mailing list >>> routing-discussion@ietf.org >>> https://www.ietf.org/mailman/listinfo/routing-discussion >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sat Jun 14 07:24:52 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C0C1B286E for ; Sat, 14 Jun 2014 07:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_aPK-iS7XrE for ; Sat, 14 Jun 2014 07:24:50 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9ACD1B2853 for ; Sat, 14 Jun 2014 07:24:49 -0700 (PDT) Received: from [192.168.1.8] (unknown [112.208.107.184]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 155F918013DA; Sat, 14 Jun 2014 16:24:44 +0200 (CEST) Message-ID: <539C5B1F.9020300@pi.nu> Date: Sat, 14 Jun 2014 16:24:31 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Lou Berger , adrian@olddog.co.uk Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> <539C3F4E.8050302@labn.net> <539C455C.70007@pi.nu> <031c01cf87d5$383401f0$a89c05d0$@olddog.co.uk> <1469ab52bd8.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <1469ab52bd8.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/EE3kImBNl3GMQeg6QghWNg21J24 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 14:24:51 -0000 revival of sub-IP :) /Loa On 2014-06-14 16:08, Lou Berger wrote: > Do I hear a new area being proposed? > > :-) > > > On June 14, 2014 9:34:02 AM "Adrian Farrel" wrote: > >> In the interests of stirring this particular pot to see what floats to >> the >> surface... >> >> If splitting existing WGs would not be of any specific benefit, why >> don't we >> merge a few WGs? After all, most people who go to CCAMP also go to >> MPLS, so >> surely joining them would be beneficial. >> >> Adrian >> >> >> > -----Original Message----- >> > From: routing-discussion >> [mailto:routing-discussion-bounces@ietf.org] On >> Behalf >> > Of Loa Andersson >> > Sent: 14 June 2014 13:52 >> > To: Lou Berger >> > Cc: routing-discussion@ietf.org >> > Subject: Re: big equal to inefficient ?? >> > Lou, >> > I think there is a pretty strong agreement splitting the "giants" (who >> > ever came up with that name) doesn't help. What we do in one or two >> > slots we will have to do in 6 or 7. In stead of being subscribed to >> > 1 or two mailing lists, there will two handfuls, and a very tricky >> > coordination to reach even the roughest consensus. >> > >> > /Loa >> > PS >> > BTW how big is the tourist problem, lot of people milling around on >> > Sun and Mon, and then gradually declining towards the end of the >> > week. >> > On 2014-06-14 14:25, Lou Berger wrote: >> > > >> > > On 6/13/2014 12:58 AM, Alia Atlas wrote: >> > >> >> > >> We all suffer from the Bystander effect (i.e. someone else will take >> > >> care of it) when a group gets too large. >> > >> >> > >> Alia >> > >> >> > > >> > > So "Giant" = number of attendees in the room (or active on the list)? >> > > Unless the split results in meeting time overlap, I don't see how >> > > splitting groups helps. >> > > >> > > Are you trying to address the tourism effect? (Which by the way is >> one >> > > of my pet peeves, but I've given up on getting our "leadership" to >> not >> > > choose meeting destinations based on the number of IETF tourists that >> > > will show.) >> > > >> > > Lou >> > > >> > > >> > > >> > > _______________________________________________ >> > > routing-discussion mailing list >> > > routing-discussion@ietf.org >> > > https://www.ietf.org/mailman/listinfo/routing-discussion >> > > >> > -- >> > >> > Loa Andersson email: loa@mail01.huawei.com >> > Senior MPLS Expert loa@pi.nu >> > Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > _______________________________________________ >> > routing-discussion mailing list >> > routing-discussion@ietf.org >> > https://www.ietf.org/mailman/listinfo/routing-discussion >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >> > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Mon Jun 16 07:03:25 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D711A0047 for ; Mon, 16 Jun 2014 07:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbXu_wNOsrMk for ; Mon, 16 Jun 2014 07:03:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 686321A004A for ; Mon, 16 Jun 2014 07:03:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DF001C406; Mon, 16 Jun 2014 10:03:18 -0400 (EDT) Date: Mon, 16 Jun 2014 10:03:18 -0400 From: Jeffrey Haas To: "Fedyk, Don" Subject: Re: Have an interim Meeting was RE: big equal to inefficient ?? Message-ID: <20140616140318.GC25292@pfrc> References: <8090206f8703405e9ffb4149326e973c@CO2PR05MB636.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645D3540B@dfweml701-chm.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/RTNTipzYocg6OHXCISudz8-Sheo Cc: Ross Callon , Stewart Bryant , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:03:23 -0000 On Fri, Jun 13, 2014 at 09:41:12PM +0000, Fedyk, Don wrote: > Well I've noticed that when a meeting finishes a bit early that people > often stick around for a bit of discussion but if you pack the agenda to > the limit everyone is tearing out to the next slot/dinner. Could we script > a 5 minute free discussion or would people just adapt and leave the room > earlier? This has happened at the very least in BFD and GROW. BFD was a partial meeting slot filled with content and then a MIB design session - sparsely attended as you may imagine but highly productive. GROW had a similar discussion element to work on the BMP protocol. I think there are two observations that come from this: - If your meeting slots are so filled that you're not getting *any* useful discussion, why was there a presentation? IMO, see comments from the plenary session where meeting effectiveness was discussed. - Leave time at the end of your sessions so that people can have that productive hall conversation. For my part, I think I'll try to skip some of my usual meeting ghosting that I often do to pick up on areas I don't follow strongly and declare at least one timeslot "bar office hours". -- Jeff From nobody Wed Jun 18 03:53:57 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C608A1A018F for ; Wed, 18 Jun 2014 03:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FilipuxVhOwA for ; Wed, 18 Jun 2014 03:53:52 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9491A018E for ; Wed, 18 Jun 2014 03:53:52 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id a41so438792yho.16 for ; Wed, 18 Jun 2014 03:53:51 -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=ZisLJ1xaTxHdBv01mOTKen01aeD6yGzUPavHeF1JF+4=; b=OU+F6EDye+M4U9anOORbr5GNx6E2uHTOi7nkbVOKlpwY0t9BQ9x4NvKpIDw8ujMK8P LYaijSS/Hgk2XbzLwm8bfiucUaHZ/BY6upKJqavEo7US5lQqoKFqZvHoUmkUy1+re0Xa 1/9XwY6fHXr0u6YycmciJ+5kDqO9KnzsTs/2tI1W7tXp2lGWXmWgj3Yu9DvrvUNjfv9Q xqLMocP9MuoZSe9KRKV0AD5SI6Ax3apRYnPqBMiCxyG60alBbdpUwBwctHGhIV329cOB mMmsSzCLi+2G71+BsJIORedRlmYOhGLGBtLcukProwp4b/yQlM9Bpkb0ibpnx/vzpEOf ZA5Q== MIME-Version: 1.0 X-Received: by 10.236.101.198 with SMTP id b46mr53989423yhg.68.1403088831451; Wed, 18 Jun 2014 03:53:51 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Wed, 18 Jun 2014 03:53:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jun 2014 11:53:51 +0100 Message-ID: Subject: Re: Improving and Restructuring the Routing Area From: Abdussalam Baryun To: Alia Atlas Content-Type: multipart/alternative; boundary=20cf30050b2263160604fc1a138e Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/z5x8t-pz_CitLAInh8YS1q_Dz58 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 10:53:55 -0000 --20cf30050b2263160604fc1a138e Content-Type: text/plain; charset=UTF-8 Thanks Alia and Adrian, Dear All, I agree that the area should restructure and follow more clear IETF-management-objectives for the area. I will try mt best to comment but that does not mean my input is best, just writting thoughts which may help. Some suggested before that WGs were not working together, they are separate, and that it was not the way of progress.Your message did not mention the reasons of this or did not define the problem. I think the main problem is the management not the participants or the organising of concensus, if we know the reasons of our problem it is the best start to avoid it repeat. My comments/discuusion below: I will start with the last paragraph: {For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion.} Two thinking points : a) I see the discussion can be: 1) Area Restructure, 2) WGs Reorganising or closing, 3) WG's Charters and Functions. Please show us the way for future discussings. b) IETF Routing Area performance after change. What is the principle reasons to make us do closing a WG or merging some WGs into one? Please note that there are possibilities that other organisations may like to close many IETF-WGs but is that good for the community? Will we have the same speed after reorganising? more below: On Tue, Jun 10, 2014 at 8:57 PM, Alia Atlas wrote: > To all participants in the Routing Area, > > Adrian and I are working on improving the quality, speed, and > experience of getting work done in the IETF Routing Area. There are > three initiatives that we are working: WG Draft QA, Routing Area > specific WG chair training, and reorganizing the working groups in the > area. > Why are they the only priority? I suggest to add Participation and Management Quality Assurance, the problem is not the draft but is who are working in the WG with Chair with AD. If we get reasonable participation and more volunteering and more acknowledgemnts, then we will get better drafts. > > First, we intend to use our Routing Directorate more proactively by > introducing a Working Group Draft Quality Assurance (WG Draft QA) > process where the same selected routing directorate member will review > a draft during WG draft adoption and during WG last call. The process > will be documented on the Routing Area wiki > (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow > directorate reviews to report technical issues that can actually get > fixed early in the process (equivalent of bug reports) as opposed to > just noting the concerns in the drafts (equivalent of release notes). > > Second, as was discussed during the recent IESG retreat, in addition > to the IETF-wide WG chair training, we intend to have a series of > training sessions for WG Chairs in the Routing Area addressing topics > such as judging consensus, project management, motivating volunteers, > using the datatracker (via a sandbox version that can be played > with safely), and sharing experiences between WG chairs. > In my opinion, the WG chairs in this area should communicate more often on the lists, some WGs do already and they make it work with quality but some WG have busy Chairs therefore we get low quality in participation and reviews. The ADs should force Editors and Chairs to volunteer more. I had a comment to an editor in another area but still got no respond because the chair/AD accepted that behavior, and I did not. > > Third, we intend to reorganize the working groups in the Routing area. > We feel that it is important to focus on areas where there is active > interest in standardization and to be open and able to accept new work > into the area. As you know, we have had several new working groups > (nvo3, i2rs, sfc, spring) created in the last few years and we need to > be open and able to handle more new work as it comes in. We would > also like to improve the signal-to-noise ratio experienced by > participants in the different working groups and improve the quantity > and quality of discussion and reviews. It is likely that not all WGs > in the Routing Area will be directly affected. > > Here is the time-line for reorganizing the WGs. > > NOW: public discussion on routing-discussion@ietf.org about how to > reorganize the working groups to best meet our motivations. > Additional focused discussions are expected on the > rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. > > In Toronto: There will be meetings with the WG chairs and the > Routing Directorate to get the ideas described and agreed upon. > Please report the results and what will be done to this list, because you may meet any time but what is the value/results of the meeting is more important. > > At the Routing Area Meeting in Toronto: Discuss the set of > reorganized WGs and general charter content in the Routing Area > meeting. > I suggest, first each WG in the area discuss and deliver a report to the ADs of their feedback with WG consensus. > > September 2014: Based upon the feedback, suggestions, and > discussion, Adrian and I finalize the reorganized WG charters. We > start the internal IESG discussion and public reviews. > I suggest that ADs receive from individuals feedback and also from WG feedbacks (including its recharter ideas), so each WG have discussed on its list and gave it WG report to ADs and then here in this list each individual can put their individual opinion. > > October 2014: Formal rechartering process completes. > Recharter is not enough, to solve the current issue you want to solve. > > In Honolulu: The new set of WGs meet. > > After Honolulu: Adrian and I deal with any issues and charter > updates based upon a few months of experience. > > Here are the motivations that Adrian and I would like to be considered > when coming up with ideas for how the WGs should be reorganized. > > 1) Move towards organizing working groups on functional > responsibilities rather than scoping them to specific protocols. > IMO, that is not enough, you need first to make sure that each one WG is organised, then you start moving toward organising WGs. > > 2) Split giant working groups so relevant work is done in one place > and there is an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. > IMHO, that is very wrong decision, please why we separating while we want to organise and volunteer together. This > > 3) Create synergies for scattered functionality (example ideas: > OAM, FRR, traffic-engineering) > > 4) Create a DISPATCH working group for clear new idea discussion; > rtgwg serves some of this purpose but doesn't have a clear process > and isn't drawing in the new ideas. > This preferable to be f2f meeting only WG. > > 5) Focus Routing Area time on design centers rather than on far > corner cases. > > 6) Each working group should have clear, well defined, and achievable > goals. > This should be in the charter and ADs should follow up with the goals and milestones. > > Noting that the Routing Area has inherited some of its WG structure > from the sub-IP area, it is not a goal to force IP routing and MPLS > routing to remain separated. > > The goal of this reorganization is not closing working groups. Adrian > and Alia are perfectly capable of closing working groups without going > through restructuring. > IMO, usually restructure is more about managment (ADs, Chairs, and departments) than about participants work. Reorganising and closing WG is necessary at any time if there is a need which does not affect each work/draft/participant. > > For those of you that have read this far, thank you. Getting this 80% > right is going to take some serious discussion and thought. We all > work in the Routing Area together with different perspectives. Please > think carefully and help us have a highly focused discussion. > > Thanks, > Alia and Adrian > Thanks, AB --20cf30050b2263160604fc1a138e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Alia and Adrian,
=C2=A0
Dear All,
=C2=A0
I agree that the area should restructure and follow more clear IETF-ma= nagement-objectives for the area.=C2=A0I will try mt best to comment but th= at does not mean my input is best, just writting thoughts which may help. S= ome suggested before that WGs=C2=A0were not working together, they are sepa= rate, and that it=C2=A0was not the way of progress.Your message did not men= tion the reasons of this=C2=A0or did not define the problem.=C2=A0 I think = the main problem is the management not the participants or the organising o= f concensus, if we know the reasons of our problem it is the best start to = avoid it repeat.
=C2=A0
My comments/discuusion below:
=C2=A0
I will start with the last paragraph:
=C2=A0
{For those of you that have read this far, thank you. =C2=A0Getting th= is 80%
right is going to take some serious discussion and thought. =C2=A0We a= ll
work in the Routing Area together with different perspectives. =C2=A0P= lease
think carefully and help us have a highly focused discussion.}
=C2=A0
Two thinking points=C2=A0:
=C2=A0
a) I see the discussion can be: 1) Area Restructure, 2) WGs Reorganisi= ng=C2=A0or closing, 3) WG's Charters and Functions. Please show us the = way for future discussings.
=C2=A0
b) IETF Routing Area performance after change.=C2=A0What is the princi= ple reasons=C2=A0to make us do=C2=A0closing a WG or merging=C2=A0some WGs i= nto one? Please note that there are possibilities that other organisations = may like to close many IETF-WGs but is that good for the community? Will we= have the same speed after reorganising?
=C2=A0
more below:

On Tue, Jun 10, 2014 at 8:57 PM, Alia Atlas <ak= atlas@gmail.com> wrote:
To all participants in the Routing Area,

Adrian and I are working on improving the quality, speed, and
experience of getting work done in the IETF Routing Area. =C2=A0There = are
three initiatives that we are working: WG Draft QA, Routing Area
specific WG chair training, and reorganizing the working groups in the=
area.
=C2=A0
Why are they the only priority? I suggest to add Participation and Man= agement Quality Assurance, the problem is not the draft but is who are work= ing in the WG with Chair with AD. If we get=C2=A0reasonable participation a= nd more volunteering and more acknowledgemnts, then we will get better draf= ts.
=C2=A0

First, we intend to use our Routing Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft QA)
process where the same selected routing directorate member will review=
a draft during WG draft adoption and during WG last call. =C2=A0The pr= ocess
will be documented on the Routing Area wiki
directorate reviews to report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release notes).<= /div>

Second, as was discussed during the recent IESG retreat, in addition
to the IETF-wide WG chair training, we intend to have a series of
training sessions for WG Chairs in the Routing Area addressing topics<= /div>
such as judging consensus, project management, motivating volunteers,<= /div>
using the datatracker (via a sandbox version that can be played
with safely), and sharing experiences between WG chairs.
=C2=A0
In my opinion, the WG chairs in this area should communicate more ofte= n on the lists, some WGs do already and they make it work with quality but = some WG have busy Chairs therefore we get low quality in participation and = reviews. The ADs should force Editors and Chairs to volunteer more. I had a= comment to an editor in another area but still got no respond because the = chair/AD accepted that behavior, and I did not.
=C2=A0

Third, we intend to reorganize the working groups in the Routing area.=
We feel that it is important to focus on areas where there is active
interest in standardization and to be open and able to accept new work=
into the area. =C2=A0As you know, we have had several new working grou= ps
(nvo3, i2rs, sfc, spring) created in the last few years and we need to=
be open and able to handle more new work as it comes in. =C2=A0We woul= d
also like to improve the signal-to-noise ratio experienced by
participants in the different working groups and improve the quantity<= /div>
and quality of discussion and reviews. =C2=A0It is likely that not all= WGs
in the Routing Area will be directly affected.

Here is the time-line for reorganizing the WGs.

=C2=A0 =C2=A0NOW: public discussion on routing-discussion@ietf.org about how= to
=C2=A0 =C2=A0reorganize the working groups to best meet our motivation= s.
=C2=A0 =C2=A0Additional focused discussions are expected on the
=C2=A0 =C2=A0= rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists.

=C2=A0 =C2=A0In Toronto: There will be meetings with the WG chairs and= the
=C2=A0 =C2=A0Routing Directorate to get the ideas described and agreed= upon.
=C2=A0
Please report the results and what will be done to this list, because = you may meet any time but what is the value/results of the meeting is more = important.
=C2=A0

=C2=A0 =C2=A0At the Routing Area Meeting in Toronto: Discuss the set o= f
=C2=A0 =C2=A0reorganized WGs and general charter content in the Routin= g Area
=C2=A0 =C2=A0meeting.
=C2=A0
I suggest, first each WG in the area discuss and deliver a report to t= he ADs of their feedback with WG consensus.
=C2=A0

=C2=A0 =C2=A0September 2014: Based upon the feedback, suggestions, and=
=C2=A0 =C2=A0discussion, Adrian and I finalize the reorganized WG char= ters. =C2=A0We
=C2=A0 =C2=A0start the internal IESG discussion and public reviews.
=C2=A0
I suggest that ADs receive from individuals feedback and also from WG = feedbacks (including its recharter ideas), so each WG have discussed on its= list and gave=C2=A0it WG=C2=A0report to ADs and then here in this list eac= h individual can put their individual opinion.
=C2=A0

=C2=A0 =C2=A0October 2014: Formal rechartering process completes.
=C2=A0
Recharter is not enough, to solve the current issue you want to solve.=
=C2=A0

=C2=A0 =C2=A0In Honolulu: The new set of WGs meet.

=C2=A0 =C2=A0After Honolulu: Adrian and I deal with any issues and cha= rter
=C2=A0 =C2=A0updates based upon a few months of experience.

Here are the motivations that Adrian and I would like to be considered=
when coming up with ideas for how the WGs should be reorganized.

=C2=A0 =C2=A01) Move towards organizing working groups on functional
=C2=A0 =C2=A0responsibilities rather than scoping them to specific pro= tocols.
=C2=A0
IMO, that is not enough, you need first to make sure that=C2=A0each on= e WG is organised, then you start moving toward organising WGs.
=C2=A0

=C2=A0 =C2=A02) Split giant working groups so relevant work is done in= one place
=C2=A0 =C2=A0and there is an improved signal-to-noise ratio for partic= ipants who
=C2=A0 =C2=A0are only interested in a slice of the current working gro= up's work.
=C2=A0
IMHO, that is very wrong decision, please why we separating while we w= ant to organise and volunteer together. This

=C2=A0 =C2=A03) Create synergies for scattered functionality (example = ideas:
=C2=A0 =C2=A0OAM, FRR, traffic-engineering)

=C2=A0 =C2=A04) Create a DISPATCH working group for clear new idea dis= cussion;
=C2=A0 =C2=A0rtgwg serves some of this purpose but doesn't have a = clear process
=C2=A0 =C2=A0and isn't drawing in the new ideas.
=C2=A0
This preferable to=C2=A0be f2f=C2=A0meeting only WG.
=C2=A0

=C2=A0 =C2=A05) Focus Routing Area time on design centers rather than = on far
=C2=A0 =C2=A0corner cases.

=C2=A0 =C2=A06) Each working group should have clear, well defined, an= d achievable goals.
=C2=A0
This should be in the charter and ADs should follow up with the goals = and milestones.
=C2=A0

Noting that the Routing Area has inherited some of its WG structure
from the sub-IP area, it is not a goal to force IP routing and MPLS
routing to remain separated.

The goal of this reorganization is not closing working groups. =C2=A0A= drian
and Alia are perfectly capable of closing working groups without going=
through restructuring.
=C2=A0
IMO, usually restructure is more about managment (ADs, Chairs, and dep= artments)=C2=A0than about participants work. Reorganising and closing WG is= necessary at any time if there is a need which does not affect each work/d= raft/participant.
=C2=A0

For those of you that have read this far, thank you. =C2=A0Getting thi= s 80%
right is going to take some serious discussion and thought. =C2=A0We a= ll
work in the Routing Area together with different perspectives. =C2=A0P= lease
think carefully and help us have a highly focused discussion.

Thanks,
Alia and Adrian
=C2=A0
=C2=A0
Thanks,
=C2=A0
AB

--20cf30050b2263160604fc1a138e-- From nobody Wed Jun 18 04:27:19 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3448A1A01B0 for ; Wed, 18 Jun 2014 04:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Pxelj7nwLDL for ; Wed, 18 Jun 2014 04:27:16 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9CA1A0171 for ; Wed, 18 Jun 2014 04:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=442; q=dns/txt; s=iport; t=1403090836; x=1404300436; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=n7Jb6mQKrT8j4i8/Po/U5GxPJp+/AeFBe9qY7Nz0lpk=; b=WWsgdNeVEAxVAKu1O+C/JcIMg4Fg+ZcY50CRWHc78AMoJcgEkqk8Ocfp aksAuaujmabJM3kX+ozNe6tWmd7b1fSD674QMR9Dj4F21q1f9ijT7mMl7 QGATpQH6sLkjSrTR75/GCwpeMFF+mE4tUIGTMjO4M194hDkvf62LojvrZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0GAJl2oVOtJssW/2dsb2JhbABark0BAQEBAQEFAZYUgxQBgSN1hAMBAQEEOEABEAsOCgkWDwkDAgECAUUGAQwBBwEBiD60AJgRF4ViiRMHhEMBA5pDk1iDQw X-IronPort-AV: E=Sophos;i="5.01,499,1400025600"; d="scan'208";a="90243955" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 18 Jun 2014 11:27:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5IBREDv023199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jun 2014 11:27:14 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s5IBRDZF014232; Wed, 18 Jun 2014 12:27:14 +0100 (BST) Message-ID: <53A17793.3050708@cisco.com> Date: Wed, 18 Jun 2014 12:27:15 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Lou Berger , Alia Atlas Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> <539C3F4E.8050302@labn.net> In-Reply-To: <539C3F4E.8050302@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/qazapMfCUn2m9gu0yuCkZOMsmmQ Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 11:27:18 -0000 On 14/06/2014 13:25, Lou Berger wrote: > > Are you trying to address the tourism effect? (Which by the way is one > of my pet peeves, but I've given up on getting our "leadership" to not > choose meeting destinations based on the number of IETF tourists that > will show.) > That is orthogonal to the problem that I think is being addressed. However I agree with your concern. Minneapolis would work for me every time. Stewart From nobody Wed Jun 18 05:08:58 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B0B1A01D1 for ; Wed, 18 Jun 2014 05:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCHPm0pljd-n for ; Wed, 18 Jun 2014 05:08:49 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182141A01C9 for ; Wed, 18 Jun 2014 05:08:48 -0700 (PDT) Received: from [195.245.231.67:24265] by server-10.bemta-5.messagelabs.com id AF/19-01434-F4181A35; Wed, 18 Jun 2014 12:08:47 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-3.tower-82.messagelabs.com!1403093326!34662521!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20971 invoked from network); 18 Jun 2014 12:08:46 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-3.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 18 Jun 2014 12:08:46 -0000 Received: from EXHY021V.surrey.ac.uk (131.227.200.104) by exht011p.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 18 Jun 2014 13:08:46 +0100 Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.200.4) by email365.surrey.ac.uk (131.227.200.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 18 Jun 2014 13:08:45 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) with Microsoft SMTP Server (TLS) id 15.0.959.24; Wed, 18 Jun 2014 12:08:44 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0959.000; Wed, 18 Jun 2014 12:08:44 +0000 From: To: , Subject: RE: Improving and Restructuring the Routing Area Thread-Topic: Improving and Restructuring the Routing Area Thread-Index: AQHPhOZQ/8yljSQLnkuLJOAhBb2sM5t2vWGAgAAUIms= Date: Wed, 18 Jun 2014 12:08:44 +0000 Message-ID: <1403093323676.55245@surrey.ac.uk> References: , In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.149.114.231] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02462830BE x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(24454002)(164054003)(199002)(189002)(31014004)(377454003)(53234004)(83322001)(19580395003)(19580405001)(74662001)(15975445006)(31966008)(15198665003)(16236675004)(74482001)(74502001)(86362001)(64706001)(20776003)(36756003)(66066001)(83072002)(80022001)(85852003)(4396001)(99396002)(79102001)(50986999)(87936001)(54356999)(77982001)(2656002)(76176999)(46102001)(15202345003)(81342001)(81542001)(76482001)(92566001)(85306003)(101416001)(95666004)(15395725005)(21056001)(92726001)(105586002)(19607625011); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB439; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: surrey.ac.uk does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_140309332367655245surreyacuk_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB439.eurprd06.prod.outlook.com X-OriginatorOrg: surrey.ac.uk X-CrossPremisesHeadersPromoted: EXHY021v.surrey.ac.uk X-CrossPremisesHeadersFiltered: EXHY021v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Hh_uS82_Tk8NW_e1v9cl6679n38 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 12:08:55 -0000 --_000_140309332367655245surreyacuk_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "I suggest to add Participation and Management Quality Assurance, the probl= em is not the draft but is who are working in the WG with Chair with AD. If= we get reasonable participation and more volunteering and more acknowledge= mnts, then we will get better drafts." I suggest reading Robert M. Pirsig's "Zen and the Art of Motorcycle Mainten= ance." It's about what happens to a PhD student who is obsessed with quality. Lloyd Wood http://about.me/lloydwood ________________________________ From: routing-discussion on behalf of= Abdussalam Baryun Sent: Wednesday, 18 June 2014 8:53 PM To: Alia Atlas Cc: routing-discussion@ietf.org Subject: Re: Improving and Restructuring the Routing Area Thanks Alia and Adrian, Dear All, I agree that the area should restructure and follow more clear IETF-managem= ent-objectives for the area. I will try mt best to comment but that does no= t mean my input is best, just writting thoughts which may help. Some sugges= ted before that WGs were not working together, they are separate, and that = it was not the way of progress.Your message did not mention the reasons of = this or did not define the problem. I think the main problem is the manage= ment not the participants or the organising of concensus, if we know the re= asons of our problem it is the best start to avoid it repeat. My comments/discuusion below: I will start with the last paragraph: {For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion.} Two thinking points : a) I see the discussion can be: 1) Area Restructure, 2) WGs Reorganising or= closing, 3) WG's Charters and Functions. Please show us the way for future= discussings. b) IETF Routing Area performance after change. What is the principle reason= s to make us do closing a WG or merging some WGs into one? Please note that= there are possibilities that other organisations may like to close many IE= TF-WGs but is that good for the community? Will we have the same speed afte= r reorganising? more below: On Tue, Jun 10, 2014 at 8:57 PM, Alia Atlas > wrote: To all participants in the Routing Area, Adrian and I are working on improving the quality, speed, and experience of getting work done in the IETF Routing Area. There are three initiatives that we are working: WG Draft QA, Routing Area specific WG chair training, and reorganizing the working groups in the area. Why are they the only priority? I suggest to add Participation and Manageme= nt Quality Assurance, the problem is not the draft but is who are working i= n the WG with Chair with AD. If we get reasonable participation and more vo= lunteering and more acknowledgemnts, then we will get better drafts. First, we intend to use our Routing Directorate more proactively by introducing a Working Group Draft Quality Assurance (WG Draft QA) process where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call. The process will be documented on the Routing Area wiki (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow directorate reviews to report technical issues that can actually get fixed early in the process (equivalent of bug reports) as opposed to just noting the concerns in the drafts (equivalent of release notes). Second, as was discussed during the recent IESG retreat, in addition to the IETF-wide WG chair training, we intend to have a series of training sessions for WG Chairs in the Routing Area addressing topics such as judging consensus, project management, motivating volunteers, using the datatracker (via a sandbox version that can be played with safely), and sharing experiences between WG chairs. In my opinion, the WG chairs in this area should communicate more often on = the lists, some WGs do already and they make it work with quality but some = WG have busy Chairs therefore we get low quality in participation and revie= ws. The ADs should force Editors and Chairs to volunteer more. I had a comm= ent to an editor in another area but still got no respond because the chair= /AD accepted that behavior, and I did not. Third, we intend to reorganize the working groups in the Routing area. We feel that it is important to focus on areas where there is active interest in standardization and to be open and able to accept new work into the area. As you know, we have had several new working groups (nvo3, i2rs, sfc, spring) created in the last few years and we need to be open and able to handle more new work as it comes in. We would also like to improve the signal-to-noise ratio experienced by participants in the different working groups and improve the quantity and quality of discussion and reviews. It is likely that not all WGs in the Routing Area will be directly affected. Here is the time-line for reorganizing the WGs. NOW: public discussion on routing-discussion@ietf.org about how to reorganize the working groups to best meet our motivations. Additional focused discussions are expected on the rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. In Toronto: There will be meetings with the WG chairs and the Routing Directorate to get the ideas described and agreed upon. Please report the results and what will be done to this list, because you m= ay meet any time but what is the value/results of the meeting is more impor= tant. At the Routing Area Meeting in Toronto: Discuss the set of reorganized WGs and general charter content in the Routing Area meeting. I suggest, first each WG in the area discuss and deliver a report to the AD= s of their feedback with WG consensus. September 2014: Based upon the feedback, suggestions, and discussion, Adrian and I finalize the reorganized WG charters. We start the internal IESG discussion and public reviews. I suggest that ADs receive from individuals feedback and also from WG feedb= acks (including its recharter ideas), so each WG have discussed on its list= and gave it WG report to ADs and then here in this list each individual ca= n put their individual opinion. October 2014: Formal rechartering process completes. Recharter is not enough, to solve the current issue you want to solve. In Honolulu: The new set of WGs meet. After Honolulu: Adrian and I deal with any issues and charter updates based upon a few months of experience. Here are the motivations that Adrian and I would like to be considered when coming up with ideas for how the WGs should be reorganized. 1) Move towards organizing working groups on functional responsibilities rather than scoping them to specific protocols. IMO, that is not enough, you need first to make sure that each one WG is or= ganised, then you start moving toward organising WGs. 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. IMHO, that is very wrong decision, please why we separating while we want t= o organise and volunteer together. This 3) Create synergies for scattered functionality (example ideas: OAM, FRR, traffic-engineering) 4) Create a DISPATCH working group for clear new idea discussion; rtgwg serves some of this purpose but doesn't have a clear process and isn't drawing in the new ideas. This preferable to be f2f meeting only WG. 5) Focus Routing Area time on design centers rather than on far corner cases. 6) Each working group should have clear, well defined, and achievable go= als. This should be in the charter and ADs should follow up with the goals and m= ilestones. Noting that the Routing Area has inherited some of its WG structure from the sub-IP area, it is not a goal to force IP routing and MPLS routing to remain separated. The goal of this reorganization is not closing working groups. Adrian and Alia are perfectly capable of closing working groups without going through restructuring. IMO, usually restructure is more about managment (ADs, Chairs, and departme= nts) than about participants work. Reorganising and closing WG is necessary= at any time if there is a need which does not affect each work/draft/parti= cipant. For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion. Thanks, Alia and Adrian Thanks, AB --_000_140309332367655245surreyacuk_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

"I suggest to add Participation and Management Quality Assurance, t= he problem is not the draft but is who are working in the WG with Chair wit= h AD. If we get reasonable participation and more volunteering and mor= e acknowledgemnts, then we will get better drafts."


I suggest reading Robert M. Pirsig's "Zen and the Art of Motorcycle= Maintenance."


It's about what happens to a PhD student who is obsessed with quality.


Lloyd Wood
http://about.me/lloydwood
From: routing-discussion &= lt;routing-discussion-bounces@ietf.org> on behalf of Abdussalam Baryun &= lt;abdussalambaryun@gmail.com>
Sent: Wednesday, 18 June 2014 8:53 PM
To: Alia Atlas
Cc: routing-discussion@ietf.org
Subject: Re: Improving and Restructuring the Routing Area
 
Thanks Alia and Adrian,
 
Dear All,
 
I agree that the area should restructure and follow more clear IETF-ma= nagement-objectives for the area. I will try mt best to comment but th= at does not mean my input is best, just writting thoughts which may help. S= ome suggested before that WGs were not working together, they are separate, and that it was not the way of p= rogress.Your message did not mention the reasons of this or did not de= fine the problem.  I think the main problem is the management not the = participants or the organising of concensus, if we know the reasons of our problem it is the best start to avoid it repeat= .
 
My comments/discuusion below:
 
I will start with the last paragraph:
 
{For those of you that have read this far, thank you.  Getting th= is 80%
right is going to take some serious discussion and thought.  We a= ll
work in the Routing Area together with different perspectives.  P= lease
think carefully and help us have a highly focused discussion.}
 
Two thinking points :
 
a) I see the discussion can be: 1) Area Restructure, 2) WGs Reorganisi= ng or closing, 3) WG's Charters and Functions. Please show us the way = for future discussings.
 
b) IETF Routing Area performance after change. What is the princi= ple reasons to make us do closing a WG or merging some WGs i= nto one? Please note that there are possibilities that other organisations = may like to close many IETF-WGs but is that good for the community? Will we have the same speed after reorganising?
 
more below:

On Tue, Jun 10, 2014 at 8:57 PM, Alia Atlas <akatlas@gmail.co= m> wrote:
To all participants in the Routing Area,

Adrian and I are working on improving the quality, speed, and
experience of getting work done in the IETF Routing Area.  There = are
three initiatives that we are working: WG Draft QA, Routing Area
specific WG chair training, and reorganizing the working groups in the=
area.
 
Why are they the only priority? I suggest to add Participation and Man= agement Quality Assurance, the problem is not the draft but is who are work= ing in the WG with Chair with AD. If we get reasonable participation a= nd more volunteering and more acknowledgemnts, then we will get better drafts.
 

First, we intend to use our Routing Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft QA)
process where the same selected routing directorate member will review=
a draft during WG draft adoption and during WG last call.  The pr= ocess
will be documented on the Routing Area wiki
directorate reviews to report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release notes).<= /div>

Second, as was discussed during the recent IESG retreat, in addition
to the IETF-wide WG chair training, we intend to have a series of
training sessions for WG Chairs in the Routing Area addressing topics<= /div>
such as judging consensus, project management, motivating volunteers,<= /div>
using the datatracker (via a sandbox version that can be played
with safely), and sharing experiences between WG chairs.
 
In my opinion, the WG chairs in this area should communicate more ofte= n on the lists, some WGs do already and they make it work with quality but = some WG have busy Chairs therefore we get low quality in participation and = reviews. The ADs should force Editors and Chairs to volunteer more. I had a comment to an editor in another area= but still got no respond because the chair/AD accepted that behavior, and = I did not.
 

Third, we intend to reorganize the working groups in the Routing area.=
We feel that it is important to focus on areas where there is active
interest in standardization and to be open and able to accept new work=
into the area.  As you know, we have had several new working grou= ps
(nvo3, i2rs, sfc, spring) created in the last few years and we need to=
be open and able to handle more new work as it comes in.  We woul= d
also like to improve the signal-to-noise ratio experienced by
participants in the different working groups and improve the quantity<= /div>
and quality of discussion and reviews.  It is likely that not all= WGs
in the Routing Area will be directly affected.

Here is the time-line for reorganizing the WGs.

   NOW: public discussion on routing-discussion@ietf.org about how to
   reorganize the working groups to best meet our motivation= s.
   Additional focused discussions are expected on the
   = rtg-chairs@ietf.org and rtg-dir@ietf.org = mailing lists.

   In Toronto: There will be meetings with the WG chairs and= the
   Routing Directorate to get the ideas described and agreed= upon.
 
Please report the results and what will be done to this list, because = you may meet any time but what is the value/results of the meeting is more = important.
 

   At the Routing Area Meeting in Toronto: Discuss the set o= f
   reorganized WGs and general charter content in the Routin= g Area
   meeting.
 
I suggest, first each WG in the area discuss and deliver a report to t= he ADs of their feedback with WG consensus.
 

   September 2014: Based upon the feedback, suggestions, and=
   discussion, Adrian and I finalize the reorganized WG char= ters.  We
   start the internal IESG discussion and public reviews.
 
I suggest that ADs receive from individuals feedback and also from WG = feedbacks (including its recharter ideas), so each WG have discussed on its= list and gave it WG report to ADs and then here in this list eac= h individual can put their individual opinion.
 

   October 2014: Formal rechartering process completes.
 
Recharter is not enough, to solve the current issue you want to solve.=
 

   In Honolulu: The new set of WGs meet.

   After Honolulu: Adrian and I deal with any issues and cha= rter
   updates based upon a few months of experience.

Here are the motivations that Adrian and I would like to be considered=
when coming up with ideas for how the WGs should be reorganized.

   1) Move towards organizing working groups on functional
   responsibilities rather than scoping them to specific pro= tocols.
 
IMO, that is not enough, you need first to make sure that each on= e WG is organised, then you start moving toward organising WGs.
 

   2) Split giant working groups so relevant work is done in= one place
   and there is an improved signal-to-noise ratio for partic= ipants who
   are only interested in a slice of the current working gro= up's work.
 
IMHO, that is very wrong decision, please why we separating while we w= ant to organise and volunteer together. This

   3) Create synergies for scattered functionality (example = ideas:
   OAM, FRR, traffic-engineering)

   4) Create a DISPATCH working group for clear new idea dis= cussion;
   rtgwg serves some of this purpose but doesn't have a clea= r process
   and isn't drawing in the new ideas.
 
This preferable to be f2f meeting only WG.
 

   5) Focus Routing Area time on design centers rather than = on far
   corner cases.

   6) Each working group should have clear, well defined, an= d achievable goals.
 
This should be in the charter and ADs should follow up with the goals = and milestones.
 

Noting that the Routing Area has inherited some of its WG structure
from the sub-IP area, it is not a goal to force IP routing and MPLS
routing to remain separated.

The goal of this reorganization is not closing working groups.  A= drian
and Alia are perfectly capable of closing working groups without going=
through restructuring.
 
IMO, usually restructure is more about managment (ADs, Chairs, and dep= artments) than about participants work. Reorganising and closing WG is= necessary at any time if there is a need which does not affect each work/d= raft/participant.
 

For those of you that have read this far, thank you.  Getting thi= s 80%
right is going to take some serious discussion and thought.  We a= ll
work in the Routing Area together with different perspectives.  P= lease
think carefully and help us have a highly focused discussion.

Thanks,
Alia and Adrian
 
 
Thanks,
 
AB

--_000_140309332367655245surreyacuk_-- From nobody Wed Jun 18 08:12:14 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DB01A028B for ; Wed, 18 Jun 2014 08:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbB2H67ruif3 for ; Wed, 18 Jun 2014 08:12:08 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id B0AB21A0295 for ; Wed, 18 Jun 2014 08:11:58 -0700 (PDT) Received: (qmail 12725 invoked by uid 0); 18 Jun 2014 15:11:57 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 18 Jun 2014 15:11:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id FrBs1o00X2SSUrH01rBvDB; Wed, 18 Jun 2014 09:11:56 -0600 X-Authority-Analysis: v=2.1 cv=EJKVjTpC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=PK2Gh033CTMA:10 a=C8UVKu96udcA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=XaRE7RIwhVlYScbS4zYA:9 a=cOeCr6LdqmDWPc_I:21 a=aYqq3XVqQ6NN2-BJ:21 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BfgByWwpWDSk91uLoIMcLpLmpp0thlHdPgtjPnTiI4g=; b=d+k4Dsl5Dwy8zw5NuFW/PqDjibFLM6h52I5yoLYvh4v6hQ9JhRW7ClH+mnR64gbf2MEhuj4ORT70dIgzGkXhiQ+GCOOXjnyOxdSTPTq4J2NZvTRw/WHY0rL8ZgvxI99b; Received: from box313.bluehost.com ([69.89.31.113]:32885 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1WxHWj-0005Qy-8i; Wed, 18 Jun 2014 09:11:53 -0600 Message-ID: <53A1AC36.3000206@labn.net> Date: Wed, 18 Jun 2014 11:11:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: stbryant@cisco.com Subject: Re: big equal to inefficient ?? References: <53993792.3050902@pi.nu> <5399E05D.20506@cisco.com> <5399E18C.4090306@pi.nu> <6BD3A616-1EB7-4445-9D9E-4246B767F78A@layerfree.net> <7347100B5761DC41A166AC17F22DF1121B7CD9A6@eusaamb103.ericsson.se> <95AFF36B-AE2D-4A1E-BBE2-768EE6615B19@layerfree.net> <539A8088.1090302@pi.nu> <539A83A8.2060402@pi.nu> <539C3F4E.8050302@labn.net> <53A17793.3050708@cisco.com> In-Reply-To: <53A17793.3050708@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/8IfkXxF2LHX8hiWM-japyGHqSQE Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 15:12:12 -0000 Stewart, On 06/18/2014 07:27 AM, Stewart Bryant wrote: > On 14/06/2014 13:25, Lou Berger wrote: >> >> Are you trying to address the tourism effect? (Which by the way is one >> of my pet peeves, but I've given up on getting our "leadership" to not >> choose meeting destinations based on the number of IETF tourists that >> will show.) >> > That is orthogonal to the problem that I think is being addressed. This is what I expected, that is, until Alia raised it... > > However I agree with your concern. Minneapolis would work for > me every time. WFM... Lou > > Stewart > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Thu Jun 19 03:31:14 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8A31A00F0 for ; Thu, 19 Jun 2014 02:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyCDrf31_-T3 for ; Thu, 19 Jun 2014 02:48:12 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FE91A00EC for ; Thu, 19 Jun 2014 02:48:11 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j107so1887977qga.3 for ; Thu, 19 Jun 2014 02:48:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=lHGVYYVskSuloajf5LnsHb+YhcXRqxCg3ZoOVFg+59o=; b=lsQR5EbcpSPZd0IWv1+hg2d4DkxaxfEln1f6WOvja4DVJxEd3Uwav/mw3GDsIsZWP2 f2GAiFr051ZAdQxkcYhTHeeUzAUKfjMAG0flKv07WO0OgRLk2CrfLSbvDK2wHeJegpoL 4O6BeLpG39Xo4yOJA4NrZKlUKJyIZADCXflBER0tgvbbGinDLCTw6fV6Ltb8h6r08a3A tpSfhzD25vQUJBlUJycTm8Q4tzScdWi9xC/ASjGRfLADYH8AuQU+WwV9IW350tOL5rU+ 2V+4/NeFoRuXOBQoVdgqkeWHvfl7xennv/fUFs0Ns99ROMuDiK60RqT50nb2SBc9x2UG 7VXA== X-Gm-Message-State: ALoCoQkphzmJsMSiPrSYEDzdxS8kImsZr81pes/3lGTgLHkNV7r5v1NY/fqhOJinVExwkN/CGjnv X-Received: by 10.224.136.129 with SMTP id r1mr5182397qat.60.1403171290944; Thu, 19 Jun 2014 02:48:10 -0700 (PDT) Received: from wonder.chopps.org (c-71-227-97-41.hsd1.mi.comcast.net. [71.227.97.41]) by mx.google.com with ESMTPSA id m13sm7742260qab.19.2014.06.19.02.48.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 02:48:10 -0700 (PDT) Subject: Re: Improving and Restructuring the Routing Area Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_42A0F990-4091-4ADF-B35A-D55F17A6CA23" From: Christian Hopps In-Reply-To: Date: Thu, 19 Jun 2014 05:47:08 -0400 Message-Id: References: To: "isis-wg@ietf.org list" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/7bzBrB_in9ttocQAN4kQQ8IAz58 X-Mailman-Approved-At: Thu, 19 Jun 2014 03:31:13 -0700 Cc: Hannes Gredler , Christian Hopps X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 09:48:14 -0000 --Apple-Mail=_42A0F990-4091-4ADF-B35A-D55F17A6CA23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi isis-wg, Please be aware of the ongoing discussion related to improving the = Routing Area. The discussion is taking place on = routing-discussion@ietf.org, so please subscribe and join in if = interested. Thanks, Chris. On Jun 10, 2014, at 3:57 PM, Alia Atlas wrote: > To all participants in the Routing Area, >=20 > Adrian and I are working on improving the quality, speed, and > experience of getting work done in the IETF Routing Area. There are > three initiatives that we are working: WG Draft QA, Routing Area > specific WG chair training, and reorganizing the working groups in the > area. >=20 > First, we intend to use our Routing Directorate more proactively by > introducing a Working Group Draft Quality Assurance (WG Draft QA) > process where the same selected routing directorate member will review > a draft during WG draft adoption and during WG last call. The process > will be documented on the Routing Area wiki > (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow > directorate reviews to report technical issues that can actually get > fixed early in the process (equivalent of bug reports) as opposed to > just noting the concerns in the drafts (equivalent of release notes). >=20 > Second, as was discussed during the recent IESG retreat, in addition > to the IETF-wide WG chair training, we intend to have a series of > training sessions for WG Chairs in the Routing Area addressing topics > such as judging consensus, project management, motivating volunteers, > using the datatracker (via a sandbox version that can be played > with safely), and sharing experiences between WG chairs. >=20 > Third, we intend to reorganize the working groups in the Routing area. > We feel that it is important to focus on areas where there is active > interest in standardization and to be open and able to accept new work > into the area. As you know, we have had several new working groups > (nvo3, i2rs, sfc, spring) created in the last few years and we need to > be open and able to handle more new work as it comes in. We would > also like to improve the signal-to-noise ratio experienced by > participants in the different working groups and improve the quantity > and quality of discussion and reviews. It is likely that not all WGs > in the Routing Area will be directly affected. >=20 > Here is the time-line for reorganizing the WGs. >=20 > NOW: public discussion on routing-discussion@ietf.org about how to > reorganize the working groups to best meet our motivations. > Additional focused discussions are expected on the > rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. >=20 > In Toronto: There will be meetings with the WG chairs and the > Routing Directorate to get the ideas described and agreed upon. >=20 > At the Routing Area Meeting in Toronto: Discuss the set of > reorganized WGs and general charter content in the Routing Area > meeting. >=20 > September 2014: Based upon the feedback, suggestions, and > discussion, Adrian and I finalize the reorganized WG charters. We > start the internal IESG discussion and public reviews. >=20 > October 2014: Formal rechartering process completes. >=20 > In Honolulu: The new set of WGs meet. >=20 > After Honolulu: Adrian and I deal with any issues and charter > updates based upon a few months of experience. >=20 > Here are the motivations that Adrian and I would like to be considered > when coming up with ideas for how the WGs should be reorganized. >=20 > 1) Move towards organizing working groups on functional > responsibilities rather than scoping them to specific protocols. >=20 > 2) Split giant working groups so relevant work is done in one place > and there is an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. >=20 > 3) Create synergies for scattered functionality (example ideas: > OAM, FRR, traffic-engineering) >=20 > 4) Create a DISPATCH working group for clear new idea discussion; > rtgwg serves some of this purpose but doesn't have a clear process > and isn't drawing in the new ideas. >=20 > 5) Focus Routing Area time on design centers rather than on far > corner cases. >=20 > 6) Each working group should have clear, well defined, and = achievable goals. >=20 > Noting that the Routing Area has inherited some of its WG structure > from the sub-IP area, it is not a goal to force IP routing and MPLS > routing to remain separated. >=20 > The goal of this reorganization is not closing working groups. Adrian > and Alia are perfectly capable of closing working groups without going > through restructuring. >=20 > For those of you that have read this far, thank you. Getting this 80% > right is going to take some serious discussion and thought. We all > work in the Routing Area together with different perspectives. Please > think carefully and help us have a highly focused discussion. >=20 > Thanks, > Alia and Adrian >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion --Apple-Mail=_42A0F990-4091-4ADF-B35A-D55F17A6CA23 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi isis-wg,

Please be aware of the ongoing discussion related to improving the Routing Area. The discussion is taking place on  routing-discussion@ietf.org, so please subscribe and join in if interested.

Thanks,
Chris.

On Jun 10, 2014, at 3:57 PM, Alia Atlas <akatlas@gmail.com> wrote:

To all participants in the Routing Area,

Adrian and I are working on improving the quality, speed, and
experience of getting work done in the IETF Routing Area.  There are
three initiatives that we are working: WG Draft QA, Routing Area
specific WG chair training, and reorganizing the working groups in the
area.

First, we intend to use our Routing Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft QA)
process where the same selected routing directorate member will review
a draft during WG draft adoption and during WG last call.  The process
will be documented on the Routing Area wiki
directorate reviews to report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release notes).

Second, as was discussed during the recent IESG retreat, in addition
to the IETF-wide WG chair training, we intend to have a series of
training sessions for WG Chairs in the Routing Area addressing topics
such as judging consensus, project management, motivating volunteers,
using the datatracker (via a sandbox version that can be played
with safely), and sharing experiences between WG chairs.

Third, we intend to reorganize the working groups in the Routing area.
We feel that it is important to focus on areas where there is active
interest in standardization and to be open and able to accept new work
into the area.  As you know, we have had several new working groups
(nvo3, i2rs, sfc, spring) created in the last few years and we need to
be open and able to handle more new work as it comes in.  We would
also like to improve the signal-to-noise ratio experienced by
participants in the different working groups and improve the quantity
and quality of discussion and reviews.  It is likely that not all WGs
in the Routing Area will be directly affected.

Here is the time-line for reorganizing the WGs.

   NOW: public discussion on routing-discussion@ietf.org about how to
   reorganize the working groups to best meet our motivations.
   Additional focused discussions are expected on the
   rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists.

   In Toronto: There will be meetings with the WG chairs and the
   Routing Directorate to get the ideas described and agreed upon.

   At the Routing Area Meeting in Toronto: Discuss the set of
   reorganized WGs and general charter content in the Routing Area
   meeting.

   September 2014: Based upon the feedback, suggestions, and
   discussion, Adrian and I finalize the reorganized WG charters.  We
   start the internal IESG discussion and public reviews.

   October 2014: Formal rechartering process completes.

   In Honolulu: The new set of WGs meet.

   After Honolulu: Adrian and I deal with any issues and charter
   updates based upon a few months of experience.

Here are the motivations that Adrian and I would like to be considered
when coming up with ideas for how the WGs should be reorganized.

   1) Move towards organizing working groups on functional
   responsibilities rather than scoping them to specific protocols.

   2) Split giant working groups so relevant work is done in one place
   and there is an improved signal-to-noise ratio for participants who
   are only interested in a slice of the current working group's work.

   3) Create synergies for scattered functionality (example ideas:
   OAM, FRR, traffic-engineering)

   4) Create a DISPATCH working group for clear new idea discussion;
   rtgwg serves some of this purpose but doesn't have a clear process
   and isn't drawing in the new ideas.

   5) Focus Routing Area time on design centers rather than on far
   corner cases.

   6) Each working group should have clear, well defined, and achievable goals.

Noting that the Routing Area has inherited some of its WG structure
from the sub-IP area, it is not a goal to force IP routing and MPLS
routing to remain separated.

The goal of this reorganization is not closing working groups.  Adrian
and Alia are perfectly capable of closing working groups without going
through restructuring.

For those of you that have read this far, thank you.  Getting this 80%
right is going to take some serious discussion and thought.  We all
work in the Routing Area together with different perspectives.  Please
think carefully and help us have a highly focused discussion.

Thanks,
Alia and Adrian

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion

--Apple-Mail=_42A0F990-4091-4ADF-B35A-D55F17A6CA23-- From nobody Thu Jun 19 14:06:37 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7EF1A041F for ; Thu, 19 Jun 2014 14:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8JuZDMEvtfk for ; Thu, 19 Jun 2014 14:06:33 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE171A040E for ; Thu, 19 Jun 2014 14:06:33 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so2172647yha.31 for ; Thu, 19 Jun 2014 14:06:32 -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=Cc8dnEur5wBRmbXUkwSPALlFIsxJRtLwXvrupm2jTgc=; b=yXohY202GxvdBeQdHuQoCCDRtf8X1S6i4vVtcfJz9/QHLwTvDirpJIq+WlE3/iRR80 CYKl9yabmlaEsRw5S65MN0NuIcmAiUGOEnzvtZsyE4BqnM5cz0baNvw5MgF+CzAiYjto sTgK/rih7lMolCT34wO1WXl0f+ZU2IA+V+JRELzrnbYOFvWhSh+7LMZzrEIa6+qkeX7r tfqo+EWBKqMGicZ4YIuljDFG7a19pGEI54SjXyvGuPEva+U84UgYb3hTZDEW8HFRUoGI HSEWSjgH5du+stGgtPrqxUjGX6bh2vkMAObOZ05U4/nBhcjzeak3vWbjoyfjZUaCmzzW By4w== MIME-Version: 1.0 X-Received: by 10.236.135.228 with SMTP id u64mr11737335yhi.18.1403211992488; Thu, 19 Jun 2014 14:06:32 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Thu, 19 Jun 2014 14:06:32 -0700 (PDT) In-Reply-To: <027a8e31cf2e47e0bbfabc23a7507e16@CO2PR05MB636.namprd05.prod.outlook.com> References: <027a8e31cf2e47e0bbfabc23a7507e16@CO2PR05MB636.namprd05.prod.outlook.com> Date: Thu, 19 Jun 2014 22:06:32 +0100 Message-ID: Subject: Re: Improving and Restructuring the Routing Area From: Abdussalam Baryun To: Ross Callon Content-Type: multipart/alternative; boundary=20cf301af3f55b625e04fc36c0cc Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/un269oM0O21snBHZ9FVQWHBNhPo Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 21:06:35 -0000 --20cf301af3f55b625e04fc36c0cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ross, Thanks. I want to discuss your point more further, my comments below, On Tuesday, June 10, 2014, Ross Callon wrote: > I think that there is quite a bit of content in this email, and that we > might need to end up with several threads -- such as one for routing > directorate changes, one for WG chair training, and one for WG > reorganization. > > > Yes, I think it will be good to discuss here before the next meetings, because it is a big change for this IETF large area. > > > Speaking for the latter =E2=80=93 WG reorganization, and specifically on = dealing > with very large WGs: I think that there is a tradeoff here. Very large WG= s > can be cumbersome and might not be as =E2=80=9Cfocused=E2=80=9D as smalle= r groups. > > There are old WGs and large WGs (old in participation or large in participation), I think large WGs are difficult to reorganise, because we may reduce interests to participate. The most important issue is not in participation but in team work, if WGs are just groups with no team work then the work or the output is with low quality. On the other hand small WGs may not be focused because the group is not working as a team. > However, it is much easier or more likely for work to diverge when it is > split into multiple groups. > > We may split but still there should be links between the groups, otherwis= e we loose the value of the main routing use cases. The ADs and WGs' chairs should maintain those links. > > > As one example, one obviously large group is MPLS. Looking at the work > going on in MPLS, one possible way to split it up would be to split off t= he > OAM work. However, how to manage a protocol is very much tied into other > aspects of the operation of the protocol. If people working on one aspect > of a protocol are bored listening to OAM discussions, it might nonetheles= s > be a good idea for them to listen to OAM discussions. > > > > Do we want to get into discussing details pertinent to specific WGs? > > Because I don't know why we are changing, I think it is important to start with the principles of reorganising and closing, as what make us select some WGs to reorganise? But if the reason of the ADs to think of reorganising is some specific WGs then we may just start with specifying them. Best, AB > --20cf301af3f55b625e04fc36c0cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ross,

Thanks.=C2=A0I want to discuss your point m= ore further, my comments below,

On Tuesday, June 10, 2014, Ro= ss Callon wrote:

I think that there is qui= te a bit of content in this email, and that we might need to end up with se= veral threads -- such as one for routing directorate changes, one for WG chair training, and one for WG reorganization.


Yes, I think it will be good to discuss here= =C2=A0before the next meetings, because it is a big change for=C2=A0this IE= TF large area.=C2=A0

=C2=A0

Speaking for the latter = =E2=80=93 WG reorganization, and specifically on dealing with very large WG= s: I think that there is a tradeoff here. Very large WGs can be cumbersome and might not be as =E2=80=9Cfocused=E2=80=9D as smaller groups.=C2=A0

<= /div>

There are old WGs and large WGs (old in participation or lar= ge in participation),=C2=A0I think large WGs are difficult to reorganise, b= ecause we may reduce interests to participate.=C2=A0=C2=A0The most importan= t issue=C2=A0is not in participation but in team work, if WGs are just grou= ps with no team work then the work or the output is with low quality. On th= e other hand small WGs may not be focused because the group is not working = as a team.=C2=A0

However, it i= s much easier or more likely for work to diverge when it is split into mult= iple groups.

We may split but still there should be links between the groups, oth= erwise we loose the value of the main routing=C2=A0use cases. The ADs =C2= =A0and WGs'=C2=A0chairs=C2=A0should maintain those links.=C2=A0

=C2=A0

As one example, one obvio= usly large group is MPLS. Looking at the work going on in MPLS, one possibl= e way to split it up would be to split off the OAM work. However, how to manage a protocol is very much tied into other aspects of = the operation of the protocol. If people working on one aspect of a protoco= l are bored listening to OAM discussions, it might nonetheless be a good id= ea for them to listen to OAM discussions.

=C2=A0

Do we want to get into di= scussing details pertinent to specific WGs?


Because I=C2=A0don't know why we are changing,=C2= =A0I think it is important to start with the principles of reorganising and= closing, as what make us select some WGs to reorganise? But if the reason = of the ADs to think of reorganising is some specific WGs then we may just s= tart with specifying them.=C2=A0

Best,
AB=C2=A0

--20cf301af3f55b625e04fc36c0cc-- From nobody Tue Jun 24 06:05:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C0B1B2919 for ; Tue, 24 Jun 2014 06:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYmvYBnnzgY1 for ; Tue, 24 Jun 2014 06:04:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776851B290F for ; Tue, 24 Jun 2014 06:04:55 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OD4rGZ027870 for ; Tue, 24 Jun 2014 14:04:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OD4p2O027834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Jun 2014 14:04:52 +0100 From: "Adrian Farrel" To: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> Subject: FW: Routing Area organization Date: Tue, 24 Jun 2014 14:04:49 +0100 Message-ID: <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0240_01CF8FB5.43ED9550" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSmnyEPMMBa9dnJPneRdJ51F0Ld5x6I+yg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20776.005 X-TM-AS-Result: No--17.114-10.0-31-10 X-imss-scan-details: No--17.114-10.0-31-10 X-TMASE-MatchedRID: mIMb8eDo9tXk6hzGVYJqnJVRzPxemJL0t2i75GXpB0m6pZ/o2Hu2YaB6 3Salz7JwkdkOuSFnF059FoDILZamC8uY+x+wpWIHh2VzUlo4HVM5vvch9MIrZEVj1h+dTv6+Sjq S1/6Q/rWqfOx/zQXipYt6aYxMrDD+BxIED8tgOKFj2Mi9Aq5L09J178I1tpklInzOyTDR1usDjX ubJaKTSwBmK+PFELwkM6R5cB/plEVahpkpltl7cRwUxA/eIq2eUcH09qBGmHSabNoYojBQdl8Ub Sn1RTfDfSB0Q38RMjB+XHMTeEdcYbmcX0hGNwcCBEfU2vugRF1AJ/ashI7fOwFbHA9TqNLQ6Wf6 mBROpcHy3f0hvGuLhKKja1hNbb57VR6p6fJaldaGwT67eecJ8JRy1HDTPOXaLO3j+XDwlkPX6Xz uWIU29x/nudWQRADIABWRP8jbfPKKx7xD7ImGeu9VsdrlGzy3Q6/DFZugyt0wODfUl7mJKf4ZAU sty2ENqv6+7o00zYeLFgnz+hpr+XW0oJLOugKBj1RGQOB2Vvn9GaYSzB/sh6Jd7mc2dRi3oEozr aubH2nx6gF+AN4QjuBe5QRmIfivPwbcb/CNUOlwvDydhBUuyCAXLFyLhL5W5GdZsk1yqBcqoeXF Mnt4lSJunynLhcivKEdCtwyfJsLWV8MKb34RlRZU/yoIC8o9JVsoL7U3JcDimKcLRvsB1UauzWh ZogiAzkH/0tV77RA9ihzfHXEWBFN5kIZnYeEYY4guKfvwCBYzH3zWWApNw/ufvd3T2+v3GRCKVx 5QswnzbeV2VN8Li3ZBE86uj+HtFIXwv4qc0ZOeAiCmPx4NwGmRqNBHmBvelpyqxIUg/ZTJ4y0wP 1A6AMaUO+wtQNbafIoQ5smzFRZk1fRjzF0YcpVtnwROLoeUYqSoGSSpNw8JEfvLUKky5g== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/SH7eKvMDSL_B-Z1Um6oLCD1XxkQ X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:05:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0240_01CF8FB5.43ED9550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Forwarding with Joel's permission. From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: 23 June 2014 17:14 To: Alia Atlas; adrian@olddog.co.uk Subject: Routing Area organization (Feel free to circulate this if you think it is useful. I don't have the right email addresses on this machine to send directly to the relevant parties.) In looking at the discussion of the routing area, it seems to me that the starting premise is very important. I believe we all agree that we want a structure that helps us produce useful RFCs to enable a stronger and more innovative routing system that meets the real needs of the various kinds of operations to deliver Internet services. (I.e the general IETF goals.) The following are my rough thoughts on this topic, as input to the discussion. First, I take it as given that there may well be a better way to structure the work. The structure we have is an outgrowth of years of accumulation. It seems to me distinctly worth looking at whether looking at what changes we can make, what they will accomplish,a nd if any of them are likely to improve our working. Personally, I think this examination is long overdue. Note that even if we decide that we like the current structure, it will still have been worth looking and understanding why we are working the way we are. One of the biggest problems I see is the number of times when work has to be presented in multiple working groups, and the drafts revised to address related but disconnected concerns. This waste author energy and working group time. This is a consequence of our feeling a need to control how protocols evolve. And such control is necessary. But needs to be balanced with other needs. Also we all become tourists very often even in working groups we are interested in. Any arrangement of work other than treating the world as one working group (which I hope we all agree would be a very bad idea) will need some cross-communciation between groups. But some arrangements produce better commonality. Similarly, any arrangement will produce working groups where some of the work is of less interest to some of the participants. But maybe we can get better alignment? A couple of obvious examples. Anything that needs to be done in an IGP needs to be done twice (fortunately, we no longer care about RIP.) Different working groups all need to develop operations, adminsitration, and maintenance mechanisms. But that means they need to redevelop the common understanding of what the needs, known techniques, and hard questions are. So I think we would benefit from rearranging the deck chairs. I would try to make the groups focus on external needs rather than on mechanism. I would start by merging the OSPF and ISIS working groups. I would also pull the OAM functions out of the various groups (BFD, MPLS, CCAMP, .) and create one place that can deal with OAM issues. I would probably then merge SPRING with core MPLS functioning. We have just closed KARP, and I would (unhappily, but I think necessarily) close ForCES. I would either close ROLLand move the work into a common low power group in another area, or make ti the common low power working group. I would merge IDR and SIDR. With the current SIDR work program, it no longer makes sense to me to treat them as separate. I would look at merging L2vpn and l3vpn back together. And combining them with NVO3. Probably also include PWE3 in that set, although that is a harder call and may be too different. I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would fit well with other groups. Yours, Joel ------=_NextPart_000_0240_01CF8FB5.43ED9550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forwarding with Joel's = permission.

 

From: Joel Halpern = [mailto:joel.halpern@ericsson.com]
Sent: 23 June 2014 = 17:14
To: Alia Atlas; adrian@olddog.co.uk
Subject: = Routing Area organization

 

(Feel free to circulate this if you think = it is useful.  I don't have the right email addresses on this = machine to send directly to the relevant = parties.)

 

In looking at the discussion of the routing = area, it seems to me that the starting premise is very important.  = I believe we all agree that we want a structure that helps us produce = useful RFCs to enable a stronger and more innovative routing system that = meets the real needs of the various kinds of operations to deliver = Internet services.  (I.e the general IETF = goals.)

The following are my rough thoughts on this = topic, as input to the discussion.

 

First, I take it as given that there may = well be a better way to structure the work.  The structure we have = is an outgrowth of years of accumulation.  It seems to me = distinctly worth looking at whether looking at what changes we can make, = what they will accomplish,a nd if any of them are likely to improve our = working.  Personally, I think this examination is long = overdue.  Note that even if we decide that we like the current = structure, it will still have been worth looking and understanding why = we are working the way we are.

 

One of the biggest problems I see is the = number of times when work has to be presented in multiple working = groups, and the drafts revised to address related but disconnected = concerns.  This waste author energy and working group time.  = This is a consequence of our feeling a need to control how protocols = evolve.  And such control is necessary.  But needs to be = balanced with other needs.   Also we all become tourists very = often even in working groups we are interested = in.

 

Any arrangement of work other than treating = the world as one working group (which I hope we all agree would be a = very bad idea) will need some cross-communciation between groups.  = But some arrangements produce better commonality.  Similarly, any = arrangement will produce working groups where some of the work is of = less interest to some of the participants.  But maybe we can get = better alignment?

 

A couple of obvious examples.  = Anything that needs to be done in an IGP needs to be done twice = (fortunately, we no longer care about RIP.)  Different working = groups all need to develop operations, adminsitration, and maintenance = mechanisms.  But that means they need to redevelop the common = understanding of what the needs, known techniques, and hard questions = are.

 

So I think we would benefit from = rearranging the deck chairs.  I would try to make the groups focus = on external needs rather than on = mechanism.

 

I would start by merging the OSPF and ISIS = working groups. 

I would also pull the OAM functions out of = the various groups (BFD, MPLS, CCAMP, …) and create one place that = can deal with OAM issues.

I would probably then merge SPRING with = core MPLS functioning.

We have just closed KARP, and I would = (unhappily, but I think necessarily) close = ForCES.

I would either close ROLLand move the work = into a common low power group in another area, or make ti the common low = power working group.

I would merge IDR and SIDR.  With the = current SIDR work program, it no longer makes sense to me to treat them = as separate.

I would look at merging L2vpn and l3vpn = back together.  And combining them with NVO3.  Probably also = include PWE3 in that set, although that is a harder call and may be too = different.

 

I would leave CCCAMP, PCE, and PIM alone, = as I am not seeing how they would fit well with other = groups.

 

Yours,

Joel

 

 

 

 

 

------=_NextPart_000_0240_01CF8FB5.43ED9550-- From nobody Tue Jun 24 06:24:16 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2DE1B29CF for ; Tue, 24 Jun 2014 06:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.95 X-Spam-Level: X-Spam-Status: No, score=-6.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQDXFtf65Zhr for ; Tue, 24 Jun 2014 06:24:10 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFD91B294D for ; Tue, 24 Jun 2014 06:24:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,538,1400022000"; d="scan'208,217";a="451618845" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 24 Jun 2014 14:24:07 +0100 X-IronPort-AV: E=Sophos; i="5.01,538,1400022000"; d="scan'208,217"; a="55602122" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 24 Jun 2014 14:24:07 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.60]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 14:24:07 +0100 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" Subject: RE: Routing Area organization Thread-Topic: Routing Area organization Thread-Index: AQFSmnyEPMMBa9dnJPneRdJ51F0Ld5x6I+yggAAFvlA= Date: Tue, 24 Jun 2014 13:24:06 +0000 Message-ID: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> In-Reply-To: <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D402F6541GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/3VdU-AWA9vxFyL1A73-mZtA_ye4 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:24:15 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D402F6541GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable No mention of MANET in Joel's analysis. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Adrian Farrel Sent: 24 June 2014 14:05 To: routing-discussion@ietf.org Subject: FW: Routing Area organization *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Forwarding with Joel's permission. From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: 23 June 2014 17:14 To: Alia Atlas; adrian@olddog.co.uk Subject: Routing Area organization (Feel free to circulate this if you think it is useful. I don't have the r= ight email addresses on this machine to send directly to the relevant parti= es.) In looking at the discussion of the routing area, it seems to me that the s= tarting premise is very important. I believe we all agree that we want a s= tructure that helps us produce useful RFCs to enable a stronger and more in= novative routing system that meets the real needs of the various kinds of o= perations to deliver Internet services. (I.e the general IETF goals.) The following are my rough thoughts on this topic, as input to the discussi= on. First, I take it as given that there may well be a better way to structure = the work. The structure we have is an outgrowth of years of accumulation. = It seems to me distinctly worth looking at whether looking at what changes= we can make, what they will accomplish,a nd if any of them are likely to i= mprove our working. Personally, I think this examination is long overdue. = Note that even if we decide that we like the current structure, it will st= ill have been worth looking and understanding why we are working the way we= are. One of the biggest problems I see is the number of times when work has to b= e presented in multiple working groups, and the drafts revised to address r= elated but disconnected concerns. This waste author energy and working gro= up time. This is a consequence of our feeling a need to control how protoc= ols evolve. And such control is necessary. But needs to be balanced with = other needs. Also we all become tourists very often even in working group= s we are interested in. Any arrangement of work other than treating the world as one working group = (which I hope we all agree would be a very bad idea) will need some cross-c= ommunciation between groups. But some arrangements produce better commonal= ity. Similarly, any arrangement will produce working groups where some of = the work is of less interest to some of the participants. But maybe we can= get better alignment? A couple of obvious examples. Anything that needs to be done in an IGP nee= ds to be done twice (fortunately, we no longer care about RIP.) Different = working groups all need to develop operations, adminsitration, and maintena= nce mechanisms. But that means they need to redevelop the common understan= ding of what the needs, known techniques, and hard questions are. So I think we would benefit from rearranging the deck chairs. I would try = to make the groups focus on external needs rather than on mechanism. I would start by merging the OSPF and ISIS working groups. I would also pull the OAM functions out of the various groups (BFD, MPLS, C= CAMP, ...) and create one place that can deal with OAM issues. I would probably then merge SPRING with core MPLS functioning. We have just closed KARP, and I would (unhappily, but I think necessarily) = close ForCES. I would either close ROLLand move the work into a common low power group in= another area, or make ti the common low power working group. I would merge IDR and SIDR. With the current SIDR work program, it no long= er makes sense to me to treat them as separate. I would look at merging L2vpn and l3vpn back together. And combining them = with NVO3. Probably also include PWE3 in that set, although that is a hard= er call and may be too different. I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would= fit well with other groups. Yours, Joel ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D402F6541GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

No mention of MANET in Jo= el’s analysis.

 <= /p>

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (O= perations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 <= /p>

From: routing-discussion [mailto:routing-discussion-bounces= @ietf.org] On Behalf Of Adrian Farrel
Sent: 24 June 2014 14:05
To: routing-discussion@ietf.org
Subject: FW: Routing Area organization

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.

Forwarding with Joel's pe= rmission.

 <= /p>

From: Joel Halpern [mailto:joel.halpern@ericsson.com]
Sent: 23 June 2014 17:14
To: Alia Atlas; adrian@olddog= .co.uk
Subject: Routing Area organization

 

(Feel free to circulate this if you think= it is useful.  I don't have the right email addresses on this machine= to send directly to the relevant parties.)

 

In looking at the discussion of the routi= ng area, it seems to me that the starting premise is very important.  = I believe we all agree that we want a structure that helps us produce useful RFCs to enable a stronger and more innovative routing syste= m that meets the real needs of the various kinds of operations to deliver I= nternet services.  (I.e the general IETF goals.)

The following are my rough thoughts on th= is topic, as input to the discussion.

 

First, I take it as given that there may = well be a better way to structure the work.  The structure we have is = an outgrowth of years of accumulation.  It seems to me distinctly worth looking at whether looking at what changes we can make, what they wi= ll accomplish,a nd if any of them are likely to improve our working.  = Personally, I think this examination is long overdue.  Note that even = if we decide that we like the current structure, it will still have been worth looking and understanding why we are working= the way we are.

 

One of the biggest problems I see is the = number of times when work has to be presented in multiple working groups, a= nd the drafts revised to address related but disconnected concerns.  This waste author energy and working group time.  Thi= s is a consequence of our feeling a need to control how protocols evolve.&n= bsp; And such control is necessary.  But needs to be balanced with oth= er needs.   Also we all become tourists very often even in working groups we are interested in.

 

Any arrangement of work other than treati= ng the world as one working group (which I hope we all agree would be a ver= y bad idea) will need some cross-communciation between groups.  But some arrangements produce better commonality.  Similarly, any arr= angement will produce working groups where some of the work is of less inte= rest to some of the participants.  But maybe we can get better alignme= nt?

 

A couple of obvious examples.  Anyth= ing that needs to be done in an IGP needs to be done twice (fortunately, we= no longer care about RIP.)  Different working groups all need to develop operations, adminsitration, and maintenance mechanisms.  B= ut that means they need to redevelop the common understanding of what the n= eeds, known techniques, and hard questions are.

 

So I think we would benefit from rearrang= ing the deck chairs.  I would try to make the groups focus on external= needs rather than on mechanism.

 

I would start by merging the OSPF and ISI= S working groups. 

I would also pull the OAM functions out o= f the various groups (BFD, MPLS, CCAMP, …) and create one place that = can deal with OAM issues.

I would probably then merge SPRING with c= ore MPLS functioning.

We have just closed KARP, and I would (un= happily, but I think necessarily) close ForCES.

I would either close ROLLand move the wor= k into a common low power group in another area, or make ti the common low = power working group.

I would merge IDR and SIDR.  With th= e current SIDR work program, it no longer makes sense to me to treat them a= s separate.

I would look at merging L2vpn and l3vpn b= ack together.  And combining them with NVO3.  Probably also inclu= de PWE3 in that set, although that is a harder call and may be too different.

 

I would leave CCCAMP, PCE, and PIM alone,= as I am not seeing how they would fit well with other groups.

 

Yours,

Joel

 

 

 

 

 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D402F6541GLKXM0002VGREEN_-- From nobody Tue Jun 24 06:34:32 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C461F1B2A06 for ; Tue, 24 Jun 2014 06:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUpkTm228MkE for ; Tue, 24 Jun 2014 06:34:28 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8184D1B29F3 for ; Tue, 24 Jun 2014 06:34:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 1885B1C90237; Tue, 24 Jun 2014 06:34:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from Joels-MacBook-Pro.local (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id CCDDB1C90236; Tue, 24 Jun 2014 06:34:13 -0700 (PDT) Message-ID: <53A97E59.4010406@joelhalpern.com> Date: Tue, 24 Jun 2014 09:34:17 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" , "adrian@olddog.co.uk" , "routing-discussion@ietf.org" Subject: Re: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/keDWb0JMpoAtR7upxKkbc2qBsQ8 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 13:34:30 -0000 While I chartered MANAT a long time ago, I don't really know enough about what is it doing. SO I could not, in good faith explicitly recommend closure, merging with low power, or leaving along. Yours, Joel On 6/24/14, 9:24 AM, Dearlove, Christopher (UK) wrote: > No mention of MANET in Joel’s analysis. > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > *From:*routing-discussion [mailto:routing-discussion-bounces@ietf.org] > *On Behalf Of *Adrian Farrel > *Sent:* 24 June 2014 14:05 > *To:* routing-discussion@ietf.org > *Subject:* FW: Routing Area organization > > **** WARNING **** > > /This message originates from outside our organisation, either from an > external partner or the internet.// > /Consider carefully whether you should click on any links, open any > attachments or reply./ > /For information regarding //*/Red Flags/*/that you can look out for in > emails you receive, click here > .// > /If you feel the email is suspicious, please follow this process > .// > > Forwarding with Joel's permission. > > *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] > *Sent:* 23 June 2014 17:14 > *To:* Alia Atlas; adrian@olddog.co.uk > *Subject:* Routing Area organization > > (Feel free to circulate this if you think it is useful. I don't have > the right email addresses on this machine to send directly to the > relevant parties.) > > In looking at the discussion of the routing area, it seems to me that > the starting premise is very important. I believe we all agree that we > want a structure that helps us produce useful RFCs to enable a stronger > and more innovative routing system that meets the real needs of the > various kinds of operations to deliver Internet services. (I.e the > general IETF goals.) > > The following are my rough thoughts on this topic, as input to the > discussion. > > First, I take it as given that there may well be a better way to > structure the work. The structure we have is an outgrowth of years of > accumulation. It seems to me distinctly worth looking at whether > looking at what changes we can make, what they will accomplish,a nd if > any of them are likely to improve our working. Personally, I think this > examination is long overdue. Note that even if we decide that we like > the current structure, it will still have been worth looking and > understanding why we are working the way we are. > > One of the biggest problems I see is the number of times when work has > to be presented in multiple working groups, and the drafts revised to > address related but disconnected concerns. This waste author energy and > working group time. This is a consequence of our feeling a need to > control how protocols evolve. And such control is necessary. But needs > to be balanced with other needs. Also we all become tourists very > often even in working groups we are interested in. > > Any arrangement of work other than treating the world as one working > group (which I hope we all agree would be a very bad idea) will need > some cross-communciation between groups. But some arrangements produce > better commonality. Similarly, any arrangement will produce working > groups where some of the work is of less interest to some of the > participants. But maybe we can get better alignment? > > A couple of obvious examples. Anything that needs to be done in an IGP > needs to be done twice (fortunately, we no longer care about RIP.) > Different working groups all need to develop operations, adminsitration, > and maintenance mechanisms. But that means they need to redevelop the > common understanding of what the needs, known techniques, and hard > questions are. > > So I think we would benefit from rearranging the deck chairs. I would > try to make the groups focus on external needs rather than on mechanism. > > I would start by merging the OSPF and ISIS working groups. > > I would also pull the OAM functions out of the various groups (BFD, > MPLS, CCAMP, …) and create one place that can deal with OAM issues. > > I would probably then merge SPRING with core MPLS functioning. > > We have just closed KARP, and I would (unhappily, but I think > necessarily) close ForCES. > > I would either close ROLLand move the work into a common low power group > in another area, or make ti the common low power working group. > > I would merge IDR and SIDR. With the current SIDR work program, it no > longer makes sense to me to treat them as separate. > > I would look at merging L2vpn and l3vpn back together. And combining > them with NVO3. Probably also include PWE3 in that set, although that > is a harder call and may be too different. > > I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they > would fit well with other groups. > > Yours, > > Joel > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Tue Jun 24 07:11:32 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5716B1B2A4B for ; Tue, 24 Jun 2014 07:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq7gSMHXY-CV for ; Tue, 24 Jun 2014 07:11:21 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6901B2A35 for ; Tue, 24 Jun 2014 07:11:16 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s5OEBDB0002473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jun 2014 09:11:14 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s5OEAuWt000307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Jun 2014 16:11:13 +0200 Received: from [172.27.205.228] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 24 Jun 2014 16:11:01 +0200 Message-ID: <53A986F5.9060608@alcatel-lucent.com> Date: Tue, 24 Jun 2014 16:11:01 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Subject: Re: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <53A97E59.4010406@joelhalpern.com> In-Reply-To: <53A97E59.4010406@joelhalpern.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/2O-VAJCSQUnDDDA2lsgbafrIxUg X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:11:29 -0000 Joel, and what would be your views on the remaining two: I2RS and SFC? Also, except for OAM, you propose to merge groups. Do you think there are other elements existing in various working groups which we could aggregate to form a new WG, i.e. do a split and merge rather than a merge only. -m Le 24/06/2014 15:34, Joel M. Halpern a écrit : > While I chartered MANAT a long time ago, I don't really know enough > about what is it doing. SO I could not, in good faith explicitly > recommend closure, merging with low power, or leaving along. > > Yours, > Joel > > On 6/24/14, 9:24 AM, Dearlove, Christopher (UK) wrote: >> No mention of MANET in Joel’s analysis. >> >> -- >> >> Christopher Dearlove >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >> chris.dearlove@baesystems.com | >> http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> *From:*routing-discussion [mailto:routing-discussion-bounces@ietf.org] >> *On Behalf Of *Adrian Farrel >> *Sent:* 24 June 2014 14:05 >> *To:* routing-discussion@ietf.org >> *Subject:* FW: Routing Area organization >> >> **** WARNING **** >> >> /This message originates from outside our organisation, either from an >> external partner or the internet.// >> /Consider carefully whether you should click on any links, open any >> attachments or reply./ >> /For information regarding //*/Red Flags/*/that you can look out for in >> emails you receive, click here >> .// >> >> /If you feel the email is suspicious, please follow this process >> .// >> >> >> Forwarding with Joel's permission. >> >> *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] >> *Sent:* 23 June 2014 17:14 >> *To:* Alia Atlas; adrian@olddog.co.uk >> *Subject:* Routing Area organization >> >> (Feel free to circulate this if you think it is useful. I don't have >> the right email addresses on this machine to send directly to the >> relevant parties.) >> >> In looking at the discussion of the routing area, it seems to me that >> the starting premise is very important. I believe we all agree that we >> want a structure that helps us produce useful RFCs to enable a stronger >> and more innovative routing system that meets the real needs of the >> various kinds of operations to deliver Internet services. (I.e the >> general IETF goals.) >> >> The following are my rough thoughts on this topic, as input to the >> discussion. >> >> First, I take it as given that there may well be a better way to >> structure the work. The structure we have is an outgrowth of years of >> accumulation. It seems to me distinctly worth looking at whether >> looking at what changes we can make, what they will accomplish,a nd if >> any of them are likely to improve our working. Personally, I think this >> examination is long overdue. Note that even if we decide that we like >> the current structure, it will still have been worth looking and >> understanding why we are working the way we are. >> >> One of the biggest problems I see is the number of times when work has >> to be presented in multiple working groups, and the drafts revised to >> address related but disconnected concerns. This waste author energy and >> working group time. This is a consequence of our feeling a need to >> control how protocols evolve. And such control is necessary. But needs >> to be balanced with other needs. Also we all become tourists very >> often even in working groups we are interested in. >> >> Any arrangement of work other than treating the world as one working >> group (which I hope we all agree would be a very bad idea) will need >> some cross-communciation between groups. But some arrangements produce >> better commonality. Similarly, any arrangement will produce working >> groups where some of the work is of less interest to some of the >> participants. But maybe we can get better alignment? >> >> A couple of obvious examples. Anything that needs to be done in an IGP >> needs to be done twice (fortunately, we no longer care about RIP.) >> Different working groups all need to develop operations, adminsitration, >> and maintenance mechanisms. But that means they need to redevelop the >> common understanding of what the needs, known techniques, and hard >> questions are. >> >> So I think we would benefit from rearranging the deck chairs. I would >> try to make the groups focus on external needs rather than on mechanism. >> >> I would start by merging the OSPF and ISIS working groups. >> >> I would also pull the OAM functions out of the various groups (BFD, >> MPLS, CCAMP, …) and create one place that can deal with OAM issues. >> >> I would probably then merge SPRING with core MPLS functioning. >> >> We have just closed KARP, and I would (unhappily, but I think >> necessarily) close ForCES. >> >> I would either close ROLLand move the work into a common low power group >> in another area, or make ti the common low power working group. >> >> I would merge IDR and SIDR. With the current SIDR work program, it no >> longer makes sense to me to treat them as separate. >> >> I would look at merging L2vpn and l3vpn back together. And combining >> them with NVO3. Probably also include PWE3 in that set, although that >> is a harder call and may be too different. >> >> I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they >> would fit well with other groups. >> >> Yours, >> >> Joel >> >> ******************************************************************** >> This email and any attachments are confidential to the intended >> recipient and may also be privileged. If you are not the intended >> recipient please delete it from your system and notify the sender. >> You should not copy it or use it for any purpose nor disclose or >> distribute its contents to any other person. >> ******************************************************************** >> >> >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion >> > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > > From nobody Tue Jun 24 12:46:39 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA16B1A037D; Tue, 24 Jun 2014 12:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAsORPfBcIFM; Tue, 24 Jun 2014 12:46:23 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16471A03C1; Tue, 24 Jun 2014 12:46:15 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OJkDjZ024113; Tue, 24 Jun 2014 20:46:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OJkAUT024083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 20:46:13 +0100 From: "Adrian Farrel" To: , Subject: Heads up interesting IRTF talk Date: Tue, 24 Jun 2014 20:46:08 +0100 Message-ID: <035e01cf8fe4$f36212c0$da263840$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+P5NmxFjkJp+wQSeKwuhx3i4Ptdw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20778.000 X-TM-AS-Result: No--0.746-10.0-31-10 X-imss-scan-details: No--0.746-10.0-31-10 X-TMASE-MatchedRID: RZGtuGBMNjW2oWr/dU6+kB9NWUi6yjCBXArLpqs9pJctWyi3YZaESQji 0cLmTX9f+BY5Eio9E49aaVIsgpwFfl1YKGD2ztkY4EprSlQmFqB9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASdET58jp62SkiEZtEMssv51kG6E/AtJXkZR7/RTlTYnTFwq2LzmPhjFQy 4iPkNYGwkCnkA3h/n1D701dfVAizuSL9OvtUca/e6+D482nHhrnqg/VrSZEiM= Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/FbzpNrGcu02y9NOcLfjHs5Ify3Q Cc: "Eggert, Lars" , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:46:29 -0000 There will be a talk describing a prize-winning piece of research in the IRTF Open Meeting in Toronto at 1420-1620 on Tuesday. > *** Robert Lychev *** for studying the security benefits provided by partially-deployed S*BGP: > > Robert Lychev, Sharon Goldberg and Michael Schapira. BGP > Security in Partial Deployment. Proc.ACM SIGCOMM, Hong Kong, > China, August 2013. Adrian From nobody Tue Jun 24 13:11:43 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC701A040D; Tue, 24 Jun 2014 13:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPUi1XDuXj9A; Tue, 24 Jun 2014 13:11:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BFE1A0657; Tue, 24 Jun 2014 13:11:40 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OKBcHW025209; Tue, 24 Jun 2014 21:11:38 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5OKBbpu025196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 21:11:37 +0100 From: "Adrian Farrel" To: , , Subject: Routing ADs Office Hours in Toronto Date: Tue, 24 Jun 2014 21:11:35 +0100 Message-ID: <036e01cf8fe8$80104bd0$8030e370$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+P6FQ1tLVATknZRher9l4vNyySoQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20778.000 X-TM-AS-Result: No--0.300-10.0-31-10 X-imss-scan-details: No--0.300-10.0-31-10 X-TMASE-MatchedRID: h+ImdGngmi9/gSvKvDS34/DrFod3YoIKHn56mq8Jolzfc2Xd6VJ+ytZa 6QhQXxWc4I57YhQrM5jY/yalI0CEiNpUsVk2Y0Y0hxT8BJzgrJ1DGFvBeB2nXGrhyhOS2sZfm6K OvyUkGsK1FKoGIAdzbJGTpe1iiCJqtD9qpBlNF8rQLWxBF9DMQcRB0bsfrpPInxMyeYT53RmqNM fjPmINBqZE5SbG4fn/uWhrVbfxy54kjL3+PTmBbEkbs5SLEcJAPBs2PLDkWaTUTFbYKqDtum/7X pqF2awvaiAi5jPCznql1O/WvQ0mLI9NJFPyrFBRLg4B6mj6omcVqi/E4tLe3lZca9RSYo/b Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/J2k5kIHWjFP0q-5iY4DQaEo9_3M X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:11:42 -0000 Hi, As usual the Routing ADs will hold open office on Sunday at IETF-90. We'll be in the IESG Breakout Room (room to be announced later or check with the Secretariat) from 14.30-16.00 on Sunday afternoon. The purpose of the meeting is to allow you to come along and raise / discuss any issues or concerns you have about routing or the Area. Clearly the hot topic is potential reorganisation of the area and we are happy to have discussion of that at the open office. We will also be dedicating a good chunk of the Area meeting on Thursday to that topic, so don't feel restricted to only talk to us about that. See you in Toronto, Adrian and Alia From nobody Wed Jun 25 03:54:17 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2A1B2B65 for ; Wed, 25 Jun 2014 03:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHDJW_JXLrhn for ; Wed, 25 Jun 2014 03:54:11 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCE41B2A9D for ; Wed, 25 Jun 2014 03:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11835; q=dns/txt; s=iport; t=1403693650; x=1404903250; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to; bh=oSCIUTEbUFl/dzB4V4tfwczL4EDT2iBHy1+jO5NDB8U=; b=B7Amp7anHSkr89qcVaBW03+9EU8FociZczbcLHVqKUVVkN0qHQoTr8ye 6ybetE43n6lS3KtVv6pLbwQvlA0Fz4etcdSWW/pUHYwq4iwWZwczwRgN0 5ScAunXlZ4Y6F9H0CpqMHxh9lWbi4p0Cgv9D/zdCh2dcUr50dPT/0uFuM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUEAOSpqlOtJssW/2dsb2JhbABagkaKO6E/BQGZOgGBJXWEAwEBAQMBeAYLCyEWDwkDAgECATwJBwwIAQGINgiqWZclF4VjiEtVhEMFmlGTa4ND X-IronPort-AV: E=Sophos; i="5.01,545,1400025600"; d="scan'208,217"; a="93107097" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 25 Jun 2014 10:54:08 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5PAs8Zo012212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2014 10:54:08 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s5PAs7kL013104; Wed, 25 Jun 2014 11:54:07 +0100 (BST) Message-ID: <53AAAA52.6080701@cisco.com> Date: Wed, 25 Jun 2014 11:54:10 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk, routing-discussion@ietf.org Subject: Re: FW: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> In-Reply-To: <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------070402060508040502010702" Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/3tAS8trlbgQSVkDwlSrCM0ONKiA X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 10:54:14 -0000 This is a multi-part message in MIME format. --------------070402060508040502010702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > I would start by merging the OSPF and ISIS working groups. > I agree, although I would make this something like IGPmaint and give it the scope off all IGPs. I take this position becsue partially because there was a small issue that arose with RIP recently and there was no where to take it, and partially because I am not convinced we should write off DV protocols yet since they can do some quire interesting things. I might take MRT to this WG since it is a routing protocol. > > I would also pull the OAM functions out of the various groups (BFD, > MPLS, CCAMP, ...) and create one place that can deal with OAM issues. > That works. > > I would probably then merge SPRING with core MPLS functioning. > I am not sure about this. IF SPRING reduced scope to MPLS that would work, but I do not see how you would do IPv6 in the MPLS WG, and it we split it we will end up with two forking designs. > > We have just closed KARP, and I would (unhappily, but I think > necessarily) close ForCES. > Agree > > I would either close ROLLand move the work into a common low power > group in another area, or make ti the common low power working group. > That makes sense. > > I would merge IDR and SIDR. With the current SIDR work program, it no > longer makes sense to me to treat them as separate. > I think that this makes sense in the long term (12 to 18months) but I am not sure that SIDR is down to the level of work where this would make sense yet. > > I would look at merging L2vpn and l3vpn back together. And combining > them with NVO3. Probably also include PWE3 in that set, although that > is a harder call and may be too different. > I tried the LxVPN merge and it was not popular, but now might be the time to try again. I don't think NVO3 belongs there since that will set the assumption of a L3VPN control plane and although the L3VPN part shoulr probbaly be moved to the LxVPN or at least the L3VPN WG > > I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they > would fit well with other groups. > Given that PWE3 is mainly LDP control plane and not much dataplane anymore, I would think about merging it into MPLS. - Stewart --------------070402060508040502010702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I would start by merging the OSPF and ISIS working groups. 

I agree, although I would make this something like IGPmaint and give it the scope off all IGPs. I take this position becsue partially because there was a small issue that arose with RIP recently and there was no where to take it, and partially because I am not convinced we should write off DV protocols yet since they can do some quire interesting things. I might take MRT to this WG since it is a routing protocol.

I would also pull the OAM functions out of the various groups (BFD, MPLS, CCAMP, …) and create one place that can deal with OAM issues.

That works.

I would probably then merge SPRING with core MPLS functioning.

I am not sure about this. IF SPRING reduced scope to MPLS that would work, but I do not see how you would do IPv6 in the MPLS WG, and it we split it we will end up with two forking designs.

We have just closed KARP, and I would (unhappily, but I think necessarily) close ForCES.

Agree

I would either close ROLLand move the work into a common low power group in another area, or make ti the common low power working group.

That makes sense.

I would merge IDR and SIDR.  With the current SIDR work program, it no longer makes sense to me to treat them as separate.

I think that this makes sense in the long term (12 to 18months) but I am not sure that SIDR is down to the level of work where this would make sense yet.

I would look at merging L2vpn and l3vpn back together.  And combining them with NVO3.  Probably also include PWE3 in that set, although that is a harder call and may be too different.

I tried the LxVPN merge and it was not popular, but now might be the time to try again. I don't think NVO3 belongs there since that will set the assumption of a L3VPN control plane and although the L3VPN part shoulr probbaly be moved to the LxVPN or at least the L3VPN WG

 

I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would fit well with other groups.

 


Given that PWE3 is mainly LDP control plane and not much dataplane anymore, I would think about merging it into MPLS.

- Stewart
--------------070402060508040502010702-- From nobody Wed Jun 25 03:55:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4081B2B78 for ; Wed, 25 Jun 2014 03:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1vwdTCaBufM for ; Wed, 25 Jun 2014 03:55:15 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157261B2B65 for ; Wed, 25 Jun 2014 03:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=193; q=dns/txt; s=iport; t=1403693715; x=1404903315; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=s49ZSvrvWF/WT6sZUxEpClazvNtkEvJeSOBDw39AHnQ=; b=HL7daJL3BrHaXq7kyL1By3GXTmb87mMbLcdtm0svUpqp5gbMIKWd17Gf h4XFw6s309xjWImu2cUwsmBHdVSHY0itaVueIaxdDR21YUK3xGmZP2Xrw PC0zkuceLzVEPJlK/ZxDWdwd+LgeGsx8JwO7CRWRb1vSwbho3uMKdLFHz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucEAGupqlOtJssW/2dsb2JhbABakUqcdgUBliWDFQGBJXWEAwEBAQQ4QBELGAkWDwkDAgECAUUGAQwIAQGIPqpZlyUXhWOJIIRDAQSaUZNrg0M X-IronPort-AV: E=Sophos;i="5.01,545,1400025600"; d="scan'208";a="93130767" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 25 Jun 2014 10:55:13 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5PAtCNI032581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2014 10:55:13 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s5PAtBDG013180; Wed, 25 Jun 2014 11:55:12 +0100 (BST) Message-ID: <53AAAA93.8090809@cisco.com> Date: Wed, 25 Jun 2014 11:55:15 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Vigoureux , routing-discussion@ietf.org Subject: Re: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <53A97E59.4010406@joelhalpern.com> <53A986F5.9060608@alcatel-lucent.com> In-Reply-To: <53A986F5.9060608@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/rh64_dcAXxKKKIQkuQnDSx8qpkk X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 10:55:16 -0000 On 24/06/2014 15:11, Martin Vigoureux wrote: > Joel, > > and what would be your views on the remaining two: I2RS and SFC? They probably need to continue on their own for a bit. Stewart From nobody Wed Jun 25 04:46:49 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757691B2BA4 for ; Wed, 25 Jun 2014 04:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK0_R42Lu397 for ; Wed, 25 Jun 2014 04:46:46 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F028D1B2BB5 for ; Wed, 25 Jun 2014 04:46:45 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5PBkfuf016565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jun 2014 06:46:42 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5PBkeET023262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jun 2014 13:46:40 +0200 Received: from [135.244.228.255] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 25 Jun 2014 13:46:41 +0200 Message-ID: <53AAB69F.3050407@alcatel-lucent.com> Date: Wed, 25 Jun 2014 13:46:39 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: , Subject: Re: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <53A97E59.4010406@joelhalpern.com> <53A986F5.9060608@alcatel-lucent.com> <53AAAA93.8090809@cisco.com> In-Reply-To: <53AAAA93.8090809@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/VqKvpvzNUoPfkWa5QVIeGWmp6a4 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 11:46:47 -0000 Le 25/06/2014 12:55, Stewart Bryant a écrit : > On 24/06/2014 15:11, Martin Vigoureux wrote: >> Joel, >> >> and what would be your views on the remaining two: I2RS and SFC? > They probably need to continue on their own for a bit. > > Stewart Does this suggest that, in your opinion, only mature WG are subject to the reorganisation? -m From nobody Wed Jun 25 05:46:17 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6C1B2BDD for ; Wed, 25 Jun 2014 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfZWaT-juTku for ; Wed, 25 Jun 2014 05:46:09 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F8D1B2BFC for ; Wed, 25 Jun 2014 05:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=816; q=dns/txt; s=iport; t=1403700368; x=1404909968; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=LAnN/YGpXDxU78l3/LtOJ6tMBpXI15QwZn5SHLHDIlk=; b=VnGwT5UMJbxvomcR4m7tsDSlPq2tancY+OFiYdxwpBcAW8jHadl/dzmt 6QGFVNlaVu5E4r0sVMJBOK6iV7L4tyn5b5xTeVxkVdDPgQ13CUL4fW5wp z7LeRVYLUBWftTenOgQQmexB2wfdZmq9eiaP8n3G24qNvTpyIPwZo4zAb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMEADnDqlOtJssW/2dsb2JhbABZrkYFAZYlgxUBgSF1hAMBAQEEMgEFQBELGAkWDwkDAgECAUUGAQwIAQGIPqo2lyYXhWOJIIRDAQSaUZNrg0M X-IronPort-AV: E=Sophos;i="5.01,546,1400025600"; d="scan'208";a="97279033" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 25 Jun 2014 12:46:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5PCk43o027402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2014 12:46:05 GMT Received: from STBRYANT-M-R010.CISCO.COM (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s5PCk3Ui018613; Wed, 25 Jun 2014 13:46:04 +0100 (BST) Message-ID: <53AAC48B.9000403@cisco.com> Date: Wed, 25 Jun 2014 13:46:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Vigoureux , routing-discussion@ietf.org Subject: Re: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <53A97E59.4010406@joelhalpern.com> <53A986F5.9060608@alcatel-lucent.com> <53AAAA93.8090809@cisco.com> <53AAB69F.3050407@alcatel-lucent.com> In-Reply-To: <53AAB69F.3050407@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/0YmyTxtT5ET2cgRlQjGOEfSZrDY X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 12:46:15 -0000 On 25/06/2014 12:46, Martin Vigoureux wrote: > Le 25/06/2014 12:55, Stewart Bryant a écrit : >> On 24/06/2014 15:11, Martin Vigoureux wrote: >>> Joel, >>> >>> and what would be your views on the remaining two: I2RS and SFC? >> They probably need to continue on their own for a bit. >> >> Stewart > > Does this suggest that, in your opinion, only mature WG are subject to > the reorganisation? That depends! Certainly I would start that way. The recent WGs were created by the consensus of the IETF and if it made sense to merge them with existing WGs that would have been considered at the time of creation. The starting point would therefore seem to be to consider the older WGs and then to see the shape of the area looked like before changing those that were recently created. Stewart From nobody Wed Jun 25 18:19:49 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9168F1B2EA8 for ; Wed, 25 Jun 2014 18:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ELJTHrwtjN for ; Wed, 25 Jun 2014 18:19:39 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC471B2EA5 for ; Wed, 25 Jun 2014 18:19:39 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 19so1618587ykq.19 for ; Wed, 25 Jun 2014 18:19:38 -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=lxWH84JtRZC4rYcD9PxrLVDK3vOSWnIHbLFTwWRGroM=; b=tvlIgi/DH0X3IDjzdiUXWK1i1YEXb6JARosn+tJz8RKPj3XN/MJEQAlnFLJaMz+exO sMyQt21lDnrUcckZd+2BvGBld0BYYBpSSf6bgFStFGnPcVEnpxppJDWNEWxH2MZQGy8O tGWrK25+JTxWyLVqz4+DH8aalOKcXA3NqiFUyGPgif72tJkAafoeqvDASs0bBaHhX+oY V6Rgp26pFHxk/r+ReP1iROCxFEaEu1U7uEuY0vQ1i3wPtRxkIz5mGbz4nCT0RRaCdvFq z0rSGRSf6IqdwefE6pD4l0Dk/eHGDFzF0TEhttURLbCt+Txbfgu2AcL434OB3t1pTG7K 1SMw== MIME-Version: 1.0 X-Received: by 10.236.144.137 with SMTP id n9mr16471427yhj.37.1403745578531; Wed, 25 Jun 2014 18:19:38 -0700 (PDT) Received: by 10.170.194.19 with HTTP; Wed, 25 Jun 2014 18:19:38 -0700 (PDT) In-Reply-To: <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> Date: Thu, 26 Jun 2014 02:19:38 +0100 Message-ID: Subject: Re: FW: Routing Area organization From: Abdussalam Baryun To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=20cf303dd74a9043e104fcb2fc1c Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Nm3s6TFW7hyFmN22tq_yS7QqRpU Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 01:19:41 -0000 --20cf303dd74a9043e104fcb2fc1c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't agree mostly because the details/reasons for merge did not including performance/production of each WG or related main routing RFC standards. Comments below, On Tuesday, June 24, 2014, Adrian Farrel wrote: > Forwarding with Joel's permission. > > > > *From:* Joel Halpern [mailto:joel.halpern@ericsson.com > ] > *Sent:* 23 June 2014 17:14 > *To:* Alia Atlas; adrian@olddog.co.uk > > *Subject:* Routing Area organization > > > > (Feel free to circulate this if you think it is useful. I don't have the > right email addresses on this machine to send directly to the relevant > parties.) > > > > In looking at the discussion of the routing area, it seems to me that the > starting premise is very important. I believe we all agree that we want = a > structure that helps us produce useful RFCs to enable a stronger and more > innovative routing system that meets the real needs of the various kinds = of > operations to deliver Internet services. (I.e the general IETF goals.) > > So our analysis need also to consider our useful RFCs or our main routing standards that new RFCs develop from. Any decision we make should look into the current standards of this Area. > The following are my rough thoughts on this topic, as input to the > discussion. > > > > First, I take it as given that there may well be a better way to structur= e > the work. The structure we have is an outgrowth of years of accumulation= . > > IMHO, the WG work structure has no problem, the problem is Area structure, or Area Work. The topic is about the Area or inside the Area not inside the WG. > It seems to me distinctly worth looking at whether looking at what > changes we can make, what they will accomplish,a nd if any of them are > likely to improve our working. Personally, I think this examination is > long overdue. Note that even if we decide that we like the current > structure, it will still have been worth looking and understanding why we > are working the way we are. > > We are working the way we are because we follow ADs or IESG, and mostly w= e concentrate on work within WG but leave Area work to ADs. Leaders are responsible but followers may waste efforts. > > > One of the biggest problems I see is the number of times when work has to > be presented in multiple working groups, and the drafts revised to addres= s > related but disconnected concerns. This waste author energy and working > group time. This is a consequence of our feeling a need to control how > protocols evolve. And such control is necessary. But needs to be balanc= ed > with other needs. Also we all become tourists very often even in workin= g > groups we are interested in. > > Yes > > > Any arrangement of work other than treating the world as one working grou= p > (which I hope we all agree would be a very bad idea) will need some > cross-communciation between groups. > > This can be done by DTs or WGs' chairs, as first, then when we get result= s or recommendations we can do larger volumes. > But some arrangements produce better commonality. Similarly, any > arrangement will produce working groups where some of the work is of less > interest to some of the participants. But maybe we can get better > alignment? > > We cannot depend on probabilities, and we need known agreements of future arrangements. > > > A couple of obvious examples. Anything that needs to be done in an IGP > needs to be done twice (fortunately, we no longer care about RIP.) > Different working groups all need to develop operations, adminsitration, > and maintenance mechanisms. But that means they need to redevelop the > common understanding of what the needs, known techniques, and hard > questions are. > > I think IESG should push for that redevelop strategy for all Areas. > > > So I think we would benefit from rearranging the deck chairs. I would tr= y > to make the groups focus on external needs rather than on mechanism. > > Please don't ignore that our IETF process structure WGs, so who approved charters. I think let us think that we are the AD to rearrange the Area, so what is Area manager focus before the Group manager? Then what is the Group focus? The directors should focus first on the external needs, to form progress, then groups will be more guided. > > > I would start by merging the OSPF and ISIS working groups. > > I would also pull the OAM functions out of the various groups (BFD, MPLS, > CCAMP, =E2=80=A6) and create one place that can deal with OAM issues. > > I would probably then merge SPRING with core MPLS functioning. > > We have just closed KARP, and I would (unhappily, but I think necessarily= ) > close ForCES. > > I would either close ROLLand move the work into a common low power group > in another area, or make ti the common low power working group. > > I would merge IDR and SIDR. With the current SIDR work program, it no > longer makes sense to me to treat them as separate. > > I would look at merging L2vpn and l3vpn back together. And combining the= m > with NVO3. Probably also include PWE3 in that set, although that is a > harder call and may be too different. > > > > I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they > would fit well with other groups. > > > The above suggestions have not clarify reasons, but seem to help more noise, more work for WG-Chair, less group-production, and less work for ADs. What are the main standards and future developments? What are the results of performance of those WGs? AB --20cf303dd74a9043e104fcb2fc1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't agree mostly because the details/reasons for merge did=C2= =A0not including performance/production of each WG or related=C2=A0main rou= ting=C2=A0RFC standards.=C2=A0Comments below,

On Tuesday, June 24, = 2014, Adrian Farrel wrote:

Forwarding wi= th Joel's permission.

=C2=A0

From: Joel Halpern [mailto:joel.halpern@ericsson.com]
Sent: 23 June 2014 17:14
To: Alia Atlas; adrian@olddog.co.uk
Subject: Routing Area organization<= u>

=C2=A0

(Feel free to circulate this if you think it is usef= ul.=C2=A0 I don't have the right email addresses on this machine to sen= d directly to the relevant parties.)

=C2=A0

In looking at the discussion = of the routing area, it seems to me that the starting premise is very impor= tant.=C2=A0 I believe we all agree that we want a structure that helps us p= roduce useful RFCs to enable a stronger and more innovative routing system = that meets the real needs of the various kinds of operations to deliver Int= ernet services.=C2=A0 (I.e the general IETF goals.)

So our= analysis need also=C2=A0to consider our useful RFCs or our main routing st= andards that new RFCs develop from.=C2=A0=C2=A0Any decision we make should = look into the current standards of this Area. =C2=A0

The following are my rough thoughts on this topic, as input to the discus= sion.

=C2=A0

First, I take it as given tha= t there may well be a better way to structure the work.=C2=A0 The structure= we have is an outgrowth of years of accumulation.


IMHO, the=C2=A0WG=C2=A0work structure has no pro= blem, the problem is Area structure, or Area Work. The topic is about the A= rea or inside the Area not inside the WG.=C2=A0

=C2=A0 It seems to me distinctly wor= th looking at whether looking at what changes we can make, what they will a= ccomplish,a nd if any of them are likely to improve our working.=C2=A0 Pers= onally, I think this examination is long overdue.=C2=A0 Note that even if w= e decide that we like the current structure, it will still have been worth = looking and understanding why we are working the way we are.<= /span>

We are= working the way we are because we follow ADs or IESG, and mostly we concen= trate on work within WG but leave Area work to ADs. Leaders are responsible= but followers may waste efforts.=C2=A0

=C2=A0

One of the biggest problems I see is the number of times when work has t= o be presented in multiple working groups, and the drafts revised to addres= s related but disconnected concerns.=C2=A0 This waste author energy and wor= king group time.=C2=A0 This is a consequence of our feeling a need to contr= ol how protocols evolve.=C2=A0 And such control is necessary.=C2=A0 But nee= ds to be balanced with other needs.=C2=A0=C2=A0 Also we all become tourists= very often even in working groups we are interested in.


Yes=C2=A0=C2=A0

=C2=A0

Any arrangement of work other = than treating the world as one working group (which I hope we all agree wou= ld be a very bad idea) will need some cross-communciation between groups.= =C2=A0=C2=A0

This can be done by DTs or WGs' chairs, as first, then when= we get results or recommendations we can do larger volumes.=C2=A0=C2=A0

But some arrangements produce better= commonality.=C2=A0 Similarly, any arrangement will produce working groups = where some of the work is of less interest to some of the participants.=C2= =A0 But maybe we can get better alignment?

We can= not depend on probabilities, and we need known=C2=A0agreements of future ar= rangements.=C2=A0

=C2=A0<= /u>

A couple of obvious examples.= =C2=A0 Anything that needs to be done in an IGP needs to be done twice (for= tunately, we no longer care about RIP.)=C2=A0 Different working groups all = need to develop operations, adminsitration, and maintenance mechanisms.=C2= =A0 But that means they need to redevelop the common understanding of what = the needs, known techniques, and hard questions are.

I thin= k IESG should push for that redevelop strategy=C2=A0for all Areas.=C2=A0=C2= =A0

=C2=A0<= /u>

So I think we would benefit fr= om rearranging the deck chairs.=C2=A0 I would try to make the groups focus = on external needs rather than on mechanism.

Please= don't ignore that our IETF process structure WGs, so who approved char= ters.=C2=A0I think let us think that we are the=C2=A0AD=C2=A0to rearrange t= he Area,=C2=A0so what is Area manager focus before the Group manager?=C2=A0= Then what is the Group=C2=A0focus? The directors should focus first on the = external needs, to form progress, then groups will be more guided.=C2=A0

=C2=A0

I would start by merging the OSPF and ISIS working groups.=C2=A0 =

I would also pull the OAM func= tions out of the various groups (BFD, MPLS, CCAMP, =E2=80=A6) and create on= e place that can deal with OAM issues.

I would probably then merge SP= RING with core MPLS functioning.

We have just closed KARP, and I would (unhappily, but I think ne= cessarily) close ForCES.

I would either close ROLLand move the work into a common low pow= er group in another area, or make ti the common low power working group.=

I would merge IDR and SIDR.=C2= =A0 With the current SIDR work program, it no longer makes sense to me to t= reat them as separate.

I would look at merging L2vpn = and l3vpn back together.=C2=A0 And combining them with NVO3.=C2=A0 Probably= also include PWE3 in that set, although that is a harder call and may be t= oo different.

=C2=A0

I would leave CCCAMP, PCE, an= d PIM alone, as I am not seeing how they would fit well with other groups.<= u>


The above suggestions have not cl= arify reasons, but seem to help more noise, more work for WG-Chair, less gr= oup-production,=C2=A0and less work for ADs.=C2=A0What are the main standard= s and future developments? What are the results of performance of those WGs= ?=C2=A0

AB
--20cf303dd74a9043e104fcb2fc1c-- From nobody Thu Jun 26 08:53:37 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34091B2A24 for ; Thu, 26 Jun 2014 08:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB7DgXJHTbFa for ; Thu, 26 Jun 2014 08:53:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4011B31C5 for ; Thu, 26 Jun 2014 07:55:36 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 26 Jun 2014 14:55:33 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0969.007; Thu, 26 Jun 2014 14:55:33 +0000 From: Ross Callon To: Alia Atlas , "routing-discussion@ietf.org" Subject: LxVPN, RE: Improving and Restructuring the Routing Area Thread-Topic: LxVPN, RE: Improving and Restructuring the Routing Area Thread-Index: AQHPhOZLafoij3+aqkKhXgVuYb6Fv5uDkWig Date: Thu, 26 Jun 2014 14:55:32 +0000 Message-ID: <2b6a8f5df5e04cea989e163f05302c92@CO2PR05MB636.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(164054003)(377454003)(19625215002)(76576001)(16236675004)(74502001)(74662001)(4396001)(85852003)(83072002)(95666004)(99286002)(107046002)(18717965001)(105586002)(106356001)(31966008)(106116001)(15202345003)(85306003)(86362001)(79102001)(64706001)(92566001)(77982001)(20776003)(80022001)(66066001)(101416001)(46102001)(99396002)(19300405004)(2656002)(83322001)(19609705001)(15975445006)(19580405001)(87936001)(19580395003)(21056001)(76482001)(54356999)(50986999)(76176999)(33646001)(81542001)(74316001)(81342001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2b6a8f5df5e04cea989e163f05302c92CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/s16pSsenbaMKdN-igaKei1ZemEA X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 15:53:32 -0000 --_000_2b6a8f5df5e04cea989e163f05302c92CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIGlzc3VlIHRoYXQgb2NjdXJzIHRvIG1lIGlzIHRoZSBzcGxpdCBiZXR3ZWVuIEwyVlBOIGFu ZCBMM1ZQTi4gUFdFMyBzZWVtcyB0byBiZSBjbG9zZWx5IHJlbGF0ZWQuDQoNCkkgcmVtZW1iZXIg d2hlbiBQUFZQTiB3YXMgc3BsaXQgaW50byBMMlZQTiBhbmQgTDNWUE4uIEF0IHRoZSB0aW1lIHRo ZXJlIHdhcyBhIHJhdGhlciBhY3RpdmUgZGViYXRlIGdvaW5nIG9uIHJlZ2FyZGluZyBMMlZQTiBz dGFuZGFyZHMgdGhhdCB3YXMgY2F1c2luZyB0aGUgTDNWUE4gd29yayB0byBiZSBzb3J0IG9mIGxv c3QgaW4gdGhlIG5vaXNlLiBUaGlzIHBhcnRpY3VsYXIgbW90aXZhdGlvbiBmb3IgdGhlIHNwbGl0 IGVuZGVkIGxvbmcgYWdvLg0KDQpJIGRvbuKAmXQgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIHJlZ2Fy ZGluZyB3aGV0aGVyIEwyVlBOLCBMM1ZQTiwgYW5kIFBXRTMgc2hvdWxkIHN0YXkgc2VwYXJhdGUg b3Igc2hvdWxkIG1lcmdlLCBidXQgSSB0aGluayB0aGF0IGl0IGlzIGEgcXVlc3Rpb24gd2hpY2gg aXMgd29ydGggYXNraW5nLg0KDQpUaGFua3MsIFJvc3MNCg0KRnJvbTogcm91dGluZy1kaXNjdXNz aW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbGlhIEF0bGFzDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDM6NTggUE0NClRv OiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmcNClN1YmplY3Q6IEltcHJvdmluZyBhbmQgUmVz dHJ1Y3R1cmluZyB0aGUgUm91dGluZyBBcmVhDQoNClRvIGFsbCBwYXJ0aWNpcGFudHMgaW4gdGhl IFJvdXRpbmcgQXJlYSwNCg0KQWRyaWFuIGFuZCBJIGFyZSB3b3JraW5nIG9uIGltcHJvdmluZyB0 aGUgcXVhbGl0eSwgc3BlZWQsIGFuZA0KZXhwZXJpZW5jZSBvZiBnZXR0aW5nIHdvcmsgZG9uZSBp biB0aGUgSUVURiBSb3V0aW5nIEFyZWEuICBUaGVyZSBhcmUNCnRocmVlIGluaXRpYXRpdmVzIHRo YXQgd2UgYXJlIHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWENCnNwZWNpZmljIFdH IGNoYWlyIHRyYWluaW5nLCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3JraW5nIGdyb3VwcyBpbiB0 aGUNCmFyZWEuDQoNCkZpcnN0LCB3ZSBpbnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9y YXRlIG1vcmUgcHJvYWN0aXZlbHkgYnkNCmludHJvZHVjaW5nIGEgV29ya2luZyBHcm91cCBEcmFm dCBRdWFsaXR5IEFzc3VyYW5jZSAoV0cgRHJhZnQgUUEpDQpwcm9jZXNzIHdoZXJlIHRoZSBzYW1l IHNlbGVjdGVkIHJvdXRpbmcgZGlyZWN0b3JhdGUgbWVtYmVyIHdpbGwgcmV2aWV3DQphIGRyYWZ0 IGR1cmluZyBXRyBkcmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3QgY2FsbC4gIFRoZSBw cm9jZXNzDQp3aWxsIGJlIGRvY3VtZW50ZWQgb24gdGhlIFJvdXRpbmcgQXJlYSB3aWtpDQooaHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpKS4gIFRoaXMgc2hvdWxk IGFsbG93DQpkaXJlY3RvcmF0ZSByZXZpZXdzIHRvIHJlcG9ydCB0ZWNobmljYWwgaXNzdWVzIHRo YXQgY2FuIGFjdHVhbGx5IGdldA0KZml4ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxl bnQgb2YgYnVnIHJlcG9ydHMpIGFzIG9wcG9zZWQgdG8NCmp1c3Qgbm90aW5nIHRoZSBjb25jZXJu cyBpbiB0aGUgZHJhZnRzIChlcXVpdmFsZW50IG9mIHJlbGVhc2Ugbm90ZXMpLg0KDQpTZWNvbmQs IGFzIHdhcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSByZWNlbnQgSUVTRyByZXRyZWF0LCBpbiBhZGRp dGlvbg0KdG8gdGhlIElFVEYtd2lkZSBXRyBjaGFpciB0cmFpbmluZywgd2UgaW50ZW5kIHRvIGhh dmUgYSBzZXJpZXMgb2YNCnRyYWluaW5nIHNlc3Npb25zIGZvciBXRyBDaGFpcnMgaW4gdGhlIFJv dXRpbmcgQXJlYSBhZGRyZXNzaW5nIHRvcGljcw0Kc3VjaCBhcyBqdWRnaW5nIGNvbnNlbnN1cywg cHJvamVjdCBtYW5hZ2VtZW50LCBtb3RpdmF0aW5nIHZvbHVudGVlcnMsDQp1c2luZyB0aGUgZGF0 YXRyYWNrZXIgKHZpYSBhIHNhbmRib3ggdmVyc2lvbiB0aGF0IGNhbiBiZSBwbGF5ZWQNCndpdGgg c2FmZWx5KSwgYW5kIHNoYXJpbmcgZXhwZXJpZW5jZXMgYmV0d2VlbiBXRyBjaGFpcnMuDQoNClRo aXJkLCB3ZSBpbnRlbmQgdG8gcmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMgaW4gdGhlIFJv dXRpbmcgYXJlYS4NCldlIGZlZWwgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8gZm9jdXMgb24gYXJl YXMgd2hlcmUgdGhlcmUgaXMgYWN0aXZlDQppbnRlcmVzdCBpbiBzdGFuZGFyZGl6YXRpb24gYW5k IHRvIGJlIG9wZW4gYW5kIGFibGUgdG8gYWNjZXB0IG5ldyB3b3JrDQppbnRvIHRoZSBhcmVhLiAg QXMgeW91IGtub3csIHdlIGhhdmUgaGFkIHNldmVyYWwgbmV3IHdvcmtpbmcgZ3JvdXBzDQoobnZv MywgaTJycywgc2ZjLCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhlIGxhc3QgZmV3IHllYXJzIGFuZCB3 ZSBuZWVkIHRvDQpiZSBvcGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3JlIG5ldyB3b3JrIGFzIGl0 IGNvbWVzIGluLiAgV2Ugd291bGQNCmFsc28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWduYWwtdG8t bm9pc2UgcmF0aW8gZXhwZXJpZW5jZWQgYnkNCnBhcnRpY2lwYW50cyBpbiB0aGUgZGlmZmVyZW50 IHdvcmtpbmcgZ3JvdXBzIGFuZCBpbXByb3ZlIHRoZSBxdWFudGl0eQ0KYW5kIHF1YWxpdHkgb2Yg ZGlzY3Vzc2lvbiBhbmQgcmV2aWV3cy4gIEl0IGlzIGxpa2VseSB0aGF0IG5vdCBhbGwgV0dzDQpp biB0aGUgUm91dGluZyBBcmVhIHdpbGwgYmUgZGlyZWN0bHkgYWZmZWN0ZWQuDQoNCkhlcmUgaXMg dGhlIHRpbWUtbGluZSBmb3IgcmVvcmdhbml6aW5nIHRoZSBXR3MuDQoNCiAgIE5PVzogcHVibGlj IGRpc2N1c3Npb24gb24gcm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPG1haWx0bzpyb3V0aW5n LWRpc2N1c3Npb25AaWV0Zi5vcmc+IGFib3V0IGhvdyB0bw0KICAgcmVvcmdhbml6ZSB0aGUgd29y a2luZyBncm91cHMgdG8gYmVzdCBtZWV0IG91ciBtb3RpdmF0aW9ucy4NCiAgIEFkZGl0aW9uYWwg Zm9jdXNlZCBkaXNjdXNzaW9ucyBhcmUgZXhwZWN0ZWQgb24gdGhlDQogICBydGctY2hhaXJzQGll dGYub3JnPG1haWx0bzpydGctY2hhaXJzQGlldGYub3JnPiBhbmQgcnRnLWRpckBpZXRmLm9yZzxt YWlsdG86cnRnLWRpckBpZXRmLm9yZz4gbWFpbGluZyBsaXN0cy4NCg0KICAgSW4gVG9yb250bzog VGhlcmUgd2lsbCBiZSBtZWV0aW5ncyB3aXRoIHRoZSBXRyBjaGFpcnMgYW5kIHRoZQ0KICAgUm91 dGluZyBEaXJlY3RvcmF0ZSB0byBnZXQgdGhlIGlkZWFzIGRlc2NyaWJlZCBhbmQgYWdyZWVkIHVw b24uDQoNCiAgIEF0IHRoZSBSb3V0aW5nIEFyZWEgTWVldGluZyBpbiBUb3JvbnRvOiBEaXNjdXNz IHRoZSBzZXQgb2YNCiAgIHJlb3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBjaGFydGVyIGNvbnRl bnQgaW4gdGhlIFJvdXRpbmcgQXJlYQ0KICAgbWVldGluZy4NCg0KICAgU2VwdGVtYmVyIDIwMTQ6 IEJhc2VkIHVwb24gdGhlIGZlZWRiYWNrLCBzdWdnZXN0aW9ucywgYW5kDQogICBkaXNjdXNzaW9u LCBBZHJpYW4gYW5kIEkgZmluYWxpemUgdGhlIHJlb3JnYW5pemVkIFdHIGNoYXJ0ZXJzLiAgV2UN CiAgIHN0YXJ0IHRoZSBpbnRlcm5hbCBJRVNHIGRpc2N1c3Npb24gYW5kIHB1YmxpYyByZXZpZXdz Lg0KDQogICBPY3RvYmVyIDIwMTQ6IEZvcm1hbCByZWNoYXJ0ZXJpbmcgcHJvY2VzcyBjb21wbGV0 ZXMuDQoNCiAgIEluIEhvbm9sdWx1OiBUaGUgbmV3IHNldCBvZiBXR3MgbWVldC4NCg0KICAgQWZ0 ZXIgSG9ub2x1bHU6IEFkcmlhbiBhbmQgSSBkZWFsIHdpdGggYW55IGlzc3VlcyBhbmQgY2hhcnRl cg0KICAgdXBkYXRlcyBiYXNlZCB1cG9uIGEgZmV3IG1vbnRocyBvZiBleHBlcmllbmNlLg0KDQpI ZXJlIGFyZSB0aGUgbW90aXZhdGlvbnMgdGhhdCBBZHJpYW4gYW5kIEkgd291bGQgbGlrZSB0byBi ZSBjb25zaWRlcmVkDQp3aGVuIGNvbWluZyB1cCB3aXRoIGlkZWFzIGZvciBob3cgdGhlIFdHcyBz aG91bGQgYmUgcmVvcmdhbml6ZWQuDQoNCiAgIDEpIE1vdmUgdG93YXJkcyBvcmdhbml6aW5nIHdv cmtpbmcgZ3JvdXBzIG9uIGZ1bmN0aW9uYWwNCiAgIHJlc3BvbnNpYmlsaXRpZXMgcmF0aGVyIHRo YW4gc2NvcGluZyB0aGVtIHRvIHNwZWNpZmljIHByb3RvY29scy4NCg0KICAgMikgU3BsaXQgZ2lh bnQgd29ya2luZyBncm91cHMgc28gcmVsZXZhbnQgd29yayBpcyBkb25lIGluIG9uZSBwbGFjZQ0K ICAgYW5kIHRoZXJlIGlzIGFuIGltcHJvdmVkIHNpZ25hbC10by1ub2lzZSByYXRpbyBmb3IgcGFy dGljaXBhbnRzIHdobw0KICAgYXJlIG9ubHkgaW50ZXJlc3RlZCBpbiBhIHNsaWNlIG9mIHRoZSBj dXJyZW50IHdvcmtpbmcgZ3JvdXAncyB3b3JrLg0KDQogICAzKSBDcmVhdGUgc3luZXJnaWVzIGZv ciBzY2F0dGVyZWQgZnVuY3Rpb25hbGl0eSAoZXhhbXBsZSBpZGVhczoNCiAgIE9BTSwgRlJSLCB0 cmFmZmljLWVuZ2luZWVyaW5nKQ0KDQogICA0KSBDcmVhdGUgYSBESVNQQVRDSCB3b3JraW5nIGdy b3VwIGZvciBjbGVhciBuZXcgaWRlYSBkaXNjdXNzaW9uOw0KICAgcnRnd2cgc2VydmVzIHNvbWUg b2YgdGhpcyBwdXJwb3NlIGJ1dCBkb2Vzbid0IGhhdmUgYSBjbGVhciBwcm9jZXNzDQogICBhbmQg aXNuJ3QgZHJhd2luZyBpbiB0aGUgbmV3IGlkZWFzLg0KDQogICA1KSBGb2N1cyBSb3V0aW5nIEFy ZWEgdGltZSBvbiBkZXNpZ24gY2VudGVycyByYXRoZXIgdGhhbiBvbiBmYXINCiAgIGNvcm5lciBj YXNlcy4NCg0KICAgNikgRWFjaCB3b3JraW5nIGdyb3VwIHNob3VsZCBoYXZlIGNsZWFyLCB3ZWxs IGRlZmluZWQsIGFuZCBhY2hpZXZhYmxlIGdvYWxzLg0KDQpOb3RpbmcgdGhhdCB0aGUgUm91dGlu ZyBBcmVhIGhhcyBpbmhlcml0ZWQgc29tZSBvZiBpdHMgV0cgc3RydWN0dXJlDQpmcm9tIHRoZSBz dWItSVAgYXJlYSwgaXQgaXMgbm90IGEgZ29hbCB0byBmb3JjZSBJUCByb3V0aW5nIGFuZCBNUExT DQpyb3V0aW5nIHRvIHJlbWFpbiBzZXBhcmF0ZWQuDQoNClRoZSBnb2FsIG9mIHRoaXMgcmVvcmdh bml6YXRpb24gaXMgbm90IGNsb3Npbmcgd29ya2luZyBncm91cHMuICBBZHJpYW4NCmFuZCBBbGlh IGFyZSBwZXJmZWN0bHkgY2FwYWJsZSBvZiBjbG9zaW5nIHdvcmtpbmcgZ3JvdXBzIHdpdGhvdXQg Z29pbmcNCnRocm91Z2ggcmVzdHJ1Y3R1cmluZy4NCg0KRm9yIHRob3NlIG9mIHlvdSB0aGF0IGhh dmUgcmVhZCB0aGlzIGZhciwgdGhhbmsgeW91LiAgR2V0dGluZyB0aGlzIDgwJQ0KcmlnaHQgaXMg Z29pbmcgdG8gdGFrZSBzb21lIHNlcmlvdXMgZGlzY3Vzc2lvbiBhbmQgdGhvdWdodC4gIFdlIGFs bA0Kd29yayBpbiB0aGUgUm91dGluZyBBcmVhIHRvZ2V0aGVyIHdpdGggZGlmZmVyZW50IHBlcnNw ZWN0aXZlcy4gIFBsZWFzZQ0KdGhpbmsgY2FyZWZ1bGx5IGFuZCBoZWxwIHVzIGhhdmUgYSBoaWdo bHkgZm9jdXNlZCBkaXNjdXNzaW9uLg0KDQpUaGFua3MsDQpBbGlhIGFuZCBBZHJpYW4NCg0K --_000_2b6a8f5df5e04cea989e163f05302c92CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUgaXNzdWUgdGhhdCBvY2N1cnMgdG8gbWUgaXMgdGhl IHNwbGl0IGJldHdlZW4gTDJWUE4gYW5kIEwzVlBOLiBQV0UzIHNlZW1zIHRvIGJlIGNsb3NlbHkg cmVsYXRlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSByZW1lbWJlciB3aGVuIFBQVlBOIHdhcyBzcGxpdCBpbnRv IEwyVlBOIGFuZCBMM1ZQTi4gQXQgdGhlIHRpbWUgdGhlcmUgd2FzIGEgcmF0aGVyIGFjdGl2ZSBk ZWJhdGUgZ29pbmcgb24gcmVnYXJkaW5nIEwyVlBOIHN0YW5kYXJkcyB0aGF0IHdhcyBjYXVzaW5n IHRoZSBMM1ZQTg0KIHdvcmsgdG8gYmUgc29ydCBvZiBsb3N0IGluIHRoZSBub2lzZS4gVGhpcyBw YXJ0aWN1bGFyIG1vdGl2YXRpb24gZm9yIHRoZSBzcGxpdCBlbmRlZCBsb25nIGFnby4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBkb27igJl0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiByZWdhcmRpbmcgd2hldGhlciBM MlZQTiwgTDNWUE4sIGFuZCBQV0UzIHNob3VsZCBzdGF5IHNlcGFyYXRlIG9yIHNob3VsZCBtZXJn ZSwgYnV0IEkgdGhpbmsgdGhhdCBpdCBpcyBhIHF1ZXN0aW9uIHdoaWNoIGlzIHdvcnRoDQogYXNr aW5nLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgUm9zczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcm91dGluZy1kaXNjdXNz aW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkFsaWEgQXRsYXM8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAx MCwgMjAxNCAzOjU4IFBNPGJyPg0KPGI+VG86PC9iPiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSW1wcm92aW5nIGFuZCBSZXN0cnVjdHVyaW5nIHRoZSBS b3V0aW5nIEFyZWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UbyBhbGwgcGFydGljaXBhbnRzIGluIHRoZSBSb3V0aW5nIEFyZWEsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkcmlhbiBhbmQg SSBhcmUgd29ya2luZyBvbiBpbXByb3ZpbmcgdGhlIHF1YWxpdHksIHNwZWVkLCBhbmQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4cGVyaWVuY2Ug b2YgZ2V0dGluZyB3b3JrIGRvbmUgaW4gdGhlIElFVEYgUm91dGluZyBBcmVhLiAmbmJzcDtUaGVy ZSBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRocmVlIGluaXRpYXRpdmVzIHRoYXQgd2UgYXJlIHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0 aW5nIEFyZWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnNwZWNpZmljIFdHIGNoYWlyIHRyYWluaW5nLCBhbmQgcmVvcmdhbml6aW5nIHRoZSB3b3Jr aW5nIGdyb3VwcyBpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmFyZWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZpcnN0LCB3ZSBpbnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVj dG9yYXRlIG1vcmUgcHJvYWN0aXZlbHkgYnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludHJvZHVjaW5nIGEgV29ya2luZyBHcm91cCBEcmFmdCBR dWFsaXR5IEFzc3VyYW5jZSAoV0cgRHJhZnQgUUEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wcm9jZXNzIHdoZXJlIHRoZSBzYW1lIHNlbGVjdGVk IHJvdXRpbmcgZGlyZWN0b3JhdGUgbWVtYmVyIHdpbGwgcmV2aWV3PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIGRyYWZ0IGR1cmluZyBXRyBkcmFm dCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3QgY2FsbC4gJm5ic3A7VGhlIHByb2Nlc3M8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpbGwgYmUg ZG9jdW1lbnRlZCBvbiB0aGUgUm91dGluZyBBcmVhIHdpa2k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPig8YSBocmVmPSJodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2FyZWEvcnRnL3RyYWMvd2lraTwvYT4pLiAmbmJzcDtUaGlzIHNob3VsZCBhbGxvdzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlyZWN0b3JhdGUg cmV2aWV3cyB0byByZXBvcnQgdGVjaG5pY2FsIGlzc3VlcyB0aGF0IGNhbiBhY3R1YWxseSBnZXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZpeGVk IGVhcmx5IGluIHRoZSBwcm9jZXNzIChlcXVpdmFsZW50IG9mIGJ1ZyByZXBvcnRzKSBhcyBvcHBv c2VkIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5qdXN0IG5vdGluZyB0aGUgY29uY2VybnMgaW4gdGhlIGRyYWZ0cyAoZXF1aXZhbGVudCBvZiBy ZWxlYXNlIG5vdGVzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2Vjb25kLCBhcyB3YXMgZGlzY3Vzc2VkIGR1cmluZyB0aGUgcmVjZW50IElF U0cgcmV0cmVhdCwgaW4gYWRkaXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnRvIHRoZSBJRVRGLXdpZGUgV0cgY2hhaXIgdHJhaW5pbmcsIHdl IGludGVuZCB0byBoYXZlIGEgc2VyaWVzIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50cmFpbmluZyBzZXNzaW9ucyBmb3IgV0cgQ2hhaXJzIGlu IHRoZSBSb3V0aW5nIEFyZWEgYWRkcmVzc2luZyB0b3BpY3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN1Y2ggYXMganVkZ2luZyBjb25zZW5zdXMs IHByb2plY3QgbWFuYWdlbWVudCwgbW90aXZhdGluZyB2b2x1bnRlZXJzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dXNpbmcgdGhlIGRhdGF0cmFj a2VyICh2aWEgYSBzYW5kYm94IHZlcnNpb24gdGhhdCBjYW4gYmUgcGxheWVkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aXRoIHNhZmVseSksIGFu ZCBzaGFyaW5nIGV4cGVyaWVuY2VzIGJldHdlZW4gV0cgY2hhaXJzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlyZCwgd2UgaW50ZW5kIHRv IHJlb3JnYW5pemUgdGhlIHdvcmtpbmcgZ3JvdXBzIGluIHRoZSBSb3V0aW5nIGFyZWEuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBmZWVsIHRo YXQgaXQgaXMgaW1wb3J0YW50IHRvIGZvY3VzIG9uIGFyZWFzIHdoZXJlIHRoZXJlIGlzIGFjdGl2 ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW50 ZXJlc3QgaW4gc3RhbmRhcmRpemF0aW9uIGFuZCB0byBiZSBvcGVuIGFuZCBhYmxlIHRvIGFjY2Vw dCBuZXcgd29yazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+aW50byB0aGUgYXJlYS4gJm5ic3A7QXMgeW91IGtub3csIHdlIGhhdmUgaGFkIHNldmVy YWwgbmV3IHdvcmtpbmcgZ3JvdXBzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4obnZvMywgaTJycywgc2ZjLCBzcHJpbmcpIGNyZWF0ZWQgaW4gdGhl IGxhc3QgZmV3IHllYXJzIGFuZCB3ZSBuZWVkIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iZSBvcGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3Jl IG5ldyB3b3JrIGFzIGl0IGNvbWVzIGluLiAmbmJzcDtXZSB3b3VsZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxzbyBsaWtlIHRvIGltcHJvdmUg dGhlIHNpZ25hbC10by1ub2lzZSByYXRpbyBleHBlcmllbmNlZCBieTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGFydGljaXBhbnRzIGluIHRoZSBk aWZmZXJlbnQgd29ya2luZyBncm91cHMgYW5kIGltcHJvdmUgdGhlIHF1YW50aXR5PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgcXVhbGl0eSBv ZiBkaXNjdXNzaW9uIGFuZCByZXZpZXdzLiAmbmJzcDtJdCBpcyBsaWtlbHkgdGhhdCBub3QgYWxs IFdHczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ aW4gdGhlIFJvdXRpbmcgQXJlYSB3aWxsIGJlIGRpcmVjdGx5IGFmZmVjdGVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIHRoZSB0 aW1lLWxpbmUgZm9yIHJlb3JnYW5pemluZyB0aGUgV0dzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Tk9XOiBwdWJsaWMg ZGlzY3Vzc2lvbiBvbiA8YSBocmVmPSJtYWlsdG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3Jn Ij4NCnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZzwvYT4gYWJvdXQgaG93IHRvPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 cmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMgdG8gYmVzdCBtZWV0IG91ciBtb3RpdmF0aW9u cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtBZGRpdGlvbmFsIGZvY3VzZWQgZGlzY3Vzc2lvbnMgYXJlIGV4cGVjdGVkIG9u IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpydGctY2hhaXJzQGlldGYub3JnIj5ydGctY2hh aXJzQGlldGYub3JnPC9hPiBhbmQNCjxhIGhyZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5y dGctZGlyQGlldGYub3JnPC9hPiBtYWlsaW5nIGxpc3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7SW4gVG9yb250bzog VGhlcmUgd2lsbCBiZSBtZWV0aW5ncyB3aXRoIHRoZSBXRyBjaGFpcnMgYW5kIHRoZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O1JvdXRpbmcgRGlyZWN0b3JhdGUgdG8gZ2V0IHRoZSBpZGVhcyBkZXNjcmliZWQgYW5kIGFncmVl ZCB1cG9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7QXQgdGhlIFJvdXRpbmcgQXJlYSBNZWV0aW5nIGluIFRvcm9udG86 IERpc2N1c3MgdGhlIHNldCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3Jlb3JnYW5pemVkIFdHcyBhbmQgZ2VuZXJhbCBj aGFydGVyIGNvbnRlbnQgaW4gdGhlIFJvdXRpbmcgQXJlYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO21lZXRpbmcuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtTZXB0ZW1iZXIgMjAxNDogQmFzZWQgdXBvbiB0aGUgZmVlZGJhY2ssIHN1Z2dlc3Rpb25z LCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDtkaXNjdXNzaW9uLCBBZHJpYW4gYW5kIEkgZmluYWxpemUgdGhlIHJlb3Jn YW5pemVkIFdHIGNoYXJ0ZXJzLiAmbmJzcDtXZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3N0YXJ0IHRoZSBpbnRlcm5hbCBJ RVNHIGRpc2N1c3Npb24gYW5kIHB1YmxpYyByZXZpZXdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7T2N0b2JlciAyMDE0 OiBGb3JtYWwgcmVjaGFydGVyaW5nIHByb2Nlc3MgY29tcGxldGVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7SW4gSG9u b2x1bHU6IFRoZSBuZXcgc2V0IG9mIFdHcyBtZWV0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7QWZ0ZXIgSG9ub2x1bHU6 IEFkcmlhbiBhbmQgSSBkZWFsIHdpdGggYW55IGlzc3VlcyBhbmQgY2hhcnRlcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3Vw ZGF0ZXMgYmFzZWQgdXBvbiBhIGZldyBtb250aHMgb2YgZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBhcmUgdGhlIG1v dGl2YXRpb25zIHRoYXQgQWRyaWFuIGFuZCBJIHdvdWxkIGxpa2UgdG8gYmUgY29uc2lkZXJlZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlbiBj b21pbmcgdXAgd2l0aCBpZGVhcyBmb3IgaG93IHRoZSBXR3Mgc2hvdWxkIGJlIHJlb3JnYW5pemVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7MSkgTW92ZSB0b3dhcmRzIG9yZ2FuaXppbmcgd29ya2luZyBncm91cHMgb24g ZnVuY3Rpb25hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO3Jlc3BvbnNpYmlsaXRpZXMgcmF0aGVyIHRoYW4gc2NvcGluZyB0 aGVtIHRvIHNwZWNpZmljIHByb3RvY29scy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzIpIFNwbGl0IGdpYW50IHdvcmtp bmcgZ3JvdXBzIHNvIHJlbGV2YW50IHdvcmsgaXMgZG9uZSBpbiBvbmUgcGxhY2U8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDth bmQgdGhlcmUgaXMgYW4gaW1wcm92ZWQgc2lnbmFsLXRvLW5vaXNlIHJhdGlvIGZvciBwYXJ0aWNp cGFudHMgd2hvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7YXJlIG9ubHkgaW50ZXJlc3RlZCBpbiBhIHNsaWNlIG9mIHRoZSBj dXJyZW50IHdvcmtpbmcgZ3JvdXAncyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7MykgQ3JlYXRlIHN5bmVyZ2ll cyBmb3Igc2NhdHRlcmVkIGZ1bmN0aW9uYWxpdHkgKGV4YW1wbGUgaWRlYXM6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7T0FN LCBGUlIsIHRyYWZmaWMtZW5naW5lZXJpbmcpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs0KSBDcmVhdGUgYSBESVNQQVRD SCB3b3JraW5nIGdyb3VwIGZvciBjbGVhciBuZXcgaWRlYSBkaXNjdXNzaW9uOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3J0 Z3dnIHNlcnZlcyBzb21lIG9mIHRoaXMgcHVycG9zZSBidXQgZG9lc24ndCBoYXZlIGEgY2xlYXIg cHJvY2VzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO2FuZCBpc24ndCBkcmF3aW5nIGluIHRoZSBuZXcgaWRlYXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDs1KSBGb2N1cyBSb3V0aW5nIEFyZWEgdGltZSBvbiBkZXNpZ24gY2VudGVycyByYXRoZXIg dGhhbiBvbiBmYXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtjb3JuZXIgY2FzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs2KSBFYWNoIHdvcmtp bmcgZ3JvdXAgc2hvdWxkIGhhdmUgY2xlYXIsIHdlbGwgZGVmaW5lZCwgYW5kIGFjaGlldmFibGUg Z29hbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk5vdGluZyB0aGF0IHRoZSBSb3V0aW5nIEFyZWEgaGFzIGluaGVyaXRlZCBzb21lIG9mIGl0 cyBXRyBzdHJ1Y3R1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmZyb20gdGhlIHN1Yi1JUCBhcmVhLCBpdCBpcyBub3QgYSBnb2FsIHRvIGZvcmNl IElQIHJvdXRpbmcgYW5kIE1QTFM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnJvdXRpbmcgdG8gcmVtYWluIHNlcGFyYXRlZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdvYWwgb2YgdGhp cyByZW9yZ2FuaXphdGlvbiBpcyBub3QgY2xvc2luZyB3b3JraW5nIGdyb3Vwcy4gJm5ic3A7QWRy aWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h bmQgQWxpYSBhcmUgcGVyZmVjdGx5IGNhcGFibGUgb2YgY2xvc2luZyB3b3JraW5nIGdyb3VwcyB3 aXRob3V0IGdvaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj50aHJvdWdoIHJlc3RydWN0dXJpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciB0aG9zZSBvZiB5b3UgdGhhdCBoYXZlIHJl YWQgdGhpcyBmYXIsIHRoYW5rIHlvdS4gJm5ic3A7R2V0dGluZyB0aGlzIDgwJTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmlnaHQgaXMgZ29pbmcg dG8gdGFrZSBzb21lIHNlcmlvdXMgZGlzY3Vzc2lvbiBhbmQgdGhvdWdodC4gJm5ic3A7V2UgYWxs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3Jr IGluIHRoZSBSb3V0aW5nIEFyZWEgdG9nZXRoZXIgd2l0aCBkaWZmZXJlbnQgcGVyc3BlY3RpdmVz LiAmbmJzcDtQbGVhc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnRoaW5rIGNhcmVmdWxseSBhbmQgaGVscCB1cyBoYXZlIGEgaGlnaGx5IGZvY3Vz ZWQgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWxpYSBhbmQgQWRyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2b6a8f5df5e04cea989e163f05302c92CO2PR05MB636namprd05pro_-- From nobody Thu Jun 26 09:32:32 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA061B2B02 for ; Thu, 26 Jun 2014 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dZ8qVOvajtb for ; Thu, 26 Jun 2014 09:32:26 -0700 (PDT) Received: from layerfree.net (heronab1.miniserver.com [77.73.2.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B052F1B2E8B for ; Thu, 26 Jun 2014 09:12:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=173.38.208.169; Received: from [10.61.162.218] (unverified [173.38.208.169]) by layerfree.net (SurgeMail 6.5a) with ESMTP (TLS) id 1070-1293857 for multiple; Thu, 26 Jun 2014 16:10:42 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: LxVPN, RE: Improving and Restructuring the Routing Area From: Giles Heron In-Reply-To: <2b6a8f5df5e04cea989e163f05302c92@CO2PR05MB636.namprd05.prod.outlook.com> Date: Thu, 26 Jun 2014 17:12:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56F918B1-D0CF-4298-A402-DB0C8BD0AE85@layerfree.net> References: <2b6a8f5df5e04cea989e163f05302c92@CO2PR05MB636.namprd05.prod.outlook.com> To: Ross Callon X-Mailer: Apple Mail (2.1878.2) X-Authenticated-User: giles@layerfree.net Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/B2t5CVmBuDQRXstS1VtbON0s01w Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:32:28 -0000 Yes, worth consideration for sure. The 3 groups are certainly a lot less active than they were once. And = while L2VPN is probably the most active, the majority of that activity = is around EVPN - which uses similar mechanisms to IPVPN/RFC4364. There = are also drafts which straddle the L2/L3 divide (e.g. for integrated L2 = and L3 forwarding in the data-center). And re PWE3 we're just adopting = a draft in L2VPN which was previously in PWE3 - so the boundary there = can be a bit blurry too. Though PWE's blurrier (if that's even a word) = boundary may be that with MPLS. I think there might also be value in doing VPN YANG models in one place = (if we agree that we need to do YANG models now as well as/instead of = MIBs) as we can ensure maximum commonality in the models that way. speaking only for myself, and not for my co-chair, of course. Giles On 26 Jun 2014, at 15:55, Ross Callon wrote: > One issue that occurs to me is the split between L2VPN and L3VPN. PWE3 = seems to be closely related. > =20 > I remember when PPVPN was split into L2VPN and L3VPN. At the time = there was a rather active debate going on regarding L2VPN standards that = was causing the L3VPN work to be sort of lost in the noise. This = particular motivation for the split ended long ago. > =20 > I don=92t have a strong opinion regarding whether L2VPN, L3VPN, and = PWE3 should stay separate or should merge, but I think that it is a = question which is worth asking. > =20 > Thanks, Ross > =20 > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] = On Behalf Of Alia Atlas > Sent: Tuesday, June 10, 2014 3:58 PM > To: routing-discussion@ietf.org > Subject: Improving and Restructuring the Routing Area > =20 > To all participants in the Routing Area, > =20 > Adrian and I are working on improving the quality, speed, and > experience of getting work done in the IETF Routing Area. There are > three initiatives that we are working: WG Draft QA, Routing Area > specific WG chair training, and reorganizing the working groups in the > area. > =20 > First, we intend to use our Routing Directorate more proactively by > introducing a Working Group Draft Quality Assurance (WG Draft QA) > process where the same selected routing directorate member will review > a draft during WG draft adoption and during WG last call. The process > will be documented on the Routing Area wiki > (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow > directorate reviews to report technical issues that can actually get > fixed early in the process (equivalent of bug reports) as opposed to > just noting the concerns in the drafts (equivalent of release notes). > =20 > Second, as was discussed during the recent IESG retreat, in addition > to the IETF-wide WG chair training, we intend to have a series of > training sessions for WG Chairs in the Routing Area addressing topics > such as judging consensus, project management, motivating volunteers, > using the datatracker (via a sandbox version that can be played > with safely), and sharing experiences between WG chairs. > =20 > Third, we intend to reorganize the working groups in the Routing area. > We feel that it is important to focus on areas where there is active > interest in standardization and to be open and able to accept new work > into the area. As you know, we have had several new working groups > (nvo3, i2rs, sfc, spring) created in the last few years and we need to > be open and able to handle more new work as it comes in. We would > also like to improve the signal-to-noise ratio experienced by > participants in the different working groups and improve the quantity > and quality of discussion and reviews. It is likely that not all WGs > in the Routing Area will be directly affected. > =20 > Here is the time-line for reorganizing the WGs. > =20 > NOW: public discussion on routing-discussion@ietf.org about how to > reorganize the working groups to best meet our motivations. > Additional focused discussions are expected on the > rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. > =20 > In Toronto: There will be meetings with the WG chairs and the > Routing Directorate to get the ideas described and agreed upon. > =20 > At the Routing Area Meeting in Toronto: Discuss the set of > reorganized WGs and general charter content in the Routing Area > meeting. > =20 > September 2014: Based upon the feedback, suggestions, and > discussion, Adrian and I finalize the reorganized WG charters. We > start the internal IESG discussion and public reviews. > =20 > October 2014: Formal rechartering process completes. > =20 > In Honolulu: The new set of WGs meet. > =20 > After Honolulu: Adrian and I deal with any issues and charter > updates based upon a few months of experience. > =20 > Here are the motivations that Adrian and I would like to be considered > when coming up with ideas for how the WGs should be reorganized. > =20 > 1) Move towards organizing working groups on functional > responsibilities rather than scoping them to specific protocols. > =20 > 2) Split giant working groups so relevant work is done in one place > and there is an improved signal-to-noise ratio for participants who > are only interested in a slice of the current working group's work. > =20 > 3) Create synergies for scattered functionality (example ideas: > OAM, FRR, traffic-engineering) > =20 > 4) Create a DISPATCH working group for clear new idea discussion; > rtgwg serves some of this purpose but doesn't have a clear process > and isn't drawing in the new ideas. > =20 > 5) Focus Routing Area time on design centers rather than on far > corner cases. > =20 > 6) Each working group should have clear, well defined, and = achievable goals. > =20 > Noting that the Routing Area has inherited some of its WG structure > from the sub-IP area, it is not a goal to force IP routing and MPLS > routing to remain separated. > =20 > The goal of this reorganization is not closing working groups. Adrian > and Alia are perfectly capable of closing working groups without going > through restructuring. > =20 > For those of you that have read this far, thank you. Getting this 80% > right is going to take some serious discussion and thought. We all > work in the Routing Area together with different perspectives. Please > think carefully and help us have a highly focused discussion. > =20 > Thanks, > Alia and Adrian > =20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From nobody Thu Jun 26 10:23:13 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BE01B2BAA for ; Thu, 26 Jun 2014 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TigyXNfnoK4s for ; Thu, 26 Jun 2014 10:23:06 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417AF1B2B8D for ; Thu, 26 Jun 2014 10:23:05 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id i50so3294921qgf.40 for ; Thu, 26 Jun 2014 10:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XB9S7w8paZaFL96PeU2kS56Vlz2FNJ0B+Zk8ifAD8ZM=; b=hz1DGuXodo6sjENpUs2OP+4s+M/17dFNp2Bxvm4WYlaeFgQZsOGaAMLBk4zHnFbV58 czA8I65h4AtgLeBuydpDx0j0o29auuK7o2DPrg0dhV0pOzIhFDGtO1p9jtxokqhDIG2k WxSLP5Hadm3IpLcVJ+Tn2RuQ+Cf5XyxD4uD6i08CyscSg4PL8hT+IxdSnCrjzvMFZfUr ynKMXgFLIcZBh1183v/A1JGcVcekTZj13NAap5C1j+aDLRUub5NNthAMEhkZfALJFt4j 2bUCsv9BkploQP72hy3m/nGmK/qgKpXCW4WDfPyS80F2YfAYnw7BoFzqCcL/qvubr+DI CekA== X-Received: by 10.140.98.35 with SMTP id n32mr23323245qge.111.1403803384228; Thu, 26 Jun 2014 10:23:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.28.2 with HTTP; Thu, 26 Jun 2014 10:22:44 -0700 (PDT) In-Reply-To: <56F918B1-D0CF-4298-A402-DB0C8BD0AE85@layerfree.net> References: <2b6a8f5df5e04cea989e163f05302c92@CO2PR05MB636.namprd05.prod.outlook.com> <56F918B1-D0CF-4298-A402-DB0C8BD0AE85@layerfree.net> From: "Andrew G. Malis" Date: Thu, 26 Jun 2014 13:22:44 -0400 Message-ID: Subject: Re: LxVPN, RE: Improving and Restructuring the Routing Area To: Giles Heron Content-Type: multipart/alternative; boundary=001a113aad840d327f04fcc072a9 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/LKSSkpTwiC4rKBmI8lgkckJeO6k Cc: Ross Callon , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:23:10 -0000 --001a113aad840d327f04fcc072a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also, speaking for myself (and not my PWE3 co-chair), I agree with Giles (and an earlier comment from Stewart) that the current work in PWE3 is closer to that in the MPLS WG than the L2VPN WG. For the most part, we're working on various extensions to LDP for PW setup and maintenance. That said, whether MPLS & PWE3 should be merged is dependent on other factors as well, such whether this would be putting too much into one WG (the "big" WG syndrome). Cheers, Andy On Thu, Jun 26, 2014 at 12:12 PM, Giles Heron wrote: > Yes, worth consideration for sure. > > The 3 groups are certainly a lot less active than they were once. And > while L2VPN is probably the most active, the majority of that activity is > around EVPN - which uses similar mechanisms to IPVPN/RFC4364. There are > also drafts which straddle the L2/L3 divide (e.g. for integrated L2 and L= 3 > forwarding in the data-center). And re PWE3 we're just adopting a draft = in > L2VPN which was previously in PWE3 - so the boundary there can be a bit > blurry too. Though PWE's blurrier (if that's even a word) boundary may b= e > that with MPLS. > > I think there might also be value in doing VPN YANG models in one place > (if we agree that we need to do YANG models now as well as/instead of MIB= s) > as we can ensure maximum commonality in the models that way. > > speaking only for myself, and not for my co-chair, of course. > > Giles > > On 26 Jun 2014, at 15:55, Ross Callon wrote: > > > One issue that occurs to me is the split between L2VPN and L3VPN. PWE3 > seems to be closely related. > > > > I remember when PPVPN was split into L2VPN and L3VPN. At the time there > was a rather active debate going on regarding L2VPN standards that was > causing the L3VPN work to be sort of lost in the noise. This particular > motivation for the split ended long ago. > > > > I don=E2=80=99t have a strong opinion regarding whether L2VPN, L3VPN, a= nd PWE3 > should stay separate or should merge, but I think that it is a question > which is worth asking. > > > > Thanks, Ross > > > > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] > On Behalf Of Alia Atlas > > Sent: Tuesday, June 10, 2014 3:58 PM > > To: routing-discussion@ietf.org > > Subject: Improving and Restructuring the Routing Area > > > > To all participants in the Routing Area, > > > > Adrian and I are working on improving the quality, speed, and > > experience of getting work done in the IETF Routing Area. There are > > three initiatives that we are working: WG Draft QA, Routing Area > > specific WG chair training, and reorganizing the working groups in the > > area. > > > > First, we intend to use our Routing Directorate more proactively by > > introducing a Working Group Draft Quality Assurance (WG Draft QA) > > process where the same selected routing directorate member will review > > a draft during WG draft adoption and during WG last call. The process > > will be documented on the Routing Area wiki > > (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow > > directorate reviews to report technical issues that can actually get > > fixed early in the process (equivalent of bug reports) as opposed to > > just noting the concerns in the drafts (equivalent of release notes). > > > > Second, as was discussed during the recent IESG retreat, in addition > > to the IETF-wide WG chair training, we intend to have a series of > > training sessions for WG Chairs in the Routing Area addressing topics > > such as judging consensus, project management, motivating volunteers, > > using the datatracker (via a sandbox version that can be played > > with safely), and sharing experiences between WG chairs. > > > > Third, we intend to reorganize the working groups in the Routing area. > > We feel that it is important to focus on areas where there is active > > interest in standardization and to be open and able to accept new work > > into the area. As you know, we have had several new working groups > > (nvo3, i2rs, sfc, spring) created in the last few years and we need to > > be open and able to handle more new work as it comes in. We would > > also like to improve the signal-to-noise ratio experienced by > > participants in the different working groups and improve the quantity > > and quality of discussion and reviews. It is likely that not all WGs > > in the Routing Area will be directly affected. > > > > Here is the time-line for reorganizing the WGs. > > > > NOW: public discussion on routing-discussion@ietf.org about how to > > reorganize the working groups to best meet our motivations. > > Additional focused discussions are expected on the > > rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. > > > > In Toronto: There will be meetings with the WG chairs and the > > Routing Directorate to get the ideas described and agreed upon. > > > > At the Routing Area Meeting in Toronto: Discuss the set of > > reorganized WGs and general charter content in the Routing Area > > meeting. > > > > September 2014: Based upon the feedback, suggestions, and > > discussion, Adrian and I finalize the reorganized WG charters. We > > start the internal IESG discussion and public reviews. > > > > October 2014: Formal rechartering process completes. > > > > In Honolulu: The new set of WGs meet. > > > > After Honolulu: Adrian and I deal with any issues and charter > > updates based upon a few months of experience. > > > > Here are the motivations that Adrian and I would like to be considered > > when coming up with ideas for how the WGs should be reorganized. > > > > 1) Move towards organizing working groups on functional > > responsibilities rather than scoping them to specific protocols. > > > > 2) Split giant working groups so relevant work is done in one place > > and there is an improved signal-to-noise ratio for participants who > > are only interested in a slice of the current working group's work. > > > > 3) Create synergies for scattered functionality (example ideas: > > OAM, FRR, traffic-engineering) > > > > 4) Create a DISPATCH working group for clear new idea discussion; > > rtgwg serves some of this purpose but doesn't have a clear process > > and isn't drawing in the new ideas. > > > > 5) Focus Routing Area time on design centers rather than on far > > corner cases. > > > > 6) Each working group should have clear, well defined, and achievabl= e > goals. > > > > Noting that the Routing Area has inherited some of its WG structure > > from the sub-IP area, it is not a goal to force IP routing and MPLS > > routing to remain separated. > > > > The goal of this reorganization is not closing working groups. Adrian > > and Alia are perfectly capable of closing working groups without going > > through restructuring. > > > > For those of you that have read this far, thank you. Getting this 80% > > right is going to take some serious discussion and thought. We all > > work in the Routing Area together with different perspectives. Please > > think carefully and help us have a highly focused discussion. > > > > Thanks, > > Alia and Adrian > > > > _______________________________________________ > > routing-discussion mailing list > > routing-discussion@ietf.org > > https://www.ietf.org/mailman/listinfo/routing-discussion > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > --001a113aad840d327f04fcc072a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Also, speaking for myself (and not my PWE3 co-chair), I ag= ree with Giles (and an earlier comment from Stewart) that the current work = in PWE3 is closer to that in the MPLS WG than the L2VPN WG. For the most pa= rt, we're working on various extensions to LDP for PW setup and mainten= ance. That said, whether MPLS & PWE3 should be merged is dependent on o= ther factors as well, such whether this would be putting too much into one = WG (the "big" WG syndrome).

Cheers,
Andy



On Thu, Jun 26, 2014 at= 12:12 PM, Giles Heron <giles@layerfree.net> wrote:
Yes, worth consideration for sure.

The 3 groups are certainly a lot less active than they were once. =C2=A0And= while L2VPN is probably the most active, the majority of that activity is = around EVPN - which uses similar mechanisms to IPVPN/RFC4364. =C2=A0There a= re also drafts which straddle the L2/L3 divide (e.g. for integrated L2 and = L3 forwarding in the data-center). =C2=A0And re PWE3 we're just adoptin= g a draft in L2VPN which was previously in PWE3 - so the boundary there can= be a bit blurry too. =C2=A0Though PWE's blurrier (if that's even a= word) boundary may be that with MPLS.

I think there might also be value in doing VPN YANG models in one place (if= we agree that we need to do YANG models now as well as/instead of MIBs) as= we can ensure maximum commonality in the models that way.

speaking only for myself, and not for my co-chair, of course.

Giles

On 26 Jun 2014, at 15:55, Ross Callon <rcallon@juniper.net> wrote:

> One issue that occurs to me is the split between L2VPN and L3VPN. PWE3= seems to be closely related.
>
> I remember when PPVPN was split into L2VPN and L3VPN. At the time ther= e was a rather active debate going on regarding L2VPN standards that was ca= using the L3VPN work to be sort of lost in the noise. This particular motiv= ation for the split ended long ago.
>
> I don=E2=80=99t have a strong opinion regarding whether L2VPN, L3VPN, = and PWE3 should stay separate or should merge, but I think that it is a que= stion which is worth asking.
>
> Thanks, Ross
>
> From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Ali= a Atlas
> Sent: Tuesday, June 10, 2014 3:58 PM
> To: routing-discussion@= ietf.org
> Subject: Improving and Restructuring the Routing Area
>
> To all participants in the Routing Area,
>
> Adrian and I are working on improving the quality, speed, and
> experience of getting work done in the IETF Routing Area. =C2=A0There = are
> three initiatives that we are working: WG Draft QA, Routing Area
> specific WG chair training, and reorganizing the working groups in the=
> area.
>
> First, we intend to use our Routing Directorate more proactively by > introducing a Working Group Draft Quality Assurance (WG Draft QA)
> process where the same selected routing directorate member will review=
> a draft during WG draft adoption and during WG last call. =C2=A0The pr= ocess
> will be documented on the Routing Area wiki
> (http://trac.tools.ietf.org/area/rtg/trac/wiki). =C2=A0This shoul= d allow
> directorate reviews to report technical issues that can actually get > fixed early in the process (equivalent of bug reports) as opposed to > just noting the concerns in the drafts (equivalent of release notes).<= br> >
> Second, as was discussed during the recent IESG retreat, in addition > to the IETF-wide WG chair training, we intend to have a series of
> training sessions for WG Chairs in the Routing Area addressing topics<= br> > such as judging consensus, project management, motivating volunteers,<= br> > using the datatracker (via a sandbox version that can be played
> with safely), and sharing experiences between WG chairs.
>
> Third, we intend to reorganize the working groups in the Routing area.=
> We feel that it is important to focus on areas where there is active > interest in standardization and to be open and able to accept new work=
> into the area. =C2=A0As you know, we have had several new working grou= ps
> (nvo3, i2rs, sfc, spring) created in the last few years and we need to=
> be open and able to handle more new work as it comes in. =C2=A0We woul= d
> also like to improve the signal-to-noise ratio experienced by
> participants in the different working groups and improve the quantity<= br> > and quality of discussion and reviews. =C2=A0It is likely that not all= WGs
> in the Routing Area will be directly affected.
>
> Here is the time-line for reorganizing the WGs.
>
> =C2=A0 =C2=A0NOW: public discussion on routing-discussion@ietf.org about how to
> =C2=A0 =C2=A0reorganize the working groups to best meet our motivation= s.
> =C2=A0 =C2=A0Additional focused discussions are expected on the
> =C2=A0 =C2=A0rtg-chairs@ietf.or= g and rtg-dir@ietf.org mailing = lists.
>
> =C2=A0 =C2=A0In Toronto: There will be meetings with the WG chairs and= the
> =C2=A0 =C2=A0Routing Directorate to get the ideas described and agreed= upon.
>
> =C2=A0 =C2=A0At the Routing Area Meeting in Toronto: Discuss the set o= f
> =C2=A0 =C2=A0reorganized WGs and general charter content in the Routin= g Area
> =C2=A0 =C2=A0meeting.
>
> =C2=A0 =C2=A0September 2014: Based upon the feedback, suggestions, and=
> =C2=A0 =C2=A0discussion, Adrian and I finalize the reorganized WG char= ters. =C2=A0We
> =C2=A0 =C2=A0start the internal IESG discussion and public reviews. >
> =C2=A0 =C2=A0October 2014: Formal rechartering process completes.
>
> =C2=A0 =C2=A0In Honolulu: The new set of WGs meet.
>
> =C2=A0 =C2=A0After Honolulu: Adrian and I deal with any issues and cha= rter
> =C2=A0 =C2=A0updates based upon a few months of experience.
>
> Here are the motivations that Adrian and I would like to be considered=
> when coming up with ideas for how the WGs should be reorganized.
>
> =C2=A0 =C2=A01) Move towards organizing working groups on functional > =C2=A0 =C2=A0responsibilities rather than scoping them to specific pro= tocols.
>
> =C2=A0 =C2=A02) Split giant working groups so relevant work is done in= one place
> =C2=A0 =C2=A0and there is an improved signal-to-noise ratio for partic= ipants who
> =C2=A0 =C2=A0are only interested in a slice of the current working gro= up's work.
>
> =C2=A0 =C2=A03) Create synergies for scattered functionality (example = ideas:
> =C2=A0 =C2=A0OAM, FRR, traffic-engineering)
>
> =C2=A0 =C2=A04) Create a DISPATCH working group for clear new idea dis= cussion;
> =C2=A0 =C2=A0rtgwg serves some of this purpose but doesn't have a = clear process
> =C2=A0 =C2=A0and isn't drawing in the new ideas.
>
> =C2=A0 =C2=A05) Focus Routing Area time on design centers rather than = on far
> =C2=A0 =C2=A0corner cases.
>
> =C2=A0 =C2=A06) Each working group should have clear, well defined, an= d achievable goals.
>
> Noting that the Routing Area has inherited some of its WG structure > from the sub-IP area, it is not a goal to force IP routing and MPLS > routing to remain separated.
>
> The goal of this reorganization is not closing working groups. =C2=A0A= drian
> and Alia are perfectly capable of closing working groups without going=
> through restructuring.
>
> For those of you that have read this far, thank you. =C2=A0Getting thi= s 80%
> right is going to take some serious discussion and thought. =C2=A0We a= ll
> work in the Routing Area together with different perspectives. =C2=A0P= lease
> think carefully and help us have a highly focused discussion.
>
> Thanks,
> Alia and Adrian
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf= .org
> https://www.ietf.org/mailman/listinfo/routing-discussion

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion

--001a113aad840d327f04fcc072a9-- From nobody Thu Jun 26 13:14:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887B51B2DCC for ; Thu, 26 Jun 2014 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLG4q_flrMPj for ; Thu, 26 Jun 2014 13:14:13 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD5F1B2DD6 for ; Thu, 26 Jun 2014 13:14:13 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s5QKA5WD015976; Thu, 26 Jun 2014 16:14:11 -0400 Received: from vawvcgsie2k1301.ciena.com (LIN1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 1mrp35s146-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 26 Jun 2014 16:14:10 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 26 Jun 2014 16:14:09 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 26 Jun 2014 16:14:09 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 26 Jun 2014 16:14:08 -0400 From: "Shah, Himanshu" To: "Andrew G. Malis" , Giles Heron Date: Thu, 26 Jun 2014 16:14:07 -0400 Subject: RE: LxVPN, RE: Improving and Restructuring the Routing Area Thread-Topic: LxVPN, RE: Improving and Restructuring the Routing Area Thread-Index: Ac+RY1XuxDI8iIMORrmigqFWbuoXQQAF08eA Message-ID: <40746B2300A8FC4AB04EE722A593182B74DA34DB@ONWVEXCHMB04.ciena.com> References: <2b6a8f5df5e04cea989e163f05302c92@CO2PR05MB636.namprd05.prod.outlook.com> <56F918B1-D0CF-4298-A402-DB0C8BD0AE85@layerfree.net> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-20782.002 x-tm-as-result: No--49.042300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182B74DA34DBONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-26_07:2014-06-26,2014-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406260214 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/F_NOMZNY0wyW00Oggb6imdxPzbI Cc: Ross Callon , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 20:14:17 -0000 --_000_40746B2300A8FC4AB04EE722A593182B74DA34DBONWVEXCHMB04cie_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1ITyDigJMgUFdFMyBpcyBtb3JlIHRpZ2h0bHkgY291cGxlZCB0byBMMlZQTiBhbmQgbWVyZ2Ug dGhlcmUgdGhhbiB0byBNUExTLg0KVGhpcyB3YXksIHdlIHdpbGwgYXZvaWQgQklHIHdnIHN5bmRy b21lLg0KDQpSZWdhcmRzLA0KaGltYW5zaHUNCg0KRnJvbTogcm91dGluZy1kaXNjdXNzaW9uIFtt YWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBB bmRyZXcgRy4gTWFsaXMNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI2LCAyMDE0IDE6MjMgUE0NClRv OiBHaWxlcyBIZXJvbg0KQ2M6IFJvc3MgQ2FsbG9uOyByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBMeFZQTiwgUkU6IEltcHJvdmluZyBhbmQgUmVzdHJ1Y3R1cmluZyB0 aGUgUm91dGluZyBBcmVhDQoNCkFsc28sIHNwZWFraW5nIGZvciBteXNlbGYgKGFuZCBub3QgbXkg UFdFMyBjby1jaGFpciksIEkgYWdyZWUgd2l0aCBHaWxlcyAoYW5kIGFuIGVhcmxpZXIgY29tbWVu dCBmcm9tIFN0ZXdhcnQpIHRoYXQgdGhlIGN1cnJlbnQgd29yayBpbiBQV0UzIGlzIGNsb3NlciB0 byB0aGF0IGluIHRoZSBNUExTIFdHIHRoYW4gdGhlIEwyVlBOIFdHLiBGb3IgdGhlIG1vc3QgcGFy dCwgd2UncmUgd29ya2luZyBvbiB2YXJpb3VzIGV4dGVuc2lvbnMgdG8gTERQIGZvciBQVyBzZXR1 cCBhbmQgbWFpbnRlbmFuY2UuIFRoYXQgc2FpZCwgd2hldGhlciBNUExTICYgUFdFMyBzaG91bGQg YmUgbWVyZ2VkIGlzIGRlcGVuZGVudCBvbiBvdGhlciBmYWN0b3JzIGFzIHdlbGwsIHN1Y2ggd2hl dGhlciB0aGlzIHdvdWxkIGJlIHB1dHRpbmcgdG9vIG11Y2ggaW50byBvbmUgV0cgKHRoZSAiYmln IiBXRyBzeW5kcm9tZSkuDQoNCkNoZWVycywNCkFuZHkNCg0KDQpPbiBUaHUsIEp1biAyNiwgMjAx NCBhdCAxMjoxMiBQTSwgR2lsZXMgSGVyb24gPGdpbGVzQGxheWVyZnJlZS5uZXQ8bWFpbHRvOmdp bGVzQGxheWVyZnJlZS5uZXQ+PiB3cm90ZToNClllcywgd29ydGggY29uc2lkZXJhdGlvbiBmb3Ig c3VyZS4NCg0KVGhlIDMgZ3JvdXBzIGFyZSBjZXJ0YWlubHkgYSBsb3QgbGVzcyBhY3RpdmUgdGhh biB0aGV5IHdlcmUgb25jZS4gIEFuZCB3aGlsZSBMMlZQTiBpcyBwcm9iYWJseSB0aGUgbW9zdCBh Y3RpdmUsIHRoZSBtYWpvcml0eSBvZiB0aGF0IGFjdGl2aXR5IGlzIGFyb3VuZCBFVlBOIC0gd2hp Y2ggdXNlcyBzaW1pbGFyIG1lY2hhbmlzbXMgdG8gSVBWUE4vUkZDNDM2NC4gIFRoZXJlIGFyZSBh bHNvIGRyYWZ0cyB3aGljaCBzdHJhZGRsZSB0aGUgTDIvTDMgZGl2aWRlIChlLmcuIGZvciBpbnRl Z3JhdGVkIEwyIGFuZCBMMyBmb3J3YXJkaW5nIGluIHRoZSBkYXRhLWNlbnRlcikuICBBbmQgcmUg UFdFMyB3ZSdyZSBqdXN0IGFkb3B0aW5nIGEgZHJhZnQgaW4gTDJWUE4gd2hpY2ggd2FzIHByZXZp b3VzbHkgaW4gUFdFMyAtIHNvIHRoZSBib3VuZGFyeSB0aGVyZSBjYW4gYmUgYSBiaXQgYmx1cnJ5 IHRvby4gIFRob3VnaCBQV0UncyBibHVycmllciAoaWYgdGhhdCdzIGV2ZW4gYSB3b3JkKSBib3Vu ZGFyeSBtYXkgYmUgdGhhdCB3aXRoIE1QTFMuDQoNCkkgdGhpbmsgdGhlcmUgbWlnaHQgYWxzbyBi ZSB2YWx1ZSBpbiBkb2luZyBWUE4gWUFORyBtb2RlbHMgaW4gb25lIHBsYWNlIChpZiB3ZSBhZ3Jl ZSB0aGF0IHdlIG5lZWQgdG8gZG8gWUFORyBtb2RlbHMgbm93IGFzIHdlbGwgYXMvaW5zdGVhZCBv ZiBNSUJzKSBhcyB3ZSBjYW4gZW5zdXJlIG1heGltdW0gY29tbW9uYWxpdHkgaW4gdGhlIG1vZGVs cyB0aGF0IHdheS4NCg0Kc3BlYWtpbmcgb25seSBmb3IgbXlzZWxmLCBhbmQgbm90IGZvciBteSBj by1jaGFpciwgb2YgY291cnNlLg0KDQpHaWxlcw0KDQpPbiAyNiBKdW4gMjAxNCwgYXQgMTU6NTUs IFJvc3MgQ2FsbG9uIDxyY2FsbG9uQGp1bmlwZXIubmV0PG1haWx0bzpyY2FsbG9uQGp1bmlwZXIu bmV0Pj4gd3JvdGU6DQoNCj4gT25lIGlzc3VlIHRoYXQgb2NjdXJzIHRvIG1lIGlzIHRoZSBzcGxp dCBiZXR3ZWVuIEwyVlBOIGFuZCBMM1ZQTi4gUFdFMyBzZWVtcyB0byBiZSBjbG9zZWx5IHJlbGF0 ZWQuDQo+DQo+IEkgcmVtZW1iZXIgd2hlbiBQUFZQTiB3YXMgc3BsaXQgaW50byBMMlZQTiBhbmQg TDNWUE4uIEF0IHRoZSB0aW1lIHRoZXJlIHdhcyBhIHJhdGhlciBhY3RpdmUgZGViYXRlIGdvaW5n IG9uIHJlZ2FyZGluZyBMMlZQTiBzdGFuZGFyZHMgdGhhdCB3YXMgY2F1c2luZyB0aGUgTDNWUE4g d29yayB0byBiZSBzb3J0IG9mIGxvc3QgaW4gdGhlIG5vaXNlLiBUaGlzIHBhcnRpY3VsYXIgbW90 aXZhdGlvbiBmb3IgdGhlIHNwbGl0IGVuZGVkIGxvbmcgYWdvLg0KPg0KPiBJIGRvbuKAmXQgaGF2 ZSBhIHN0cm9uZyBvcGluaW9uIHJlZ2FyZGluZyB3aGV0aGVyIEwyVlBOLCBMM1ZQTiwgYW5kIFBX RTMgc2hvdWxkIHN0YXkgc2VwYXJhdGUgb3Igc2hvdWxkIG1lcmdlLCBidXQgSSB0aGluayB0aGF0 IGl0IGlzIGEgcXVlc3Rpb24gd2hpY2ggaXMgd29ydGggYXNraW5nLg0KPg0KPiBUaGFua3MsIFJv c3MNCj4NCj4gRnJvbTogcm91dGluZy1kaXNjdXNzaW9uIFttYWlsdG86cm91dGluZy1kaXNjdXNz aW9uLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbi1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIEFsaWEgQXRsYXMNCj4gU2VudDogVHVlc2RheSwgSnVuZSAx MCwgMjAxNCAzOjU4IFBNDQo+IFRvOiByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8bWFpbHRv OnJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZz4NCj4gU3ViamVjdDogSW1wcm92aW5nIGFuZCBS ZXN0cnVjdHVyaW5nIHRoZSBSb3V0aW5nIEFyZWENCj4NCj4gVG8gYWxsIHBhcnRpY2lwYW50cyBp biB0aGUgUm91dGluZyBBcmVhLA0KPg0KPiBBZHJpYW4gYW5kIEkgYXJlIHdvcmtpbmcgb24gaW1w cm92aW5nIHRoZSBxdWFsaXR5LCBzcGVlZCwgYW5kDQo+IGV4cGVyaWVuY2Ugb2YgZ2V0dGluZyB3 b3JrIGRvbmUgaW4gdGhlIElFVEYgUm91dGluZyBBcmVhLiAgVGhlcmUgYXJlDQo+IHRocmVlIGlu aXRpYXRpdmVzIHRoYXQgd2UgYXJlIHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWEN Cj4gc3BlY2lmaWMgV0cgY2hhaXIgdHJhaW5pbmcsIGFuZCByZW9yZ2FuaXppbmcgdGhlIHdvcmtp bmcgZ3JvdXBzIGluIHRoZQ0KPiBhcmVhLg0KPg0KPiBGaXJzdCwgd2UgaW50ZW5kIHRvIHVzZSBv dXIgUm91dGluZyBEaXJlY3RvcmF0ZSBtb3JlIHByb2FjdGl2ZWx5IGJ5DQo+IGludHJvZHVjaW5n IGEgV29ya2luZyBHcm91cCBEcmFmdCBRdWFsaXR5IEFzc3VyYW5jZSAoV0cgRHJhZnQgUUEpDQo+ IHByb2Nlc3Mgd2hlcmUgdGhlIHNhbWUgc2VsZWN0ZWQgcm91dGluZyBkaXJlY3RvcmF0ZSBtZW1i ZXIgd2lsbCByZXZpZXcNCj4gYSBkcmFmdCBkdXJpbmcgV0cgZHJhZnQgYWRvcHRpb24gYW5kIGR1 cmluZyBXRyBsYXN0IGNhbGwuICBUaGUgcHJvY2Vzcw0KPiB3aWxsIGJlIGRvY3VtZW50ZWQgb24g dGhlIFJvdXRpbmcgQXJlYSB3aWtpDQo+IChodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVh L3J0Zy90cmFjL3dpa2kpLiAgVGhpcyBzaG91bGQgYWxsb3cNCj4gZGlyZWN0b3JhdGUgcmV2aWV3 cyB0byByZXBvcnQgdGVjaG5pY2FsIGlzc3VlcyB0aGF0IGNhbiBhY3R1YWxseSBnZXQNCj4gZml4 ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxlbnQgb2YgYnVnIHJlcG9ydHMpIGFzIG9w cG9zZWQgdG8NCj4ganVzdCBub3RpbmcgdGhlIGNvbmNlcm5zIGluIHRoZSBkcmFmdHMgKGVxdWl2 YWxlbnQgb2YgcmVsZWFzZSBub3RlcykuDQo+DQo+IFNlY29uZCwgYXMgd2FzIGRpc2N1c3NlZCBk dXJpbmcgdGhlIHJlY2VudCBJRVNHIHJldHJlYXQsIGluIGFkZGl0aW9uDQo+IHRvIHRoZSBJRVRG LXdpZGUgV0cgY2hhaXIgdHJhaW5pbmcsIHdlIGludGVuZCB0byBoYXZlIGEgc2VyaWVzIG9mDQo+ IHRyYWluaW5nIHNlc3Npb25zIGZvciBXRyBDaGFpcnMgaW4gdGhlIFJvdXRpbmcgQXJlYSBhZGRy ZXNzaW5nIHRvcGljcw0KPiBzdWNoIGFzIGp1ZGdpbmcgY29uc2Vuc3VzLCBwcm9qZWN0IG1hbmFn ZW1lbnQsIG1vdGl2YXRpbmcgdm9sdW50ZWVycywNCj4gdXNpbmcgdGhlIGRhdGF0cmFja2VyICh2 aWEgYSBzYW5kYm94IHZlcnNpb24gdGhhdCBjYW4gYmUgcGxheWVkDQo+IHdpdGggc2FmZWx5KSwg YW5kIHNoYXJpbmcgZXhwZXJpZW5jZXMgYmV0d2VlbiBXRyBjaGFpcnMuDQo+DQo+IFRoaXJkLCB3 ZSBpbnRlbmQgdG8gcmVvcmdhbml6ZSB0aGUgd29ya2luZyBncm91cHMgaW4gdGhlIFJvdXRpbmcg YXJlYS4NCj4gV2UgZmVlbCB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBmb2N1cyBvbiBhcmVhcyB3 aGVyZSB0aGVyZSBpcyBhY3RpdmUNCj4gaW50ZXJlc3QgaW4gc3RhbmRhcmRpemF0aW9uIGFuZCB0 byBiZSBvcGVuIGFuZCBhYmxlIHRvIGFjY2VwdCBuZXcgd29yaw0KPiBpbnRvIHRoZSBhcmVhLiAg QXMgeW91IGtub3csIHdlIGhhdmUgaGFkIHNldmVyYWwgbmV3IHdvcmtpbmcgZ3JvdXBzDQo+IChu dm8zLCBpMnJzLCBzZmMsIHNwcmluZykgY3JlYXRlZCBpbiB0aGUgbGFzdCBmZXcgeWVhcnMgYW5k IHdlIG5lZWQgdG8NCj4gYmUgb3BlbiBhbmQgYWJsZSB0byBoYW5kbGUgbW9yZSBuZXcgd29yayBh cyBpdCBjb21lcyBpbi4gIFdlIHdvdWxkDQo+IGFsc28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWdu YWwtdG8tbm9pc2UgcmF0aW8gZXhwZXJpZW5jZWQgYnkNCj4gcGFydGljaXBhbnRzIGluIHRoZSBk aWZmZXJlbnQgd29ya2luZyBncm91cHMgYW5kIGltcHJvdmUgdGhlIHF1YW50aXR5DQo+IGFuZCBx dWFsaXR5IG9mIGRpc2N1c3Npb24gYW5kIHJldmlld3MuICBJdCBpcyBsaWtlbHkgdGhhdCBub3Qg YWxsIFdHcw0KPiBpbiB0aGUgUm91dGluZyBBcmVhIHdpbGwgYmUgZGlyZWN0bHkgYWZmZWN0ZWQu DQo+DQo+IEhlcmUgaXMgdGhlIHRpbWUtbGluZSBmb3IgcmVvcmdhbml6aW5nIHRoZSBXR3MuDQo+ DQo+ICAgIE5PVzogcHVibGljIGRpc2N1c3Npb24gb24gcm91dGluZy1kaXNjdXNzaW9uQGlldGYu b3JnPG1haWx0bzpyb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc+IGFib3V0IGhvdyB0bw0KPiAg ICByZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdyb3VwcyB0byBiZXN0IG1lZXQgb3VyIG1vdGl2YXRp b25zLg0KPiAgICBBZGRpdGlvbmFsIGZvY3VzZWQgZGlzY3Vzc2lvbnMgYXJlIGV4cGVjdGVkIG9u IHRoZQ0KPiAgICBydGctY2hhaXJzQGlldGYub3JnPG1haWx0bzpydGctY2hhaXJzQGlldGYub3Jn PiBhbmQgcnRnLWRpckBpZXRmLm9yZzxtYWlsdG86cnRnLWRpckBpZXRmLm9yZz4gbWFpbGluZyBs aXN0cy4NCj4NCj4gICAgSW4gVG9yb250bzogVGhlcmUgd2lsbCBiZSBtZWV0aW5ncyB3aXRoIHRo ZSBXRyBjaGFpcnMgYW5kIHRoZQ0KPiAgICBSb3V0aW5nIERpcmVjdG9yYXRlIHRvIGdldCB0aGUg aWRlYXMgZGVzY3JpYmVkIGFuZCBhZ3JlZWQgdXBvbi4NCj4NCj4gICAgQXQgdGhlIFJvdXRpbmcg QXJlYSBNZWV0aW5nIGluIFRvcm9udG86IERpc2N1c3MgdGhlIHNldCBvZg0KPiAgICByZW9yZ2Fu aXplZCBXR3MgYW5kIGdlbmVyYWwgY2hhcnRlciBjb250ZW50IGluIHRoZSBSb3V0aW5nIEFyZWEN Cj4gICAgbWVldGluZy4NCj4NCj4gICAgU2VwdGVtYmVyIDIwMTQ6IEJhc2VkIHVwb24gdGhlIGZl ZWRiYWNrLCBzdWdnZXN0aW9ucywgYW5kDQo+ICAgIGRpc2N1c3Npb24sIEFkcmlhbiBhbmQgSSBm aW5hbGl6ZSB0aGUgcmVvcmdhbml6ZWQgV0cgY2hhcnRlcnMuICBXZQ0KPiAgICBzdGFydCB0aGUg aW50ZXJuYWwgSUVTRyBkaXNjdXNzaW9uIGFuZCBwdWJsaWMgcmV2aWV3cy4NCj4NCj4gICAgT2N0 b2JlciAyMDE0OiBGb3JtYWwgcmVjaGFydGVyaW5nIHByb2Nlc3MgY29tcGxldGVzLg0KPg0KPiAg ICBJbiBIb25vbHVsdTogVGhlIG5ldyBzZXQgb2YgV0dzIG1lZXQuDQo+DQo+ICAgIEFmdGVyIEhv bm9sdWx1OiBBZHJpYW4gYW5kIEkgZGVhbCB3aXRoIGFueSBpc3N1ZXMgYW5kIGNoYXJ0ZXINCj4g ICAgdXBkYXRlcyBiYXNlZCB1cG9uIGEgZmV3IG1vbnRocyBvZiBleHBlcmllbmNlLg0KPg0KPiBI ZXJlIGFyZSB0aGUgbW90aXZhdGlvbnMgdGhhdCBBZHJpYW4gYW5kIEkgd291bGQgbGlrZSB0byBi ZSBjb25zaWRlcmVkDQo+IHdoZW4gY29taW5nIHVwIHdpdGggaWRlYXMgZm9yIGhvdyB0aGUgV0dz IHNob3VsZCBiZSByZW9yZ2FuaXplZC4NCj4NCj4gICAgMSkgTW92ZSB0b3dhcmRzIG9yZ2FuaXpp bmcgd29ya2luZyBncm91cHMgb24gZnVuY3Rpb25hbA0KPiAgICByZXNwb25zaWJpbGl0aWVzIHJh dGhlciB0aGFuIHNjb3BpbmcgdGhlbSB0byBzcGVjaWZpYyBwcm90b2NvbHMuDQo+DQo+ICAgIDIp IFNwbGl0IGdpYW50IHdvcmtpbmcgZ3JvdXBzIHNvIHJlbGV2YW50IHdvcmsgaXMgZG9uZSBpbiBv bmUgcGxhY2UNCj4gICAgYW5kIHRoZXJlIGlzIGFuIGltcHJvdmVkIHNpZ25hbC10by1ub2lzZSBy YXRpbyBmb3IgcGFydGljaXBhbnRzIHdobw0KPiAgICBhcmUgb25seSBpbnRlcmVzdGVkIGluIGEg c2xpY2Ugb2YgdGhlIGN1cnJlbnQgd29ya2luZyBncm91cCdzIHdvcmsuDQo+DQo+ICAgIDMpIENy ZWF0ZSBzeW5lcmdpZXMgZm9yIHNjYXR0ZXJlZCBmdW5jdGlvbmFsaXR5IChleGFtcGxlIGlkZWFz Og0KPiAgICBPQU0sIEZSUiwgdHJhZmZpYy1lbmdpbmVlcmluZykNCj4NCj4gICAgNCkgQ3JlYXRl IGEgRElTUEFUQ0ggd29ya2luZyBncm91cCBmb3IgY2xlYXIgbmV3IGlkZWEgZGlzY3Vzc2lvbjsN Cj4gICAgcnRnd2cgc2VydmVzIHNvbWUgb2YgdGhpcyBwdXJwb3NlIGJ1dCBkb2Vzbid0IGhhdmUg YSBjbGVhciBwcm9jZXNzDQo+ICAgIGFuZCBpc24ndCBkcmF3aW5nIGluIHRoZSBuZXcgaWRlYXMu DQo+DQo+ICAgIDUpIEZvY3VzIFJvdXRpbmcgQXJlYSB0aW1lIG9uIGRlc2lnbiBjZW50ZXJzIHJh dGhlciB0aGFuIG9uIGZhcg0KPiAgICBjb3JuZXIgY2FzZXMuDQo+DQo+ICAgIDYpIEVhY2ggd29y a2luZyBncm91cCBzaG91bGQgaGF2ZSBjbGVhciwgd2VsbCBkZWZpbmVkLCBhbmQgYWNoaWV2YWJs ZSBnb2Fscy4NCj4NCj4gTm90aW5nIHRoYXQgdGhlIFJvdXRpbmcgQXJlYSBoYXMgaW5oZXJpdGVk IHNvbWUgb2YgaXRzIFdHIHN0cnVjdHVyZQ0KPiBmcm9tIHRoZSBzdWItSVAgYXJlYSwgaXQgaXMg bm90IGEgZ29hbCB0byBmb3JjZSBJUCByb3V0aW5nIGFuZCBNUExTDQo+IHJvdXRpbmcgdG8gcmVt YWluIHNlcGFyYXRlZC4NCj4NCj4gVGhlIGdvYWwgb2YgdGhpcyByZW9yZ2FuaXphdGlvbiBpcyBu b3QgY2xvc2luZyB3b3JraW5nIGdyb3Vwcy4gIEFkcmlhbg0KPiBhbmQgQWxpYSBhcmUgcGVyZmVj dGx5IGNhcGFibGUgb2YgY2xvc2luZyB3b3JraW5nIGdyb3VwcyB3aXRob3V0IGdvaW5nDQo+IHRo cm91Z2ggcmVzdHJ1Y3R1cmluZy4NCj4NCj4gRm9yIHRob3NlIG9mIHlvdSB0aGF0IGhhdmUgcmVh ZCB0aGlzIGZhciwgdGhhbmsgeW91LiAgR2V0dGluZyB0aGlzIDgwJQ0KPiByaWdodCBpcyBnb2lu ZyB0byB0YWtlIHNvbWUgc2VyaW91cyBkaXNjdXNzaW9uIGFuZCB0aG91Z2h0LiAgV2UgYWxsDQo+ IHdvcmsgaW4gdGhlIFJvdXRpbmcgQXJlYSB0b2dldGhlciB3aXRoIGRpZmZlcmVudCBwZXJzcGVj dGl2ZXMuICBQbGVhc2UNCj4gdGhpbmsgY2FyZWZ1bGx5IGFuZCBoZWxwIHVzIGhhdmUgYSBoaWdo bHkgZm9jdXNlZCBkaXNjdXNzaW9uLg0KPg0KPiBUaGFua3MsDQo+IEFsaWEgYW5kIEFkcmlhbg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBy b3V0aW5nLWRpc2N1c3Npb24gbWFpbGluZyBsaXN0DQo+IHJvdXRpbmctZGlzY3Vzc2lvbkBpZXRm Lm9yZzxtYWlsdG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvdXRpbmctZGlzY3Vzc2lvbg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kcm91dGluZy1kaXNjdXNzaW9u IG1haWxpbmcgbGlzdA0Kcm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPG1haWx0bzpyb3V0aW5n LWRpc2N1c3Npb25AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3JvdXRpbmctZGlzY3Vzc2lvbg0KDQo= --_000_40746B2300A8FC4AB04EE722A593182B74DA34DBONWVEXCHMB04cie_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbWJyaWE7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiMwMDQwQzA7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6aXRhbGljO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYg Y2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtjb2xvcjojMDA0MEMw Jz5JTUhPIOKAkyBQV0UzIGlzIG1vcmUgdGlnaHRseSBjb3VwbGVkIHRvIEwyVlBOIGFuZCBtZXJn ZSB0aGVyZSB0aGFuIHRvIE1QTFMuPG86cD48L286cD48L3NwYW4+PC9pPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bWJyaWEiLCJzZXJpZiI7Y29sb3I6IzAwNDBDMCc+VGhpcyB3YXksIHdlIHdpbGwgYXZvaWQgQklH IHdnIHN5bmRyb21lLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYW1icmlhIiwi c2VyaWYiO2NvbG9yOiMwMDQwQzAnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxpPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYW1icmlhIiwic2VyaWYiO2NvbG9yOiMwMDQwQzAnPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9pPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7Y29sb3I6IzAwNDBDMCc+aGlt YW5zaHU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48aT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FtYnJpYSIsInNlcmlmIjtj b2xvcjojMDA0MEMwJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiByb3V0aW5nLWRpc2N1 c3Npb24gW21haWx0bzpyb3V0aW5nLWRpc2N1c3Npb24tYm91bmNlc0BpZXRmLm9yZ10gPGI+T24g QmVoYWxmIE9mIDwvYj5BbmRyZXcgRy4gTWFsaXM8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBK dW5lIDI2LCAyMDE0IDE6MjMgUE08YnI+PGI+VG86PC9iPiBHaWxlcyBIZXJvbjxicj48Yj5DYzo8 L2I+IFJvc3MgQ2FsbG9uOyByb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8YnI+PGI+U3ViamVj dDo8L2I+IFJlOiBMeFZQTiwgUkU6IEltcHJvdmluZyBhbmQgUmVzdHJ1Y3R1cmluZyB0aGUgUm91 dGluZyBBcmVhPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5BbHNvLCBzcGVha2luZyBmb3Ig bXlzZWxmIChhbmQgbm90IG15IFBXRTMgY28tY2hhaXIpLCBJIGFncmVlIHdpdGggR2lsZXMgKGFu ZCBhbiBlYXJsaWVyIGNvbW1lbnQgZnJvbSBTdGV3YXJ0KSB0aGF0IHRoZSBjdXJyZW50IHdvcmsg aW4gUFdFMyBpcyBjbG9zZXIgdG8gdGhhdCBpbiB0aGUgTVBMUyBXRyB0aGFuIHRoZSBMMlZQTiBX Ry4gRm9yIHRoZSBtb3N0IHBhcnQsIHdlJ3JlIHdvcmtpbmcgb24gdmFyaW91cyBleHRlbnNpb25z IHRvIExEUCBmb3IgUFcgc2V0dXAgYW5kIG1haW50ZW5hbmNlLiBUaGF0IHNhaWQsIHdoZXRoZXIg TVBMUyAmYW1wOyBQV0UzIHNob3VsZCBiZSBtZXJnZWQgaXMgZGVwZW5kZW50IG9uIG90aGVyIGZh Y3RvcnMgYXMgd2VsbCwgc3VjaCB3aGV0aGVyIHRoaXMgd291bGQgYmUgcHV0dGluZyB0b28gbXVj aCBpbnRvIG9uZSBXRyAodGhlICZxdW90O2JpZyZxdW90OyBXRyBzeW5kcm9tZSkuPG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPkFuZHk8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFRodSwgSnVuIDI2LCAyMDE0IGF0IDEyOjEy IFBNLCBHaWxlcyBIZXJvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpbGVzQGxheWVyZnJlZS5uZXQi IHRhcmdldD0iX2JsYW5rIj5naWxlc0BsYXllcmZyZWUubmV0PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPlllcywgd29ydGggY29uc2lkZXJhdGlvbiBmb3Ig c3VyZS48YnI+PGJyPlRoZSAzIGdyb3VwcyBhcmUgY2VydGFpbmx5IGEgbG90IGxlc3MgYWN0aXZl IHRoYW4gdGhleSB3ZXJlIG9uY2UuICZuYnNwO0FuZCB3aGlsZSBMMlZQTiBpcyBwcm9iYWJseSB0 aGUgbW9zdCBhY3RpdmUsIHRoZSBtYWpvcml0eSBvZiB0aGF0IGFjdGl2aXR5IGlzIGFyb3VuZCBF VlBOIC0gd2hpY2ggdXNlcyBzaW1pbGFyIG1lY2hhbmlzbXMgdG8gSVBWUE4vUkZDNDM2NC4gJm5i c3A7VGhlcmUgYXJlIGFsc28gZHJhZnRzIHdoaWNoIHN0cmFkZGxlIHRoZSBMMi9MMyBkaXZpZGUg KGUuZy4gZm9yIGludGVncmF0ZWQgTDIgYW5kIEwzIGZvcndhcmRpbmcgaW4gdGhlIGRhdGEtY2Vu dGVyKS4gJm5ic3A7QW5kIHJlIFBXRTMgd2UncmUganVzdCBhZG9wdGluZyBhIGRyYWZ0IGluIEwy VlBOIHdoaWNoIHdhcyBwcmV2aW91c2x5IGluIFBXRTMgLSBzbyB0aGUgYm91bmRhcnkgdGhlcmUg Y2FuIGJlIGEgYml0IGJsdXJyeSB0b28uICZuYnNwO1Rob3VnaCBQV0UncyBibHVycmllciAoaWYg dGhhdCdzIGV2ZW4gYSB3b3JkKSBib3VuZGFyeSBtYXkgYmUgdGhhdCB3aXRoIE1QTFMuPGJyPjxi cj5JIHRoaW5rIHRoZXJlIG1pZ2h0IGFsc28gYmUgdmFsdWUgaW4gZG9pbmcgVlBOIFlBTkcgbW9k ZWxzIGluIG9uZSBwbGFjZSAoaWYgd2UgYWdyZWUgdGhhdCB3ZSBuZWVkIHRvIGRvIFlBTkcgbW9k ZWxzIG5vdyBhcyB3ZWxsIGFzL2luc3RlYWQgb2YgTUlCcykgYXMgd2UgY2FuIGVuc3VyZSBtYXhp bXVtIGNvbW1vbmFsaXR5IGluIHRoZSBtb2RlbHMgdGhhdCB3YXkuPGJyPjxicj5zcGVha2luZyBv bmx5IGZvciBteXNlbGYsIGFuZCBub3QgZm9yIG15IGNvLWNoYWlyLCBvZiBjb3Vyc2UuPGJyPjxi cj5HaWxlczxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPk9u IDI2IEp1biAyMDE0LCBhdCAxNTo1NSwgUm9zcyBDYWxsb24gJmx0OzxhIGhyZWY9Im1haWx0bzpy Y2FsbG9uQGp1bmlwZXIubmV0Ij5yY2FsbG9uQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PGJy Pjxicj4mZ3Q7IE9uZSBpc3N1ZSB0aGF0IG9jY3VycyB0byBtZSBpcyB0aGUgc3BsaXQgYmV0d2Vl biBMMlZQTiBhbmQgTDNWUE4uIFBXRTMgc2VlbXMgdG8gYmUgY2xvc2VseSByZWxhdGVkLjxicj4m Z3Q7PGJyPiZndDsgSSByZW1lbWJlciB3aGVuIFBQVlBOIHdhcyBzcGxpdCBpbnRvIEwyVlBOIGFu ZCBMM1ZQTi4gQXQgdGhlIHRpbWUgdGhlcmUgd2FzIGEgcmF0aGVyIGFjdGl2ZSBkZWJhdGUgZ29p bmcgb24gcmVnYXJkaW5nIEwyVlBOIHN0YW5kYXJkcyB0aGF0IHdhcyBjYXVzaW5nIHRoZSBMM1ZQ TiB3b3JrIHRvIGJlIHNvcnQgb2YgbG9zdCBpbiB0aGUgbm9pc2UuIFRoaXMgcGFydGljdWxhciBt b3RpdmF0aW9uIGZvciB0aGUgc3BsaXQgZW5kZWQgbG9uZyBhZ28uPGJyPiZndDs8YnI+Jmd0OyBJ IGRvbuKAmXQgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIHJlZ2FyZGluZyB3aGV0aGVyIEwyVlBOLCBM M1ZQTiwgYW5kIFBXRTMgc2hvdWxkIHN0YXkgc2VwYXJhdGUgb3Igc2hvdWxkIG1lcmdlLCBidXQg SSB0aGluayB0aGF0IGl0IGlzIGEgcXVlc3Rpb24gd2hpY2ggaXMgd29ydGggYXNraW5nLjxicj4m Z3Q7PGJyPiZndDsgVGhhbmtzLCBSb3NzPGJyPiZndDs8YnI+Jmd0OyBGcm9tOiByb3V0aW5nLWRp c2N1c3Npb24gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cm91dGluZy1kaXNjdXNzaW9uLWJvdW5j ZXNAaWV0Zi5vcmciPnJvdXRpbmctZGlzY3Vzc2lvbi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24g QmVoYWxmIE9mIEFsaWEgQXRsYXM8YnI+Jmd0OyBTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0 IDM6NTggUE08YnI+Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBp ZXRmLm9yZyI+cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPC9hPjxicj4mZ3Q7IFN1YmplY3Q6 IEltcHJvdmluZyBhbmQgUmVzdHJ1Y3R1cmluZyB0aGUgUm91dGluZyBBcmVhPGJyPiZndDs8YnI+ Jmd0OyBUbyBhbGwgcGFydGljaXBhbnRzIGluIHRoZSBSb3V0aW5nIEFyZWEsPGJyPiZndDs8YnI+ Jmd0OyBBZHJpYW4gYW5kIEkgYXJlIHdvcmtpbmcgb24gaW1wcm92aW5nIHRoZSBxdWFsaXR5LCBz cGVlZCwgYW5kPGJyPiZndDsgZXhwZXJpZW5jZSBvZiBnZXR0aW5nIHdvcmsgZG9uZSBpbiB0aGUg SUVURiBSb3V0aW5nIEFyZWEuICZuYnNwO1RoZXJlIGFyZTxicj4mZ3Q7IHRocmVlIGluaXRpYXRp dmVzIHRoYXQgd2UgYXJlIHdvcmtpbmc6IFdHIERyYWZ0IFFBLCBSb3V0aW5nIEFyZWE8YnI+Jmd0 OyBzcGVjaWZpYyBXRyBjaGFpciB0cmFpbmluZywgYW5kIHJlb3JnYW5pemluZyB0aGUgd29ya2lu ZyBncm91cHMgaW4gdGhlPGJyPiZndDsgYXJlYS48YnI+Jmd0Ozxicj4mZ3Q7IEZpcnN0LCB3ZSBp bnRlbmQgdG8gdXNlIG91ciBSb3V0aW5nIERpcmVjdG9yYXRlIG1vcmUgcHJvYWN0aXZlbHkgYnk8 YnI+Jmd0OyBpbnRyb2R1Y2luZyBhIFdvcmtpbmcgR3JvdXAgRHJhZnQgUXVhbGl0eSBBc3N1cmFu Y2UgKFdHIERyYWZ0IFFBKTxicj4mZ3Q7IHByb2Nlc3Mgd2hlcmUgdGhlIHNhbWUgc2VsZWN0ZWQg cm91dGluZyBkaXJlY3RvcmF0ZSBtZW1iZXIgd2lsbCByZXZpZXc8YnI+Jmd0OyBhIGRyYWZ0IGR1 cmluZyBXRyBkcmFmdCBhZG9wdGlvbiBhbmQgZHVyaW5nIFdHIGxhc3QgY2FsbC4gJm5ic3A7VGhl IHByb2Nlc3M8YnI+Jmd0OyB3aWxsIGJlIGRvY3VtZW50ZWQgb24gdGhlIFJvdXRpbmcgQXJlYSB3 aWtpPGJyPiZndDsgKDxhIGhyZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRn L3RyYWMvd2lraSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2Fy ZWEvcnRnL3RyYWMvd2lraTwvYT4pLiAmbmJzcDtUaGlzIHNob3VsZCBhbGxvdzxicj4mZ3Q7IGRp cmVjdG9yYXRlIHJldmlld3MgdG8gcmVwb3J0IHRlY2huaWNhbCBpc3N1ZXMgdGhhdCBjYW4gYWN0 dWFsbHkgZ2V0PGJyPiZndDsgZml4ZWQgZWFybHkgaW4gdGhlIHByb2Nlc3MgKGVxdWl2YWxlbnQg b2YgYnVnIHJlcG9ydHMpIGFzIG9wcG9zZWQgdG88YnI+Jmd0OyBqdXN0IG5vdGluZyB0aGUgY29u Y2VybnMgaW4gdGhlIGRyYWZ0cyAoZXF1aXZhbGVudCBvZiByZWxlYXNlIG5vdGVzKS48YnI+Jmd0 Ozxicj4mZ3Q7IFNlY29uZCwgYXMgd2FzIGRpc2N1c3NlZCBkdXJpbmcgdGhlIHJlY2VudCBJRVNH IHJldHJlYXQsIGluIGFkZGl0aW9uPGJyPiZndDsgdG8gdGhlIElFVEYtd2lkZSBXRyBjaGFpciB0 cmFpbmluZywgd2UgaW50ZW5kIHRvIGhhdmUgYSBzZXJpZXMgb2Y8YnI+Jmd0OyB0cmFpbmluZyBz ZXNzaW9ucyBmb3IgV0cgQ2hhaXJzIGluIHRoZSBSb3V0aW5nIEFyZWEgYWRkcmVzc2luZyB0b3Bp Y3M8YnI+Jmd0OyBzdWNoIGFzIGp1ZGdpbmcgY29uc2Vuc3VzLCBwcm9qZWN0IG1hbmFnZW1lbnQs IG1vdGl2YXRpbmcgdm9sdW50ZWVycyw8YnI+Jmd0OyB1c2luZyB0aGUgZGF0YXRyYWNrZXIgKHZp YSBhIHNhbmRib3ggdmVyc2lvbiB0aGF0IGNhbiBiZSBwbGF5ZWQ8YnI+Jmd0OyB3aXRoIHNhZmVs eSksIGFuZCBzaGFyaW5nIGV4cGVyaWVuY2VzIGJldHdlZW4gV0cgY2hhaXJzLjxicj4mZ3Q7PGJy PiZndDsgVGhpcmQsIHdlIGludGVuZCB0byByZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdyb3VwcyBp biB0aGUgUm91dGluZyBhcmVhLjxicj4mZ3Q7IFdlIGZlZWwgdGhhdCBpdCBpcyBpbXBvcnRhbnQg dG8gZm9jdXMgb24gYXJlYXMgd2hlcmUgdGhlcmUgaXMgYWN0aXZlPGJyPiZndDsgaW50ZXJlc3Qg aW4gc3RhbmRhcmRpemF0aW9uIGFuZCB0byBiZSBvcGVuIGFuZCBhYmxlIHRvIGFjY2VwdCBuZXcg d29yazxicj4mZ3Q7IGludG8gdGhlIGFyZWEuICZuYnNwO0FzIHlvdSBrbm93LCB3ZSBoYXZlIGhh ZCBzZXZlcmFsIG5ldyB3b3JraW5nIGdyb3Vwczxicj4mZ3Q7IChudm8zLCBpMnJzLCBzZmMsIHNw cmluZykgY3JlYXRlZCBpbiB0aGUgbGFzdCBmZXcgeWVhcnMgYW5kIHdlIG5lZWQgdG88YnI+Jmd0 OyBiZSBvcGVuIGFuZCBhYmxlIHRvIGhhbmRsZSBtb3JlIG5ldyB3b3JrIGFzIGl0IGNvbWVzIGlu LiAmbmJzcDtXZSB3b3VsZDxicj4mZ3Q7IGFsc28gbGlrZSB0byBpbXByb3ZlIHRoZSBzaWduYWwt dG8tbm9pc2UgcmF0aW8gZXhwZXJpZW5jZWQgYnk8YnI+Jmd0OyBwYXJ0aWNpcGFudHMgaW4gdGhl IGRpZmZlcmVudCB3b3JraW5nIGdyb3VwcyBhbmQgaW1wcm92ZSB0aGUgcXVhbnRpdHk8YnI+Jmd0 OyBhbmQgcXVhbGl0eSBvZiBkaXNjdXNzaW9uIGFuZCByZXZpZXdzLiAmbmJzcDtJdCBpcyBsaWtl bHkgdGhhdCBub3QgYWxsIFdHczxicj4mZ3Q7IGluIHRoZSBSb3V0aW5nIEFyZWEgd2lsbCBiZSBk aXJlY3RseSBhZmZlY3RlZC48YnI+Jmd0Ozxicj4mZ3Q7IEhlcmUgaXMgdGhlIHRpbWUtbGluZSBm b3IgcmVvcmdhbml6aW5nIHRoZSBXR3MuPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7Tk9X OiBwdWJsaWMgZGlzY3Vzc2lvbiBvbiA8YSBocmVmPSJtYWlsdG86cm91dGluZy1kaXNjdXNzaW9u QGlldGYub3JnIj5yb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8L2E+IGFib3V0IGhvdyB0bzxi cj4mZ3Q7ICZuYnNwOyAmbmJzcDtyZW9yZ2FuaXplIHRoZSB3b3JraW5nIGdyb3VwcyB0byBiZXN0 IG1lZXQgb3VyIG1vdGl2YXRpb25zLjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtBZGRpdGlvbmFsIGZv Y3VzZWQgZGlzY3Vzc2lvbnMgYXJlIGV4cGVjdGVkIG9uIHRoZTxicj4mZ3Q7ICZuYnNwOyAmbmJz cDs8YSBocmVmPSJtYWlsdG86cnRnLWNoYWlyc0BpZXRmLm9yZyI+cnRnLWNoYWlyc0BpZXRmLm9y ZzwvYT4gYW5kIDxhIGhyZWY9Im1haWx0bzpydGctZGlyQGlldGYub3JnIj5ydGctZGlyQGlldGYu b3JnPC9hPiBtYWlsaW5nIGxpc3RzLjxicj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwO0luIFRv cm9udG86IFRoZXJlIHdpbGwgYmUgbWVldGluZ3Mgd2l0aCB0aGUgV0cgY2hhaXJzIGFuZCB0aGU8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7Um91dGluZyBEaXJlY3RvcmF0ZSB0byBnZXQgdGhlIGlkZWFz IGRlc2NyaWJlZCBhbmQgYWdyZWVkIHVwb24uPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7 QXQgdGhlIFJvdXRpbmcgQXJlYSBNZWV0aW5nIGluIFRvcm9udG86IERpc2N1c3MgdGhlIHNldCBv Zjxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtyZW9yZ2FuaXplZCBXR3MgYW5kIGdlbmVyYWwgY2hhcnRl ciBjb250ZW50IGluIHRoZSBSb3V0aW5nIEFyZWE8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7bWVldGlu Zy48YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtTZXB0ZW1iZXIgMjAxNDogQmFzZWQgdXBv biB0aGUgZmVlZGJhY2ssIHN1Z2dlc3Rpb25zLCBhbmQ8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ZGlz Y3Vzc2lvbiwgQWRyaWFuIGFuZCBJIGZpbmFsaXplIHRoZSByZW9yZ2FuaXplZCBXRyBjaGFydGVy cy4gJm5ic3A7V2U8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7c3RhcnQgdGhlIGludGVybmFsIElFU0cg ZGlzY3Vzc2lvbiBhbmQgcHVibGljIHJldmlld3MuPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5i c3A7T2N0b2JlciAyMDE0OiBGb3JtYWwgcmVjaGFydGVyaW5nIHByb2Nlc3MgY29tcGxldGVzLjxi cj4mZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwO0luIEhvbm9sdWx1OiBUaGUgbmV3IHNldCBvZiBX R3MgbWVldC48YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtBZnRlciBIb25vbHVsdTogQWRy aWFuIGFuZCBJIGRlYWwgd2l0aCBhbnkgaXNzdWVzIGFuZCBjaGFydGVyPGJyPiZndDsgJm5ic3A7 ICZuYnNwO3VwZGF0ZXMgYmFzZWQgdXBvbiBhIGZldyBtb250aHMgb2YgZXhwZXJpZW5jZS48YnI+ Jmd0Ozxicj4mZ3Q7IEhlcmUgYXJlIHRoZSBtb3RpdmF0aW9ucyB0aGF0IEFkcmlhbiBhbmQgSSB3 b3VsZCBsaWtlIHRvIGJlIGNvbnNpZGVyZWQ8YnI+Jmd0OyB3aGVuIGNvbWluZyB1cCB3aXRoIGlk ZWFzIGZvciBob3cgdGhlIFdHcyBzaG91bGQgYmUgcmVvcmdhbml6ZWQuPGJyPiZndDs8YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7MSkgTW92ZSB0b3dhcmRzIG9yZ2FuaXppbmcgd29ya2luZyBncm91cHMg b24gZnVuY3Rpb25hbDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDtyZXNwb25zaWJpbGl0aWVzIHJhdGhl ciB0aGFuIHNjb3BpbmcgdGhlbSB0byBzcGVjaWZpYyBwcm90b2NvbHMuPGJyPiZndDs8YnI+Jmd0 OyAmbmJzcDsgJm5ic3A7MikgU3BsaXQgZ2lhbnQgd29ya2luZyBncm91cHMgc28gcmVsZXZhbnQg d29yayBpcyBkb25lIGluIG9uZSBwbGFjZTxicj4mZ3Q7ICZuYnNwOyAmbmJzcDthbmQgdGhlcmUg aXMgYW4gaW1wcm92ZWQgc2lnbmFsLXRvLW5vaXNlIHJhdGlvIGZvciBwYXJ0aWNpcGFudHMgd2hv PGJyPiZndDsgJm5ic3A7ICZuYnNwO2FyZSBvbmx5IGludGVyZXN0ZWQgaW4gYSBzbGljZSBvZiB0 aGUgY3VycmVudCB3b3JraW5nIGdyb3VwJ3Mgd29yay48YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAm bmJzcDszKSBDcmVhdGUgc3luZXJnaWVzIGZvciBzY2F0dGVyZWQgZnVuY3Rpb25hbGl0eSAoZXhh bXBsZSBpZGVhczo8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7T0FNLCBGUlIsIHRyYWZmaWMtZW5naW5l ZXJpbmcpPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7NCkgQ3JlYXRlIGEgRElTUEFUQ0gg d29ya2luZyBncm91cCBmb3IgY2xlYXIgbmV3IGlkZWEgZGlzY3Vzc2lvbjs8YnI+Jmd0OyAmbmJz cDsgJm5ic3A7cnRnd2cgc2VydmVzIHNvbWUgb2YgdGhpcyBwdXJwb3NlIGJ1dCBkb2Vzbid0IGhh dmUgYSBjbGVhciBwcm9jZXNzPGJyPiZndDsgJm5ic3A7ICZuYnNwO2FuZCBpc24ndCBkcmF3aW5n IGluIHRoZSBuZXcgaWRlYXMuPGJyPiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7NSkgRm9jdXMg Um91dGluZyBBcmVhIHRpbWUgb24gZGVzaWduIGNlbnRlcnMgcmF0aGVyIHRoYW4gb24gZmFyPGJy PiZndDsgJm5ic3A7ICZuYnNwO2Nvcm5lciBjYXNlcy48YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAm bmJzcDs2KSBFYWNoIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGhhdmUgY2xlYXIsIHdlbGwgZGVmaW5l ZCwgYW5kIGFjaGlldmFibGUgZ29hbHMuPGJyPiZndDs8YnI+Jmd0OyBOb3RpbmcgdGhhdCB0aGUg Um91dGluZyBBcmVhIGhhcyBpbmhlcml0ZWQgc29tZSBvZiBpdHMgV0cgc3RydWN0dXJlPGJyPiZn dDsgZnJvbSB0aGUgc3ViLUlQIGFyZWEsIGl0IGlzIG5vdCBhIGdvYWwgdG8gZm9yY2UgSVAgcm91 dGluZyBhbmQgTVBMUzxicj4mZ3Q7IHJvdXRpbmcgdG8gcmVtYWluIHNlcGFyYXRlZC48YnI+Jmd0 Ozxicj4mZ3Q7IFRoZSBnb2FsIG9mIHRoaXMgcmVvcmdhbml6YXRpb24gaXMgbm90IGNsb3Npbmcg d29ya2luZyBncm91cHMuICZuYnNwO0Fkcmlhbjxicj4mZ3Q7IGFuZCBBbGlhIGFyZSBwZXJmZWN0 bHkgY2FwYWJsZSBvZiBjbG9zaW5nIHdvcmtpbmcgZ3JvdXBzIHdpdGhvdXQgZ29pbmc8YnI+Jmd0 OyB0aHJvdWdoIHJlc3RydWN0dXJpbmcuPGJyPiZndDs8YnI+Jmd0OyBGb3IgdGhvc2Ugb2YgeW91 IHRoYXQgaGF2ZSByZWFkIHRoaXMgZmFyLCB0aGFuayB5b3UuICZuYnNwO0dldHRpbmcgdGhpcyA4 MCU8YnI+Jmd0OyByaWdodCBpcyBnb2luZyB0byB0YWtlIHNvbWUgc2VyaW91cyBkaXNjdXNzaW9u IGFuZCB0aG91Z2h0LiAmbmJzcDtXZSBhbGw8YnI+Jmd0OyB3b3JrIGluIHRoZSBSb3V0aW5nIEFy ZWEgdG9nZXRoZXIgd2l0aCBkaWZmZXJlbnQgcGVyc3BlY3RpdmVzLiAmbmJzcDtQbGVhc2U8YnI+ Jmd0OyB0aGluayBjYXJlZnVsbHkgYW5kIGhlbHAgdXMgaGF2ZSBhIGhpZ2hseSBmb2N1c2VkIGRp c2N1c3Npb24uPGJyPiZndDs8YnI+Jmd0OyBUaGFua3MsPGJyPiZndDsgQWxpYSBhbmQgQWRyaWFu PGJyPiZndDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7 IHJvdXRpbmctZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyA8YSBocmVmPSJtYWlsdG86 cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnIj5yb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc8 L2E+PGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb3V0aW5nLWRpc2N1c3Npb24iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JvdXRpbmctZGlzY3Vzc2lvbjwvYT48YnI+PGJyPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnJvdXRpbmctZGlzY3Vz c2lvbiBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnJvdXRpbmctZGlzY3Vzc2lvbkBp ZXRmLm9yZyI+cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvdXRpbmctZGlzY3Vzc2lvbiIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm91dGlu Zy1kaXNjdXNzaW9uPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_40746B2300A8FC4AB04EE722A593182B74DA34DBONWVEXCHMB04cie_-- From nobody Fri Jun 27 11:33:08 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15FE1B29B9 for ; Fri, 27 Jun 2014 11:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pXVsMFKmYP3 for ; Fri, 27 Jun 2014 11:33:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5F21B29A2 for ; Fri, 27 Jun 2014 11:33:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F0F7720038; Fri, 27 Jun 2014 13:56:51 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 828E763B1C; Tue, 24 Jun 2014 11:12:05 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6EE3B63AED; Tue, 24 Jun 2014 11:12:05 -0400 (EDT) From: Michael Richardson To: routing-discussion@ietf.org, "Joel M. Halpern" Subject: Re: FW: Routing Area organization In-Reply-To: <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/EhXzhLCQ4O3tJ1eHL_T6v4rOJso Cc: adrian@olddog.co.uk X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 18:33:06 -0000 --=-=-= Adrian Farrel wrote: > I would either close ROLLand move the work into a common low power group in > another area, or make ti the common low power working group. ROLL will close by the end of 2014. We thought that IETF90 might be the last in-person meeting, but I can't promise that yet. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU6mVRYCLcPvd0N1lAQK0lwgAvu74FeYAJwB5+uZZ7T2/Y+b9pqmfXBW3 QjxHDp/0Pylmowz7XzCTb4O7b/L/mFlZYAi5KqKJsta1P138WlSjUoR/RXSJheks Kqn+wFJKcEjFGyDB8Q27n1uXNNuqsozBZaU0vnoa3FwaTvc0D84yf5bEYquvCQ5V bYVutXu1F+TB/NF7MrRissfh3YXROHWbSnR6fEMKejwKE5St9HwJrkDep45iD1HA aVsU77AnPC4V9M/d6W/bgvcqG5DOIgIzwOBnuieSsSeYMIBqjC6m5lghMC2Ckfm+ OYY/JFeYWhmUP1JcT8XDqtCqhdLkkwvfJY0cKBB2ccJUXQbYxZN5ZQ== =6klM -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 27 16:21:06 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE64F1A023E for ; Fri, 27 Jun 2014 16:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G62ANjNXZNev for ; Fri, 27 Jun 2014 16:21:01 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3CD1A023D for ; Fri, 27 Jun 2014 16:21:01 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id f73so3503840yha.8 for ; Fri, 27 Jun 2014 16:21:01 -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=YQOlqFDNA4y8YqvZVxR5WMqAGNKNJhAKDoOu0/MYITM=; b=RtK8YvA8asaPmz5PcnYk+wBk8vOFv3IYf1HuPG/UrabuDaEeCVx0EYM4EGAEGvybYI dpGDO+ZMl7nO3Oi97dgW5j+v4JH4iXPG/4CkGjKfFRduqszH1NSgozmQ/RF7Rrt06XQ4 AWL2W2TpFmNc2VTJPHmAp9lhsIeBv8ZM+DdgEMrUs9ynejWIoxccTLp29Ts9AKCmnc9y COnf5SwRL/2mmMAHYU3kPdGFf83FpRLvF6eDRj9kKvOUrQawb9o0td1NgApsNqvtLDL8 NgJWhv1EMCNwHk34wUyz3Fo+TzznLc5cCdc0aUNgTEXf0abnIYdJFND1SorU/6p6iL0K Dj4A== MIME-Version: 1.0 X-Received: by 10.236.90.209 with SMTP id e57mr8131510yhf.135.1403911261070; Fri, 27 Jun 2014 16:21:01 -0700 (PDT) Received: by 10.170.194.19 with HTTP; Fri, 27 Jun 2014 16:21:00 -0700 (PDT) In-Reply-To: <25896.1403622725@sandelman.ca> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <25896.1403622725@sandelman.ca> Date: Sat, 28 Jun 2014 00:21:00 +0100 Message-ID: Subject: Re: FW: Routing Area organization From: Abdussalam Baryun To: Michael Richardson Content-Type: multipart/alternative; boundary=20cf3005e07a032ca004fcd99048 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/nX2Wq5O4y_v2L7WTrXEM7MzJQuM Cc: "adrian@olddog.co.uk" , "Joel M. Halpern" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 23:21:04 -0000 --20cf3005e07a032ca004fcd99048 Content-Type: text/plain; charset=UTF-8 I think including this Area's current standards relating to its WG, as we don't forget about current standards. I noticed that there were pushing for ROLL close but not sure if there was consensus in the WG to close. I remember that there was serious discussions related to RPL performance, and RPL is the main standard but it still may have issues. So if there is community agreement to close ROLL, who will consider developing RPL for more use cases. I have no problem with closing this WG if ADs want, but we should not be closing develop standards or leave their design not completed if some other want to continue. AB On Tuesday, June 24, 2014, Michael Richardson wrote: > > Adrian Farrel > wrote: > > I would either close ROLLand move the work into a common low power > group in > > another area, or make ti the common low power working group. > > ROLL will close by the end of 2014. We thought that IETF90 might be the > last > in-person meeting, but I can't promise that yet. > > -- > Michael Richardson >, Sandelman > Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > --20cf3005e07a032ca004fcd99048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think including this=C2=A0Area's=C2=A0current=C2=A0standards relating= =C2=A0to its=C2=A0WG, as we don't forget about current=C2=A0standards. = I noticed that there were=C2=A0pushing for ROLL close but not sure if there= was consensus in the WG to close. I remember that there was serious discus= sions related to RPL performance, and RPL is the main standard but it=C2=A0= still may have issues.=C2=A0

So if there is community agreement to close ROLL, who w= ill consider=C2=A0developing RPL for more use cases. I have no problem with= closing this=C2=A0WG if ADs want,=C2=A0but we should not be=C2=A0closing d= evelop=C2=A0standards or leave their=C2=A0design=C2=A0not completed if some= other=C2=A0want to continue.=C2=A0

AB

On Tuesday, June 24, 2014, Michael Ric= hardson wrote:

Adrian Farrel <adrian@olddog.co.uk> wrote:
=C2=A0 =C2=A0 > I would either close ROLLand move the work into a common= low power group in
=C2=A0 =C2=A0 > another area, or make ti the common low power working gr= oup.

ROLL will close by the end of 2014. =C2=A0We thought that IETF90 might be t= he last
in-person meeting, but I can't promise that yet.

--
Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works
IETF ROLL WG co-chair. =C2=A0 =C2=A0http://datatracker.ietf.org/wg/roll/cha= rter/

--20cf3005e07a032ca004fcd99048-- From nobody Sat Jun 28 05:07:35 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CFB1A011C for ; Sat, 28 Jun 2014 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZbjt0SmKSI4 for ; Sat, 28 Jun 2014 05:07:28 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F9F1A00AA for ; Sat, 28 Jun 2014 05:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5399; q=dns/txt; s=iport; t=1403957249; x=1405166849; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=eZE1PeCBK27JUm2R8elLFmkp9Ugs5aON4hEtxfzgiII=; b=amaLaJ3eIoLyG28ooA9S4Xl+DCLfOZF6gAb90lbXhUxcQEHRgCqsKZ4J gpw4n0zPZ6zSyOTixb6GhMjib31OBDSsZ35XqcJjWhyKlBbQfg3LpDDoC BcqKekGB75I3vvHGysnnF0/RSQAdGJ9C+5A14ZuMnvYFWGvWSzAa2D4kP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQMALmvrlOtJV2b/2dsb2JhbABagw1SWqpTAQEBAQEBBQFtAYIpjUSBVQGGbFMBgQcWdYQDAQEBBAEBAWsbAgEIBBQnByEGCxQRAgQBEhSIGgMRDb4uDYZSFAMGAYVdhnuBWFWDLYEWBZhfgX6BRowlhhCDQoIw X-IronPort-AV: E=Sophos; i="5.01,567,1400025600"; d="scan'208,217"; a="56686120" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 28 Jun 2014 12:07:08 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5SC77LC004090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Jun 2014 12:07:07 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.151]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Sat, 28 Jun 2014 07:07:06 -0500 From: "JP Vasseur (jvasseur)" To: Michael Richardson , Adrian Farrel , "Joel M. Halpern" , "routing-discussion@ietf.org" , "Abdussalam Baryun" Subject: Re: Routing Area organization Thread-Topic: Routing Area organization Thread-Index: AQHPksl6KS1an37aiEuBDGbRidDFLw== Date: Sat, 28 Jun 2014 12:07:06 +0000 Message-ID: <9286C2DD-69CD-41B5-AACD-9E4632496AB2@cisco.com> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <25896.1403622725@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.97] Content-Type: multipart/alternative; boundary="_000_9286C2DD69CD41B5AACD9E4632496AB2ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/xfFjH57zWnpKce44PTNAEek6kKw X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 12:07:31 -0000 --_000_9286C2DD69CD41B5AACD9E4632496AB2ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On the subject matter of ROLL, since I was co-chairing for 5 years, this se= ems premature to me. Indeed, there are now several deployment with millions of nodes, and without a doubt protocol ext= ensions will be required. Furthermore there are true specifics about LLNs deserving IMO to keep the WG alive for some t= ime at least. Thanks. JP. On Jun 28, 2014, at 1:21 AM, Abdussalam Baryun > wrote: I think including this Area's current standards relating to its WG, as we d= on't forget about current standards. I noticed that there were pushing for = ROLL close but not sure if there was consensus in the WG to close. I rememb= er that there was serious discussions related to RPL performance, and RPL i= s the main standard but it still may have issues. So if there is community agreement to close ROLL, who will consider develop= ing RPL for more use cases. I have no problem with closing this WG if ADs w= ant, but we should not be closing develop standards or leave their design n= ot completed if some other want to continue. AB On Tuesday, June 24, 2014, Michael Richardson wrote: Adrian Farrel > wrote: > I would either close ROLLand move the work into a common low power gr= oup in > another area, or make ti the common low power working group. ROLL will close by the end of 2014. We thought that IETF90 might be the la= st in-person meeting, but I can't promise that yet. -- Michael Richardson >, Sandelman Softwar= e Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --_000_9286C2DD69CD41B5AACD9E4632496AB2ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable On the subject matter of ROLL, since I was co-chairing for 5 years, this se= ems premature to me. Indeed, there are now
several deployment with millions of nodes, and without a doubt protoco= l extensions will be required. Furthermore there 
are true specifics about LLNs deserving IMO to keep the WG alive for s= ome time at least.

Thanks.

JP.

On Jun 28, 2014, at 1:21 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

I think including this Area's current&n= bsp;standards relating to its WG, as we don't forget about curren= t standards. I noticed that there were pushing for ROLL close but= not sure if there was consensus in the WG to close. I remember that there was serious discussions related to RPL performance, and RPL is the m= ain standard but it still may have issues. 

So if there is community agreement to close ROLL, who will consider&nb= sp;developing RPL for more use cases. I have no problem with closing this&n= bsp;WG if ADs want, but we should not be closing develop sta= ndards or leave their design not completed if some other wan= t to continue. 

AB

On Tuesday, June 24, 2014, Michael Richardson wrote:

Adrian Farrel <adrian@olddog.co.uk> wrote:
    > I would either close ROLLand move the work into a common= low power group in
    > another area, or make ti the common low power working gr= oup.

ROLL will close by the end of 2014.  We thought that IETF90 might be t= he last
in-person meeting, but I can't promise that yet.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelma= n Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/cha= rter/

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion

--_000_9286C2DD69CD41B5AACD9E4632496AB2ciscocom_-- From nobody Sat Jun 28 10:29:43 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AA71A0387 for ; Sat, 28 Jun 2014 10:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gDajtmZ0Tik for ; Sat, 28 Jun 2014 10:29:38 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042EB1A0382 for ; Sat, 28 Jun 2014 10:29:37 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5SHTWF5024244; Sat, 28 Jun 2014 18:29:32 +0100 Received: from 950129200 ([149.254.181.99]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s5SHTUvQ024233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Jun 2014 18:29:31 +0100 From: "Adrian Farrel" To: "'JP Vasseur \(jvasseur\)'" , "'Michael Richardson'" , "'Joel M. Halpern'" , , "'Abdussalam Baryun'" References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <25896.1403622725@sandelman.ca> <9286C2DD-69CD-41B5-AACD-9E4632496AB2@cisco.com> In-Reply-To: <9286C2DD-69CD-41B5-AACD-9E4632496AB2@cisco.com> Subject: RE: Routing Area organization Date: Sat, 28 Jun 2014 18:29:24 +0100 Message-ID: <00c401cf92f6$82fc59e0$88f50da0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01CF92FE.E4C30BD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFSmnyEPMMBa9dnJPneRdJ51F0LdwFUNSw1AkJmzUIBA2+WVwFkd+oLnFDCgnA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20786.000 X-TM-AS-Result: No--31.409-10.0-31-10 X-imss-scan-details: No--31.409-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkBE3+HJGhOygFVeGWZmxN2MCIFiJP1XZ1LjsTquy0JRi5hj e/k69J6Byhc8qlJBQbp86ASFUpR8RVxJyuxIJS/oSEQN/D/3cG7DHSNFHFxB80SVpnjjB2vkyJi VHsxfXPgTX1o9z+vwJ0lWoAj0w0Xlq0nnY6Lqu2ejFYHTfcPkwqX1XMd/SqvuArMcoUfMuwkIvX JhQQTwfmyCDmQ1JMsfp1TrE9YeL7iVd+RxKfkrImA/V00XWjDtHJJXhOFmNVtIjvA1/YS+0TEYT 1NY9ru5icv0w1I+Nemmi73qEYzchwVcD+m/PiZI6/xAZojbl7c6QNs2WCY79aj5v7I4/SgYqban atOfUmJFNXNnLXKkbzyUG2TkqFpK+g3TEidc8f+RGzV8Bxg0cdLzZBb+sVAjYXvKrYW+zbcc5Zb 9Gn+KytpUhkWHC+FFr060l5dPt5XOf6FUr/HJkZRrnSy7UTtbj0Ch4H3a2gReGZa58oEXZPgFse 6Tj2INTzJTmHIIC0LbAqeSI3xDne9e8ifCHArbQr2qXCJMSV91k+gP1XamtKlVRHRK9i1K/hkBS y3LYQ2q/r7ujTTNh4sWCfP6Gmv5dbSgks66AoH2Ii0VSfdeQzuvYa1v2IFhTx0U/40+rr7a6BBk IrnTcudLZPVW5sDNedxyf/baQ0eb2ohNz0F+pNT+TcIhUUCBZJAk04EAz2Un+p552csI1Y/sYBB J7n+d9sFE6GfY4gY8LuP+bOkMWp8voPxO05mszzuzg6dga4Iytf6nW43O0D3dpxIEGwCa8FhGjT p5WPfXX6lVF/9rGbRd0WwZSVdNNJyAyqAmcb+eAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMeDWdEU5XDLsBorcjURJsgGFbVHVWIb3KYhOD0ffEr8l+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/5CPL1N8QoGNXm6nMQdGbQ-5dwn0 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 17:29:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C5_01CF92FE.E4C30BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just for the record, Michael was quoting me quoting Joel. I did not say "I would close ROLL". On the other hand, work in the WG is tailing off as Michael says. That says nothing about the success or failure of RPL, but rather that we have reached something of a plateau in the standardisation. When the WG has run out of work and assuming that there is no new work proposed (by people who are actually doing the work!) then the WG would close. Closing a WG is a mark of success, not failure. Working groups are supposed to be set up to do something, do it, and then close. It is quite possible that, at some time in the future, there will be a need to do more work on RPL (adding any number of widgets, removing options, polishing documentation) and that a new WG would be spun up to handle new work. That might be next week or in ten years' time. Adrian From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] Sent: 28 June 2014 13:07 To: Michael Richardson; Adrian Farrel; Joel M. Halpern; routing-discussion@ietf.org; Abdussalam Baryun Subject: Re: Routing Area organization On the subject matter of ROLL, since I was co-chairing for 5 years, this seems premature to me. Indeed, there are now several deployment with millions of nodes, and without a doubt protocol extensions will be required. Furthermore there are true specifics about LLNs deserving IMO to keep the WG alive for some time at least. Thanks. JP. On Jun 28, 2014, at 1:21 AM, Abdussalam Baryun wrote: I think including this Area's current standards relating to its WG, as we don't forget about current standards. I noticed that there were pushing for ROLL close but not sure if there was consensus in the WG to close. I remember that there was serious discussions related to RPL performance, and RPL is the main standard but it still may have issues. So if there is community agreement to close ROLL, who will consider developing RPL for more use cases. I have no problem with closing this WG if ADs want, but we should not be closing develop standards or leave their design not completed if some other want to continue. AB On Tuesday, June 24, 2014, Michael Richardson wrote: Adrian Farrel > wrote: > I would either close ROLLand move the work into a common low power group in > another area, or make ti the common low power working group. ROLL will close by the end of 2014. We thought that IETF90 might be the last in-person meeting, but I can't promise that yet. -- Michael Richardson >, Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion ------=_NextPart_000_00C5_01CF92FE.E4C30BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just for the record, Michael = was quoting me quoting Joel. I did not say "I would close = ROLL".

 

On the other hand, work in the = WG is tailing off as Michael says.

That says nothing about the = success or failure of RPL, but rather that we have reached something of = a plateau in the standardisation.

When the WG has run out of = work and assuming that there is no new work proposed (by people who are = actually doing the work!) then the WG would = close.

Closing a WG is a mark of = success, not failure.

Working groups are supposed to = be set up to do something, do it, and then = close.

 

It is quite possible that, at = some time in the future, there will be a need to do more work on RPL = (adding any number of widgets, removing options, polishing = documentation) and that a new WG would be spun up to handle new work. = That might be next week or in ten years' time.

 

Adrian

 

 

From: JP Vasseur = (jvasseur) [mailto:jvasseur@cisco.com]
Sent: 28 June 2014 = 13:07
To: Michael Richardson; Adrian Farrel; Joel M. Halpern; = routing-discussion@ietf.org; Abdussalam Baryun
Subject: Re: = Routing Area organization

 

On the subject = matter of ROLL, since I was co-chairing for 5 years, this seems = premature to me. Indeed, there are now

several deployment with millions of nodes, and without a doubt = protocol extensions will be required. Furthermore = there 

are true specifics = about LLNs deserving IMO to keep the WG alive for some time at = least.

 

Thanks.

 

JP.

 



I think including this Area's current standards = relating to its WG, as we don't forget about = current standards. I noticed that there were pushing for ROLL = close but not sure if there was consensus in the WG to close. I remember = that there was serious discussions related to RPL performance, and RPL = is the main standard but it still may have issues.  =

 

So if there is community agreement to close ROLL, who will = consider developing RPL for more use cases. I have no problem with = closing this WG if ADs want, but we should not be closing = develop standards or leave their design not completed if = some other want to = continue. 

 

AB


On Tuesday, June = 24, 2014, Michael Richardson wrote:


Adrian Farrel = <adrian@olddog.co.uk> = wrote:
    > I would either close ROLLand move the work = into a common low power group in
    > another area, or = make ti the common low power working group.

ROLL will close by = the end of 2014.  We thought that IETF90 might be the = last
in-person meeting, but I can't promise that = yet.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software = Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

_______________________________________________
routing-discus= sion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=

 

------=_NextPart_000_00C5_01CF92FE.E4C30BD0-- From nobody Sun Jun 29 03:24:09 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8383A1A0444 for ; Sun, 29 Jun 2014 03:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka34JXfqvKt2 for ; Sun, 29 Jun 2014 03:24:03 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B131A044D for ; Sun, 29 Jun 2014 03:24:03 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 200so3972733ykr.16 for ; Sun, 29 Jun 2014 03:24:02 -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=NqZ4Z2gAqcYZbWolqu8yK0Iy+U/fa/QYLc5bDX2c+Go=; b=HUxDpVR4uGmj6GSaxrX8ySv9f/OHpq9U6Hnh6tVpOahBjKZmIboj4cUUGe8ls2uDPG Y3OioOG6OqqbqwfGOJq027YqvhqhH2vIVbZWe/8yFYJvtX7a/LfTOq7DFg8yqHsnyJ5c u7F6hXCLzER7yr7N7aJkmAXSyFtfP0inwkwk13Q4ugiEsUVsDNU7Uqwdn/y3pmgP+3ej qnZHAiTq4TWV9eoJtKgczMEHLCxjisUe+hO4AWXcDb3xJUtNPHDWkDOflaLYx0hzRSk0 +3qVvbir3/TQjtCqdQmMm5FvZoZXDdPpFT5gGwOI3XxS4BwjrCvqtgGjDRJaeE8OYQEV +WZQ== MIME-Version: 1.0 X-Received: by 10.236.113.129 with SMTP id a1mr1337782yhh.127.1404037442697; Sun, 29 Jun 2014 03:24:02 -0700 (PDT) Received: by 10.170.194.19 with HTTP; Sun, 29 Jun 2014 03:24:02 -0700 (PDT) In-Reply-To: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> Date: Sun, 29 Jun 2014 11:24:02 +0100 Message-ID: Subject: Re: FW: Routing Area organization From: Abdussalam Baryun To: "routing-discussion@ietf.org" Content-Type: multipart/alternative; boundary=20cf300e512105feba04fcf6f1bc Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Q1LQX3Dd2VkY9L_ZB-IeWc6gKVk Cc: "adrian@olddog.co.uk" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 10:24:07 -0000 --20cf300e512105feba04fcf6f1bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the most important missing item (to organise the area by functionality and quality) is the routing-area-WG (rtgwg), which I suggest should be closed, because it is a general interest and not specific, not community-grouped, and does not ensure quality. How can an area become a working group or a WG becoming an Area? IMHO, this rtgwg WG is making the routing area not organised in terms of new-work/new-interest approved by the area. Routing Area WG helps close all other WGs because this WG is open chartered as any area's purpose. AB On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote: > No mention of MANET in Joel=E2=80=99s analysis. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com > | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > --20cf300e512105feba04fcf6f1bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the most important missing item (to organise the=C2=A0area by=C2=A0= functionality and quality)=C2=A0is the routing-area-WG (rtgwg), which I sug= gest should be closed, because it is a general interest=C2=A0and not specif= ic, not community-grouped, and does not ensure quality.=C2=A0How can an are= a become a working group or a WG becoming an Area? IMHO, this=C2=A0rtgwg=C2= =A0WG is making the routing=C2=A0area not organised in terms of new-work/ne= w-interest approved by=C2=A0the area.

 --20cf300e512105feba04fcf6f1bc-- From nobody Sun Jun 29 04:44:10 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6962A1A0496 for ; Sun, 29 Jun 2014 04:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0eaRKKEQLAr for ; Sun, 29 Jun 2014 04:44:05 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABFC1A0467 for ; Sun, 29 Jun 2014 04:44:05 -0700 (PDT) Received: from [192.168.0.107] (81-229-83-119-no65.business.telia.com [81.229.83.119]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3C55D1802B24; Sun, 29 Jun 2014 13:44:03 +0200 (CEST) Message-ID: <53AFFC04.9010203@pi.nu> Date: Sun, 29 Jun 2014 13:44:04 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Abdussalam Baryun , "routing-discussion@ietf.org" Subject: Re: FW: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Gcs0kz82uFnmM0e9H5NxXBqWtDg Cc: "adrian@olddog.co.uk" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 11:44:08 -0000 Folks, I'm not able to parse either of the paragraphs below, however let me state that I think that the rtgwg is extremely useful, functions well and have done a lot of high quality work. /Loa On 2014-06-29 12:24, Abdussalam Baryun wrote: > I think the most important missing item (to organise the area > by functionality and quality) is the routing-area-WG (rtgwg), which I > suggest should be closed, because it is a general interest and not > specific, not community-grouped, and does not ensure quality. How can an > area become a working group or a WG becoming an Area? IMHO, > this rtgwg WG is making the routing area not organised in terms of > new-work/new-interest approved by the area. > > Routing Area WG helps close all other WGs because this WG is open > chartered as any area's purpose. > > AB > > On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote: > > No mention of MANET in Joel’s analysis.____ > > __ __ > > -- ____ > > Christopher Dearlove____ > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124____ > > chris.dearlove@baesystems.com > | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Sun Jun 29 07:01:57 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D7E1A026C for ; Sun, 29 Jun 2014 07:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecsCqsjzLsQF for ; Sun, 29 Jun 2014 07:01:51 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65521A0262 for ; Sun, 29 Jun 2014 07:01:50 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5TE1lwJ010865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 29 Jun 2014 09:01:49 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5TE1ln2021220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Jun 2014 16:01:47 +0200 Received: from [135.244.224.52] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 29 Jun 2014 16:01:47 +0200 Message-ID: <53B01C4A.8010007@alcatel-lucent.com> Date: Sun, 29 Jun 2014 16:01:46 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: , Subject: Re: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <53A97E59.4010406@joelhalpern.com> <53A986F5.9060608@alcatel-lucent.com> <53AAAA93.8090809@cisco.com> <53AAB69F.3050407@alcatel-lucent.com> <53AAC48B.9000403@cisco.com> In-Reply-To: <53AAC48B.9000403@cisco.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/kvokjI52oe0CIOLKsCST6bWPdRQ X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 14:01:55 -0000 Le 25/06/2014 14:46, Stewart Bryant a écrit : > On 25/06/2014 12:46, Martin Vigoureux wrote: >> Le 25/06/2014 12:55, Stewart Bryant a écrit : >>> On 24/06/2014 15:11, Martin Vigoureux wrote: >>>> Joel, >>>> >>>> and what would be your views on the remaining two: I2RS and SFC? >>> They probably need to continue on their own for a bit. >>> >>> Stewart >> >> Does this suggest that, in your opinion, only mature WG are subject to >> the reorganisation? > That depends! Certainly I would start that way. > > The recent WGs were created by the consensus of the IETF and if it made > sense to merge them with existing WGs that would have been considered at > the time of creation. The starting point would therefore seem to be to > consider the older WGs and then to see the shape of the area looked like > before changing those that were recently created. > > Stewart One could argue that at the time of their creation the question of reorganizing the area was not on the table. I am not advocating for considering all WGs, but on the other hand I do think that the age of a WG might not be the best criteria for selecting it, or not. More precisely if the plan is to reorganize the area we should be careful not to leave on the side few islands which would sustain the model that we seek to change. At the very least we should have a clear plan on how to integrate the for-further-study WGs. -m From nobody Mon Jun 30 04:16:42 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F001A0467 for ; Sun, 29 Jun 2014 04:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeoFx-SN06-X for ; Sun, 29 Jun 2014 04:56:31 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F77E1A0347 for ; Sun, 29 Jun 2014 04:56:29 -0700 (PDT) Received: from [81.147.146.161] (helo=[192.168.1.78]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X1Dib-0002ul-Lq; Sun, 29 Jun 2014 12:56:25 +0100 Subject: Re: Routing Area organization Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_19F97026-0FFC-45CE-A58D-0A9BD0C2112A" From: Rob Shakir In-Reply-To: Date: Sun, 29 Jun 2014 12:56:23 +0100 Message-Id: <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/REFpDhM40YOXzJ_YAN-1lDxr6a4 X-Mailman-Approved-At: Mon, 30 Jun 2014 04:16:33 -0700 Cc: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 11:56:34 -0000 --Apple-Mail=_19F97026-0FFC-45CE-A58D-0A9BD0C2112A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Abdussalam, Like Loa, I=92m not too clear on the point that you are making here. = Perhaps you can clarify for us? rtgwg does a valuable job of picking up items that are not necessarily = protocol specific, but require standardisation. The work on composite = links, and IP FRR are good examples of this. In addition - it provides = the hugely valuable roles of allowing operational considerations for = wider routing issues to be considered, as well as the introduction and = evaluation of new ideas, without a significant process overhead, which = may subsequently be added to an existing WG=92s charter, or result in a = new WG being formed. I would strongly oppose closing rtgwg. Cheers, r. On 29 Jun 2014, at 11:24, Abdussalam Baryun = wrote: > I think the most important missing item (to organise the area by = functionality and quality) is the routing-area-WG (rtgwg), which I = suggest should be closed, because it is a general interest and not = specific, not community-grouped, and does not ensure quality. How can an = area become a working group or a WG becoming an Area? IMHO, this rtgwg = WG is making the routing area not organised in terms of = new-work/new-interest approved by the area. >=20 > Routing Area WG helps close all other WGs because this WG is open = chartered as any area's purpose.=20 >=20 > AB >=20 > On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote: > No mention of MANET in Joel=92s analysis. >=20 > =20 >=20 > -- >=20 > Christopher Dearlove >=20 > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 >=20 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion --Apple-Mail=_19F97026-0FFC-45CE-A58D-0A9BD0C2112A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Abdussalam,

Like Loa, I=92m not = too clear on the point that you are making here. Perhaps you can clarify = for us?

rtgwg does a valuable job of picking up = items that are not necessarily protocol specific, but require = standardisation. The work on composite links, and IP FRR are good = examples of this. In addition - it provides the hugely valuable roles of = allowing operational considerations for wider routing issues to be = considered, as well as the introduction and evaluation of new ideas, = without a significant process overhead, which may subsequently be added = to an existing WG=92s charter, or result in a new WG being = formed.

I would strongly oppose closing = rtgwg.

Cheers,
r.

<= div>
On 29 Jun 2014, at 11:24, Abdussalam Baryun <abdussalambaryun@gmail.com&= gt; wrote:

I think the most important missing item (to organise = the area by functionality and quality) is the = routing-area-WG (rtgwg), which I suggest should be closed, because it is = a general interest and not specific, not community-grouped, and = does not ensure quality. How can an area become a working group or = a WG becoming an Area? IMHO, this rtgwg WG is making the = routing area not organised in terms of new-work/new-interest = approved by the area.

Routing Area WG helps close all other WGs = because this WG is open chartered as = any area's purpose. 

AB

On Tuesday, June = 24, 2014, Dearlove, Christopher (UK) wrote:

No mention of MANET in Joel=92s = analysis.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications = Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 = 242124

chris.dearlove@baesystems.com= | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace = Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

=
_______________________________________________routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion
=

= --Apple-Mail=_19F97026-0FFC-45CE-A58D-0A9BD0C2112A-- From nobody Mon Jun 30 04:50:08 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602791A0240 for ; Mon, 30 Jun 2014 04:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNH6J89kCK5s for ; Mon, 30 Jun 2014 04:50:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C9B1A023E for ; Mon, 30 Jun 2014 04:50:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJK46474; Mon, 30 Jun 2014 11:50:00 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 12:49:59 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 30 Jun 2014 19:49:55 +0800 From: Qin Wu To: Rob Shakir , Abdussalam Baryun Subject: RE: Routing Area organization Thread-Topic: Routing Area organization Thread-Index: AQHPlFTKzW0GX3+qAUKlRM+BW+fnF5uJhtQQ Date: Mon, 30 Jun 2014 11:49:54 +0000 Message-ID: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> In-Reply-To: <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8457B7D6nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/aOZD64bcuzTBZXPprM0OElTPsfg Cc: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 11:50:06 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8457B7D6nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBhbHNvIHRoaW5rIFJUR1dHIGlzIHZlcnkgdXNlZnVsIHdvcmtpbmcgZ3JvdXAuDQpTaW5jZSBJ IHNlZSBpdCBjYW4gaGFuZGxlIG5ldyB3b3JrIGFzIGZvbGxvd3M6DQoNCi0gICAgICAgICAgRGV2 ZWxvcGluZyB0aGUgbmV3IHdvcmsgcmVsYXRlZCB0byByb3V0aW5nIGFyZWEgYnV0IG5vdCBiZWxv bmcgdG8gYW55IGV4aXN0aW5nIHdvcmtpbmcgZ3JvdXBzDQoNCi0gICAgICAgICAgRGV2ZWxvcGlu ZyBhIHByb3Bvc2FsIGZvciBhIEJPRi4NCg0KLSAgICAgICAgICBEZXZlbG9waW5nIGEgY2hhcnRl ciBhbmQgZXN0YWJsaXNoaW5nIGNvbnNlbnN1cyBmb3IgYSBuZXcgV0cNCldvdWxkIGl0IGJlIGdv b2QgZm9yIHJ0Z3dnIHRvIGhlbHANCg0KLSAgICAgICAgICBEaXJlY3QgdGhlIHdvcmsgdG8gYW4g ZXhpc3RpbmcgV0cuDQphcyB3ZWxsPyBKdXN0IGxpa2UgT1BTIEFyZWEgaGFzIG9wc2F3ZyB3b3Jr aW5nIGdyb3VwIGFuZCBSQUkgYXJlYSBoYXMgZGlzcGF0Y2ggd29ya2luZyBncm91cC4NCg0KUmVn YXJkcyENCi1RaW4NCreivP7Iyzogcm91dGluZy1kaXNjdXNzaW9uIFttYWlsdG86cm91dGluZy1k aXNjdXNzaW9uLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUm9iIFNoYWtpcg0Kt6LLzcqxvOQ6IDIw MTTE6jbUwjI5yNUgMTk6NTYNCsrVvP7IyzogQWJkdXNzYWxhbSBCYXJ5dW4NCrOty806IGFkcmlh bkBvbGRkb2cuY28udWs7IHJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZw0K1vfM4jogUmU6IFJv dXRpbmcgQXJlYSBvcmdhbml6YXRpb24NCg0KQWJkdXNzYWxhbSwNCg0KTGlrZSBMb2EsIEmhr20g bm90IHRvbyBjbGVhciBvbiB0aGUgcG9pbnQgdGhhdCB5b3UgYXJlIG1ha2luZyBoZXJlLiBQZXJo YXBzIHlvdSBjYW4gY2xhcmlmeSBmb3IgdXM/DQoNCnJ0Z3dnIGRvZXMgYSB2YWx1YWJsZSBqb2Ig b2YgcGlja2luZyB1cCBpdGVtcyB0aGF0IGFyZSBub3QgbmVjZXNzYXJpbHkgcHJvdG9jb2wgc3Bl Y2lmaWMsIGJ1dCByZXF1aXJlIHN0YW5kYXJkaXNhdGlvbi4gVGhlIHdvcmsgb24gY29tcG9zaXRl IGxpbmtzLCBhbmQgSVAgRlJSIGFyZSBnb29kIGV4YW1wbGVzIG9mIHRoaXMuIEluIGFkZGl0aW9u IC0gaXQgcHJvdmlkZXMgdGhlIGh1Z2VseSB2YWx1YWJsZSByb2xlcyBvZiBhbGxvd2luZyBvcGVy YXRpb25hbCBjb25zaWRlcmF0aW9ucyBmb3Igd2lkZXIgcm91dGluZyBpc3N1ZXMgdG8gYmUgY29u c2lkZXJlZCwgYXMgd2VsbCBhcyB0aGUgaW50cm9kdWN0aW9uIGFuZCBldmFsdWF0aW9uIG9mIG5l dyBpZGVhcywgd2l0aG91dCBhIHNpZ25pZmljYW50IHByb2Nlc3Mgb3ZlcmhlYWQsIHdoaWNoIG1h eSBzdWJzZXF1ZW50bHkgYmUgYWRkZWQgdG8gYW4gZXhpc3RpbmcgV0ehr3MgY2hhcnRlciwgb3Ig cmVzdWx0IGluIGEgbmV3IFdHIGJlaW5nIGZvcm1lZC4NCg0KSSB3b3VsZCBzdHJvbmdseSBvcHBv c2UgY2xvc2luZyBydGd3Zy4NCg0KQ2hlZXJzLA0Kci4NCg0KDQpPbiAyOSBKdW4gMjAxNCwgYXQg MTE6MjQsIEFiZHVzc2FsYW0gQmFyeXVuIDxhYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbTxtYWls dG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQpJIHRoaW5rIHRoZSBt b3N0IGltcG9ydGFudCBtaXNzaW5nIGl0ZW0gKHRvIG9yZ2FuaXNlIHRoZSBhcmVhIGJ5IGZ1bmN0 aW9uYWxpdHkgYW5kIHF1YWxpdHkpIGlzIHRoZSByb3V0aW5nLWFyZWEtV0cgKHJ0Z3dnKSwgd2hp Y2ggSSBzdWdnZXN0IHNob3VsZCBiZSBjbG9zZWQsIGJlY2F1c2UgaXQgaXMgYSBnZW5lcmFsIGlu dGVyZXN0IGFuZCBub3Qgc3BlY2lmaWMsIG5vdCBjb21tdW5pdHktZ3JvdXBlZCwgYW5kIGRvZXMg bm90IGVuc3VyZSBxdWFsaXR5LiBIb3cgY2FuIGFuIGFyZWEgYmVjb21lIGEgd29ya2luZyBncm91 cCBvciBhIFdHIGJlY29taW5nIGFuIEFyZWE/IElNSE8sIHRoaXMgcnRnd2cgV0cgaXMgbWFraW5n IHRoZSByb3V0aW5nIGFyZWEgbm90IG9yZ2FuaXNlZCBpbiB0ZXJtcyBvZiBuZXctd29yay9uZXct aW50ZXJlc3QgYXBwcm92ZWQgYnkgdGhlIGFyZWEuDQoNClJvdXRpbmcgQXJlYSBXRyBoZWxwcyBj bG9zZSBhbGwgb3RoZXIgV0dzIGJlY2F1c2UgdGhpcyBXRyBpcyBvcGVuIGNoYXJ0ZXJlZCBhcyBh bnkgYXJlYSdzIHB1cnBvc2UuDQoNCkFCDQoNCk9uIFR1ZXNkYXksIEp1bmUgMjQsIDIwMTQsIERl YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIHdyb3RlOg0KTm8gbWVudGlvbiBvZiBNQU5FVCBpbiBK b2Vsoa9zIGFuYWx5c2lzLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmlu Y2lwYWwgRW5naW5lZXIsIENvbW11bmljYXRpb25zIEdyb3VwDQpDb21tdW5pY2F0aW9ucywgTmV0 d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCkJBRSBTeXN0ZW1zIEFkdmFuY2Vk IFRlY2hub2xvZ3kgQ2VudHJlDQpXZXN0IEhhbm5pbmdmaWVsZCBSb2FkLCBHcmVhdCBCYWRkb3cs IENoZWxtc2ZvcmQsIENNMiA4SE4sIFVLDQpUZWw6ICs0NCAxMjQ1IDI0MjE5NCB8ICBGYXg6ICs0 NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208amF2YXNjcmlwdDpf ZSglN0IlN0QsJ2N2bWwnLCdjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbScpOz4gfCBodHRw Oi8vd3d3LmJhZXN5c3RlbXMuY29tPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vPg0KDQpCQUUg U3lzdGVtcyAoT3BlcmF0aW9ucykgTGltaXRlZA0KUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sg SG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwgRmFybmJvcm91 Z2gsIEhhbnRzLCBHVTE0IDZZVSwgVUsNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5v OiAxOTk2Njg3DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kcm91dGluZy1kaXNjdXNzaW9uIG1haWxpbmcgbGlzdA0Kcm91dGluZy1kaXNjdXNzaW9uQGll dGYub3JnPG1haWx0bzpyb3V0aW5nLWRpc2N1c3Npb25AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvdXRpbmctZGlzY3Vzc2lvbg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA8457B7D6nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I also thi= nk RTGWG is very useful working group.

Since I se= e it can handle new work as follows:

-De= veloping the new work related to routing area but not belong to any existin= g working groups

-De= veloping a proposal for a BOF.

-De= veloping a charter and establishing consensus for a new WG

Would it b= e good for rtgwg to help

-Di= rect the work to an existing WG.

as well? J= ust like OPS Area has opsawg working group and RAI area has dispatch workin= g group.

 = ;

Regards!

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: routing= -discussion [mailto:routing-discussion-bounces@ietf.org] =B4=FA= =B1=ED Rob Shakir
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C229=C8=D5 19:56
=CA=D5=BC=FE=C8=CB: Abdussalam Baryun
=B3=AD=CB=CD: adrian@olddog.co.uk; routing-discussion@ietf.org
=D6=F7=CC=E2: Re: Routing Area organization

 

Abdussalam,

 

Like Loa, I=A1=AFm not too clea= r on the point that you are making here. Perhaps you can clarify for us?

 

rtgwg does a valuable job of pi= cking up items that are not necessarily protocol specific, but require stan= dardisation. The work on composite links, and IP FRR are good examples of t= his. In addition - it provides the hugely valuable roles of allowing operational considerations for wider routing is= sues to be considered, as well as the introduction and evaluation of new id= eas, without a significant process overhead, which may subsequently be adde= d to an existing WG=A1=AFs charter, or result in a new WG being formed.

 

I would strongly oppose closing= rtgwg.

 

Cheers,

r.

 

 



I think the most important miss= ing item (to organise the area by functionality and quality) = ;is the routing-area-WG (rtgwg), which I suggest should be closed, because = it is a general interest and not specific, not community-grouped, and does not ensure quality. How can an area become a working group o= r a WG becoming an Area? IMHO, this rtgwg WG is making the routin= g area not organised in terms of new-work/new-interest approved by&nbs= p;the area.

 

Routing Area WG helps = ;close all other WGs because this WG is open chartered as any area's&n= bsp;purpose. 

AB


On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote:

No mention of MANET in J= oel=A1=AFs analysis.

 

--

Christopher Dearlove

Senior Principal Enginee= r, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

_______________________________= ________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https:= //www.ietf.org/mailman/listinfo/routing-discussion

 

--_000_B8F9A780D330094D99AF023C5877DABA8457B7D6nkgeml501mbschi_-- From nobody Mon Jun 30 06:32:30 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1EA1A030D for ; Mon, 30 Jun 2014 06:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miRSVee3Ft59 for ; Mon, 30 Jun 2014 06:32:27 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B021A0309 for ; Mon, 30 Jun 2014 06:32:27 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id a41so4858492yho.16 for ; Mon, 30 Jun 2014 06:32:26 -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=Ij0ukRxko2fvH7X30iRbEZN3uWhIOjS6pd+1NoxjJNQ=; b=IH88WVqawcLf2spjFeHencuWkA1TSCOauj/h08Hc5i0Dx8DU/b4ykID2IaHNRenbCB Up5VYfa1JGG+5Sfz4BAuJ21SYeUwo9D0TfYCLhvMHQS/EYCY8hgkPf1QWo/qATrtTIYR TMd+3NyLveeJ0InK7CV8oyVD22M9jm2tbdjSGtg29xomQ5p3U1uPaNDPa92AmxL9XdON m2GMB/i6IsiM3UU7xB6huVMlKLZz7VJpEJX4TH5IqIRXCLIPQVVubpSK9RobA3O3nBJ2 3hgAsCdmbhaxxmjIrcIpfdRtuI84WYNX8cxcW1Vo0kf6S1hwHFYFIWGaNhV2xaiknG3i o69Q== MIME-Version: 1.0 X-Received: by 10.236.66.70 with SMTP id g46mr2791164yhd.159.1404135146283; Mon, 30 Jun 2014 06:32:26 -0700 (PDT) Received: by 10.170.194.19 with HTTP; Mon, 30 Jun 2014 06:32:26 -0700 (PDT) In-Reply-To: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> Date: Mon, 30 Jun 2014 14:32:26 +0100 Message-ID: Subject: Re: FW: Routing Area organization From: Abdussalam Baryun To: Qin Wu Content-Type: multipart/alternative; boundary=089e013a160e9c688504fd0db070 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/UB74yyhPFdOxE70HcYUyAviIcxI Cc: "adrian@olddog.co.uk" , Rob Shakir , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 13:32:29 -0000 --089e013a160e9c688504fd0db070 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Qin and Rob, Please don't misunderstand me, I am trying to discuss improving the area organisation, I was not discussing improving WG organisation, because as I said before all our WG have no problems and they are doing well. Please read the point number 4 from first restructure-statements of Alia and Adrian, I think the ADs agree to replace rtgwg WG with another more functional in process so that we can have more clear charters as well. AB On Monday, June 30, 2014, Qin Wu wrote: > I also think RTGWG is very useful working group. > > Since I see it can handle new work as follows: > > - Developing the new work related to routing area but not belong > to any existing working groups > > - Developing a proposal for a BOF. > > - Developing a charter and establishing consensus for a new WG > > Would it be good for rtgwg to help > > - Direct the work to an existing WG. > > as well? Just like OPS Area has opsawg working group and RAI area has > dispatch working group. > > > > Regards! > > -Qin > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* routing-discussion [mailto:routing-discuss= ion-bounces@ietf.org > ] *= =E4=BB=A3=E8=A1=A8 > *Rob Shakir > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2014=E5=B9=B46=E6=9C=8829=E6=97= =A5 19:56 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Abdussalam Baryun > *=E6=8A=84=E9=80=81:* adrian@olddog.co.uk > ; > routing-discussion@ietf.org > > *=E4=B8=BB=E9=A2=98:* Re: Routing Area organization > > > > Abdussalam, > > > > Like Loa, I=E2=80=99m not too clear on the point that you are making here= . Perhaps > you can clarify for us? > > > > rtgwg does a valuable job of picking up items that are not necessarily > protocol specific, but require standardisation. The work on composite > links, and IP FRR are good examples of this. In addition - it provides th= e > hugely valuable roles of allowing operational considerations for wider > routing issues to be considered, as well as the introduction and evaluati= on > of new ideas, without a significant process overhead, which may > subsequently be added to an existing WG=E2=80=99s charter, or result in a= new WG > being formed. > > > > I would strongly oppose closing rtgwg. > > > > Cheers, > > r. > > > > > > On 29 Jun 2014, at 11:24, Abdussalam Baryun > wrote: > > > > I think the most important missing item (to organise the area > by functionality and quality) is the routing-area-WG (rtgwg), which I > suggest should be closed, because it is a general interest and not > specific, not community-grouped, and does not ensure quality. How can an > area become a working group or a WG becoming an Area? IMHO, this rtgwg WG > is making the routing area not organised in terms of new-work/new-interes= t > approved by the area. > > > > Routing Area WG helps close all other WGs because this WG is open > chartered as any area's purpose. > > AB > > > On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote: > > No mention of MANET in Joel=E2=80=99s analysis. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > > https://www.ietf.org/mailman/listinfo/routing-discussion > > > --089e013a160e9c688504fd0db070 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Qin and Rob,

Please don't misunderstand me, I am = trying to discuss improving the area organisation, I was not discussing imp= roving WG organisation,=C2=A0because as I said before all our WG have no pr= oblems and they are doing well. Please read the point number 4 from first r= estructure-statements of=C2=A0Alia and Adrian, I think the ADs agree to rep= lace rtgwg WG=C2=A0with another more functional in process so that we can h= ave more clear charters as well.=C2=A0

AB

On Monday, June 30, 2014, Qin Wu wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

I also thi= nk RTGWG is very useful working group.

Since I se= e it can handle new work as follows:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Devel= oping the new work related to routing area but not belong to any existing w= orking groups

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Devel= oping a proposal for a BOF.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Devel= oping a charter and establishing consensus for a new WG

Would it b= e good for rtgwg to help

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Direc= t the work to an existing WG.

as well? J= ust like OPS Area has opsawg working group and RAI area has dispatch workin= g group.

=C2= =A0

Regards!

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA: routing-discussion [mailto:routing-discussion-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Rob Shakir
= =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B46=E6=9C=8829=E6=97=A5 19:56
=E6=94=B6=E4=BB=B6=E4=BA=BA: Abdussalam Baryun
=E6=8A=84=E9=80=81: adrian@olddog.co.uk; routing-discussion@ietf.org
=E4=B8=BB=E9=A2=98: Re: Routing Area organization

=C2=A0

Abdussalam,

=C2=A0

Like Loa, I=E2=80=99m not too c= lear on the point that you are making here. Perhaps you can clarify for us?=

=C2=A0

rtgwg does a valuable job of pi= cking up items that are not necessarily protocol specific, but require stan= dardisation. The work on composite links, and IP FRR are good examples of t= his. In addition - it provides the hugely valuable roles of allowing operational considerations for wider routing is= sues to be considered, as well as the introduction and evaluation of new id= eas, without a significant process overhead, which may subsequently be adde= d to an existing WG=E2=80=99s charter, or result in a new WG being formed.

=C2=A0

I would strongly oppose closing= rtgwg.

=C2=A0

Cheers,

r.

=C2=A0

=C2=A0

On 29 Jun 2014, at 11:24, Abdus= salam Baryun <abdussalambaryun@gmail.com> wrote:



I think the most important miss= ing item (to organise the=C2=A0area by=C2=A0functionality and quality)=C2= =A0is the routing-area-WG (rtgwg), which I suggest should be closed, becaus= e it is a general interest=C2=A0and not specific, not community-grouped, and does not ensure quality.=C2=A0How can an area become a working group o= r a WG becoming an Area? IMHO, this=C2=A0rtgwg=C2=A0WG is making the routin= g=C2=A0area not organised in terms of new-work/new-interest approved by=C2= =A0the area.

=C2=A0

_______________________________= ________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion=

=C2=A0

--089e013a160e9c688504fd0db070-- From nobody Mon Jun 30 06:53:18 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF071A0344 for ; Mon, 30 Jun 2014 06:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV3om7YyN2i4 for ; Mon, 30 Jun 2014 06:53:13 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6AE1A0338 for ; Mon, 30 Jun 2014 06:53:13 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 142so4653055ykq.3 for ; Mon, 30 Jun 2014 06:53:13 -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=lQB8otHItPjknmwxBgcU2o30iUVP2gsSET7h/7+CUNQ=; b=Y/VnoXOk5mFL3AXVu9IUgVPlnLa32xnvdozT1C4CC+3Q//uJcgstK8rPZzw5RHuLpm sHMLw/mQ1KtcglCMWpnGRY+Qx9Ia9UgCh5El3RBEmqbcVDrOl/R7G8RUblbw8GYXLBeV tdhBFVnHbZBwUI/FqO4eA+s5F2+eMvPxKr7thU1RDDUZQLRsMzvXqqfuM9T6vjiAFySf dsxKJjkCFgL7td2ne44U3CV1+PXw3/xqi6fc9yhool9NXqxZIInMGsoEzHlJvJTbhDjT 9YaPJ8rZ74+I0r/nWzPW5Myf/M9gZ3Mqs0kSVN2YXATEC/dm5zeaL5VzM8ZnTLq80h5Y 02NA== MIME-Version: 1.0 X-Received: by 10.236.191.74 with SMTP id f50mr42559047yhn.9.1404136393074; Mon, 30 Jun 2014 06:53:13 -0700 (PDT) Received: by 10.170.194.19 with HTTP; Mon, 30 Jun 2014 06:53:12 -0700 (PDT) In-Reply-To: <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> Date: Mon, 30 Jun 2014 14:53:12 +0100 Message-ID: Subject: Re: FW: Routing Area organization From: Abdussalam Baryun To: Rob Shakir Content-Type: multipart/alternative; boundary=20cf303f6996eced7104fd0dfaad Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/5wPihSfSVN-O4tV-Yn7Caj5aMQo Cc: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 13:53:17 -0000 --20cf303f6996eced7104fd0dfaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rob, My point was to make our area work more clear and ensure quality. Is there another way to handle the routing area's new work issues? Is the only solution is having a WG to solve that as rtgwg? I was thinking of a different solution than having a general purpose WG, but a DT. I thought what is important to solve new standards process in the area is not a General WG problem but it is a DT problem. So we use list for DT or the same rtgwg list for discussing all new work unrelated-to-area-current-WGs coming in the Routing Area. The new work after DT approves becomes an individual area work. Just my thoughts and trying to improve the organisation. I maybe wrong. AB On Sunday, June 29, 2014, Rob Shakir wrote: > Abdussalam, > > Like Loa, I=E2=80=99m not too clear on the point that you are making here= . Perhaps > you can clarify for us? > > rtgwg does a valuable job of picking up items that are not necessarily > protocol specific, but require standardisation. The work on composite > links, and IP FRR are good examples of this. In addition - it provides th= e > hugely valuable roles of allowing operational considerations for wider > routing issues to be considered, as well as the introduction and evaluati= on > of new ideas, without a significant process overhead, which may > subsequently be added to an existing WG=E2=80=99s charter, or result in a= new WG > being formed. > > I would strongly oppose closing rtgwg. > > Cheers, > r. > > > On 29 Jun 2014, at 11:24, Abdussalam Baryun > wrote: > > I think the most important missing item (to organise the area > by functionality and quality) is the routing-area-WG (rtgwg), which I > suggest should be closed, because it is a general interest and not > specific, not community-grouped, and does not ensure quality. How can an > area become a working group or a WG becoming an Area? IMHO, this rtgwg WG > is making the routing area not organised in terms of new-work/new-interes= t > approved by the area. > > Routing Area WG helps close all other WGs because this WG is open > chartered as any area's purpose. > > AB > > On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote: > >> No mention of MANET in Joel=E2=80=99s analysis. >> >> >> >> -- >> >> Christopher Dearlove >> >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> BAE Systems (Operations) Limited >> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace >> Centre, Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > > https://www.ietf.org/mailman/listinfo/routing-discussion > > > --20cf303f6996eced7104fd0dfaad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rob,

My point was=C2=A0to make our area=C2=A0work mor= e clear and ensure quality.=C2=A0Is there another way to handle the routing= area's new work issues? Is the only solution is having a WG to solve t= hat as rtgwg? I was thinking of a different solution than having a general = purpose=C2=A0WG, but a DT.=C2=A0

I thought what=C2=A0is important to solve new standards= process in the area is not a General WG problem but it is=C2=A0a DT proble= m. So we use list for=C2=A0DT or=C2=A0the same rtgwg=C2=A0list for discussi= ng all new work unrelated-to-area-current-WGs=C2=A0coming in the=C2=A0Routi= ng Area. The new work after DT approves becomes an individual area work.=C2= =A0

Just my thoughts=C2=A0and trying to improve the organis= ation. I maybe wrong.=C2=A0

AB

On Sunday, J= une 29, 2014, Rob Shakir wrote:
Abdussalam,

Like Loa= , I=E2=80=99m not too clear on the point that you are making here. Perhaps = you can clarify for us?

rtgwg does a valuable job = of picking up items that are not necessarily protocol specific, but require= standardisation. The work on composite links, and IP FRR are good examples= of this. In addition - it provides the hugely valuable roles of allowing o= perational considerations for wider routing issues to be considered, as wel= l as the introduction and evaluation of new ideas, without a significant pr= ocess overhead, which may subsequently be added to an existing WG=E2=80=99s= charter, or result in a new WG being formed.

I would strongly oppose closing rtgwg.

Cheers,
r.


On 29 = Jun 2014, at 11:24, Abdussalam Baryun <abd= ussalambaryun@gmail.com> wrote:

I think the most important missing item (to o= rganise the=C2=A0area by=C2=A0functionality and quality)=C2=A0is the routin= g-area-WG (rtgwg), which I suggest should be closed, because it is a genera= l interest=C2=A0and not specific, not community-grouped, and does not ensur= e quality.=C2=A0How can an area become a working group or a WG becoming an = Area? IMHO, this=C2=A0rtgwg=C2=A0WG is making the routing=C2=A0area not org= anised in terms of new-work/new-interest approved by=C2=A0the area.

Routing Area=C2=A0WG helps=C2=A0close all other WGs because = this WG is open chartered as any=C2=A0area's=C2=A0purpose.=C2=A0
AB

On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote:

No mention of MANET = in Joel=E2=80=99s analysis.

= =C2=A0

--

= Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=C2=A0|=C2=A0 Fax: +44 1245 242124=

chris.dearlove@baesystems.com | http://www.baes= ystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

_______________________________________________routing-discussion mailing list
routing-= discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion

--20cf303f6996eced7104fd0dfaad-- From nobody Mon Jun 30 07:16:38 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A411A035D for ; Mon, 30 Jun 2014 07:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24Gt_zK38-e7 for ; Mon, 30 Jun 2014 07:16:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB761A0358 for ; Mon, 30 Jun 2014 07:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12437; q=dns/txt; s=iport; t=1404137793; x=1405347393; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J9HOD/ayuY5JG6vZ4Ovw4h2PBkH25QuAR+VHEBrqOQg=; b=Edk6wcmJraTDiSX+/kDdOrUcX8+a2bSCj54tgq4rfJi/TcYyB/wWfKe7 U6ESNE0uzzXDSHCvjMGI5eBdpnKkie1MkgEjAwMaGIAWPPod/6Vvv9NIZ 2ozVyzO81FYPztTH6t/JE8S/I01v7BscclnRyL6KMAVfAsuN3sPbXCGdT Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHAHRwsVOtJA2B/2dsb2JhbABagkZHUlqrGAEBAQEBAQUBbgGSBgGGbFMBgQsWdYQEAQEEAQEBUhkLEAIBCAc4ByEGCxQRAgQOBRQHiBMDEQ3AUA2GUhQDBoVehnyBRQoHAUwEBwmDJIEWBYYRkk+Bfo1rhhKDQoFuCRci X-IronPort-AV: E=Sophos;i="5.01,575,1400025600"; d="scan'208,217";a="336702957" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jun 2014 14:16:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5UEGUJo032574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 14:16:31 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.222]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 09:16:30 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Subject: Re: Routing Area organization Thread-Topic: Routing Area organization Thread-Index: AQHPlG3jO6ilB1Z9d0SlYZ+qu8FSeA== Date: Mon, 30 Jun 2014 14:16:30 +0000 Message-ID: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: multipart/alternative; boundary="_000_CF649FF593DF410687509696D34D00A0ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/ilV4XobJh3eJg3TlMVjfeu0VIRA Cc: "adrian@olddog.co.uk" , Rob Shakir , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 14:16:35 -0000 --_000_CF649FF593DF410687509696D34D00A0ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rob, The point I took from the email is that it's difficult to tell what the rtg= wg is supposed to do (at least from the name). Calling it the "Routing Area= Working Group" seems less like a name, and more like throwing IETF keyword= s against the wall until a sufficient number of them stick together. ;-) I admit, I don't have a proposal here, although if one is necessary, we cou= ld borrow your text and call it the "Picking up items that are not necessar= ily protocol specific, but require standardization" Working Group. One obvi= ous downside would be the length of the spiffy group-name acronym, I guess.= ;-) One other thing from your email caught my attention, and I was wondering if= I could get some clarification. You state the WG is partially for "...as w= ell as the introduction and evaluation of new ideas=85". Isn't the introduc= tion and evaluation of new work part of *all* of the working groups? Or (an= d this is addressed to the ADs), has something changed that we all need to = be aware of? Regards, Stan On Jun 30, 2014, at 9:53 AM, Abdussalam Baryun > wrote: Hi Rob, My point was to make our area work more clear and ensure quality. Is there = another way to handle the routing area's new work issues? Is the only solut= ion is having a WG to solve that as rtgwg? I was thinking of a different so= lution than having a general purpose WG, but a DT. I thought what is important to solve new standards process in the area is n= ot a General WG problem but it is a DT problem. So we use list for DT or th= e same rtgwg list for discussing all new work unrelated-to-area-current-WGs= coming in the Routing Area. The new work after DT approves becomes an indi= vidual area work. Just my thoughts and trying to improve the organisation. I maybe wrong. AB On Sunday, June 29, 2014, Rob Shakir wrote: Abdussalam, Like Loa, I=92m not too clear on the point that you are making here. Perhap= s you can clarify for us? rtgwg does a valuable job of picking up items that are not necessarily prot= ocol specific, but require standardisation. The work on composite links, an= d IP FRR are good examples of this. In addition - it provides the hugely va= luable roles of allowing operational considerations for wider routing issue= s to be considered, as well as the introduction and evaluation of new ideas= , without a significant process overhead, which may subsequently be added t= o an existing WG=92s charter, or result in a new WG being formed. I would strongly oppose closing rtgwg. Cheers, r. On 29 Jun 2014, at 11:24, Abdussalam Baryun > wrote: I think the most important missing item (to organise the area by functional= ity and quality) is the routing-area-WG (rtgwg), which I suggest should be = closed, because it is a general interest and not specific, not community-gr= ouped, and does not ensure quality. How can an area become a working group = or a WG becoming an Area? IMHO, this rtgwg WG is making the routing area no= t organised in terms of new-work/new-interest approved by the area. Routing Area WG helps close all other WGs because this WG is open chartered= as any area's purpose. AB On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote: No mention of MANET in Joel=92s analysis. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --_000_CF649FF593DF410687509696D34D00A0ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7171B32DB6543D4DB142CB2170DCEB44@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Rob, 

The point I took from the email is that it's difficult to tell what th= e rtgwg is supposed to do (at least from the name). Calling it the "Ro= uting Area Working Group" seems less like a name, and more like throwi= ng IETF keywords against the wall until a sufficient number of them stick together. ;-) 
I admit, I don't have a proposal here, although if one is necessary, w= e could borrow your text and call it the "Picking up items that are no= t necessarily protocol specific, but require standardization" Working = Group. One obvious downside would be the length of the spiffy group-name acronym, I guess. ;-)

One other thing from your email caught my attention, and I was wonderi= ng if I could get some clarification. You state the WG is partially for &qu= ot;...as well as the introduction and evaluation of new ideas=85". Isn= 't the introduction and evaluation of new work part of *all* of the working groups? Or (and this is addressed to the ADs)= , has something changed that we all need to be aware of?

Regards,
Stan


On Jun 30, 2014, at 9:53 AM, Abdussalam Baryun <abdussalambaryun@gmail.com>
 wrote:

Hi Rob,

My point was to make our area work more clear and ensure qua= lity. Is there another way to handle the routing area's new work issue= s? Is the only solution is having a WG to solve that as rtgwg? I was thinki= ng of a different solution than having a general purpose WG, but a DT. 

I thought what is important to solve new standards process in the= area is not a General WG problem but it is a DT problem. So we use li= st for DT or the same rtgwg list for discussing all new work= unrelated-to-area-current-WGs coming in the Routing Area. The new work after DT approves becomes an individual area work. 

Just my thoughts and trying to improve the organisation. I maybe = wrong. 

AB

On Sunday, June 29, 2014, Rob Shakir wrote:
Abdussalam,

Like Loa, I=92m not too clear on the point that you are making here. P= erhaps you can clarify for us?

rtgwg does a valuable job of picking up items that are not necessarily= protocol specific, but require standardisation. The work on composite link= s, and IP FRR are good examples of this. In addition - it provides the huge= ly valuable roles of allowing operational considerations for wider routing issues to be considered, as well as the i= ntroduction and evaluation of new ideas, without a significant process over= head, which may subsequently be added to an existing WG=92s charter, or res= ult in a new WG being formed.

I would strongly oppose closing rtgwg.

Cheers,
r.


On 29 Jun 2014, at 11:24, Abdussalam Baryun <abdussal= ambaryun@gmail.com> wrote:

I think the most important missing item (to organ= ise the area by functionality and quality) is the routing-ar= ea-WG (rtgwg), which I suggest should be closed, because it is a general in= terest and not specific, not community-grouped, and does not ensure quality. How can an area become a working group or a = WG becoming an Area? IMHO, this rtgwg WG is making the routing&nb= sp;area not organised in terms of new-work/new-interest approved by th= e area.

Routing Area WG helps close all other WGs because this WG is= open chartered as any area's purpose. 

AB

On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote:

No mention of MANET in Jo= el=92s analysis.

 

--

Christopher Dearlove

Senior Principal Engineer= , Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesyst= ems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www.ietf.org/mailman/listinfo/routing-discussion

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion

--_000_CF649FF593DF410687509696D34D00A0ciscocom_-- From nobody Mon Jun 30 07:33:01 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D3C1A0347 for ; Mon, 30 Jun 2014 07:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpG_LeDpfRYA for ; Mon, 30 Jun 2014 07:28:53 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A4F1A0343 for ; Mon, 30 Jun 2014 07:28:52 -0700 (PDT) Received: from [109.144.197.44] (helo=[10.210.203.248]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1X1cZd-0004p1-UN; Mon, 30 Jun 2014 15:28:49 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Routing Area organization From: Rob Shakir In-Reply-To: Date: Mon, 30 Jun 2014 15:28:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/25oyEzB82XF_yO2LkAwhUkKRROI X-Mailman-Approved-At: Mon, 30 Jun 2014 07:33:00 -0700 Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 14:28:55 -0000 Hi Stan, I agree, maybe a re-branding could be required. :-)=20 On 30 Jun 2014, at 15:16, Stan Ratliff (sratliff) = wrote: > One other thing from your email caught my attention, and I was = wondering if I could get some clarification. You state the WG is = partially for "...as well as the introduction and evaluation of new = ideas=85". Isn't the introduction and evaluation of new work part of = *all* of the working groups? Or (and this is addressed to the ADs), has = something changed that we all need to be aware of? Of course, I guess I meant things that don=92t clearly fit within the = other working groups. If I have a new BGP idea, of course this would go = to IDR. However, I think the value is that rtgwg allows other ideas (for = example, SPRING, MRT, IP FRR) which might have cross-WG impact or maybe = don=92t look like they require a whole new WG to be introduced to an = audience which includes a number of cross-routing area experts. Does this make sense? :-) r. From nobody Mon Jun 30 07:44:15 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E4C1A036A for ; Mon, 30 Jun 2014 07:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBgIdPG87-pS for ; Mon, 30 Jun 2014 07:44:12 -0700 (PDT) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444351A036C for ; Mon, 30 Jun 2014 07:44:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id 3E8FED407B3; Mon, 30 Jun 2014 07:44:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-22.clppva.east.verizon.net [70.106.134.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id A54D9D40563; Mon, 30 Jun 2014 07:44:09 -0700 (PDT) Message-ID: <53B177BA.4080204@joelhalpern.com> Date: Mon, 30 Jun 2014 10:44:10 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" , Abdussalam Baryun Subject: Re: Routing Area organization References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/olwd03w8K5SwgSXiCnJhPlykFYE Cc: "adrian@olddog.co.uk" , Rob Shakir , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 14:44:14 -0000 Following the lead of RAI< we could call it Routing Dispatcher instead of RTGWG, if that would help folks understand it better. Yours, Joel On 6/30/14, 10:16 AM, Stan Ratliff (sratliff) wrote: > Rob, > > The point I took from the email is that it's difficult to tell what the > rtgwg is supposed to do (at least from the name). Calling it the > "Routing Area Working Group" seems less like a name, and more like > throwing IETF keywords against the wall until a sufficient number of > them stick together. ;-) > I admit, I don't have a proposal here, although if one is necessary, we > could borrow your text and call it the "Picking up items that are not > necessarily protocol specific, but require standardization" Working > Group. One obvious downside would be the length of the spiffy group-name > acronym, I guess. ;-) > > One other thing from your email caught my attention, and I was wondering > if I could get some clarification. You state the WG is partially for > "...as well as the introduction and evaluation of new ideas…". Isn't the > introduction and evaluation of new work part of *all* of the working > groups? Or (and this is addressed to the ADs), has something changed > that we all need to be aware of? > > Regards, > Stan > > > On Jun 30, 2014, at 9:53 AM, Abdussalam Baryun > > > wrote: > >> Hi Rob, >> >> My point was to make our area work more clear and ensure quality. Is >> there another way to handle the routing area's new work issues? Is the >> only solution is having a WG to solve that as rtgwg? I was thinking of >> a different solution than having a general purpose WG, but a DT. >> >> I thought what is important to solve new standards process in the area >> is not a General WG problem but it is a DT problem. So we use list >> for DT or the same rtgwg list for discussing all new work >> unrelated-to-area-current-WGs coming in the Routing Area. The new work >> after DT approves becomes an individual area work. >> >> Just my thoughts and trying to improve the organisation. I maybe wrong. >> >> AB >> >> On Sunday, June 29, 2014, Rob Shakir wrote: >> >> Abdussalam, >> >> Like Loa, I’m not too clear on the point that you are making here. >> Perhaps you can clarify for us? >> >> rtgwg does a valuable job of picking up items that are not >> necessarily protocol specific, but require standardisation. The >> work on composite links, and IP FRR are good examples of this. In >> addition - it provides the hugely valuable roles of allowing >> operational considerations for wider routing issues to be >> considered, as well as the introduction and evaluation of new >> ideas, without a significant process overhead, which may >> subsequently be added to an existing WG’s charter, or result in a >> new WG being formed. >> >> I would strongly oppose closing rtgwg. >> >> Cheers, >> r. >> >> >> On 29 Jun 2014, at 11:24, Abdussalam Baryun >> > > wrote: >> >>> I think the most important missing item (to organise the area >>> by functionality and quality) is the routing-area-WG (rtgwg), >>> which I suggest should be closed, because it is a general >>> interest and not specific, not community-grouped, and does not >>> ensure quality. How can an area become a working group or a WG >>> becoming an Area? IMHO, this rtgwg WG is making the routing area >>> not organised in terms of new-work/new-interest approved by the >>> area. >>> >>> Routing Area WG helps close all other WGs because this WG is open >>> chartered as any area's purpose. >>> >>> AB >>> >>> On Tuesday, June 24, 2014, Dearlove, Christopher (UK) wrote: >>> >>> No mention of MANET in Joel’s analysis.____ >>> >>> __ __ >>> >>> -- ____ >>> >>> Christopher Dearlove____ >>> >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124____ >>> >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough >>> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>> >>> _______________________________________________ >>> routing-discussion mailing list >>> routing-discussion@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/routing-discussion >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > From nobody Mon Jun 30 07:57:32 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3561A0367 for ; Mon, 30 Jun 2014 07:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67yhXS71jNfH for ; Mon, 30 Jun 2014 07:57:29 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6BA1A035C for ; Mon, 30 Jun 2014 07:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3121; q=dns/txt; s=iport; t=1404140250; x=1405349850; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C0Yo4uwoZVIM22IcYlBwhY5vRSksxOWXNiLz0bBGoZo=; b=LoVg9kI2X0CRzfg8C8UjRQG3v3rzpEhPLoYaR6k4P6ei8T9V5I7Wfi9h SUM7grgr8pvgt4/l5GLi6EWH5yh/UxSjq1KF2dCpKBVUMEFJ6xGNTKKEV Yq9PhyIK7XPRN3Hl//nJ2WZtLjWyif2btGoxiR+nAug+IRuf0cFWSn4kW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYHAFB6sVOtJV2d/2dsb2JhbABagw2BLKsZAQEBAQEBBQFuAZlGAYENFnWEAwEBAQMBawcHBQsCAQgOCi4yJQIEDgUbiB8Ix0YXhWSIQREBAhszB4MtgRYFml6TfYNCgXc5 X-IronPort-AV: E=Sophos;i="5.01,575,1400025600"; d="scan'208";a="336794851" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 30 Jun 2014 14:57:29 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5UEvS35008533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 14:57:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.222]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 09:57:27 -0500 From: "Stan Ratliff (sratliff)" To: Rob Shakir Subject: Re: Routing Area organization Thread-Topic: Routing Area organization Thread-Index: AQHPlG3jO6ilB1Z9d0SlYZ+qu8FSeJuKCiqAgAAIAQA= Date: Mon, 30 Jun 2014 14:57:26 +0000 Message-ID: <455C5628-DDDB-4C65-93C0-6FAFB27BC3DF@cisco.com> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <2F385896-4AA9-4EC8-954D-CBA1BCEB0868@rob.sh> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.190] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0193FAB1DE6DA540B0690D01B66302CA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/ZNbCDN2ov-BIgZDV0YrAFtjTLbk Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 14:57:31 -0000 Rob,=20 On Jun 30, 2014, at 10:28 AM, Rob Shakir wrote: > Hi Stan, >=20 > I agree, maybe a re-branding could be required. :-)=20 >=20 > On 30 Jun 2014, at 15:16, Stan Ratliff (sratliff) wr= ote: >=20 >> One other thing from your email caught my attention, and I was wondering= if I could get some clarification. You state the WG is partially for "...a= s well as the introduction and evaluation of new ideas=85". Isn't the intro= duction and evaluation of new work part of *all* of the working groups? Or = (and this is addressed to the ADs), has something changed that we all need = to be aware of? >=20 > Of course, I guess I meant things that don=92t clearly fit within the oth= er working groups. If I have a new BGP idea, of course this would go to IDR= . However, I think the value is that rtgwg allows other ideas (for example,= SPRING, MRT, IP FRR) which might have cross-WG impact or maybe don=92t loo= k like they require a whole new WG to be introduced to an audience which in= cludes a number of cross-routing area experts. >=20 > Does this make sense? :-) >=20 > r. >=20 That absolutely makes sense, and I agree. However, it does bring up an oppo= rtunity for me to crawl up on the old, rickety soapbox, and discuss somethi= ng that bothers me about the routing area, and the IETF in general:=20 I'm absolutely in agreement that we need ways to support and foster innovat= ion. That said, I think we're organized into too many silos, with work that= is 90% overlapping occurring in different working groups. The best example= I can provide for that is ROLL and MANET. We had a lengthy discussion on t= he MANET list not that long ago on the topic "When is a low-power, radio-ba= sed, ad-hoc forming network *not* a MANET? The answer was: Basically, when = it's a ROLL network." Another example along the same vein is the "ITS" work= ing group that is trying to form in the Internet Area - they are concerned = with putting networking gear into vehicles, forming "on-the-move", ad-hoc r= outing relationships, and opportunistically getting the best out of the net= work. However, instead of doing that work in ROLL (they are relatively low-= power, radio-based, after all) or in MANET (did I mention ad-hoc? ;-) group= s, the IETF is seeing fit to create yet another WG.=20 This is all just IMHO, but it seems to me that this has more to do with pol= itics (both inter-personal and inter-company), and less to do with technolo= gy. And I can't help but think that in the end, we will wind up with a plet= hora of solutions that won't interoperate. There might be job security in t= hat we'll need a whole additional layer of RFCs to "glue" things together (= e.g. - a RPL to OLSRv2 interoperability spec comes to mind), but that appro= ach gives me the willies. Again, we need to foster innovation, but avoid re= -addressing what is basically the same set of issues over and over again, c= oming up with "standard silos". =85easing my rather large fanny off of the soapbox for now=85=20 Regards, Stan= From nobody Mon Jun 30 09:35:08 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F1F1A03CF for ; Mon, 30 Jun 2014 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.251 X-Spam-Level: X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PKn3PlfE85S for ; Mon, 30 Jun 2014 09:34:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268591A03BB for ; Mon, 30 Jun 2014 09:34:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJK71184; Mon, 30 Jun 2014 16:34:49 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 30 Jun 2014 17:34:48 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.95]) by dfweml704-chm.china.huawei.com ([169.254.6.218]) with mapi id 14.03.0158.001; Mon, 30 Jun 2014 09:34:46 -0700 From: Linda Dunbar To: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" Subject: RE: Routing Area organization Thread-Topic: Routing Area organization Thread-Index: AQFSmnyEPMMBa9dnJPneRdJ51F0Ld5x6I+yggAmlK3A= Date: Mon, 30 Jun 2014 16:34:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D6E6D0@dfweml701-chm.china.huawei.com> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> In-Reply-To: <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.88] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645D6E6D0dfweml701chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/Gy5FhHqlz0fzMR3uJCKS5baIlWA X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:35:00 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645D6E6D0dfweml701chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like Joel's suggestions. There are indeed a lot of similarities among L2V= PN/L3VPN/NVO3 The draft-ietf-nvo3-framework (that just pasted IETF last call) depicted th= e similar framework as L2VPN, except NV03 focusing on using IP as outer hea= der whereas L2VPN having MPLS as outer header. Besides consolidating the current WGs, hope the Routing area can start some= new initiatives that are different from existing mode of operations. As the industry is moving more towards open source, it can improve IETF's i= mpact to industry by having a WG to promote Proof of Concept projects that = engage multiple vendors and service providers. The Proof of Concept project= code can be the baseline protocol specification. By doing so, not only it promotes more collaboration among vendors/service = providers, it also helps improving the image of IETF being too slow image.. My two cents, Linda From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Be= half Of Adrian Farrel Sent: Tuesday, June 24, 2014 8:05 AM To: routing-discussion@ietf.org Subject: FW: Routing Area organization Forwarding with Joel's permission. From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: 23 June 2014 17:14 To: Alia Atlas; adrian@olddog.co.uk Subject: Routing Area organization (Feel free to circulate this if you think it is useful. I don't have the r= ight email addresses on this machine to send directly to the relevant parti= es.) In looking at the discussion of the routing area, it seems to me that the s= tarting premise is very important. I believe we all agree that we want a s= tructure that helps us produce useful RFCs to enable a stronger and more in= novative routing system that meets the real needs of the various kinds of o= perations to deliver Internet services. (I.e the general IETF goals.) The following are my rough thoughts on this topic, as input to the discussi= on. First, I take it as given that there may well be a better way to structure = the work. The structure we have is an outgrowth of years of accumulation. = It seems to me distinctly worth looking at whether looking at what changes= we can make, what they will accomplish,a nd if any of them are likely to i= mprove our working. Personally, I think this examination is long overdue. = Note that even if we decide that we like the current structure, it will st= ill have been worth looking and understanding why we are working the way we= are. One of the biggest problems I see is the number of times when work has to b= e presented in multiple working groups, and the drafts revised to address r= elated but disconnected concerns. This waste author energy and working gro= up time. This is a consequence of our feeling a need to control how protoc= ols evolve. And such control is necessary. But needs to be balanced with = other needs. Also we all become tourists very often even in working group= s we are interested in. Any arrangement of work other than treating the world as one working group = (which I hope we all agree would be a very bad idea) will need some cross-c= ommunciation between groups. But some arrangements produce better commonal= ity. Similarly, any arrangement will produce working groups where some of = the work is of less interest to some of the participants. But maybe we can= get better alignment? A couple of obvious examples. Anything that needs to be done in an IGP nee= ds to be done twice (fortunately, we no longer care about RIP.) Different = working groups all need to develop operations, adminsitration, and maintena= nce mechanisms. But that means they need to redevelop the common understan= ding of what the needs, known techniques, and hard questions are. So I think we would benefit from rearranging the deck chairs. I would try = to make the groups focus on external needs rather than on mechanism. I would start by merging the OSPF and ISIS working groups. I would also pull the OAM functions out of the various groups (BFD, MPLS, C= CAMP, ...) and create one place that can deal with OAM issues. I would probably then merge SPRING with core MPLS functioning. We have just closed KARP, and I would (unhappily, but I think necessarily) = close ForCES. I would either close ROLLand move the work into a common low power group in= another area, or make ti the common low power working group. I would merge IDR and SIDR. With the current SIDR work program, it no long= er makes sense to me to treat them as separate. I would look at merging L2vpn and l3vpn back together. And combining them = with NVO3. Probably also include PWE3 in that set, although that is a hard= er call and may be too different. I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would= fit well with other groups. Yours, Joel --_000_4A95BA014132FF49AE685FAB4B9F17F645D6E6D0dfweml701chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like Joel’s sugge= stions. There are indeed a lot of similarities among L2VPN/L3VPN/NVO3<= /o:p>

The draft-ietf-nvo3-frame= work (that just pasted IETF last call) depicted the similar framework as L2= VPN, except NV03 focusing on using IP as outer header whereas L2VPN having MPLS as outer header.

 <= /p>

Besides consolidating the= current WGs, hope the Routing area can start some new initiatives that are= different from existing mode of operations.

As the industry is moving= more towards open source, it can improve IETF’s impact to industry b= y having a WG to promote Proof of Concept projects that engage multiple vendors and service providers. The Proof of Concept project code = can be the baseline protocol specification.

 <= /p>

By doing so, not only it = promotes more collaboration among vendors/service providers, it also helps = improving the image of IETF being too slow image..

 <= /p>

My two cents,

 <= /p>

Linda

 <= /p>

 <= /p>

From: routing-= discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, June 24, 2014 8:05 AM
To: routing-discussion@ietf.org
Subject: FW: Routing Area organization

 

Forwarding= with Joel's permission.

 = ;

From: Joel Hal= pern [mailto:joel.halpern@eric= sson.com]
Sent: 23 June 2014 17:14
To: Alia Atlas; adrian@olddog= .co.uk
Subject: Routing Area organization

 

(Feel free to circulate th= is if you think it is useful.  I don't have the right email addresses = on this machine to send directly to the relevant parties.)

 

In looking at the discussi= on of the routing area, it seems to me that the starting premise is very im= portant.  I believe we all agree that we want a structure that helps us produce useful RFCs to enable a stronger and more innovative= routing system that meets the real needs of the various kinds of operation= s to deliver Internet services.  (I.e the general IETF goals.)

The following are my rough= thoughts on this topic, as input to the discussion.

 

First, I take it as given = that there may well be a better way to structure the work.  The struct= ure we have is an outgrowth of years of accumulation.  It seems to me distinctly worth looking at whether looking at what changes we can m= ake, what they will accomplish,a nd if any of them are likely to improve ou= r working.  Personally, I think this examination is long overdue. = ; Note that even if we decide that we like the current structure, it will still have been worth looking and understan= ding why we are working the way we are.

 

One of the biggest problem= s I see is the number of times when work has to be presented in multiple wo= rking groups, and the drafts revised to address related but disconnected concerns.  This waste author energy and working group ti= me.  This is a consequence of our feeling a need to control how protoc= ols evolve.  And such control is necessary.  But needs to be bala= nced with other needs.   Also we all become tourists very often even in working groups we are interested in.<= /p>

 

Any arrangement of work ot= her than treating the world as one working group (which I hope we all agree= would be a very bad idea) will need some cross-communciation between groups.  But some arrangements produce better commonality.&nb= sp; Similarly, any arrangement will produce working groups where some of th= e work is of less interest to some of the participants.  But maybe we = can get better alignment?

 

A couple of obvious exampl= es.  Anything that needs to be done in an IGP needs to be done twice (= fortunately, we no longer care about RIP.)  Different working groups all need to develop operations, adminsitration, and maintenance mechanisms= .  But that means they need to redevelop the common understanding of w= hat the needs, known techniques, and hard questions are.<= /p>

 

So I think we would benefi= t from rearranging the deck chairs.  I would try to make the groups fo= cus on external needs rather than on mechanism.

 

I would start by merging t= he OSPF and ISIS working groups. 

I would also pull the OAM = functions out of the various groups (BFD, MPLS, CCAMP, …) and create = one place that can deal with OAM issues.

I would probably then merg= e SPRING with core MPLS functioning.

We have just closed KARP, = and I would (unhappily, but I think necessarily) close ForCES.

I would either close ROLLa= nd move the work into a common low power group in another area, or make ti = the common low power working group.

I would merge IDR and SIDR= .  With the current SIDR work program, it no longer makes sense to me = to treat them as separate.

I would look at merging L2= vpn and l3vpn back together.  And combining them with NVO3.  Prob= ably also include PWE3 in that set, although that is a harder call and may be too different.

 

I would leave CCCAMP, PCE,= and PIM alone, as I am not seeing how they would fit well with other group= s.

 

Yours,

Joel

 

 

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645D6E6D0dfweml701chmchi_-- From nobody Mon Jun 30 10:33:20 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78331A0402 for ; Mon, 30 Jun 2014 10:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkUVtqjx52n9 for ; Mon, 30 Jun 2014 10:33:09 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A5C1A03FA for ; Mon, 30 Jun 2014 10:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14231; q=dns/txt; s=iport; t=1404149586; x=1405359186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=u6ZI5uM+79zV+0PQRK6bQQAIA54abDmCFJuoBMvYvM0=; b=EVi8fYp55RNs0gAXrM84/Qh1gKex4ZJaJOyBn10YPfNdizbJUbqfzDY5 aXOyX1gl49uqWFFXOZp96P3e0zqXo3cNWnT7zYTr6DfClxbSTxf7JadLm HaQ17VSpqJ4Gcduan0rKbAkfnjnLC/WpfkNB7Afe2lm4Y0r7CjlUfaFw/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIHAPqdsVOtJA2J/2dsb2JhbABagkZHUk0NqxoBAQEBAQEFAW4BkgYBhmxTAYERFnWEBAEBBAEBAWsLEAIBCD8HJwsUEQIEDgWIQg3IKhMEhWSIVU4Hgy2BFgWaXpN9g0KCMA X-IronPort-AV: E=Sophos; i="5.01,576,1400025600"; d="scan'208,217"; a="57185759" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 30 Jun 2014 17:33:05 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5UHX5jS002659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 17:33:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.80]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 12:33:05 -0500 From: "Carlos Pignataro (cpignata)" To: "Stewart Bryant (stbryant)" Subject: Re: Routing Area organization Thread-Topic: Routing Area organization Thread-Index: AQHPlIlZbXSg/HPx4kO5xE5f4P/C2A== Date: Mon, 30 Jun 2014 17:33:04 +0000 Message-ID: References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <53AAAA52.6080701@cisco.com> In-Reply-To: <53AAAA52.6080701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/alternative; boundary="_000_D9F93AB31F7E4428972CDAC68B8A9865ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/jKzbsyt_vMWlkvlg4SYaht2p2PY Cc: Adrian Farrel , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 17:33:15 -0000 --_000_D9F93AB31F7E4428972CDAC68B8A9865ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with most of these suggestions, which align work more functionally = rather than per protocol. I will also note that SPRING is not a contained s= ubset of MPLS, as its charter says " The initial data planes that will be = considered are MPLS and IPv6." A couple of additional observations: * All these effectively reduce the number of WGs (by way of merging or clos= ing). What is also interesting is a way to figure out how to kick off more = work with agility, and RTGWG (or "Routing dispatch foobar WG") should not b= e a default gateway for everything else. * If one of the motivations as laid out by Alia is to "split giant working = groups" to focus work, there's a second phase missing and what is the targe= t of more agile energy. * Another area of interests is how to liaise work -- considering OAM as a f= unction, much of the OAM generic work recently has come out of OPSAWG. I li= ke OAM in routing as a function, but needs to be coordinated outside the RT= G-Area too. * Lastly, while WG reorg and scope is good, it should be only part of the e= xercise. A missing part is how to enable smaller "newer" WGs to deliver on = its goals. Thanks, -- Carlos. On Jun 25, 2014, at 6:54 AM, Stewart Bryant > wrote: I would start by merging the OSPF and ISIS working groups. I agree, although I would make this something like IGPmaint and give it the= scope off all IGPs. I take this position becsue partially because there wa= s a small issue that arose with RIP recently and there was no where to take= it, and partially because I am not convinced we should write off DV protoc= ols yet since they can do some quire interesting things. I might take MRT t= o this WG since it is a routing protocol. I would also pull the OAM functions out of the various groups (BFD, MPLS, C= CAMP, =85) and create one place that can deal with OAM issues. That works. I would probably then merge SPRING with core MPLS functioning. I am not sure about this. IF SPRING reduced scope to MPLS that would work, = but I do not see how you would do IPv6 in the MPLS WG, and it we split it w= e will end up with two forking designs. We have just closed KARP, and I would (unhappily, but I think necessarily) = close ForCES. Agree I would either close ROLLand move the work into a common low power group in= another area, or make ti the common low power working group. That makes sense. I would merge IDR and SIDR. With the current SIDR work program, it no long= er makes sense to me to treat them as separate. I think that this makes sense in the long term (12 to 18months) but I am no= t sure that SIDR is down to the level of work where this would make sense y= et. I would look at merging L2vpn and l3vpn back together. And combining them = with NVO3. Probably also include PWE3 in that set, although that is a hard= er call and may be too different. I tried the LxVPN merge and it was not popular, but now might be the time t= o try again. I don't think NVO3 belongs there since that will set the assum= ption of a L3VPN control plane and although the L3VPN part shoulr probbaly = be moved to the LxVPN or at least the L3VPN WG I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would= fit well with other groups. Given that PWE3 is mainly LDP control plane and not much dataplane anymore,= I would think about merging it into MPLS. - Stewart _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --_000_D9F93AB31F7E4428972CDAC68B8A9865ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4E211100177F614A81E04E1564055AA2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable I agree with most of these suggestions, which align work more functionally = rather than per protocol. I will also note that SPRING is not a contained s= ubset of MPLS, as its charter says "  The initial data planes tha= t will be considered are MPLS and IPv6."

A couple of additional observations:
* All these effectively reduce the number of WGs (by way of merging or= closing). What is also interesting is a way to figure out how to kick off = more work with agility, and RTGWG (or "Routing dispatch foobar WG"= ;) should not be a default gateway for everything else.
* If one of the motivations as laid out by Alia is to "split gian= t working groups" to focus work, there's a second phase missing and wh= at is the target of more agile energy.
* Another area of interests is how to liaise work -- considering OAM a= s a function, much of the OAM generic work recently has come out of OPSAWG.= I like OAM in routing as a function, but needs to be coordinated outside t= he RTG-Area too.
* Lastly, while WG reorg and scope is good, it should be only part of = the exercise. A missing part is how to enable smaller "newer" WGs= to deliver on its goals. 

Thanks,

-- Carlos.



On Jun 25, 2014, at 6:54 AM, Stewart Bryant <stbryant@cisco.com> wrote:


I would start by merging the OSPF and ISIS= working groups. 

I agree, although I would make this something like IGPmaint and give it the= scope off all IGPs. I take this position becsue partially because there wa= s a small issue that arose with RIP recently and there was no where to take= it, and partially because I am not convinced we should write off DV protocols yet since they can do some = quire interesting things. I might take MRT to this WG since it is a routing= protocol.

I would also pull the OAM functions out of= the various groups (BFD, MPLS, CCAMP, =85) and create one place that can deal with OAM issues.

That works.

I would probably then merge SPRING with co= re MPLS functioning.

I am not sure about this. IF SPRING reduced scope to MPLS that would work, = but I do not see how you would do IPv6 in the MPLS WG, and it we split it w= e will end up with two forking designs.

We have just closed KARP, and I would (unh= appily, but I think necessarily) close ForCES.

Agree

I would either close ROLLand move the work= into a common low power group in another area, or make ti the common low power working group.

That makes sense.

I would merge IDR and SIDR.  With the= current SIDR work program, it no longer makes sense to me to treat them as separate.

I think that this makes sense in the long term (12 to 18months) but I am no= t sure that SIDR is down to the level of work where this would make sense y= et.

I would look at merging L2vpn and l3vpn ba= ck together.  And combining them with NVO3.  Probably also includ= e PWE3 in that set, although that is a harder call and may be too different.=

I tried the LxVPN merge and it was not popular, but now might be the time t= o try again. I don't think NVO3 belongs there since that will set the assum= ption of a L3VPN control plane and although the L3VPN part shoulr probbaly = be moved to the LxVPN or at least the L3VPN WG

 

I would leave CCCAMP, PCE, and PIM alone, = as I am not seeing how they would fit well with other groups.

 

Given that PWE3 is mainly LDP control plane and not much dataplane anymore,= I would think about merging it into MPLS.

- Stewart
_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/routing-discussion

--_000_D9F93AB31F7E4428972CDAC68B8A9865ciscocom_-- From nobody Mon Jun 30 11:08:03 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5485D1A03A9 for ; Mon, 30 Jun 2014 11:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.552 X-Spam-Level: X-Spam-Status: No, score=-14.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwTI1nZpjepI for ; Mon, 30 Jun 2014 11:07:58 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A504E1A02DE for ; Mon, 30 Jun 2014 11:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5330; q=dns/txt; s=iport; t=1404151678; x=1405361278; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=DY16kiTSYJhzb3P04TrmCQjFpAvXzTugRcNMa9Kw628=; b=jqxD7I6wb2XwaZupqqznpER4vWcK8DZHKzRuONWD+Hyhdx8+RIctQCcS eSa6SHpve6aqlrbayWKhrnowdBLJKzNGXJxInb3jpLdTgKSNmnFZHZa1o kgk2AkVn2GBktOP3e362wXRDE9tzXwcRzjrmQgmBW2fwzRtXtbbtsGQdY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUHACemsVOtJV2T/2dsb2JhbABagw2sRgEBAQEBAQUBbgGZRgGBEhZ1hAMBAQEEOisUEAsRBAEBAQkeBw8FMgkOE4hCyDMXhWSDaIRZEQECTgeEQwWKR5AWAZN9g2IdgTo X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="57186520" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 30 Jun 2014 18:07:51 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5UI7o1D003176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2014 18:07:50 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s5UI7if5011247; Mon, 30 Jun 2014 11:07:49 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s5UI7gKX011245; Mon, 30 Jun 2014 11:07:42 -0700 Date: Mon, 30 Jun 2014 11:07:42 -0700 From: Toerless Eckert To: Linda Dunbar Subject: Re: Routing Area organization Message-ID: <20140630180742.GG22713@cisco.com> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645D6E6D0@dfweml701-chm.china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D6E6D0@dfweml701-chm.china.huawei.com> User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/eenlSC5dxrhnfER-dRWGDMAKLIo Cc: "adrian@olddog.co.uk" , "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:08:01 -0000 Linda, It would be interesting to see how the IETF can better leverage open source to achieve its goals. I am not sure that this discussion best starts with "lets have a WG centered around it", but rather with questions whether the IETF should consider open source as an actual official output - eg: expand IETF beyond generating RFCs. Cheers Toerless On Mon, Jun 30, 2014 at 04:34:46PM +0000, Linda Dunbar wrote: > I like Joel's suggestions. There are indeed a lot of similarities among L2VPN/L3VPN/NVO3 > The draft-ietf-nvo3-framework (that just pasted IETF last call) depicted the similar framework as L2VPN, except NV03 focusing on using IP as outer header whereas L2VPN having MPLS as outer header. > > Besides consolidating the current WGs, hope the Routing area can start some new initiatives that are different from existing mode of operations. > As the industry is moving more towards open source, it can improve IETF's impact to industry by having a WG to promote Proof of Concept projects that engage multiple vendors and service providers. The Proof of Concept project code can be the baseline protocol specification. > > By doing so, not only it promotes more collaboration among vendors/service providers, it also helps improving the image of IETF being too slow image.. > > My two cents, > > Linda > > > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, June 24, 2014 8:05 AM > To: routing-discussion@ietf.org > Subject: FW: Routing Area organization > > Forwarding with Joel's permission. > > From: Joel Halpern [mailto:joel.halpern@ericsson.com] > Sent: 23 June 2014 17:14 > To: Alia Atlas; adrian@olddog.co.uk > Subject: Routing Area organization > > (Feel free to circulate this if you think it is useful. I don't have the right email addresses on this machine to send directly to the relevant parties.) > > In looking at the discussion of the routing area, it seems to me that the starting premise is very important. I believe we all agree that we want a structure that helps us produce useful RFCs to enable a stronger and more innovative routing system that meets the real needs of the various kinds of operations to deliver Internet services. (I.e the general IETF goals.) > The following are my rough thoughts on this topic, as input to the discussion. > > First, I take it as given that there may well be a better way to structure the work. The structure we have is an outgrowth of years of accumulation. It seems to me distinctly worth looking at whether looking at what changes we can make, what they will accomplish,a nd if any of them are likely to improve our working. Personally, I think this examination is long overdue. Note that even if we decide that we like the current structure, it will still have been worth looking and understanding why we are working the way we are. > > One of the biggest problems I see is the number of times when work has to be presented in multiple working groups, and the drafts revised to address related but disconnected concerns. This waste author energy and working group time. This is a consequence of our feeling a need to control how protocols evolve. And such control is necessary. But needs to be balanced with other needs. Also we all become tourists very often even in working groups we are interested in. > > Any arrangement of work other than treating the world as one working group (which I hope we all agree would be a very bad idea) will need some cross-communciation between groups. But some arrangements produce better commonality. Similarly, any arrangement will produce working groups where some of the work is of less interest to some of the participants. But maybe we can get better alignment? > > A couple of obvious examples. Anything that needs to be done in an IGP needs to be done twice (fortunately, we no longer care about RIP.) Different working groups all need to develop operations, adminsitration, and maintenance mechanisms. But that means they need to redevelop the common understanding of what the needs, known techniques, and hard questions are. > > So I think we would benefit from rearranging the deck chairs. I would try to make the groups focus on external needs rather than on mechanism. > > I would start by merging the OSPF and ISIS working groups. > I would also pull the OAM functions out of the various groups (BFD, MPLS, CCAMP, ...) and create one place that can deal with OAM issues. > I would probably then merge SPRING with core MPLS functioning. > We have just closed KARP, and I would (unhappily, but I think necessarily) close ForCES. > I would either close ROLLand move the work into a common low power group in another area, or make ti the common low power working group. > I would merge IDR and SIDR. With the current SIDR work program, it no longer makes sense to me to treat them as separate. > I would look at merging L2vpn and l3vpn back together. And combining them with NVO3. Probably also include PWE3 in that set, although that is a harder call and may be too different. > > I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would fit well with other groups. > > Yours, > Joel From nobody Mon Jun 30 13:23:53 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017561A041D for ; Mon, 30 Jun 2014 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vxam7w-8QeXp for ; Mon, 30 Jun 2014 13:23:51 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3F91A02FB for ; Mon, 30 Jun 2014 13:23:50 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so5304567yha.3 for ; Mon, 30 Jun 2014 13:23:50 -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=tz0gy7BJHSZzkFqHjuYbFUx8yD41wZv3J/YR0hWtJLk=; b=YqM03/DXAMtobQutevS1q6dw7LX2fdzwhiSdmX3k6HpOHlco0PxGFeMM3kV4pIU1Of m3iwNFV4BV+KqMwxfHJsNQ7TVSLD9PuFPeA9MIhZ0SENtEFHQuFOhd0Z+QzARDI9jsJM BIqwUDEjg5mv/7a1AwIcav/t0V7NUjbchZMdco6bZCEnlCiwBJXifpab9SSlg8FmHSdq IzbldaOcAuD/zwK8f41rErJs43L4kRp75d/rViC+jiTOzu3JZOx/V5Wy4ib2hs9n55He VHR9GS6Mn2KXA9wTSls1i4O2rjygr0b4cXE59j+wM84FbKHyyFf+N9WOKcCaB4lR9imr RWEA== MIME-Version: 1.0 X-Received: by 10.236.191.74 with SMTP id f50mr45707858yhn.9.1404159830246; Mon, 30 Jun 2014 13:23:50 -0700 (PDT) Received: by 10.170.194.19 with HTTP; Mon, 30 Jun 2014 13:23:50 -0700 (PDT) In-Reply-To: <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> Date: Mon, 30 Jun 2014 21:23:50 +0100 Message-ID: Subject: FW: Routing Area organization From: Abdussalam Baryun To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=20cf303f6996e3cb1d04fd136ff4 Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/m7iZ-VgBHiVo5ci6LTt5_DuKzjw Cc: "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:23:52 -0000 --20cf303f6996e3cb1d04fd136ff4 Content-Type: text/plain; charset=UTF-8 > > > *From:* Joel Halpern [mailto:joel.halpern@ericsson.com] > *Sent:* 23 June 2014 17:14 > *To:* Alia Atlas; adrian@olddog.co.uk > *Subject:* Routing Area organization > > > I would leave CCCAMP, PCE, and PIM alone, as I am not seeing how they would > fit well with other groups. > > I am not sure why to leave PIM alone. The PIM is a protocol focus group, so it should be more functional focus, maybe focus on multicast functions. Also other WG that focus on one protocol should consider discussing their WG because usually the ones in protocol-WG are more aware to adapt to other functions. AB --20cf303f6996e3cb1d04fd136ff4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2=A0=

From: Joel Halpern [mailto:joel.h= alpern@ericsson.com]
Sent: 23 June 2014 17:14
To: Alia Atlas; adrian@olddog.= co.uk
Subject: Routing Area organization=

=C2=A0

I would leave CCCAMP, PCE, and PIM a= lone, as I am not seeing how they would fit well with other groups.<= /p>

I am not sur= e why to leave PIM alone.=C2=A0The PIM is a protocol focus group, so it sho= uld be more functional focus, maybe focus on=C2=A0multicast functions. Also= other WG that focus on one protocol should consider discussing their WG be= cause usually the ones in protocol-WG are more aware to adapt to other func= tions.=C2=A0

AB=C2=A0
--20cf303f6996e3cb1d04fd136ff4-- From nobody Mon Jun 30 13:58:09 2014 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA651A00DB; Mon, 30 Jun 2014 13:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hszHi7g2sje; Mon, 30 Jun 2014 13:58:06 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559D11A0300; Mon, 30 Jun 2014 13:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1234; q=dns/txt; s=iport; t=1404161886; x=1405371486; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1xcAqLwImJgrAhkAKsgfZ8s3bwYz1hVNs2i9jrumZo8=; b=asmFw3oHDKwRzaVciKyNWib0P2iLABo0SFDtorRAwWPCUhvp0hEdabW7 iPuBRvTOwPElmvR0DpNR+0AJDeU10SoTWc8AIkue6/OJ1OpFbciZY0E89 6TyF8FeZJYFCUaWzHYFi+gY1km+Cu8JMnxtGV+AWZ2GtBppuWA0az8cUk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwFAEHOsVOtJA2N/2dsb2JhbABagw1Sq3YBAQEBAQEFAW6SB4ZxUwGBExZ1hAMBAQEDAQEBATc0CwULCxgJJQ8FEycPE4g6CA3IKhMEhWSJIweEQwWKR5AWAZN9g2Id X-IronPort-AV: E=Sophos;i="5.01,577,1400025600"; d="scan'208";a="57228096" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 30 Jun 2014 20:58:05 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5UKw5eV000629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2014 20:58:05 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id s5UKw3Pg018378; Mon, 30 Jun 2014 13:58:03 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id s5UKw3W8018375; Mon, 30 Jun 2014 13:58:03 -0700 Date: Mon, 30 Jun 2014 13:57:58 -0700 From: Toerless Eckert To: Abdussalam Baryun Subject: Re: FW: Routing Area organization Message-ID: <20140630205758.GR22713@cisco.com> References: <6BCE198E4EAEFC4CAB45D75826EFB07603179161@eusaamb101.ericsson.se> <023f01cf8fac$e226e360$a674aa20$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: http://mailarchive.ietf.org/arch/msg/routing-discussion/VtI6FtucCBEO9u70HLhe6hZSrUI Cc: "adrian@olddog.co.uk" , pim@ietf.org, "routing-discussion@ietf.org" X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 20:58:08 -0000 On Mon, Jun 30, 2014 at 09:23:50PM +0100, Abdussalam Baryun wrote: > > > > I am not sure why to leave PIM alone. The PIM is a protocol focus group, > so it should be more functional focus, maybe focus on multicast functions. AFAIK, it already has that focus if you read the charter, eg: in general it deals with all IP multicast routing/protocol issues, eg: for example anything MAGMA was doing previously. Multicast things are only done in other WGs when it is multicast+FOO and FOO-WG feels they want to own it. Which in general is a good thing because it help to ensure multicast+FOO becomes more mainstrain within FOO. I may be wrong. Cc'ed the WG for further clarification. The working group name has only been kept for historic fondness. > Also other WG that focus on one protocol should consider discussing their > WG because usually the ones in protocol-WG are more aware to adapt to other > functions. Agreed. Functional grouping is certainly more desirable than protocol centric WGs. Cheers Toerless > > AB > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion